Interoperability Vocabulary Vocabulary Service Extensions SAGE Local Extension Concepts Post-coordination Concept expressions Aggregation logic Information Model and VMR

HL7 Reference Information Standards Clinical Decision Support and the Clinical Statements Model Virtual Medical Record (VMR) SAGE clinical record queries Clinical expression models Order Set Standards SAGE and Workflow Activity Graphs Context and Triggers CIS Actions

Interoperability	Vocabulary	Information Model	HL7 Standards	Workflow
Interoperability

The goal of the SAGE guideline development is to create an environment for interoperable publication, dissemination and implementation of guideline decision support. Interoperability implies full and transparent use of software between computing platforms and vendors without regard to local implementation. Interoperability requires attention to five discreet layers of data and knowledge sharing:

• Functional: physical data transfer must be supported employing shared standards
• Transactional: data must be shared in a messaging and distribution format that is accepted by all parties
• Semantic: clinical meaning must be supported within a shared information model and employ a standard domain ontology
• Procedural: executable processes must share a common plan for run-time support
• Ergonomic: software processes should be deployed in the clinical environment within a shared work plan

The SAGE model for interoperability addresses the five requirement layers as follows:

Functional	SAGE encoding employs Unicode character sets and standard file formats
Transactional	SAGE guideline encoding is delivered as XML markup generated by the open source Protégé workbench
Semantic	US standard clinical vocabularies exclusively employed as the domain ontology SAGE Virtual Medical Record (VMR) information model developed in compliance with HL7 Reference Information Model (HL7 RIM)
Procedural	SAGE execution engine standards specify the application program interface (API) with the vendor Clinical Information System(CIS)
Ergonomic	Workflow-aware guideline model links scenarios for clinical work to execution environment employing vendor CIS transaction monitoring

SAGE Controlled Resource strategies specify the architecture, standards and algorithms which support of interoperation of SAGE guidelines.

Interoperability	Vocabulary	Information Model	HL7 Standards	Workflow
Vocabulary				top

Semantic interoperability (sharing of conceptual meaning) between vendors requires the use of a common domain ontology for encoding clinical content. The ideal domain ontology would be comprehensive, share a common definitional model and employ recognized procedures for domain extension and aggregation semantics. Although no single vocabulary reference has been recognized as a universal answer to this issue, the federal government has identified a limited set of reference terminologies to support these needs for the United States. The Consolidated Health Informatics Initiative(CHI) has specified:

• SNOMED Clinical Terms www.snomed.org
• Logical Object Identifiers and Numeric Codes www.regenstrief.org/medinformatics/LOINC
• National Drug File - Reference Terminology
• RxNorm

as the minimal set of vocabulary standards to be employed in clinical system and decision support development. The SAGE guideline initiative employs these CHI supported terminologies exclusively for SAGE guideline encoding.

The SAGE project maintains concepts which require vocabulary extensions in separate SAGE terminology namespaces that are linked to the existing standards. For example, if a SAGE concept was defined as a collection of LOINC concepts, it is maintained as a member of the SAGE LOINC terminology extension. If a concept's intent is consist with a particular terminology's intent, such as SNOMED CT and is a reasonable candidate for inclusion in a future release, it is maintained in the appropriate SAGE-linked terminology namespace (such as SAGE SNOMED CT.)

Vocabulary Service Extensions

Concepts required by the guideline encoding cannot always be accurately represented using the standard (pre-coordinated) release of terminologies employed by SAGE. Certain concepts required as intermediary variables in the execution logic can be declared as SAGE extension concepts and kept in the local namespace if they are not required for query of the CIS record. Other concepts which are expected to be recorded in the clinical data record may require that extension concepts be developed in compliance with the syntax and grammar of the reference terminology (post-coordinated concepts) or that boolean logical statements be developed (concept expressions) which define the new concept in terms of other pre-coordinated concepts. Experience with encoding of standard guidelines suggests that such vocabulary extensions are required in 5 to 15% of cases. Furthermore, limitations in the reference features of some of the standard terminologies, especially problems with the subsumption hierarchies, require support for extended aggregation logic from the domain ontology at run-time. These constitute four categories of vocabulary service extensions employed in the SAGE guideline model.

SAGE Local Extension Concepts

Due to the complexity of guideline logic, concept variables required for execution must often be created within the decision logic model. Since these concepts are not stored in the CIS, no questions of interoperability arise. SAGE local extension concepts are defined solely within the guideline encoding, are assigned a local extension code, and are maintained within a SAGE vocabulary namespace. Encoding of US Immunization guidelines required 16 such concepts, which represented 7% of concept content. From the three guideline exemplars presented, samples of SAGE local extension concepts include:

• "Pneumococcal vaccination up-to-date" [SAGE]
• "DTaP vaccine is due" [SAGE]
• "Class I CAP risk" [SAGE]
• "Blood cultures obtained prior to arrival" [SAGE]

Post-coordination

Those vocabulary schemes employed by SAGE which employ a compositional model and support post-coordination include SNOMED-CT and NDF-RT. These terminologies have defined models for building meaning and support expectations that the user community may maintain extensions to add shared concepts that have not been provided in the pre-coordinated release. While LOINC employs a compositional model, absence of a subsumption hierarchy and extension maintenance features preclude use of post-coordination for this terminology. Concepts required for guideline representation which are within the scope and definition of these terminologies are modeled as post-coordinated concepts.

Examples:

• "Lives in dormitory" [SAGE SNOMED CT]
  • "Is a Finding of residence and accommodation circumstances (finding) 365508006"
  • "Interprets Residence and accommodation circumstances (observable entity) 22409007"
  • "Has interpretation Dormitory"
• "Occupational exposure to N meningitidis" [SAGE SNOMED CT]
  • "Is a Meningococcus contact (finding) 170473002"
  • "Associated with Neissseria meningitidis (organism) 17872004"
  • "Interprets General clinical state (observable entity) 278844005"
• "Severe community acquired pneumonia" [SAGE SNOMED CT]
  • "Is a Community acquired pneumonia (disorder) 385093006"
  • "Severity Severe (severity modifier) (qualifier value) 24484000"

Concept expressions

Guideline clinical concepts are often complex and may not always be cleanly defined by concepts in the standard reference terminologies. This occurs in one use case when a concept refers to a set which does not represent one entire "branch" of the standard reference ontology. In such a case a logical restriction on two or more branch elements may often allow for a precise definition of the set of concepts of interest. We found this to be a recurring requirement for employment of terminology standards and call these logical restrictions "Concept expressions". A concept expression may employ AND, OR and NOT, thereby restricting the sets of concepts and their subtypes to a logical intersection, union or disjunction as necessary for clinical correctness. Examples of such composite clinical references from the guidelines presented included:

• "Chronic pulmonary disease excluding asthma" [SAGE SNOMED CT]

  In this case, clinical guideline experts agreed that conditions such as "Chronic rhinitis" and "Chronic pharyngitis" were outside the scope of the pulmonary conditions intended by the guideline authors.

  
• "Chronic renal failure conditions" [SAGE SNOMED CT]

  Several SNOMED CT subtype concepts, including "Acute renal failure syndrome" and "Renal failure unspecified" were thought not to be within the scope of "Chronic renal failure"

  

Aggregation logic

SNOMED-CT and NDF-RT include rich hierarchical relationships which are employed as a domain ontology by the SAGE run-time environment to define aggregation queries when the guideline logic requires a check for a concept AND all of it subtypes (children). These hierarchies are extremely useful for SAGE decision logic but do not always provide the supertype concepts required by the guideline use case. Furthermore LOINC does not have such relationships. In those cases when guideline logic required a supertype concept not within the pre-coordinated terminology release, this concept and associated relationships were defined in the SAGE extension namespaces. Examples occurred within each terminology employed in the encoding, although overall the frequency of requirement was low.

Exemplars are:

• "Glucocorticoid preparation for chronic use" [SAGE SNOMED CT]
  
• "HEMOGLOBIN A1C.All_Clinical" [SAGE LOINC]
  
• "Immunocompromising procedure" [SAGE SNOMED CT]
  
• "Radiation therapy procedures" [SAGE SNOMED CT]
  

Interoperability	Vocabulary	Information Model	HL7 Standards	Workflow
The Information Model and VMR				top

Reliable and consistent behavior of SAGE guidelines across vendor platforms requires that the SAGE execution engine can query and update CIS record information during guideline execution regardless of data base organization. Vocabulary standards support semantic interoperability at the domain level, but standardization of content must also be reflected in the information model (top level ontology) for full functionality. In order to provide that functionality, SAGE employs an idealized model of clinical record information artifacts compliant with formalisms of the HL7 Reference Information Model (RIM). This is called the Virtual medical Record (VMR). All read / writes to the vendor CIS database occur with service calls compliant with this formalism. The vendor implementation of a SAGE engine, in turn, is required to provide mapping from the VMR to the physical and logical specifics of the vendor CIS data model.

