Background (adapted from content here)

SHIELD aims to build, implement, and support a comprehensive solution that addresses clinical and semantic device interoperability of in vitro diagnostics (IVD) across the nation. This encompasses data as it flows throughout the entire laboratory data life cycle. Through the innovative harmonization of data standards such as SNOMED-CT (a U.S. government system used for the exchange of electronic clinical information) and LOINC (a database and universal standard for identifying medical laboratory observations), the FDA SHIELD program team is working to develop a platform that dramatically improves the quality and portability of laboratory data, which helps reduce patient safety risk. Laboratory data is simple to transmit, but tremendously challenging to manage and evaluate due to non-standardized encoding practices used by IVD manufacturers, laboratories, and EHR vendors nationwide. This diversity in IVD test data may have an impact on patient safety and make it more difficult to analyze lab data on a national level.

The vocabulary and data standards workgroup (VDS-wg) was slated to identify how existing standards might be leveraged to solve some of these interoperability challenges. Scope was defined as follows:

In-Scope:

• Vocabulary standards (SNOMED CT, LOINC, UCUM)

• Supporting messaging/transport standards (HL7 v2 and FHIR)

• Supporting identifier standards (device identifiers [UDI], test kit identifiers [reagent/lot], specimen container identifiers, GS1 supply chain identifiers [inventory], [blood bank] product identifiers)

• Supporting information and data models (data elements, pre vs post coordination, order level metadata [ask at order entry question responses], clinical information, procedure/method metadata [e.g. antibody, point-of-care vs routine, processing steps, etc.])

• Any and all laboratory tests utilized for clinical care or public health in the USA today except direct access testing (FDA approved and laboratory developed tests [LDTs]).

Out-of-Scope:

• Billing coding systems (CPT, HCPCS, PLA)

• Experimental and/or research-only tests.

• Non-laboratory data.

• Implementation guidance.

• Policy and regulations.

• Translation from other languages to English.

• Direct access testing (DAT) / consumer performed testing.

The workgroup looked at two use cases and gathered data during a discovery phase to establish detailed, concrete examples of challenges in the real world, documented here. These examples included the D-Dimer test and AST liver function test, described in detail in the next “use cases” section below. The role that current standards play was noted and gaps identified. Known limitations and/or areas that standards cannot address currently are enumerated at the end of this document as open issues. The workgroup decided to prioritize review of those data elements that would best serve to address laboratory result interoperability challenges. To this end, the workgroup reviewed a subset of data elements in the Hl7 laboratory result interface (LRI) specification. Recommendations for appropriate use of standards for these data elements form the basis for the recommendations of this workgroup to the steering committee.

Use Cases

Problem #1: Aspartate transferase (AST), an enzyme commonly tested to monitor liver health, requires the active form of Vitamin B6 (P-5'-P) to be fully catalyzed.

For patients with high levels of AST or Vitamin B6 deficiency, AST can be under-measured when the test method is not supplemented with P-5'-P.

Problem #2: D-Dimer interpretation (excerpt from page 11 of roadmap)

A patient underwent unnecessary laboratory testing and imaging, had effective treatment delayed, and developed a serious iatrogenic condition from unnecessary treatment due to misinterpretation of a laboratory result transferred from the electronic health record of a community hospital to a tertiary care facility. The case in more details follows.

A 45-year-old female patient was transferred from a community hospital to the intensive care unit of a tertiary care facility with symptoms of chest pain and low oxygen saturation. Prior to the transfer, imaging and laboratory studies were performed at the community hospital to rule out suspected pulmonary embolism. A chest X-ray was equivocal, but a D-dimer assay was reported as 0.583 Fibrinogen Equivalent Units (FEU) µg/mL, which was within the normal range at the site and indicated a low probability of thrombosis. When the patient was transferred, the laboratory results performed at the community hospital were imported into the EHR of the receiving facility and became available to the new clinical team.

