2024-01-08 LIDR Meeting Notes

Hung Luu

Children’s

Riki Merrick

Vernetzt, APHL

Andrea Pitkus

UW

Pam Banning

3M

Xavier Gansel

Biomerieux

Amy McCormick

Epic

Dan Rutz

Epic

Rob Rae

CAP

Rob Hausam

Hausam Consulting

Sandy Jones

CDC

Stan Huff

Graphite

Ed Heierman

Abbott / IICC

Andrew Quinn

Laurent Lardin

Biomerieux

Anthony Killeen

UMN

Craig Collom

Marti Velezis

 Sonrisa / FDA

Walter Sujansky

FDA

Susan Downer

JMC

Ralf Herzog

Roche

Cornelia Felder

Roche

Daniel Golson

JMC

Andrea Prada

JMC

Maria Sagat

 CAP

Raja Cholan

FDA

Russ Ott

FDA

Akila Namasivayam

FDA

Reviewing minutes from the last call - Action Item Follow up

• Pull out the definitions from LIVD for test kit and equipment and put here: SHIELD Glossary

  • Review operational definition of “equivalence”

• Outreach to Dr. DeBaca

  • Hung will check for more info and maybe see, if she could participate in SHIELD

• Hung is still working on the examples

• Waiting for response from Ed

• Keep updating the googlesheet: Potassium LIVD data

• Have LIVD File Repository Requirements

  Have draft budget (for setting up a web-based database and yearly maintenance): https://aphlinformatics.atlassian.net/wiki/download/attachments/915407143/LIDR - Budget.xlsx?api=v2

• Sign up for sections to provide draft content on the LIDR White Paper

• Review LIDR Use Cases and sign up to lead one of these

Call Schedule

Riki out on travel 1/15 and 1/22; at HL7 WGM 1/29

No call 1/15, Hung will run 1/22 and 1/29

Review LIDR White Paper

For next call (1/22) review the written sections - add inline comments or edit directly (use strikethrough instead of deletion for content sections) and include initials or name with the comment / edits

Renaming LIDR

FDA had requested to change the word represented by the “R” in LIDR from Repository to something else - see email text from Keith:

LIDR acronym has bugged me because the R = repository, which is implying instance data rather than metadata or knowledge.

I propose a tweak that preserves the LIDR acronym, but substitutes some words that work better for me:

Laboratory Interoperability Data Record

Or

Laboratory Interoperability Device Record

Suggestion:

Laboratory Interoperability Device Reference

Laboratory Interoperability Device Record

Or even combine:

Laboratory Interoperability Device Reference Record

Discussion:

Device is too constraint

Repository is a place you put stuff

