Blog Details

This article covers a key aspect of confusion — about why SNOMED CT has findings that look similar to a lab result. More importantly, we cover why you might not always want to rely on just the SNOMED CT code alone to represent all the entire lab report.

Recap — if you haven’t already followed the first part, please go refer to it. It covers the request and result aspects — aka the first 2 rings of power!

‘Findings’ perspective — the third ring of Power!

If you have followed things so far, then you will find this straightforward. Everything that comes out of a lab as a result/report is about `what was observed/found` and in the broader context it is just a `finding`. They are not the `end` of the chain/triangle, but rather a trigger for an `intervention/action` in the clinical pathway. Yes a `finding` could lead to another `request` and the triangular activity can go on but in most cases it leads to an intervention by the requesting clinician and an improved health outcome for the patient (hopefully). From a patient’s perspective too, these are what is of most interest and so you won’t be surprised to find that there is a lot of content in SNOMED CT around findings.

Types of Lab `Findings`

Lets first look at the types of things that a lab report contains. While from a generic perspective it makes sense to group/categorise findings as `normal` or `abnormal`, there is a tricky problem here. It also goes to the heart of how these `findings` relate to the `observations` reported by the lab. So think of it this way — if `my height is 180 cm`, then someone measured/observed that about my height and found that my height is 180 centimeters. So:

`Jay’s height as observed` = `180 cm` as measured using a `tape` (for example)

My `height` is something that can be observed/measured. Now remember the definition of `observable entity` above is exactly this. So in effect, in the SNOMED CT world, `height of a person` is you guessed it, an Observable Entity! So now `finding/observing` this thing is a `fin`ding`… So in the SNOMED CT world semantically:

`Finding of Height` (Clinical Finding) = `Height of a person (observable entity)` + `180 centimeters` [numerical value not coded in SNOMED CT]

This would also apply logically if someone were to observe/interpret this as `tall/short/average` based on some reference. Since that is still a finding, except the 180 cm has now been replaced with something more qualitative like `tall/average/short` etc. There are various types of `qualitative` results (ordinals, nominals, etc) which is a topic for another time.

If I combine a Result/Observable-entity with a numerical value, or qualitative value or even an interpretation, they all generally fall into the `findings` category in SNOMED CT. This is why when you search for `serum calcium`, you will find results like:

So why Observable + Value concepts as findings?

By now you should have understood that combining an `Observable entity` with a `qualitative` (words like high, low, medium, normal, abnormal etc) or `quantitative` (numerical) results. So you could ask — if we have:

1. An `agreed` list of possible `qualitative` values — (e.g. HL7 produces these).
2. An `agreed` way of representing `qualitative` values (called numbers 😂)

Then why would we have these `combination findings` (calcium high, calcium abnormal, calcium normal) in SNOMED CT?

The answer while not satisfactory is legacy/history. Yes, back in the mists of time when people and systems found it easier to use a single `code` (aka the concept id) to find all `normal` or `abnormal` results instead of just using a combination of `code` (Observable concept id) plus a a value (textual or numerical). Why?

Think about this — the lab specialist usually releases a `report` with a result (assuming the test isn’t incomplete, etc), which almost always carries an `interpretation` of what the test was showing. So yes the report might say:

Remember the `optional` interpretation column? Well most times, the lab actually releases this since they flag if the result is normal/abnormal based on the reference ranges. There is no problem with the requesting clinician (e.g. GP reading this), but think about it about a `epidemiologist` or `statistician` which wants to retrieve a list of all patients who had an `abnormal ionised calcium` at admission (e.g. to rule out biological variations in bisphosphonate dosing), then how would they query the data? Here is the `pseudo_sql`

Select `patient_id` from `patient_tabel` where `test_id` = `<concept_id_of_ionised_calcium>` and (`value` < 4.64 or `value` > 5.28`)

Select `patient_id` from `patient_tabel` where `test_id` = `<concept_id_of_ionised_calcium>` and (`interpretation` = `abnormal` OR `interpretation` = `high` OR `interpretation` = `low`…)

You can’t always rely on just the first query, since what is `normal` or `abnormal` depends on the `reference range`. If you are unsure why, then please refer to our previous post… So somewhere along the line, someone thought, how about we avoid all this and maybe just get the requesting doctor to record this as `abnormal` (and all its variants) as a single coded record entry which should solve the problem. So you guessed it… we now have (and need) codes (aka SNOMED CT concepts with concept ids) for all these… The end result is a proliferation of such `interpretative codes` in SNOMED CT. It is also worth remembering that some of this goes so back in history, that computer systems had RAM measured in `kilobytes` and processors in `hertz`, not in multiples of those!

Gotcha in Interpretation Concepts

