ATHENA DSS uses the EON architecture for developing guideline-based decision-support systems (To note: A version of the EON Guideline Interpreter that uses web services instead of CORBA is under development). The EON architecture, created at Stanford Medical Informatics (SMI), provides ATHENA with the platform-independent technology to:

The architecture of a software system consists of the system’s constituent components and the relationships among them. ATHENA DSS’s system architecture reflects the fact that it uses SMI’s EON technology for developing decision-support systems for guideline-based care (1, 2, 4-6).

EON is an extensible architecture for developing decision-support tools for various aspects of protocol-based care. Initially developed to create systems for executing clinical trial protocols for the treatment of cancer and HIV infection (7) , it has been extended for the management of chronic diseases and of other types of guidelines. Because of the generic nature of the EON technology, ATHENA DSS has the potential to be extended to encode additional guidelines, to be extended for additional decision-support tasks, and to be implemented in clinical information systems outside the VA environment.

The functionality of the tools provided by EON has been shaped by the tasks they were designed to perform. As shown in Figure 1, an EON application may contain several classes of components:

1. problem-solving modules such as the EON Guideline Interpreter;
2. the ChronusII temporal mediator;
3. a declarative guideline knowledge base that defines all clinical protocols and guidelines in terms of a general guideline model; and
4. client programs that access the services provided by problem-solving modules and by the ChronusII temporal mediator.

The current EON implementation uses Common Object Request Broker Architecture (CORBA) as its client/server infrastructure (8), where the interfaces to the server components are defined using Object Management Group’s Interface Definition Language (IDL), a standard of the International Organization for Standardization (ISO). In addition to being accessed as server processes running in a distributed set up, like any CORBA component, both problem-solving modules and the ChronusII temporal mediator can also be linked into applications as library programs.

EON’s problem-solving modules access the guideline knowledge base through Protégé’s Application Programming Interface (API). Depending on the services a client program provides to end users, a client program may or may not access the knowledge base.

 

EON Problem-Solving Modules

All problem-solving modules in the EON guideline applications (see Figure 1) access a guideline knowledge base consisting of models of clinical guidelines, patient data, and medical concepts that are created in and accessed through the Protégé tool. These problem-solving modules perform the computations necessary to automate specific tasks associated with guideline-directed therapy. The EON Guideline Interpreter, shown in the middle in Figure 1, is one such module. It takes as input a standard clinical guideline description and relevant patient data, and generates as output situation-specific recommendations for the current patient encounter (5).

Other modules developed in the past include a program for determining eligibility for clinical trial protocols. It generates as output the qualitative likelihood that a patient is eligible for the given protocol (10). Another is an explanation-generation component that takes as input patient data and EON’s guideline recommendations, and generates as output explanations based on an argumentation model (6).

(Click to enlarge)

Figure 1 - Architecture of EON guideline applications

 

ChronusII Temporal Mediator

Clinical databases typically contain a significant amount of temporal information, such as when a specimen for a laboratory test is obtained and when a prescription is written and filled. This information is often crucial in medical decision-support systems. Although ad hoc queries that involve time are common in clinical systems, the medical informatics field has no standard means for representing or querying temporal data. Over the past decade, the temporal database community has made significant progress in developing models of time and integrating them into database systems. Much of this research can be applied to clinical database systems.

As part of the EON project, a temporal database mediator has been developed that serves as the conduit between the problem-solving modules and the clinical data stored in an archival patient database (4). Called ChronusII, it extends the standard relational model and the SQL query language to support temporal queries. It provides an expressive general-purpose temporal query language that is tuned to the querying requirements of clinical decision-support systems. When a calling program such as the EON Guideline Interpreter seeks to answer a question such as, “How long has the patient been taking lisinopril at a dose greater than 30 mg per day?”, it passes the query to ChronusII. ChronusII:

1. queries the prescription table in the database for rows of data where the dose of lisinopril is greater than 30 mg;
2. determines whether there are rows of data whose start and stop times meet or overlap and thus can be concatenated; and
3. determines the duration of the concatenated time interval.

