Using ESB and BPEL for evolving healthcare systems towards SOA

Transcription

1 ehealth Beyond the Horizon Get IT There S.K. Andersen et al. (Eds.) IOS Press, Organizing Committee of MIE All rights reserved. 747 Using ESB and BPEL for evolving healthcare systems towards SOA D. PAPAKONSTANTINOU, F. MALAMATENIOU and G. VASSILACOPOULOS Department of Digital Systems, University of Piraeus, Piraeus , Greece Abstract. Healthcare organizations often face the challenge of integrating diverse and geographically disparate information technology systems to respond to changing requirements and to exploit the capabilities of modern technologies. Hence, systems evolution, through modification and extension of the existing information technology infrastructure, becomes a necessity. This paper takes a process perspective of healthcare delivery within and across organizational boundaries and the presents a disciplined approach for evolving healthcare systems towards a service-oriented architecture using the enterprise system bus middleware technology for resolving integration issues and the business process execution language for supporting collaboration requirements. Keywords. Evolution; healthcare systems; SOA; ESB; BPEL; standards; EMR. Introduction Healthcare organizations often invest significant resources in the development of large and complex information systems that must be modified and extended to respond to changing requirements, in addition to capitalizing on modern technologies [1]. Technologically innovative efforts of the past have often resulted in the development of disparate, incompatible and heterogeneous systems based on the traditional transaction processing paradigm rather than on supporting business processes. Thus, the integration of diverse and disparate information systems with emphasis on communication and collaboration is a challenge often faced by healthcare organizations [1,2]. To meet this challenge, a systems evolution process must be designed and implemented with the objective to achieve interoperability among diverse systems that may have been developed at different times and with different technologies, and to support a process view of the healthcare delivery context. System evolution is an iterative and incremental process directed toward long-tem user needs and operating on legacy or existing systems [3]. Having a certain direction, evolution differs from an unconstrained series of small modifications that may have little direction over long term. It also differs from systems development that has a specific direction or unifying intent but can start from scratch. Thus, the complexity and volatility of requirements for large-scale healthcare systems and the large in-place investments make evolution a necessity. In most cases, the decision for system evolution hinges on whether the existing system architecture and functions fit current and anticipated requirements of the

2 748 D. Papakonstantinou et al. / Using ESB and BPEL for Evolving Healthcare Systems Towards SOA problem domain. Thus, in evolving existing systems, most weight must be placed upon the need to explore the systems operating context, develop this context where necessary and make the target system serve it. When this context is described in terms of its constituent business processes and interactions among them, as is often the case, the evolution process focuses on designing a system in terms of how it supports business processes. When an integrated, process-oriented healthcare system is envisaged, developers are required to first solve communication-level integration issues, ensuring that existing systems using different transport protocols and data formats can exchange information, and then to decide how existing systems can interact to support business processes [4]. Along these lines, this paper presents a healthcare systems evolution process that is directed towards the Service-Oriented Architecture (SOA) philosophy using the Enterprise Service Bus (ESB) middleware and the Business Process Execution Language (BPEL) to support systems integration and collaboration. 1. A system evolution process The drive in healthcare to contain cost and improve quality has called for a transition from the institution-centered to consumer-centered care, requiring increased cooperation and collaboration among functional units. This creates an impetus for healthcare organizations to evolve their existing systems so that to enable integrated access to patient information irrespective of the location it resides. SOA, as a set of guidelines for integrating disparate systems, represents a view as to how business and technology architectures can be integrated and how composite application functionality is delivered to a portal or Web browser. Hence, SOA constitutes a promising evolution intent for healthcare systems since technological heterogeneity is more the rule than the exception in most healthcare organizations [1,2,3]. SOA is a concept that enables end-to-end application integration across and among healthcare providers, and provides a flexible model that permits the healthcare organizations to respond to environmental changes quickly and efficiently. It constructs applications from the ground up, taking one or more services and connecting them to form a complete, cross-functional, end-to-end healthcare process such as "medical order". This architectural style is dependent on the Internet and is a combination of business architecture, application architecture and software architecture. In addition, it allows users to rapidly build, reuse and reconfigure automated workflow processes (services) as healthcare priorities, regulatory requirements or environmental conditions change [5]. Hence, SOA responds to the need of exchanging medical information between diverse healthcare systems on the web and can form an ideal architectural basis for evolving existing healthcare systems [6,7,8]. A SOA environment needs a robust and secure infrastructure that can easily combine and re-assemble services to meet changing requirements without disruption and can span new service-enabled applications as well as existing [9]. ESB meets the connectivity needs of applications and services, by matching and routing messages between them, and makes services available for broad access and reuse [9,10]. An ESB operates as a bus that connects the various resources, ensures that services are exposed over standards-based protocols (e.g. SOAP, HTTP and JMS), enabling any client to contact them directly and to perform transformation and routing of service requests. ESB increases system performance, thus enabling the development of virtual healthcare

