Date

Nov 27, 2023

Attendees

Bolded names were present

Name

Organization

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

Agenda and Notes

Topic

Notes

Reviewing minutes from the last call - Action Item Follow up

Google Sheet review and discussion

  • Goal of LIDR:

    • Identify the complete meaning of a lab test - identify all elements needed to be shared with every instance

    • Identify if results from two tests can be called equivalent / be comingled

  • We need to clearly describe:

    • how LIDR is intended to be used (prioritize the use cases)

    • who is building it - need to stress that this will need funding!

  • What will be mapped in the LIS?

    • unique identifier linking to the LIDR entry?

    • LOINC only?

    • lab test name?

    • ANSWER: Identify all elements needed to be shared with every result instance and in what field each element should be sent

    • LOINC as well as value sets for the identified elements

  • How is LIDR different from LIVD?

    • LIVD = provide info to suport LOINC mapping

    • LIDR = standardize data elements from LIDR for each entry in the instance data = LIDR = additional mappings for data elements that must be sent for ech instance - identified in the Potassium Analyzers googlesheet as bright pink columns

      • added more columns to include

        • Reference Range

        • split out Vendor Result Description into 3 columns

          • scale (not sent) to identify if Qualitative (narrative, nominal or ordinal), semiquantitiative or Quantitative)

          • QL result value sets (Coded in SNOMED CT)

          • QN result units of measure (coded in UCUM)

            • example: mmol/L and mEq/L are not the same - should be represented in 2 different rows

  • Will LIDR provide naming guidance - example Serum Potassium Molar for test in row 4?

  • Use manufacturer name and analyte for searching

  • For specimen type - set up different rows when package insert allows serum or plasma?

    • yes - should have 3 rows to cover the real world situations of instrument supports either vs lab calibrated to one fo them specifically, as serum cannot be used on plasma calibrated instruments; specimen type MUST be sent in all cases to be consistent

    • vendors should submit all allowable permutations

    • we need to provide guidance on what labs need to do

    • some usecases may have other requirements - for example for SARS-COV2 reporting the committee decided to split saliva samples from any respiratory sampletypes, even though the respiratory sampletypes could also be assigned to more detailed LOINC systems in some cases, but were combined for this publication

  • We need to have answers for why we are asking labs to do these things that are more than what they are currently doing - should be a section in white paper (supports more detailed interpretation of lab tests)

  • need to have clear guidance to the vendors and the labs on when sample types/units should be split

  • example could be the inventory use case, where we have supply chain issues for certain container types - if not specific specimen type (which translates to container type for some)

  • This all requires curation - and that requires funding - need section in white paper for rationale for funding curation

Next Steps

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

Next call

Monday 12/4/2023 9 - 10 AM ET

Adjourned

10:05 AM ET

Chat:


Recording:


Action items



Quick decisions not requiring context or tracking

For quick, smaller decisions that do not require extra context or formal tracking, use the “Add a decision…” function here.



Decisions requiring context or tracking

For decisions that require more context (e.g., documentation of discussion, options considered) and/or tracking, use the decision template to capture more information.

Create from Template