OpenClinical logo

Clinical demonstrators

Methods and tools for the development of computer-interpretable guidelines

SEBASTIAN
System for Evidence-Based Advice through Simultaneous Transaction with an Intelligent Agent across a Network
SEBASTIAN is a Web service-based framework for (i) encoding medical knowledge into a machine-executable format; (ii) integrating this knowledge into various clinical applications to enable clinical decision support.
keywords Clinical decision support, clinical practice guidelines, computer-interpretable guidelines, XML, markup, web services, XML messages, knowledge representation, knowledge acquisition, guideline execution, re-use of executable medical knowledge, standards, HL7 RIM, UMLS, Java Integrated Development Environment (IDE), IntelliJ IDEA, InfoPath
developed by Division of Clinical Informatics, Department of Community and Family Medicine, Duke University Medical Center, Durham, North Carolina, USA
introduced 2005
status In use / under continued development.

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

support NIH (National Institutes of Health of the US Department of Health and Human Services), AHRQ (Agency for Healthcare Research and Quality), HRSA (Health Resources and Services Administration of the US Department of Health and Human Services).
in use SEBASTIAN has been used to implement four decision support systems to date:
  • An outpatient Diabetes Reminder System (DRS) at the Duke Family Medicine Center
  • Three systems to support the health management of approximately 16,000 Medicaid beneficiaries in Durham County, North Carolina. "One system provides patientsí primary care clinics with reports that list the patients most in need of services, along with identified care needs and recommended actions. A second system emails alerts to appropriate health care providers regarding care issues requiring follow-up, and a third system generates care reminder letters for patients in English and, when applicable, in Spanish."
tools See annotated screens below illustrating use of SEBASTIAN tools.

The SEBASTIAN toolset is maintained in-house and the software is not freely available.

Contact Kensaku Kawamoto at Duke University (details below) if you are interested in accessing the SEBASTIAN toolset.
Knowledge Representation approach
  • 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.
Knowledge Authoring
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.

spacer


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.

spacer


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.

spacer


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


spacer


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 service operations
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.

Strengths of the approach
  • 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.

Limitations of the approach
  • 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.

plans
  • 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.
references

Kawamoto K, Lobach DF. Design, implementation, use, and preliminary evaluation of SEBASTIAN, a standards-based web service for clinical decision support. Proceedings / AMIA Annual Symposium. 2005:380-384.

[]   [OC]

" Despite their demonstrated ability to improve care quality, clinical decision support systems are not widely used. In part, this limited use is due to the difficulty of sharing medical knowledge in a machine executable format. To address this problem, we developed a decision support Web service known as SEBASTIAN. In SEBASTIAN, individual knowledge modules define the data requirements for assessing a patient, the conclusions that can be drawn using that data, and instructions on how to generate those conclusions. Using standards-based XML messages transmitted over HTTP, client decision support applications provide patient data to SEBASTIAN and receive patient-specific assessments and recommendations. SEBASTIAN has been used to implement four distinct decision support systems; an architectural overview is provided for one of these systems. Preliminary assessments indicate that SEBASTIAN fulfills all original design objectives, including the re-use of executable medical knowledge across diverse applications and care settings, the straightforward authoring of knowledge modules, and use of the framework to implement decision support applications with significant clinical utility. "

contact Kensaku Kawamoto
Division of Clinical Informatics
Department of Community and Family Medicine
Duke University Medical Center
DUMC 2914
Durham
NC 27710
USA

T: (919) 684-6421
E: kawam001atmc.duke.edu
links  bullet  Division of Clinical Informatics at Duke University

A SEBASTIAN website is currently under development at Duke University.

acknowledgements
Kensaku Kawamoto, Division of Clinical Informatics at Duke University
page history
Entry on OpenClinical: 26 January 2006
Last main update: 15 February 2006

 

Search this site
 
Privacy policy User agreement Copyright Feedback

Last modified:
© Copyright OpenClinical 2002-2011