• 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: https://terminology.hl7.org/5.4.0/ValueSet-v2-0493.html - 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 (http://www.ecfr.gov/cgi-bin/text-idx?SID=1248e3189da5e5f936e55315402bc38b&node=pt42.5.493&rgn=div5#se42.5.493_11291)

      • 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 http://hl7.org/fhir/us/core/StructureDefinition-us-core-observation-lab.html
            CDA: observation.code

          • Coded representation of CLIA element in §493.1291(c)(4) in CLIA 42 CFR 493.1291 - Test Report (http://www.ecfr.gov/cgi-bin/text-idx?SID=1248e3189da5e5f936e55315402bc38b&node=pt42.5.493&rgn=div5#se42.5.493_11291)

        • 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

      • 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:

  • NEW elements:

  • 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