Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current Restore this Version View Page History

« Previous Version 5 Next »

  • 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/).

      • COMMENT:

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

        • #2 - Update definition - proposal for review: Uniquely identifies the test reagent configuration (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. For FDA cleared/approved tests, refers to the unique device identifier (UDI), created by the manufacturer and available as a barcode and human readable text on the package.

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

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

    • APHL comment on USCDI+

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

  • 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

  • OVERALL:

    • 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

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