EHRS-FM IG

ISO/HL7 10781 - Electronic Health Record System Functional Model, Release 2.1
0.14.0 - CI Build

ISO/HL7 10781 - Electronic Health Record System Functional Model, Release 2.1 - Local Development build (v0.14.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Requirements: CP.4 Manage Orders (Function)

Active as of 2024-06-01
Statement N:

Provide the ability to manage clinical orders and results including medication, non-medication, diagnostic tests, blood products, other biologics and referrals, using order sets as appropriate.

Description I:

The provision of clinical care includes the need to order from a variety of treatments using order sets as appropriate as well as reviewing the results of treatment. Orders for treatments may include medications, non-medication therapies (e.g., physical therapy, special diet, immunizations, non-allopathic regimens); diagnostic care (e.g., laboratory , radiology); blood products and other biologics (e.g., blood transfusions, human growth hormones). Patients are often referred to other health care providers for more specialized diagnostic workup, and/or treatment. An effective EHR-S must include support and management of these processes and associated documentation.

Criteria N:
CP.4#01 SHALL

The system SHALL provide the ability to manage role-based, context-based, and/or user-based order entry.

CP.4#02 SHALL

The system SHALL provide the ability to manage the creation, renewal, modification and discontinuation of orders.

CP.4#03 SHALL

The system SHALL provide the ability to render relevant, patient-specific laboratory test results when entering an order.

CP.4#04 SHALL

The system SHALL provide the ability to manage the status of an order (e.g., open, completed, in process).

CP.4#05 MAY

The system MAY provide the ability to capture, maintain and render order entry with an appropriate registration process when the identity of the patient is unknown or in an urgent situation.

CP.4#06 dependent SHOULD

The system SHOULD provide the ability to manage standing orders or orders that may be submitted by providers other than licensed providers according to scope of practice, organizational policy, and/or jurisdictional law.

CP.4#07 SHALL

The system SHALL provide the ability to capture and render problem/diagnosis as an element of an order.

CP.4#08 MAY

The system MAY provide the ability to capture, maintain and render, as discrete data, a diagnosis/problem code, and/or description associated with an order of any type (including prescriptions and medications ordered for administration).

CP.4#09 MAY

The system MAY provide the ability to link an order of any type (including medication order) with a related clinical problem(s), and/or diagnosis code(s) and description.

CP.4#10 SHALL

The system SHALL provide the ability to annotate and render comments and instructions with an order.

CP.4#11 SHOULD

The system SHOULD provide the ability to annotate and render free text comments and instructions with an order (e.g., "Short draw, do CBC first").

CP.4#12 SHOULD

The system SHOULD provide the ability to tag frequently used and institutionally-approved order sets as "favorites" or "preferences" to facilitate retrieval and ordering.

CP.4#13 MAY

The system MAY provide the ability to manage orders submitted to or received from external organizations, and/or facilities such as Health Information Exchanges (HIEs) or regional Electronic Health Record Systems (EHR-Ss).

CP.4#14 dependent SHALL

The system SHALL render patient identifying information (e.g., the patient name, identification number, and age or date of birth) on all order screens, according to scope of practice, organizational policy, and/or jurisdictional law.

CP.4#15 SHALL

The system SHALL provide the ability to capture, maintain and render an indicator of oral verification ("read-back") of the complete order by the person receiving the telephone or verbal order.

CP.4#16 SHALL

The system SHALL provide the ability to capture and render the urgency status (e.g., As-Soon-As-Possible or STAT) associated with an order.

CP.4#17 SHOULD

The system SHOULD provide the ability to render order history for any order, including the ordering clinician, order details, date, and time.

CP.4#18 SHOULD

The system SHOULD provide the ability to tag and render a field as required for a complete order by order type (e.g., pediatric order for antibiotic that requires the patient's weight).

CP.4#19 SHOULD

The system SHOULD provide the ability to tag orders to be activated at a future date and time including admission orders, discharge orders, and post-operative orders.

CP.4#20 MAY

The system MAY provide the ability to manage conditional orders that can be activated when certain criteria and conditions are met.

CP.4#21 SHALL

The system SHALL provide the ability to capture, store and render the identity of all providers who signed an order including their name and credential identifier.

CP.4#22 SHOULD

The system SHOULD provide the ability to render a list of active orders for a patient.

CP.4#23 SHOULD

The system SHOULD provide the ability to render a list of orders by similar or comparable type (e.g., all radiology or all laboratory orders).

CP.4#24 SHOULD

The system SHOULD provide the ability to render outstanding orders for multiple patients, as opposed to outstanding orders for a single patient (e.g., all outstanding orders for a specific clinician or all outstanding orders for a care setting).

CP.4#25 SHOULD

The system SHOULD provide the ability to capture and transmit the provider's order cancellation request.

CP.4#26 SHOULD

The system SHOULD conform to function [[CPS.8.4]] (Support for Communication between Provider and Patient, and/or the Patient Representative) to manage information regarding orders.

CP.4#27 dependent SHALL

The system SHALL provide the ability to determine and capture co-signatures for orders based upon roles (e.g., consulting physician) according to scope of practice, organizational policy, and/or jurisdictional law.