E-HEALTH PLATFORMS AND ARCHITECTURES

E-HEALTH PLATFORMS AND ARCHITECTURES E-Government Andreas Meier Nicolas Werro University of Fribourg Alfredo Santa Cruz 19.01.2007

Contents 1. Introduction 2. Existing Capabilities and Strategic Approach 2.1. Existing capabilities 2.2. Strategic approach 2.2.1. Key issues in Healthcare systems 3. Service Oriented Approach (SOA) 4. Electronic Health Record (EHR) 4.1. Model of HER 4.2. Architectural approach HER 5. A Norwegian case based on XML, ebxml and PKI 6. Conclusion

1. Introduction In 2006 healthcare implies a major government and private concern, on average health spending data between 1990 and 2004 grew faster than GDP in every OECD country except Finland. In 1990, it accounted for an average of 7 % of GDP across OECD countries and reached 8.9 % in 2004. In general health care systems operate in an intricate environment of public and private services, with a great number of business models. Consequently, the design, implementation, integration and operation of health care systems become a tricky and complex task. Governmental institutions and private entities tend to implement theirs own processes and delivery channels. As a result, each one takes its own approach to controlling information flow and access. Having an overview of the entire health care system, we can see a collection of isolated islands, each of them is using a particular technical platform and standard, as a consequence a waste of energy in order to get the right information at the right time. Furthermore, the lack of integration between services offered by multiple organizations, it is a mirror of the fact that these organizations themselves are in most cases unable to efficiently and effectively integrate data in their own corporation. So, healthcare and delivery entities are rethinking the ways they use technology and they are looking for ways to make lasting investments in solutions that help manage the enormous complexity of healthcare systems, help healthcare workers performs their jobs more effectively and manage the sensitive and private data for each system in a way that improves services. The purpose of e-health conceptual system architecture is to provide a set of architectural representations of the entire e-health system. This e-health architecture should be derived from the structure and processes of the activities it is intended to support. To design and implement e-health architecture, the IT plans will demonstrate: a. E-Health projects should be classified according to the activity and services, for example, a registry, shared repository, application, common service or EHR system.

b. IT plans should identify what e-health services are required internally and by other external organizations. In this way, the selection and implementation of standards lead to efficient collaboration and interoperability across the system. c. IT plans should identify what e-health services will be provided by the system. These services are the counterpart of item 2 above. The entire portfolio of plans will eventually form a coherent network of available services and services expectations. Moreover, e-health has the potential to enable broader reach and improve quality and effectiveness of healthcare, as a result improve patient care and reduce costs. This article is structured as follows: in section 2, a description of existing capabilities and strategic approach are given. Afterwards, in section 3, a description of SOA (Service Oriented Approach) is presented giving the main characteristics of this approach. Then, in section 4, a definition of Electronic Health Record (EHR) is specified which is close to the approach SOA. Finally, I give an example apply this approach in a real context: Norway case based on XML, ebxml and PKI.

2. EXISTING CAPABILITIES AND STRATEGIC APPROACH 2.1. Existing capabilities Organizations have already some components required to deliver e-health services. These components will be incorporate as existing building block into the new architecture. That is why concepts such as modularity and interoperability should take into account. 2.2. Strategic approach Complex processes often involve information systems in multiple organizations, where it is not possible to mandate that all organizations information systems are developed simultaneously to a single design. It is important to work on standards and focus on integration between organizations in end-to-end business processes. Thus, middleware technologies and standards committees should take a very active function in defining ways for organizations to collaborate. To allow organizations the autonomy and flexibility they need to take control over their own IT environments, while still enabling inter-organization business. Technology architects commonly recommended a service-oriented approach. The service-oriented approach allows each agency to do whatever it likes within its own domain. But whenever it collaborates with others in a larger setting, it does so through a number of defined services and for each service, the technical mechanism for using the service, the data content and business rules are all defined and agreed by all participants. The service-oriented approach respects the internal autonomy of each participant agencies. It attempts to identify each of the participants and describe their roles and relationships to the rest of the system. The roles and relationships of the participants imply a set of business services that they each must provide to the system as a whole. Each of these services requires detailed information and definitions of technical protocol, data and business rules. IT environments need to accommodate data, interactions and transactions for participants such as patients, healthcare professionals, healthcare providers and policy makers. The relationships

and services can be visualized through a schematic drawing showing the interactions patterns among these groups. Figure 1 show the relations among healthcare s actors. Figure 1: Interactions among participants 2.2.1. Key issues in Healthcare systems a. How to create a patient s health record b. How to construct a system, in which patient s information is stored in multiple systems for long time c. How to manage identity d. How to identify a patient uniquely and reliably e. How to interconnect diverse systems and how to make them interoperate f. How to communicate with remote systems g. How to reuse legacy systems h. How to achieve performance, flexibility and agility

