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

1. Service-oriented architectures (SOA) and their application and usage in healthcare Herak Sen CSE300: Topics in Biomedical Informatics herak.sen@engr.uconn.edu Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-255 Storrs, CT 06269-2155

2. Outline • Introduction and Motivation • Role of SOA • Background on SOA • SOA in healthcare: • Connected Health • Connected Health Framework – Microsoft • Health Research Data Network (HRDN) • Modeling Medical e-services • Mobile • Bottlenecks

3. Introduction and Motivation (Complexity) • Operate in different environment • Entity focused i.e. built specifically for providers, patient ,insurance companies etc • Minimum information sharing • Hardly any interaction • Complicated business, legal and ethical rules

4. Introduction and Motivation (Outcome) • Patient suffers • Repeats information to different kinds of entity • No simple way to find information in times of emergency • Quality • 8th leading cause of death in US in medical errors • Duplicate patient information may be lead to repeated testing due to conflicts • 1/3 spending on healthcare goes to fix the duplication • $2.7 trillion estimated expenditure by 2010 but not number 1 in health care services

5. Introduction and Motivation (Solutions) • Technology • Give the entities especially patients to choose health services • Adoption of connected computer systems could reduce error and money • Internet can be used to deliver health information quickly • Standardize health data exchange • Use the current systems instead of making new ones Create a non-proprietary “network of networks” that will support rapid health information flow

6. Role of SOA • Significant work in independent healthcare area • PHR • EMR • Medication Management tool • Chronic disease management tools • Need to connect various systems • Service Oriented Architecture • Provides ways to connect disparate systems • Connect at edge of one system

7. Role of SOA (healthcare) • Common Framework of standards at National Level • Data Exchange • Security and Authorization • Data Integrity • All built as services • Using such services to integrate various existing systems • No redesigning of existing systems • Secure integration without jeopardizing patients and providers confidential data

8. Service Oriented Architecture

9. Service Oriented Architecture • Definition • 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 published, discovered and invoked • Abstracted away from the implementation using standards-based form of interfaces. • One can think “functions” in a program as services • Hides the implementation • Discoverable by the library it belongs • Can be invoked to get results • Publishable through a library

10. SOA Motivation • Present systems are across different architectures networks and even between organizations • Challenge is to find extendible, flexible that fits into legacy systems • Need to adapt to changing business models without effecting other parts of systems • Integration • Provide existing business functionalities as services that can be reused

11. SOA Examples • Yahoo • Flickr • Travel • Google • SOAP search API • Amazon • Amazon Associates Web Service exposes Amazon's product data and e-commerce functionality • Amazon DevPay is a simple-to-use billing and account management service

12. SOA Components • Services • The contract defined between one or more “published” interfaces exposing well-defined functionalities • Interfaces • Defining services , like header files in C++ • Contracts • Published Services • Published services are exposed through network • Public services are exposed within a system

13. SOA Components • Service provider • The software entity that implements a service specification • Services are just interfaces • Provider provides implementation • There can be many implementations • Its up to the client to select the service provider

14. SOA Components • Clients • The software entity that requests the services • Clients can be an end user application or another service • Typically they would choose a particular provider and call the appropriate service

15. SOA Components • Service locator • A specific kind of service provider • Acts as a registry and allows for the lookup of service provider interfaces and service locations • Identifiers are used to used for clients to discover the services • Service must be dynamically discovered and therefore their location should not be hard coded

16. SOA Components • Service broker • A special service provider that can pass on service requests to one or more additional service providers Components of SOA

17. SOA Management • 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.

18. Web Services

19. Web Services • SOA can be implemented in many ways with web services as the most popular • Definition by The Web Services Architecture Working Group • “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 ”

20. Web Service components • Service • Defined using XML based language called Web Service Descriptor Language (WSDL). • Contains operation performed, data types used and communication protocol used • Simple Object Access Protocol (SOAP) • Lightweight XML based protocol. • Platform independent • No drawbacks of RPC like security, compatibility and blocking by firewalls and proxy servers • Web service may also use other transport protocol such as HTTP,MIME,SSL,SMTP etc

21. Web Service components • Universal Description, Discovery and Integration (UDDI) • Web service that manages information about service providers, implementations and metadata. • Service providers can advertise their web services through UDDI • Defined in XML

22. Web Service components WSDL SOAP, HTTP, SSL etc UDDI

23. Web Service Performance and Reliability • Questions? • Can we depend on network • Is it slow • Enterprise system support • Answer – Distributed Architecture solutions • Internal services may use RPC • Load balancing software • Fault tolerant clusters • Wide area load distribution • Replica Management • WS- Transactions

24. Web Service Performance and Reliability • Scalability • Asynchronous callbacks to reduce transport layer overhead • Queues- Component that just listens to the requests

