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

Transcription

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, (TEKES 40210/07)

2 China-Finland e-health Partnership 2 (60) Table of contents 1. Defining integration types, interoperability needs and cases Current state description Most urgent needs of users and administration Generic Classification of integration needs and solution principles Specifying the integration solutions Inputs needed for the solution Overall process for integration specification Main requirements describing the business case for the integration (phase 1) Participating applications (phases 2 and 3) Potential information and functional standards and specifications (phase 4 and 5) List of questions to help in producing solutions and examples Scope of the solution Information and semantics Functionality and interactions Application infrastructure aspects Technical aspects Generic recommendations for different integration types Information integration Functional integration User integration Process integration Examples of integration Examples based on current state descriptions The example solutions Scope of the solution Information and semantics Functionality and interactions Application infrastructure aspects Technical aspects Description of Regional information sharing by Weifang CHC and Kingstar Scope of the solution Information and semantics Functionality and interactions Application infrastructure aspects Technical aspects ehit example Scope of the solution Information and semantics Functionality and interactions Application infrastructure aspects Technical aspects Conclusions and recommendations References... 57

3 China-Finland e-health Partnership 3 (60) 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 ( SerAPI ( 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 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 China-Finland e-health Partnership 4 (60) Acknowledgements This paper is based on research conducted in the project China-Finland e-health Partnership (Cn-Fi ehp), funded in by the Finnish Agency for Technology and Innovation Tekes (grant no /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 SOA Service Oriented Architecture (See chapter 2)

5 China-Finland e-health Partnership 5 (60) 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 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 China-Finland e-health Partnership 6 (60) 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 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 China-Finland e-health Partnership 7 (60) 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 Generic Classification of integration needs and solution principles The categories of Enterprise Application Integration (EAI) solution models include informationoriented, service-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 China-Finland e-health Partnership 8 (60) 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 China-Finland e-health Partnership 9 (60) 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 EAdevelopment 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 China-Finland e-health Partnership 10 (60) 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) Inputs needed for the solution Overall process for integration specification The following figure illustrates the overall process for specifying integration solutions (Mykkänen et al 2003). -integration requirements -application architecture -functionality in existing applications -application infrastructure 1. What: Model the integration domain 2. Where: Examine application architecture 3. How: Examine technical infrastructure SPECIFICATION -functional and semantic standards -functional integration points -semantic mediation requirements 4. How: Identify functional interfaces and select their style -integration points in application architecture -technology-neutral functional interfaces -semantic mediation for interfaces -existing application infrastructure 5. How: Choose integration technology -new application infrastructure -integration technologies 6. How: Specify technical interfaces -technical standards -new methods, tools and technologies ITERATION, VALIDATION Integration profile specification -technology-specific functional interfaces 7. How: Choose tools and products for integration Diagram 2. A process for specifying integration solutions.

11 China-Finland e-health Partnership 11 (60) 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 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 China-Finland e-health Partnership 12 (60) 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 China-Finland e-health Partnership 13 (60) 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 Potential information and functional standards and specifications (phase 4-5) standardization relevant to ehealth and HIS medicine and healthcare healthcare IT and IS IT, domain-neutral and cross-domain software production / development security process description and definition interface technologies messaging and enveloping electronic documents egovernmenance and architecture identification data communications electronic health records security and confidentiality support for processes service and API interfaces archiving and long term storage message interfaces electronic clinical documents support for information solutions architecture information models and elements terminologies, classifications, codes guidelines, knowledge processes, pathways quality of care 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 languages

14 China-Finland e-health Partnership 14 (60) 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 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 China-Finland e-health Partnership 15 (60) 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. The following forms include the questions divided in above mentioned categories:

16 China-Finland e-health Partnership 16 (60) 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 resources etc.): 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: Other relevant documentation: Form 1: Scope of the solution

17 China-Finland e-health Partnership 17 (60) Information and semantics 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 regional/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: Form 2: Information and semantics

18 China-Finland e-health Partnership 18 (60) 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: Tools 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: Tools used, specify: Other (use case descriptions etc.), specify: Form 3: Functionality and interactions

19 China-Finland e-health Partnership 19 (60) 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 integration or portal) [ ] Yes [ ] No If yes, specify: Is the solution intended for: a) multiple users (e.g. distributed service, common service etc.) b) single user (e.g. user interface, workstation level, user-specific sessions etc.) [ ] Yes [ ] No If yes, specify: [ ] Yes [ ] No If yes, specify: 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 mediation between the participating applications) d) direct (point-to-point) or mediated communication (is the communication directly between

20 China-Finland e-health Partnership 20 (60) systems or using integration platform or bus?) e) coordinated information or communication (is there a coordination layer e.g. workflow or process engine or integrating user interface in the solution?) f) unidirectional or bidirectional invocations (are the invocations initiated always by one of the participating applications, or varyingly initiated by different applications?) g) synchronous or asynchronous communication (is there a request/reply communication or simple send "fire and forget" communication?) h) state management (is there a shared session, context etc. specified in one or several of the components of the architecture, specify) Form 4: Application infrastructure

21 China-Finland e-health Partnership 21 (60) Technical aspects Technical aspects What are the technology solutions to the following? a) Interface technology for data (e.g. XML or HL7 protocol specified) b) Other data access mechanisms (e.g. database middleware, SQL, ODBC, JDBC) c) Data transformation technologies d) Interface technology for functionality 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, message brokers etc.) g) Session or transaction management (e.g. ACID transaction protocols) 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 information or functionality to the user (e.g. html / ASP/JSP pages) k) Operating systems or supported platforms (runtime infrastructure) l) Development tools, programming languages etc. Form 5: Technical aspects

