EDITING INSTRUCTIONS:

Option 1: Click on the pen (Edit) to make changes directly in the text:

use strikethrough to preserve changed text sections (don;t worry about tracking typos and don;t worry about formatting) - if you want to make sure people know you made the edits, add your initials (and if you want to pick a font color for your edits, you could do that, too). Click on Publish when done to save.

Option 2: Highlight the text you want to suggest a change for and use the bubble (in-line comment) feature; these changes will not be in the actual text, so may be a good option when your comment is more descriptive / explanatory, rather than creating direct content.

1        Strategies

This section sets out the strategies needed to transform the current US laboratory landscape into an interoperable system.   The Strategies are interdependent and include feedback functions to ensure quality of the data.  

1.1        Expanding beyond the LIVD (LOINC In Vitro Diagnostic) Mapping

Assigning all codes and identifiers neccessary to properly identify the performed test in order to determine if results in health records can be reliably exchanged and understoodcan be can be a daunting proposition for the laboratorian that is setting up the new test in their LIS/LIMS to be included in their service catalog – the goal of the LIVD file[i]  is for the IVD manufacturer, who knows the details of the test best, to provide one or more LOINC codes that are appropriate for the IVD test kit and instrument combination, depending on the different clinical contexts in which it can be used. - tThis was the first step in creating this reference standard collection. After industry study and scrutiny of LIVD, the next iteration is known as Laboratory Interoperable Database Repository (LIDR) - starting out, these elements should be coded using content at minimum from LOINC, SNOMED CT, and UCUM as applicable or unique identifiers, ideally the FDA Unique Device Identification System (UDI) and a means to know, if the test has been ?calibrated/harmonized? against an international standard.and UID.

[Comments by Jack Bloom and Ana Sz:

We think that we need to move away from any many-to-many mappings that will preclude the generation of interoperable data. We need to start by creating a list of unique, critical questions that need to be answered and assign a unique code for equivalent laboratory tests that will support addressing such problems. Of course, as Jack Bloom explained to Ana Sz, we need to have in place a whole support infrastructure for creating the positive and negative controls, and the low and high standards to that are needed to support the calibration of equivalent lab tests. In summary, we need to have in place the reagents needed to centrally calibrate many critical laboratory test results for equivalent tests across laboratories and platforms. This should be driving how we code laboratory test results. ]

LIDR will be the authoritative source to provide a means to easily and accurately find, automated, where possible, the terminology and identification elements to ensure tests result data for their tests kits and IVD instrument platforms can be reported in an interoperable fashion. The Laboratory Interoperable Database Repository (LIDR) will provide a means for the laboratorian to easily find the specific test they need or identify which test kits can be run on an IVD instrument platform they already own. As part of the work to understand the elements needed to achieve complete clinical interoperability, we need to define our data foundation, i.e., identify the data elements that are needed, document their definitions, associated coding systems and other conventions and identify if these elements will need to be included in the data exchanges between different systems or if they are mostly needed as supporting elements in the LIDR. Clinical interoperability is needed for the interpretation of individual test results that are temporally related but most likely derived from different source systems. Only results from equivalent assays can be safely trended.

For tests to be equivalent and interchangeable, the following conditions must be met:

1. Same test (defined as same analyte/observable performed on the same specimen type)

2. Same Instrument Platform

3. Same Test Kit

OR

1. Same Test

2. The IVD manufacturer has calibrated their assay to an internationally certified and standardized material in order to harmonize their results with those of other IVD manufacturers. Only assays that have undergone this harmonization process can be considered equivalent regardless of platform and/or test kit. [From ASz: Need to catalogue the assays that have been centrally harmonized and the ones that have not been catalogued (identify all these categories in a central repository - do not leave any out]

For clinical interoperability to be achieved, the information for equivalence determination must be readily available at the time of mapping the external result into the native EHRs. The following coded data elements would be displayed in the mapping module as an EHR functionality requirement and are thus required elements in the LIVD file.

§  These are elements that need to be included in the data exchange for every test (code system proposed for use in US) - at this level the appropriate combination of codes to use for these elements is a 1:1 mapping for the perfromed test - the performing lab determines which of the prescriptive enumerations (e.g. which LIDR entry) is used.

o   IVD Test Performed Identifier including the Test Analyte/Observable (LOINC)

o   Specimen information

·       Specimen Type (SNOMED CT) at minimum

·       Specimen Source Site (SNOMED CT)

·       Specimen source site topography (SNOMED CT))

·       Specimen collection method (SNOMED CT)

·       Specimen addititves (SNOMED CT)

o   Testkit Identification (Unique Identification for the test kit = could be UDI for FDA approved tests or another unique identification system for other type of tests like EUA and LDTs) – this should be included in the package insert to allow for a guaranteed match between the test being set up in the lab and the entry in LIDR - for commercially available tests (not LDTs).

o   Equipment Identification (Unique Identification for the instrument; this should be UDI, when available)

o   Harmonization/Calibration Indicator (identifies those assays that have undergone successful manufacturer harmonization with calibration to an internationally certified and standardized material[RW1])

