Principles of integrating added-value applications to health information management and sharing

(1)

China-Finland e-Health Partnership 1 (60)

China-Finland e-Health Partnership

Research Project Report 3

Principles of integrating added-value

applications to health information

management and sharing

Hannu Virkanen, Juha Mykkänen,Jiechen Jiang University of Kuopio, HIS R&D Unit

University of Kuopio, Healthcare Information Systems Research and Development (HIS R&D) Unit

University of Kuopio, Kuopio, Finland, 2008 www.uku.fi/ehp

(2)

Table of contents

1. Defining integration types, interoperability needs and cases ... 5

1.1. Current state description ... 5

1.2. Most urgent needs of users and administration ... 6

1.3. Generic Classification of integration needs and solution principles ... 7

2. Specifying the integration solutions ... 8

2.1. Inputs needed for the solution ... 10

2.1.1. Overall process for integration specification ... 10

2.1.2. Main requirements – describing the business case for the integration (phase 1) ... 11

2.1.3. Participating applications (phases 2 and 3) ... 12

2.1.4. Potential information and functional standards and specifications (phase 4 and 5) .. 13

2.2. List of questions to help in producing solutions and examples ... 14

2.2.1. Scope of the solution ... 16

2.2.2. Information and semantics ... 17

2.2.3. Functionality and interactions ... 18

2.2.4. Application infrastructure aspects ... 19

2.2.5. Technical aspects ... 21

3. Generic recommendations for different integration types ... 22

3.1. Information integration ... 22

3.2. Functional integration ... 22

3.3. User integration ... 22

3.4. Process integration ... 23

4. Examples of integration ... 23

4.1. Examples based on current state descriptions ... 23

4.1.1. The example solutions ... 26

4.2. Description of Regional information sharing by Weifang CHC and Kingstar ... 40

4.3. eHit example ... 49

5. Conclusions and recommendations ... 55

(3)

Summary