22 China-Finland e-health Partnership 22 (60) 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 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 o o HL7 version 2 messaging with the support of interface engines and platforms, messages based on the defined core data sets 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 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 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 China-Finland e-health Partnership 23 (60) 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 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) Home Weifang CHC East Hospital Maternity and Child Healthcare Center After 16 weeks of pregnancy insurance e-card East Hospital e-card Receipt of Receipt of payment Receipt of payment payment Few days before estimated time Maternity Card Patient Card Telephone Agreeing follow ups Outpatient clinic Regular examination results Info can be used only in East Hospital Telephone If mother is not reached, calling CHC Manual work Regular visits 9 times? Visiting schedule Call to remind if not coming LIS, dr.workstation etc. use integration?? EPR not in use in outpatient clinic Telephone Lab test orders & results by post Consultation Specilized hospital Maternity health record Inpatient clinic Reference letter Collecting and sending further CHC in other district insurance e-card Maternity Patient Card Card Delivery time East Hospital e-card Regular examination results Admission EPR,LIS etc. use: only ineast Hospital Inpatient data Delivery Patient Maternity Card Card Receipt of payment Notification letter Copy of discharge summary Discharge Maternity management system by post Last pages of Maternity Card CDC Centralized data base 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 China-Finland e-health Partnership 25 (60) organization (Maternity and Child Healtcare Center) and the needed papers arrive the Community Health Center too late to prepare the after delivery care program. Home Weifang CHC East Hospital Maternity and Child Healthcare Center Before and after estimated delivery time ~7 days after delivery Maternity Patient Card Card Discharge summary Telephone 2-3 home visits Appointment time for home visit Information available only in Weifang CHC Visit Notes Maternity health record Information transfer bertween GP and public health provider Information transfer late by post, arcieved in CHC Useful information for home visit Last pages of Maternity Card CDC No information transfer Centralized data base 30 days after delivery e-insurance card WeifangCHC e-card Different e-cards in each hospital 42 days after delivery e-insurance card East Hospital e-card Maternity Patient Card Card Duplicate work For archiving only Maternity Patient Card Card Payment info + all receipts Closing case and archiving Maternity health record Creating electronic maternity health record Maternity and child health IS EHR,LIS, dr.workstation etc. use? integration?? Baby checking No information transfer Visiting schedule Call to remind if Telephone not coming Physical check Regular Inpatient examination data results Return money Centralized data base Insurance organization Diagram 5. Process for follow-ups after delivery

26 China-Finland e-health Partnership 26 (60) 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. NWS (Nurse Workstation) DWS (Doctor Workstation) Other organizations: Insurance organization Clinical information eprescription Consultation Test order Orders Birth Control Office RIS/ MiniPACS LIS HIS Outpatient registration and payment (invoice) Pharmacy management Invoicing and Billing system Homecare data gathering (PDA) - system? Admission and discharge management Hospital management inquiry system Appointment system Financial and human resources management system EHR Maternity and Child Health system Immuninzation Diabetes Clinical information Hypertension Patient and family information Other Healthcare organizations Different level hospitals East Hospital Maternity Management System CDC Matermal and child healthcare center EPR system Regional public health data 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 China-Finland e-health Partnership 27 (60) 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 NWS (Nurse Workstation) DWS (Doctor Workstation) Other organizations: Insurance organization Clinical information eprescription Consultation Test order Orders Birth Control Office RIS/ MiniPACS LIS HIS Outpatient registration and payment (invoice) Pharmacy management Invoicing and Billing system Homecare data gathering (PDA) - system? Admission and discharge management Hospital management inquiry system Appointment system Financial and human resources management system EHR Maternity and Child Health system Immuninzation Diabetes Clinical information Delivery Information Hypertension Patient and family information Other Healthcare organizations Different level hospitals East Hospital Maternity Management System CDC Matermal and child healthcare center EPR system Regional public health data Diagram 7: The delivery information, point to point: PUSH.

28 China-Finland e-health Partnership 28 (60) Solution example 1b: point to point PULL NWS (Nurse Workstation) DWS (Doctor Workstation) Other organizations: Insurance organization Clinical information eprescription Consultation Test order Orders Birth Control Office RIS/ MiniPACS LIS HIS Outpatient registration and payment (invoice) Pharmacy management Invoicing and Billing system Homecare data gathering (PDA) - system? Admission and discharge management Hospital management inquiry system Appointment system Financial and human resources management system EHR Maternity and Child Health system Immuninzation Diabetes Clinical information Information Request Hypertension Delivery Information Patient and family information Other Healthcare organizations Different level hospitals East Hospital Maternity Management System CDC Matermal and child healthcare center EPR system Regional public health data 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 Information:

29 China-Finland e-health Partnership 29 (60) + 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 China-Finland e-health Partnership 30 (60) Solution example 2: Deploying CDC system with desktop integration NWS (Nurse Workstation) DWS (Doctor Workstation) Other organizations: Insurance organization Clinical information eprescription Consultation Test order Orders Birth Control Office RIS/ MiniPACS LIS HIS Outpatient registration and payment (invoice) Pharmacy management Invoicing and Billing system Homecare data gathering (PDA) - system? Admission and discharge management Hospital management inquiry system Appointment system Financial and human resources management system EHR Maternity and Child Health system Immuninzation Context Management Service Diabetes Clinical information Hypertension Patient and family information Synchronization (Shared View) Maternity Management System Public Health data incl. Other Healthcare organizations Different level hospitals East Hospital Maternity Management System CDC Delivery Information (view) Matermal and child healthcare center Public Health data incl. EPR system Delivery Information (submit) Regional public health data 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.