o  Results (describing all allowable results)

·       Quantitative Results need to include units of measure (UCUM chosen by the performing lab)

·       Qualitative Result value set (SNOMED CT chosen by the performing lab)

§  These are elements that need to be included as codified metadata to support the mapping and search functionality in LIDR and should be available for secondary data use and aggregation; some of these data elements may also be available in FDA’s GUDID ( ) and we should establish which could be looked up there vs in LIDR.:

o   Method (SNOMED CT)

o   Manufacturer name – in order to support searching

o   Model name – in order to support searching

o Vendor Analyte Name = Test name

1. provide prescriptive enumeration of LOINC terms for any particular test/device combination

• Do we also need a test category simple enough for group searches?

o Analyte name in detail with the proper definition granular enough to assign the correct LOINC (this is often described in more detail in the package insert, e.g. target regions for PCR probes) [From ASz: Lets categorize the information in the package inserts and bring the information into the centralized repository]

o   all allowable Specimen Types (SNOMED CT)

1. provide prescriptive enumeration of SNOMED CT terms for any particular test/device combination

o  Results

·       Quantitative Results need to include units of measure (UCUM)

1. provide prescriptive enumeration of UCIM expressions for any particular test/device combination

·       Qualitative Result value set (SNOMED CT) of all allowable results applicable for the type of method used (or an indicator that free text is allowed)

1. provide prescriptive enumeration of SNOMED CT terms for any particular test/device combination

o   reference interval

o   limit of quantification and other metadata to enable interpretation.

Implementation Considerations

·       Only external tests that share the exact same attributes should be fully mapped and allowed to trend with the corresponding local test results.

·       As additional elements are identified a data model expansion process will be established for the LIVD file format and the LIDR.

Goals and Objectives

In support of laboratory interoperability, the LIVD file and LIDR specifically address the following:

·       Provide a standardized format for IVD manufacturers to share the above defined data elements

·       Provide a process to have the IVD manufacturer provided mappings reviewed for accuracy

·       Publish the IVD related data elements centrally in LIDR and make them available to all laboratories for system access as well as manual search.

In addition, SHIELD must identify and, if needed refine, the protocols to transmit this information between the different stakeholders and actors in the healthcare environment as follows, based on existing specifications:

·       For IVD vendor to LIS = IHE LAW = CLSI Auto16 (international)

·       For EHR-s to LIS for orders = LOI (US realm)

·       For LIS to EHR-s for results = LRI (US realm) or IHE XD Lab (Europe and other countries – this part may not be needed in SHIELD)

We want to build this system in a way that it can grow over time (feedback loop)

Actions

Expand LIVD file format:

o   To support[PG2]  value sets for specimen types, units of measure and codification of method

