Research Challenges for Achieving Healthcare Business Process Interoperability

Transcription

1 International Conference on ehealth, Telemedicine, and Social Medicine Research Challenges for Achieving Healthcare Business Process Interoperability Dimitrios Alexandrou, Gregoris Mentzas Information Management Unit, Electrical and Computer Engineering, National Technical University of Athens, Athens, Greece Abstract - E-Health systems interoperability constitutes one of the main challenges of the IT society. E-Health interoperability will not occur without a shared policy and a process framework that will support appropriate business collaboration models and provide a sustainable environment in which interoperable solutions can be created, deployed, and managed. Coordinated business interactions require a common understanding of business function even though alternative delivery mechanisms and channels may be employed. In the healthcare context, a patient visits various organizations or units within organizations to get proper treatment. The role of healthcare workflow-management by use of IT is to adjust the contributions of those organizations or units in terms of effective service provision, appropriate timing, and best quality. Workflow management technology can play an important role, for it helps to organize, automate and improve business processes. Supporting clinical processes with information technology requires workflow specification (i.e., the identification of tasks, procedural steps, input and output information, people and departments involved, and the management of information flow according to this specification). Keywords: business process interoperability; healthcare; coordinated business process; I. INTRODUCTION The recent push for healthcare reform has caused healthcare organizations to focus on ways to streamline their processes in order to deliver high quality treatment while at the same time reducing operating costs. This has precipitated a review and upgrade of clinical and administrative protocols and the increased utilization of information systems to improve the efficiency of certain processes. On the other hand, healthcare s complex business processes can be difficult to manage for the following reasons: Information required to make clinical decisions may not be readily available or exists in many different forms. Assembling this information -- if at all possible to do so -- takes significant and precious time. Bad clinical decisions may be made because critical facts never reached the decision maker. Business processing rules may not be applied consistently because of inexperience or poor training. Transition of work from one stage of the business process to another may be done slowly, incorrectly, or not at all -- causing delays, errors and possible mistreatment of the patient. Difficulties arise in determining the status of tasks in the business process. Changing business processes may require major retraining and lengthy learning curves. Some of these difficulties can be traced back to the heterogeneous nature and fragmentation of healthcare organizations. Professionals require a certain degree of autonomy, whilst workflow management requires a certain degree of standardization. Organizations or units need goals that fit to their specific practice, workflow management requires cooperative goals, or at least, goals that do not conflict. Also, standardization is needed to make full mutual adjustment of organizations possible, even though such standardization may unnecessarily complicate the way of working. As a result, a dedicated business transformation may be necessary. Since processes are fundamental building blocks of an organization s success, healthcare providers have to redefine their boundaries and make strategic alliances so to be able to cope with the changes in the healthcare provision market. Technologies that focus on process management and process optimization constitute good candidates for assisting healthcare organizations fulfill their corporate vision. As the complexity -- and overhead costs -- of delivering healthcare services have increased, the importance of utilization of workflow management technologies is more than evident. In this paper we present our proposition concerning the business interoperability between large IT systems of healthcare organizations so as to achieve a seamless treatment environment. Moreover, we present an indicative set of research challenges that have to be /09 $ IEEE DOI /eTELEMED