31 China-Finland e-health Partnership 31 (60) Business/Applications: + no routing problems, the need to create connections is limited and unified (all the healthcare organization in the area must connect to a single centralized database) +/- uses existing applications and data storage, but creates a need to build many new features and functionalities in them and needs a deployment of a new service for context management Information: - data contents at minimum (public health data) + forces to unify the used data regionally - a need to unify the patient identifier (use of the data/context synchronization) Technincal: +/- no obvious technical limitations at this level, existing models can be used (i.e. IHE XDS etc.) Development points: fulfills: 4/4 (Development points: I, II, III, IV) Needed implementations/deployments: Context management (Service/Clients) in the organization for viewing/input of the data Enabling output/view of the maternity data in the regional data center Deployment of the Maternity Management System in all the regional organizations

32 China-Finland e-health Partnership 32 (60) Solution example 3: Using Regional Data Center NWS (Nurse Workstation) DWS (Doctor Workstation) Other organizations: Insurance organization Clinical information eprescription Consultation Test order Orders Birth Control Office RIS/ MiniPACS LIS HIS Outpatient registration and payment (invoice) Pharmacy management Invoicing and Billing system Homecare data gathering (PDA) - system? Admission and discharge management Hospital management inquiry system Appointment system Financial and human resources management system EHR Maternity and Child Health system Immuninzation Diabetes Clinical information Hypertension Patient and family information Patient Data incl. Delivery Information (view) Other Healthcare organizations Different level hospitals East Hospital Maternity Management System CDC Regional Data Center Matermal and child healthcare center EPR system Regional public health data Patient Data incl. Delivery Information (submit) Diagram 10. The patient health data including the delivery information transferred using Regional data center. The next proposed solution solves the problems of previous example solutions by enabling the clinical information sharing regionally. The solution uses a regional centralized database as the data storage and the solution reduces the need for deploying any more additional information systems in the organizations by creating the connections to the existing information systems. The richer data contents can be achieved by selecting systems containing the actual care related clinical information as the systems to be connected and storing the actual clinical information in the centralized data center. Evaluation of the proposed model: Business/Applications: + no routing problems, the need to create connections is limited and unified (all the healthcare organization in the area must connect to a single centralized database) +/- needs a regional centralized database, to share the clinical information (EHR/EPR) + the model and information contents can be reused in many other different use cases (apart from Maternity Pathway) Information: - information contents: includes clinical information (EHR/EPR systems connected) +forces to unify the used data regionally Technincal: +/- no obvious technical limitations at this level, existing models can be used (i.e. IHE XDS etc.) Development points:

33 China-Finland e-health Partnership 33 (60) fulfills: Development point: III (differs from the proposed solution in the Development points) Needed implementations/deployments: Regional Data Center APIs in EHR/EPR systems Variations in the proposed models by architectural viewpoints: Business: Business case is the same in all the solutions. There is variation in the process resulting the information exchange in the different solutions. Applications: The amount and the selection of participating applications vary by the models and also has impact on the data contents of the proposed solutions. Information: The used information depends on which application and/or services are selected to participate the information sharing process. Technical: The technical solutions are not limited unless any ready-made models aren t deployed, which usually force the use of specified technologies. Solution example 3: Using Regional Data Center described using the questions framework The solution is described more detailed in the following by using the proposed questions framework. In this phase the solution cannot be described with complete specifications, but the proposed solution can be used as an outline of the actual implementation, which is one possible usage of the framework Scope of the solution Scope of the solution Name of the solution/project: Delivery information sharing An overall description of the solution: The patient information including the delivery information is sent from the organization where the birth takes place (Hospital) and gathered in the Regional Data Center. The patient information is requested by the organization where the after delivery care takes place (Community Healthcare Center). Main requirements for the solution: The organization, which takes responsibility of the after delivery care needs to know when the birth happened to start the follow up care program. Also additional information about birth helps planning the further care. Description of the business case: The resources are consumed in trying to contact the mother after the expected date of delivery. This can be avoided by enabling the information sharing between the organizations. Also a better quality of the information can be accomplished by delivering the information by information systems. The deployment of regional centralized database enables the

34 China-Finland e-health Partnership 34 (60) sharing of the delivery information along with other clinical information to all the organization in the region with a single solution. Domain of the solution (e.g. Healthcare, Administration, Domain Independent etc.): Healthcare Sub Domain (e.g. Laboratory, Human resources etc.): Maternal care Is the solution used (e.g. information shared) in: [ ] local level [x] regional level [ ] national level References to other relevant work: Specifications, documentation (project plan etc.): Not available Administrative regulation: Not available Other relevant documentation: 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). References: National/Regional implementations in countries like: Finland etc. Form 1: Scope of the solution

