Orders

PACIO Supports Inclusion of Nutrition Order

• Data Class: Orders (V5) 
• Data Element: Nutrition Order (New Submission) 
• Recommendation: Accept the Nutrition Order data element and include it in USCDI as a Level 2 data element. 
• 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 welcomes the submission of the Nutrition Order data element by the Academy of Nutrition and Dietetics. Nutrition Orders are a foundational component of safe patient care across post-acute and acute care settings. The information in a Nutrition Order ranges from the nutritional contents of the patient’s diet, the textures and modifications needed for a patient to safely eat that diet, to the cultural or religious needs that must be met for the patient to find the meal acceptable. Nutrition Orders are a daily tool in many different provider workflows including practitioners, dietitians, and speech language pathologists and capture information that must be exchanged between settings for safe and effective care. 
• Nutrition Order has been exchanged by a commercial EHR using a FHIR Implementation Guide that is currently in Ballot titled Personal Functioning and Engagement. 

APHL questions the usability of this class

APHL does not consider the creation of this class an improvement, as this data class combines several "data elements" for various domains like Medication, Diagnostic Imaging, Clinical Tests, Procedures and Laboratory. These data elements are better enumerated within each domain, because the data elements needed for orders may differ, and should be properly grouped to support the clinical context. The Laboratory order in particular has it's own regulation, litsting the required and must support elements = https://www.ecfr.gov/current/title-42/section-493.1241
APHL supports the inclusion of ALL data elements specifically called out in CLIA Test Request.
In addition the listed elements cannot really be considered single elements, but rather each signifies a group of elements needed to place an order in its named domain, based on the current definition. Can an USCDI data element reperesent a group of data elements?

Orders

As with SDOH and Observations, NACHC encourages ONC to create a formal data model that accounts for nested data classes with functional ones. We agree with the HL7 recommendations below;

Orders (General) - [New Data Class]

https://www.healthit.gov/isa/uscdi-data-class/orders#draft-uscdi-v5

HL7 notes that the distinction between the new Orders data class and other data classes such as Laboratory, Procedures, and Medication is unclear considering lab tests, procedures, and medications can all be ordered and a variety of the already defined data elements are relevant when ordered.  HL7 recommends that the general Orders data class include data elements relevant across all order types. Individual data classes should reference these general data elements and their respective standards while adding data elements specific to that data class when being ordered.

HL7 highlights that the addition of orders in Draft USCDI v5 improves transition of care so that the receiving provider is aware of orders put in by the sending provider. HL7 observes one important scenario to recognize and accommodate, is to ensure that orders for a patient going to a skilled nursing facility (SNF) are received in a timely manner and not lost. This is linked to critical implements and accommodations a patient could need on arrival at an SNF including medications, special diets, special bed, etc.  This could also provide avenues for a patient or caregiver to trace back to what was ordered and compare to what was delivered, as well as a way a patient can show another organization what was ordered in case during the transition of care, the order was lost (for example, an order for pain medication for a cancer patient when transitioning from acute care to post-acute care).

PACIO Comments on Duplicate Order Type

• Data Class: Orders (Draft V5)
• Data Element: Portable Medical Orders for Life-Sustaining Treatments (Level 0)
• Recommendation: Remove the Portable Medical Orders for Life-Sustaining Treatments data element under the Orders Data Class in Level 0 and do not consider this data element for inclusion for future versions of USCDI.
• 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. Conceptually, including data elements for “Portable Medical Orders” (Level 2) and “Portable Medical Orders for Life-Sustaining Treatment” (Level 0) in the USCDI is duplicative. The preferred language would be “Portable Medical Order” rather than “Orders for End-of-Life Care,” because we have found jurisdictions that utilize “Portable Medical Orders” during encounters that are NOT related to EOL care such as Behavioral Health Advanced Directives that have component Portable Medical Orders. “Portable Medical Order” would be more broadly applicable than either “Orders for End of Life Care” or “Portable Medical Orders for Life-Sustaining Treatments,” but in any case, only one data element should be included in future versions of USCDI to represent this concept.

PACIO Comments on Portable Medical Order