Before we all agree with the creation and continued use of such concepts (hopefully you don’t), here is an example of where such things can go wrong…

The guidance for `euglycaemia` (aka good glucose control for diabetes) was changed for a test called `HbA1c measurement` from 7 to 6.5. So if we have previously just used a single `code` in SNOMED CT to represent this but forgot to save the `value`, then historical data analysis becomes a problem.

So if you design a healthcare system with results of any sort, try to persist/store as much of the `lab report` as possible without relying on a single interpretation/finding code. Medicine constantly evolves!

Reductionist View — A Logical Fallacy?

So let’s’ revisit all this together as sometimes people attempt to reduce all this into something very simple:

• You have a concept `xxxxxx` for the request for `ionised calcium`
• You have a concept `yyyyyy` for the observation/result of `ionised calcium` which can take a numerical (quantitative) or qualitative value.
• You have a concept `zzzz` for the finding of `ionised calcium being normal` (or abnormal, or elevated etc).

They then apply reductive logic to this and ask — why can’t we just have a single concept `xxxxx` and just use this everywhere. In fact, people will tell you that they use the same `code` in their system for both request and result and it works just fine. What they really mean is, they cause this confusion and they let someone else in the system/product side handle this mess, just because they can’t be bothered to do things systematically in a principled way.

This sounds very seductively simple and very logical. Except, it breaks down quite quickly the moment you get into details:

So if you asked the question `what constitutes a Liver Function Test (LFT)`, they’ll tell you:

• Alanine transaminase (ALT)
• Aspartate transaminase (AST)
• Alkaline phosphatase (ALP)
• Albumin and total protein
• Bilirubin
• Gamma-glutamyltransferase (GGT)
• L-lactate dehydrogenase (LD)
• Prothrombin time (PT)

You can clearly see they are all separate tests, so really we can’t have a single code for the `request` and the `result` of this test. You might speciously argue that `ah, but we can reuse the same code for the `report` and just add `normal/abnormal` to it. If you have followed anything I said in the above section, hopefully you understand why this is a bad idea.

What about simple Tests ?

Here comes the other argument — but `we can use the same code for simple tests like Urea, Cholesterol, etc`. I will refer you to something in the previous article — about lab scientists and analysis being very precise about how the result was derived. There are multiple techniques for analysis -and even for what you think is simple automated testing like `colorimetric method`, there are many variants. I can hear the argument coming — but we don’t care about this, so it can be ignored. Not true!! Medicine is always evolving, which means techniques for analysis are always changing and we want to know how two tests compare with each other when the analysis method was different. We don’t want to just rely on manufacturers to tell us this, we want to trend and compare them over time.

So if you really want to distinguish between two `results for say urea` that use different methods, you want to record this. So in fact, there are no simple tests — you just choose to treat them that way.

This is actually why LOINC is amazing and is very precise and detailed. It tries to record exactly what the lab scientist did to produce the result.

I am not bashing anyone who currently does this. I am making the case for why laboratory medicine and reliable data matters for the future. So please let us not try to use specious logic to hold oursevlves back from benefiting from advances in medicine and testing technologies!

Considerations for Implementation (or LIMS roll-out)

Understand the rationale for different hierarchies in SNOMED CT and your use case. Hopefully this article gave you enough information about why a single coded entry is not always representative of a lab report. Here are some principles to keep in mind:

• Always try to store the qualitative fragments of a lab report alongside the interpretative element
• Aim not to reuse the same `identifier` for everything in the life cycle of an investigation
• Aim to leverage features of information models like HL7 FHIR and OpenEHR to handle the qualitative and interpretive aspects of lab reports
• Aim not to reduce/downgrade the level of information that comes out of your LIMS where possible — you reduce the resuability of data in the future.
• If you are standardising your lab data, always use the most specific level of concept you can find in LOINC or SNOMED CT.

This article isn’t about making you all informatics experts or SNOMED CT experts — there is a reason why Termlex specialises in this space and spent decades building expertise. Some of our products like Termnexus takes a lot of the pain away from the creation and maintenance of such `constrained use case specific lists` (think ValueSets from the HL7 FHIR world).

Of course, if you are embarking on the journey of consolidating your lab data, procuring a new LIMS or generally care about aggregating all your lab data then check out Pathnexus — our lab data harmonisation platform that allows you to handle the differences between SNOMED CT hierarchies and also use LOINC.

Want to discuss using SNOMED CT or LOINC in LIMS, EHR or personal health records?

Want to discuss your electronic health record (EHR) implementation strategy with us? Want to see how some of our products can lower barriers and accelerate your system (EHR, LIMS, etc) rollout? Then please feel free to get in touch with us!