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

Data Element

Applicable Vocabulary Standard(s)

Orders

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

Examples include but are not limited to diagnostic imaging, laboratory tests, interventions, referrals and consultations, and do-not-resuscitate.

Comment

PACIO Project Support to Include Orders Data Class

  • Data Class: Orders (Level 2) 

  • Data Element: Orders for End of Life Care (Level 2) 

  • Recommendation: Include the “Orders” data class and “Orders for End of Life Care” as a data element under that class in USCDI V4. 

  • Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO Community believes the data elements Care Experience Preferences, Treatment Preferences, End of Life Orders and Durable Medical Power of Attorney included together provide the most essential information to give a holistic view of the individual’s wishes, necessary to inform care. The PACIO Community appreciates that the Care Experience Preference, Advance Directive Observation, and Treatment Intervention Preferences data elements are planned for the Goal data class in V4, but to maximize the clinical utility this information we recommend also advancing Orders for End of Life Care as data element in V4. As stated previously, we understand expanding these concepts beyond advance healthcare decision documents to a more broad utilization than our use case which we have no objection to. 

Support for orders and request for data model clarity

We support the USCDI TF and HITAC recommendations to prioritize medical orders for life sustaining treatment (POLST/MOLST) and End of Life Care Orders as noted by CMS-CCSQ. We also concur with Lisa Nelson's sentiment that additional thought should be given to the data model structure for representing orders more generally.

CMS-CCSQ Support for Orders in USCDI v3

CMS-CCSQ  continues to support inclusion of the broader Orders data class to capture and exchange all orders for medical services (service requests). This information confirms appropriate and high-quality care is provided in quality measurement, is relevant information required to support a referral or a transfer of care request from one practitioner or organization to another, and is used for prior authorization activities.

 

CMS-CCSQ also recommends inclusion of an End of Life Care Orders data element defined as orders for hospice, palliative care, and comfort care.

Rationale:  End of life care orders are especially critical for care coordination and care decision making. This concept may be used to share relevant information required to support a transfer of care request from one practitioner or organization to another that provides end of life care services, which often happen at different organizations. Interoperability of these orders would also allow orders to move more easily between organizations, facilitating patient choice.

Maturity:

  • Current standards:
    • Orders can be exchanged in mature FHIR standards, including Service Request profile included in QI Core.
    • End of Life Care concepts are captured in mature terminology: LOINC, SNOMED
  • Current uses, exchange, and use cases: Orders (service requests) for end-of-life care services are routinely captured in EHR systems used by hospitals and providers and are used 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 orders (service requests) for an intervention (i.e., palliative care, hospice, comfort care).

Do you intend the USCDI to support a multiaxial heirarchy?

If you make Orders a Data Class, then you need to decide if you will allow notions to be categorized in more than one place or not.  For example, orders for laboratory, pathology, and diagnostic imaging tests, should those data elements be covered in those respective data classes, or should those data elements be shown within the Orders data class?  Or should they show in both places?

Log in or register to post comments