·       May require clarification for use of SNOMED CT content outside member countries (is not an issue in the US, but IVD manufacturers operate worldwide, so need to ensure that either all codes used are in the Global Patient Setummary (GPS) set or get specific agreement with SNOMED International

·       Will first require work with IICC to update the underlying specification and then with HL7 OO WG, where the project already exists, but for these additions we will need to participate in 2 connectathons and go through a new STU ballot. [From ASz: instead of balloting why we do not do the testing using real data from several labs and instruments?]

·       Timeframe 6 – 12 months

·       Budget: in kind contribution of SHIELD participants - one or two cycles of updates

o   To support proper [PG3] assignment of unique test kit and instrument platform identifiers, which ideally should always be the device identifier in the UDI string included in the barcode

·       Require request for UDI submission as part of the FDA review (or include as assigned identifier with every approved IVD test kit or platform)

·       Requires work with FDA and the GUDID publishers

·       Timeframe ???@Greg Pappas???

·       Update the USCDI to include ALL elements listed in the LIVD file

·       Requires work with ONC

·       Timeframe 6 months???@Micky Tripathi???

·       Budget: Government activity - not sure!

o   Create LIDR

·       Document the requirements for the repository (see: )

·       Identify the governance structure for changes to the LIVD file / LIDR / review process and associated tooling

·       Members need to have practical expertise in tooling, terminology and Laboratory (include professional organizations, SDO representatives, tooling) and need to represent SHIELD leadership

·       Identify the hosting site (this will need long term funding support) – this should be open and free access – propose NLM

·       Identify the review team (this will need long term funding support)

·       Agree on the submission, review and publication process

·       Identify what would be the minimal viable product for the first step and create an improvement plan over time

·       Timeframe 3 – 6 month till MVP

·       Timeframe overall: indefinitely!

·       Budget: Needs higher initial development funds and long term commitment for the hosting site as well as the review committee (Clinical Architecture will provide a rough number)

o   Develop a plan to incrementally grow LIDR:

·       Develop the list of high volume CRITICAL tests with high impact on patient safety, if not properly identified when merged in flowsheets

Note: Consider labs that are commonly used in NDS submissions: Labs to identify liver toxicity and CBC·      

Look at list from participating organizations for high volume tests

·       Get input from CAP and AACC

·       Identify the IVD manufacturers that produce tests / instruments for the tests on the list

·       Use IICC for outreach

·       Timeframe 9-12 mo

·       Budget: in kind contributions from SHIELD participants - one time expense

o   Confirm existing systems are able to receive, store, and forward this information, so work with vendors of these systems and promote adoption of the above identified standards:

·       IVD Instruments (IHE LAW)

·       Laboratory systems (IHE LAW and LOI and LRI)

·       Healthcare systems (LOI and LRI)

·       Data repositories like the IVD data hub (new standards for secondary data use – propose SMART-on-FHIR apps / medMORPH and other specifications currently in development

·       Timeframe 9-12 mo

·       Budget: Suggest creation of a survey and distributions via professional organizations (maybe CAP can include in their vendor surveys?) / IICC - one time event - hopefully in kind by participating SHIELD participants

o   Support for Terminology Tooling (model of meaning) - this is really for the tooling committee to flesh out!

·       Terminology tooling to co-mingle and publish the unified LOINC, SNOMED and RxNorm terminology which will be developed for ongoing maintenance and distribution of the unified controlled medical terminology to support primary and secondary uses of encoded laboratory, and other, health data (This could be the VA developed SOLOR, or University of Nebraska developed controlled medical terminology). There would be coordination and licensing management of LOINC, SNOMED and RxNorm in a unified format such that licensing terms for each individual terminology are maintained while realizing the needed benefits for a unified distribution of these controlled medical terminologies. Tooling will further enable rapid authoring of new terms and logical organization of terms to support new IVDs and/or test kits that come to market.

o   Describe the ROI to all affected stakeholders to get buy-in without having to rely on regulatory guidance

·       Timeframe 3 - 6 mo

·       Budget: one time - should be able to abstract from the strategic plan, then just need a communication plan - hopefully in kind by participating SHIELD participants

Key Performance Indicators

For the LIVD file specifically:

• [Internal Impact Level] Number of Entries in LIDR file with completed elements [Count] / IVDs

  • % completed with LOINC, SNOMED, UDI

    • Feedback -> Y

    • Number (or %) of mappings in LIVD file deemed correct by expert review

      • Feedback -> Y

• [External Impact Level] Number of IVD manufacturers that provide test mappings in the LIDR. use LIVD file (this could be done as survey until we have the repository built - after that this could just be based on the submitters to the repository) - if we want a percentage of all IVD manufacturers would need to decide what to use as denominator (maybe all IVD manufacturers that have submitted IVD for FDA approval?)

  • Of those IVD manufacturers the percentage of test kit/instrument combinations that have been mapped in LIVD file format [From ASz: add version control, and as date]

    • to provide LOINC mappings for their tests (and orders) [add version control, and as date]

    • to provide SNOMED CT mappings for their qualitative results [add version control, and as date]

    • to provide SNOMED CT mappings for their specimen terms [add version control, and as date]

• [External Impact Level] Quality of LOINC coding by IVD manufacturers

  • number of times the review during submission resulted in a revision of mapping by the IVD manufacturer (this is only possible if we have a review process - as part of the requirements, we did indicate that we need a flag showing if content has been reviewed before publication (unless we decide we don’t publish ANY unreviewed content - this is dependent on funding for the review team))

• [External Impact Level] Number of IVD manufacturers that have UDI for their test kits and instruments (could be a survey or review of GUDID)

  • Of those that have UDIs – percentage of instruments and test kits that have UDI (could be a survey or review of GUDID)

  • OR percentage of the mapped test in LIDR that include a UDI (regardless of manufacturer)

• [External Impact Level] Number of software vendors (LIS and EHR-s, Public Health Surveillance systems, HIEs)) that incorporate the ability to receive, store and send LIDR data elements

• [External Impact Level] Number of laboratories that request access to the LIDR and use LIVD file content to build their catalogs (could use survey or once we have repository track access to and use of content)

  • Of those that use it,

    • percentage of tests that are in the catalog for each file

    • components in LIVD file used for catalog creation / test set up in LIS (this can be used in the feedback loop for improvement of LIVD content)

    • track as baseline and then repeated over time the LOE for creation of a NEW test set up in the catalog / LIS (now and after LIVD file use)

    • satisfaction with

      • the tooling to access content

      • the content of the LIVD file

    • Request feedback on (part of feedback loop)

      • missing content

      • desired other functionality of tooling

      • next priority domain to add to the repository (part of feedback loop)

• [Mission Impact Level] Percentage of labs that have been mapped (this could be done via audit of labs - for example CAP, or by auditing the IVD data hub content) - this assumes that all labs use the same UID for each IVD (if that is not the case, we cannot get this reliably)

  • the same test to the same LOINC as in the LIVD file

  • the same result value to the same SNOMED CT concept

  • the same specimen type to the same SNOMED CT concept

• [From ASz: which organization assures that lab test results arrive to each end user undamaged?]

[i]

 [RW1]Indenting in this section may need editing.

 [PG2]Who?  I thought the current LIVD committee said this was too big for them? Who will do this?  Are we creating a group?

 [PG3]Is there a budget associated with this.  How many people are needed. What time commitment.