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

Sandy Jones

CDC

Stan Huff

Graphite

Ed Heierman

Abbott / IICC

Andrew Quinn

Laurent Lardin

Biomerieux

Anthony Killeen

UMN

Craig Collom

Walter Sujansky

FDA

Susan Downer

JMC

Reviewing the WG scope

Made updates on the page

• Discussion around what IVD testing is (add opertional definition)

• add parking lot for items we can't decide at the moment

  • Will serve as a running list of data elements that we need to keep track of and may require coordination with other workgroups (like standards and terminology).  Will allow the LIDR workgroup to continue to make progress and not get stuck.

  • Added to parking lot:

    • Calculations

    • Observations done by analysts.

    • Test cutoffs - probably need to examine by test type.  For example, account for differences between:

      • Drug testing - SAMSA cutoffs

      • PCR/molecular

      • Chemistry

      • HIV example - repeatedly reactive

      • Semi-quantitative

    • Calibrators

      • May come up in discussion during next week’s presentation from vendors.

      • Could move from the parking lot to in/out of scope.

    • Provide guidance on best terminology representation for specific methods. 

• Confluence section renamed from Scope to ‘Scope and Purpose’

• Clarification on workgroup activities

  • tackling both the repository of data itself (LIDR) and a data standard

  • Data standard would include data elements relevant to interpretation of test/result and important to the data flow but not explicitly included in the repository (also described as data elements that inform user of usefulness of result and are essential to interpretation of result) – lot number used as an example.

• Discussion regarding what is in-scope for the broader SHIELD project and what is in-scope for the LIDR workgroup specifically.

• Division of labor - LIDR/Standards+Terminology

  • Orders and calculations could be covered by the standards and terminology workgroup.

  • Conversely, if S+T identifies data elements that should be included in LIDR, that would be a feedback loop back to us.

• Description of two main issues around encoding of tests:

  • Correct LOINCs are not being assigned consistently.

  • Even if labs are correctly and consistently coding tests, the LOINC codes themselves don't have enough information to distinguish certain aspects of tests (UDI of device, SNOMED coding of qualitative results)

    • these elements can differ from test to test and lab to lab, and the resulting variability makes it difficult or impossible to perform comparison and analysis.  The big question: What is needed in terms of data elements and granularity to allow for meaningful comparison of tests/results from different labs?

  • Considerations

    • Method - that information typically does not appear on lab reports currently and is sometimes included in LOINC codes (but sometimes not)

    • Will instrument vendors determine units of measures for their tests? Will they assign SNOMED codes to qualitative results for their kits?  If so, who will determine if they've done this correctly?  Part of the work of this group will be to determine the role of vendors.

• Operational Definitions

  • Section added on confluence.

  • What is the operational definition of IVD test? 

    • Only what's coming off an instrument/test kit?

    • Does this include calculations? Ratios, timed components, challenges?

    • Observations performed by analysts (for example, urine clarity and color)?

    • Orders?  Original LIVD files doesn't have orders in it however it can be helpful to have LOINCs relevant for orders when they are available (like multiplex panels)

    • Scenarios when multiple analyzers need for orders to be completed?

  • May want to solicit feedback from IVD manufacturers.

  • Some calculations are well established and standardized - like LDL (calculated, not a direct measurement).  If we include ONLY what is coming off the instrument, we are omitting some of these more commonly ordered measurements.

More background on UDI

Future topic / different parts / how assigned:

Reviewing the use cases

Started Outline document: https://aphlinformatics.atlassian.net/wiki/spaces/SC/pages/edit-v2/2020966449 - has section on use cases

• Use Cases

  • Need to define who is going to consume LIDR, how,  and for what needs?  This will inform how we meet those needs.

  • LIDR is needed because, at labs, often the person doing the coding is not an expert in the laboratory testing being performed.

    • LIDR improves coding accuracy.

    • Clear difference between LIVD file on CDC website and LIVD file available through manufacturer. Accuracy was better for CDC file.

  • LIDR would:

    • Support correct coding for LOINC - expansion of LIVD to include units, specimen types, methods

    • Address the 'why' of coding, which is standardization that would ultimately to allow for comparison and analysis.

    • LOINC is good at identifying the analyte but for method (that would allow for comparability), need UDI.

    • There will still be mapping that needs to be done by analysts but having a constrained set of codes is a much better starting point than the entirety of the LOINC and SNOMED code systems.

      • For example, SARS-CoV-2 file included attributes not currently in the LIVD file including setting (at home) or pooling.  These attributes help to narrow down the list of relevant codes.  Assists both the person doing the mapping at labs and the agencies receiving the data.

    • Other potential uses (which may or may not be in scope):

      • FDA interested in data elements that are helpful in doing post market analysis.

      • Test performance - right now, we can't identify which instrument results come from.  If we could identify the instrumentation on patient samples, we can monitor population averages - faster detection of assays that need correction.

      • Moving averages of patient results can be used for quality assurance.

Timeline for work products

• scope for this working group by end of August

• outline of white paper by end of October

• Deadline for requirements for LIDR MVP – end of October