Data Element
CCHD Newborn Screening Interpretation
Description

The result of the screening of the preductal and postductal oxygen saturation measurements.
Submitted By: Craig Newman / Altarum
Data Element Information
Use Case Description(s)
Use Case Description Pulse Oximetry (CCHD) screening should be performed for each of the nearly 4,000,000 infants born in the United States each year. Abnormal screening pulse oximetry triggers CCHD screening. Data is shared with the local Public Health Critical Congenital Heart Defects (CCHD) program in most states and territories.
Estimate the breadth of applicability of the use case(s) for this data element CCHD programs exist in most states and attempt to collect data on all newborns in the jurisdiction
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) LOINC 73700-7 - CCHD newborn screening interpretation
LOINC Preferred Answer List LL2453-0
Additional Specifications Publish HL7 version 2 implementation guide
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=366

US Core profile resources
Current Use Extensively used in production environments
Supporting Artifacts CCHD data is collected by public health programs across the country although most data collection is currently manual or via paper. The state of Michigan is receiving electronic data from at least one hospital site.
Extent of exchange N/A
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) None
Restrictions on Use (e.g. licensing, user fees) none
Privacy and Security Concerns Parent's may opt out of testing (but this choice should still be captured and shared)
Estimate of Overall Burden This data is being collected by EHRs and/or devices today, but there is very little support for electronic exchange of the data. Vendors would need to support electronic data exchange (either as a v2 message or by exposing the Observations necessary to convey the data elements). Development would also be needed on the Public Health side to receive the data electronically or to query for it. The use of v2 messaging would require some implementation effort by the submitting hospital site as workflows which trigger sending data would need to be validated and tested. The use of FHIR API to query for data would reduce the implementation burden on hospitals but would make the Public Health workflow more complicated.
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.

Comment

Log in or register to post comments