China-Finland e-Health Partnership is Finnish and Chinese counterparts’ joint research project, which aims to better information sharing in healthcare. The project was approved to be the bilateral governmental China-Finland Science and Technology Programme. The research institutions in Finland are University of Kuopio (UKu, coordinator) and University of Tampere (UTa). This project is organized with 4 main research themes: 1) Needs and requirements, 2) Architectures, interoperability and standards and 3) Data set definition for electronic health records, 4) Evaluation. Within each theme, Finnish counterparts’ previous research results from e.g. ZipIT (www.uku.fi/zipit/english/), SerAPI (http://www.serapi.fi/english.html), eHP Finland, and EBMeDS projects, are applied. All the themes concentrated on the same case domain, to ensure better use of resources and mutual understanding of the pilot site by working groups and projects counterparts. Maternity care pathway was selected as a case study, and two healthcare organizations, Weifang Community Health Center (CHC) and East Hospital, were selected as target organizations in Pudong New area. Data was gathered mostly in field studies in the hospitals during November 2007 and January 2008. The findings of this study are reported in the report: Describing the current state of health information management and sharing: The case of maternity pathway in Weifang Community Health Centre and East Hospital, Shanghai in 2007 (Luukkonen et al 2008).

This report introduces the theoretical background for solving the integration and data sharing needs and suggests tools for creating the required solutions systematically. Also examples of applying the proposed models to the target environment are introduced to illustrate how the recognized “bottlenecks” depicted in the current state report could be solved.

The aforementioned tools are: Questions Framework for gathering information for the integration solution (Chapter 2) and information systems diagrams drawn from the current state analysis (Chapter 4) used as a basis to start outlining solution and migration plan for the target environment.

The report introduces basics of SOA (Service Oriented Architecture) and EA (Enterprise Architecture)-practices applied to the integration and information sharing needs in target environment. The basis of the research has been laid in the numerous research projects (see Mykkänen 2007, Luukkonen et al 2007) in University of Kuopio in the field of healthcare information technology and particularly in the health information sharing and systems integration.

(4)

Acknowledgements

This paper is based on research conducted in the project China-Finland e-Health Partnership

(Cn-Fi eHP), funded in 2007-2008 by the Finnish Agency for Technology and Innovation Tekes (grant no. 40210/07) as well as Conceptia Oy, eHIT Oy, GoodIT Oy, Kuopio Innovation Oy, Mawell Oy, Mylab Oy and Tietotarha Oy. The project was implemented by the University of Kuopio, Healthcare information Systems Research and Development Unit, and the University of Tampere, Department of Computer Sciences.

The 12th Joint Session under the Agreement on Scientific and Technological Cooperation between the People’s Republic of China and the Republic of Finland, in Beijing on 24 May 2006, approved the Cn-Fi eHP project and its sister project Researching on the strategy of construction & evolution in digital hospital (Guidelines for information interoperability), by the Health Information Centre of Shanghai Municipal Health Bureau, to the Sino-Finnish Scientific and Technological Cooperation Programme as project no. AM12:08.

The authors wish to gratefully acknowledge the invaluable contributions of the Health Information Centre of Shanghai Municipal Health Bureau, the Pudong Health Authority of the Social Development Bureau of the Pudong New Area District, all participants of the sister project and particularly members of staff of the Weifang Community Health Centre and the East Hospital.

Abbreviations and terms:

CDC Center for Disease Control and Prevention CHC Community Healthcare Center

DICOM3 Digital Imaging and Communications in Medicine, version 3 -standard DWS Doctor workstation application(s)

EA Enterprise Architecture (See chaper 2) EHR Electronic Health Record

EPR Electronic Patient Record

GP General Practitioner (working in CHC) HIS Hospital Information System

HL7 Health Level 7 –standard

MCH Maternity and Child Healthcare Center

PACS Picture Archiving and Communication System SMHB Shanghai Municipal Health Bureau

(5)

1. Defining integration types, interoperability needs and cases

1.1. Current state description

This report contains methodological support for and examples of specifying interoperability solutions for healthcare organizations in China, based on the work performed in China-Finland eHealth Partnership project. Many recommendations and examples are based on experience and analysis of interoperability standards, architectural and methodology guidelines, and joint work (e.g. meetings, workshops, project materials) between Finnish and Chinese partners. Examples of integration include case-based material, including cases where the integration specification is based on the integration solutions of Finnish applications and products related to the project. Most of the solutions and cases are illustrated in relation to the maternity pathway which was studied in detail for the project.

The knowledge of the target environment for this report is mainly based on the findings reported in Describing the current state of health information management and sharing: The case of maternity pathway in Weifang Community Health Centre and East Hospital, Shanghai in 2007 – report released as a part of the Cn-Fi-eHP-project's work (Luukkonen et al 2008). In addition to this case material, general national guidelines from China and Finland, as well as various specifications and approaches from international standardization and research, as well as external material about Chinese healthcare and standards landscape (e.g. IBM 2006, Zhang et al 2007, Lee et al 2007), and more detailed background from the previous projects (e.g. Jiang 2005) are utilized.

In most cases, as in the case examples introduced in this report, the specification and implementation of the interoperability solutions is done in relation to several already existing applications. E.g. the whole infrastructure cannot be built from scratch, but a long line of legacy solutions and limitations set by the infrastructure must be considered.

This is the situation especially in hospitals, for example one hospital in the Pudong pilot has as many as 66 different applications (which resembles situation in western countries). In many hospitals, many of the main systems are built by only one vendor, but in comparison to CHCs, the vendor landscape is more heterogeneous in general. Many hospitals also have their own systems development teams or departments. In cases where an external vendor is used, the hospital may have 4-7 in IT staff, the yearly IT budgets varying from 400 000 RMB to projects with total investment of 5-10 million RMBs for hospital IT. Enterprise IT architecture plans are rare. The typical basic functionality of hospital systems includes admission / discharge / transfer functions, outpatient functions, patient billing, medication, query functions for management, nurse workstations and often doctor workstations. Many hospitals have laboratory information systems and basic electronic patient record systems including diagnosis, and several systems have some integrations or interfacing capabilities, and different applications are executed on 4-8 servers typically (often with little backup capabilities). Local area and regional networks (such as Pudong health information network) are widespread.

In community health centers, the systems portfolio is much more focused, often with one main vendor delivering most of the functionalities and applications for different uses (typically 1-2 servers). In CHCs, basic functionality often includes admission / discharge / transfer functionality, patient billing, summary queries for the management, and doctor and nurse workstation user interfaces. EPR or diagnosis systems are not used in many CHCs. One workstation is typically used by more than one users, both for doctor and nurse workstations.

Many hospitals and CHCs are connected to the regional network which enables solutions and applications on regional level. However, most use of the regional network has been focused on the use of public health applications.

It must be noted that the definitions of concepts often differ to some extent from the traditional western definitions, for example "EHR" - electronic health record is often considered to include

(6)

personal and family health information, including procedures, health factors, administrative and clinical aspects, information on examinations and procedures, and also information to support the management of healthcare delivery.

1.2. Most urgent needs of users and administration

Some of the most relevant problems analyzed and gathered for the Pudong pilot project, as well as health information sharing in Shanghai and China in general, include:

the lack of health information standards and guidelines

the need for many interfaces between systems and difficulties in supporting all the needed connections efficiently

the lack of qualified information technicians varying levels of hospital information systems

low or non-existent budgets for information systems development and maintenance (it has been estimated that more than 80% of healthcare centres have no annual IS development budget)

the integration level between applications within hospitals is low

communication networks within healthcare facilities and between them have been already built, but information services and applications do not make full use of them

the level and interoperability of applications have to be improved to support both patient and provider based information needs, to improve the efficiency of healthcare delivery, to enable better leadership and management decision support, and to improve work along the care pathways of the patient.

Many of these issues set barriers to regional and inter-organizational information sharing. For example, the development and effective deployment of electronic referral and discharge between CHCs and hospitals requires overcoming many of these challenges. Furthermore, in addition to technology solutions, this also requires enforcement of policies between primary and specialized care, and piloting in specified domain such as maternity. This report, however, focuses on specification of interoperability between applications.

Some concrete needs related to the integration of applications include: improving the integration level of applications within hospitals

building more comprehensive and usable doctor workstations which can be extended with new functionality in hospitals and CHCs

introducing new systems related to specific new medical technologies or the needs of different specialities and clinics

the unification and extension of information and functionality required from electronic patient record systems in hospitals and CHCs

developing IT solutions for digital health centers

integration of information used in CHCs and hospitals to the public health surveillance and quality assurance

enabling regional information sharing solutions across organizations (clinical and administrative information) both for public health surveillance and reporting, and care delivery building referral / feedback processes and systems between various healthcare organizations

(7)

building support for care chains from patient perspective, and to diagnosis-related recommendations for treatment.

These needs align to most extent with those reported from detailed study of maternity pathway (Luukkonen et al 2008) and previous projects (e.g. Jiang 2005), but also contain some specific emphasis on interoperability.

1.3. Generic Classification of integration needs and solution principles

The categories of Enterprise Application Integration (EAI) solution models include information-oriented, service-information-oriented, process-oriented and user-oriented integration (Linthicum 2000). One of the approaches is typically the most evident in one integration solution, but each integration problem can usually be solved also by using or combining different models.

Information-oriented integration uses information exchange, databases and APIs that produce information. In this approach, source and target systems typically need only a few changes; state, logic and sequence do not need to be considered; and the approach is simple and widely used. The examples of information-oriented approaches in healthcare include HL7, EDIFACT or DICOM messages and HL7 CDA documents. Information-oriented integration typically also emphasized semantics, data types and metadata management.

Process-oriented integration produces a layer of defined and centrally managed processes on top of existing processes to support the flow of information and control logic between them. The solutions often include integration servers, distributed objects or workflow and process engines. It is necessary to clearly define and understand the processes in the organization or the community to produce process-oriented solutions. Workflow-oriented IHE integration profiles are an example of process-oriented integration definition in healthcare.

Service-oriented integration allows applications to share common business logic, functional services or methods. This is accomplished by defining interfaces of shared methods and by providing the infrastructure or middleware for the communication and method invocation. This approach promotes reuse, reduces the need for replicating methods and data in several applications, and enables information-oriented and process-oriented integration by providing the required infrastructure. Examples of service-oriented integration in healthcare include Object Management Group (OMG) Healthcare specifications (e.g. PIDS, TQS) and Healthcare Services Specification Project (HSSP) specifications. Service-oriented integration solutions may require changes in legacy applications such as adaptation into the common infrastructure.

User-oriented integration allows the user to gain a consistent view for several systems or underlying services. This can be accomplished by using a unifying front-end system (e.g. portal or front-end workstation application) or by synchronizing the various applications on the user workstation. This approach focuses on the single-user aspects, and the applications are not necessarily directly integrated on data or service level. The examples of user-oriented integration include healthcare professional portals and the CCOW context management standard from HL7, and more detailed specifications utilizing these standards such as IHE Patient Sychronized Applications (PSA) integration profile.

In this report, we use this division of integration types to:

classify the main nature of specific integration needs (relating identified interoperability needs to different integration types)

based on the classification, provide some architectural blueprints for different types on integration solutions

identify relevant standards and specifications

In many cases, the solution combines features from different integration types, but it is useful to define and name the primary approach as one of the specified options.

(8)

2. Specifying the integration solutions

In this research the basics of practices and methodologies are introduced to start modeling and arranging the infrastructure of an healthcare organization in order to create more easily adaptable architecture to answer the emerging information sharing and integration needs.

EA (Enterprise Architecture)

One of such practices is Enterprise Architecture (EA), a common practice for aligning organizations business processes and IT infrastructure. EA is a high level viewpoint to start developing the information systems infrastructure in a way that the resulting solution supports the business processes of the environment. Selected parts of the EA-practice are introduced and applied on the example cases in the target environment.

Enterprise Architecture framework is a tool used to organize and focus the complex task of describing all the necessary aspects of the enterprise architecture. The framework groups the different areas needed for the entire architecture description usually into the following viewpoints: Business, Applications, Information and Technology.

Diagram 1: Different viewpoints of Enterprise Architecture

The practical methods for managing the Enterprise Architecture, such as Zachman framework (Sowa & Zachman 1992), TOGAF (Open Group 2007) and RM-ODP (ISO 1995) frameworks are designed for documenting the enterprises architecture for development purposes. For example a model like Zachman framework does not prescribe the notation used to describe the aspects, but leaves these considerations on the actual implementation level of the specification or modeling work. In this research a few examples of the documentation and on how to gather information to describe the necessary levels (Applications architecture, Technical architecture, Information architecture, Business architecture) for further development are instructed. As an example of development efforts there are few outlined solutions in the theme of information sharing built upon the current status descriptions and gathered information.

(9)

SOA (Service Oriented Architecture)

SOA (Service Oriented Architecture) is a methodology, which is an emerging development model for the interoperability solutions. The basic idea of SOA is to see the functionalities of systems as services, which participate in the business process to deliver the necessary outcome for the operations performed in the organization. SOA can be utilized as methodology for developing systems, composing the applications of interoperating and reusable components e.g. services, as well as SOA can be seen as a methodology for systems integration. For enterprise architects SOA is a tool with built-in capability for enabling the information sharing between different systems.

SOA and EA working together:

In the next few chapters the common development topics of SOA (and SOA related) and EA-development are being outlined by the three different EA viewpoints:

Interoperability

The business processes are recognized and defined in the Business architecture domain of the Enterprise architecture work. The mapping of the applications is done in as a part of the Business architecture work, but is also considered in more detail in the Applications architecture domain. SOA offers a natural extension to Enterprise Architecture in implementing the different computable outcomes of the architecture, such as BPEL (Business Process Execution Language), WS-CDL (Web Services Coreography Descriptions Language) or WS-Coordination used to compose and to control the execution of the process steps in the actual SOA implementations. SOA methodology is also used in implementing the process participants, the applications (services) and the interactions (the messages).

Information to be shared

There are many ongoing efforts to develop the high level information models i.e. reference information models or common information models to uniformly specify and describe the essential data in business domains such as: healthcare, federal services, travel industry etc. The information models are abstracting the application level data and formats to domain level and in some cases beyond the domain boundaries to enable the sharing and discovery of the information in different systems. The standardized form of the data derived from the information model is utilized in the operations executed by the services to exchange the needed information on application and enterprise information sharing in SOA enabled environment. The result of this development is a useful tool for enterprise architects to have an implementation ready/oriented data model to be utilized as a part of the organizations Data architecture and in development of information exchange between applications and organizations.

Implementation technology

SOA provides tools and infrastructure to develop interoperable solutions used to produce the actual implementations of the services and interactions in business processes. Web Services as a communication technology of SOA provides many readily built versatile services and models to be utilized as a part of the infrastructure and to be consumed by applications.

Summary

Both introduced methodologies (SOA/EA) have gained ground as the development and management practices for information technology and system environments. As the needs to control ever increasing amount of solutions in the environment emerges with a similar need build interoperability between the solutions, have these practices been selected for tools to provide the needed answers.

SOA and EA complement each other, while EA provides the big picture, the overall approach for developing the organizations IT infrastructure by aligning the business needs and information systems development, SOA gives useful tools and components (data models, interaction models,

(10)

technology) to implement the overall vision. SOA and EA are concerned on the same aspects of the information systems and their development on different, but sometimes overlapping levels. The SOA methods, specifications and standards are concentrated on the implementation aspects, which also have to be applied in the actual context of the domain, the lanscape and overall business needs of the enterprise, which is delivered by the EA.

SOA approach has been welcomed as a useful supplier of tools to extend the Enterprise Architecture work on more detailed level and to enable the information to be exchanged between the applications. As such the SOA methodology can influence all the Business, Applications, Data (Information) and Technical architecture domains of EA-practice.

Recently the proposed marriage of EA and SOA has gained more and more attention. The work on matching these two methodologies has been started and discussed in many levels. The enterprise architecture frameworks have been seen possible to be updated in order to take advantage on the benefits SOA offers. For example The Open Group (developer of TOGAF, a framework for the enterprise architecture development) has started a SOA Working Group to analyze the relation of SOA and EA and to support enterprise architecture work utilizing SOA (e.g. Dico 2008).

2.1. Inputs needed for the solution

2.1.1.Overall process for integration specification

The following figure illustrates the overall process for specifying integration solutions (Mykkänen et al 2003).

1. What: Model the integration domain 2. Where: Examine application architecture 3. How: Examine technical infrastructure 4. How: Identify functional interfaces and select their style

5. How: Choose integration technology

7. How: Choose tools and products for

integration 6. How: Specify technical interfaces -integration requirements

-functionality in existing applications

-application architecture

-application infrastructure

-functional integration points -semantic mediation requirements

-functional and semantic standards

-technical standards

-new methods, tools and technologies -integration points in application architecture -existing application infrastructure -technology-neutral functional interfaces -semantic mediation for interfaces

-new application infrastructure -integration technologies -technology-specific functional interfaces Integration profile specification S P E C IF IC A T IO N IT E R A T IO N , V A L ID A T IO N

(11)

The main phases of the process include:

1. Elicit and document the requirements for the integration situation

2. Examine the architecture of the participating applications and specify the architectural constraints for the integration solution

3. Examine the technologies or technology recommendations available in the existing applications and the integration environment to refine the technical integration solutions 4. Define the interfaces (data, functionality) for the integration solution

5. Select and refine the integration technologies for the solution

6. Specify and refine the interface specifications based on results of phases 4 and 5 7. Select tools and products for the implementation of the integration solution

In this report, we focus on phases 1 to 6. Basis for phase 1 in our example case has been outlined in Report 1 Current state description. The following describes how to the Enterprise Architecture work and the process of specifying a single integration solution are tied together e.g. what parts of the Enterprise Architecture decisions affect the phases of specifying the integration solution.

2.1.2.Main requirements – describing the business case for the integration (phase 1)

For an overall description of the requirements pointing out the needed solution are several different forms of descriptions available. The useful tool for the communication between the different stakeholders and levels of professionals (decision makers, domain experts and IT professional) is the business case description. The format is used in different Enterprise Architecture frameworks as a part of the Business architecture (like TOGAF) and project management methods (like Prince2) and applied in the information technology development. Business case is a description of an IT related task, which is used to justify reasons for a development project on different levels throughout project’s lifecycle. Describing the business case for an integration solution is made to ensure that the task: the investment needed and the resulting benefits are also aligned with the business needs of the company or the organization. Business cases are used to explain the investment for the management of the organization by making it evident that the IT related project or a task is necessary for the business also by monetary reasoning.

The business case should be kept up to date during the execution of the project. The description should be reviewed in certain checkpoints to make sure that the reasons for the development are still valid and the effort is delivering the expected benefits.

The contents of the Business case documentation can vary depending on the maturity of the basic idea and amount of the unsolved items. The format of the business case can be decided in the organizations. It varies from informal descriptions to a formal plan resembling a project plan with emphasis on the business viewpoints. The business case includes/can include the following parts:

reasons and justification of the project

business opportunities and alignment to the business strategy allocation of resources: involved work, expected costs and schedule risk analysis: factors that may impact to the success of the project

The details and amounts mentioned in the Business Case proposition are at first estimates becoming more accurate as the specification work progresses. The main points of Business case are used as a part of the Task list for describing the integration solutions in this document to bring out the business viewpoints of the outlined solutions (Chapter 2.2.).

(12)

2.1.3.Participating applications (phases 2 and 3)

There are a few architecture viewpoints and architectural domains, which concern the applications and their functional relationship to each other in the enterprise environment. These different levels of descriptions can be also utilized in finding the potential integration points. The architecture domains are: Applications architecture, Technical architecture or Software architecture and Information architecture. They all are parts of the Enterprise architecture in the practice to describe the current state and to plan the development of an enterprise environment aligned with the business strategy of the organization. There are several different patterns recognized in each domain as the best practices how to solve certain types of recurring problems. Various classifications are used to identify the different patterns needed to solve a certain type of a problem.

Relevant Architecture domains:

Applications architecture (phases 2 and 5)

Applications architecture focuses on the level of applications, their interactions and data shared in the interactions between the systems forming the application base of the organization. Applications architecture is also the level where the integration needs between the different systems can be identified and organized to a migration plan stating the steps leading to newly arranged architecture to more accurately match the current business needs of the organization. The roadmap descriptions of the architecture are usually made in three different levels describing different development stages of the enterprise architecture. The stages are: current state, intermediate (a migration plan) and the target descriptions. The application maps introduced in this document (Appendices 1-3) can be seen as parts of the current state descriptions of the Applications architecture, in this case describing only certain parts of the whole enterprise, limited in the context of Maternity Pathway. The proposed solutions for the recognized needs in the information sharing (Chapter 4) can be utilized in creating the target descriptions for the enterprise. The short term targets can also serve as the intermediate descriptions of the architecture, as the focus in developing the health information sharing has an emerging tendency of shifting for example from the regional level solutions (the current target of the environment under research) to national level solutions. This direction of development has been seen in many countries investing in the health information services.

Technical architecture (Software architecture) (phases 3 and 5-7)

In the Enterprise Architecture domains Technical Architecture is seen as a part of the Software Architecture or as a synonym to Software architecture. Technical Architecture is concerned of the design and behavior of a single application or an infrastructure service, as the main difference to the Applications architecture, which deals with interoperability and collaboration between the applications in the enterprise.

The relevance of this architectural viewpoint for the enterprise level integration and information sharing solutions comes from the work that is done in this level in partitioning the functionality of a solution to different components and services. Recognizing the reusable components or services to be used in the other applications is done as a part of this partitioning work. Among these components are also the potential candidates for the core/common services needed and consumed by other applications in the infrastructure. These services can also act as reusable integration solutions in the organization level. Naturally SOA contains several architectural patterns in the Software architecture level.

(13)

Information architecture (Data architecture) (phases 1,2,4-6)

Information architecture is concerned of developing and documenting the data used and shared in the organization in and between the information systems. Different aspects and tools to further develop and analyze the existing data are: use and construction of data models for defining the data entities and their relationships and on top of that the metadata to describe these enterprise data elements.

The results of this work can be used and applied in constructing the integration solution, the documented data models can be uses as-is in the information exchange utilizing the mediation services to translate the data. But also building the information exchange is a point to start the further development of the data models for example with the help of high level data models to create standards based data sets for the enterprise information sharing. The benefit of this development effort are realized in the possibility of having a tool support for the building of the integration solution and also better capabilities for the cross enterprise information sharing.

2.1.4.Potential information and functional standards and specifications (phase 4 - 5)

medicine and healthcare in fo rm a tio n m o d e ls a n d e le m e n ts te rm in o lo g ie s , c la s s ifi c a tio n s , c o d e s p ro c e s s e s , p a th w a y s q u a lit y o f c a re g u id e lin e s , k n o w le d g e a rc h ite c tu re healthcare IT and IS s u p p o rt fo r i n fo rm a tio n s o lu tio n s e le c tr o n ic c lin ic a l d o c u m e n ts m e s s a g e in te rfa c e s a rc h iv in g a n d lo n g te rm s to ra g e s e rv ic e a n d A P I i n te rfa c e s s u p p o rt fo r p ro c e s s e s s e c u rit y a n d c o n fid e n tia lit y

IT, domain-neutral and cross-domain e le c tr o n ic h e a lth r e c o rd s

standardization relevant to eHealth and HIS

d a ta c o m m u n ic a tio n s id e n tif ic a tio n e G o v e rn m e n a n c e a n d a rc h ite c tu re e le c tr o n ic d o c u m e n ts m e s s a g in g a n d e n v e lo p in g in te rfa c e te c h n o lo g ie s p ro c e s s d e s c rip tio n a n d d e fin iti o n s e c u rit y s o ftw a re p ro d u c tio n / d e v e lo p m e n t

Diagram 3. Standardization areas related to interoperability in health information systems.

There are various standards available to support interoperability in eHealth domain (See Diagram 3). The interoperability standards are typically used in phases 4 and 5 of the integration specification process, but many of them can be also used in the requirements phase as one of the basis or blueprints. The most relevant standardization domains for specific integration needs include:

High level data models, standards and specifications, such as nationally defined core data sets, HL7 RIM and domain information models

Functional standards for electronic health records, such as HL7 EHR functional model standards

Standardized message and document specifications such as HL7 version 2 and version 3 messages, EDI and HL7 CDA R1 and R2

the enabling information integration technologies such as XML and its applications (phase 5) the enabling service integration technologies such as WSDL and other interface definition

(14)

the enabling process integration technologies such as BPEL and modeling notations such as BPMN

the enabling user integration technologies such as portal standards open communication and data transfer technologies.

Many technical specifications apply basic XML technologies such as Schema, XPath etc. whose obvious benefits include platform neutrality and human readability. In this report, we do not consider platform specific aspects (such as implementations using Java Enterprise Edition or .NET platforms), as modern development tools and execution infrastructures typically support platform-neutral interfacing and communication protocols.

2.2. List of questions to help in producing solutions and examples

Motivation – Why the checklist is used?

These questions can be used as a checklist to provide a systematic approach to start analyzing the integration and information sharing needs. A starting point to this process is a list that requires different stakeholder to match their solutions, products, and services against specified goals and requirements. The list can be used as an inventory of things that have been already considered or decided and also listing the aspects that are still untouched, but need to be addressed.

It should be noted that only those aspects of the solution which deal with integration and interoperability should be described. Thus, not the internal solutions of each of the applications need to be described unless they directly influence the integration situation.

The viewpoints - For who is the list intended?

The list can be used as a common base of communication between different stakeholders of the integration needs.

Different viewpoints:

purchaser: who wants to purchase or develop the interoperability solution (e.g. IT staff) vendor: as a description of the solution or gathering the needs from the client

expert/consultant: as an outline the solution for consumer or the vendor

How to use the Framework

List of questions to cover and to remind of different aspects needed in outlining the integration solutions and can be used iteratively in the different phases of the project to help in coordinating the different areas of specification process. Every question can’t be answered depending on the needed details and maturity of the project.

Keywords: depending on the stage of readiness of the project, there can be different level of decisions or propositions. These can be marked with different keywords e.g. suggestion (for solutions to be considered), minimum/preferred (for the level of the suggested solution) etc., for example:

Used data standards or specifications, specify: What data standards or specifications are used?

suggestion: HL7 CDA R2 for the clinical data

Example of the notes made to define or help deciding the data format in Form 2: Information and semantics.

(15)

Background of the framework

This checklist is based on “An evaluation and selection framework for interoperability standards”, a conceptual framework which was developed for the systematic evaluation of interoperability standards. The Framework itself was based on the work done in PlugIT- and SerAPI-projects in University of Kuopio (Mykkänen et al 2008).

The structure of the question list:

The question list is divided in the following five categories:

Scoping the solution:

An overall description to explain the basic requirements for the solution, as well as the business case supporting the acquisition. Also this section is charting the environment demanding the solution, such as regulatory compliance issues.

Information and semantics:

The questions are used to identify the shared information and to describe the usage of the data in the solution. References to the already selected or suggested data standards can be stated in this section.

Functionality and Interactions:

The part concentrates in describing the functionality of the proposed solution. Use of different levels of models, notations and descriptions are described.

Application infrastructure:

The architectural parts like applications and other functional components needed for the solution are recognized, along with the solution principles.

Technical aspects:

Section includes more detailed inventory of the technical options and decision for the solution.

(16)

2.2.1.Scope of the solution

Scope of the solution

Name of the solution/project:

An overall description of the solution:

Main requirements for the solution:

Description of the business case:

Domain of the solution (e.g. Healthcare, Administration, Domain Independent etc.):

Sub Domain(e.g. Laboratory, Human resourcesetc.):

Is the solution used (e.g. information shared) in:

[ ] local level [ ] regional level [ ] national level References to other relevant work:

Specifications, documentation (project plan etc.):

Administrative regulation:

Information and semantics

What information is shared or transferred (an overview)?

Describe the use of the shared information:

Is the data needed in other contexts or use cases (definitions reused, information sharing on region-al/national level)? Describe

Used data standards or specifications, specify: What data standards or specifications are used? High level information model or concept model: Code sets (Classifications, Vocabularies, Terminology):

Other data sets (application specific, proprietary etc.):

Need for additional data services Data transformation or

mediation service

[ ] Yes [ ] No If yes, specify:

Code Services [ ] Yes [ ] No If yes, specify: Anonymisation [ ] Yes [ ] No If yes, specify: Others, specify:

(18)

2.2.3.Functionality and interactions

Functionality and interactions

Interactions (functions or operations between systems) Number and description of main interactions?

Standards, methodologies used in the functionality, specify:

Tools used, specify:

Workflows (tasks by users, links of tasks to applications) Number and description of main workflows?

Viewpoint of the modeling (which actors included, what are main information flows):

Standards, methodologies used, specify:

Process (phases between organizational units, high level process descriptions) Number and description of main processes?

Viewpoint of the modeling (which units included, owner of the process, inputs and outcomes of each main phase of the process):

Standards, methodologies used, specify:

Other (use case descriptions etc.), specify:

(19)

2.2.4.Application infrastructure aspects

Application infrastructure aspects

Participating applications:

Are the participating applications and services specified/recognized? Yes [ ] No [ ] If yes, specify (application names, roles, status [existing, to be purchased, under construction], owner):

Are there any architectural specifications (application maps, target architecture etc.)? Specify for current and future state:

Is the basic integration principle:

a) information transfer or sharing [ ] Yes [ ] No If yes, specify: b) service or API invocation [ ] Yes [ ] No If yes, specify: c) process or workflow coordination [ ] Yes [ ] No If yes, specify: d) unified or synchronized view for

