• Medical knowledge is captured in SEBASTIAN in XML documents known as Executable Knowledge Modules (EKMs). An EKM encapsulates medical knowledge in a machine-executable format that can be used to generate patient-specific inferences useful for clinical decision support (CDS).

• The scope of an EKM is an assessment of a single patient in a specified topic area. The topic area may be narrow (e.g. the need for a glycated hemoglobin test for a patient with diabetes) or broad (e.g. the existence of contraindications to any medications prescribed or about to be prescribed for a patient).

• EKMs use a patient information model based on the HL7 Reference Information Model (RIM), and medical concepts are preferentially defined using standard vocabularies included in UMLS (the National Library of Medicine's Unified Medical Language System).

• EKMs include maintenance, library, knowledge and logic sections.

• The EKM maintenance and library sections contain meta-data regarding the EKM (e.g. title, identifier, keywords).

• The EKM knowledge section defines the data requirements for assessing a patient using the EKM, which may include demographic data (e.g., gender, race, age) as well as data on health care acts (e.g., observations, diagnoses, procedures).

• The EKM knowledge section also specifies the format and meaning of the machine-interpretable CDS results that can be generated using the specified patient data. For example, an EKM that evaluates whether a patient with diabetes is due for a glycated hemoglobin test may specify that it will return a result code indicating whether the patient is (i) ineligible because he does not have diabetes; (ii) eligible but not in need of the test due to a test on record from the previous six months; or (iii) eligible and in need of the test. Furthermore, the EKM may specify that it will return a result parameter that specifies when the last test was conducted and a parameter that specifies the value of the patient's last test.

• Finally, the logic section uses native Java code to specify how the patient data provided by a SEBASTIAN client will be used to generate the CDS results promised in the knowledge section. To generate the results, SEBASTIAN creates Java classes corresponding to each EKM in its knowledge repository. Within these Java classes, required data elements are made available to the module author as native Java objects. For example, if a module requires data on glycated hemoglobin tests from the past year, the Java class will contain an array that is populated at runtime by Observation objects that represent glycated hemoglobin tests from the previous year. Given this setup, standard programming techniques can be used to manipulate the patient data and to generate the CDS results promised in the knowledge section.

• The logic section could potentially make use of a clinical guideline represented as a Task-Network Model in order to generate the CDS results.

An EKM can be authored using any XML editor. Currently, EKMs are edited using a Microsoft InfoPath form.

Figure 1: Screenshot of an EKM library section as viewed from within the InfoPath authoring environment.

Figure 2: Screenshot of an EKM knowledge section in which the format and meaning of the CDS results that will be returned by an EKM are being specified.

The authoring environment provides extensive terminology support through the use of a terminology Web service that is wrapped around the UMLS. The terminology service is primarily used to identify concepts subsumed by a parent concept (Figure 3) and to translate concepts between terminologies (Figure 4).

Figure 3. Screenshot of EKM knowledge section in which the terminology service is used to identify all SNOMED CT codes considered to be a descendant of the concept for the ACE inhibitor drug class.

Figure 4. Screenshot of EKM knowledge section in which the terminology service is used to translate SNOMED CT codes for ACE inhibitors into equivalent NDC codes

The EKM logic section can be edited using the InfoPath authoring environment. However, a Java Integrated Development Environment (IDE) is generally used to edit the Java classes that are auto-generated by SEBASTIAN and which correspond to the EKMs. The IDE currently being used to author the EKM logic section is IntelliJ IDEA. The processing instructions specified in the Java class are then translated back into the EKM logic section by SEBASTIAN, so as to maintain a one-to-one correspondence between an EKM and its associated Java class.

SEBASTIAN offers four service operations to its clients to provide CDS using EKMs. As a Web service, SEBASTIAN communicates with client systems ("Intelligent Agents" in the SEBASTIAN acronym) using XML messages transmitted over the Internet. The primary service operation offered by SEBASTIAN is a patient evaluation operation. In this operation, a client specifies the EKMs to use for evaluating a patient, and the client also submits the patient data required by the EKMs. In return, SEBASTIAN returns CDS results regarding the patient as specified in the EKMs' knowledge sections. SEBASTIAN also offers three other operations to support the patient evaluation operation. These allow a client to:

• identify the knowledge modules that meet client search criteria;
• obtain descriptions of selected modules, including descriptions of the results that will be returned following patient evaluation;
• identify the data required for evaluating a patient using specified knowledge modules.

Process for enabling CDS capabilities within a clinical application using SEBASTIAN:

• The developer of the clinical application identifies the EKMs that meet the CDS needs of the application;
• The developer verifies that the application has access to the data required by the EKMs of interest;
• The developer ensures that when CDS functionality is needed, the application will
  • retrieve the required patient data,
  • send a request to SEBASTIAN to evaluate the patient using the relevant EKMs,
  • parse the EKM results that are returned,
  • process the CDS results to meet end-user needs.

• EKMs can be re-used across multiple applications and institutions.

• EKMs can be authored in a straightforward manner.

• The framework is relatively easy to understand and to use.

• Appropriate standards (e.g. HL7 RIM, UMLS, XML, Web services) are used.

• The only infrastructure required for receiving decision support from SEBASTIAN are an Internet connection and the capacity to exchange data using XML.

• SEBASTIAN facilitates knowledge maintenance by encapsulating executable medical knowledge into modules that are independent of specific applications, version controlled, tagged with meta data, and maintained centrally on behalf of multiple client applications.

• SEBASTIAN could be used to manage centrally executable medical knowledge on behalf of an institution or a region, since one SEBASTIAN instantiation can support multiple applications operating in diverse clinical environments.

• External knowledge resources and decision engines can be invoked from within the EKM logic section. Thus, medical knowledge that has been represented using different formalisms could potentially be accessed through a common SEBASTIAN interface.

• SEBASTIAN is serving as the basis for an emerging HL7 standard for Web service-based decision support.

• SEBASTIAN's usefulness has not yet been validated for several important types of CDS applications, such as computerized provider order entry (CPOE) systems with CDS capabilities.

• Fewer than one hundred EKMs have been implemented to date (at January 2006). The SEBASTIAN knowledge base will need to be expanded significantly in order to more comprehensively meet the CDS needs faced by health care professionals in various clinical contexts.

• The SEBASTIAN patient information model has not yet been formally reconciled with the HL7 RIM through a harmonization process.

• The SEBASTIAN service interface is serving as the basis of the emerging HL7 Decision Support Service specification. This seeks to standardize the input/output interface for services that use patient data to deliver patient-specific conclusions in a machine-interpretable format.

• Further operational uses of SEBASTIAN are being planned.