Fixing the NHS PBCL Legacy issue affecting lab results - common misconceptions

Fixing the NHS PBCL Legacy issue affecting lab results - common misconceptions

Background

For those who are not from the UK or even if you are in the UK NHS but don’t wear some of the informatics/data hats you might or might not be familiar with the PBCL. Pathology Bounded Code List (PBCL) is a legacy standard that is used to share the `coded` (aka the test names part) of lab results. It is a subset of the Read Codes that were created as a companion to the other half of the lab messaging standard (EDIFACT) in the 20xx years, to ensure that all results received by the primary care systems were standardised. Please pay attention to the `results` and `primary care systems` parts of that statement. So if you receive a lab result and it is coded, the `name` and `code` of the result is from the PBCL.

The Read Codes have been deprecated since April 2016. So no new Read codes can be added, which means if there is no Read Code for a lab test already in existence before that date, there can be no new PBCL codes. This has been characterised as a `burning platform` to showcase the need for this standard to be replaced as soon as possible. Apologies to our regular readers for the dramatic banner image, but it seemed appropriate given the `burning platform` analogy. This is the reason why NHS England created the Unified Test List (UTL) as a replacement for the PBCL (alongside HL7 FHIR for EDIFACT). However, here are the sort of things we hear often from people:

  • If only NHS England (previously NHS Digital) could issue some more new PBCL codes, we could fix the problem
  • All our test results are standardised when they are sent to primary care systems (aka PBCL coded), so we don’t have any issue with sharing results.
  • If only NHS England (previously NHS Digital), released a 1:1 migration table from PBCL to SNOMED CT, we’d be standards compliant in short order

The last one being the most misleading of the statements. But characterises the harmful misconceptions about the current state of both the PBCL and the way it is being used. Before this comes across as an attack on anyone or any group, please note that we are all passionate about helping patients and clinical safety. So if any of the misconceptions about the PBCL could result in patient harm or clinical safety risk, then we should clear them.

So without further dragging this on, here are the misconceptions about the PBCL that need clearing up.

Misconception 1: One to one map from PBCL to UTL codes can exist

This is an easy enough assumption to make — that for every PBCL code that is being used, there will be an exact replacement in the UTL (aka SNOMED CT). I can see why on the surface it might appear to be the case. Here are some sample PBCL codes that are common enough as you can imagine:

  • Fluid Sodium Level [4Q43.]
  • Fluid sample Amylase [4I3E.]
  • Calcium Level [4Q72.]

Two immediately obvious questions popup when we look at such codes:

  1. How do we know what exactly we are measuring when it says `level`?
  2. Is it the presence, substance concentration (mass or molar), enzyme concentration, catalytic activity, etc
  3. How do we know what specimen (or thing) this is being measured in?
  4. There can be many types of fluids — blood, serum, plasma, cerebrospinal fluid, ascitic fluid, pleural fluid, etc

Yet, we see such tests with PBCL mappings in some of the test catalogues we look at. Don’t get me wrong, for each PBCL code above, there are also corresponding `level` concepts that specify the specimen. So question #1 still remains unresolved and gets in the way of ever creating a 1:1 mapping since without knowing what is being measured, we can never have that explicit mapping. Here are some examples of PBCL codes with specimens specified:

Pathnexus screenshot - showing PBCL matches for sodium levels with different specimens