the end user (e.g. desktop inte-gration or portal)

Is the solution intended for: a) multiple users (e.g. distributed

service, common serviceetc.)

b) single user (e.g. user interface, workstation level, user-specific sessions etc.)

Describe the following interoperability features, if needed in the solution? a) location or discovery of

participating systems or components

b) invocation model (messages, events, application programming interfaces)

c) shared or mediated information semantics (where is the meaning of data specified, is there media-tion between the participating applications)

d) direct (point-to-point) or me-diated communication (is the communication directly between

(20)

systems or using integration plat-form or bus?)

e) coordinated information or communication (is there a coor-dination layer e.g. workflow or process engine or integrating us-er intus-erface in the solution?) f) unidirectional or bidirectional

invocations (are the invocations initiated always by one of the participating applications, or va-ryingly initiated by different ap-plications?)

g) synchronous or asynchronous communication (is there a re-quest/reply communication or simple send "fire and forget" communication?)

h) state management (is there a shared session, context etc. spe-cified in one or several of the components of the architecture, specify)

(21)

2.2.5.Technical aspects

Technical aspects

What are the technology solutions to the following? a) Interface technology for data

(e.g. XML or HL7 protocol speci-fied)

b) Other data access mechanisms (e.g. database middleware, SQL, ODBC, JDBC)

