Service-oriented architectures (SOA) and their application and usage in healthcare

Transcription

1 Service-oriented architectures (SOA) and their application and usage in healthcare I. Abstract: Herak Sen CSE300: Topics in Biomedical Informatics Healthcare in United States is a major concern.it is estimated that healthcare spending continues to increase tremendously with an estimate of over $2.7 trillion by 2010 [1]. The rising hospital costs, medical errors, lack of medical records in case of medical emergency are few of the causes that add greatly to the healthcare costs. On the other hand healthcare not only involves patients and providers, it spans public-private boundaries involving policy makers, legislators, providers, citizen who interact in complicated ways. Medical data are sensitive and bound by laws that makes healthcare an important concern for both government and private organization. It is obvious that technology can be used in solving many of these issues also no single organization can solve all these problems and therefore a collaborative approach is needed. Service Oriented Architecture is a natural answer for developing such systems where the present, legacy and future systems build by different organization can communicate with each other. This approach would give a fast and reliable health services to the consumer. II. Introduction and Motivation Healthcare systems are very complex that work in different environments, different models and implementations. Many of the systems have been developed around entities such as doctors, hospitals, insurance companies, researchers etc. All of them work in their own environment with minimal interaction. Also none of them want to share information, which sometimes may lead to the suffering of the consumer of the health service. Patients have to deal with several of these entities that might not have any similarity. Each has a different approach in controlling the information. The sensitive nature of the health information is very critical. If it is not protected well all of the health entities will be reluctant to use a widespread and connected health system. Some of the key facts and challenges [2] are that many people die in hospitals each year as the result of medical errors which makes its eight leading cause of death in the country. Many people also die because they did not receive appropriate healthcare and it has been found that adults receive 55% of the recommended healthcare [3]. Despite spending a lot on healthcare [4] it has been found that United States does not rank high in the quality of services provided compared to other countries. It also does not do well in reducing medical errors, overall rating of doctors. Another key problem was that a patient has to tell his/her medical information repeatedly to various health professionals. This leads to duplication of information, sometimes-conflicting information which also results in re doing the health tests. A study shows that one-third of the spending on healthcare by the country goes to care that is duplicative.

2 With Internet and advancement in affordable technologies, healthcare services can be effectively delivered to the patient that would enable the patients to maintain and improve their own health through better options and choices. In long term patients can be directly involved in deciding what the system should offer by series of feedbacks about the system. Adoption of computer systems could reduce errors and saving huge amount of money. Similarly standardized healthcare information exchange would deliver high national savings. There has been significant work in various independent areas of healthcare such EMR [5] an PHR [6], standards such as HL7 [7], tools like medication management tools, chronic disease tools, systems used at hospitals and devices such as used by diabetic patients. There is a need to connect all of them rather than creating one system that does it all such that all of them conform some basic principles and standards. This way information would not be stored in one place but can be aggregated by authorized users to provide various health services. There has been recommendation [2] for creation of a non-proprietary network of networks to support the rapid acceleration of electronic connectivity that will enable the flow of information to support patient care. Service oriented architecture fits perfectly in such a scenario. There can be a common framework at national level comprising of standards for various information exchange, security and authorizations, data integrity built upon service-oriented paradigm. Using such architecture would help integrating various systems and services in secure manner without jeopardizing patients and providers confidential data. III. Service Oriented Architecture As more and more organizations are implementing systems that are across different architectures, network and even between organization The challenge is to find a solution that is extendible, flexible and fits well with the existing legacy systems [8]. Replacing the legacy systems may be costly and introduces new development cycle increasing the chance of malfunctioning. As business models changes organization quickly need to adapt such changes into their computing infrastructure that might require the legacy systems change to support to the new business functions and integrate to the newly developed systems or integrate to the systems of its partners. The complexity of the whole thing is what makes it a constant challenge to organizations [8]. This kind of complex scenario can be effectively handled using Service Oriented Architecture. Definitions In [9] SOA is defined as The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. Some earlier definitions include Applications must be developed as independent sets of interacting services offering well-defined interfaces to their potential