ChronusII encapsulates temporal database functionalities, so that each problem-solving module does not have to duplicate these functionalities itself.

 

EON Knowledge Base

EON contains a declarative knowledge base that includes the EON Guideline Model, medical-concept model, and patient data model. This subsection gives a brief overview; and Figure 2 shows a portion of the EON knowledge base as represented in the Protégé editor.

- The EON Guideline Model (2) consists of a set of classes and attributes that describe concepts and relations with which the content of clinical guidelines are formalized. The content of a particular guideline is encoded as instances and as attribute values of these classes. The EON Guideline Model includes classes and attributes for modeling concepts such as the target population of the guideline (eligibility_criteria attribute in Figure 2), goals (goal attribute in Figure 2), and a clinical algorithm that sequences the decisions and actions of a guideline (the screen shot in the upper-right corner of Figure 2). Depending on the nature of the guideline knowledge to be modeled, the EON Guideline Model may allow a clinical algorithm to be specified as a collection of scenarios, decisions to be made in these scenarios, and preferred alternatives at these decision points. Alternatively, when complex sequencing of decisions and actions is required, the model allows a clinical algorithm to make use of additional operators that perform iteration, multiple branching, and synchronization of concurrent threads of execution.

- The medical-concept model defines the particular clinical interventions that are typical for a given area of medicine, and the types of patient findings and patient problems that are most commonly reported in a given medical discipline. The medical-concept model is an explicit component of the EON knowledge base, in the acknowledgement that different classes of health-care providers tend to make different classes of observations about their patients and perform different kinds of patient-care activities. In ATHENA, the medical-concept model consists primarily of comorbidities affecting the management of hypertension and of the classes of antihypertensive drugs that the system may need to cover.

- A patient data model defines the classes and attributes of patient information required by the rest of the system. This simplified view of patient data, created for the purpose of aiding in clinical decisions, supports: (a) a structured data model for representing information related to individual patients, (b) domains for values of attributes in the data model, and (c) logical expressions through which guideline decision-support systems can test the states of the patient.

(Click to enlarge)

Figure 2 - The EON Guideline Model in the Protégé editor. The left panel shows part of the hierarchy of classes in the model. The Management_Guideline class is selected, shown by the violet highlighting. The template slots shown in the right panel include the clinical_algorithm slot. The clinical algorithm represents guideline recommendations in terms of patient scenarios, decision points, and action alternatives. The floating screen shot in the figure shows the hypertension management diagram (an instance of the Management_Diagram class) presented as a Protégé graph.

 

REFERENCES:

1. Musen MA, Tu SW, Das A, Shahar Y. Eon: A component-based approach to automation of protocol-directed therapy. J Am Med Inform Assoc 1996;3:367-388.

2. Tu SW, Musen MA. A flexible approach to guideline modeling. Proc AMIA Symp; 1999. 420-424.

3. Tu SW, Musen MA. Modeling data and knowledge in the eon guideline architecture. MedInfo; 2001. 280-284.

4. O'Connor MJ, Tu SW, Musen MA. The chronus ii temporal database mediator. Proc AMIA Symp; 2002. 434-438.

5. Tu SW, Musen MA. From guideline modeling to guideline execution: Defining guideline-based decision-support services. Proc AMIA Symp; 2000. 863-867.

6. Shankar RD, Martins SB, Tu SW, Goldstein MK, Musen MA. Building an explanation function for a hypertension decision-support system. Proceedings of MedInfo; 2001. 538-542.

7. Tu SW, Musen MA. The eon model of intervention protocols and guidelines. Proc AMIA Symp; 1996. 587-591.

8. Object Management Group. Common object request broker architecture (corba/iiop). In; 2005.

9. W3C. Web services activity. In; 2002.

10. Tu SW, Kemper CA, Lane NM, Carlson RW, Musen MA. A methodology for determining patients' eligibility for clinical trials. Methods of Information in Medicine 1993;32(4):317-325.