c) Data transformation technologies

d) Interface technology for functio-nality or interactions (e.g. Web services, WSDL, CORBA, DCOM API technologies)

e) Communication technologies (network protocols, wire formats etc., e.g. SOAP, DCOM)

f) Integration platform (ESB, mes-sage brokers etc.)

g) Session or transaction manage-ment (e.g. ACID transaction pro-tocols)

h) Addressing or discovery for the services (e.g. service registry, UDDI)

i) Encryption or certificates (e.g. SSL, https, digital signatures) j) Presentation technology of

in-formation or functionality to the user (e.g. html / ASP/JSP pages) k) Operating systems or supported

platforms (runtime infrastruc-ture)

l) Development tools, program-ming languages etc.

(22)

3. Generic recommendations for different integration types

Recommendations in this chapter are based on the pilot experience, international and Chinese viewpoints, and discussions with international, Finnish and Chinese partners.

3.1. Information integration

utilize national core data sets defined for specific subdomains as information reference models for local integration solutions and product development, where possible; keep the modifications to the core data sets as minimal as possible

define or select codesets and terminologies which will be used across institutions for regional information sharing, and arrange procedures to import them to various different systems (e.g. using central repository or in the future shared terminology services); especially refine the defined core data sets with the specified code sets and terminologies

as part of the holistic approach for integration, it is necessary to support several different information integration needs, but basic types of information integration should be specified with uniform standards and approaches; the most important ones being (in first phase):