In like manner, architecture is governed by the following requirements: a. Planning horizon: architecture should include the foundation for the implementation of capabilities through the time. This means it must include services that will dominate in the future. b. Support for Electronic Health Record usage: The comprehensive and integrated patient record make possible an improved healthcare delivery. c. Interoperability: supporting the integration of work of multiple disciplines and enabling integrated teams in order to provide care to patients. This point is above all important when teams are geographically distributed and in different organizations. d. Alignment: The architecture must align with the objectives, approach of standards and governmental recommendations. e. Flexibility: the architecture must allow for different business requirements and existing assets to integrate and collaborate. f. Support for shared procurement opportunities: helping participants to engage in the joint procurement of shared assets.

3. Service Oriented Approach (SOA) Before present this approach, the following philosophies of integration systems is given in the next graphic. Figure 2: Philosophies of integration As we see in the figure 2, SOA is not tied to a specific technology. It may be implemented using a wide range of technologies such as RPC, DCOM, CORBA or Web services. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the serving having foreknowledge of the calling application, and without the application needing knowledge of how the service actually performs its tasks. SOA expresses a perspective of software architecture that defines the use of software services in order to support the requirements of the business processes and software users. Resources on a network in a SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation. Therefore, SOA approach facilitates integration on two major levels: a. Application integration: systems and applications can talk to each other in mutually understandable terms. b. Technically operability: systems can be interconnected in a secure and in a reliable manner.

These two levels can allow healthcare systems to interoperate and collaborate at a higher level, enabling applications such as decision support, patient and business intelligence. SOA has two important functions: a. From a business perspective: enhancing business capability and information available to consumer both inside and outside the enterprise. Specially by supporting improved business that means joining up systems at the application level and resolving issues of data consistency and business interoperability. b. From a technical point of view: enabling applications to interoperate across diverse technical and operational platforms. The figure 3 depicts these two functions. Figure 3: SOA overview

4. Electronic Health Record (EHR) EHR is the provision to a care provider, in a single viewer application, of an integrated view of patient s electronic health data. The viewer may be a web portal or a window in an existing clinical application. 4.1. Model of EHR The model contains three major sections. At first, the core processes of direct care then support processes like laboratory analysis and finally information infrastructure like HER security. The model EHR does not imply any specific technical architecture; the functions of the architecture can be implemented by any technology. The following graphic show us this model. Figure 4: EHR model

4.2. Architectural approach EHR Infoway s EHR recommends an architectural approach that is showed figure 4: Figure 5: Architectural approach The following functions should be implemented: a. For data sources that might not be available when data needs to be seen, the information is pushed when it is updated, into Domain-specific Repositories, which are accessible when required by applications that need them. b. For all data sources and repositories that will act as sources for the integrated record, an index or directory is maintained. As data are pushed into repositories, or stored in clinical systems, a reference to the data is recorded in an EHR Repository or document registry. When an application needs to display an integrated view, it uses the EHR Repository to find the components of the record, and display them. c. All components of the system communicate through a shared network infrastructure, using agreed service protocols. ( HIAL means Health Information Access Layer ).

d. Information is integrated using Registry Services, which allow single patient, provider and location identifiers to be resolved from diverse identifiers used throughout the system. Concerning implementation model at macro level follows as: Figure 6: EHR implementation Health authorities are the focal point of e-health service delivery. Within their IM/IT plans they provide for clinical systems and domain-specific repositories. Both clinical systems and domain repositories can be considered feeder systems for health authority and province-wide e-health services. For a collection of strategic topics, health authority feeder systems push data into a set of shared repositories. In many cases, the shared repository will actually be fed by other agencies such as pharmacies and private labs. Some data is maintained at a local level, for example, the colleges and regulating bodies (for provider data) or the pharmacies (for client data).

A document index identifies the location of all e-health objects relating to an individual, indexed by type, and containing links to the specific location of the object (health authority). Pushing data into domain repositories means also updating the index. Access to all of these data is provided through a set of standardized services. These services provide access to resources in shared repositories, or in health authority applications, such as query access services via Web Services or for online services via standards like HL7. Data are integrated into health authority clinical systems or EHR systems, including EHR viewers, for use in the health authority and by external care providers. It s important that the data integration happens through the use of the standard services already defined. A HIAL exists both within each health authority, supporting its own internal integration, and amongst all participants. This infrastructure component provides basic messaging capability, but also a number of other common services such as federated authentication and authorization, message queuing and workflow, and administration.

5. A Norwegian case based on XML, ebxml and PKI The National Insurance Administration (NIA) initiated a project to improve the communication infrastructure between business partners such as pharmacies, hospitals and doctors. 5.1. Legacy system The legacy system is or was based on: a. EDI based communications and EDIFACT messages using X.400 message protocol. b. Use of a proprietary Public Key Infrastructure (PKI). The following diagram shows this system: Figure 7: Architecture legacy As shown in the diagram, there is no direct connection between individual pharmacies and the NIA. There is a central hub, which connects to all pharmacies using a pharmaceutical computer network. This central system is connected using EDIFACT.

