Once a guideline has been developed and encoded and tested, it is deployed to a clinical environment with a SAGE compliant clinical information system. The guideline logic is reviewed, and tested locally, and then modified for local conditions. Following that, concepts in the guideline which use standard terminology system like SNOMED Clinical Terms (SNOMED CT), are mapped to internal local identifiers on the target system. It is then installed and executed.

Some details about each of these steps will be explained here.

The architecture of the SAGE Execution Engine and its operations are covered in Guideline Execution.

The ebXML Registry

Guidelines are encoded in Protégé which can produce permanent files in several formats, including XML files which are easily portable not only to other Protégé environments, but may be processed by other systems. During the SAGE Project, we used the standard Protégé files as the transport form of guidelines.

Guidelines in these formats may be stored on a public web site, or in a managed environment with version control. One can easily imagine a searchable, evidence linked guideline store that is capable of sending out notices of changes to interested clinicians.

The ebXML Registry Server supports registration, management, update and retrieval of guideline packages along with their metadata in the form of attributes, slots, context sensitive classifications according to both internal and external classification schemes, auditable events and associated registry objects. The packages themselves may include both machine-readable guideline specifications and related human-readable documents. Guideline packages are versioned, and dependencies among (versions of) different packages are maintained.

For a demonstration project, we deployed the ebxmlrr, now the freeBXML Registry (OMAR) server software from SourceForge, and an Apache Tomcat servlet engine, together with a PostgreSQL 7.3 relational database system supported by the Cygwin UNIX emulation environment, all running on Windows 2000. The Apelon DTS Server provides uniform access to multiple standard medical terminologies. In this application, it expedites selection of appropriate guideline metadata from medical terminologies via hierarchical browsing and by searching based on code lookup, text matching, attribute queries, etc. For example, the disease or condition that is diagnosed, treated or prevented by a particular guideline can be selected from the International Classification of Diseases, Ninth Revision (ICD-9).

DTS is written in Java and runs on Windows 2000 and XP, along with certain UNIX platforms. Apelon's Guideline Registry client connects with both of the servers and provides end users with a custom GUI for submitting and managing guidelines through their life cycle in the registry, as well as for finding and retrieving guidelines of interest, all by means of standard terms. The client is a prototype implemented in Java. It builds on the JAXR client API implemented by the ebxmlrr client software from SourceForge, along with the DTS client API implemented by Apelon. It also leverages Apelon's rich set of graphical terminology interface components.

A guideline can be downloaded from any SAGE compliant source. Such a download would include the Protégé files and/or their XML equivalents, and possibly HTML formatted readable versions of the guideline logic and background information. During the project, we commonly exchanged copies of all the files needed for review and execution in a single compressed directory.

Guideline workflow logic is often more complicated than simple rules. With increased scenario complexity, the probability of errors rises geometrically. The SAGE workbench supports both display and testing of imported guidelines.

Guidelines can be "display" as web pages. The KB2DOC tab in the SAGE Guideline Workbench produces XML output that is transformed to html.
For example, see HTML for Community Acquired Pneumonia, HTML for Diabetes, and HTML for Immunizations.

SAGE allows workbench testing. We accomplish this in two ways: 1) Isolated - with the guideline running in Protégé and patient data being entered by hand through forms, and 2) Connected - with the SAGE Engine using the isolated guideline but getting patient data from an active clinical information system (CIS). See The SAGE Tab.

SAGE also allows internal consistency checking of bindings and data constraints. Our environment supports creation and editing of terminology mappings.

Guidelines are unlikely to be directly applicable as delivered to every clinical environment. Minor editing may be required to adjust for formulary, or for laboratory normal ranges. Major edits might be required for variances in workflows in different clinics, or local goals. For example, in one institution, automatic enrollment in an Immunizations guideline may be the normal practice; in others, a clinician is required to put a patient on any guideline.

Another localization issue is workflow. At some institutes doctors may give immunizations while at others they may be administered by RNs. In some locations, tasks may be done in parallel; in others, say, due to staff size or training, operations might be serial. It is important for SAGE to know who is responsible for actions and at what time to intervene.

SAGE is much more than an "alerts and reminders" machine. For example, if SAGE recommends a medication for the patient, it must know the preferred medication to recommend at the local site. Formularies vary from clinic-to-clinic and hospital-to-hospital. The Protégé allows adjustments and testing to accommodate local variances.

Here is an example, showing a change in the Diabetes guideline based on a 2006 option for choosing a lower LDL goal.

The interoperable SAGE model assumes compliance with information and vocabulary standards. Implementing this model in a system with parochial terminology requires: 1) Review of scenario assumptions for local applicability, and 2) Exhaustive mapping to local data tables which must supported coded concepts. Standards-based coded content in a SAGE guideline must be mapped to corresponding codes used in the host CIS.

The SAGE environment comes with tools for reviewing and setting mappings. Shown here are screens for setting (or deleting/editing) a mapping, and listing of existing mappings. The listing shown here is for Observations.

Mappings are set for each of our Virtual Medical Record classes. Here are a few Mayo Clinic mappings for Problems and Observations.

An Example Mapping at the Mayo Clinic: HbA1c

Early in our Diabetes guideline encoding, SAGE needs access to observations about the Hemoglobin A1c values for a patient. The first criteria depend on knowing whether the test has been run during a time interval before the current visit.
The criterion uses a specific value

BIN A1C/HEMOGLOBIN.TOTAL:MFR:PT:BLD:QN: [LOINC 4548-4]

At The Mayo Clinic, there are 4 different lab values equivalent to the LOINC 4548-4. The middle two shown here are used in research and thus are not available for viewing clinically. We therefore map 82080 and 82990 to this LOINC code. The middle two Mayo research lab values will not be mapped.

Here is the mapping, including the GE Centricity values from the master tables at The Mayo Clinic:

LOINC has 4 different values for the HbA1c. Mayo uses only the first two. The second one is a calculated value. It is no longer in use at Mayo. Old records might have that value as well, so our mapping for HbA1c will include the second LOINC value 17855-8.

So, our mapping at this time, including the other LOINC code, is show here. In fact, our guideline only uses the LOINC 4548-4 code, so all three of the GE Centricity concepts map to this same code.

The guideline also needs to be able to detect an ORDER for a HbA1c. For this we use the SNOMED CT code of 313835008. So we need to add this our mapping.

After SAGE information model and terminologies are mapped to those of the local institution, the guideline is ready to be made active as described in the Guideline Execution page.