o HL7 version 2 messaging with the support of interface engines and platforms, messages based on the defined core data sets

o document-oriented information exchange (preferably CDA R2 with structured and coded information) for clinical documents, potentially starting from the utilization and sharing of CDA R2 Laboratory reports using IHE XD-Lab specification

o the gradual reduction of data sheet integration which is directly related to the mapping between database tables, and move towards message- and document-based information integration.

for each central information set, define whether it should be centrally stored or stored in various different systems (on local hospital and CHC level, on regional level) - for most reusable information (needed in many applications), aim to develop central information repositories and define master data management and provisioning or query solutions to deliver the needed information to the separate applications. For central repositories, develop data quality assurance services.

use patient identifiers and patient basic demographic and family information as the starting point for master data management solutions mentioned above. Gradually extend the information contents towards clinical core data sets.

3.2. Functional integration

utilize functional model standards such as HL7 EHR-S functional model as the primary source of functional requirements for new applications and extensions to existing applications, instead of direct application product features, perform functional and information modeling separately from application products

identify functionally oriented integration needs (e.g. calculation, complex queries, functional operations of specific components) and specify blueprints for the definition of functional services (reusable core services) to gradually support migration to SOA-based architecture, especially for new applications

implement above defined functional interface specifications to existing applications, when their functional features should be integrated with other applications