3 users. Similarly, supporting technology must be available to allow application developers to browse collections of services, select those of interest, and assemble them to create the desired functionality [10]. In [11] a service is described as A course-grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled (often asynchronous), message-based communication model. Components of SOA [8,11,12] Service: The contract defined between one or more published interfaces exposing welldefined functionalities. There is a critical difference between public and published interfaces that is key to SOA. A public interface can be used by components within the system whereas the published interfaces are exposed through the network. In the former case the clients are known and in the later they are not known. Service provider: The software entity that implements a service specification. It is important to remember that services are just interfaces, they have no definition for the services therefore providers provide the implementation. There can be many implementations of a particular service. Its up to the clients which provider they choose. Clients: The software entity that requests the services. Typically they would choose a particular provider and call the appropriate service. Clients can be an end user application or another service. Service locator: A specific kind of service provider that acts as a registry and allows for the lookup of service provider interfaces and service locations. As mentioned earlier the clients should be able to find and choose services implemented by various providers therefore the service must have some identifiers associated with them so that they an be discovered. Service must be dynamically discovered and therefore their location should not be hard coded. Service Broker: A special service provider that can pass on service requests to one or more additional service providers. Fig 1. Components of SOA

4 These components allow the services to work and managed independently. Some of the management issues can be [13] the following. Security: Authorize requests, encrypt and decrypt data as required, and validate information. Deployment: Allow the service to be moved around the network to maximize performance or eliminate redundancy to provide optimum availability. Logging: Provide auditing and metering capabilities. Dynamic rerouting: Provide fail-over or load-balancing capabilities. Maintenance: Manage new versions of the service. Web Services Service oriented architecture can be implemented in various ways, one of the most popular implementation is as Web Service. The Web Services Architecture Working Group [14] describes it as A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols. Fig 2. Web Services XML based In Web Services the services are defined using an XML based language called Web Service Descriptor Language [15,16]. It contains operations performed, message used, data types used and communication protocol used by the web service [17,18].

5 Web Services can use any transport protocol to invoke the services and get the results. The most popular is Simple Object Access Protocol (SOAP) [19]. W3C defines it as lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. [20]. SOAP is widely used as its XML based and easily used over HTTP. Originally applications communicated using Remote Procedure Call (RPC), but HTTP is not designed to handle this. RPC also had security and compatibility problems also firewalls and proxy servers would block most of it. Using XML over HTTP provides much better way of communication for applications running on different operating systems and programming language. Since XML is text based SOAP becomes totally platform independent and extensible. The services can be discovered (service locator) using Universal Description, Discovery and Integration (UDDI). It is defined as platform-independent framework (XML) for describing and discovering services [21]. The registry services manages, provides information about services providers, implementation and metadata [22]. Performance and Reliability As web services are based on HTTP and SOAP, their performance and reliability will always be questioned. Can web services be used in enterprise systems? Isn t it too slow and unreliable? The answer will be same as for any distributed architecture systems. We cannot totally depend on HTTP for reliability and correct trade-offs and decisions should be made to support the systems and business requirements [11]. If performance is the key requirement then some portion of the system can be designed with fast RPC mechanism. For example if a service use some other services which are not exposed to clients then those internal services can use RPC communication. There other ways problems such as load on the server, the problems is discussed in [23]. There are various load balancing techniques that can be used. Apart from load balancing software of a machine can be configured to respond. Fault Tolerance Clusters, Wide Area Load Distribution, Replica Management are some other techniques to handle performance and reliability. Web services can also be made scalable making them asynchronous and using queues. Since there is a transport overhead as the services by design are remote it is important to reduce the response time. Making asynchronous services the clients can continue executing and the providers has chance to respond. This is very helpful where network costs are high and latency is unpredictable. Queues are also popular where services that expect very high load. The system is designed in such a way that there is special component that just listens to the requests and another component that services the request. The former one is known as the queue. Security Web services communicate via SOAP that is XML based hence it can be easily read. This poses a serious question how secure is web services? Can it be used for data which are confidential WS-Security tries to address this issue by introducing security at SOAP messaging provide quality of protection through message integrity, message