5.2 Architecture Requirements The upgraded architecture must provide the following benefits: a. Security messages: important due to the sensitive nature information exchanged in an e- Health context and this system must guarantee authentication, integrity, confidentiality, and non-repudiation. b. Message transport must be reliable and make sure messages are delivered once only once. c. Efficiency of the administrative processes should be improved to enable healthcare system to provide better system. To achieve the requirements, the following technological changes must be undertaken: a. A migration from mainframes to less expensive UNIX-based platforms. b. Introduction of a secure messaging-based system for enterprise application integration. c. A migration to industry-standard Public Key Infrastructure (PKI). d. Adoptions of open standards transport protocols and message formats. e. Migration of X.400 to a less expensive Internet Protocol-based National Health Network in Norway. f. Adoption of Extensible Markup Language (XML) as a new standard message format and format for electronic business documents.

5.3. New Architecture An overview of this new architecture is showed in the following diagram and this new architecture is based on the SOA approach: Figure 8: New architecture The main advantages of this new architecture are that doctors are connected to the NIA and other organizations in the Norwegian Healthcare Network and messages sent by doctors will be signed using the personal private key and sensitive messages will be encrypted using their public key. These advantages are described in the next sub-sections. 5.3.1. Open standards The architecture is based on open standard transport protocol and message formats. Each partner is responsible for being able to send and receive messages according to the standard interfaces The NIA has worked with its partners in the selection of these standards. The joint decision has been to use XML formats for new message types. Transport protocols and message formats are based on open standards, for that reason a single solution is not mandated to each business partner. A key advantage of the use of XML is that it allows for better message specification and automatic message validation and therefore eases error detection and testing.

Another difference with the existing situation is that ebxml Messaging will be used as message transport protocol. EbXML Messaging will be used to transport both EDIFACT payloads for existing connections and XML payloads for new message types. The Norwegian Centre for Informatics in Health and Social Care is responsible for development of healthcare IT standards in Norway and also maintains the relation to European and international standards organizations in the healthcare domain. KITH has developed the XML schemas for the new message types. 5.3.2. The ebxml Messaging Service The ebxml Message service is message protocol. Architecturally, it fits between a business application or middleware and lower-level Internet protocols, providing business-oriented additional functionality. This is illustrated in the following diagram: Figure 9: ebxml Messaging Service

Specifically, the ebxml Messaging Service offers the following benefits: a. It provides the security features (authentication, integrity, confidentially and nonrepudiation), through the use of XML digital signatures and XML encryption, in combination with a Public Key Infrastructure (PKI). b. In the Norwegian e-health network, ebxml Messages use SMTP as the underlying Internet message transport protocol. Other ebxml applications use HTTP, often layered over Transport Layer Security (SSL/TLS). c. It provides a reliable messaging protocol based on receipt acknowledgments and a retry mechanism. This prevents loss of messages in the messaging system. d. It enables routing based on envelope information (even for encrypted payloads). e. It supports tracing and monitoring of message traffic. 5.4 Overview of the NIA (National Insurance Administration) project in Norway The Norwegian e-health infrastructure has been based on the principle of using open standards: a. ebxml Messaging, the International Standard for secure and reliable messaging. b. EDIFACT and XML for the definition of business document types. c. Internet Protocol for the National Health Network. The use of open standards has been a strategic choice that has worked well for the project. This principle explicitly leaves the responsibility of implementing these standards with the individual business partners. Organizations make an agreement to communicate and then are individually responsible for the implementation of the agreement. It does not impose a single software solution on an entire community, but allows individual business partners to select a solution that conforms to the standard, but also meets each individual organization s (possibly unique) requirements.

Figure 10: Message protocol overview The IT management underlines that the real challenges in deploying and extending the Norwegian e-health infrastructure are not technical, but related to the organizational complexity of connecting large numbers of partners that use a diversity of enterprise and legacy systems, but are required to converge on a common interface.

6. Conclusions Healthcare organizations should develop their technological infrastructures aligning some crucial values such as interoperability, collaborative and economical savings. Open architectures such as ebxml can achieve interoperability among seamless healthcare providers, healthcare professionals and, private and public organizations. Moreover, interoperability allows leverage infrastructure investment because legacy network is still used. To communicate with other organizations, all of them employ a single standard of communication, enabling delivery health services. Besides the use of a single standard, economical savings is feasible, for example an integrated platform among organizations can lower technological costs. The values mentioned above go in the way of improving patient health and boost communication among all actors of healthcare organizations,

References Gesundheit Telematik Gründlagen Anwendugen. Haas E-health Care Information Systems. Joseph Tan European Conference on e-health 2006. Secure Sharing of Electronic Patients Records. Surya Nepal, John Zic, Gregorie Kraehenbuehl, Frederic Jaccard Service Oriented Architecture (SOA). Acrobat white paper - 2006 Connected Health Framework Architecture and Design Blueprint. Microsoft white paper 2006 Software architecture for digital healthcare - 2005. University of Kuopio. Mikko Korpela, Juha Mykkänen, Jari Porrasmaa and Matti Sipilä Norwegian e-health Infrastructure based on XML, ebxml and PKI - 2005. Oasis Case Study SOA Reference Model. Wikipedia Http://en.wikipedia.org/wiki/SOA