They noted the D-dimer result as higher than their cutoff value of 0.5 FEU µg/mL without realizing that it had originated from an outside hospital using instrumentation different from their hospital laboratory. The D-dimer assays used at the two facilities produced numerically different results and had different cutoff values for predicting the likelihood of thrombosis, despite having the same LOINC® and similar units of measure. The misinterpreted D-dimer result led the clinical team to believe the patient likely had a pulmonary embolism, and she started on empiric heparin therapy. The patient underwent computed tomography (CT) pulmonary angiography to definitively diagnose pulmonary embolism. The CT scan did not show any evidence of pulmonary embolism but did show bilateral lung infiltrates consistent with pneumonia. The patient also underwent Doppler ultrasound blood flow studies of the arms and legs to rule out deep venous thrombosis. A repeat D-dimer was performed in the tertiary care facility’s laboratory and showed a value of 0.376 FEU µg/mL, below the institutional cutoff for thrombosis. Heparin therapy was discontinued, and the patient was treated for her pneumonia. Two days later, however, her platelet count dropped precipitously from 347 x 109/L at admission to 80 × 109/L. The patient was diagnosed with heparin-induced thrombocytopenia and required treatment with continuous intravenous infusion of argatroban.

Recommendations

The workgroup went through LRI specifications and identified the following elements as most relevant. The existing standard or value set used to encode each one was reviewed and recommendations for change, if any, are stipulated below.

Administrative Sex - (as opposed to sex at birth). Some states may have different requirements (O&O discussion here discusses differences in states). USCDI Gender Identify as recommended by USCDI, references SNOMED CT US Edition as follows (Representing Patient Gender Identity | Interoperability Standards Advisory (ISA) (healthit.gov)). The workgroup supports use of SCT but if a particular answer is not represented in SCT, can use the HL7 v3 code (last two bullets below).

• Gender identity. LOINC code: 76691-5

• Male. SNOMED CT U.S. Edition code 446151000124109

• Female. SNOMED CT U.S. Edition code 446141000124107

• Female-to-Male (FTM)/Transgender Male/Trans Man. SNOMED CT U.S. Edition code: 407377005

• Male-to-Female (MTF)/Transgender Female/Trans Woman. SNOMED CT U.S. Edition code: 407376001

• Identifies as non-conforming gender (SNOMED CT U.S. Edition synonyms include: Genderqueer; Identifies as neither exclusively male nor female, Non-binary gender) SNOMED CT U.S. Edition code: 446131000124102

• Additional gender category or other, please specify. HL7 Version 3 code: OTH

• Choose not to disclose. HL7 Version 3 code: ASKU
  Please note other systems do exist (Homosaurus Vocabulary Site)

Race - multiple races (unlimited) need to be supported ideally within information systems. Leading EHR vendors support this already. These lists of terms are not supported by any ontology (and there is no plan for future support at this time).

For USCDI both of these standards are required and are thus recommended by the workgroup:

• The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997

• CDC Race and Ethnicity Code Set Version 1.2 (July 2021)

Interpretation Codes - text based interpretation of a quantitative value (e.g. detected, not detected; positive / negative). Current value set: HL70078_USL. For semantic interoperability, the interpretation code should be put into OBX-8 using SNOMED CT as the vocabulary. Current practice may have this value in OBX-5 but that should be discouraged to support semantic interoperability. Some systems have limitations that are sensitive to having no value in OBX-5 (even though HL7 indicates conditional, not required). There appears to be some controversy if there is only a qualitative result (e.g. detected, not detected), whether that would go in OBX-5 vs leaving OBX-5 blank and putting the interpretation code into OBX-8. Abnormality / panic flags also fit in OBX-8 (but it can repeat). We could propose a deprecated mechanism to allow for backwards compatibility but propose the ideal future state. Could look at CLSI standards for reporting.

For reference, the top rows of HL7 table 78 list of values is below:

Observation Result Status Codes Interpretation - Final, prelim, etc OBX-11, significant overlap with Result Status, OBR-25. These are transactional and more focused on implemented configuration and not required for semantic interoperability. No data standard recommended beyond the HL7 valueset.

Value Type - Data type of the result. Recommend continue to use the HL7 valueset (table 0125)

Examples:

Encapsulated Data Formatted Text (Display) Multiplexed array Numeric array Numeric Numeric range Reference Pointer Structured Numeric String Data Time Text Data (Display) Value range Extended Address

Specimen Type - currently uses table 487 in HL7. Consensus recommendation of the WG is to use SNOMED CT Specimen Type hierarchy.