2 confronted in order to achieve the desired interoperability. The rest of the paper is organized as follows. Sections 2 and 3 refer to workflow management in Healthcare domain and to technology trends in the area. Moreover, section 4 presents a harmonized (desired) use case. In section 5, we describe a real-life scenario that is further modeled by our approach in section 6. Finally, section 7 concludes the paper combined with our thoughts concerning research challenges in the domain to be achieved. II. WORKFLOW MANAGEMENT PRACTICES IN HEALTHCARE Clinical processes are characterized by a high degree of communication and cooperation among physicians, nurses, and other groups of personnel. An information system should support these processes by enabling a seamless information flow between different participants and different locations. Taking under consideration the rapidly changing healthcare environment and requirements, an ideal information system should be capable of incrementally evolving according to the users needs. Supporting clinical processes with information technology requires workflow specification (i.e., the identification of tasks, procedural steps, input and output information, people and departments involved, and the management of information flow according to this specification). Currently, well-structured business processes are increasingly supported by Workflow Management Systems (WfMS) as a means to streamline, automate, and re-engineer business processes. There are many workflow software products that adequately support relatively simple processes, such as document management, form processing, and imaging. However, such approaches are not yet widely accepted in health information systems, partly because they fall short in meeting the challenges of healthcare processes, which are mission-critical and often complex, dynamic, largescale, and QoS-based, and partly because integrating autonomous, independently developed applications in healthcare takes a large amount of effort, whereas such applications tend to be technically and semantically incompatible. Traditionally, healthcare processes have been managed using limited forms of workflow. Some examples of these are clinical and administrative protocols. However, these protocols have remained limited in their utilization, in part because developers have rarely incorporated both clinical and administrative activities into one comprehensive care protocol. This lack of integration hinders the delivery of care, as the effectiveness of protocols is often dependent on many administrative tasks being properly executed at the correct time. Consequently, many healthcare organizations have turned to workflow management techniques to help improve the efficiency of their treatment processes. The trend toward computerizing business processes has led to a large number of commercially available information systems, some of which specifically target the healthcare sector. Different approaches for process support in health information systems are currently under discussion. The most comprehensive approach for process support is offered by dedicated Workflow Management Systems (WfMS). The approach of general purpose WfMS, which facilitate existing applications to be linked together into global processes controlled by an external workflow engine, is conceptually mature and successful in many application areas. However, this approach does not yet play a significant role in health information systems, one reason being that existing clinical applications often come with built-in workflow functionality, which is not conform to standards for interoperating workflow engines as proposed by the Workflow Management Coalition [5]. Today s healthcare processes require capabilities for mission-critical workflow support and enterprise integration. Indispensable features include: the seamless deployment over networked and heterogeneous server platforms; the rapid deployment of applications; the ease of integration of legacy/existing applications; the high scalability and performance; the specification, analysis, and monitoring of quality of service metrics; and the adaptation to changes. Reliability is an inherent part of the WfMS infrastructure; it includes support for error handling and recovery by exploiting transaction management features. A well-defined hierarchical error-model is used for capturing and defining logical errors, and a recovery framework provides support for the detection and recovery of workflow system components in the event of failure. The system also supports a dynamic change interface, QoS management, and a case-based reasoning subsystem to effectively handle exceptions. III. TECHNOLOGY TRENDS OF WORKFLOW MANAGEMENT In terms of integration and interoperability, a Web Services Architecture (WSA) environment provides the core architecture that allows any two Web applications to interoperate with each other. To assure that business processes can meet their specific objectives automatically utilizing essential human labor only, Business Process Interoperability (BPI) takes a 59