• Data Class: Orders (Draft V5)
• Data Element: Portable Medical Orders (Level 2)
• Recommendation: Advance and include Portable Medical Orders in the final draft of USCDI V5 and rename the element “Portable Medical Order.”
• 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.
• Conceptually, data elements for an Order and Portable Medical Order are similar but have fundamental differences that must be captured separately to ensure expert clinical care in the appropriate settings. Portable Medical Orders are setting agnostic and follow a patient between settings. They are in essence orders that are written without a known final destination when they come into effect. They do not expire when a patient is discharged from a facility, and they do not need to be rewritten by a receiving clinician to remain actionable. This differs from the concept of an Order, and we believe both should be captured as separate data elements to aid in their retrieval and use.
• The PACIO Community believes the data elements “Care Experience Preferences,” “Treatment Intervention Preferences,” “Portable Medical Order” and “Healthcare Agent” (Please see our comment about “Durable Medical Power of Attorney") included together provide the most essential information to give a holistic view of a patient's wishes and provide the tools needed for providers to take action to honor those wishes. 
• In the same way we believe Orders and Order are notionally different, we believe Portable Medical Orders could be mistakenly interpreted as a list or summary of portable medical orders. We believe the data element should be renamed “Portable Medical Order” to clarify that this element is meant to exchange the complete order and its contents, not a list or summary.
• The PACIO Community appreciates that the “Care Experience Preferences” and “Treatment Intervention Preferences” data elements have been included as data elements in USCDI V4. The PACIO community also appreciates the renaming of the Portable Medical Order data element. To maximize the clinical utility of this information we recommend also advancing “Portable Medical Order” as a data element in V5.

PACIO Comment on Order Data Element

• Data Class: Orders (Currently Draft V5)
• Data Element: Orders (Currently Draft V5)
• Recommendation: Rename the “Orders” data element to “Order,” clarify its usage, and finalize it as part of USCDI V5
• 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 applauds the addition of the Orders data element in draft V5 and recommends it be adopted in the final release of Version 5. We believe that the information conveyed could be refined by renaming the data element to “Order” - this is notionally different as it does not refer to a list of orders, but to the individual orders themselves. The value of an order is in its contents, something that would not be captured if a list or summary of orders fulfilled the requirements of the Orders data element. This critical information is needed for order reconciliation, continuity of care, transitions of care, reducing duplications of effort, and removing conflicting orders.

PACIO Comment on Orders Data Class

• Data Class: Orders (Currently Draft V5)
• Recommendation: Include the Orders Data Class in USCDI V5
• 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 applauds the inclusion of the Orders Data Class in USCDI V5. Orders are an essential component of all interventions performed regardless of provider and setting. The Orders Data Class will capture this information.

USCDI V5 Feedback

The “Orders” data element should not be expressed in the plural. Data elements should be expressed in the singular.

The “Portable Medical Orders (level 2)” data element also should be expressed in the singular (Portable Medical Order).

The Portable Medical Order (level 2) data element also should be accelerated to be included in USCDI V5 because this data element represents the type of document/form that is used to represent orders for end-of-life care that can be shared across organizations. Being a document/form is a very important aspect of this data element’s nature because this data element requires “context” to be accurately understood and used and that context is provided by it being a document.

Including the Order data element without the Portable Medical Order data element is less effective than introducing them together.  Plus, there is a lot of concern around what order information needs to be represented and exchanged.  Often times, orders are a mechanism to drive workflow within an EHR system.  Being able to focus the Order data element on order information that needs to be shared across systems or liberated to exist outside of the context of a system, would help clarify the purpose of the Order data element. This data element should focus on orders that need to be shared outside of the system where the order is created.

USCDI V5 Feedback

Again, USCDI needs to clarify the difference between a Data Element which is a “document” and a data element which is an individual more specific type of information which may be exchanged within the context of a document or as a clinical statement on its own. 

A Portable Medical Order document is a collection of provider-authored directives for the delivery of patient care services.  USCDI guidance will continue to confuse the industry (as already has been done by establishing the “clinical note” Data Element without clarifying if this Data Element represents a document which holds a collection of clinical notes expressed as narrative or structured data, or if the clinical note Data Element describes an individual narrative clinical note that would be expressed within the context of a clinical note document. 

Somewhere within the USCDI efforts, this confusion which I call the “Sheep, Sheep Problem” needs to be addressed. USCDI has a “collective noun” problem which impacts the framework in multiple areas, not just Orders and Clinical Notes. This problem should be addressed sooner rather than later. 

Orders should be addressed in their respective data classes

Orders vary in their information models and terminology bindings from data class to data class, so my recommendation is to roll up orders into their corresponding data classes rather than to treat "Orders" as its own data class. For example, a medication order (prescription) would belong under the Medicaion data class, have RxNorm as its applicable vocabulary standard for the medication, and could have further specification for route, frequency, refills, and other medication-specific order characteristics. On the other hand, a lab order would belong under the Laboatory data class, would likely have LOINC as its applicable vocabulary standard for the lab test to be performed and could have further specification for specimen source, repetitions, and other lab-specific characteristics. A diagnostic imaging order would belong under the Diagnostic Imaging data class, would likely have LOINC as its applicable vocabulary standard for the imaging test and could have further specification for priority, laterality, and other diagnostic imaging characteristics. All of these domain-specific characteristics could be fleshed out over time (while being mindful about the varying degrees of pre-coordination and post-coordination that might make sense for orders), but the point is that I think we are dealing with a heterogenous collection of orders and order details that need to be addressed separately.

The original request for "Provider-authored directive for the delivery of patient care services" included examples such as "diagnostic imaging, laboratory tests, interventions, referrals and consultations, and do-not-resuscitate" which are essentially all examples of different kinds of procedure orders. While a Procedures data class does exist, as we aim to support orders for these diverse procedures, it may be that new data classes and/or data elements need to be added in a similar manner to how the Diagnostic Imaging data class (essentially a "Diagnostic Imaging Procedure") was added to differentiate from the somewhat nonspecific Prodedures data class. For example, to support the "referrals and consultations" example, there could be a new "Referrals" data element in the Procedures data class that would have associated characteristics such as department, provider, Reason for Referral (which already exists), and other characteristics. For now, DNR/POLST/MOLST might fit best under the Procedures data class. It might warrant a new data element, perhaps "Resuscitation Orders" or something similar. The characteristics could be fleshed out and proposed for future public comment where there might be ways to describe patient preferences for chest compressions, mechanical ventilation, blood transfusion, etc.