SCTID: 123038009

123038009 | Specimen (specimen) |
en Specimen (specimen)
en Specimen
en Material (structure, substance, device) removed from a source (patient, donor, physical location, product)

Specimen Reject Reason - WG consensus is to continue to use HL7 table 490. The rejection reasons represent local administrative terms that can be challenging to predict. The most common terms appear to already be listed in table 490. The value set is only 13 data rows in size and may require augmentation in certain implementations. It is unclear how an implementor might encode data in an interoperable way if the needed rejection reason is not listed. Should one more entry be added that indicates “Reason other than those listed?” (and then need a way to capture an additional comment).

Specimen Condition - WG consensus is to continue to use HL7 table 493. The specimen condition list represents terms that can be challenging to predict. The list appears to be incomplete and requires additional terms to support specimen condition interoperability more thoroughly

Relevant Clinical Information - in LOINC this falls under “preconditions” but may not be exhaustive. In the current HL7 table 916, the valueset focuses only on fasting. Other relevant clinical information such as what might be needed for a COVID test order/result would require ask at order entry questions. Given the broad definition from HL7 below, it may not be scalable to have a single HL7 category list as the value set for this. A mechanism needs to exist to convey ask-at-order-entry questions and answers (potentially pre-populated from the electronic record and then reviewed by a provider) on the interface in an interoperable manner. Once the extension is completed, LOINC preconditions will be available for use within the LOINC extension to SCT. Thus the WG consensus is that use of the full list of preconditions in SCT will be a better solution than attempting to create an exhaustive value set in table 916.

Definition from HL7: This field contains additional clinical information about the patient or specimen. This field is used to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies where a simple text string or code is sufficient. This field could use all appropriate code sets including SNOMED to message Relevant Clinical Information. If more information is needed, such as date/time of the observation, who observed it, abnormal ranges, etc., or must be provided in further structured format, e.g., structured numeric with units of measure encoded, the Observation/Result group following the OBR should be used. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. Refer to HL7 Table 0916, Relevant Clinical Information in Chapter 2C, Code Tables, for valid values.

Device Type - current HL7 references table 961, which is empty. The consensus of the WG is to use the UDI schema proposed by the FDA (UDI Basics | FDA). We defer to the LIDR or future workgroup on the extension of additional device / test kit identifiers for which different patterns of (new) data elements (for which no established standard exists) might be required.

