We developed The SAGE Engine that understands the encoded guidelines produced in the Protégé workbench. Show here is the architecture of the execution environment.
The encoded guideline is uploaded to the engine where first it is validated to be sure that all the necessary attributes have been defined for successful execution. Once validated, the CIS events encoded in the guideline are registered with the event manager in the CIS, thereby expressing the execution engine's interest in these CIS events. When a relevant event is detected, the engine begins execution.
Once the guideline has been activated, the SAGE execution engine is able to execute the guideline by interpreting the en-coded content, obtaining current patient data from the CIS, and invoking functionality within the CIS to implement an action specified in the guideline.
A SAGE guideline deployment consists of a SAGE execution engine, an event listener, a terminology server, and a set of interfaces called VMR/Action services which interoperate with the local Clinical Information System (CIS). An execution engine can execute multiple guidelines and a health care delivery may run one or more execution engines based on scalability and other considerations. The engine itself is portable and may run on any of several computers including inside the CIS itself.
The SAGE execution engine is designed specifically to process guidelines encoded using the SAGE guideline model. The engine interprets the content of the context, action, and decision nodes in an encoded guideline, executes workflow and decision logic, and interacts appropriately with the CIS. The event listener is the mechanism by which the engine is notified of state changes in the CIS. As part of conforming to the SAGE engine, the CIS implements the module that forwards events of interest to the event listener.
Most commercial CISs have terminology services implemented within themselves. In the absence of terminology services within the CIS environment that supports standard terminologies, an external terminology server may be employed in a SAGE deployment. The terminology server encapsulates standard terminologies and implements terminology subsumption that may be used by the engine. In our implementations we have used three different terminology services:
- internal for the SAGE engine itself,
- the Apelon DTS terminology server, both on-site and remote
- a controlled concept directory service that is part of the GE Centricity Enterprise CIS.
The VMR/Action services are interfaces into both patient data and application functionality provided by the CIS. The VMR services are used to get information from the CIS (e.g: obtain patient's age) and the Action services are used to initiate actions within the CIS (e.g., place an order for Hepatitis B vaccine). The VMR/Action services can be viewed as wrappers around existing CIS data and functionality and support interoperability by presenting a unified view of clinical information systems to the guideline execution engine.
In the SAGE project we have aligned the VMR/Action services interfaces with standards such as HL7 messages and have proposed these interfaces as standard access/action mechanisms into CIS data and functional elements. These interfaces can be used by non-CIS systems such as the guideline execution engine to interact with the CIS.
In the guideline model, patient data concepts are represented using VMR classes. Queries for patient data are represented using standard VMR-based methods. Patient data queries are processed via VMR Service web services. Generic methods are "mapped" to CIS-specific methods. Data objects returned to SAGE Engine are built from HL7 data types.
Here we see an "expanded" view of the VMR interface.
The illustrates a patient data request for a Serum Creatinine value, most likely in a defined time-frame like "the most recent" or "before 3months ago". The left-hand side of the interface in generic; it knows nothing about the specifics of any CIS. The right-hand side is bound to a particular CIS, so it can find the Serum Creatinine lab value in the appropriate databases using the local CIS methods.
We have created CIS web services for Centricity Enterprise that support such VMR based queries. They return standard-based formatted messages that contain one or more patient values, in this case, for Serum Creatinine. These VMR Services include access to Appointments, Alerts, Procedures, Problems, Substance Administrations, Referrals, Adverse Reactions, Medication and Other Orders, Encounters, and Goals.
The Action part of these interfaces includes the ability to issues orders and alerts, and potentially to retract or revise both of these. SAGE may places new problems on the patient's problem list. It can also perform population surveillance. Actions might include the issuing of new events that will impact future actions, as could be used to monitor for administration of antibiotics.
Alerts can be manifest in the CIS in multiple forms: via the Inbox (a simple message), as orders or order sets (e.g., in Community Acquired Pneumonia below), as problems placed on the problem list, or as suggested actions on a flowsheet, or in the form of visible indicators in flowsheets, and with explanatory text accompanying other recommendations.
Details on the SAGE execution semantics are covered in The SAGE Guideline Model Specification Document [pdf]. The SAGE Engine implements that specification at a level that has allowed successful implementation of three guidelines so far. There are opportunities for adding to the the engine mechanisms when needed as new guidelines demand those facilities.
The Context, Decision, and Action nodes in our Recommendation Sets are described in Model Components.
For further details see our MedInfo 2004 paper.