SHIELD Feedback on USCDI V5 Draft

• Test Kit Unique Device Identifier

  • Current definitions

    • in USCDI: Numeric or alphanumeric code representing a collection of materials necessary to perform diagnostic tests with Applicable Vocabulary Standard(s) = FDA Unique Device Identification System (UDI System)

    • in USCDI+: Uniquely identifies the type of test (at minimum by using test name and manufacturer (similar to the make and model of a car)) that was used to obtain the Test Result Value. It is a device identifier and should be referenced using Device Identifiers (DI), when available. The DI is contained within the unique device identifier (UDI), created by manufacturer (Manufacturer requests UDI issuance, then provides DI, or can be pulled from GUDID database (https://accessgudid.nlm.nih.gov/).

    • Applicable Vocabulary for test kits that have no UDI - for those that are not FDA approved for example

    • COMMENT:

      • #1 - Definitions between USCDI and USCDI+ MUST be the same for this data element for the same use case

      • #2 - Update definition: Uniquely identifies the test reagent configuration that was used to obtain the Test Result Value. For FDA cleared/approved tests, a unique device identifier (UDI) should be available. At a minimum test name and manufacturer can be used to identify this element. Also acceptable is the Device Identifier (DI), which is contained within the unique device identifier (UDI) and can be retrieved from GUDID database (https://accessgudid.nlm.nih.gov/). Optimally the full UDI should be used, when available (can be formated as a barcode and/or human readable text).

    • Specific Feedback requested In the ONC Standards Bulletin (https://www.healthit.gov/sites/default/files/page/2024-01/Standards_Bulletin_2024-1.pdf) = ONC seeks feedback on the new Test Kit Unique Device Identifier data element that would be added to the Laboratory data class, including in what scenarios this data element would be useful and what experience health IT developers have exchanging this element.":

      • would need to also define requirements for storage in the LIS

      • when the test kit identifier is added to the results - options are:

        • provided it via IVD instrument interface as described in IHE LAW = CLSI AUTO-16

        • scan a barcode on the test kit package (data labels that are standardized and systemized reduce the burden of entering and risk of introducing transcription errors when doing this manually) - this is agnostic to where the scanning happens (can be at LIS or middleware or IVD instrument)

        • assigned to the test in the LIS set up (this would only be at the level of DI) and has a risk of becoming outdated, if not properly maintained

      • use cases based on what type of testing is performed - may be hard to request for manual tests, that are not IVD generated (some cultures, microscopy, anatomic pathology would fall into that category)

      • DI can be published in LIVD, looked up in the GUDID database (https://accessgudid.nlm.nih.gov/) or read on the package insert

    • LDTs are out of scope for SHIELD, so we didn’t explicitly consider it, but overall that area needs to be examined for impacts

• Instrument Unique Identifier

  • Suggest to elevate this element into V5 as it supports the use of Test Kit Identifier

  • Using the same applicable vocabulary as for Test Kit Identifier, i.e. at minimum instrument name and manufacturer, DI of UDI, full UDI

• Consider overall comment - WAS NOT DISCUSSED, so not included

  • Need to create a better model of relationships between the USCDI data element to help implementers understand the dependencies and cntext each of them provide for the use case they are implementing:

    • examples

      • Need for LOINC for patient generated wearables (continuous glucose monitor) that represent produce result values and need to be identified using the instrument identifier

      • units of measrue with result values for quant result

      • specimen type and source site

BACKGROUND INFO

• APHL comment on USCDI+ for Test Kit Unique Identifier:

  • Data Rationale portant to PHA and where currently available): For the clinical use case it is important to support result trending when obtained from different laboratories. For PH this is important to understand test performance, especially for EUA or new methods. For regulatory use case this can suport post-market surveillance and enhance migration of EUA to 510K applications as well as provide support for real world data use for research in general.
    This data element will require some implementation planning in order to get to the expected full FDA defined UDI and its elements. While each laboratory tracks the tests they perform, documenting the UDI is not currently done in the LIS and creating a way to make that easiest for laboratories must be part of the plan.

  • Element specific Mapping, rather than just naming the resource:
    V2: OBX-17 or OBX-18 or PRT-10 or PRT-22
    FHIR: observation.device
    CDA:

Other thoughts - not for submission:

• In V5:

  • Specimen Condition Acceptability

    • Request to rename it to specimen condition - see discussion in US Core here: https://jira.hl7.org/browse/FHIR-43567. The term specimen condition acceptability should not be considered a characteristic of the specimen, rather of the test/observation that could not be performed due to the condition of the specimen. A specimen may be in a condition that could be acceptable for one test, but not another. In interoperability standards there are at least two fields: one on the specimen to reflect the actual condition of the specimen, and another would be one of multiple reasons why the test could not be performed and/or if results must be considered in context of a sub-optimum condition of the specimen.

    • Update description to match description for specimen Condition in https://jira.hl7.org/browse/FHIR-43567.

    • Element specific Mapping, rather than just naming the resource:
      V2: SPM-24
      FHIR: Specimen.condition
      CDA:

    • Lab Applicable Vocab Std: hl7VS-specimenCondition - HL7 Terminology (THO) v5.4.0 - could also create a value set from SNOMED CT - propose HL7 OO create this value set

    • Corresponds to CLIA element in §493.1291(c)(7) in CLIA 42 CFR 493.1291 - Test Report (42 CFR Part 493 -- Laboratory Requirements

    • Tests

      • Relabeling to represent the “Laboratory Performed Test Code”

        • This change is needed to avoid confusion with result values, but also to clarify that this element represented the coded representation

        • Update definition to: The coded representation of the analysis of specimens derived from humans, which provide information for the diagnosis, prevention, treatment of disease, or assessment of health.

        • Associated Vocabulary should be more constrained than just LOINC - suggest LOINC from Lab class, 'obs only' or 'both')

        • Data Rationale (why important to PHA and where currently available): Categorically describes the test that was performed, which isused for automatic routing to the responsible program at the PHA and when stored in the EHR is the underpinning for use of RCTC to trigger eCR for reportable conditions; created in LIS/LIMS, stored in EHR as required by certification

        • Element specific Mapping, rather than just naming the resource:
          V2: OBX-3
          FHIR: observation.code.coding - is mandatory in US Core Laboratory Result Observation Profile - US Core Implementation Guide v7.0.0
          CDA: observation.code

        • Coded representation of CLIA element in §493.1291(c)(4) in CLIA 42 CFR 493.1291 - Test Report (42 CFR Part 493 -- Laboratory Requirements

      • It is important to capture both the coded representation of the test that was performed as well as the name - might be good to add a new element “Performed Test Name”

    • Values/Results

      • Relabeling Values/Results to Result Values

      • Update the description: Recorded value or findings of the analytical test performed on a specimen.
        Note that the scale of the test influences the format of this data element:

        • For quantitative tests the format is numeric or structured numeric (to support ranges, titers etc) and often must be interpreted in conjunction with the element Result Unit of Measure

        • For qualitative tests the format is coded for ordinal or nominal scale, and text (short or formatted) for narrative scale.

        • Further classify the categories of result values - vocabulary binding is only valid for qualitative result types - depending on the scale the binding shifts. The binding should be more prescriptive based on scale of test:

          • For nominal scale often SCT in organism hierarchy, example value set: PHIN VADS

          • For ordinal scale use SCT from qualifier hierarchy: PHIN VADS

      • Element specific Mapping, rather than just naming the resource:
        V2: OBX-5
        FHIR: observation.value
        CDA: observation.value

      • Corresponds to CLIA element in §493.1291(c)(6), §493.1291(c)(7) in CLIA 42 CFR 493.1291 - Test Report (42 CFR Part 493 -- Laboratory Requirements

    • Specimen Identifier

      • Description: Alphanumeric value to uniquely identify an indivudal specimen (at minimum, within one organization, which MUST be identified by including the assigning authority for the identifier). This SHOULD also have an attribute called “identifier type” - in this case to identify if this placer (submitter) or filler (performing lab) - could then also be used to represent the level 2 element Accession number (level 2 element)

        • want to make comment that ALL identifiers MUST have assigning authority to ensure global uniqueness,

      • There are at least 2 actors: the ordering facility (placer) and the performing facility (filler). At least the Filler Specimen Identifier should be captured. As for all identifiers, it should be understood, that an identifier MUST include the assigning authority to provide uniqueness across organizations.

      • Element specific Mapping, rather than just naming the resource:
        V2: SPM-2.1 for placer, SPM-2.2 for filler, SPM-31 for other organizations
        FHIR: Specimen.identifier
        CDA:

      • Data Rationale (why important to PHA and where currently available):Critical for PHA - this is the often the key identifier in a lab report

      • Corresponds to CLIA element in §493.1276 (a) in CLIA 42 CFR 493.1276 – Clinical Cytogenetics (https://www.ecfr.gov/current/title-42/section-493.1276)

• Level 2:

  • Laboratory Test/Panel Code

    • Update name of the element to “Ordered Laboratory Test / Panel Code”

    • Update the description to disambiguate if we are talking about the order or the performed test (resulted test): A code that identifies the test or group of tests (panel) being ordered for the analysis on a specimen derived from humans, which provide information for the diagnosis, prevention, treatment of disease, or assessment of health.

    • Update the Lab Applicable Vocab Std to be more specific: LOINC: Lab class (Order only or Both)

    • Element specific Mapping, rather than just naming the resource:
      V2: OBR-4
      FHIR: DiagnosticReport.code.coding and ServiceRequest.Code
      CDA: inFullfillmentOf

    • Corresponds to the coded version of CLIA element in §493.1291(c)(4) in CLIA 42 CFR 493.1291 - Test Report (42 CFR Part 493 -- Laboratory Requirements

  • Laboratory results: date and timestamps

    • Remove as it is too broad, as each use case has specific steps that require that date/time stamps are recorded and these should be clearly by having individual elements for each - for the lab data exchange use case these are the date trigger events date/times are needed:

      • Specimen Collection Date/Time

      • Specimen Received in the Lab Date/Time

      • Test Performed Date/Time

      • Report Released Date/Time - and if applicable Report Update Released Date/Time

  • Specimen collection date/time

    • Data Rationale (why important to PHA and where currently available): Critical for PH Follow up to determine the temporal context; should already be collected in EHR, if provider collected, is collected in LIS/LIMS and important for result interpretation.
      Specimen collection date/time is so natural to be required that it is not even listed in specimen collection procedures, that enumerate what data must be collected and what needs to be considered – found only one for Turkey; NCBI - WWW Error Blocked Diagnostic
      In looking at specimen reject reasons / acceptability criteria, which are published for each test in the lab’s catalog we found most test have one for time delay, which is calculated using the specimen collection date/time to the specimen received date time – here are some examples in the literature (and you can look at pretty much any lab catalog for any test, all of them list acceptability time ranges/cut offs)
      • NCBI - WWW Error Blocked Diagnostic - time delay element in their study
      • https://a1.mayomedicallaboratories.com/webjc/attachments/142/aecfe40-criteria-for-specimen-rejection.pdf - Mayo on the “general criteria” list
      • Use Section 7.2 Report Format for Specimen received date, Test performed date, Report date, Report Update Date and in section 9.2 Specimen Collection Date (I am surprised it didn’t mention collection date!) NCBI - WWW Error Blocked Diagnostic
      • Example from the mayo catalog – see SPECIMEN STABILITY INFORMATION: https://www.mayocliniclabs.com/test-catalog/overview/75759#Specimen

      Element specific Mapping, rather than just naming the resource:
      V2: depending on version SPM-17/OBR-7/OBR-8
      FHIR: specimen.collected (either DateTime or Period) and also observation.effectiveTime
      CDA:

    • Corresponds to CLIA element in 42 CFR 493.1241 (c) (6) in 42 CFR 493.1241 - Test Request (http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=1&SID=7183fd6176006cf7c40b73d2c39d399a&ty=HTML&h=L&mc=true&r=PART&n=pt42.5.493#se42.5.493_11241) and called out in CLIA: 42 CFR Part 493 Subpart K - Preanalytic Systems

  • Laboratory Test Performed Date

    • need to update definition - current definition is actually meaning the same as Specimen collection date/time - suggest: Date (and optionally time) when testing was conducted by the testing laboratory

    • Element specific Mapping, rather than just naming the resource:
      V2: OBX-19
      FHIR: HL7.FHIR.UV.EXTENSIONS\Observation AnalysisDateTime - FHIR v5.0.0
      CDA:

• NEW elements:

  • Specimen Reject Reason

  • Date of the Report

    • is in USCDI+ = https://uscdiplus.healthit.gov/uscdi?id=uscdi_record&table=x_g_sshh_uscdi_uscdi_elements&sys_id=04a7ba8a1b367d1094626318624bcbf3&view=sp

      • Definition: The date and time at which the LIS system releases the results to the provider and other recepients. This applies to any report, whether preliminary, final or corrected.

      • Data Rationale (why important to PHA and where currently available): Critical for PH to understand the temporal context between mulitple verisons, also used to understand laboratory turn around time; originated in LIS/LIMS, collected in EHR

      • Element specific Mapping, rather than just naming the resource:
        V2: OBR-22
        FHIR: DiagnosticReport.issued - is already must support in US Core DiagnosticReport Profile for Laboratory Results Reporting (https://hl7.org/fhir/us/core/StructureDefinition-us-core-diagnosticreport-lab.html)
        CDA: ClinicalDocument.effectiveTime

      • Corresponds to CLIA element in §493.1291(c)(3) in CLIA 42 CFR 493.1291 - Test Report (42 CFR Part 493 -- Laboratory Requirements

  • Observation Method

    • Description: Describes the detailed type of method used for the analysis of the specimen.
      This element can repeat.

    • Should bind vocabulary to more specific valueset based mapping: https://terminology.hl7.org/5.1.0/CodeSystem-v3-ObservationMethod.html or SNOMED CT decendants of 108252007 | Laboratory procedure

    • Data Rationale (why important to PHA and where currently available): This element is currently supported in ELR as RE (must support) element - it can provide more detail than the LOINC method and could stand in in some cases for Unique Testkit Identifier, when tests are harmonized to a standard method - supports PHA in better understanding the results received across organizations; collected in LIS/LIMS, not usually stored in EHR-s

    • Element specific Mapping, rather than just naming the resource:
      V2: OBX-17
      FHIR: observation.method
      CDA: observation.method

• Other:

  • Healthcare facility aquired infection reporting coding is pre-coordinated into the organism name compared how the lab reports (often comes out of a special module in EHR-s, which remaps the information from the format in which it comes in from the lab = which is the organism and then the tested antibiotic and their susceptibility status)

  • To support precision medicine it might be helpful to set up a central system to track adverse events for releasing patient results without provider review and other HIT related incidents / patient happiness / usablility for patients

Background:

HL7 OO WG feedback for reference, if desired: https://confluence.hl7.org/display/OO/USCDI+v5+-+OO+Draft+Feedback