Mapping maintenance and implementation

This section looks at considerations for map maintenance and implementation. In addition to the pathology and laboratory medicine terminology mapping requirement, these are widely applicable to mapping other national interoperable terminologies. Key considerations are: 

• end-user mapping maintenance
• architectural requirements
• implications for standardising mapping development and implementation – specific guidance for the lab domain

As a national list of reportables, SNOMED CT PaLM will grow as new lab tests are added, and changes will be made through ongoing quality assurance. It is not a static artefact. Consequently, maps to SNOMED CT PaLM should not be static, and will need updating as SNOMED CT PaLM changes. If a lab’s practices change (such as a test that was performed in plasma changes to being performed in serum), the map to SNOMED CT PaLM will need to change. 

Therefore, to ensure data integrity it is necessary to:

• replace retired SNOMED CT PaLM concepts with their replacements 
• map to more suitable content created in later versions of SNOMED CT PaLM 

SNOMED CT Historical association reference set mechanism

Finding replacement SNOMED CT content can be done through SNOMED CT’s historical association reference set. This technical reference set enables users to find replacements for retired components (in this case, SNOMED CT PaLM reportables) by describing the association between them. Details on these associations are available from SNOMED International. 

The crucial consideration is that the majority of the changes will be categorised as ‘SAME AS’. In such cases, this generally doesn’t require review (See section 8 - roles and responsibilities) as the replacement concept is identical to the one retired. Other relationship types such as ‘POSSIBLY EQUIVALENT TO’ do require more consideration and would need to be reviewed.  

Mapping tools can use the information within the historical association reference set to automate maintenance, as shown in the example below:

A user might choose to automate the changes (where the ‘SAME AS’ association is in effect) or manually review, allowing them to choose a different SNOMED CT PaLM reportable if appropriate, as shown in the example below:

For governance purposes, the tool should then record the changes with an audit history so users can understand what changes were made, when, and by whom. Any changes would need to be captured and recorded for governance and provenance before being rolled out in live systems.

The architectural requirements became more visible as the PaLM Mapping Project team worked through the functional and technical requirements of terminology mapping tooling. These requirements are mainly specific to: 

• data loading 
• maintaining latest releases of interoperable terminology code systems 
• maintaining and sharing concept maps and value sets for referential terminology optimisation, training language models to support mapping, and for lab reuse and implementation 
• the capability to point to other SNOMED CT extensions to glean available content to pull into the national SNOMED CT release instead of duplicating creation of SNOMED CT content
• publishing and releasing concept maps and value sets in the international standard FHIR data model format 

Details of the architectural design can be found in the Appendix.

Users should consider two main options for developing, maintaining, and extending local terminology to standard interoperable terminology mappings. These options are based on the belief that one-to-many mappings are an implementation burden and introduce risk, as this lends itself to inconsistencies between labs. 

1. Where there is ambiguity in historical terminology mappings, and many-to-one mappings (such as local reportable to Read PBCL maps), labs should create new local reportables to map to more granular SNOMED CT PaLM reportables.

As part of this process, we recommend clustering duplicate/replicated codes (both source and target codes). The expert reviewer can then quickly identify any potential historical errors/duplicates/inconsistencies in an individual lab’s code list, or a pathology network’s combined code list, and to remap the old many-to-one mappings to specific SNOMED CT PaLM reportables.

If there is no available SNOMED CT PaLM reportable, labs should not apply a generic code mapping. Instead, labs should request new SNOMED CT PaLM content to accurately match the source content.

2. Labs should standardise data entry lists as structured terminology component building blocks that render as granular SNOMED CT PaLM content in the reported interoperable message. In other words, create a professionally led system input standard for the ‘minimum information about a lab test result’ per lab discipline. 

This standardises the interoperable ‘synthetic primary key’ created in the middleware that auto-maps to SNOMED CT PaLM (see Appendix).

These options are vital to successful terminology mapping implementation. For the pathology and laboratory medicine terminology mapping requirement, and other use-cases, they ensure remapping to more specific reusable, comparable SNOMED CT terminology. 

As a case in point, SNOMED CT PaLM removes ambiguities around specimen types. A coded blood specimen, for example, no longer represents blood materials like acellular blood, plasma, or serum, as seen in legacy representations of lab data such as Read PBCL. This makes old representations of ‘whole blood’ redundant, because in SNOMED CT PaLM, ‘blood’ means ‘whole blood’. Blood specimens are differentiated and specified in the result types of SNOMED CT PaLM and so must be mapped to correspond with the exactness of the source lab analyser’s output. This precision is crucial to enhancing the accuracy and comparability of patient test result information, both by human interpretation and machine-readable interpretation.