6 confidentiality, and single message authentication [26]. It provides mechanism for associating security tokens with messages. It supports multiple security tokens format to accommodate different kinds of authentication and authorization. It also describes how to encode Username Tokens, X.509 Tokens, SAML Tokens, REL Tokens and Kerberos Tokens as well as how to include opaque encrypted keys as a sample of different binary token types. Message integrity is provided using XML signatures which tries to ensure that messages originated from the correct and not modified on the network. In general the following points are the key points in web service security [24,25]. 1. Choosing between message layer security and transport layer security. 2. Choosing a client authentication technology, from basic direct authentication to more sophisticated brokered solutions, including X.509, Kerberos version 5 protocol, and STS solutions. 3. Protecting confidentiality of messages. 4. Detecting tampered messages. 5. Preventing the processing of replayed messages. 6. Accessing remote resources and flowing identity across tiers. 7. Preventing exceptions from revealing sensitive implementation details. 8. Protecting Web services from malformed or malicious messages. Some of the most common scenarios for web services and their security are very well described in [24]. 1. Public Web service: In this scenario transport layer security that is HTTPS and Username Token can be a good choice. 2. Intranet Web service: Here message layer security with the Kerberos [28] protocol can be used. 3. Internet business-to-business: In B2B Kerberos protocol can be used within organization and X.509 certificates between businesses. 4. Multiple Internet Web services: In this scenario a Security Token Service (STS)[27] may be used.

7 IV. Health care systems and role of SOA Achieving electronic connectivity in healthcare Connecting for health [29] a private public collaborative organization that studies various fields of health information technology. In [2] they outlined ways and means to connect health care systems. Few of the key recommendations were the following-: 1. Develop the health information infrastructure in a way that safeguards privacy, leverages both bottom up and top down strategies, is incremental in nature, and is based on a decentralized and federated model -- an interoperable, standards-based network of networks built on the Internet. The network should not contain a central repository for patient medical records. Instead, it should be a pathway that facilitates their identification and exchange, with appropriate authorization, in a private and secure way. 2. A Common Framework is needed immediately in order to pursue a decentralized strategy that builds out from a local and regionally driven approach to creating the infrastructure. Only by conforming to a Common Framework can we ensure that data exchange pilots, personal health records, and regional systems will be able to interoperate across and with other regional systems. The Common Framework is premised on secure transport over the Internet and provides minimal but basic components for the infrastructure including secure connectivity, reliable authentication, and a minimum suite of standards for information exchange. It is comprised of network software, common policies, documents and methodologies that can be shared in the public domain. 3. Public-private collaboration should fund. 4. Implement and use the data standards that have been proven. It also ensures interoperability. 5. Accurate Linking of Health records are very important as it may lead to prompt services. Also it is recommended that using a National Health ID for linking is not the correct solution. There is a risk of privacy because if leaked it can provide very sensitive information. Also it cannot be implemented in short period of time, as it would require an upgrade for all health systems that will be expensive. It is proposed that linking and sharing are made at the edges of the network. It would also allow providing additional linking requirement locally. The choice of what to link and what to disclose should be given to patients. It is clear from the above recommendations that connecting health care systems cannot be done in centralized way i.e. one cannot build a system that does all the work. It has to be system of systems. The only way to do is build many systems based on common standards. The standards should allow easy connection of these systems. Service oriented

8 architecture provides all the necessary features to connect systems and exchange data in secure and robust way. Connected Health Services- Microsoft In October 2006 Microsoft proposed a framework for connected health services [1]. The Connected Health Framework is an architectural approach following the Connecting for health [2] guidelines. The architecture proposes of an information system with common definitions both at technical and business level. This is essential as per [2] which argues that the systems must use common data standards. This architecture puts patient as the main entity and recommends transforming healthcare through productive, dependable and economic solutions that are connected by design. In the paper it has also been mentioned that lack of integration between services provided by various organizations also results in inefficient use of the services not only by other organization but also themselves also. Microsoft proposed that the systems cannot be developed using a national health ID, as it is too risky and can cause security issue. Instead the system should link at the edges of the network that can be established using authorization. The system should be federated based on data standards, interoperable, protects patient s privacy and is built incrementally without using a national health ID or a centralized database. By aggregating the above the system should be connected, information driven and work in collaborative environment. Architectural Description The 4 key features [1] of the architecture are: - 1. Service-orientation a modular approach that reduces dependencies between systems, using open standards and protocols to promote data application and interoperability. 2. Federated data given the local nature of healthcare delivery, data should reside as close as possible to where it s created and administered, caching information at different levels within the system (departmental, regional, national) to allow for different levels of service. 3. Federated security allowing easier management of identities and security credentials by delegating aspects of authentication and role assignment to trusted parties. 4. Trustworthiness reliable, fault tolerant systems.

