ISO/HL7 10781 - Electronic Health Record System Functional Model, Release 2.1
2.1.0 - CI Build
Publish Box goes here
Active as of 2024-11-23 |
Provide the functionality required to support the management of treatment administration and documentation. (Treatment defined as the administration or application of remedies to a patient for a disease or injury; medicinal or surgical management; therapy.)
Provide the functionality required to support the documentation of non-medication treatments (e.g., wound dressing change that includes use of a topical cream or sterile wash during that process) to a patient based on clinical needs and requirements and provider orders within the system. This includes presenting end users with the list of clinical treatments that are to be administered to a patient, necessary administration information, and capture all required and relevant documentation details.
CP.6.3#01 | SHALL |
The system SHALL provide the ability to render the list of treatments that are to be administered within a specified time frame and including all administration directions/instructions. |
CP.6.3#02 | SHALL |
The system SHALL conform to function [[CP.6.1]] (Medication Administration) to support the administration of medications as part of the treatment administration. |
CP.6.3#03 | SHOULD |
The system SHOULD provide the ability to render all medications associated with the treatment as given or administered (including dose and quantity of dispensed units of medication). |
CP.6.3#04 | SHOULD |
The system SHOULD provide the ability to tag the treatments that are to be administered by the patient (i.e. self-administered). |
CP.6.3#05 | SHALL |
The system SHALL provide the ability to render the information necessary to adminster the treatment (e.g., body site, time and frequency). |
CP.6.3#06 | SHALL |
The system SHALL provide the ability to capture, maintain, and render information regarding multiple body sites where treatments are scheduled to be administered. |
CP.6.3#07 | SHOULD |
The system SHOULD provide the ability to render a notification when treatments are due. |
CP.6.3#08 | dependent SHALL |
The system SHALL provide the ability to capture, maintain and render details associated with the treatment as discrete data, including: treatment; date and time of treatment; site; administering provider; observations, reactions and complications; and reason treatment not given, and/or related activity not performed;according to scope of practice, organizational policy, and/or jurisdictional law. |
CP.6.3#09 | SHOULD |
The system SHOULD provide the ability to capture, maintain and render details associated with continuous treatments (e.g., infusions, tube feedings, bladder irrigations, suction levels). |
CP.6.3#10 | dependent SHALL |
The system SHALL provide the ability to capture, maintain and render details associated with treatments (including routinely scheduled, "one-time", "on-call" and "PRN") in a manner that distinguishes them from other types of treatments according to scope of practice. |
CP.6.3#11 | SHOULD |
The system SHOULD provide the ability to capture information regarding the effectiveness of treatments when such information can be determined either at the time of administration or during the episode of care. For example, the effectiveness of certain treatments can be determined immediately (i.e., during the administration of the treatment) such as the patient's immediate response to bronchodilator therapy, the application of a tourniquet to stop bleeding, or the administation of a nitroglycerine pill under the tongue to stop a heart attack. |
CP.6.3#12 | SHOULD |
The system SHOULD provide the ability to render any clinical interventions or assessments required prior to the treatment. |
CP.6.3#13 | SHOULD |
The system SHOULD provide the ability to render any clinical interventions or assessments required subsequent to the treatment. |
CP.6.3#14 | SHALL |
The system SHALL provide the ability to capture verification of patient identity prior to administration of the treatment. |
CP.6.3#15 | SHOULD |
The system SHOULD provide the ability to capture verification of patient identity using integrated point of care devices (e.g., barcode) prior to administration of the treatment. |
CP.6.3#16 | SHOULD |
The system SHOULD provide the ability to render treatment orders that have not been administered. |
CP.6.3#17 | SHOULD |
The system SHOULD provide the ability to render treatments to be administered over a selectable date/time range. |
CP.6.3#18 | SHALL |
The system SHALL provide the ability to render the treatment administration history including administering provider date and time. |
CP.6.3#19 | SHALL |
The system SHALL provide the ability to render prior treatment history (including treatment assessment data and patient response) prior to the administration of the treatment. |
CP.6.3#20 | SHOULD |
The system SHOULD provide the ability to annotate an individual scheduled treatment and include the annotation as part of the legal medical record(e.g., describe the treatment to be administered based upon specific clinical indicators). |
CP.6.3#21 | SHALL |
The system SHALL provide the ability to render the treatment order as written (i.e., exact clinician order language) when rendering treatment specific information including special instructions. |
CP.6.3#22 | SHALL |
The system SHALL provide the ability to capture and render patient-specific instructions related to the treatment. |
CP.6.3#23 | SHALL |
The system SHALL provide the ability to manage information regarding a second provider witness to co-document treatment. |
CP.6.3#24 | SHOULD |
The system SHOULD provide the ability to capture the documentation of treatment administration using a barcode scanner or imaging scanner (e.g., scanner capable of reading two-dimensional symbologies). |
CP.6.3#25 | SHOULD |
The system SHOULD provide the ability to render an alert to the administering provider when an electronic identification device (e.g., barcode & scanner or Radio Frequency Identifier (RFID)) is used to document treatment and one of the following is in error: right patient, right treatment, right time and right method or there has not been positive identification of administering provider. |
CP.6.3#26 | SHOULD |
The system SHOULD provide the ability to manage treatment schedules (e.g., adjustments for delay, refused, unavailable). |
CP.6.3#27 | conditional SHALL |
IF the system provides the ability to manage treatment schedules, THEN the system SHALL provide the ability to render a notification of a change in the treatment schedule. |
CP.6.3#28 | MAY |
The system MAY provide the ability to auto-populate details associated with the treatment administration from the treatment order information. |
CP.6.3#29 | SHOULD |
The system SHOULD conform to function [[CP.1.2]] (Manage Allergy, Intolerance and Adverse Reaction List) to capture an reaction to a specific treatment. |
CP.6.3#30 | SHOULD |
The system SHOULD provide the ability to capture that patient educational information was provided at the time of the treatment including to whom the information was provided. |
CP.6.3#31 | SHALL |
The system SHALL conform to function [[CP.3.2]] (Manage Patient Clinical Measurements) to capture other clinical data pertinent to the treatment (e.g., vital signs, blood glucose reading). |
CP.6.3#32 | SHOULD |
The system SHOULD provide the ability to capture that a treatment has not been administered including the reason for not administering (e.g., patient refusal). |
CP.6.3#33 | SHOULD |
The system SHOULD provide the ability to exchange treatment information with other related systems (e.g., pharmacy, laboratory ). |
CP.6.3#34 | SHOULD |
The system SHOULD conform to function [[CPS.1.7]] (Preferences, Directives, Consents and Authorizations) in order to capture the patient's preferences regarding receipt of treatment (e.g., refusal of certain materials/supplies) at the time of treatment administration. |
CP.6.3#35 | SHOULD |
The system SHOULD capture and maintain user preferences for how the list of treatments are rendered. |