Interoperability	Vocabulary	Information Model	HL7 Standards	Workflow
HL7 Reference Information Standards				top

Clinical Decision Support and the Clinical Statements Model

The VMR specification was developed in dialogue with the Clinical Decision Support Technical Committee of HL7 and follows formalisms developed from the HL7 RIM by the Clinical Statements Special Interest Group.

Click to to view details.

Here is the HL7 Clinical Statements Project Page.

Virtual Medical Record (VMR)

The VMR consists of thirteen information classes, each representing a specialization of the RIM Act class, consistent with the Clinical Statements standard development.

• Observation: An event record containing a report or symptom, a physical finding, a laboratory or test result pertaining to the patient, the patient medical history or that of a related subject.
• Encounter:A patient event record identifying a clinical care activity involving a patient and one or more clinical providers
• Problem: A patient episode record of an important diagnostic impression or summary statement of clinical state applicable to a patient over time
• Adverse reaction: A patient record of an allergic or adverse reaction to some substance
• VMR Order: a patient order record specifying the plan for obtaining a test, administering a treatment, or initiating a procedure
• Medication Order (specializes VMR Order): a patient order record specifying the plan to administer a pharmaceutical treatment
• Goal: A statement of intent in the patient record specifying a patient state or finding that is the object of the care plan. The value slot specifies the target value for the code.
• Procedure: An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject.
• Referral: A patient order record initiating a request for evaluation or service by another care provider or agency
• Agent: An entity that participates in an act through a role
• Appointment: A patient order record specifying the details of a plan for a clinical care encounter
• Alert: A record of alerts that have been generated in the system for the patient
• Composite clinical model: A clinical model that is an aggregation of a number of component acts.

SAGE clinical record queries

An instance of a VMR object class is defined by a set of attribute-value pairs which are unique to the object class and the existence of the instance. The attributes for each class are defined by derivation from the Act specialization of the HL7 RIM version 3. Sample object definition for the class Observation is included in Figure 4, below. All read and write activities to the CIS record occur through the SAGE engine program interface and constrain or query these object attributes.

Figure 4: VMR Observation class

Clinical expression models

SAGE Clinical Expression Models (CEM) are restrictions on VMR queries which define valid instances retrieved from the CIS clinical record or from direct user input as required for evaluation of guideline knowledge. CEMs are employed in order to specify information class, vocabulary code set, time or encounter constraints, method, subject or value restrictions which are important to validate or constrain data retrieval. CEMs may be employed to construct user queries for data, or restrict the data types and format which are retrieved from the CIS.

In the example below, a CEM for pulse rate specifies a restriction on the "code" slot of an observation, requiring that the query restricts results to those where the "code" attribute of the data record contains the SNOMED CT observable "Pulse rate" or one of its children.

In a similar vein, a CEM may specify restrictions for any of the attributes of the data query at VMR class and may restrict the cardinality, define defaults and specify the domain for each element. CEMs are employed to assure that CIS and User queries return valid data and to specify default behavior at the user interface.

Order Set Standards

Order sets are a knowledge construct in common use at many institutions. An order set is a collection of proposed orders structured to fulfill a portion of a care plan. An order is an authenticated communication from a licensed practitioner authorizing an action upon a patient within the health care system. Before an order is issued to a particular patient it is templated within the systems. Order sets are collections of these templated orders plus the inter-relationship of these orders.

See also Model Components: Order Sets.

The SAGE consortium recognized the need to share order sets and proposed an order set publication standard that fulfills the following use cases:

1. Publish, Distribute and Track: Provide metadata for authoring, maintenance and dissemination by professional standards organizations
2. Import: Full text order set content permits localization and use within vendor EHR including ordering tests, treatments and procedures, setting goals, and recording observations
3. Presentation management: Organize and restrict order session content for maximum clinical utility
4. Manage as knowledge: Coded standards-based order content supports manipulation of order sets, order segments and order items by a decision support engine

We envision that a shared order set will be developed and published recognized experts. The published order set will contain metadata about the development and use of the order set, a collection of templated orders and information about their interrelationship. This published order set may be part of a larger guideline based care plan encoded in the SAGE format. The order set will be mapped into the local CIS CPOE subsystem and order master. The localized order set will then be available for selection by the physician to issue in the care of a patient.

The order set publication standard is a functional and structural definition of a structured format for publishing and distributing order set content. It is not a proposal for developing order masters and it is not an order messaging standard. The proposed standard must address the varied capabilities of host systems that will deploy the order set content.