35 China-Finland e-health Partnership 35 (60) Information and semantics Information and semantics What information is shared or transferred (an overview)? Clinical information of the delivery. Describe the use of the shared information: The information is used to decide when to start the after delivery follow up program and to prepare for it. Is the data needed in other contexts or use cases (definitions reused, information sharing on regional/national level)? Describe Possible to reuse the format in sharing of the clinical information. Used data standards or specifications, specify: What data standards or specifications are used? N/A High level information model or concept model: N/A Code sets (Classifications, Vocabularies, Terminology): N/A Other data sets (application specific, proprietary etc.): N/A 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: Form 2: Information and semantics

36 China-Finland e-health Partnership 36 (60) Functionality and interactions Functionality and interactions Interactions (functions or operations between systems) Number and description of main interactions? 1. Export from local EHR/EPR system to the Regional Data Center 2. Use of regional data by local EHR/EPR system Standards, methodologies used in the functionality, specify: For example: IHE XDS Tools used, specify: Workflows (tasks by users, links of tasks to applications) Number and description of main workflows? 1. Export/publish: the data is transferred to the Regional Data Center (for example as a batch process). 2. The data is queried by the user from the Regional Data Center. Viewpoint of the modeling (which actors included, what are main information flows): Standards, methodologies used, specify: Tools 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: Tools used, specify: Other (use case descriptions etc.), specify: The overview of suggested solutions and needs are described 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 (Luukkonen et al 2008). Form 3: Functionality and interactions

37 China-Finland e-health Partnership 37 (60) Application infrastructure aspects Application infrastructure aspects Participating applications: Are the participating applications and services specified/recognized? Yes [ X ] No [ ] If yes, specify (application names, roles, status [existing, to be purchased, under construction], owner): - EPR/EPR system (possibly use of Maternity and Child health subsystem): to store the delivery information to Regional Data Center (hospital level) and to view the delivery information stored in the Regional Data Center - Regional Data Center: to store and to share the information Are there any architectural specifications (application maps, target architecture etc.)? Specify for current and future state: See Current state (Diagram 6)and Suggested solution (Diagram 10) Is the basic integration principle: a) information transfer or sharing [ X ] Yes [ ] No If yes, specify: b) service or API invocation [ X ] Yes [ ] No If yes, specify: c) process or workflow coordination [ ] Yes [ X ] No If yes, specify: d) unified or synchronized view for the end user (e.g. desktop integration portal) [ ] Yes [ X ] No If yes, specify: Is the solution intended for: a) multiple users (e.g. distributed service, common service etc.) [ X ] Yes [ ] No If yes, specify: b) single user (e.g. user interface, workstation level, user-specific sessions etc.) [ ] Yes [ ] No If yes, specify: Are the following interoperability features needed/needed to be solved in the solution? a) location or discovery of participating systems or components b) invocation model (messages, events, application programming interfaces) No. Needs to be solved. c) shared or mediated information semantics (where is the meaning of data specified, is there media- Needs to be solved.

38 China-Finland e-health Partnership 38 (60) tion between the participating applications) d) direct (point-to-point) or mediated communication (is the communication directly between systems or using integration platform or bus?) e) coordinated information or communication (is there a coordination layer e.g. workflow or process engine or integrating user interface in the solution?) f) unidirectional or bidirectional invocations (are the invocations initiated always by one of the participating applications, or varyingly initiated by different applications?) g) synchronous or asynchronous communication (is there a request/reply communication or simple send "fire and forget" communication?) h) state management (is there a shared session, context etc. specified in one or several of the components of the architecture, specify) No. No. Needs to be solved. Needs to be solved. No. Form 4: Application infrastructure

39 China-Finland e-health Partnership 39 (60) Technical aspects Technical aspects What are the technology solutions to the following? a) Interface technology for data Needs to be solved. (e.g. XML or HL7 protocol specified) b) Other data access mechanisms (e.g. database middleware, SQL, ODBC, JDBC) Not relevant c) Data transformation technologies Not relevant d) Interface technology for functionality or interactions (e.g. Web services, WSDL, CORBA, DCOM API technologies) e) Communication technologies (network protocols, wire formats etc., e.g. SOAP, DCOM) Needs to be solved. Needs to be solved. f) Integration platform (ESB, message brokers etc.) g) Session or transaction management (e.g. ACID transaction protocols) 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 information or functionality to the user (e.g. html / ASP/JSP pages) k) Operating systems or supported platforms (runtime infrastructure) l) Development tools, programming languages etc. Not relevant Needs to be solved. Not relevant Not relevant Not relevant Form 5: Technical aspects

40 China-Finland e-health Partnership 40 (60) 4.2. Description of Regional information sharing by Weifang CHC and Kingstar The following description of Regional information sharing was structured by an interview with Shanghai partners especially from Weifang CHC and complemented by the project staff in November Scope of the solution Scope of the solution Name of the solution/project: Regional information sharing for Weifang and East hospital and other participating facilities (3+3+1) - Hospital Information Shared System of Pudong An overall description of the solution: Selected information is made available regionally, information originates from local systems, is transferred to the regional system, and used regionally through web-based user interface of the regional system. The launch of web-based regional system can be integrated to the use of the local system. Main requirements for the solution: Necessary basic demographic, basic clinical and referral information should be made available to the doctors from different health centers and hospitals when patient visits different facilities in the region. The input of the information remains in the local system. The solution also includes referral forms, where information goes through the Pudong hospital authorities Description of the business case: Regional information sharing is one of the goals of the regional and government development. Information sharing enables better collaboration between hospitals and health centers, gives potential for doctors to have a more detailed view of patient information and may prevent errors and duplicate examinations and orders. Domain of the solution (e.g. Healthcare, Administration, Domain Independent etc.): Healthcare, basic clinical and administrative work Sub Domain (e.g. Laboratory, Human resources etc.): Basic information, no e.g. maternity information included. Is the solution used (e.g. information shared) in: [ ] local level [ X ] regional level [ ] national level References to other relevant work:

41 China-Finland e-health Partnership 41 (60) Specifications, documentation (project plan etc.): Documentation by the Chinese partners, especially "regional information sharing" report. Administrative regulation: Successful regional models will possibly be recommended on Shanghai level by SMHB Other relevant documentation: See Report 2: Evaluation of technology acceptance and success of health IT - Case maternity pathway in Shanghai Weifang CHC and East Hospital (Nykänen et al 2008). Form 1: Scope of the solution Information and semantics Information and semantics What information is shared or transferred (an overview)? Basic personal demographic and EHR information. Information and structured core dataset has been defined as part of the project with collaboration with vendors. In more detail: -List of visits or inpatient stays in various facilities (sorted by organization and date) -Patient registration information under each visit / inpatient stay -Consultations and diagnoses under each visit / inpatient stay -Laboratory test results -Medication prescriptions for outpatients (no medication summary) -Referrals and referral information Describe the use of the shared information: Input: upon the use of the local system, regionally shared information is automatically selected for transfer to the regional data center. Apparently no special actions are required from the user. Use: In Weifang (integrated systems by one vendor), the user can launch web based regional application using a separate button when viewing information of a specific patient. The web based system displays information from different facilities where patient has received care, based on organization / visit or ward period classification. No information is input in the web based regional system directly by the user. Is the data needed in other contexts or use cases (definitions reused, information sharing on region-

42 China-Finland e-health Partnership 42 (60) al/national level)? Describe Not known Used data standards or specifications, specify: What data standards or specifications are used? National core data set standards have been used as a basis, but data items have been selected and extended. High level information model or concept model: Information model is based on the description of the regional data (defined by the vendor) to which the local systems must be adapted. Patient identification is based on the use of social insurance card number. Code sets (Classifications, Vocabularies, Terminology): Not known at specific level Other data sets (application specific, proprietary etc.): See information / concept model. The data model of export from local systems is proprietary. Need for additional data services Data transformation or mediation service [ ] Yes [X ] No If yes, specify: Code Services [ ] Yes [X ] No If yes, specify: Anonymisation [ ] Yes [X ] No If yes, specify: Others, specify: Form 2: Information and semantics

43 China-Finland e-health Partnership 43 (60) Functionality and interactions Functionality and interactions Interactions (functions or operations between systems) Number and description of main interactions? 1. Export from local systems to the regional data center 2. Use of regional data by web application 3. Launch of regional web application from local system Standards, methodologies used in the functionality, specify: None Tools used, specify: Not known at specific level Workflows (tasks by users, links of tasks to applications) Number and description of main workflows? 1.Export: input is transparent to the use of local system. At midnight, all regionally usable patient data is transferred to the regional data center Launch and use of regional application: The user can start the regional application directly from a button in the local system. The regional application displays visits in different hospitals and health centers, and the user can select and see more detailed information from Viewpoint of the modeling (which actors included, what are main information flows): No detailed models seen so far. Standards, methodologies used, specify: None seen so far. Tools used, specify: Not known at specific level. Process (phases between organizational units, high level process descriptions) Number and description of main processes? Referral information and referral alerts are included in the system, but referral is actually done using a different system. Viewpoint of the modeling (which units included, owner of the process, inputs and outcomes of each main

44 China-Finland e-health Partnership 44 (60) phase of the process): No process integration Standards, methodologies used, specify: N/A Tools used, specify: N/A Other (use case descriptions etc.), specify: See above Form 3: Functionality and interactions

