Procedure Order

Provider-authored request for the delivery of patient care services.

Data Element

Procedure Order

Description

Provider-authored request for the performance of a diagnostic or therapeutic intervention.

Submitted By: Joel Andress / Centers for Medicare and Medicaid Services (CMS) Center for Clinical Standards and Quality (CCSQ)
Data Element Information
Rationale for Separate Consideration	USCDIv1 includes medical services that are complete (procedures, labs) and Plan of Treatment, but not orders for services. Services not provided by the same organization where ordered requires a transfer of a patient with the relevant order information.
Use Case Description(s)
Use Case Description	Orders (service requests) are used extensively by hospitals, clinicians and providers as part of the quality measurement. They are important for quality improvement, clinical decision support and measurement to understand the link between things ordered and then completed/administered. These data are necessary to confirm appropriate and high quality of care is received for patients across different populations. It is clinically relevant from a care perspective and a quality measurement perspective to distinguish information about services orders, and those completed. Currently, CMS quality measures include the following order concepts. Orders for: • Labs and diagnostic studies • Interventions (i.e. hospice, comfort care, palliative care) and procedures • Devices • Follow-ups/referrals
Estimate the breadth of applicability of the use case(s) for this data element	More than 4,00 hospitals and 1 million providers currently capture, access and exchange this order (service request) information. This information is currently electronically submitted by providers and hospitals to CMS for quality measurement. eCQI resource center, includes measure specifications for CMS program eCQMs (i.e. CMS 125, CMS 71, CMS 645): https://ecqi.healthit.gov/ecqms
Link to use case project page	https://ecqi.healthit.gov/ecqms
Use Case Description	Each step in the chain of events between a clinician’s request for a service (order) and the completion of that service is critical for vigilance and surveillance of patient safety and appropriate care. It is important to have the capacity to evaluate the clinician’s intent, the actual completion across care settings and across time. Specifically, this concept allows for transfer of information of the order to be completed, if the service is not being provided by the same organization.
Estimate the breadth of applicability of the use case(s) for this data element	All healthcare providers, laboratories, hospitals using EHR systems should have order information documented and accessible.
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)	Orders reference services available in standardized terminology: Intervention order (Comfort measures): SNOMEDCT Device order: SNOMEDCT Diagnostic study, laboratory test order: LOINC Encounter/follow-up order: SNOMEDCT https://vsac.nlm.nih.gov/valueset/expansions?pr=ecqm
Additional Specifications	HL7 FHIR QI Core Implementation Guide STU4 based on FHIR R4, Service Request: http://hl7.org/fhir/us/qicore/StructureDefinition-qicore-servicerequest.html CMS Quality Data Model (QDM) version 5.5 Guidance, orders (https://ecqi.healthit.gov/sites/default/files/QDM-v5.5-Guidance-Update-May-2020-508.pdf) US CORE Implementation Guide: Service Request noted as a future potential profile: https://www.hl7.org/fhir/us/core/future-of-us-core.html
Current Use	Extensively used in production environments
Supporting Artifacts	Orders (service requests) are routinely captured in EHR systems used by hospitals and providers for the use in CMS quality reporting eCQMs across programs including IQR, QPP, and Promoting Interoperability programs. CMS requires the submission of order (service request) related data for quality measurement for eligible hospitals/CAHs and clinicians using ONC Certified Health Electronic Record Technology (CEHRT)—this includes order (service requests) for a procedure, diagnostic service, intervention, laboratory test, or other planned service for a patient. https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/MMS/Quality-Programs https://ecqi.healthit.gov/ecqms https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/MMS/Quality-Programs
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.
Supporting Artifacts	Orders (service requests) data for quality measurement is electronically exchanged from organization’s EHR systems to CMS for reporting and payment quality measurement programs, via QRDA files and other architectures. These orders (service requests data elements have been tested for reliability and validity of capture during the development of CMS eCQMs and can be feasibly exchanged. Ongoing testing for exchanging these data in FHIR standards via HL7 Connectathons. https://ecqi.healthit.gov/qrda https://confluence.hl7.org/display/FHIR/2020-09+Clinical+Reasoning https://ecqi.healthit.gov/qrda
Potential Challenges
Restrictions on Standardization (e.g. proprietary code)	No challenges anticipated. This data is available in standard terminology that can be publicly access via the VSAC and HL7.
Restrictions on Use (e.g. licensing, user fees)	We are not aware of any restrictions.
Privacy and Security Concerns	This data, like any patient data should be exchanged securely. Current processes exist, governed by CMS and ONC, to securely transfer this data element.
Estimate of Overall Burden	Orders (Service requests) are regularly captured by a broad range of healthcare providers, and should not cause burden to implement. Some burden required to include a ServiceRequest profile as a US Core profile, though it is already noted as a potential addition for future iterations, and built out in QI Core.
Other Implementation Challenges	N/A

ASTP 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.

Orders

Data Element

Comment