3 D. Papakonstantinou et al. / Using ESB and BPEL for Evolving Healthcare Systems Towards SOA 749 applications as a connected, process-based set of independent services that exist inside or outside the healthcare organization. Thus, ESB facilitates cross-platform interoperability, unifies message oriented, event driven and service-oriented approaches for integrating applications and services, and, hence, provides a technological basis for evolving existing healthcare systems into an integrated district-wide environment [9,10]. In a federated healthcare environment (i.e. one in which services cross organizational boundaries) or in a distributed healthcare environment (i.e. one in which service communications bridge geographic boundaries) it is critical that data, events and replies are directed to the right place at the right time without management overhead. To this end, an ESB, besides resolving integration issues, provides the capability of orchestrating healthcare activities into processes, typically via BPEL [4]. BPEL provides a standard, XML-based platform that expresses a business process s event sequence and collaboration logic, whereas the underlying services provide the process functionality. Hence, in a SOA approach that aims at supporting healthcare processes, BPEL can be used to implement intra and inter-process collaboration. Based on the above, a system evolution process towards a process-based SOA consists of the following stages: i. Develop a process description of the healthcare organization, or part of the organization, under review and specify process support requirements, including collaboration and cooperation requirements. To this end, generate a graphical representation of how and in what order process activities are executed as part of a human workflow. ii. Map existing system applications onto the process models developed to compare what is available with what is needed. From this comparison, identify which applications to keep, which to modify or upgrade, which to create or develop and which to discontinue so that the target system meets the requirements. Then, develop old and new applications as services that are iii. assigned to process activities. Describe services into the BPEL engine, that generates an XML file which tells the message router (service bus) the rules associated with each service, and use ESB as a message router and rules engine that performs validations on messages, transformations on data and ensures message delivery from one system to the next, and eventually the delivery of information to the user s portal or browser. Thus, a message is simply the packet of data requested by any service. The above approach suggests an evolution direction where a SOA implemented on an ESB/BPEL software infrastructure becomes a vital issue in supporting relationships such as those which exist between the healthcare systems and their operating context, relationships between roles at work and relationships between parts of the systems which are expressed as services. This paper focuses on the third stage. 2. Motivating scenario To illustrate the technical aspects of the above approach to systems evolution, a sample integration project is described which is concerned with the automation of crossorganizational healthcare processes spanning a health district. Typically, a health district consists of one district general hospital and a number of peripheral hospitals

4 750 D. Papakonstantinou et al. / Using ESB and BPEL for Evolving Healthcare Systems Towards SOA and health centers. As patient referrals are usually made among various healthcare providers within a district, there is a need to ensure that access to integrated patient information by authorized users is enabled when and where needed. Thus, the sample process considered here is concerned with patient referrals from health centers to hospitals and it involves three separate systems based on different technologies: Radiology Order System (ROS): a system that handles medical order processing among healthcare organizations and is already exposed as a web service. Radiology Report System (RRS): a system that uses a Java Message Service (JMS) queuing system for communication. Electronic Patient Record (EMR): a customized system implemented in Corba. Suppose a healthcare process that begins with a health center s physician request for a radiological procedure on one of his/her patients and ends with issuing a radiological report by a radiologist. In this process two functional units are involved: the health center and the radiology department of a hospital. On performing the radiological procedure requested, the radiologist accesses the relevant part of the patient record and issues a radiological report, incorporating both the radiological images and the associated assessment, which is sent to the requesting physician. Figure 1 shows a high-level view of the healthcare process concerned with radiology orders. Figure 1. A high-level view of the healthcare process concerned with radiology orders 3. System architecture The system architecture described here delineates the intent of an evolution process directed toward a SOA implementation on an ESB/BPEL software infrastructure to enable access to integrated patient information during the execution of healthcare processes spanning a health district. To this end, the sample applications mentioned in the previous section are synthesized within a SOA so that they serve as a unified whole. Uniting these applications into business processes involves solving various integration issues by exposing each application as a web service and, then, using BPEL

