• No results found

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

N/A
N/A
Protected

Academic year: 2021

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

Copied!
19
0
0

Loading.... (view fulltext now)

Full text

(1)

Service-oriented architectures (SOA) and their application and

usage in healthcare

Herak Sen

CSE300: Topics in Biomedical Informatics

I. Abstract:

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

(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 well-defined 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”.

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].

         Fig 2. Web Services XML based

(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. Healthcare 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

(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.

(9)

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.

  Fig 3: A business pattern for healthcare

(10)

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

  Fig 4: Architecture

(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 colo-rectal 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 DisclosureRiskEstimator and DisclosureRisk 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

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.

  Fig 5: Modeling process – 4level use case model

(15)

3. In the third step the focus is on the activities performed in an IHE transaction i.e. the HL7 and DICOM messages exchanged. The diagram is more detailed view of the IHE flow. It shows invoke and receive activities for messages. These IHE activities can then be split into various BPEL activities.

4. Finally using the above the IHE transactions can be converted into BPEL processes. The BPEL specification contains definitions of types, variables, messages and correlationSets that can be derived from DICOM and HL7. Then partners and a process using basic and structured activities are defined. The WSDL file contains a portType and a serviceLinkType section to define the Web services. Finally, compensation activities are provided using scopes and security issues are outlined.

Cooperative Mobile Healthcare Information Support System Using Web Services over Wireless and Wired Network

The previous examples elaborated architectures, services and finally use of web services for achieving connected health. In [36] the use web services are described for the end user of the healthcare information system. It shows medical information can be distributed to both wired and wireless network without creating software for both. Healthcare services through the web are an emerging field. On the other hand, wireless devices such as mobile phone have become very common. With increasing processing power device and storage capabilities for the wireless devices many desktop applications are being developed for them. Healthcare services can also delivered using such devices. This would be very beneficial as providers and patients can communicate using a small device therefore in case of emergency the response can be very quick. The bottleneck of using the wireless devices are the limited processing power compared to desktops and the display is very small. Due to its small display the existing web content cannot be

displayed properly on these device.

Several research are undergoing for finding solutions to display contents on the limited screen size. The simplest adaptation technique is to not change the original page in any way, but let the user navigate using scrollbars. The other technique is develop pages specific for the each kind if devices, though this will give the best user experience but will require lot of work for content or web designer. Finally, the Automatic authoring technique render and filter useful contents and transforms them for browsing on devices with small display. This requires minimum user intervention and can convert web documents suitable for small display on the fly.

(16)

The system consist of five main component

1. Web Server: It provides medical information for mobile devices on both wired and wireless networks using WSDL to describe functions and protocols. It then transmits to the mobile devices and user binds the web server and the WSDL that enables web services to be used using SOAP.

2. Medical Information Database: It contains patient information, lists, symptoms, prescriptions and diagnosis.

3. Mobile Context server: It applies context to the contents using styles, an attribute override, and templates according to the resources of a given mobile device.

4. Desktop subscribers: They can ask for services after checking the WSDL of a service. They can browse full contents on one screen shot because of the wide screen monitors.

5. Mobile Subscribers: Each mobile device has different screen size, input method, color and markup language that affect Internet browsing. The mobile context server optimizes the web contents according to the mobile device. Microsoft Mobile Internet Toolkit developed the Mobile context server. This toolkit creates device specific structure that applies property override, stylesheet and templates. After the system evaluates the mobile devices computing capacity, the system serves the web contents based on the context chosen by the mobile context server Web services provide the backbone for this architecture, as there was no need to develop new pages for each mobile device. The healthcare services can be exposed as web services that can be accessed by different kind of devices. Also in future if some service changes then it would be available to all the wired and wireless devices.

  Fig 6: Architecture

(17)

V. Bottlenecks of SOA in health care

Though SOA provides a lot of promises in the health care domain, there are realistic problems that may become the bottleneck [35] of such architecture.

1. SOA requires significant expertise at designing. Due to complex nature of healthcare architects must spend significant amount in designing the framework of reusable services. This step would significant time and various public private organization must come together.

2. The standard in representing data in health care is evolving and must be given be given high priority. It is very important for services to know that semantics of the data being passed to and fro from it. Standards would also play an important role in making the systems interoperable. Today there are a number of data standards in various fields of heath care and therefore there is a need to determine whether they are sufficient and comprehensive.

3. A key feature of SOA is that services can be discovered but in reality this is a very complex process and specifically in healthcare the discovery of services would require considerable human expertise, as one has to choose the correct service. It is very important that the services are described very well such that one can choose the correct service, as this step may be very critical in some situations. Consider there is a service that outputs dosages for some disease. Imagine if the dosage was in pounds and the service user is expecting in kilograms. This can result in a fatal outcome. 4. Some areas of health care are still not well defined such as dosing. Dosing depends

on not very well formed parameters therefore it is still very difficult to provide services for it. There is need for researchers in both medicine and SOA to indentify such areas and find ways of constructing services.

5. Another guarantee that SOA may not be able to give is response in real-time situations. Due to distributed nature of SOA, organizations may be skeptical adopting SOA for an emergency situations where fast response is most critical. 6. There is a need for motivating various health care organizations for adopting SOA

for larger goal. Most of these organizations are reluctant to share their data due to both organizational and legal constraints. It may be beneficial for organizations to publish some of the services for some fee. Government may take initiative to promote such an idea of commercial services.

VI. Conclusion

Service oriented architecture provides many benefits especially it can be very useful in complex domain like healthcare where there are so many rules that are not limited to medicine but span across like ethics and law. Many organizations have invested and built

(18)

healthcare informatics products over the years but still the quality of healthcare is not improving. It is due to the facts that most of the organizations are skeptical about

information sharing due to various rules. It is indentified that information sharing without jeopardizing patient-provider confidential information is must to improve the quality of healthcare. It is also clear that discarding existing systems is not beneficial, hence there is need to connect various healthcare systems. Service Oriented architecture provides the framework for achieving such connectivity. In this report the guidelines for a connected health framework was mentioned followed by an architecture using the guidelines. Then using a specific area in healthcare (HRDN) various services needed for the area was described. After services at conceptual level, web service use to model medical e-services was described and then use of web service to reuse functionality for wireless and wired devices was mentioned. SOA can integrate health services without violating the various rules though it requires a significant expertise at various organizational levels. Proper collaboration by various private public organizations can identify the problem areas and then start connecting the systems. Such a system of systems can help save a lot of lives.

VII. References

1. Microsoft Collaborative Health Solutions Streamline Information Flow :

http://www.microsoft.com/industry/healthcare/solutions/collaborativehealth.mspx 2. Achieving electronic connectivity in healthcare:

http://connectingforhealth.org/resources/cfh_aech_roadmap_072004.pdf

3. McGlynn EA, Asch SM, Adams J, Keesey J, Hicks J, DeCristofaro A, Kerr EA. The Quality of Healthcare Delivered to Adults in the United States, New England Journal of Medicine, Vol. 348, No. 26, June 26, 2003, pp. 2635-2645.

4. Health Spending in Most OECD Countries Rises, with the U.S. far Outstripping all Others. Available at http://www.oecd.org/document/12/0,2340,en_2649_37419_31938380_1_1_1_37419,00.html

5. Electronic medical record. Available at http://en.wikipedia.org/wiki/Electronic_medical_record

6. Personal health record: Available at http://en.wikipedia.org/wiki/Personal_health_record

7. HL7- Available at http://www.hl7.org/

8. Service Oriented Architecture - http://javaboutique.internet.com/tutorials/serv_orient/

9. Understanding Service-Oriented Architecture : D Sprott, L Wilkes - Microsoft Architect Journal, 2004

10. Large-Scale, Component-Based Development by Alan W. Brown, Prentice Hall, 2000

11. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications : A Brown, S Johnston, K Kelly - Rational Software Corporation, 2002 -

download.boulder.ibm.com

12. Service Oriented Architecture - what is made of?

http://www.developer.com/services/article.php/10928_1010451_2

13. Migrating to a service-oriented architecture: K Channabasavaiah, K Holley, E Tuggle - IBM DeveloperWorks

(19)

14. Web Service Architecture - http://www.w3.org/TR/ws-arch/

15. What is Web Services - http://www.w3schools.com/webservices/default.asp

16. Web Services Description Language (WSDL) : Available athttp://www.w3.org/TR/wsdl20/

17. WSDL Tutorial: http://www.w3schools.com/wsdl/wsdl_documents.asp

18. Understanding WSDL:http://msdn2.microsoft.com/en-us/library/ms996486.aspx

19. Introduction to SOAP: http://www.w3schools.com/soap/soap_intro.asp

20. SOAP Version 1.2 Part 1: Messaging Framework: http://www.w3.org/TR/soap12-part1/

21. WSDL and UDDI: http://www.w3schools.com/wsdl/wsdl_uddi.asp

22. Universal Description, Discovery, and Integration (UDDI): http://xml.coverpages.org/uddi.html

23. Ingham, D. B., Shrivastava, S. K., and Panzieri, F. 2000. Constructing Dependable Web Services. IEEE Internet Computing 4, 1 (Jan. 2000), 25-33. DOI= http://dx.doi.org/10.1109/4236.815846

24. Web Services Security (WS-Security): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp

25. Web Services Security Scenarios,Patterns and Implementation Guidance for Web Service Enhancements (WSE) 3.0: http://msdn2.microsoft.com/en-us/library/aa480545.aspx

26. Web Services Security: http://www.ibm.com/developerworks/library/specification/ws-secure/

27. Security Token Service:http://msdn2.microsoft.com/en-us/library/aa480563.aspx

28. Kerberos: http://web.mit.edu/Kerberos/

29. Connecting For Health: http://www.connectingforhealth.org/aboutus/index.html

30. Rainer Anzböck, Schahram Dustdar.Modeling Medical E-services Proceedings of the second International Conference on Business Process Management, BPM 2004, Potsdam, Germany in June 2004

31. DICOM: http://medical.nema.org/

32. The IHE Process to Achieve Standards-based Interoperability: http://ihe.net/About/process.cfm

33. Business Process Execution Language: http://www.ibm.com/developerworks/library/specification/ws-bpel/

34. Taylor, K., O'Keefe, C., Colton, J., Baxter, R., Sparks, R., Srinivasan, U., Cameron, M. & Lefort, L. (2004), A service oriented architecture for a health research data network, in `Proceedings of the 19th International Conference on Scientific and Statistical Database Management (SSDBM'04)', Greece

35. Service-oriented Architecture in Medical Software: Promises and PerilsPM Nadkarni, RA Miller - Journal of the American Medical Informatics Association, 2007

36. Ho Hyun Kang, Sung Rim Kim, Kee-Deog Kim, Dong Keun Kim, Sun K. Yoo: Cooperative Mobile Healthcare Information Support System Using Web Services over Wireless and Wired Network. CDVE 2007: 323-330

References

Related documents

Při návrhu algoritmu bylo potřeba vymyslet způsob, jakým si uchovávat informace o jednotlivých postavách tak, aby bylo možné mezi nimi hledat stejné nebo velmi podobné páry..

With background traffic generated for the 50-node mode of AT&T network, we evaluate the VoIP quality for the primary optimal path and the diverse paths in the same 10-node

Our PNA software is implemented as a Linux kernel module split into an active logging step and a real-time monitoring step that allows analysis of network frames as they arrive

Considering the use of Smart ICT in the public infrastructure planning, development and operation process will enable major projects to be designed, built and managed with greater

This guideline and systematic review were prepared by The Diagnosis and Treatment of Osteochondritis Dissecans of the Knee guideline work group with the assistance of the

In the ongoing quest to best assess and comprehension level, it is important to know which response questions best measure knowledge, which presentation conditions best

Building Community Resilience to Climate Change in Champhone District Savannakhet Province. Champhone District, Savannakhet Province

In this quasi-experimental static comparison group design, a homogenous sample of 128 American Literature (high school juniors) students were placed in a comparison and treatment