25. Web Service Security • SOAP and XML are text based • WS- Security • Integrating security with SOAP • Provides message integrity using XML signatures • Associates security tokens with messages for confidentiality • Support multiple security tokens format such as Username, X.509, SAML, REL Kerberos etc

26. Web Service Security considerations • Message VS Transport layer security • Client authentication VS Sophisticated brokered solutions, including X.509, Kerberos protocol • Protecting confidentiality of messages. • Detecting tampered messages. • Preventing the processing of replayed messages. • Accessing remote resources and flowing identity across tiers. • Preventing exceptions from revealing sensitive implementation details. • Protecting Web services from malformed or malicious messages.

27. SOA in Healthcare

28. Connected Health • Connecting for health • A private public collaborative organization that studies various fields of health information technology • Features • Safeguards privacy • Decentralized • Federated • Network of networks built on Internet • No central repository (e.g. patient medical records) • Exchange with authorization

29. Connected Health • Common Framework • Ensures interoperability • Secure transport in internet • Reliable authentication • Network software • Common policies • Methodologies • Documents • Use proven data standards • Private-public fund

30. Connected Health • Conclusions • Cannot be centralized • Standards and common framework allows easy interoperability Service Oriented Architecturefits in this paradigm

31. Connected Health Framework-Microsoft

32. Connected Health Framework-Microsoft • Architectural approach following the “Connecting for health” guidelines • Information system with common definitions both at technical and business level • Patient as the main entity • Lack of integration services between organization results in inefficiency • No national health ID • Systems should link at the edges using authorization • Federated based on data standards, interoperable, protects patient’s privacy and is built incrementally

33. Connected Health Framework-Microsoft Architectural Description • Service oriented • Modular approach • Reduces dependencies between systems • Use open standards and protocols • Interoperable • Federated data • Data should reside as close as possible to where it‘s created and administered • Caching at various level (departmental, regional, national)

34. Connected Health Framework-Microsoft • Federated security • Easier management of identities • Delegating aspects of authentication • Delegating role assignments • Trustworthiness • Reliable • Fault tolerant

35. Connected Health Framework-Microsoft Business Pattern for Healthcare

36. Connected Health Framework-Microsoft Architecture

37. Connected Health Framework-Microsoft Alignment of Business and Technical Architectures

38. Connected Health Framework-Microsoft • Advantages • High level architectural • Applicable to various medical domain • Tries to separate stable and volatile processes • Very modular • Provides good integration Based on Service Oriented Architecture

39. Health Research Data Network (HRDN)

40. Health Research Data Network (HRDN) • “Collection of software services, connected via high bandwidth communication infrastructure and standardized interfaces, enabling use participating data collection by authorized participants.” • Motivation • Health Researchers constantly need data or their research and experiments • The data sets though exist but are difficult to acquire due to their sensitive nature • Data custodian organizations keep such data though there are ethical and legislative requirements for accessing those for research purpose

41. Health Research Data Network (HRDN) • Goal • Minimize the time for researchers to access the data • Access without violating various requirements • Organizational Requirement • Ethical Requirement • Legislative Requirement • Support collaboration and re-use of knowledge among the HRDN participants

42. Health Research Data Network (HRDN) Abstract HRDN Architecture

43. Health Research Data Network (HRDN) • Preparing • Collection of data by data custodians • Does not dictate how to collect data. • Storing • Adding software and standards around data held by data custodians • HRDN does not force data custodian how to store data. • It provides services to access data from data custodian’s legacy system

44. Health Research Data Network (HRDN) Sharing Allows resources to be discovered and also access to multiple data sources and other services • Data Services • Accepts a request for data as query and returns requested data as messages. • Response may also contain some metadata such as timestamp and volume summary • May invoke security, auditing and logging services

45. Health Research Data Network (HRDN) Sharing • Orchestration Services • Responsible for invocation of network resources. • It takes a series of scenarios or a workflow that involves invocation of various resources • Planner and Transformation services • Responsible for transformation of data as per various schemas • Cache Manager • Responsible for the persistent and safe data storage • It receives requests from clients for standard data creation, updating, deletion and retrieval

46. Health Research Data Network (HRDN) Using: These services provide the final response to the clients. Services • Analytical Information Management service • checks whether the given data fits for the request. Generates metadata relating to the quality of fitness. • Exploratory Data Analysis service provides various statistical summaries and graphical forms. • Surveillance Analysis service provides some specialist analysis functions appropriate for health surveillance. • Statistical Model Building service provides statistical and decision making services.

47. Health Research Data Network (HRDN) • Describing: • These services provide metadata management, such as in sharing layer the metadata can be the track of information flow or in the preparing and storing layer metadata such as who created and stored the data, time etc can be stored.

48. Health Research Data Network (HRDN) • Protecting : • Member Registration Services provides mean to authenticate users using membership definitions policy etc and responds with security token . • Security Token Services generated security tokens and may form input for 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

49. Health Research Data Network (HRDN) HRDN Services

50. Modeling Medical e-services