9 Fig 3: A business pattern for healthcare As per [2] the above figure describes a typical healthcare business pattern. There are various processes all around which interact with each other. These processes should be secured. Also the processes may be running on different environment. The challenge is how to integrate them so that at the end the users get the best experience. Service Oriented Architecture provides an ideal solution for this scenario. Each of the above processes can be designed as services and uses standards for exchange at the edges. Notice even the security envelope can be a service. Web Services based in XML and SOAP provides the mean of achieving this interoperability and also supports the evolving business processes and changing business objectives. Another key advantage is that the existing or the legacy systems need not be discarded. They can be re-engineered in such a way that all of its functionality is preserved and used as services.

10 Fig 4: Architecture It is easy to see from the above figure that various parts of the systems are divided into services that have well defined edges and connection points. This way user and business processes that are more volatile can also be separated from the data and business component that are relatively stable via connected health service hub. The advantage of such architecture is that it does not dictate any one way of implementing and designing various healthcare systems. It provides guidelines how various systems can easily interact and get connected to other systems. Health Research Data Network (HRDN) The above architecture is a very high level view that can be applied in various medical domains. Similar features can be seen in [34] that describes a service oriented architecture for a health research data network (HRDN). Health Researchers constantly need data or their research and experiments. The data sets though exist but are difficult

11 to acquire due to their sensitive nature. There are data custodian organizations that keep such data and there are ethical and legislative requirements for accessing those for research purpose. The goal of HRDN is to minimize the time for researchers to access the data while supporting the complex organizational and ethical requirements that arising from research in inter-organizational and inter-jurisdictional data collection. It tries to support collaboration and re-use of knowledge among the HRDN participants. HRDN addresses the problem by proposing an architecture that consists of layers of services as follows: - 1. Preparing and Storing: This layer is responsible for preparing the data. As mentioned earlier that the data is stored with the data custodian organizations that have their own system and methods for preparing the data hence HRDN architecture does not enforce any way of doing that. The specific services are specific to organization. It may be noticed that the architecture proposed by Microsoft also allows business processes to be separate. The advantage is that the data custodians can use their existing systems to be a part of the HRDN, hence saving lot of money and resources and also their business rules inside their systems are preserved. They interface with HRDN via a set of services that connect to their legacy application and pass only the required data to HRDN. 2. Sharing: Sharing allows resources to be discovered and also access to multiple data sources and other services. There are various sub services within this such as:- a. Data Services that accepts a request for data as query and returns requested data as messages. The request may include may include temporary data storages by client and may include various parameters. The response may also contain some metadata such as timestamp and volume summary. The data service may invoke security, auditing and logging services. b. Orchestration Services manages multiple composite invocation of network resources i.e. it takes a series of scenarios or a workflow that involves invocation of various resources. In other words the workflow that is a graph of data dependent service invocations. It provides with asynchronous execution of the workflow and output the result and the execution trace. c. Planner and Transformation services are responsible for transformation of data as per various schemas. The requests are presented to the planner and the planner produces a workflow plan. d. Cache Manager is responsible for the persistent and safe data storage. It receives requests from clients for standard data creation, updating, deletion and retrieval. It ensures that the operations are compliant with the custodian requirements. The clients can only access data if they are authorized. e. Structure Registry keeps track of various data and transformation services in the network. 3. Using: These services provide the final response to the clients and also uses Disclosure Risk Estimator and Risk Mitigator services to ensure that the result

