Generic LOINC code as a temporary placeholder for lab tests yet to be mapped to LOINC

Greetings!

Tapping into the collective intelligence of the greater LOINC committee.

Does anyone know, if there is an existence of a generic LOINC code which can serve as a temporary placeholder/interim solution for lab tests to adopt?

Similar question has been asked before in 2015, link: Generic LOINC code for when no code exists? - laboratory-loinc / other-lab - LOINC Community Forum.

How does your nation/lab resolve LOINC mappability issues for lab test without LOINC?

Thank you!

2 Likes

Hi Chee,

This is a large multifaceted topic. Is there an issue within your EHR and/or healthcare system with just leaving a laboratory test mapped value to LOINC blank or null?

To the best of my knowledge, there is not a LOINC code that may be used as a temporary place holder, nor do I think there should be.

Had a temporary code existed In the U.S., this would have defeated the purpose of Meaningful Use legislation that drove the adoption of electronic health record systems in years 2010 - 2015. After that, the use of such a code could potentially have had adverse impacts on National Committee for Quality Assurance (NCQA) reporting by making it more difficult to filter out laboratory tests that were not mapped.

I would also have to go back and look at the HL7 FHIR Resource for laboratory, but I believe the requirement for a LOINC code carries a “SHOULD” binding meaning that if an organization has it mapped to a valid LOINC code, it should be included in the electronic messaging. If a laboratory test is not mapped, then this value should be left blank. Mapping to a temporary LOINC code would make this filtering much more difficult.

I would also caution against creating an Organization specific temporary LOINC code. I saw this done by an U.S. based healthcare organization back in 2013 and it created problems because no other healthcare organization had that code in their terminology server so all it did was generate interface errors for the receiving organization.

Perhaps I am missing something. Do you have a specific use case you are attempting to resolve using a “placeholder/intermim” loinc code as opposed to leaving the field blank or null?

Thanks
John

1 Like

Hi John,

Thank you for your detailed insights regarding LOINC code implementation and the concerns about using placeholder codes. I appreciate you sharing your experience from the U.S. healthcare system perspective.

I would like to provide context regarding Singapore’s unique situation. The Ministry of Health (MOH) has been implementing mandatory LOINC coding for laboratory data contributions (specifically lab test identigy) to our National Electronic Health Record (NEHR) system. While we’ have been successful in LOINC adoption since 2018 across both private and public laboratories progressively, we are now facing a specific challenge with the upcoming Health Information Bill.

The bill is expected to propose that all laboratory data contributed to NEHR must be in LOINC. However, we recognise that achieving 100% LOINC coverage is impractical due to:

  1. Emerging laboratory technologies
  2. New tests awaiting LOINC code assignment
  3. Tests that may never receive LOINC codes

To address this regulatory requirement while acknowledging these practical limitations, we are considering implementing a non-LOINC code structure that exists outside the LOINC schema. This would serve as an “escape valve” for laboratories to maintain compliance with the Health Information Bill while accurately indicating tests that cannot be mapped to LOINC.

I understand your concerns about the U.S. experience where placeholder codes complicated NCQA reporting and created filtering challenges. However, our proposed approach differs in that we are not creating a temporary LOINC code, but rather a separate coding mechanism that clearly distinguishes non-LOINC-mapped tests from LOINC-mapped ones.

Would you be willing to share your thoughts on this alternative approach? We believe it might offer a practical solution while avoiding the pitfalls you’ve described from your U.S. experience.

Looking forward to hearing from you!

1 Like

Hi Chee Yuen,

Thank you for the additional context. This is a complex topic with no single correct resolution.

Instead of creating a whole new “non-LOINC based code system” to manage this content, have you considered authoring this content in the Singapore extension of SNOMED CT?

I see that MoH Singapore has registered a SNOMED CT namespace identifier (1000132) which means that Singapore has the ability to create and publish its own extension of SNOMED CT. Based on the information located at Singapore, it appears that Singapore is actively using their SNOMED extension and generating content as well as publishing releases.

Using SNOMED CT as the “non-LOINC” code system would eliminate the need for Singapore to “recreate a wheel” that already exists within the logical definition for an observable entity within SNOMED CT. There are several advantages to pursuing this solution:

  1. Placing this content in SNOMED CT means it is can immediately be used in HL7 V2 and FHIR messaging structures with no need for additional code system OID or URI content to support the message structure.
  2. Immediate code system versioning and release processing in a standardized format already in use within Singapore
  3. It would allow Singapore to leverage the work being done as part of the LOINC/SNOMED partnership that has led to the creation of SNOMED Extension of LOINC content. (https://loincsnomed.org/). Granted, there is a bit of a learning curve with using the alternate identifiers and understanding the difference between it and an exact map.
  4. Long term, this may allow Singapore the ability to more easily leverage any mapping work done between LOINC, SNOMED, and NPU for global interoperability.

Normally, I would be able to point out any deficiencies that should be taken into consideration by going down this path, but I am struggling to come up with any. There may be some political hurdles that need to be crossed between your LOINC and SNOMED Terminology authoring teams but these would be topics that are specific to Singapore that I would not be familiar with.

Does this idea resonate with you or perhaps it is already the direction you were thinking of pursuing?

Best,
John

1 Like