Connecting Medical Informatics and Bio-Informatics R. Engelbrecht et al. (Eds.) ENMI, 2005
211
Towards a Generic Connection of EHR and DSS Helma van der Lindena, Sjoerd Diepenb, Gerrit Boersa, Huibert Tangea, Jan Talmona a
b
Dept. of Medical Informatics, University Maastricht, Maastricht, The Netherlands Dept. of Electrical Engineering, Eindhoven University of Technology, Eindhoven, The Netherlands
Abstract Decision Support Systems (DSS) are typically integrated in Electronic Health Record systems (EHR). By removing this integration full reuse of a DSS system is possible. The connection between the EHR and the DSS system should be standardsbased and generic. We intend to demonstrate the viability of this setup by implementing it using PropeRWeb as EHR system, Gaston as DSS system, HL7v3 messages and the SOAP protocol. Keywords: Decision Support Systems, DSS, EHR, standards, HL7, distributed connection
1. Introduction Decision support systems (DSS) are traditionally implemented either as a stand-alone system or as a component that is highly integrated in a specific Electronic Health Record (EHR) system[1, 2]. Since there is a trend to build information systems in general and health information systems in particualr from components there is a need for other approaches to link the EHRs with DSS. Till now combinations of EHR and DSS systems in an open environment hardly exist. Our PropeR project studies the use of decision support combined with an EHR system and focuses on a generic connection in an open environment between these two components. We developed an extendable, generic EHR system, PropeRWeb [3, 4]. This system is currently in use by two groups of users for testing. We are now working on extending the functionality of PropeRWeb by including a generic connection to an independent DSS system. In this paper we will describe the requirements necessary to implement this connection. 2. Design considerations The costs and effort of implementing guidelines in DSS systems are high [5]. Many projects have therefore focused on defining reusable DSS components and/or reusable guideline implementations. Guidelines are typically defined for a specific medical specialism or disease. Some will be used as is, while others will be localized to incorporate the work process of the Section 3: Decision Support and Clinical Guidelines
Connecting Medical Informatics and Bio-Informatics R. Engelbrecht et al. (Eds.) ENMI, 2005
212
implementing institution. Reusable guidelines in local DSS systems (i.e. systems closely coupled to the EHR system that contains the data) have a drawback: the process of installing the guidelines have to be repeated in each institution that wants to use the guideline. The same holds for the management of updates. This is inevitable for the localized guidelines, but the former two categories would benefit from a centralized service where implementation and maintenance are combined. A possible future configuration is shown in Figure 1 as an illustration. There may be a national authority which provides a DSS for drug interactions, while a national institute for cardiology provides a DSS with cardiology guidelines. General practitioners use a regional DSS which contains relevant guidelines, while the hospital also uses a dedicated DSS for guidelines modified to the local situation. National drug interactions guidelines
DSS Cardiology guidelines
GP EHR
DSS GP DSS
EHR
Regional guidelines
Hospital
GP EHR DSS EHR Localized guidelines
GP EHR
Figure 1: Distributed setup of EHR and DSS For a generic connection between an EHR system and a DSS system, each system has to be regarded as a black box, communicating through standards-based messages. When a set of messages is defined and widely adopted, it becomes possible to build a distributed support system that is maintained by various parties. 2.1. Guideline execution Computer interpretable formats for guidelines such as GLIF [6], EON [7], and PROforma [8], basically have a similar structure. A guideline is usually broken down in steps which include multiple decisions. To support a decision the DSS system needs information that can either be formalized, and therefore retrieved from the EHR data source (e.g. lab results), or it cannot be formalized and needs to be requested from the user (e.g. the current patient state). The result of a decision can lead to a message (reminder or alert) to the user1. In current configurations (e.g. GLEE [9] and SAGE [10]) a DSS has direct access to both the EHR data and the user interface. In a distributed configuration however, there is no direct connection between the DSS and the EHR data or between the DSS and the user. All information has to be provided by the EHR system, since it is the only system with access 1
For the sake of simplicity, we will use the term reminder in this article to refer to both reminders and alerts. Section 3: Decision Support and Clinical Guidelines
Connecting Medical Informatics and Bio-Informatics R. Engelbrecht et al. (Eds.) ENMI, 2005
213
to the EHR data and also the only system to communicate with the user. This will lead to three types of messages: messages from the DSS to the EHR requesting data; messages from the DSS to the EHR requesting user information; messages from the DSS to the EHR to remind the user. A generic connection should support this pattern. Since the EHR system is the entry point of new patient data, it is also responsible for initiating the communication with the DSS. 3. Implementation design 3.1. Communication states and channels The communication between an EHR and a DSS starts from the moment decision support is requested for a specific patient. This can either be actively initiated by the EHR user or automatically initiated by the EHR through configuration according to institutional regulations. The communication is ended when the end of the guideline is reached. The latter can be because (1) the last step of the guideline is executed, (2) the user has indicated that no guideline support is necessary or (3) the user has deviated from the guideline and it is not possible to continue execution of the guideline. In all cases the DSS can signal the EHR that the communication is ended. During the communication, multiple messages are exchanged between the EHR and the DSS. A period of communication regarding one guideline for one patient is called a channel. The lifetime of a channel spans the execution of one guideline. The channel is a virtual concept to simplify the administration of the communication.There can be multiple channels open at one point in time. There are two states for a channel: open and closed. The initial state is always closed. The state is changed to open after a request from the EHR to the DSS for guideline support. We call this the “establish channel request”. While the guideline steps are executed one or more message pairs are exchanged (see below). When the DSS finishes processing the last step in the guideline, it notifies the EHR with a “shutdown call”. This changes the state of the channel to “closed”. These state changing messages are responded to only by an acknowledgment. 3.2. Message types Looking at the message types, two situations can be discerned. The DSS sends a request for data. If the data are available in the EHR, they will be retrieved; otherwise the request will be presented to the user for answering. The EHR will send the result as response to the DSS. The DSS can also send a request for user interaction. This is typically a question with one or more predefined answers. A reminder can be modelled as a question with one answer. The EHR will present this question/answer pair to the user and return the selected answer to the DSS. In case of a reminder, either the EHR or the DSS can choose to ignore the answer based on configuration settings. All DSS requests and the user responses are logged in the EHR.
Section 3: Decision Support and Clinical Guidelines
Connecting Medical Informatics and Bio-Informatics R. Engelbrecht et al. (Eds.) ENMI, 2005
214
3.3. Responsibilities In a peer-to-peer connection between two independent systems, there should be a clear definition of the responsibilities of each system. In our approach, the overall responsibility for the communication lies with the EHR system. It is the only system with access to the clinical data and the applicable authorization rules. It also maintains the user interface. The EHR system should initiate the communication with the DSS, handle requests for data and user interaction, and log all activity pertaining to this communication (i.e. the requests from the DSS as well as the user responses). 4. Requirements 4.1. Message content The communication messages must have a standard format and must use a terminology and domain model that is either the same for the EHR and the guideline or can be mapped to the terminologies used in either system. HL7v3 provides a format and a method to define these messages [11]. HL7v3 messages require definition of coding schemes and other terminological origins. This made us decide to move the terminology mapping to the EHR system, i.e. the EHR system is responsible for mapping the HL7v3 messages to the internal representations. Although there are currently no specific messages defined for this communication, HL7v3 specifies how to define such messages based on the domain model. This allows us to define our own messages with a reasonable guarantee that the implementation is future-proof, i.e. only the structure of the message itself will be subject to change, not the overall structure. 4.2. Requirements for the EHR Following the design explained above, an EHR system capable of communication with a DSS needs to be able to: x x x x x x
handle the communication, i.e. it needs a communication interface; map the message domain model to the internal domain model; map terminology to internal terminology; handle requests for user interaction; log the actions resulting from the communication; (in future) handle multiple requests from different DSS systems.
4.3. Requirements for the DSS The DSS system needs to be able to: x handle the communication, i.e. it needs a communication interface; x map the message domain model to the internal domain model; x (in future) handle multiple requests from different EHR systems; 5. Current state The approach outlined, is currently under development using the PropeRWeb EHR system and the Gaston guideline execution engine [12]. As guideline we use a treatment protocol
Section 3: Decision Support and Clinical Guidelines
Connecting Medical Informatics and Bio-Informatics R. Engelbrecht et al. (Eds.) ENMI, 2005
216
8. References [1] Kawamoto K, Houlihan CA, Balas EA, Lobach DF. Improving clinical practice using clinical decision support systems: a systematic review of trials to identify features critical to success. Bmj 2005;330(7494):765. [2] Shiffman RN, Liaw Y, Brandt CA, Corb GJ. Computer-based guideline implementation systems: a systematic review of functionality and effectiveness. J Am Med Inform Assoc 1999;6(2):104-14. [3] van der Linden H, Tange H, Talmon J, Hasman A. PropeR revisited. Stud Health Technol Inform 2003;95:346-51. [4] van der Linden H, Boers G, Tange H, Talmon J, Hasman A. PropeR: a multi disciplinary EPR system. Int J Med Inform 2003;70(2-3):149-60. [5] Johnson P, Tu S, Jones N. Achieving reuse of computable guideline systems. Medinfo 2001;10(Pt 1):99103. [6] Peleg M, Boxwala AA, Ogunyemi O, Zeng Q, Tu S, Lacson R, Bernstam E, Ash N, Mork P, OhnoMachado L, Shortliffe EH, Greenes RA. GLIF3: the evolution of a guideline representation format. Proc AMIA Symp 2000:645-9. [7] Musen MA, Tu SW, Das AK, Shahar Y. EON: a component-based approach to automation of protocoldirected therapy. J Am Med Inform Assoc 1996;3(6):367-88. [8] Fox J, Johns N, Rahmanzadeh A. Disseminating medical knowledge: the PROforma approach. Artif Intell Med 1998;14(1-2):157-81. [9] Wang D, Peleg M, Tu SW, Boxwala AA, Ogunyemi O, Zeng Q, Greenes RA, Patel VL, Shortliffe EH. Design and implementation of the GLIF3 guideline execution engine. J Biomed Inform 2004;37(5):30518. [10] Ram P, Berg D, Tu S, Mansfield G, Ye Q, Abarbanel R, Beard N. Executing Clinical Practice Guidelines Using the SAGE Execution Engine. Medinfo 2004;2004:251-5. [11] anonymous, Health Level 7 Ballot 8 (only available to members), http://www.hl7.org, 2004, Last accessed: Jan 2005 [12] De Clercq PA, Blom JA, Hasman A, Korsten HH. GASTON: an architecture for the acquisition and execution of clinical guideline-application tasks. Med Inform Internet Med 2000;25(4):247-63. [13] HOVON, HOVON 42 AML / SAKK, http://www.hovon.nl, 2001, Last accessed: Jan 2005 [14] anonymous, Web Services Activity site, http://www.w3.org/2002/ws/, Last accessed: Jan 2005 [15] Gudgin M, Hadley M, Mendelsohn N, Moreau J-J, Nielsen HFN, SOAP Version 1.2 Part 1: Messaging Framework, http://www.w3.org/TR/soap12-part1/, 2003, Last accessed: Jan 2005 [16] He H, What is Service-Oriented Architecture?, http://webservices.xml.com/pub/a/ws/2003/09/30/ soa.html, 2003, Last accessed: Jan 2005
Address for correspondence H. van der Linden Dept. Medical Informatics, University Maastricht POBOX 616 6200 MD Maastricht The Netherlands
[email protected]
Section 3: Decision Support and Clinical Guidelines
