Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Provision of Medication Safety and Prescription Decision Support through an e-Prescribing System (Scenario originally described in HL7 Decision Support Service (DSS) Service Functional Model (SFM) Version 1.0)

Scenario Details:  John is an oncology patient seen by David in follow-up clinic. Towards the end of the visit, David begins to write prescriptions for John. When David enters a prescription, the basic medication safety knowledge module hosted by DSS A looks for medication safety issues. Required data are retrieved from the EMR and David is notified of any identified safety issues regarding drug-allergy contraindications, drug-drug interactions, and inappropriate dosing.

In addition to checking for medication safety issues, the system has the proposed prescription evaluated by DSS B, which serves as the national repository of medication prior authorization rules within the United States of America.  Each time David enters a prescription, the system submits the proposed medication and the patient’s health insurance information to a “gatekeeper” knowledge module that identifies whether the medication requires prior authorization.

For most of John’s prescriptions, DSS B’s gatekeeper knowledge module indicates that the patient’s insurer requires no prior authorization.  However, for one of the prescriptions, erythropoietin (EPO), prior authorization is required. The knowledge module for EPO authorization is designed so that either a) all potentially required data can be provided to the knowledge module at once, or b) the required data can be provided iteratively for those data elements deemed to be necessary based on the data already provided.

The local CPOE system is configured to utilize the EPO knowledge module in an interactive mode. The interaction occurs as follows:

1)    The CPOE system first provides the patient’s problem list as required by the knowledge module when evaluating a patient in an interactive mode.

2)    Based on the patient’s problem list, the knowledge module determines that the patient has cancer and that he is potentially eligible for EPO therapy to ameliorate chemotherapy-induced anemia.

3)    The system then provides relevant patient lab results retrieved from the underlying EHR, and the patient is again deemed to meet the prior authorization requirement.

4)    Finally, the knowledge module needs to know whether the patient is complaining of fatigue that limits an activity of daily living.  Since this data element is not available from within the EHR system, the system asks David to provide the required information manually.

5)    After receiving David’s affirmation of activity-limiting fatigue, the EPO knowledge module concludes that John is in fact eligible for EPO treatment and notifies the e-CPOE system that prior authorization has been approved for John’s EPO. 

Actors: Physician, Patient (John)

Requirements:

 

Requirement #

Description

1.3.1

The System shall have access to relevant patient medical data including diagnoses, medications, adverse events, radiology, labs, appointments, etc.

1.3.2

The System shall have access to relevant authoritative medical reference knowledge bases.

1.3.3

The System shall have access to other relevant authoritative decision support systems that have public, well-defined APIs.

1.3.4

The System shall have the ability to respond to data requests from relevant authoritative decision support systems that have been approved for system integration.

1.3.5

The System shall optionally limit its responses for data requests from authorized third party decision support systems according to local policy.

1.3.6

The System shall have the ability to present providers with questions and manually respond to data requests from decision support systems if automated access to such data is either not available or not desirable.

Assumption: should define the data elements that would be accepted by the system for response.

1.3.7

The System shall provide a method of documenting decision support interactions

(will new clinical data captured in interactive mode be send for storage to EMR?).

1.3.8

The System shall allow providers to override recommendations by the clinical decision support system

1.3.9

KMR / DDSS shall provide information for auditable events and shall be configurable.

1.3.10

The system shall provide audit logs that include all inputs and outputs from inference engine (be conservative).

1.3.11

The system shall provide other authorized requesters, such as an EMR system, with audit responses/logs.

  • No labels