3.3. User integration

Reduce / try to keep down the number of simultaneously used separate applications or user interfaces for one user: specify unified portal-based solutions and front-end applications for target state but prefer separating them from underlying services.

(23)

Prefer programmatic access to shared data via applications which are already used instead of introducing new (web) applications.

Especially integrate shared electronic patient records with DWS, and build additional features for DWS enabled by structured core data sets and coded information (e.g. decision support) Consider the introduction of context management solutions or services to enable lightweight

user integration (single sign-on, patient synchronization) for DWSs which include the use of several applications for the treatment of one patient.

3.4. Process integration

In addition to identifying most urgent integration needs related to data transfer and sharing, analyze in more detail the needed use situations and processes where information is used before proceeding to the development of integration solutions

In process models and identified information flows between different actors, identify reusable information and reusable functional capabilities of participating components, which can be supported with solutions

Based on the analysis of the workflows and processes, identify workflow improvements, and produce flexibility into workflows by using generic service and process definitions, gradually building support for workflow management and modification using process engines.

4. Examples of integration

4.1. Examples based on current state descriptions

There has been noticed various bottlenecks in information sharing in the Describing the current state of health information management and sharing report. In the following, one of the problems is reviewed based on the findings in the aforementioned report and different levels of solutions are introduced. The solutions are illustrated and developed on the diagrams of the current information system maps related to maternity pathway (see Diagrams 4 and 5) and the introduced questions framework is also used to outline each possible solution.

