Date: Fri, 29 Mar 2024 09:39:12 -0400 (EDT)
Message-ID: <1589186347.1267.1711719552306@pe-confl01.extra.infoway-inforoute.ca>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_1266_728381893.1711719552304"
------=_Part_1266_728381893.1711719552304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Lessons Learned<=
/h2>
The mapping of the Laboratory Information System (LIS) test catalogue to=
the pan-Canadian LOINC Observation Code Database (pCLOCD), once completed,=
requires ongoing maintenance to keep the maps current. The pCLOCD is publi=
shed in Excel or Access format, it is expected that mapping projects have a=
ccess to a mapping tool (LOINC Mapping: Planning). The pCLOCD and the parent standard, LOI=
NC, provide updated releases twice a year.
Considerations:
- Is there an established maintenance cycle set up to support the mapping=
s?=20
- Is there a process in place to support out of cycle changes?
- Is there a change management process that requires submission of change=
s made in the LIS and any upstream systems such as EMR=E2=80=99s?
- Have all the internal and external resources to support changes and new=
releases been identified and secured?=20
- Are vendor resources required to apply any of the changes identified?=
li>
- Are there charges associated with vendor support?
- Is maintenance being managed in a decentralized or centralized model?=
=20
- If decentralized, is there a process in place to ensure changes were no=
t overlooked between sites and were applied consistently between LIS maps?<=
/li>
- Are the published releases from the Standards Development Organization=
=E2=80=99s (SDO=E2=80=99s) understood or is additional training, resources =
required?
- Is each map supported with an audit log that keeps track of changes to =
the map?=20
- Is documentation required to support changes, deprecations and code pro=
motions?=20
- If so, where is the documentation maintained and do the right people ha=
ve access to it?
- Are the data elements utilized in the implementation provided only by p=
CLOCD?=20
- Has additional metadata been added or pCLOCD data been modified (i.e. i=
nterface terms that are not part of the published artifact, overwriting exi=
sting viewer names, extension codes)?
- Can the codes that are in use by the implementation be identified easil=
y?
- Has a maintenance checklist been created?
Is the architecture of the repository understood w=
ell enough to analyze changes that may affect historical information?
Recommended Actions=
:
- Maintenance cycles should be established early in the project life cycl=
e.=20
- Consider creating a road map that identifies new releases and associate=
d timing as well as providing windows for other changes to occur.
- Maintenance changes usually involve a number of resources (internal and=
external) and need to be planned for accordingly.
- Most SDO=E2=80=99s publish new releases of their terminology biannually=
. Although it is not imperative to update systems with each release, each o=
ne will need to be analyzed for impacts to current mappings. Out of cycle c=
hanges will also occur if local extension codes are being submitted for con=
sideration to the parent SDO.
- LIS systems tend to change frequently. To maintain the integrity of the=
repository and other destination systems, changes must be considered as so=
on as they occur, and schedules put in place to implement those changes. Im=
plementation project should ensure that a request for change process is in =
place early with all appropriate stakeholders. This process will be used to=
accept and distribute changes that are made to maps and associated codes a=
nd local tests.
- If repositories are sending lab reports to upstream systems such as EMR=
=E2=80=99s, a change management process should also be in place to support =
receiving changes and submitting changes to those systems.
- Timing of the changes needs to be managed to make sure that as each sys=
tem changes it does not cause a subsequent error in the upstream receiving =
system.
- Resources that are required to support changes and new releases may inc=
lude system administrators, business analysts, Information Technology/Manag=
ement (IT/IM) analysts and vendors or contractors. Ensure the costs for cha=
nges that involve vendors or consultants are accounted for, especially if i=
t is anticipated that changes will be implemented and billed as they occur.=
If costs are charged by occurrence rather than lump sum, this could become=
quite expensive.
- Systems administrator or IT/IM resources will be required to:=20
- Get access to the new release;
- Upload the new release to the development environment of the tool (if a=
pplicable), ensuring adequate backups etc. are in place prior; and
- Create and run queries and provide reports.
- Business analysts/system administrators will be required to:=20
- Get a list of codes in use in each map;
- Identify queries to look for changes that impact maps;
- Analyze reports for impacts to maps;
- Review new codes to see if they address any mapping problems or are sim=
ilar to existing extension codes;
- Do any remapping required;
- Implement approved changes into the production environment; and
- Implement changes in the LIS.
- Vendors/Contractors/IM/IT resources will be required to:=20
- Implement changes in the repository and any upstream systems (EMR=E2=80=
=99s etc); and
- Run associated Quality Assurance processes and Conformance testing as r=
equired.
- If possible, look for ways to consolidate maintenance changes across di=
fferent LIS=E2=80=99 if maintenance is being managed in a decentralized mod=
el. This will help ensure that changes were not overlooked and are applied =
consistently between LIS maps.=20
- If maintenance is managed centrally then all of the changes can be anal=
yzed at once and a list of changes created and communicated to the resource=
s from each LIS or EMR etc. along with the implementation schedule.
- Not all release artifacts are supported by extensive release notes. If =
release notes are published, ensure they are available and provided to all =
the resources that may need them.=20
- Allow sufficient time after receiving the release notes to review and a=
sk any questions prior to the start of the update.
- Each change that is made to a map, especially a map that is used in a p=
roduction environment, should be documented along with supporting informati=
on that explains the change. This information should be kept in close proxi=
mity to the actual map if possible.=20
- The audit log should keep track of the date the map was effective and t=
he date is was inactive as well as any changes to the code that is associat=
ed with a map.
- If a code is deprecated and replaced with a new code, it is beneficial =
to include a note along with the map that indicates why the map was changed=
.
- If the implementation has added metadata to the map ensure the update p=
rocess does not overwrite the data when the new release is loaded into the =
system.
- Biannual releases of pCLOCD/LOINC need to be compared to the codes in u=
se.=20
- Changes to codes not in use will have no impact on maps and may only ne=
ed to be analyzed for other purposes.
- It is important to generate all queries based on codes in use and those=
codes need to be easily identified for this purpose.
- A checklist is required to ensure all changes have been analyzed for im=
pacts to existing maps. Ensure the checklist contains procedures to support=
the following:=20
- Periodically LOINC codes change the component name, typically to add cl=
arity or to correct a component that was misrepresented. This change is lik=
ely to impact the map. (i.e. A LOINC code changed from =E2=80=98metho=
dless differential=E2=80=99 to =E2=80=98manual differential=E2=80=99 which =
significantly changes the use of the code. The historical records needed to=
maintain the original meaning of =E2=80=98methodless differential=E2=80=99=
but any new records needed to be remapped. In this scenario it may be impo=
ssible to maintain two meanings for one code and therefore future use of th=
e changed code is prohibited. An extension code would need to be created fo=
r future mappings of both =E2=80=98methodless differential=E2=80=99 and =E2=
=80=98manual differential=E2=80=99).=20
- Anticipating this type of change early in project planning allows suffi=
cient time to create processes to support a change of this magnitude.
- Each release contains codes that are deprecated. Implementations are en=
couraged to deprecate the use of the code and remap to the replacement or a=
n alternative code.=20
- This change may have impacts on trending, graphs and any other statisti=
cal analysis that is relying on the unique identifier of the code.
- Consider looking for an opportunity to build in relationships between c=
odes that would support this process.
- New codes are added with each release.
- New codes can have two flavors; the first is the new code that originat=
ed from the SDO release and the second is the code that was created as a re=
sult of the submission of an extension code by the implementation. New code=
s that are created as a result of the submission of an extension code by th=
e implementation require additional considerations:=20
- Making a change to the unique identifier is a significant change to a c=
ode and to the mapping relationship and should be planned out carefully to =
make sure all possible implications have been considered both upstream and =
downstream from the repository.
- There are at least two models to consider to support the conversion of =
an extension code to a new code;=20
- The first is to add the new code, deprecate the local extension and rem=
ap.
- The second is to update the local extension with the new code identifie=
r, which by default creates a new mapping relationship between the identifi=
er and the local test.
- In each model ensure that there is a way to associate the local extensi=
on to the new code similar to the association created for a deprecated code=
.
- All changes that are done to existing maps need to be considered in lig=
ht of what exists already in the repository and in any upstream systems.=20
- There are many ways to query information from a database, and if a key =
requirement is based on the LOINC code for a specific purpose, the work wil=
l be impacted each time there is a change to a map that is not supported by=
cross relationships or supporting documentation.
Get Involved:
Join a collaboratio=
n group to solve interoperability challenges.
The Health Terminologies Community is a open forum for sharing and communi=
cating on topics of terminologies and classifications and their use in Cana=
da. We welcome all participants.
------=_Part_1266_728381893.1711719552304--