3 service-oriented architecture (SOA) approach [6], which focuses on the processes themselves, rather than on the technologies required to automate them. SOA is an effective way to address the problems caused by information silos. SOA makes practical sense since organizations cannot be expected to replace or modify their current enterprise software to achieve BPI, whereas they utilize a great many legacy software systems, custom applications, manual procedures and paper forms. Representations of business processes (including registries, information models, messaging, etc) that predates Web Services will be based on state-of-the-art specifications [4]. Also, on standards for web services that describe the messages going in and out of a service as well as data types and standards for Web Services Addressing [7] as well as Web Service Orchestration, i.e. invocation of Web Services under the control of a central workflow engine [3], [8] and Web Service Choreography, i.e. specifying behavior of autonomous services so together they achieve a desired goal. Currently, there are technological solutions that enable you to transform your core business processes with a new breed of "out-of-the-box" service-oriented business applications (SOBAs) called Business Process Applications (BPA). However, with the exception of some recent developments of Web Services, such as BPEL4WS, these technologies mostly function as interfaces to existing IT systems and do not lend adequate support to the business processes. Therefore, a new type of process-oriented integration architectures have been developed, referred to as process managers (sometimes business process management systems, process brokers, or process automation systems), which closely reflect the business processes (in healthcare: healthcare processes). Finally, in the context of IHE, which is an important initiative strongly supported by the industry, what is sorely missing is business process support in IHE XDS. Indeed, in the healthcare domain, there is a wide array of shared care delivery collaborative processes such as the placing and tracking of orders (e.g. drug prescriptions, radiology orders, etc.). Although, through a separate effort, IHE has also defined inter-departmental Workflow Profiles, these have not been integrated to XDS Profile. Hence, there is no way to track the processes in XDS and the resulting clinical documents are manually inserted into the registry/repository. There has been an effort to describe the implementation of an enhanced IHE architecture integrating ebxml Business Processes, IHE Workflow Profiles and the IHE XDS architecture [9]. The choice of using ebxml Business Processes (ebbp) in IHE XDS is important for the following reasons: For collaborative, inter-departmental or inter-enterprise healthcare business processes, the choreography of multi-party interactions as well as the collaboration rules and constraints among all the interacting parties of the healthcare enterprise should be provided. To express such multi-party collaboration among departments in an enterprise or between enterprises, a choreography language like Web Services Choreography Definition Language [10] or ebxml Business Processes (ebbp) is needed; business process orchestration languages, like BPEL, falls short to satisfy this need. IV. HARMONIZED USE CASE After determining the goal for healthcare business process interoperability, a harmonized use case is presented, which describes the necessary actors/services and steps to achieve the goal. This harmonized use case will avoid defining technical approaches and policies more than necessary. The harmonized use case is intended to provide the basis while determining the research challenges in the area of business process interoperability for e-health applications. During the structuring of the harmonized use case, the required intelligent interoperability facilitated by Business Process management with various trading partners - healthcare providers, intermediaries, thirdparty administrators (TPAs), insurance organizations, financial services, care management partners was taken under consideration. The vision is to establish a healthcare information exchange (HIE), namely an IT service delivery infrastructure that provides pertinent and timely transactions information between organizations across the healthcare value chain. This HIE will allow to securely receive electronic "packages" from registered trading partner's information systems, open and validate them, transform and route them, enrich, repackage and deliver them. Claims and exception management can be automated, resulting in significant administrative efficiencies including increased retention and new business, as well as lowered costs and risk. Thus, this use case is relevant to five (5) different scenarios that have been identified: Scenario 1: Patient performs laboratory examinations prior to Medical Treatment At the beginning of the harmonized use case, a patient provides blood sample, during laboratory examinations, prior to being admitted to the Hospital A for further medical treatment. Laboratory results will be validated and sent to Hospital A. Results and possible diagnosis will be part of the patient s clinical 60

