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.