45 China-Finland e-health Partnership 45 (60) Application infrastructure aspects Application infrastructure aspects Participating applications: Are the participating applications and services specified/recognized? Yes [ X ] No [ ] If yes, specify (application names, roles, status [existing, to be purchased, under construction], owner): Core systems in all participating hospitals and health centers send information to the central database. No specialized applications (e.g. LIS, RIS, etc.) were reported to be connected to the regional database. Central database receives information and acts as a basis for web application through which the regionally collected information is used. Currently, not all the participating hospitals input data into the regional database, and the use in those facilities where the web based system could be used has remained limited (e.g. 30 users in Weifang but little use). Systems by two vendors send information to the regional database (from at least 1 hospitals - GongLi and 2 CHC's - LuJiaZhui+WeiFang), but for example BSoft systems in East hospital are not connected to the regional database provided by Kingstar (vendor). Are there any architectural specifications (application maps, target architecture etc.)? Specify for current and future state: See above + report "regional information sharing" by Chinese partners Is the basic integration principle: a) information transfer or sharing [ X ] Yes [ ] No If yes, specify: b) service or API invocation [ ] Yes [ X ] No If yes, specify: c) process or workflow coordination [ ] Yes [ X ] No If yes, specify: Integration 1: each midnight, gathered basic patient information is transferred to the central database (batch transfer) d) unified or synchronized view for the end user (e.g. desktop integration or portal) [ X ] Yes [ ] No If yes, specify: Integration 2: when using the local system, the user can also use the web-based regional system to see organization, visit or ward period based information. No combined views of different information (just visit / period), no automated selection of related / relevant information. Integration 3: the interviewees did not understand the questions related to single sign-on (which seems to be included in the demo) and could not make distinctions between access management in regional and local sys-

46 China-Finland e-health Partnership 46 (60) tem. The patient identifier is evidently transferred to the regional system when it is launched. Is the solution intended for: a) multiple users (e.g. distributed service, common service etc.) b) single user (e.g. user interface, workstation level, user-specific sessions etc.) [ X ] Yes [ ] No If yes, specify: The regional service and local applications are multi-user. The information transfer to regional database collects all information for regional use from one organization. [ X ] Yes [ ] No If yes, specify: The launch of regional application transfers user-specific state (selected patient, possibly user identification). The regional and local applications are used on the same desktop. The system is used only by doctors, as part of doctor workstations. Describe the following interoperability features, if needed in the solution? a) location or discovery of participating systems or components 1. For batch data transfer, the address of the regional recipient must be configured For use of the regional system, a web address and possible opening parameters must be known to the browser (which can be embedded in local system) b) invocation model (messages, events, application programming interfaces) c) shared or mediated information semantics (where is the meaning of data specified, is there mediation between the participating applications) d) direct (point-to-point) or mediated communication (is the communication directly between systems or using integration platform or bus?) e) coordinated information or communication (is there a coordination layer e.g. workflow or 1. Probably batch file transfer 2. Normal http/web application use 3. Invocation of browser within the local application or an external browser (depending on the application type, hyperlink or windows browser launch with parameters etc.) Shared information semantics, specified by the regional system. Local mediation is the responsibility of connecting applications. No integration platform or bus has been described. No coordination layer described; the local system remains main system and controller and input channel of the information.

47 China-Finland e-health Partnership 47 (60) process engine or integrating user interface in the solution?) f) unidirectional or bidirectional invocations (are the invocations initiated always by one of the participating applications, or varyingly initiated by different applications?) g) synchronous or asynchronous communication (is there a request/reply communication or simple send "fire and forget" communication?) h) state management (is there a shared session, context etc. specified in one or several of the components of the architecture, specify) 1. Specifics not known (fetch or send) 2+3 Unidirectional - the local system / browser always invokes the regional system. Evidently no direct invocations from regional system to the local systems, but some referral alert information is highlighted on some patient information queries. 1. Asynchronous timed batch transfer; local information available through the regional system on the following day Synchronous usage, information is online displayed from the regional system. In 2+3, user and patient selection state can be transferred when launching the application. Form 4: Application infrastructure

48 China-Finland e-health Partnership 48 (60) Technical aspects Technical aspects What are the technology solutions to the following? a) Interface technology for data Proprietary format. Not known specifically. (e.g. XML or HL7 protocol specified) b) Other data access mechanisms (e.g. database middleware, SQL, ODBC, JDBC) Not part of the open solution c) Data transformation technologies Local transformations may be needed to fit local systems to the regional model. d) Interface technology for functionality 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, message brokers etc.) g) Session or transaction management (e.g. ACID transaction protocols) 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 information or functionality to the user (e.g. html / ASP/JSP pages) k) Operating systems or supported platforms (runtime infrastructure) l) Development tools, programming languages etc. Not known (a question for vendors) 1. Not confirmed, web server http POST discussed. 2. Typical web server / http communication None No transactions in regional system, just reception and delivery of data. Session transfer in application launch (integration 3) Evidently part of the configuration (send address of patient information packages, address of web server for regional use). Not seen In integration 2: web/html, no internal specifics discussed. 1. Not relevant 2. Not relevant 3. For application launch, some Windowsspecific application connections could be part of the launch functionality Not relevant Form 5: Technical aspects

49 China-Finland e-health Partnership 49 (60) 4.3. ehit example This example illustrates an added value application / service integration with mobile homecare solutions in relation to the maternity pathway Scope of the solution Scope of the solution Name of the solution/project: Regional integration example in the Maternity context, case: ehit. An overall description of the solution: Home measurements are made by pregnant diabetic mother and the results are transferred to the central database, to avoid many point-to-point connections, the stored information can be used regionally. Professionals have access to the data through their doctor and nurse work stations to monitor the health status online. Main requirements for the solution: main integration and interoperability needs: - pregnancy diabetes requires frequent monitoring: self measurement - home measurements can be performed by the patient, data can be sent to the professionals in Weifang (/ East hospital) using mobile devices. Description of the business case: A pregnancy with diabetes requires additional attention (frequent monitoring by measurements) on the health service providers, which needs a lot of resources, both mothers and healthcare professionals. The use of resources can be reduced by using home measurement devices, which can transfer the results by mobile connections directly to information systems for health care providers to monitor. Domain of the solution (e.g. Healthcare, Administration, Domain Independent etc.): Healthcare Sub Domain (e.g. Laboratory, Human resources etc.): Maternity, Home care Is the solution used (e.g. information shared) in: [ ] local level [ X ] regional level [ ] national level References to other relevant work: Specifications, documentation (project plan etc.):

50 China-Finland e-health Partnership 50 (60) None Administrative regulation: None Other relevant documentation: None Form 1: Scope of the solution Information and semantics Information and semantics What information is shared or transferred (an overview)? Measurement information depending on what is measured i.e. blood pressure, glucose etc. Definition needed: which measurements? Describe the use of the shared information: use of information by the care givers - on hospital / CHC visits or - periodical checks by professionals or - alerts related to threshold values - directly from device or remotely on home visits Is the data needed in other contexts or use cases (definitions reused, information sharing on regional/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.): - if no direct data integration (shared data definitions and id s), mediation server is needed to make necessary transformations and id map-

