SNOMED International’s E2O Project

SNOMED International’s E2O Project — Transmuting Evaluation Procedures Into Observables In SNOMED CT

Among all the various global projects underway to develop and curate SNOMED CT as an international standard for representing clinical information in electronic health records, this one, which I am fortunate to be involved in at the moment, is perhaps a little unsung but is something that is probably a significant step forward in offering a constrained reference ontology frame for pathology and laboratory medicine (‘PaLM’ but I’m just going to say ‘lab’ from now on) reporting and requesting of diagnostic tests. To a newcomer, this might seem arcane but consistency and standardisation have been a long term aspiration in this field and this work sets up the framework for this through the use of SNOMED’s strengths in formal ontology and description logic.

What’s the project?

It’s a project of SNOMED International, the standards body that manages SNOMED CT: The ‘Evaluation Procedures to Observables (E2O) Transfer Evaluation Project’ (E2O for short). It involves a review of ‘evaluation procedure’ content in SNOMED to explore migrating them into an observable entity hierarchy. The codes displayed in the SNOMED procedure hierarchy under [eval proc] arose from a combination of UK test codes and CAP content, tweaked and improved over time. But procedures aren’t the codes that take values in SNOMED.

Why is this important?

This work means we can use SNOMED CT agnostically as common interoperable exchange language for NPU, LOINC, UTL/PBCL and any other lab code system, national or local when we want to transmit, receive and share lab tests and results…anywhere.

This all might sound arcane to people who aren’t SNOMED nerds like me and some history is also relevant for an understanding of why this is useful work but there is also a risk of TL;DR.

A bit of background.

OK, we all know that lab tests are essential for modern medicine and this has been brought forcibly to our attention by the recent rising profile of viral disease epidemiology. And of course these test codes are only a part of the detailed message with result values, reference ranges, alerts, text interpretations, methods etc, that is ultimately transmitted between lab and receiving unit.

Some countries use LOINC for lab test requesting and reporting and some use the Scandinavian NPU system, others like the UK NHS use the PBCL (a legacy ‘Read Code’ based test list mainly used in UK Primary Care) with varying degrees of adoption or simply bespoke local test lists with local coding. Since the PBCL or the evaluation procedures also exists in the UK edition of SNOMED CT, it would appear that this existing content can be used to represent test results. However, there is a catch here…or several!

How does SNOMED CT fit in?

The usable bits of SNOMED (the rest being definitional scaffolding etc) are findings/disorders, procedures/therapies, contextualised findings and procedures (called situations), medications and observable entities. Observable entities are a ‘Janus’ thing in the middle that looks both ways: back towards the action (procedure) that was done to elicit the observable and forwards to the clinical finding that is an interpretation or conclusion from the test result. A simple example of an observable entity is:

‘Plasma sodium concentration (observable entity)’.

Observable entities like this take a value such as ‘138’ to which is attached a unit of measurement (UoM) like ‘millimoles per litre’ (mmol/L).

This information is modellable and definable in the observable entity model but is not available in the procedures hierarchy and it is actually an historical matter that the concepts to which we want to assign numeric values ended up in the procedure hierarchy. This is not an issue as such if one sees compartmentalised code systems and cross border data sharing as just something to live with. We have to acknowledge locality specific framing and also accept that some holy grail of one universal code set is unrealistic.

We cannot therefore use content from the (evaluation) procedure hierarchy describing measurement activities to represent lab results, i.e. the observations that are the reported output of the measurement, without migrating this evaluation procedure content into the observable entity hierarchy — the basis for the E2O work! (This issue skates around some interesting issues of metrology that we cannot tackle here but it is worth being aware of this enormous and complex specialist subject.)

Here are a couple of examples of procedure content that the procedure hierarchy model does not support and cannot define sufficiently to safely take an appended field entry and thus in need of revision and definition using the observable entity model:

Lipids measurement (procedure)

Clostridium difficile toxin detection (procedure)

Is the first ‘total lipids’ repesult or a lipids panel request or a semi-quantitative test? In what? What UoMs will the numeric values take? Could the second mean that the toxin has been detected? Where? Remember the context is sharable information; the requester will know the context needed to interpret the reported result but how will anyone else? How would a lab interpret these requests?