Description of the problem in the example case

The basic problem was that no information is transferred between the two organizations East Hospital and Weifang Community Health Center or the information arrives too late to be useful. The proposed solutions concentrate on the case when mother is discharged from the hospital after the delivery and the responsibility of the further care is taken by the community health center. The community health center should have the information of the date when the mother has been discharged in order to start the postnatal care. In the current procedure the staff of CHC starts trying to contact the mother after the date estimate, which is based on the estimate of birth date. This procedure is seen as resource consuming task and causes amounts of unnecessary work.

(24)

China-Finland e-Health Partnership 24 (60) CDC East Hospital Weifang CHC Regular visits 9 times Home Maternity management system Call to remind if not

coming Admission Delivery Regular examination results Discharge Centralized data base Last pages of Maternity Card by post After 16 weeks of pregnancy Delivery time EPR,LIS etc. use: only inEast Hospital If mother is not reached, calling CHC Telephone Copy of discharge summary Maternity Card Patient Card Maternity Card Patient Card Visiting schedule Regular examination results ? ? Specilized hospital LIS, dr.workstation etc. use integration? Inpatient data Telephone Consultation Lab test orders & results by post Agreeing follow ups Telephone Maternity health record Manual work CHC in other district Collecting and sending further Reference letter Few days before estimated time

Info can be used only in East Hospital

Maternity Card Patient Card Maternity and Child Healthcare Center insurance e-card East Hospital e-card Receipt of paymentReceipt of payment Receipt of payment Receipt of

paymentReceipt of _payment

Receipt of payment insurance e-cardEast Hospital e-card Notification letter Outpatient clinic Inpatient clinic EPR not in use in outpatient clinic

Diagram 4. Process for late pregnancy and delivery

In the Diagram 4 it can be seen that the information about the delivery is typed in the Maternity Management System and then stored in the CDC’s Centralized data base (the Discharge step in the Diagram). The information cannot be used in any other organization, because only input of the information is enabled in this regional data storage.

The information is received by the Community Health Center in paper format (Last pages of Maternity Card in Diagrams 4 and 5). In this case the information is routed via another

(25)

organization (Maternity and Child Healtcare Center) and the needed papers arrive the Community Health Center too late to prepare the after delivery care program.

CDC East Hospital Weifang CHC Maternity and Child Healthcare Center Home Baby checking Maternity and child health IS Closing case and archiving Information available only in Weifang CHC Appointment time for home visit

Centralized data base Last pages of Maternity Card Information transfer late by post, arcieved in CHC 2-3 home visits Discharge summary Telephone Visit Notes

30 days after delivery Before and after estimated delivery time

~7 days after delivery

Useful information for home visit Maternity health record For archiving only e-insurance card Insurance organization EHR,LIS, dr.workstation etc. use? integration?? No information transfer Visiting schedule Call to remind if not coming

42 days after delivery

Physical check Telephone Regular examination results Inpatient data e-insurance card Creating electronic maternity health record Centralized data base Duplicate work Payment info + all receipts Return money Maternity health record No information transfer Information transfer bertween GP and public health provider Maternity Card Patient Card Maternity Card Patient Card Maternity Card Patient Card WeifangCHC e-card East Hospital e-card Different e-cards in each hospital