5 D. Papakonstantinou et al. / Using ESB and BPEL for Evolving Healthcare Systems Towards SOA 751 to combine the services into business processes. Figure 2 shows a schematic view of the architecture s four main components. These are: the existing IT infrastructure; the ESB which includes adapters to expose existing systems and provide transport connectivity; the BPEL engine that is capable of interpreting and executing business processes described in BPEL by orchestrating existing services and the services developed or created from the existing systems. A fifth component may also be introduces to represent an authorization server that manages who, in terms of role, can perform the various BPEL activities, such as invoking a service or assigning a new value in an XML document. In the context of the proposed architecture, the ROS is already implemented as a web service and, hence, no further development is required. Additional work is only required for exposing the two remaining systems as services. Specifically, an ESB allows clients to access the services through HTTP (or other protocols) and forwards client requests to the RRS via JMS. In this context, new message formats are defined using a CDA-based XML Schema and transformation rules are created to convert to the existing application s format. This results in a new ESB-based web service for RRS, which receives requests and transforms them before placing them in the JMS queue and communicates with other web services via BPEL. Figure 3 shows the BPEL constructs that were added to WSDL files for this purpose. The PartnerLinkType defines the role of each partner in a healthcare process and ties it to a given PortType (i.e. the WSDL term for interfaces). In this example, the presence of a single role implies a clientserver relationship. The figure also shows the RadProcCd property definition and a property alias that describes how to extract that property s value from the authentication message. Figure 2. A service-oriented architecture implemented on ESB and BPEL <plnk:partnerlinktype name="rrslinktype"> <plnk:role name="serviceprovider"> <plnk:porttype name="tns:rrs "/> </plnk:role> </plnk:partnerlinktype> <bpws:property name="radproccd" type="xsd:string" /> <bpws:propertyalias messagetype="tns:authenticate" part="request" propertyname="tns:radproccd " query="/xsd1:emrdetails/radproccd" /> Figure 3. Example of BPEL s WSDL extensions.

6 752 D. Papakonstantinou et al. / Using ESB and BPEL for Evolving Healthcare Systems Towards SOA Finally, the Corba-based EMR must be addressed and to this end an ESB wizard can be used to automatically create the web service by designing the interface in WSDL and create the web service from there. The service implementation acts as a client to the Corba system directly or though an ESB-generated web service interface. This architecture is compatible with the EN Health Informatics Service Architecture (HISA) standard, which aims at providing a reference model for health care IT services, facilitating the building and purchasing of interoperable systems [11]. Thus, healthcare information is clearly separated from the applications and can be made available where and when needed to the various modules of the information system. 4. Concluding remarks Healthcare organizations are faced with the challenge to improve healthcare quality, preventing medical errors, reducing healthcare costs, improving administrative efficiencies, reducing paper work and increasing access to affordable healthcare. To these ends, innovative health information technologies are often used in order to shift focus from traditional transaction processing into communication and collaboration. This paper describes an approach to evolving existing systems towards a certain direction, namely, a SOA-based solution which is based on the ESB middleware technology to resolve integration issues and BPEL to orchestrate individual healthcare activities into healthcare processes. Thus, through the evolution process presented in this paper, communication-level integration issues are solved first to ensure that all partial systems (existing and new) using different transport protocols and data formats can exchange information and, once these issues are resolved, the various IT systems are made to interact to support healthcare processes. Hence, the result of evolution is an interoperable process and service oriented healthcare information system. References 1. Lenz R, Kuhn KA. Towards a continuous evolution and adaptation of information systems in healthcare. Intl J of Med Inf 2004; 73: Huizen Van G and Backman AJ. SOA: First Principles. SONIC software, Ferrara FM. The CEN healthcare information systems architecture standard and the DHE middleware A practical support to the integration and evolution of healthcare systems. Intl J of Med Inf 1998; 48: Pasley J. How BPEL and SOA are changing web services development. IEEE Int Comp 2005; Erl T. Service-Oriented Architecture (SOA): Concepts, Technology, and Design. The Prentice Hall Service-Oriented Computing Series from Thomas Erl Bloomberg J. Service-Oriented Architecture: why and how?. Zapthink Whitepaper, Fisher M and Jendrock E. Chapter 1: Introduction to web services. Java Web Services Tutorial. Sun Microsystems, Schulte R. SOA is changing software. Gartner Research, Davidsen L. Building an ESB without limits. IBM Software Workgroup, Balani N. Model and build ESB SOA frameworks - Adapt service-oriented architectures for easy application integration. IBM DeveloperWorks, Bott OJ. European Standards for the Electronic Health Record. ehealth benchmarking