4 status and will assist the selection of the appropriate Clinical Pathway. Scenario 2: Patient receives medical treatment in Healthcare Organization A The patient is admitted to Hospital A, and a Clinical Pathway is selected and executed. A healthcare expert defines in detail the procedure to be followed concerning the execution of the specific clinical pathway, accesses patient medical record, prescribes medication, checks patient s health status and, finally collects all the required information about the results of the treatment for the patient and produces statistics. At some point of the clinical pathway, healthcare expert requires a CT examination that will be performed in Hospital B. Scenario 3: Healthcare Organization A creates Collaborative Medical Summary The Healthcare expert prepares a medical documentation (Collaborative Medical Summary) containing the most relevant information, in order for the patient to be transferred to a different institution (Hospital B) for the specific diagnostic procedure (CT). Collaborative Medical Summary contains next to other information physical examination findings, labresults, diagnosis, therapeutic propositions and requests for further examinations concerning a specific set of problems of the patient. The attending physician includes the appropriate clinical request for further examination, attaches privacy consent to the summary and signs it. Scenario 4: Patient receives CT examination in Healthcare Organization B during Clinical Pathway The patient arrives at the imaging facility (Hospital B) and is identified by the medical imagist. Medical imagist validates the request, consults the Collaborative Medical Summary, realizes the necessary images and writes the examination report. Medical imagist sends the report to the attending physician in Hospital A. Scenario 5: Reimbursement Procedure Patient asks the insurance consultant to perform the Reimbursement procedure for all the above clinical acts. Following is the harmonized use case that we have described (Figure 1). In the harmonized scenario presented in the following figure, workflow management technology helps to organize, automate, orchestrate and improve business processes. It begins by analyzing work processes in order to divide them into component tasks. Defining each task includes specifying who does the work, the information needed, the business rules for how to perform the task, the potential outputs, and who performs the next step in the business process. Once tasks have been defined, workflow management technology can be used to automate the process. The goal is to meet the unique needs of the user without compromising the user s ability to easily adapt to the revised process. Consider the following attributes of an automated and optimized process: It assembles the information needed to perform each task typically holding this information in a case or folder that moves through the process itself It provides guidance for performing each task according to the correct business rules It routes the task, along with the information needed to perform it, to the appropriate person It divides certain tasks into parts or parcels, coordinating the work of multiple people on the various parts or parcels, and then reassembles the parts or parcels, speeding up the business process For a successful support of cross-organizational business processes, interoperability has to be captured beyond current protocol-based approaches developed in the Web Services stack. All collaboration between organizations is performed following a high-level business goal. For the understanding of interoperability it is important that managers and process owners are able to capture this goal by modeling interaction from a high-level business point of view [2]. Collaboration Business Processes (CBPs) have to be modeled capturing the overall business context of collaboration and have to be linked up with private processes and resources without exposing private information. The methodology that we propose aims at providing a suitable solution in this context. Methodology consists of three aspects [1]: A. Structuring complex cross-organizational business processes by applying swimlanes B. Introducing views as a layer of abstraction above private processes called views. The approach allows for high level modeling of CBPs, enabling a scalable exposition of internal processes C. Introducing Business Process Definition Metamodel (BPDM) as a modeling methodology based on UML supporting the view concept For a successful integration, business partners have to model their interaction from a high-level business point of view, independent of their underlying implementation. On the other hand, they have to link their existing internal processes and resources to the agreed interaction model and offer process-oriented interfaces to the outside world. An important requirement in this context is to enable organizations to conceal its private processes to preserve autonomy and privacy. White-box exposition of their internal 61

5 knowledge, such as internal process steps, data, and resources cannot be expected. Figure 1. Overall View of the Use Case Actors and Services However, successful implementation of crossorganizational business processes requires information sharing and exposing parts of the internal processes. The level of exposure can vary, and contracts with partners as well as trust building may lead to revealing more internal information as the business relationship evolves. A particular interaction may require involved partners to adapt for the purpose of the communication. This adaptation cannot necessarily be reflected in the partners' private (internal) business processes without inflicting their ability to interact with other partners in a different context. The decision about how much knowledge will be shared and which insight into the internal process is given is clearly business-driven and made by process owners or managers. Managers and process owners decide about the context of the interaction with their business partner and define the first high-level view of the CBP. This requires modeling techniques that support modeling of partner interaction from a business viewpoint and that allow for model-based information hiding and exposing, without involving coding. It is the intent that a process modeler can leave a private process unchanged and relate it with a process-based interface which can be adapted to interact in a specific collaboration. The main idea of view-based modeling of CBPs is to introduce process views as an additional layer above the private processes of an organization [11]. Process views provide a process-oriented interface between business partners. Private processes are only known to their owning organization and not exposed to the outside world. Process views are an abstraction of the private processes, containing information that needs to be published for the purpose of a specific interaction. From a structural perspective, private processes consist of (private) tasks and (private) dependencies, whilst process views consist of view tasks (synonym: virtual tasks) and view dependencies (synonym: virtual dependencies). Several tasks of a private process can be combined to one view task. [12][13] V. REAL-LIFE SCENARIO Mary Brown having health problems decides to visit a private diagnostic centre to have some laboratory tests. She visits the diagnostic centre and has a blood test. The diagnostic centre has a repository containing the Electronic Health Records and the Health History of its patients. Once the blood test is 62

