Page Comparison

Use cases

• Determine whether you can trend two tests on the same line in an EHR flowsheet?

  • Alignment ------

  • Comments

    • data aggregation can hide quality issues

• Support laboratory public health reporting and data aggregation with minimal manual curation?

  • Alignment ---

• Detect quality issues at an arbitrary point in the laboratory analytic workflow (e.g. a given reagent lot)?

  • Alignment ------

  • Comments

    • Where does quality discussion take place?

    • Ensure historical accuracy of critical data elements as standards and specifications change over time

    • How do we create the necessary ones

    • Quality can depend on external groups

• Determine the comparability of two laboratories’ data for use as real-world evidence?

  • Alignment ---

• Evaluate the likely transferability of a clinical decision support model between hospitals?

  • Alignment ---

• Identify laps in currently used nomenclatures that are not comprehensive enough.

• Create comprehensive interoperable nomenclatures by using similar novel NLP as google does

• Identify the frequency of the presence of differing unidentical longitudinal mapping within the same Health Information System and version, across a 6 month period, across the still not interoperable nomenclatures.

• Integrate differing nomenclatures LOINC, LIVID, etc. into a full interoperable system that will avoid unnecessary mapping.

• Need to identify the frequency of non-calibrated results for equivalent analytes

• Integrate clinical information specialists that can help integrate the necessary pieces and evaluate the resulting outputs

• Make it accessible to a person reading it and support manual mapping by providing guided support where multiple mappings are possible per the IVD manufacturer

• Make it accessible to a computer for automatic mapping suggestions as much as possible

• Help the IVD vendor to create the content for the LIVD file

• Support upload of IVD vendor created content to the LIVD file repository

• Support review of submitted content, with workflow support for further clarification and official publication after review

• Would tooling include tools needed to map the vendor LOINCs (and SCT qualifier values) from IVD vendors? (i.e. an authoring tool)? 

• Is another part the maintenance of the LIVD maps (to changes in IVD vendor product info, instruments, UDIs, as well as to code systems like LOINC and SCT)?

• Assuming "highly reliable semantic interoperability" is defined so we know when it is achieved?  Hopefully the source of truth for the definition for a lab test is also defined and where in the information flow (see VRE example below).  Is it the test in the EHR?  Is it the test in the performing lab's CLIA/CAP specimen collection manual?  Is it the test in the performing lab's LIS build? The answer will dictate the coding and semantic meaning needs.

• Provide data to support a pathway for approval of EUAs, and to monitor performance of EUAs and approved IVDs

• Identify the data elements early (even though we know we will need more) so we can approach the industry early to start working towards adding support for elements they are NOT yet supporting

Use Cases

At a high level, the SHIELD Initiative’s clinical interoperability effort has three major goals:

• Clinical interoperability of laboratory results

• Public health surveillance and reporting

• Performance monitoring of in vitro diagnostic tests

Necessary Tools and Functionality

Problem: Mapping laboratory tests to terminologies is non-standardized, error-prone, and highly labor-intensive. The end product is ineffective for the above use cases.

Solution:

Develop tools that:

• Define a single source of truth for correct mapping of IVDs to codes and make it easily accessible

• Assure the quality of the mapping process to guard patient safety

• Contain all necessary data elements for downstream use cases

• Ease import and maintenance for laboratories, manufacturers, and health IT vendors

• Clearly communicate to vendors what they must support in the future

Measures

• Most of the hospitals in this country do not have a valid decision support system for the prevention of sepsis

Suggested test data elements

• Test name

• Test code, system, version

• Specimen source name

• Specimen collect date

• Specimen condition if altered (e.g. icteric)

• Specimen code, coding system, version

• Name of performing laboratory

• Address of performing laboratory

• Test report date

• Result

• Result code, system, version

• Units of measurement

• Test interpretation (if applicable)

• Pertinent reference intervals or normal values

• Standardization or harmonization status and a pointer to reference standard

• Unique device identifier +/- method

• An update mechanism for errors or changes affecting interpretation

• Test kit ID, kit version

• Reagent lot

• Calibrator lot

Necessary repositories

...

A reference repository for a manufacturer, device model, test code/result code/standardization or harmonization status

...

A unified terminology server for test/result/specimen names and codes

...

Necessary Data Elements (General Classes)

Problem: To support clinical interoperability, we need detailed enough information about tests to:

• Uniquely identify a single testing event for a patient

• Uniquely identify all tests of a certain class (e.g. all the same IVD, or the same analyte)

• Do so in a manner that is easily extensible

Solution: Support the following elements

• Clinical interpretation data elements

  • e.g. result value, specimen, units, reference ranges

• Semantic/ontological data elements

  • e.g. SNOMED, Solor, LOINC-on-OWL

• Device/manufacturer data elements

  • e.g. UDI for device, IVD, kit

• Standardization/harmonization information

Timelines

Problem: Much of the clinical interoperability effort relies on tools that haven’t been built yet, coordination of complex issues between large organizations, and vendor support of standards that haven’t been defined yet

Solution: Approach goals incrementally. Some necessary projects can be started immediately, whereas others will require multiple years for adoption. Even the ones that require years (e.g. vendor functionality) need to be started as soon as possible.

By Year 1:

• Define semantic resource solution

• Define necessary identifiers and data elements re: LIDR, UDI, standardization/harmonization

• Develop LIDR Implementation Help Portal

• Flat file and web access to necessary static data sources

• Immediately engage vendors on likely necessary support

By Year 2:

• LIS/EHRs begin to support new features/data elements

• Application programming interfaces to necessary static data sources

• Authoring tools for LIDR/UDI assignment

By Year 3:

• LIS/EHRs complete ability to store and exchange all necessary data elements

• Automated lab catalog and data dictionary maintenance tools

• Third party search

• Laboratory data repository

• IVD data hub

Measures

• Out of scope. Defer to Effectiveness Committee.