51 China-Finland e-health Partnership 51 (60) pings - transformations to regional standard data formats can also be made Need for additional data services Data transformation or mediation service [ ] Yes [ ] No If yes, specify: in case no direct data integration Code Services [ ] Yes [ ] No If yes, specify: Anonymisation [ ] Yes [ ] No If yes, specify: Others, specify: Form 2: Information and semantics Functionality and interactions Functionality and interactions Interactions (functions or operations between systems) Number and description of main interactions? 1) Measurement by mobile application 2) Data transfer to regional data center by mobile application 3) Data monitoring and viewing in DWS Standards, methodologies used in the functionality, specify: None Tools used, specify: Workflows (tasks by users, links of tasks to applications) Number and description of main workflows? 1) Measurement can be done by user 2) Data transfer to regional data center can be done automatically by mobile application right after the measurement. 3) Data monitoring and viewed from regional data center can be selected by the user in DWS. Viewpoint of the modeling (which actors included, what are main information flows): None at the current concept development stage. Standards, methodologies used, specify:

52 China-Finland e-health Partnership 52 (60) Tools 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: Tools used, specify: Other (use case descriptions etc.), specify: Form 3: Functionality and interactions Application infrastructure aspects Application infrastructure aspects Participating applications: Are the participating applications and services specified/recognized? Yes [ X ] No [ ] If yes, specify (application names, roles, status [existing, to be purchased, under construction], owner): Mobile measurement application: stores the measurement data and/or sends it to regional data center Regional data center: stores the measurement data sent by Mobile measurement application DWS: fetches the stored data and displays it to the user Are there any architectural specifications (application maps, target architecture etc.)? Specify for current and future state: Is the basic integration principle:

53 China-Finland e-health Partnership 53 (60) a) information transfer or sharing [X ] Yes [ ] No If yes, specify: b) service or API invocation [ X ] 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 integration or portal) [ ] Yes [ ] No If yes, specify: Is the solution intended for: a) multiple users (e.g. distributed service, common service etc.) b) single user (e.g. user interface, workstation level, user-specific sessions etc.) [ X ] Yes [ ] No If yes, specify: [ ] Yes [ ] No If yes, specify: 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) Measurement data in messages API for measurement data viewing c) shared or mediated information semantics (where is the meaning of data specified, is there mediation between the participating applications) d) direct (point-to-point) or mediated communication (is the communication directly between systems or using integration platform or bus?) e) coordinated information or communication (is there a coordination layer e.g. workflow or process engine or integrating user interface in the solution?) f) unidirectional or bidirectional invocations (are the invocations initiated always by one of the participating applications, or varyingly initiated by different applications?) g) synchronous or asynchronous communication (is there a re-

54 China-Finland e-health Partnership 54 (60) quest/reply communication or simple send "fire and forget" communication?) h) state management (is there a shared session, context etc. specified in one or several of the components of the architecture, specify) Form 4: Application infrastructure Technical aspects Technical aspects What are the technology solutions to the following? a) Interface technology for data XML for shared data definitions (e.g. XML or HL7 protocol specified) b) Other data access mechanisms (e.g. database middleware, SQL, ODBC, JDBC) c) Data transformation technologies if no direct data integration (shared data definitions and id s), mediation server is needed to make necessary transformations and id mappings d) Interface technology for functionality or interactions (e.g. Web services, WSDL, CORBA, DCOM API technologies) e) Communication technologies (network protocols, wire formats etc., e.g. SOAP, DCOM) lightweight messages for mobile communications web services (SOAP/XML) for regional data center DWS communication mobile internet / other mobile connections, http server in SOAP communication for data viewing f) Integration platform (ESB, message brokers etc.) g) Session or transaction management (e.g. ACID transaction protocols) h) Addressing or discovery for the services (e.g. service registry, UDDI) i) Encryption or certificates (e.g.

55 China-Finland e-health Partnership 55 (60) SSL, https, digital signatures) j) Presentation technology of information or functionality to the user (e.g. html / ASP/JSP pages) k) Operating systems or supported platforms (runtime infrastructure) l) Development tools, programming languages etc. Form 5: Technical aspects 5. Conclusions and recommendations In addition to integration type -specific recommendations in chapter 3, the following general recommendations for integration and architectural development. General recommendations: Use holistic (such as Enterprise Architecture) analysis framework for specifying needs and solutions Based on the experience from maternity pathway examples, it can be seen that the specific small development points (such as availability of baby delivery information) for information sharing can be solved with many different simple solutions. However, the simplest possible models do not provide reusability of the solutions. In the development of education of health IT experts, include architectural and integration aspects. Use rigorous analysis model to form a holistic view on the integration / development domain As part of the requirements and analysis phases of integration projects, use activity-driven information systems development models (see report 1), process models and Migrate from database / data sheet integration towards more functional integration Simple data sheet integration has been widely used for tightly integrating related applications in hospitals and health centers. This integration is usable for simple and singular integration needs, but for the development of reusable and to achieve flexibility in integration solutions and in systems landscape, the integration should be abstracted using functional interfaces, messages, (web) service invocations and integration infrastructure. Support the migration with integration middleware Messaging infrastructure for point-to-point solutions can be gradually extended for more flexible integration infrastructure which can also support several different communication / connectivity models and gradually evolve towards an Enterprise Service Bus. Evaluation Specify/develop an evaluation framework which includes assessing the benefits of integration solutions, in addition to usability, security and other central goals of healthcare IT development (Nykänen et al 2008). Separation of concerns in project planning In the development of health IT development project portfolio, build small and focused projects which do not include many separate or conflicting goals of various participating organizations. Define clear scope and goals for each project, and especially separate public health information