The UTL by design was created to address this ambiguity and make things a lot more specific. In that sense, it aligns more with a results focused approach of the world (since it was designed to replace the PBCL which codes lab results). So here are the sodium related concepts in the UTL, showing clearly the higher level of detail required to address those questions (both #1 and #2) that we raised above:

Pathnexus screenshot - showing UTL matches for sodium with greater detail

Way forward

Without knowing more information, even the lab specialist will be unsure exactly what needs doing. If you say `these look like some sort of requests` with some accompanying clinical note, then you’d be quite right. Since that is what most of these things are — they are erstwhile request codes (aka Procedure concepts) which have been masquerading as `result` codes (Observable entity concepts). This is a case of the first ring of power (Request) trying to impose its view on the second ring (Request) causing confusion. So the only people who’d know what a `serum sodium level` corresponds to are the lab specialists because they know locally what it is they do when they receive that request. In fact, most lab specialists would know this intuitively once they see their own `test` with the relevant SNOMED CT matches alongside the PBCL code. Here is a screenshot of this — attempting to map `fluid amylase` with the correct concept using Pathnexus (our lab data harmonisation platform).

Pathnexus - matches for Fluid Amylase without suggestions

In this case, the lab specialist likely wants to select `catalytic activity of Amylase` since this is possibly what is done. We can’t always know this ahead of time and it is highly unlikely that any one person (or group) can determine what this means for everyone nationally! However, we can make it easier for the lab specialist by suggesting a `best match` or `promoted match`, like we do in Pathnexus (based on what other users have selected) — see below:

Pathnexus - matches for Fluid Protein with best match suggestion

We would love to create a shareable/reusable repository of this model so we can all benefit from the collective work done in the NHS. So if you find this interesting or want to contribute to this, please get in touch.

Misconception 2: All our lab is PBCL coded, so we don’t need any new standards

This is another oft-repeated statement we hear — our lab data is standardised already, so not sure why we would need this UTL (or SNOMED CT or LOINC thing). Let’s be clear — medicine is constantly evolving. The Read Codes have been frozen for 7 years now (since April 2016). So unless we believe no advances have been made in medicine that need new lab test results to be shared, this misconception has no basis. I genuinely think this is a case of the person not understanding what perhaps their lab IT specialists are doing behind the scenes to plug gaps.

The way cardiac troponins are used in the detection and treatment of heart attack has changed in the past decade. We now have high-sensitivity cardiac troponins (hs-TnT) that are used more often. These don’t exist in the PBCL and exist only in the UTL.

Here is a screenshot of matches in the PBCL and UTL respectively. You can clearly see that that is only the UTL that has relevant content in this case. This is just one of the many examples where the PBCL is simply no longer sufficient for what is needed for routine clinical care and ensuring patient safety.

Matches for cardiac related tests in the PBCL
Matches for cardiac related test results in the UTL

Digression — Credit

I would like to digress to give credit to our colleague Sarah Harry for our strategy of engaging with the digitally mature secondary care organisations like Addenbrookes, Leeds Teaching hospitals, etc such content would never have made its way into the UTL. I would also like to draw attention to Mark Hannigan for bringing to attention the fact that a similar problem exists in the case of cancer screening results, where important results are not being standardised/coded sufficiently.

What happens when no PBCL code exists?

If there is no existing PBCL code that matches a test that is being requested or performed, it is `tagged` (via some bit of the archaic EDIFACT message) as an `uncoded result`. What this means is that at the receiving end (e.g. the primary care practice) someone has to manually review this result and `code` it for it to appear in the right place and get seen in the right way. I would like you to spend some time thinking about this — the thousands of times this is likely being done every day when our NHS is already under enormous pressure. Now think of the other aspect — it is re-coded by someone at the GP end. So there can be clinical safety issues if these uncoded tests are assigned the wrong code. So a patient who was meant to appear for further testing is not called in and 6 months later they present with a worse medical condition. To put that in context — think about cervical screening and how important it is for all women (that’s half our adult population)! I know some would say, just add the relevant instructions for re-coding onto the result/request form. This is a work around, but we need to fix the main issue. We can never fix the main issue, as long as people keep thinking the PBCL is perfect and does not need fixing!

If you have been using the PBCL to standardise your lab results, then you have a leaky roof. You might have various buckets in place (or someone else might have done it without your knowledge). But, the clinical safety problems will catch up eventually…

What can we do today?

If you understand the nature of this problem in the NHS, then please share this post with your network.

The wider and better recognition of this problem there is, the easier it will be for us all to move forward to using the new standards (UTL and HL7 FHIR).

I have deliberately not covered issues with the messaging part (current standard — EDIFACT) and why we would want to move to HL7 FHIR, but that is at a more technical level. If you are currently migrating your systems or procuring a new LIMS, now might be a good time for you to truly look at migrating to the UTL standard. The next section is about our product that can help with the standardisation and migration, but please feel free to skip it.

Pathexus, is our lab harmonisation platform that was designed to ease the migration of your local codes to the new UTL standard (based on SNOMED CT). It allows you not only standardise your local test catalogues but also harmonise your lab data across your network. It comes preloaded with all the future and legacy standards and with a workflow that places a focus on clinical governance of your test catalogues and eventually your lab data!

Want to discuss lab data standards, results sharing, pathology data harmonisation? We’re always open to chat

We at Termlex believe that all clinicians and patients would like to have the ability to access and compare diagnostic results from anywhere irrespective of their origin. If this is something you believe in and would like to chat, come talk to us… If you have any questions or feedback, please contact us!