Interoperability	Vocabulary	Information Model	HL7 Standards	Workflow
SAGE and Workflow				top

Workflow aware clinical decision support systems will provide the greatest opportunity to impact the quality of care when computer-based, patient-specific reminders are integrated into the clinician’s workflow.

Achievement of this goal requires an understanding of clinical workflow and how this relates to workflow assumptions implicit in the CIS. All vendor CIS environments operate with either an explicit or assumed workflow model. Workflow is the series of tasks or gates necessary to complete a process that accomplishes a goal. In health care our goals include disease prevention, health education, diagnosis, treatment and research. The focus of the CIS is on diagnosis and treatment.

The accomplishment of these goals requires processes such as admission, discharge, evaluation, treatment protocols, and care planning. Workflow is the order in which these tasks and subtasks occur.

Developers of a CIS have a workflow in mind when they design the software. A patient must be admitted to the CIS and a record created before orders can be entered. Results have to be entered in the system before they can be reviewed. An order has to be placed before a result can be attached. We assume that SAGE cannot assert control over vendor systems’ workflow management and therefore the SAGE model was developed to be aware and respond to vendor CIS workflow constraints. This contrasts with historical guideline systems development which generally adopted an agnostic approach.

The SAGE environment was created after an extensive review of pre existing guideline deployment systems, publicly available workflow engines and workflow standards which concluded that no universally accepted paradigm existed within the vendor community. The SAGE system therefore responds to opportunities for decision support within the care process by explicitly modeling clinical care context (Figure 1). Context in the SAGE model includes a sufficient abstraction of CIS workflow to specify and respond to appropriate events for purpose of triggering decision support services.

Figure 1: A clinical context modeled in SAGE guideline where the triggering event is an update of the EMR.

Upon receipt of such a triggering event (figure 2), SAGE delivers appropriate guideline based recommendations through existing functions of the host CIS. These guideline actions are bound to vendor host functionality and are modeled within a clinical care scenario which is encoded as a SAGE activity diagram.

Figure 2: SAGE context event ontology

SAGE is thus and event-driven reactive system that takes into account clinical and organizational contexts while delivering guideline based recommendations. Story board scenarios serve to organize and flow chart the workflow expectations. The scenario is encoded as an activity diagram. The SAGE engine CIS interactions were then modeled within the activity diagram for interaction with clinicians. These models are tested in a usability lab in order to determine the best method for presenting SAGE Guideline knowledge to users at the point of care.

Activity Graphs

The SAGE Activity Graph formalism (see here) is derived from the Workflow Management Coalition's Workflow Process Definition Language (WPDL). SAGE guideline modeling organizes guideline recommendations as usage scenarios. A scenario is an abstraction of the care process implementing specific roles, entities and actions within an enterprise. These scenarios correspond to real world events such as encounters, telephone triage, screening of patients, and in-patient medication administration. A scenario consists of one or more context node links to the clinical setting (such as an outpatient clinic), patient state (diagnosis of hypertension), patient management state (receiving anti-hypertensive medications), clinician role (internist) and trigger events (prescription writer). Alerts, reminders, recommendations for data collection, and decision making are then encoded within the guideline model linked to the context via the activity graph.

Context and Triggers

SAGE listens for specific events which initiate SAGE engine activity for a particular scenario. Context objects within the activity graph characterize the event for SAGE initiation. Context is a complex object (Figure 3) that includes:

• Clinical context: the clinical setting, roles and resources that must be in place for this scenario
• Informatics context: the information resources required for execution of this scenario
• New_session: indication whether this context node initiates a new session
• Precondition: criterion which must test true for this context to activate
• Scheduling constraint: criterion which must test true for this context to activate
• Subguideline: an activity graph or decision map that is executed as part of this step
• Transition restriction: control information for this context; includes Join and Split Constraints
• Triggering events: the computer-based event which triggers evaluation of the context node

Figure 3: Context attributes

CIS Actions

Another necessary component of workflow is routing of information. The system must have some understanding of the users's role in the care process in order to display the relevant information. Knowing a user role is insufficient because roles interact with the current situation to define what is needed in workflow. The current situation can be defined by where the patient physically in the care process. For instance, the surgeon does not need to see a health maintenance alert while creating an operative note. Nurses may be reassigned to a different ward at different times. The Workflow on that ward is different so their interaction with the CIS is different. By necessity user roles are defined by the security system but may not correspond to their role in the process of patient care. SAGE adopted an enterprise workflow model where by the current context was defined by users roles and location.