12 presented to the client do not disclose confidential information unless the client has the approval. a. Analytical Information Management service checks whether the given data fits for the request. It generates metadata relating to the quality of fitness. b. Exploratory Data Analysis service provides various statistical summaries and graphical forms. c. Surveillance Analysis service provides some specialist analysis functions appropriate for health surveillance. d. Statistical Model Building service provides statistical and decision making services. 4. Describing: These services provide metadata management. At various layers some metadata is always tracked such as in sharing layer the metadata can be the track of information flow. On the other hand in the preparing and storing layer metadata such as who created and stored the data, time etc can be stored. 5. Protecting: Protecting data is always the highest priority in any healthcare service and HRDN provides various services for that, though it assumes that the transport layers security is by SSL. a. Member Registration Services provides mean to authenticate users using membership definitions policy etc and responds with security token. b. Security Token Services generated security tokens and may form input for other services. c. Some other services Session Initiator that allows user to log on, Agreement Facilitator that validates whether request matches the custodian requirements etc are part of this layer. HRDN provides an excellent example of design using services in health care scenario. It proves that various aspects of such a complicated systems can easily be designed using services. It also provides in details what kind of services should be there in the given scenario that can be extended in other health care areas. HRDN can itself be tied to other similar systems using services. Example Usage as presented in the paper: Consider an epidemiologist, Emma, who is interested in studying the relationship between the post-operative survival times of colorectal cancer patients and their MYC gene amplification level. She first obtains membership through Member Registration service. She then applies to obtain data from data custodians and agrees to the terms and conditions for the usage using Agreement Facilitator service. She uses Exploratory Data Analysis services to understand the quality of the data. The service internally uses Disclosure Risk Estimator and Disclosure Risk Mitigator service that ensures the presented data does not reveal some confidential

13 information against the agreement. Finally she builds her workflow that is executed using Planner and Orchestration services. Modeling medical e-services In [30] the description of service oriented architecture becomes even more specific than the Microsoft Architecture and the HRDN that talked at the architecture level about services. It describes services implemented as Web Services. Specifically its shows how medical workflows can be modeled as web services. Though the general idea remains the same but here specific web service technologies are discussed for various layers. It highlights that there are various standards of communication such HL7 and DICOM[31] (Digital Imaging and Communication in Medicine) and defining medical workflows via IHE[31] framework but they work well in Intranet solution. But in current scenario there is need to break away from the Intranet to the Internet. The workflows and business logic can be spread across various organizations. Web services provides a feasible way to model, design and implement workflows. Features such SOAP for transportation WS-Security and WS-ReliabileMessaging for reliability and security and to model workflows BPEL(Business Process Execution Language)[33] can be used. Web Service workflow model can therefore provide medical e-services functionality in both intranet/internet environment. The paper outlines the following requirements for modeling e-service:- 1. HL7, DICOM encoding: Messages in IHE framework are based on HL7 and DICOM. The problem is how to transfer messages based on these standards using Web Services. One solution is converting the messages, which may be in binary format in XML. Another better solution is to attach the original messages to SOAP messages. WS-Attachment or SOAP messages with attachment (SwA) can be used to achieve them. More recently base64binary encoding as a standard for transferring binary data as it does not require additional protocol parsers. WS- Security can also be applied to binary data to provide message level security. 2. Web Service Transactions: Transaction protocols introduce the concept of transactions. HL7 and DICOM do not specify any transactional behavior. The application must take care of transaction and make sure that the same records are not inserted twice etc. WS-Transaction provides a standard for web service transaction. BPEL also compensation based transaction processing that allows undoing an action that has been successfully completed. 3. Security: As mentioned earlier security is very important in health care and medicine. As discussed earlier WS- security provides many of securing web services. There are other standards such as WS-Trust and WS- SecureConversation which can be used. With WS-SecureConversation web service providers specify security requirements and requestors provide claims that can be matched prior to security establishment. It also states which part of SOAP message have to be signed and encrypted to avoid message tampering.

14 4. Web service registration and binding: UDDI is standard for searching, registration and binding of web services. The registry provides services that implement specific IHE transaction. Outlining a modeling process Fig 5: Modeling process 4level use case model 1. First the 4 level UML use case diagram is defined for profiles, flows, transactions and messages used in the IHE framework. The profiles gives an overview of what an application performs. The profiles are split into various flows and are described as sequence diagrams in IHE framework. Each IHE flow is further defined using several IHE transactions. The transactions consist of one or more HL7 and DICOM messages used for communication. 2. The public workflow or the IHE transaction performed by an IHE actor is described using UML activity diagrams. The diagram can be derived from the sequence diagram.