Analysis of clinical specimens to obtain information about the health of a patient.

Data Element
Specimen Identifier
Description

Sequence of characters assigned by a laboratory for an individual specimen.

Example includes but is not limited to accession number.

Submitted By: Riki Merrick / Association of Public Health Laboratories
Data Element Information
Use Case Description(s)
Use Case Description Often LIS are not patient centric, like EHR-s, but specimen centric, so this identifier is used as the primary key to locate all data that belongs to this specimen. To support communication between provider and lab and between lab and public health agency this identifier is very important. It must be stressed, that this identifier should be unique within the assigning authority and not reused over time (though that may still be a practice in some labs).
Estimate the breadth of applicability of the use case(s) for this data element This element should be associated with EVERY lab test and its related data elements, so will be in EHR-s, LIS, PHR, Surveillance system and disease registries.
Link to use case project page http://www.hl7.org/implement/standards/product_brief.cfm?product_id=98 LRI: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279 FHIR observation in US Core lab observation profile: https://build.fhir.org/ig/HL7/US-Core/Struct
Use Case Description This also applies to lab data exchanges between lab and providers
LRI: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279
FHIR observation in US Core lab observation profile: https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-observation-lab.html references the specimen, but it is not a must support element at this time; the FHIR specimen resource refers to this element as specimen.accessionIdentifier
Estimate the breadth of applicability of the use case(s) for this data element This element should be associated with EVERY lab test and its related data elements, so will be in EHR-s, LIS, PHR, Surveillance system and disease registries.
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) N/A
Additional Specifications N/A
Current Use This data element has been used at scale between multiple different production environments to support the majority of anticipated stakeholders
Extent of exchange 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) none
Restrictions on Use (e.g. licensing, user fees) none
Privacy and Security Concerns none
Estimate of Overall Burden should already be widely used - what may still need to be expanded is the persistence of the assigning authority with the identifier.
ONC Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 2 - Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
Criterion #3
Maturity - Current Exchange		 Level 2 - Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 2 - Use cases apply to most care settings or specialties.

Comment

Submitted by Riki Merrick on

Update definition to include assigning authority

As previously noted an identifer must include a means to identify the system or organization that created it. Best practice is to not re-use identifiers over time, so that they remian unique - at least within one organization. Updated definition: 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). Example includes but is not limited to accession number.

Submitted by Riki Merrick on

APHL supports inclusion of this data element

APHL supports inclusion of this data element as it will better support the tracking of the specimen across orgnaizaitons - in order to fully do that it woudl be helpful to add the following statement to the definition:

Sequence of characters assigned by a laboratory for an individual specimen, including a means to identify the orgnaization or system that assigned it. 

Submitted by hswmin on

THIA Comment on Laboratory: Specimen Identifier

The Texas Health Informatics Alliance (THIA) Policy and Standards Working Group supports the proposal for specimen identifiers. Some institutions already have unique identifiers, but others may not. We believe that there is value in having two methods for tracking specimens.

Submitted by nedragarrett_CDC on

CDC's Consolidated Comment for USCDI v4

  • The specimen identifier is assigned at the time of collection from the patient. This identifier is critical to track with the specimen as it is transported from one point of healthcare to another, as well as to ensure that the laboratory results from the testing and evaluation are linked to the correct specimen. This is extremely critical for specimens that are sent out to a sub-lab or parts of the specimen are sent to different sub-labs for additional testing. It is critical that the specimen ID assigned at collection travel with the specimen and all parts as it is evaluated across one or more laboratories.
  • Comments from NACCHO: NACCHO supports including the data element specimen identifier
  • Comments from CSTE: CSTE agrees with CDC's recommendation for this data element.

Submitted by Riki Merrick on

APHL Comments on ISA 2022

APHL supports inclusion of this data element in the Laboratory class of USCDI V4, because it is the main way laboratories identify related lab data records in their system. For lab reports that are de-identified, for example for public health reporting to federal agencies or for research, this identifier is often the only means to link related results on the same specimen together. It may also be used as a proxy for the patient identifier, which is a CLIA required element in systems, that do not support patient administrative functionality.

Log in or register to post comments