Why else would we use SNOMED CT?

What holds existing systems back is an ontological definition within an ‘acyclic graph’ tree structure and this logical definitional structure (and, crucially, it’s machine readability) is one of SNOMED’s strengths. The advantage here is to exploit SNOMED’s formalism to anchor LOINC or NPU or PBCL/UTL in a formal shared definition and not to replace them. A shared reference/source backs these distinct code systems through a common logical definition in coded form. I have said elsewhere that implementers assume that a standards body direction to ‘adopt SNOMED’ means ‘to replace all coding with SNOMED’ in an ‘up front display ’ way in records. This is not necessarily the case.

What we did — Approach

I was fortunate to end up working with an expert in this ontological field; Dr James R Campbell MD of Nebraska Medicine, University of Nebraska Medical Center. Jim Cambell is an acknowledged expert in the field of SNOMED and LOINC representational ontology on top of his clinical standing. Under the direction of the SI Observable Entities Project group through a convened E2O sub-group of senior terminologists, we took a list of laboratory focused evaluation procedures (a subset of the broader ‘evaluation procedure’ category) and used UK usage data to prioritise a list of concepts as candidates for migration so as to be able to take a numeric or text value as observables. Our goal was and is to obtain a starter set of concepts that fitted the observable model better and could be treated as observable entities. We were seeking a set of conventions for standardising terms as definitions that could then be used to inform modelling and define the content in SNOMED. This focused on lab test results but the approach is extendable into other evaluation results from measurement procedures.

We carried out a series of validation steps such as excluding codes that could not take a single value such as test panel codes (e.g. complete/full blood count, urea and electrolytes). We were left with a set we were able to define by a core set of observable entity attributes, such as component, specimen and property. What was immediately clear, if not already known, was that the bulk of content could not be transformed to become fully defined concepts that could be used to represent a LOINC or other code in sufficient detail. We confirmed, using established SI editorial principles, that coded terms must not be interpreted beyond what they state by some form of ‘well, we think they probably meant to say…x’ and thereby, re-expressed in ‘better’ words; changing terms can be dangerous. We found that a lot of content would have to be represented in the observables hierarchy as a more generic ‘heading’ code for content so that coding for content more clearly aligned with LOINC, NPU and UTL in detail and definition could sit ‘underneath’ the migrated E2O as subtypes in the tree structure. This is not a problematic outcome; it allows a structure of content to be inferred and supports a non-disruptive migration path as users move to more granular subtypes for test reporting.

The E2O group were able to load the data into a classifier and generate an ‘.owl’ file that then is the basis for publication. The next steps on the journey involve finalising the machine classification of the migrated or transformed SNOMED content. We will also ensure terming is consistent and editorially compliant and we will be working to share this structure as draft content in an international community space for review and consultation. This then opens up further possibilities for testing out how this could be accessed as a framework and/or used to align the more granular lab test subtypes needed for test definition.

In further posts I will dive into more detail in this continuing project.

Want to discuss more about the E20 Project? We’re always open to chat

We hope you found this article on `A Single Interoperable Ontology For Pathology and Laboratory Medicine` interesting. If you have any questions or feedback, please shoot us an email at [email protected].

Termlex is a start-up that specializes in interoperability & informatics — SNOMED CT, HL7 FHIR, Lab data standardisation and app development. We support the implementation of SNOMED CT and FHIR in products and projects. Our team has experience of supporting implementation in diverse settings from startups, enterprises, and hospitals to national programmes across different countries. We can help you unlock the benefits of these standards via terminology servers, APIs and specialist tooling to support your needs. We also offer software/app development to turn your innovative clinical idea into a product!

Want to read more? Check us out on Medium, LinkedIn, Twitter and our Website to discuss more ideas and topics like this!

Other Resources

• SNOMED International Introduction: https://www.snomed.org/snomed-ct/why-snomed-ct
• Termlex SNOMED CT implementation Services: https://termlex.com/snomed-ct/
• Termlex SNOMED CT content authoring and migration services: https://termlex.com/snomed-ct-content-authoring-migration-services/