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: LIDR White Paper - 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
All please review LIDR White Paper - add to outline, make comments on use cases, add use cases
All please review LIDR WG so we can sign off on the scope for this WG in the next call or two
All Add operational definition of IVD.
Walter to coordinate with FDA to request background information on UDI
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.