6 performed, a Clinical Decision Support System provides additional support to the Medical Doctor to diagnose the health problem of Mrs. Brown. After the laboratory test results, it is decided that Mrs. Brown should be treated in a hospital. Her electronic health record, accompanied with the last results of the blood test, is forwarded to the corresponding hospital. Once Mrs. Brown arrives to the hospital, her personal health data are already stored in the repository of the hospital. Her admission is performed by the Hospital Information System which is responsible for the whole treatment procedure. Moreover, her health dataset is being utilized by the Clinical Pathway module of the hospital. The Clinical Pathway selector is responsible for the selection of the appropriate pathway of treatment according to her lab tests and results. The Clinical Pathway execution is performed and the Monitor module is being used in order to ensure the improvement of Mrs. Brown s clinical status and alert the Medical Doctors once any of the defined thresholds are exceeded. During the treatment procedure, Mrs. Brown needs to take a Computer Tomography. Since the hospital she is admitted to, does not have the appropriate equipment, she is moved to another hospital so as to take the examination. Once the CT is performed, the medical images are transferred to the hospital she is admitted, electronically and securely in order to be utilized by her medical doctors. In order to achieve that, cross-enterprise workflow management is established between the hospitals concerning the transfer of medical data. Finally, once the treatment finishes and Mrs. Brown s health status improves she is able to leave the hospital. Once she is out, she begins the procedure of her reimbursement of the hospitalization costs. She visits her insurance company and presents the invoices of the hospital she has been admitted. The software modules of the insurance company check her eligibility, perform the reimbursement estimation and finally generate the reimbursement report. Mrs. Brown is reimbursed and healthy again. intra-organizational business processes inside a healthcare entity. View Process The View Process of each healthcare entity constitutes the interface of its internal business processes to the outer world so as to interact with the external applications in a seamless and transparent to the end users way. VI. SCENARIO MODELING The above-mentioned example scenario is comprised by specific workflows and business processes on intra- and inter-organizational level. As depicted in Figure 2, the specific approach [1] introduces the following concepts: Cross Organizational Business Process Bus The specific element constitutes the main business process that is executed during the specified scenario. The Business Process Bus contains the steps of the example scenario. These steps are parts or triggers of 63