The use of the following terminologies are defined in the LRI implementation guide v2 (release 5, May 2024) specifies coding system to be used (https://www.hl7.org/implement/standards/product_brief.cfm?product_id=279 )

LOINC (Home – LOINC)

SNOMED CT (Home | SNOMED International)

UCUM (Unified Code for Units of Measure (UCUM) at NLM (nih.gov))

LOINC - SNOMED agreement here (new agreement coming out 4q of 2024)

LOINC is slated for use in OBX-3. All non-numeric results should be coded in SCT whenever possible to support interoperability.

The workgroup recommends for all qualitative results (answers), SCT codes should be used (duplicate LOINC codes should not be used). Organisms (such as that specified in culture or molecular identification) use SCT codes. Susceptibility results to antimicrobials uses LOINC (OBX-3) for the antimicrobial name and SCT for a qualitative result (susceptible or not) or can have a numeric result (not coded).

Workgroup recommendation is to promote use of SCT codes for all qualitative answer sets and specimen related data whenever possible in support of interoperability (instead of allowing use of other schemas, such as local codes, a LOINC answer code or an HL7 table)

Excerpt for reference (as examples of options permitted that may preclude interoperability):

Code to SNOMED CT preferred; codes for Specimen Type (SPM-4) as provided in the Vendor Specimen Description column of the LOINC Mapping tab in the LIVD document. ELR allows use of both SNOMED CT codes from the specimen hierarchy (PHVS_Specimen_CDC: https://phinvads.cdc.gov/vads/ViewValueSet.action?id=1F2170E4-00A6-DF11-9BDD-0015173D1785) and HL70487 codes (PHVS_SpecimenType_HL7_2x: https://phinvads.cdc.gov/vads/ViewValueSet.action?id=E1399690-F6D4-E111-AC0B-0050568D00F8) Some labs may support the sending of source site information (SPM-8); ELR R1 uses SNOMED CT codes compiled in the HITSP body site value set (PHVS_BodySite_HITSP: https://phinvads.cdc.gov/vads/ViewValueSet.action?id=9A2D4051-3AA6-42EB-AE88-541C9094B0FB) In older versions, when using OBR-15 use HL70070 for OBR-15.1 and HL70163 for OBR-15.4. "

Specimen Type (SPM 4): "Codes from either HL70487_USL or SNOMED_CT_USL Specimen hierarchy codes may be used. It should be noted that in the future SNOMED CT Specimen hierarchy may become the only recommended value set so trading partners should consider moving in that direction. LRI_NDBS_Component Value Set Fixed to: '440500007^Blood spot specimen^SCT' "

Open Issues / Possible Follow Up Action Items / Editorial Comments

1. Aggregating laboratory data answer set responses across many customers and identifying missing SCT codes might be helpful. Dan Rutz will explore whether a two column data with LRR name + distinct result. Or even just a list of distinct results (one column of unique data).

   1. Discussion 16Jul25 on

      1. whether Cosmos may provide this information? Discussion on current/ historical non numeric lab result values. Query in Cosmos that can be used in CareEverywhere based upon statistics would be helpful with assessing outside institutional data. Very labor intensive. If two results named differently from different customers/labs are truly the same. Need to understand different naming conventions. Intelligent data merge (like virtual chart).

      2. Is licensing required to access certain pieces of data in these systems? Need to check on that. However, Cosmos may not have all the data that is in the LIS. There is work on ensuring the data is good quality. Question about any limitations in data analysis? May be in certain products.

      3. Discussion on result values. Raj to look into and connecting with Dan. Good work and getting it prioritized nationally would be good. Identify where large gaps. Reference labs may have information too. Limitations of LISs as not certified. At a high level, mapping is done external to the LIS to match to SNOMED. LIS doesn’t natively support SNOMED mapping. In other cases, custom coding may be used. Another example is creating a SPM segment, may be done outside the LIS.

2. Dan Rutz pointed out that in FHIR device type “includes concepts from SNOMED CT (Home | SNOMED International ) where concept is-a 49062001 (Device)”  https://build.fhir.org/valueset-device-type.html

3. The current effort focused on laboratory results and examined two primary use cases. Other tests and other parts of the laboratory testing workflow (such as ordering) might be a focus of future efforts.

4. There is no standard or nomenclature in place today for describing a laboratory device.

5. There is no place in information models that standardize how laboratory device information is stored and transmitted.

6. There is no standard for reporting the methodology of a test along with the test result. Sometimes a long narrative is provided but other times this information is relegated to standard operating procedures accessible only to staff in the performing laboratory.

7. Closely tied to the item above is a way to describe whether two test results are equivalent. Standards for this may obviate the need for the above.

8. There is no agreement on use, coding, or mapping of HL7 value sets to other standards.

9. Lack of standardization or even guidance on use of free text vs discrete data capture vs discrete coded data capture is not addressed.

10.   In SCT, the specimen hierarchy is suboptimal. HL7 specimen domain analysis model has been mapped to SCT with some improvements suggested.

11.   For cancer, the specimen hierarchy does not follow editorial guidelines and has not been well-maintained. Proximal primitive parenting has not been widely applied.

12.   Missing content in the relevant standards remains a challenge.

13.   Lab systems don't have to store the exchange standards, but their local values stored need to be structured so they can be mapped to the national terminology standards.  Many laboratory systems store their local data in a free-form text fields for specimen source and specimen type.

14.   EHRs today don’t make best use of standards today (e.g. using UCUM to normalize units).

15.   We are missing guidelines for “standard” implementation of standards. For example, HL7 implementation guides are not always followed, and conformance is not enforced. SCT coding may occur through pre-coordination or post-coordination with little to no guidance provided on the optimal coding approach. SCT concepts may be present across multiple hierarchies with ambiguity on appropriate hierarchy to use in which context. IHE (http://IHE.net ) may serve to help address this as it attempts to provide guidance (through use cases) on how to solve interoperability challenges through proper use of existing standards.