Laboratory Interoperability Data Reference (if folks then add “repository” it still works

Laboratory Interoperability Data Reference library = LIDR library

Keep Repositiory = 5

Change to Reference Library = 1

Google Sheet review and discussion

For Full meaning of test / comparability would need: Specimen Type, Specimen Source (site or organ system), Specimen Collection Fields

also need to know which are FDA approved vs LDTs

What if we want to exclude the specimentype in LOINC (XXX) but that is not encoded in SNOMED - should be a value that is the high level applicable code in SCT

LOINC has a project to replace XXX with values that would be globally legal - create a {valueset drawn from SCT}

Is LIDR representing the meaing of the test or what is to be shared in the message - we have to keep both in mind, but they may not exactly be the same

example you would be tissue as a higher level code.

how will it differentiate between type (entire ear submitted as specimen) vs source (swab from ear, where ear is the source site) - where type would probably be Swab (rather than all the pre-cooridnated specimen types) - in specimen CMT we should lean towards use of prototype term - for wound culture would be swab or aspirate (or maybe just “specimen”)

When source is not needed here - use the organ system instead of the actual location of where the needlestick was done, since there is no difference in the blood if it is collected from left or right arm veins - so for ser/plas = type collected is whole blood

SCT defintion for type - what is collected

SCT defintion for source - where is it collected from

dealing with derived specimen is another issue altogether - source is often used to capture that

how to indicate what to populate for source:

• leave blank

• not needed to be communicated

• N/A

• blood

• actual collection site (all the legal places the blood was collected from)

What if there is only “albumin” in the data exchange - MUST have the type (urine/blood/serum)

many EHR-s have dictionary values that are comingled for specimen type and source - The Laboratory Messaging Community of Practice (LabMCoP) has been working on a solution for representing single field netires and mulit-field entires for speicmen attributes for the different domains for a long time - strugling with how to publish it https://aphlinformatics.atlassian.net/wiki/download/attachments/1852900247/20200601_CBR_SCM_OnePager_v04_final_cleared.pdf?api=v2

In LIDR - type and source are needed fields

depending on type of test we need type / source, but it may not be as important in some cases (when type is swab, source becomes very important)

Open

ANDREA POST_Call Comment on the image:

It looks to me (but needs to be confirmed), the Specimen Type is likely the top "Blood," while the Specimen Source is the next row, "Blood, Unspecified Source" and the Specimen Collection Procedure is "Venipuncture."

 As such I'd initially read that the High Sensitivity Troponin I is performed on Blood, as a Specimen Type of Serum or Plasma is not indicated.

Looking at LOINCs for Troponin I, we see the following codes.

Based upon the Blood specimen type, I'd be inclined to map to the blue LOINC:  https://loinc.org/42757-5

You'll note there are no high sensitivity method LOINCs on blood though, so this would be the best map.

However, if the specimen type is truly serum or plasma analyzed, then the best LOINC map would be in yellow aligned with the units, reflecting the HS method, etc. which is LOINC  https://loinc.org/89579-7

 Would need to confirm with the performing lab as the source of truth.  If this is UNL 

Open

 Is this from UNL?  Let's assume it is for argument's sake, their hsTropI on their lab test menu is here:  https://www.testmenu.com/nebraska/Tests/276610

You'll note on the first tab, they perform testing on plasma.  The last tab indicates their LOINC is 89579-7, which matches the specimen type, method, troponin i, etc., which I'd agree with.   If you are receiving Blood for the Specimen Type, it appears there is an error somewhere in the information flow process.  Is it with which Specimen Type Catalog term is being associated with Troponin Test and it needs to be updated to Plasma for allignment?  Less commonly, it could be what is in the HL7 message or in an interface hub that is applying Blood, or potentially in the receiving EHR system.  If the latter two, these are the types of issues the Sequoia Lab Tiger team members are also noting as lab data receivers.  

Once we establish what should be occurring (accurate/complete info), we may want to work on Best Practices/recommendations if it is due to content builds/mapping in individual LIS and EHRs, so labs can fix these and improve data quality and ensure accurate/quality info is available for end users.  If it is due to functionality in LIS/EHRs, then that may be addressed from a certification aspect.  Maybe some HIT vendors are unable to apply specimen type or source to some tests (while others have no issue).  It may be ensuring all are on the same playing level so to speak.  Detective work is needed to try to determine the root cause as part of the complexities with lab data interoperability are different or multiple factors may be involved with what is seen.  

Another aspect of today's discussion reveals there are different definitions for Specimen Type, Specimen Source, and perhaps Specimen Collection method.  This is common across the healthcare space for the last decade or so.  Same terms with slightly different meaning have been used across different federal regulations too (CLIA vs ONC over the years vs HHS/CMS).  Then HL7 and SNOMED CT have their meanings for the terms too (which is what I was describing).  There may be some EHR/LIS data dictionary descriptions for these items that may have used older terms and not updated for customers in the last decade resulting in some putting the "wrong terms" in the wrong dictionaries and thus they are encoded with the wrong SCT hierarchy codes, placed in the wrong HL7 message field for receivers like PH.  Thankfully, most jurisdictions have a process to check these before widespread production messages start.  They are often caught and corrected.  Often the same terms/codes are used in exchanges with EHRs/others LISs/HIEs, etc. too.  Are there other needs as we think about the future state/needs?  It shows how one aspect can have widespread impact.

That said, I'm glad we agree on the need for Specimen Type and Specimen Source fields in LIDR.  Did we end with agreement on how to indicate if say Specimen Source is not as vital for the meaning of a Potassium row?  (I've been using the term N/A or not applicable which may not be the best words to use.  Feel free to jump in with better terms to communicate if the field is required for Potassium, a nice to have, etc.)  Maybe I should rephrase to say does it contribute/is it needed for the full meaning of our Potassium row?  I'd argue Specimen Source does not, but Specimen Type does.  Is that the discussion we want to have in two weeks?

ACTION ITEMS

Please see the action items at top of this page - Next deliverable is White paper outline by end of this year

And we need to prioritize the use cases, so that we can finalize the requiements for the first phase of LIDR, which need to be included in the White paper

Next call

Monday 1/22/2024 9 - 10 AM ET

Adjourned