7 Figure 2. Cross-organization business process interoperability Private Process The Private Process contains all the appropriate steps required in order to implement internal workflows. Private Process is triggered by View Process and is executed inside the entity. The diagram at the right, presents the interacting entities during the example scenario. These entities are the following: 1. Diagnostic Centre: The Diagnostic Centre is the first Healthcare Provider entity that the patient interacts with. The Diagnostic Centre is able to perform laboratory examinations and some kinds of medical imaging tests. The patient visits the Diagnostic Centre and takes his/her initial examinations so as to be able to diagnose possible causes of his/her health problem. Depending on the diagnosis, the patient should (or should not) be admitted in a hospital for further medical treatment. 2. Hospital A: The Hospital A Healthcare Provider entity is the organization that is responsible for the provision of the required medical treatment to the patient. The hospital encapsulates the necessary info- and infrastructures so as to offer the appropriate medical treatment. Moreover, Hospital A usually participates in a cluster of collaborating hospitals that integrate parts of their infrastructures and human resources so as to offer the complete treatment. 3. Hospital B: The Hospital B Healthcare Provider entity encapsulates the same services as Hospital A. 4. Insurance Organization: The Insurance Organization entity is responsible for the provision of insurance services. The insurance organization interoperates with the hospitals in a seamless and transparent way so as to ensure the financial coverage of the appropriate part of the expenses of the medical treatment. According to the approach followed, there are 3 layers of processes. Firstly, the Cross-Organizational Business Process Bus includes the steps that the patient follows so as to have the required medical treatment. Moreover, each entity comprises a View Process layer that provides public process interfaces to other entities. Finally, each entity contains a Private Process layer that includes the internal parts of its business processes. VII. CONCLUSIONS - RESEARCH CHALLENGES The proposal presented for healthcare business processes interoperability imposes specific technological and scientific achievements so as to be widely accepted and utilized. These achievements will be reached once the scientific community confronts the following research challenges: Improved efficiency, standardization, reliability, and availability of comprehensive health information solutions. This could be achieved through sharing data and information among heterogeneous systems that were never designed to interoperate. Automating and integrating ad hoc paper-based processes within and across organizations. Healthcare processes are complex, involving both clinical and administrative tasks, large volumes of data, and a large number of patients and personnel. Healthcare processes are very dynamic. As processes are instantiated, changes in healthcare treatments, drugs, and protocols may invalidate running instances, requiring reparative actions. Large-scale processes often span multiple healthcare organizations and run over long periods of time. This type of process requires highly scalable workflow systems to support large instances. Furthermore, these large-scale processes often need to be integrated with legacy information systems and with distributed, autonomous, and heterogeneous computing environments; thus, they require support for transactional features and error handling. Healthcare organizations operating in modern markets require Quality of Service (QoS) management. Services with well-defined specifications must be available to patients. An appropriate control of quality leads to the creation of quality care services; these, in turn, fulfill patient satisfaction. Interoperability is not solely a technical issue. It requires the diverse drivers and solutions for joined up collaboration of ICT systems to be delivered as an interdependent outcome. Within a single organization, we might expect such a result to be delivered through an Enterprise Architecture but a number of constraints distinguish such a collaborative community from a single organization. A collaborative community is diverse in its capabilities, delivery channels, and organizational structures. Diversity provides resilience but also highlights 64

8 the challenges and potential weaknesses for collaboration. Localization of national solutions meets jurisdictional requirements driven from their diversity of environment and approach. Communities are open to changing membership and require support for a range of predicted, and sometimes, unpredictable events. Distributed systems are logically more technically resilient to isolated failure than centralized systems but within a community environment, technical issues can be overshadowed by issues of provenance and jurisdiction. Boundaries are a natural consequence of multiple, independent system design and an integration approach often attempts to hide such conditions through transparency. In a diverse community however, recognition and transition across boundaries is a building block for collaboration. This does not imply crossboundary integration. Technology changes much faster than information. A data-driven approach to interoperability is more sustainable than a connectivity-driven approach in a changing environment. International Conference on Database Systems for Advanced Applications, Hong Kong, 2001, pp [12] Schulz, K.; Orlowska, M.E., Architectural Issues for Cross-Organisational B2B Interactions, Proceedings International Conference on of Distributed Computing Systems Workshop, 2001, P [13] K.Schulz, Modelling and Architecting of Cross- Organisational Workflows, The School of Information Technology and Electrical Engineering, The University Of Queensland, Australia. VIII. ACKNOWLEDGEMENTS This work has been partially funded by the European Commission with an ICT contract RIDE Project. IX. REFERENCES [1] ATHENA project, Deliverable D.A2.1, Cross- Organisational Business Process requirements and the State of the Art in Research, Technology and Standards [2] "ATHENA European Integrated Project", , [3] BPEL4WS Consortium. Business Process Execution Language for Web Services. [4] EBXML, [5] WFMC, or [6] Defining the SOA, Alyson Behr, November 2003 [7] Simple Object Access Protocol, [8] OASIS, [9] Asuman Dogac, Veli Bicer, Alper Okcan, Collaborative Business Process Support in IHE XDS through ebxml Business Processes, ICDE 2006 [10] WSCDL, Web Services Choreography Description Language Version 1.0, [11] Liu, D.-R.; Shen, M., Modeling workflows with a process-view approach, Proceedings of Seventh 65