SNOMED CT in Lab Medicine – building the `Community PaLM Extension` on the Unified Test List
As some of you know from my previous posts, my journey in Lab Medicine started with leading England’s national pathology project and going through a life-changing experience that makes me want to see SNOMED CT work for Lab Medicine. Strangely, this post came about as I have been unwell recently, leaving me more time to reflect!
I start by addressing the elephant in the room – `why not LOINC`? The answer in the UK (and some other countries) is simple – we never used LOINC and our migration from other legacy systems is nationally defined/directed towards a single reference terminology aka SNOMED CT. I love the pragmatic approach LOINC takes and have been involved in national programmes that use LOINC (MOHH, Singapore NEHR). We also support LOINC in Pathnexus, our lab-data harmonisation platform. I believe in choices – or horses for courses as they say. However, this post isn’t about LOINC vs SNOMED CT. I will move on to `SNOMED CT in Lab Medicine` and most importantly, how we build on the amazing work of the NHS Digital team on the Unified Test List (think subset of SNOMED CT for Lab-medicine, read more here) to create a SNOMED CT Community PaLM Extension.
The SNOMED CT Community PaLM (Pathology and Lab Medicine) Extension could provide a means for countries to use SNOMED CT as the unifying standard for all of lab medicine, diagnostics – covering histopathology, microbiology, transfusion/transplant medicine, immunology…
For example, imagine countries across the world using this extension for Microbiology – to standardise data about Antimicrobial resistance. You only have to read the WHO post about the World Antimicrobial Awareness Week, to understand why this could be game-changing!
Background
The Unified Test List (UTL) does exactly what it says on the tin. It is an unified list of commonly used `requests` and `results` used in Lab Medicine. Of course its content coverage will be increased in the specialities already included, and extended to additional specialities in lab medicine. However, as the graph below shows, there is already more than sufficient content in it to warrant a serious look. Serious enough for England to approve the use of the UTL as an interoperability standard for lab medicine (starting 2024?).
NHS Digital’s Pathology and Diagnostics team deserve huge credit for getting us to critical mass.
I deliberately say `critical mass`, rather than `minimum viable product` because I believe that there are other things needed to deploy a `minimal viable product` in the wider lab context. This is not criticism, but rather something that I have always envisioned happening in phases for the UTL when I first started this work in 2018. There are two aspects to this – supporting artefacts and scaling content.
Supporting artefacts
For lab medicine to be able to use and adopt the UTL for day to day use, they also need other artefacts (bits of data) in addition to test request/result names – units of measurement, grouper/aggregation concepts, test request definitions, etc. All these allow labs to fully represent (without loss of clinical and semantic precision) the meaning of what was ordered/requested, what result/report was generated on the basis of this report. Representing units of measure in human readable and machine readable (UCUM) formats is an example of such support artefacts and professional bodies like the RCPath in England seem to agree as shown in the PRSB consultation. In our recent SNOMEDExpo2021 presentation, we outlined the reasons why aggregating lab results using SNOMED CT is useful in the real world. There are other supporting artefacts which are needed and they will likely be the topic of another post.
Scaling Content
My experience in multiple national e-health programmes highlighted some `real-world` needs about `content`.
When you think you’ve got enough content, you find out someone needs more!
For a long time, National Release Centres (NRCs) of different SNOMED CT member countries have operated as `publishing houses` synchronising `chapters` of their books with upstream changes by a central publisher. I won’t go too far into the analogy, except to say it can just about be made to work. This involves repetitive tasks multiplied many times over, not just across multiple NRCs but also their downstream affiliates. There is of course the reverse problem, where an NRC wants to contribute a chapter to the central publisher (SNOMED International), but it has a knock on effect on others who might not have any immediate use for this chapter/content. There in comes the attraction of `Community Content` that SNOMED International is encouraging (link to Rory’s post). I call it the start of the `mix and match` model or as a geek the `Java/Python’s 3rd party module/libraries` model.
The UTL is a perfect offering for this sort of model, where NHSD have done the bulk of the work and now other member countries who want to use SNOMED CT in Lab Medicine can simply use this content, extending/constraining it as they go along. In fact, with my obviously biased view I would see the UTL content being the poster-child of community content projects. Of course, this isn’t just wishful thinking since I have spent long enough thinking about it to know how it can be done.
Building the Community PaLM Extension
Just to show possible examples of extension content, I have indicated (based on some previous conversations), where we might find such content. This of course by no means indicates that any of the above organisations have sanctioned/approved this – so please don’t sue me 😂🙈! However, it does mean that taking a `layered extension` approach could work for creating the SNOMED CT Community PaLM extension. My expectation is that if we created a project (perhaps run via SI) around this community content, then we could rapidly scale up the amount of usable SNOMED CT content for lab medicine.
As an example, at Termlex (for reasons I won’t go into), we modelled prototype SNOMED CT content for Transfusion/Transplant Medicine and we identified a subset of about 600-800 concepts and possible new content of 300-400 concepts. A large fraction of these are content that is perhaps reusable by most member countries out there. Likewise, we continue to extend/build on the UTL to create `categories` for helping us address business needs like reporting, analytics etc. Please see the graph below for how those categories look currently in our extension.
At the recent SNOMEDCTExpo2021, several people asked if the work we were talking about could be made available. We have no issue making aspects of Termlex work/content available, and we need the UTL available too. Of course, NHSD makes this content available for download via their collaborative portal and TRUD (UK version of MLDS). However, other groups/member-countries could join forces with NHSD, pooling resources and content, instead of letting the UK release centre do all the work. They did after all get us to the critical mass of content!
Tools for Scaling SNOMED CT content
In Rory’s post, he describes `democratising` SNOMED CT content. This is an idea that was kicking around in my head for a while. At Termlex, we arrived at it from a `ground up` perspective – we want to democratise SNOMED CT content creation by empowering domain experts (clinicians, lab IT specialists, etc).
Our vision is simple – allow a domain/pathology/lab expert to create `fully modelled` SNOMED CT concepts on the fly in 1-3 clicks, without having to be an expert in SNOMED CT. Our execution of this idea in Pathnexus is proving very popular and it enables faster adoption of SNOMED CT.
This again is likely the topic of a separate post, but tools like this that `democratise` or `crowd-source` (😱🙈) content creation, could invert the traditional SNOMED CT content creation paradigm and scale up content in the `Community PaLM extension`.
Gotchas
I would be oversimplifying the issue, if I didn’t mention a few `gotchas`. First is the issue of managing the `layered extension` model in the diagram above. What if someone only wanted the `Microbiology extension` without all the UTL bits? The solution to this is to use `modular ontologies`. Without going into too much detail, it is possible to separate each layer of the `layered extension` into separate OWL ontologies/modules. Of course there is a very cool presentation about work in this space that SI and Manchester University are already engaged in. The second is `sound modular ontology principles` – so that every fully defined concept in the `layered extension` relies on a set of primitives which exist solely in the International Edition or the Community PaLM extension. For example, no `Molar Concentration of X` concept must rely on a concept `X` that comes from (say) the UK Drug extension, since this renders it unavailable to other countries without pulling in the entire UK Drug extension… 🙈The third (and final) part of the issue is – what about all the possibly confusing `procedure` vs `observable` content that exists in SNOMED CT. I believe the Evaluation Procedures to Observables (E2O) project is exploring this aspect. I would then suggest (perhaps controversially) that SI themselves could contribute this content to the Community PaLM Extension, so we can have `standalone` content for SNOMED CT in Lab Medicine!
What next
Why do I make the radical suggestion of a `standalone` SNOMED CT based PaLM Extension for Lab Medicine? My vision/objective is to make lab requests/results/data interoperable. I believe that a Community PaLM Extension would go a long way toward making this viable, even if it is used solely as a reference vocabulary with concept ids. However, for countries that license SNOMED CT, I think SNOMED CT itself provides the ontological framework via Description Logic to connect the Community PaLM Extension to LOINC and NPU. This would then enable true semantic interoperability across all of lab medicine, across all countries irrespective of what code system/standard they use nationally.
If Covid has shown us one thing, it is that we all stand united and can work together irrespective of any boundaries!