Your chance to be a trending expert in IT industries and make a successful career after completion of our experts.
Enhancing Pathology/Lab Tests using SNOMED CT Observables
Enhancing Pathology/Lab Tests using SNOMED CT Observables
Are you trying to make sense of Lab Test results using SNOMED CT ? Have you ever come across `Sodium Level` and wondered if this is a request/order for Sodium measurement (104934005 |Sodium measurement, serum (procedure)|) or if it is a result (1107871000000107 |Sodium substance concentration in serum (1107871000000107)|? Well you aren’t alone in the confusion. It can all be a bit hard if you are a busy clinician or a lab specialist. There is good news, as there is now some interesting work in the SNOMED CT community to address this.This article is the first in a series that looks how SNOMED CT can be used in the world of laboratory medicine (or pathology for UK folks). It covers three broad aspects of how we can
slice and dice lab/pathology data using SNOMED CT,
use the Description Logic Classifier to do this clever stuff and
use some simple programming (in Python) to make SNOMED CT and its underlying technology (DL/OWL ontologies) work for us
Of course, you can read/follow each aspect separately if you are only interested in one/some of the things we cover!
The work being done by the SNOMED CT Evaluation Procedures to Observables Entity Group (E2O group for brevity) is attempting to bring some clarity around the `Evaluation Procedure` vs `Observable Entity` concepts and associated hierarchies. There is a long explanation of the principles in SNOMED CT around this in the Editorial Principles. The first line of that page should summarise something important for us:
### Observable Entity vs. Evaluation Procedure
The observable entity and evaluation procedure hierarchies have some of the same attributes. There is not and should not be a one-to-one correspondence between the two hierarchies.
Why is this relevant?
So why is this E2O work relevant, what can we use it for and what else can be we learn from it…? Turns out a lot actually, if you can take the work and build on it. For those of you who know, Pathology and Lab Medicine is an area of active work in the UK around the Unified Test List (a SNOMED CT subset/refset and a DABP approved standard). So in the near future, NHS organisations in England will want to start conforming to this SNOMED CT based standard (Unified Test List). We have been working away quietly in this space – helping NHS organisations migrate their existing legacy (local, PBCL, etc) codes to the Unified Test List using Pathnexus (our Lab data harmonisation platform). But a significant part of what labs and that world cares about is also operational. For example, they would be interested in:
How many biochemistry tests did we do last year?
Of the biochemistry tests, how many were done on blood or urine?
Of the Covid tests we did in the last 6 months, were done with technique RT-PCR as opposed to LAMP?
You can see some of these questions are trivial but some are also generic and very applicable to a wider problem/use-case. What is needed here is something very simple but powerful – `aggregation` or `slicing` of data based on the use case. This is the beauty of the Unified Test List (and inherently SNOMED CT). With the right modelling of the underlying SNOMED CT concepts, we can use a powerful technology called the Description Logic Classifier to slice and dice data to answer exactly these sort of questions!
A bit of complexity – Description Logic & OWL
I did mention Description Logic classifier, so you can infer that there is something called Description Logic(s) and a Classifier and that somehow the work being done by the E2O group uses it. So no surprise it does – and their early work is an OWL ontology which has plenty of classes in it. Any explanation of what Description Logic is and what a DL reasoner/classifier does is well beyond a single blog post. Suffice to say:
Description Logic – is a way of `describing` (really defining) a/the world in logic (first order) that allows machines to make some clever inferences
DL Classifier – the engine that allows the machine to build an understanding/interpretation of a/the world we modelled, so it make those clever inferences.
So you first need to model the world and when you need to classify it – you get some clever inferences. People usually use a tool called Protege to model their world as an ontology (please don’t ask me to describe/define this). Once you build your ontology, you can save it different formats, but a popular format is the Web Ontology Language (OWL). So with that out of the way, let’s look at what the E2O ontology has using Protege. Here are some screenshots:
Some initial problems/confusing stuff
Notice how the `things` (classes) in the ontology seem to be numbers? These happen to be SNOMED CT concept ids, which we will see how to fix later in this series. Also see how the classes under `Observable entity` seem to be a flat list, instead of much grouping going on? But isn’t SNOMED CT meant to be all hierarchical? So how do we make sense of this and fix these things…
Before we get too deep, lets remind ourselves of what we wanted to do…
End Result – Aggregating Lab Test Results using SNOMED CT
If we do all our stuff right, what we expect is to be able to use the DL reasoner/classifier to answer those questions from above. This is why you are following this series yes? As a reminder, here is one of our examples:
Of all biochemistry tests, how many were done on blood or urine
To answer this question, we first need the DL reasoner/classifier to tell us how blood/urine tests there are in the say 100/200 tests our lab offers. So can the DL reasoner/classifier do anything clever to collect/gather say all the ‘tests done on urine’ (the classes that are modelled using urine as a system/specimen)?
The answer is – yes it can and here are some screenshots!
Please follow the series to understand how to we can use the DL reasoner/classifier to do this, fix problems like those annoying concept ids and of course get hands-on with some Python code (if you want) along the way!