56 China-Finland e-health Partnership 56 (60) development projects, hospital IT development and integration projects, and the development of digital health centres from each other. Interfacing requirements For application acquisitions, define guidelines which require systems to have most relevant interfaces to enable systems to interoperate, based on more detailed recommendations in chapter 3. In conclusion, simple data integration solutions for CHCs and hospitals have been sufficient so far for integration needs related to the health centers and hospitals. However, as the functional coverage of the healthcare enterprise systems increases, and number of components or applications inevitably increases, more reusable and standardized approaches are needed for integration. While these solutions and their supporting infrastructure bring higher initial costs, their introduction improves architectural and data quality and reduce costs on the long term. In addition, many of the main challenges and needs faced in the studied projects require integration solutions which cannot be efficiently solved only with simple database sharing or point-to-point data transfer. The utilization of rigorous needs analysis methods, the introduction of an architectural approach with sufficient coverage of various viewpoints and the specification of recommended practices for basic integration situations (types) provide a more future-proof approach for the development of healthcare IT for CHC, hospital, regional network and public health levels. To support the evident and necessary transformation of health care services delivery, a flexible information sharing infrastructure which relies on modular services and standards provides a solid basis.

57 China-Finland e-health Partnership 57 (60) References Dico A. Delivering SOA with TOGAF. The Open Group, January IBM Healthcare in China - toward greater access, efficiency and quality. IBM Institute of Business Value, ISO Reference Model of Open Distributed Processing, Part 1, Overview, ODP Reference Model ITU-T X.901jISO/IEC : 1995 DIS (E), Jiang J. What Export HIS found out about Shanghai and China. Seminar on Wellness IT Research and Development, , Kuopio. Lee S-H, Ng AW, Zhang K. The quest to improve Chinese healthcare: some fundamental issues. Int J Healthc Qual Ass 2007:20(5): Linthicum D. Enterprise Application Integration. Harlow, Addison-Wesley, Luukkonen I, Toivanen M, Mursu A. Toward planned changes: An activity-driven ISD model. In: Tiainen T, Isomäki H, Korpela M, Mursu A, Nykänen P, Paakki M-K, Pekkola S, eds. Proceedings of the 30th Information Systems Research Seminar in Scandinavia IRIS30. Tampere, Finland, August 2007, p Tampere, Finland: University of Tampere, Department of Computer Sciences Series of Publications D Net Publications D Luukkonen I, Jiang J, Korpela M, Mursu A, Mykkänen J, Mäkinen J, Nykänen P, Seppälä A, Ruonamaa H, Virkanen H (2008): 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 Kuopio, Finland: University of Kuopio, China-Finland e-health Partnership Research Project Report 1. Mykkänen J, Porrasmaa J, Rannanheimo J, Korpela M. A process for specifying integration for multi-tier applications in healthcare. Int J Med Inf 2003:70(2-3): Mykkänen J, Tuomainen M. An evaluation and selection framework for interoperability standards. Inform Software Tech 2008:50(3): Mykkänen J. Specification of reusable integration solutions in health information systems. Kuopio University Publications H. Business and Information Technology 6, Nykänen P, Seppälä A, Jiang J. Evaluation of technology acceptance and success of health IT - Case maternity pathway in Shanghai Weifang CHC and East Hospital. Report 2, China-Finland ehealth Partnership Project, Open Group The Open Group Architecture Framework (TOGAF) Version 8.1.1, Enterprise Edition. The Open Group, Sowa JF, Zachman JA. Extending and formalizing the framework for information systems architecture. IBM Systems Journal 1992:31(3): Zhang Y, Xu Y, Shang L, Rao K. An investigation into health informatics and related standards in China. Int J Med Inf 2007:76:

58 China-Finland e-health Partnership 58 (60) APPENDIX 1. Information systems currently used in Maternity Pathway in Weifang CHC

59 China-Finland e-health Partnership 59 (60) APPENDIX 2. Combined overview of Inpatient/Outpatient workflows in East Hospital

60 China-Finland e-health Partnership 60 (60) APPENDIX 3. Information systems in East Hospital Healthcare services for citizens External business platform Patient management and service platform Phone SMS system Mobile Hospital web site Internet Care relationship management system (tracking, complaint, appointment, inquiry, alarm, consultancy, health promotion, quality control) Medical treatment platform LIS Medical technology Health protection platform Health insurance system Register and charge Patient guidelines RIS Hospital accounts Prescription Physical check-up system Public health system Bank system Other systems Waiting queue Outpatient ward Intra vascular notes Outpatient doctor workstation (DWS) Intra vascular nutrition MINI PACS Preventive healthcare Rational use of medicine Appointment center e-medical history Hospital Doctor Workstation (DWS) Hospital nurse Surgery and anasthesia Nutrition ICU Community health service system Drugs Internal business platform Drug warehouse Supply room Patient records Nursing management Medical history Staff wages Goods and materials Financial software Hospital infection system Teleconferencing Department management queries Digital hospital service Hospital management queries Work time recording Business counting Quality control management Outcome evaluation