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 |
The proposed Service Request data element overlaps with the existing data elements in the Orders data class. |
Submitted by CDC_DSMH_WG on
CDC comment on data element-
CDC recommends that ONC should for the Orders data class, include the following language in the data class’ description: "Usage note: may include information on status, intent, priority, do not perform, code, occurrence, and as-needed criteria." Rationale: The current definitions for the data elements under the Orders data class identify the types of provider-authored requests but do not clearly specify which order attributes are expected. Explicitly including this useage note in each data elements description would clarify what is being ordered, the order’s status and intent, urgency, whether it should not be performed, when it should occur, and any conditions that must be met before action. This would improve consistency with FHIR/QI-Core and support more reliable clinical and quality reporting.
FHIR path(s):
ServiceRequest.status
ServiceRequest.intent
ServiceRequest.priority
ServiceRequest.doNotPerform
ServiceRequest.code
ServiceRequest.occurrence[x]
ServiceRequest.asNeeded[x]