(26)

4.1.1.The example solutions

The development points for the inter-organizational information sharing, described in the previous section, are outlined in the Current Status report the following way (Development points in information sharing p.37):

The last pages of the Maternity Card often arrive in Weifang too late to be used in planning home visits. (Development point I)

A centralized database is not used in all facilities at this moment; and only input is possible.

(Development point II)

There is no transfer of clinical or delivery date information between East Hospital and the Weifang CHC. (Development point III)

Maternity management system is not integrated with other systems (Development point IV) The basic problem is lack of the information sharing between the two organizations, which is clearly stated in the third development point. The main requirements or the business case for all the proposed solutions is the same: reduction of the unnecessary work by enabling the information sharing between the organizations. The proposed solutions show some variations, when being inspected from the different architectural viewpoints.

In the following three solution models based on the stated problem are introduced and illustrated with the examples drawn on information system diagrams (see Current state in Diagram 6). The last of the proposed solutions is also described in more detail using the previously introduced questions framework (Forms 1-5), also to show an example of the usage of the proposed model.

EHR Maternity and Child Health system Homecare data gathering (PDA) - system? DWS (Doctor Workstation) LIS HIS Outpatient registration and payment (invoice) Admission and discharge management Pharmacy management Hospital management inquiry system Invoicing and

Billing system Appointment system Diabetes Hypertension Immuninzation Clinical information Clinical information ePrescription Consultation Test order Orders RIS/ MiniPACS Financial and human resources management system Other organizations: Insurance organization

Birth Control Office

Other Healthcare organizations Different level hospitals

East Hospital

EPR system

Matermal and child healthcare center CDC Regional public health data Maternity Management System Patient and family information NWS (Nurse Workstation)

Diagram 6. The information systems and organizations related to the Maternity case. The Community Health Center’s system environment on the left and other related organizations and their systems related to the problem area on the right.

(27)

Solution example 1: point to point

The most evident and also the simplest solution to the basic problem is introduced with two versions of the model: building a point to point integration between the organizations lacking the information exchange: Solution examples point to point 1a: PUSH and b: PULL.

Solution example 1a: point to point – PUSH

Billing system Appointment system Diabetes _Hypertension Immuninzation Clinical information Clinical information ePrescription Consultation Test order Orders RIS/ MiniPACS Financial and human resources management system Other organizations: Insurance organization

East Hospital

EPR system

Delivery Inform_ation

(28)

Solution example 1b: point to point – PULL

East Hospital

EPR system

Delivery Inform_ation

Information Re_quest

Diagram 8. The delivery information, point to point: PULL.

Evaluation of the proposed models:

As we start comparing the proposed point to point solutions to the described problem, it clearly solves the main problem: the lack of information sharing between the organizations, but leaves all the other topics uncovered. Still the solution already speeds up the information transfer compared to the existing paper based workflow e.g. creates an information systems based data exchange between the organizations. The main difference between the two examples (a or b) is which of the participating applications initiates the data transfer. The solutions vary on the level of process and the functionality of the proposed solution, but the participating applications and used information content in both solutions are the same.

In the functionality both solutions are viable in case the patient’s pathway is predetermined and no variance can be made. In other words, a mother who gives birth in the East Hospital also has her postnatal care in the Weifang CHC. But this is not the case in the environment under study. The mother can freely choose the place, where the postnatal care is undertaken and as a result of this the different pathways do occur. The multiplicity in individual ways in the progression of maternal care results a huge combination of the organizations that have to be able to access each other’s data regionally. This could be resolved by connecting each organizations maternity related information systems with each other individually by point to point connections.

Business/Applications:

- no predetermined pathway for information transfer, point to point model results routing problems +the solution doesn’t require any additional applications

(29)

+ information contents: can include clinical information (EHR/EPR systems connected) - mutual agreement between two organization sufficient

Technincal:

+/- simple solution, no obvious technical limitations at this level Development points:

fulfills 1/4, Development point: III

Needed implementations/Deployments: APIs in EHR/EPR systems

(30)

Solution example 2: Deploying CDC system with desktop integration

Other Healthcare organizations

Different level hospitals East Hospital

EPR system

Matermal and child healthcare center CDC Regional public health data Maternity Management System Maternity Management System Patient and family information NWS (Nurse Workstation) Public Health data incl. Delivery Information (submit) Public Health data incl. Delivery Information (view) Context Management Service Synchronization (Shared View)

Diagram 9. Public health data of delivery information transferred using Regional public health database and viewed using a shared view in the Doctor Workstation

Evaluation of the proposed model:

It seems evident, that the proposed point-to-point models become more and more inadequate as the combination of organizations taking care of the delivery and after delivery care increases. The solution for this problem is use of a centralized database as a storage for the shared information, as it has become evident in many other national and regional implementations as well as in the Pudong area.

The solution could be achieved by developing additional features in the existing systems. The Maternity Management System, which is already used in East Hospital for storing the data after the case is closed. The system should also be able to view the data that is stored using it. The system (web application with the viewing capability) should be deployed in the community health center in order to check the delivery information from the centralized database. This also raises a need for changes the process of systems usage to enable the information sharing in real-time (or only with a few days lapse) in order for the information to be useful.

The proposed solution, even though can provide the necessary information (date of birth or more accurately the date of discharge) still falls short on information contents compared to the previous model, where the information systems containing clinical information are connected.

This model has been built to fulfill all the proposed development points (described in the beginning of the chapter) by adding also the context management to enable the usage of the Maternity Management System. This example shows also the need for EA-viewpoints to give a perspective of the whole organization to the development of the solution. It becomes evident that even though this solution fulfills all the proposed development points, it is not a versatile solution e.g. the solution brings the needed help only in the Maternity Pathway context, but doesn’t support any other information sharing need in the organization, as the next proposed solution does.