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

Data Element
Specimen Collection Method
Description

This is the collection method of the specimen sent for laboratory testing.
Submitted By: Sanjeev Tandon on behalf of CDC / CDC
Data Element Information
Rationale for Separate Consideration This may seem to be represented by the “Procedures” element. The specimen collection method differs from a procedure as it is not considered a procedure in the clinical workflow.
Use Case Description(s)
Use Case Description Specimen collection method is created at the provider side when a specimen is collected for laboratory testing. It may be captured in some EHRs during test order creation. It is exchanged with the laboratory as part of the order message. A proper test interpretation cannot be given for some test types without knowing the specimen collection method. Laboratories are required to receive this for certain tests as per CLIA requirement §493.1291(c)(5).
Estimate the breadth of applicability of the use case(s) for this data element This use case applies to some types of testing that would impact all the laboratory professionals conducting and interpreting applicable laboratory tests. It impacts patient care and providers using those test interpretations to make decisions. These providers include all the doctors, nurses, and other medical professionals who order laboratory tests.
ONC Priority
  • None of the above
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) SNOMED CT®
https://browser.ihtsdotools.org/?perspective=full&conceptId1=17636008&edition=MAIN/2023-09-01&release=&languages=en
Additional Specifications This data element RE in LOI, LRI, ELR and FHIR R5.
LOI - http://www.hl7.org/implement/standards/product_brief.cfm?product_id=152
LRI - http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279
FHIR R5 - https://hl7.org/fhir/specimen-definitions.html#Specimen.collection.method
Current Use (Level 2) Captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer
Extent of exchange (Level 2) Between more than two production EHRs or other HIT modules using available interoperability standards
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 This element is generated at the bedside and captured/ should be captured by the EHR. There are no calculations applicable. It should be communicated with the lab test order and will be used by the laboratory professional running and interpreting the test. Attempts to collect it do not impact the clinical workflow.
Other Implementation Challenges A development burden is expected.
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 0 - Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.
Evaluation Comment This data element is a specialized use or subset of the existing data element Procedure in the Procedures data class.

Comment

Submitted by BLampkins_CSTE on

CSTE Comment - v5

CSTE supports collection of more granular laboratory data to support case adjudication and reporting as well as patient deduplication and linking of data from cases to ELR, which can be critical. The variables we recommend be added to USCDI v5 include:


Name of testing/performing laboratory and associated identifiers (CLIA)(HIGH PRIORITY)
Name of ordering provider and submitter
Address of testing/performing laboratory 
Accession number at testing laboratory (HIGH PRIORITY for matching purposes)
Date the test was ordered
Date the test was performed (needs to be reconciled with results date/timestamp)
Specimen collection date and time (HIGH PRIORITY) (Needs to be reconciled with Test Date=Clinically relevant time)
Test result value (needs to be reconciled with values/results in USCDI V1 and V2), units, reference range and interpretation (HIGH PRIORITY)
Abnormal flag (HIGH PRIORITY)
Test kit identifier

Dates and times are critical to evaluating the timeliness of reporting - it is a major indicator for the performance of public health surveillance systems and without this information it is unknown how data exchange is impacting the ability for public health to respond in a timely fashion. Although the date and time data are generated by the system, in practice it has been observed that availability of this data to Public Health Departments is sparse for use in timeliness analysis
 

Submitted by nedragarrett_CDC on

CDC's comment for USCDI Draft v5

CDC supports the inclusion of this data element in USCDI v5 as it is an element that may be necessary for calculation of our digital quality metrics from FHIR data. Specimen collection method is also used in laboratory surveillance to identify results from specific collection methods.

Log in or register to post comments