Regional Health Economies and ICT Services (Studies in Health Technology and Informatics Shti)

REGIONAL HEALTH ECONOMIES AND ICT SERVICES Studies in Health Technology and Informatics This book series was started i...

Author: Niilo Saranummi | D. Piggott | D. G. Katehakis

46 downloads 868 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

REGIONAL HEALTH ECONOMIES AND ICT SERVICES

Studies in Health Technology and Informatics This book series was started in 1990 to promote research conducted under the auspices of the EC programmes’ Advanced Informatics in Medicine (AIM) and Biomedical and Health Research (BHR) bioengineering branch. A driving aspect of international health informatics is that telecommunication technology, rehabilitative technology, intelligent home technology and many other components are moving together and form one integrated world of information and communication media. The complete series has been accepted in Medline. Volumes from 2005 onwards are available online. Series Editors: Dr. J.P. Christensen, Prof. G. de Moor, Dr. A. Famili, Prof. A. Hasman, Prof. L. Hunter, Dr. I. Iakovidis, Dr. Z. Kolitsi, Dr. O. Le Dour, Dr. A. Lymberis, Dr. P. Niederer, Prof. A. Pedotti, Prof. O. Rienhoff, Prof. F.H. Roger France, Dr. N. Rossing, Prof. N. Saranummi, Dr. E.R. Siegel and Dr. P. Wilson

Volume 115 Recently published in this series Vol. 114. L. Bos, S. Laxminarayan and A. Marsh (Eds.), Medical and Care Compunetics 2 Vol. 113. J.S. Suri, C. Yuan, D.L. Wilson and S. Laxminarayan (Eds.), Plaque Imaging: Pixel to Molecular Level Vol. 112. T. Solomonides, R. McClatchey, V. Breton, Y. Legré and S. Nørager (Eds.), From Grid to Healthgrid Vol. 111. J.D. Westwood, R.S. Haluck, H.M. Hoffman, G.T. Mogel, R. Phillips, R.A. Robb and K.G. Vosburgh (Eds.), Medicine Meets Virtual Reality 13 Vol. 110. F.H. Roger France, E. De Clercq, G. De Moor and J. van der Lei (Eds.), Health Continuum and Data Exchange in Belgium and in the Netherlands – Proceedings of Medical Informatics Congress (MIC 2004) & 5th Belgian e-Health Conference Vol. 109. E.J.S. Hovenga and J. Mantas (Eds.), Global Health Informatics Education Vol. 108. A. Lymberis and D. de Rossi (Eds.), Wearable eHealth Systems for Personalised Health Management – State of the Art and Future Challenges Vol. 107. M. Fieschi, E. Coiera and Y.-C.J. Li (Eds.), MEDINFO 2004 – Proceedings of the 11th World Congress on Medical Informatics Vol. 106. G. Demiris (Ed.), e-Health: Current Status and Future Trends Vol. 105. M. Duplaga, K. Zieliński and D. Ingram (Eds.), Transformation of Healthcare with Information Technologies Vol. 104. R. Latifi (Ed.), Establishing Telemedicine in Developing Countries: From Inception to Implementation Vol. 103. L. Bos, S. Laxminarayan and A. Marsh (Eds.), Medical and Care Compunetics 1

ISSN 0926-9630

Regional Health Economies and ICT Services The PICNIC Experience

Edited by

Niilo Saranummi VTT Information Technology, Human Interaction Technologies, Tampere, Finland

David Piggott Integrity Consulting Partners Ltd., Integrity House, London, UK

Dimitrios G. Katehakis Foundation for Research and Technology – Hellas, Institute of Computer Science, Heraklion, Crete, Greece

Manolis Tsiknakis Foundation for Research and Technology – Hellas, Institute of Computer Science, Heraklion, Crete, Greece

and

Knut Bernstein MEDIQ: Medicinsk Informatik og Kvalitetsudvikling, Copenhagen, Denmark

Amsterdam • Berlin • Oxford • Tokyo • Washington, DC

© 2005 The authors. All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without prior written permission from the publisher. ISBN 1-58603-538-X Library of Congress Control Number: 2005930247 Publisher IOS Press Nieuwe Hemweg 6B 1013 BG Amsterdam Netherlands fax: +31 20 620 3419 e-mail: [email protected] Distributor in the UK and Ireland IOS Press/Lavis Marketing 73 Lime Walk Headington Oxford OX3 7AD England fax: +44 1865 750079

Distributor in the USA and Canada IOS Press, Inc. 4502 Rachael Manor Drive Fairfax, VA 22032 USA fax: +1 703 323 3668 e-mail: [email protected]

LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS

v

Regional Health Economies and ICT Services N. Saranummi et al. (Eds.) IOS Press, 2005 © 2005 The authors. All rights reserved.

Foreword The General Medical Services (GMS) (Payments) Board in Ireland is the principal agency for Irish primary care reimbursement. All public health services provided by General Practitioners, Dentists, Pharmacists and Optometrists are reimbursed by the GMS, which has an annual budget of €2.0B. The GMS has a policy of improving its services to and communications with its Primary Care clients, and this policy is described in the Board’s ICT Strategy. One of the main planks of this ICT Strategy is the development of a business infrastructure for communications with clients, using web technology. I was therefore delighted when the GMS was invited to join the PICNIC Consortium, and I was even more pleased to be asked to be the Project Co-ordinator for the second phase of the project, from April 2001 to March 2003. The development of leading edge technologies for deployment in healthcare for the benefit of patients and health professionals is at the core of the GMS’ mission. Through the vehicle of the PICNIC project, we were able to combine our business knowledge with frontline thinking on the use of ICT to create future technology solutions for healthcare that could be deployed today. The GMS was one of the PICNIC pilot agencies, and we utilised W3C web technologies and HL7’s Clinical Document Architecture protocols to build an online patient ID validation and Community Pharmacist reimbursement system. This system was prototyped under PICNIC, and was subsequently rolled-out to pharmacies all over Ireland. One of the great features of the project was the opportunity to work with thought leaders and technology futurists from all over Europe. Our PICNIC partners from Crete (FORTH), Denmark (Funen), France (Minoru), Finland (VTT), together with many other health agencies, institutions and companies, helped us develop and deploy leading edge ICT solutions for supporting Primary Care. In particular I would also like to thank our fellow partners from Ireland, the North Western Health Board, South & East Belfast Community Trust, the Department of Health & Children (for chairing the National Health Advisory Board) and Hewlett Packard Ireland (which provided technology support). Out of PICNIC came many ideas and specifications, which will contribute to the building of better systems for all those who work in healthcare throughout Europe. The challenge is for the European healthcare sector and the ICT market to take up these concepts and designs and use them to bring benefits to patients and practitioners. I would like to thank the European Commission’s Information Society Directorate for their support and patience, particularly our Project Officer, Yves Paindaveine, who brought the best out of us. Patrick BURKE Chief Executive General Medical Services (Payments) Board Republic of Ireland

This page intentionally left blank

vii

NHAB Foreword It was with great pleasure that I agreed to write this foreword to the ‘PICNIC’ book on the development of Regional Health Care Networks in Europe. As Chairman of the National Health Advisory Board (NHAB), composed of senior ICT policy makers in healthcare throughout Europe, I was privileged to assist this groundbreaking project as it proceeded through its research and development programme. The role of the NHAB was to advise the project team on the new themes in national and regional healthcare ICT strategy that were developing in parallel with the work of the project, and also to support the dissemination and exploitation of the project’s results. The PICNIC project, in my view, produced some outstanding products, including an architecture for future RHCNs, a range of Open Source ‘common components, that can be used, free of charge, by others to build RHCNs, and a series of working operational prototypes that demonstrated the effectiveness of both the PICNIC architecture and the components. Indeed in my own country, I have seen where Mr Patrick Burke, Chief Executive of the General Medical Services (Payments) Board, has, in a very innovative and forward looking way, leveraged the PICNIC technologies to provide an integrated infrastructure for his own agency’s large volume transaction processing. Unlike many R & D projects, the work of PICNIC will live on after the official closure of the project, through the architecture, the ‘PICNIC community’ of Open Source developers that are continuing to amend and enhance the components to perform new functions, and the operational systems that have succeeded the original PICNIC prototypes. This book is a further foundation stone for the continuation of the PICNIC project’s work in the vital area of healthcare ICT infrastructure development. It was a delight to work with this band of dedicated medical informatics pioneers in their leading-edge explorations on the frontier of ICT developments in healthcare, under the highly talented and rigorous project management of David Piggott. I wish them well in their future endeavours, and I hope that this book will encourage and help others to follow in their footsteps. Finally, I would like to acknowledge, once again, the ever courteous and supportive approach of those officials in Jean Claude Healy’s Unit of the European Commission’s Information Society Directorate whom we met with during the course of the project, including in particular Yves Paindaveine and Ilias Iakovidis, who very significantly contributed to the successful outcome of the project. Dr. Richard NOLAN Principal Officer IT Unit Department of Health & Children Republic of Ireland


ix

Foreword Regional health information networks had already been identified by the European Commission as a major challenge prior to 1993. The ability to connect within a region several hospitals and health professionals in order to support continuity of healthcare services carries the promise of better care and a better use of the specialised care platforms available. The fact that 95% of citizens receive care within 40 kilometres of their residence had encouraged the development of these regional networks. Today the right of a citizen to receive treatment anywhere in the EU is recognised following several judgements from the European Court of Justice. These have resulted in some modifications to the social security Council regulations1 enabling the deployment of a European health insurance card to start in June 20042. The paper based card is expected to become an electronic health insurance card by 20083, and in some countries, like Germany, even an electronic health card! The role of this card is to give access to care in an EU country that can be different to a citizen’s usual place of residence, and to share medical data between healthcare professionals for improved continuity of care. But such an electronic card, the most visible token representing a piece of Europe in every citizen’s pocket, is nothing without the back-office infrastructure to which it gives access. In this context, interoperability issues will be the key to a successful deployment: identifiers, message standards, clinical ontologies, codification systems, administrative and reimbursement procedures fully respecting privacy and confidentiality concerns will have to be put on the table and carefully looked at. Technical interoperability can be solved in many ways: in the US, an initiative of the Health and Human Services (HHS) together with Defense (DoD) and Veterans Affairs (VA) Departments have lead to the adoption on March 21, 2003 of a first set of uniform standards for the electronic exchange of clinical health information as recommended by the Consolidate Health Informatics (CHI) standards. The standards in question are HL7, DICOM, LOINC, IEEE1073 and NDCP and correspond to the US strategy of selecting the most commercially successful standards. In the EU, where the mandate to adopt such standards is limited (article 152 of the Treaty restricts the competences of the European institutions in public health matters, yet with the provision for Member States to extend the competences if they would so desire), the European Commission funds initiatives demonstrating technological interoperable solutions. The European Standardisation Organisation, CEN, and its Technical Committee 251 have produced numerous pre-standards. Yet standardisation takes time – an eternity in the Internet times – and, when they exist, standards remain subject to a voluntary take-up by users and by the eHealth industry. Organising events such as the eHealth conference 2003 in Brussels, or the 2004 event in Cork, together with an exhibition of best practices, has in both cases lead Member States to state the need for interoperable solutions such as, in 2003, “actions to address the development of standards addressing interoperability of diverse systems and services and to espe1

Council regulations 1408/71 (EC) and 574/72 (EC). COM(2003)73 – Communication from the Commission concerning the introduction of the health insurance card. 3 COM(2004)356 related to actions towards the European eHealth Area. 2

x

cially explore the possibilities of Open Source applications to achieve this objective”4. In 2004, the implementation and development of secure, interoperable and intraoperable (the ability to interchange and use information functions and services among components within a system) systems and the development of interfaces between incompatible information technology systems are recognised to be of paramount importance. Funding research projects is yet another initiative in order to support progress in this domain. In this respect, the PICNIC research project corresponded to the needs, which have since become increasingly apparent, and was instrumental in setting ways to achieve interoperability by many aspects: – – – –

–

by identifying and developing specific European-wide services, abstracting away from the end-user applications by adopting standards for message interchange such as XML, HL7 CDA by adopting standards to call for specific services through the service interfaces defined by CorbaMed, now the health task force of the OMG by adopting an Open Source approach which forms the basis of a reference implementation and which has become a modern way to disseminate best practices and set de facto standards by convincing industrial partners to follow the Open Source approach, thereby ensuring liability for the software delivery (both as a product and as a service) and permanence of the chosen solutions

After a long series of previous regional health information networks projects such as SHINE, STAR, COCO, WISE etc., the PICNIC project has built on this expertise and been a pioneer in the above-mentioned aspects. The presence of several speakers of the PICNIC consortium at the eHealth 2004 conference is therefore not surprising! Most of the work for a successful deployment of regional health information networks in Europe is still ahead of us, and the PICNIC project has shown the way. Ir. Yves PAINDAVEINE European Commission 5 Project Officer Directorate General Information Society “ICT for Health” unit

4

http://europa.eu.int/information_society/eeurope/ehealth/conference/2003/doc/min_dec_22_may_03.pdf. The views presented are those of the author and do not necessarily represent the official view of the European Commission on the subject. 5

xi

Contents Foreword Patrick Burke

v

NHAB Foreword Richard Nolan

vii

Foreword Yves Paindaveine

ix

Introduction

1

The PICNIC Story Dimitrios G. Katehakis

4

PICNIC Architecture Niilo Saranummi

37

PICNIC Technology Dimitrios G. Katehakis, Morten Bruun-Rasmussen, Vesa Pakarinen, David Piggott and Niilo Saranummi

61

How to Use the PICNIC Results David Piggott

92

Canada Health Infoway – Towards a National Interoperable Electronic Health Record (EHR) Solution Dennis Giokas

108

The Story of MedCom Claus Duedal Pedersen and Christina Elisabeth Wanscher

141

The openEHR Foundation Dipak Kalra, Thomas Beale and Sam Heard

153

The National Programme for IT in England Jeremy Thorp

174

Implementing Interoperable Secure Health Information Systems Persephone Doupi, Pekka Ruotsalainen and Hanna Pohjonen

187

Lessons Learned from PICNIC Manolis Tsiknakis and Niilo Saranummi

215

Glossary of Terms

229

Author Index

233



1

Introduction An important trend throughout Europe is a move towards more involvement of patients or citizens in informed decision making of any choice and responsibility for their own health. The vision behind this work is comprised of two components: new innovative services to the citizens and networking services and care across organisational boundaries. The term “Regional Health Economies”, as used in this book, is an umbrella term that refers to both formal and informal structures that may exist within any European healthcare region and involves patients, providers, and payers. Although each medical centre is autonomous and devoted to the delivery of a particular set of services, the desirable continuity of care requires that different medical centres, offering complementary services or different levels of expertise, exchange relevant patient data and operate in a co-operative working environment. The development of integrated healthcare information systems must be based on the definition and implementation of an open architecture where the individual modules: • • •

Are responsible for autonomous and self-consistent functional areas, Inter-work through public and stable interfaces, Are configurable, able to operate in a distributed environment, and can evolve according to the specific requirements and characteristics of the individual organisation.

The needed integration and interoperability of systems will not be achieved, unless the health care domain invests into standardisation and makes a co-ordinated effort to utilise existing and emerging de facto and de jure standards on IT infrastructures and enterprisewide integration platforms. The way IST is developing, however, means that there is no need for the creation of a fully harmonised European healthcare model (which is an impossible task anyway) for industries to have markets across Europe and globally. Differentiation and creation of new actors in IST markets means that value can be added to generic products by specialising (localising) these to meet different customer needs. However, this does not diminish the need to reduce the variation across Europe in the ways regional care is delivered and supported by IST based products and solutions. A further dimension to this comes from the Open Source initiative. The success of Linux and the Open Source Web-servers and browsers is well known. This has revitalised OS activities also in the health care domain. A large number of health care specific OS projects are underway in the world. Through Open Source the activities of various volunteer standards creating organisations have gained more credibility. Especially in the area of large-scale enterprise systems the fact that OMG’s CORBA-based specifications can fully interact with the Internet based Java/ J2EE environment has created a real competitor to Microsoft in enterprise systems. PICNIC stands for “Professionals and Citizens Network for Integrated Care”. Acknowledging that there is no uniform European agreement on how healthcare services should be organised, and that culture and value systems across Europe are different, means that there cannot be a single regional healthcare network product that would fit all needs. Instead there will be a PICNIC architectural description and specific PICNIC components and services that can be used to populate that architecture. These components and services will

2

Introduction

have to be localised and fitted to the needs of individual regions and at the same time introduce the new ways of working (i.e. trigger changes locally). This means that industries must specialise and network to provide the required services comprising component and content providers and ending with systems integration in the implementation phase and maintenance support and even operating services in the deployment phase. This vision is fully in line with the general trends in IST and its deployment. The aim of the book is to present and discuss the PICNIC project (IST-1999-10345) and its results in a context. Therefore the book begins with the “The PICNIC Story”, where the project is presented and discussed. The value that PICNIC adds is critically important, in order to have a European perspective in the reconfiguration of healthcare processes that are proceeding worldwide, for several reasons: • • • • •

It creates an environment for the users (i.e. regions) to define what regional services are needed and where the commonalties in these exist. It creates an environment where industries can take part into this and inject their expertise in IST development and deployment to this. It produces prototypes of such services and IST based tools to support and enable these. It provides inputs to European harmonisation and standardisation bodies. It assesses and evaluates the results and potential impact that these activities has on the creation of next generation regional solutions for professionals and citizens to support a network for integrated care.

The next chapter, “PICNIC Architecture” focuses on inter-enterprise integration and the facilitation of collaboration between healthcare organisations rather than on intra-enterprise integration and is presented through a number of views. The first view describes the architecture from the viewpoint of national and regional health authorities and policy makers, i.e. how the architecture enables the implementation of national and regional health policies, strategies and organisational structures. The second presents the service viewpoint relevant for the care providers, health professionals, patients and citizens, i.e. how the architecture supports and enables regional care delivery and process management, including continuity of care (shared care) and citizen-centred health services. The third is the engineering view of how the regional healthcare network is built, which is presented using four sub views: software engineering, IT services engineering, security and data. A key objective of the PICNIC project has been to provide products for a European and potentially worldwide software market. The approach followed was through the delivery of a number of Open Source components, to be integrated into applications that deliver similar services across the participating regions, aiming at their exploitation by other regions and the industry. The chapter on “PICNIC Technology” describes the technology developed during the lifecycle of the PICNIC project, focusing on the three core services of Clinical Messaging, Access to Patient Data, and Collaboration. The use of such components across different regions, which can be integrated into applications, in order to deliver similar services across participating regions can be exploited by other regions and industry as well to provide products for a European and potentially worldwide market. In order to be in a position to apply the results of PICNIC, and realise the PICNIC Architecture in a particular regional setting, a series of steps must be taken to determine the work that needs to be done. The seven main steps comprise: • • • •

Initial project definition Planning for implementation of the Architecture Procurement of technical support and/or implementation resources Design of the Technical Architecture and federated schema of RHCN data

Introduction

• • •

3

Development of the middleware platform and integration of PICNIC components and legacy applications Testing & verification of all elements of the RHCN Deployment.

Each of these steps is explained in the chapter “How to Use PICNIC Results”. Subsequently, the PICNIC context is provided by a number of other initiatives and projects (both competing and complementary within Europe and internationally). “Canada Health Infoway – Towards a National Interoperable Electronic Health Record (EHR) Solution” presents a high-level view of Infoway’s seven-year plan to have the basic elements of interoperable EHRs in place across 50 percent of Canada by 2010. In particular, the chapter discusses the business and technical approaches that have been developed to pursue aggressively Infoway’s goal. These approaches allow individual jurisdictions to deliver local and regional solutions cost-effectively while contributing to a larger, interoperable national system. Furthermore, because technology is constantly improving, the chapter describes mechanisms for accommodating future developments. Finally, it outlines progress made to date and discusses future directions. The chapter after that describes “The Story of MedCom”, the rather long development history of the electronic communication in Denmark followed by the nation-wide health portal and the background behind the Danish project organisation. “The openEHR Foundation” chapter summarises the antecedents that led to the formation of openEHR, including the research and demonstrator activities and the general health informatics context in which specifications and standards for the EHR are being developed. It outlines the formation of openEHR, and the steps that have been taken to establish it as a community and as a Foundation. The key features of the architectural approach to representing, storing and communicating EHR data are described. It outlines the present plans for software development, and the roles openEHR members are playing in international standards. “The National Programme for IT in England” describes the architecture for the core component of the NHS Care Record Service including the application, information and security architectures and the requirements for supporting standards and technologies. Finally “Implementing Interoperable Secure Health Information Systems” proposes a generic model for streamlining the security implementation process on any level -local, regional, national or cross-border, while at the same time it addresses the future prospects and requirements for advancing secure delivery of healthcare services across European borders. Finally, a concluding chapter relates PICNIC to the context. This book has gathered significant experience in developing IT services for Regional Health Economies and builds on several years of worldwide experience. Its aim is to make the European market for telematic health care services more cohesive and less fragmented, by developing a model for the preparation of the regional health care providers to implement the next generation of secure, user-friendly health care networks. As such it paves the way towards the development of regional healthcare networks, assisted by interoperable IT services, in order to support effectively continuity of care across enterprises and establish a Professionals and Citizens Network for Integrated Care.

4


The PICNIC Story Dimitrios G. KATEHAKIS Foundation for Research and Technology – Hellas, Institute of Computer Science ([email protected]), PO Box 1385, GR-711 10 Heraklion, Crete, Greece Abstract. This chapter describes how the Professionals and Citizens Network for Integrated Care (PICNIC) project was conducted in order to meet its objectives in preparing the regional healthcare providers to implement the next generation, comprehensive, user-friendly, secure healthcare network for patient centred care, and through it contribute to the de-fragmentation of the European market for health telematics. It describes the methodology followed in order to reach certain project results, starting from the selection of common documentation tools and methods, to the delivery of a new model for providing services, assessment plans, and a number of open source software components running on a number of diverse pilots throughout Europe in line with the overall PICNIC architecture.

1. Introduction PICNIC stands for Professionals and Citizens Network for Integrated Care and was a European Commission co-funded research and development project, established under the 5th Framework of European Research “Information Societies Technology Programme”. PICNIC begun in January 1, 2000, was split into two phases, and involved partners and subcontractors coming from Denmark (DK), Finland (FI), France (FR), Greece (GR), Germany (DE), Iceland (IS), Ireland (IE), Netherlands (NL), Spain (ES), Sweden (SE) and the United Kingdom (UK). The design phase involved 15 partners (Danish Centre for Health Telematics of County of Funen – DK, Tele Danmark Consult A/S – DK, Satakunta Macro Pilot – FI, VTT Information Technology – FI, General Medical Services (Payments) Board – IE, North Western Health Board (NWHB) – IE, Servicio Analuz de Salud – ES, ECOMIT – ES, South & East Belfast Health & Social Services Trust (SEBT) – UK, Systems Team plc/ In4tek – UK, Erasmus University – NL, Foundation for Research and Technology – Hellas (FORTH)– GR, University of Ioannina – GR, MN-Medizinische Netzwerke – DE, and the University Hospital of Iceland – IS), while the deployment phase involved 8 partners (General Medical Services (Payments) Board – IE, VTT Information Technology – FI, NWHB – IE, SEBT – UK, Erasmus University – NL, FORTH – GR, Minoru/ OpenHealth – FR, and the Danish Centre for Health Telematics of County of Funen – DK) and 2 subcontractors (Compaq/ HP – IE, and SECTRA – SE). Most of the application areas in PICNIC aimed at realising citizen-centred, shared care and was initiated by regional healthcare providers who were planning their next generation Regional Health Care Networks (RHCN) to support their new ways of providing health and social care. Under a shared care scheme the PICNIC partners envisaged •

healthcare professionals to collaborate and to access relevant information timely and securely for decision support and research;

D.G. Katehakis / The PICNIC Story Scenarios for Providing Care

Clinical & Telemedicine

18 WISE Services

Service Description

Service Description

Service Description

Functional Specifications



IT Services

Technical Co-ordination

Health Information

Administrative

...

...

...

...

Service Description


Architecture & Standards

Open Source Components

Prototypes

5

Prototype

Prototype

...

...

Descriptions

...

...

Development

Prototype

...

...

Prototype

Figure 1. The work of PICNIC comprised scenario building, service modelling, definition of IT-response to these, functional specification, creation of an architecture, identification of common components and finally building prototypes and implementing and evaluating these inside the regions.

• •

managers and health authorities to access relevant information including information coming from both clinical and administrative data in order to make rational decisions; citizens to access information enabling them to take a more active role in the process of disease prevention, health education, care and rehabilitation.

The aim of the project was to prepare the regional healthcare providers to implement the next generation of secure, user-friendly healthcare networks in order to contribute to the de-fragmentation of the European health telematics market. This was being done by: • • • • • • • •

developing scenarios of new ways of patient centred delivery of care; describing the services, so that a total picture of RHCNs could be presented towards industry and other healthcare authorities; specifying an overall architecture; delivering a number of certified Open Source (OS) components for the services in close co-operation with industry; integrating these components into applications that deliver similar services across participating regions; developing of a set of demonstrators, including extensive prototyping of the highest priority services to validate the concept; delivering plans and instruments for regional assessment; facilitating the exploitation of the PICNIC results by other regions and industry to provide products for a European, and potentially worldwide, market.

A schematic diagram of all the above is seen in Fig. 1. Section 2 (Common Documentation Tools and Methods) describes the selection process for the development of common tools to be used for the description of the requirements for PICNIC services and components. The scenario for the delivery of new ways of patient centred care that involves all the 18 pre-selected services, based on the development of a set of scenarios describing the objectives in health and social care for each of the PICNIC re-

6

D.G. Katehakis / The PICNIC Story

gions, is presented in Section 3 (New Model for Providing Services). Section 4 (New Services) describes the selected services from a European vision, with the level of detail needed so that they can be used for providing the functional specifications required for the development of OS software components and for services’ prototyping. Section 5 (Open Source Development) deals with the development of the common components and open interfaces required by PICNIC, while plans and instruments used to assess the regional prototypes that use the common components, are described in Section 6 (Assessment Plans and Instruments). The PICNIC pilots are presented in Section 7 (The Pilots), while technical validation and component certification are further elaborated in Sections 8 (Technical Validation) and 9 (Certification) respectively. Finally Section 10 (Conclusions) concludes on the PICNIC story and delivers some of the lessons learnt.

2. Common Documentation Tools and Methods From the beginning of the PICNIC project the technical co-ordination team considered necessary to develop common tools to describe the requirements of the PICNIC services. As in the modern approach adopted generally in software development, the PICNIC team planned to use Object Oriented (O-O) modelling techniques, since healthcare standardisation efforts, e.g. by Health Level Seven (HL7) and the Technical Committee 251 of the European Committee for Standardization (CEN-TC251), have recently gone towards the O-O approach. To maintain uniformity across regions and along the project lifeline it was necessary for PICNIC partners to agree on the tools and methods that are to be used in the project. The modelling tool was already identified in the technical annex of PICNIC and can be characterised as follows: • •

A modelling tool that supports “round-trip engineering” (i.e. provides support through all the phases of the project from problem identification and analysis to specification, design, testing and implementation) Software tools and principles that were used to build the common components and the prototypes.

The Unified Modelling Language (UML), incorporating Rumbaugh’s Object Modeling Technique (OMT) [1] and Jacobson’s Use Cases [2], is the industry standard which has been widely adopted as the development approach for O-O projects. This is because it was thought that the visual properties of UML based tools are strong and intuitive enough to be usable and understandable to users with minimal training. The task of UML modelling tool selection was divided into the following sub-tasks: • • •

Analysis/ identification of potential tool sets; Selection and purchase of a group licence; Installation and on-site training of users.

Three companies were invited to give presentations about their products and start negotiations for licences for PICNIC. The three tool-sets were carefully analysed and considered and in the end the Rational approach was seen as the solution that could best support PICNIC work, since the Rational Unified Process, (RUP) offers the possibility to go back and forth from modelling all the way to deployment in a co-ordinated fashion [3]. The training course that followed (Espoo, Finland in 1–3 March 2000) provided an indepth technical study of object-oriented analysis and design for client-server development and concentrated on the modelling techniques based on UML to develop a model based on

D.G. Katehakis / The PICNIC Story New models for provision of care: Scenarios for patient centred care

Write narrative scenarios in Word using specialized Vision templates

Generic tools and components

IT Response

With Rose Modeler Build Use Cases with Rose Modeller

Generate sequence diagrams, classes, logical views etc in dialogue with regions to clarify as necessary

7

In order to Select and specify services minimum data set functional specs

Common components

Identify commonalities (components)

responsible supporting

supporting

Regional Analyst

Figure 2. The UML methodology used in PICNIC.

realistic case studies. The objectives of using UML were that upon completion of this course, participating regions were able to: •

apply effective requirements management skills to produce a clear statement of product requirements; • capture and document requirements with use-case-modelling techniques; • set up a documentation hierarchy and standards for different levels of requirements for a product; • use attributes and traceability to help manage requirement scope and change throughout product lifecycle; • have used the Rational tools (RUP, Rational RequisitePro and Rational Rose) extensively; • have created several diagrams to gain basic modelling skills; and • understand when and why specific diagrams are modelled. Topics covered during the training were: • the requirements management process; • best practices and the RUP; • analysing the problem; • defining the system: the vision, product features and use case model; • finding actors and use cases; • managing system scope; • modelling basics; • using the Rose modelling tool in a team; • creating use case model; and finally • creating use case realisation. After the course the participants discussed their experiences in view of the proposal to use the AnalystStudio suite in the PICNIC project to generate use cases from the service scenarios. The conclusion of the discussion was that in the ideal situation (see Fig. 2): •

Each region produces a folder of scenarios. Each scenario describes the process of how service is delivered between customer and provider. Scenarios cover both intra- and inter-organisational processes.

8


Table 1. The 18 services as devised by the WISE project. Clinical Services and Telemedicine

Health Information Services

Administrative Services and Electronic Commerce

1. Clinical Messages

9. Surveillance Information

15. Reimbursement

2. Clinical e-Mail

10. Yellow Pages

16. Electronic Commerce

3. Clinical Booking

11. Professional Guidelines

17. Patient Identification (ID)

4. Shared Records

12. Disease Quality Management

18. Resource Management

5. Care Protocols

13. Public Health Information

6. Mobile and Emergency

14. Continuing Professional Development

7. Home-care Monitoring 8. Telemedicine

• •

Each region nominates a Regional Analyst/ UML Secretary. The scenario work is done in four parts which are produced in the following format: – S1 = Context and background in which the scenario exists (using a predefined Word document template); – S2 = A narrative describing the scenario (using a predefined Word document template); – S3 = A more detailed narrative describing what Information Technology (IT)services (the matrix of 18 or other IT services) are needed in the scenario (using a predefined Word document template); and – S4 = Use Cases describing the scenario (produced with Rose modeller by the Regional Analysts).

3. New Model for Providing Services The vision of the next generation, user-friendly, secure RHCNs for patient centred care was the motivating factor that drove the regions and defined the scope of PICNIC. Therefore the task facing the PICNIC partners was to think ahead and visualise the health requirements for the next 5 to 10 years. 3.1. The 18 WISE Services PICNIC started with the aim of taking the concept of the 18 services developed by the Work In Synergy for Europe (WISE) project [4]. These 18 services are required by a RHCN in order to deliver a full range of IT services to any “member” healthcare organization within the RHCN, and had been divided into three groups as seen on Table 1. Group 1: Clinical Services and Telemedicine The Clinical Services are the most important functionality in a RHCN, and consist of patient-related information communicated to healthcare professionals concerning the treatment of the individual patient. Clinical Messages is a service making it possible to exchange form-based information such as prescriptions, laboratory results, referrals, and discharge summaries almost automatically between different providers of health. When communicating Clinical Messages, a


9

“store and forward” e-mail technique is often used because of the well-known technique and the opportunity to communicate 24 hours/day. Clinical e-mail is a secure, firewall-protected and/ or encrypted e-mail service dedicated to transfer patient-related information. Today telephones are used very frequently to give short, but important, patient-related information; normal e-mail would be very adequate to use in these cases. Nevertheless, e-mail is not used much for cross-sector communication, among other reasons because of the need for special security in health. Clinical Booking is an IT service making it possible to book an appointment for treatment or investigation at other hospitals or specialist clinics. In Clinical Booking, an immediate answer is needed, and therefore on-line IT systems are normally used. Shared Records is an IT service making it possible to share patient record data for the same patient between different professionals in different institutions in the region. Record Sharing demands a high degree of functionality and common structure, and such services therefore often use the same IT application, distributed to different professionals. Care Protocols is an IT service making it possible to transfer exact defined information between health professionals in cases where different professionals participate in the treatment of the same patient group. Before communication is possible, protocols and guidelines have to be defined and agreed by the participating professionals, stating who should provide what treatment. Mobile and Emergency are IT services dedicated to support mobile units like ambulances, doctors on duty and home nurses visiting patients at home. It makes it possible to transfer patient related information from systems at home-care units and in General Practitioner (GP) surgeries, in order to get access to the patient’s journal and retrieve updated information or save new information. Home-Care Monitoring is an IT service making it possible to look after patients located at home, often as alert systems making it possible for weak patients to call assistance. Telemedicine is an IT service used during the actual care of patients, making it possible to provide expert supervision to other professionals or directly to the patient. Telemedicine is the “classic” health telematics service, and is especially relevant if large geographic distances are a problem. Group 2: Health Information Services Health Information Services are information services providing health-related information to the public in general, to specific patient groups, or to specific groups of healthcare professionals. The information is typically general guidelines and procedures, and not information about the individual patient. Surveillance Information is IT systems dedicated to communicate epidemiological information to professionals for medical surveillance. Such information are today typically gathered by national research-institutes and distributed regularly by means of newsletters etc. Yellow Pages is an IT service making it possible to get practical information about healthcare providers, often with advanced facilities to search data in large databases. The Internet-based Web sites technology has in recent years resulted in the appearance of many such yellow pages from hospitals, health authorities etc. Professional Guidelines are services for healthcare professionals with general information and guidelines about cost, quality, protocols and procedures, making it possible for health professionals to improve their practice. The gatekeeper role of GPs in many European countries especially has crystallised the need for such information systems. Disease Quality Management is services with information making it possible for health professionals to optimise care quality when making cross sector treatment of specific diagnoses.

10


Public Health Information is a service to the public in general or to specific patient groups to inform and guide about diseases, prevention and services provided by the regional healthcare system. Continuing Professional Development is a service to the healthcare professionals, to make it possible to improve their education continuously. Group 3: Administrative Services and Electronic Commerce Administrative Services and Electronic Commerce are regional health services to professionals related to administrative, financial and management issues. Reimbursement is a service making it possible to transfer bills from healthcare professionals to public or private insurance. Despite the fact that healthcare organisation differs between the countries in Europe, the reimbursement situation is important in all countries and is often the first regional telematics implementation in health. Electronic Commerce is an IT-service making it possible to order, deliver and pay for goods and services to healthcare. In trade, the United Nations’ Electronic Data Interchange (EDIFACT) standards are used world-wide for this purpose; the developments are supported by the international EDIFACT and European Article Number(ing) (EAN) organisations. Patient ID is an IT service making it possible for health professionals to access central databases for quick and secure identification of patients. Because of lack of well-known national ID-numbers, a secure identification of patients is a problem in several countries. Resource management is an IT service providing information to health professionals giving access to cost and quality information from other health providers in the region. Especially in countries which have introduced provider-purchaser systems in health, where knowledge of costs and quality has become important for healthcare professionals and administrators. 3.2. Development Methodology Having the 18 WISE services as a starting point, PICNIC needed a storyboard in order to articulate the future healthcare response, with the empowered citizen at the centre and professionals through a RHCN service providing services and support which aim to maintain the citizen’s quality of life despite clinical illness which impacts not only on family life, but also on the citizen’s ability to sustain his occupation. The storyboard was constructed around a single typical healthcare story, based on a generic patient character (‘Miguel’) which is prevalent in each partner country, as a superimposition and cross mapping of the several storyboards produced by each of the 8 partner countries, and captures generic requirements common across all countries in one story. The methodology to developing the “Miguel” story was the following; •

•

•

A series of workshops were held involving all the partners to discuss and describe current practice, including difficulties, pressures and their vision of future care delivery and, in discussion with each other and the IT partners, to develop an outline scenario of future care provision. One of the partners, a healthcare provider, was tasked with developing a real life storyboard based on their actual experiences in treating patients. They were asked to combine a number of real cases to encompass all the 18 services in the PICNIC project and to set these into a real family setting. This single “storyboard” was then sent to each healthcare partner with a request that it was used as a template to develop a storyboard for their own region with their own regional requirements built into the story. This regional storyboard would focus on the implementation of the prototype which that country was committed to


11

within the project showing the particular services they required to enable the prototype to be implemented. • The descriptions received from each country were then analysed and consolidated into one single “storyboard”. This involved analysing each partner’s story and extracting the interventions, actions or functions described and relating these to one or more of the 18 services. This approach enabled the 18 services to be described and linked within one scenario, the “Miguel Story”, which follows in Section 3.3 and is fundamental to the PICNIC project, since it combines in a single scenario all the services on which builds its solutions for a new approach to the provision of healthcare in a region [5]. The story clearly demonstrates the requirement for a new way of combining and delivering these services and the usage of modern technology to facilitate such a new delivery scenario. 3.3. The Generic Storyboard Miguel is a 51 year old man who has been working for many years as a salesman for a major company. The company is in the process of technological change after its acquisition by a big multi-national from the sector. Miguel lives with his wife Anna, 48 and two children, Julia, 19 studying Tele-communications in the capital city of the region and Antonio, 17 who is finishing high school and plans to study medicine. Before referring Miguel to the local health centre his GP gives him information on web sites where he can find evidence based information on how to stay healthy and well. It also contains the details of an Internet chat room where he can talk with other people who suffer from diabetes. (13. Public Health Information) When Miguel visits the diabetes web site he finds that the information has been compiled by experts and translated into non-expert language by the editors of the Internet portal system. Within the web site there are virtual tours which have to be paid for. Miguel uses his personal identification smart tag to pay for the tour. (16. Electronic Commerce) The GP recognises that there are two realistic courses of action to manage Miguel’s illness. As part of the information needed to make his decision on the most cost-effective course of action the GP downloads cost information from different health providers in the region. (18. Resource Management) The GP also downloads epidemiological information from the National Research Institute on Diabetes. (9. Surveillance Information) The GP explains to Miguel that he can send his primary health record electronically to the health centre via a secure regional electronic network. He asks Miguel’s permission to release all of the shared patient record, which can be updated from all available sources. However, Miguel does not authorise the release of all the information because he wants an independent second medical opinion. (1. Clinical e-Mail, 4. Shared Records) Miguel has no apparent medical problem although his GP (since they moved to the new house in the countryside the GP’s surgery is far away so they attend the new health centre, which has a team of young staff) recommended that he lose weight, change diet and stop smoking. He smokes between half a packet and one packet a day and for “work reasons” drinks between 4 and 5 units of alcohol a day, “the norm”. In his last work journey, while visiting a client he suffers a loss of consciousness. He is taken to the local health centre (isolated rural centre within his usual car routes) where they detect an abnormal level of glucose in his blood and abnormalities in the ElectroCardioGram (ECG). The local GP decides to send him to a hospital where Miguel is admitted to intensive care to treat an acute myocardial infarction and coma.

12


The doctor at the health centre views Miguel’s electronic healthcare record which includes data from Miguel’s GP, his last discharge report from hospital and the District Nurse’s notes. (4. Shared Records) Anna, Miguel’s wife uses her Wireless Application Protocol phone to browse extensive information on glucose and insulin values over time. Sometimes she looks up Miguel’s complete electronic diabetic record on the Internet. Miguel can also access his record on his television screen. (1. Clinical Messages, 4. Shared Records) Miguel’s GP and community nurse join a distance learning course through the network to keep them up-to-date with the evidence-based management and treatment of diabetes with ischaemic heart disease. (14. Continuing Professional Development) Miguel has difficulty keeping to his diet and his GP arranges a tele-consultation with a specialist dietician at the Regional Hospital (telemedicine). Miguel continues to take his blood pressure readings and he is now able to regulate these himself and send the results to the GP by electronic message. There is therefore joint control between Miguel and his GP. (1. Clinical Messages) The doctor at the health centre refers Miguel to the hospital via a clinical e-mail using his unique patient identification number. To prepare for his arrival at the hospital the doctor electronically orders previous medical records from other hospitals and when he receives these he adds them to Miguel’s shared records. (2. Clinical e-Mail, 17. Patient ID, 4. Shared Records) Miguel is not very communicative; he is dreamy and frequently has aggressive and unjustified violent reactions. He doesn’t sleep at night and on various occasions at midnight they have called the emergency services for chest pressure with no evidence of ischaemic effects. Recently they have attended the Accident and Emergency (A&E) department at the general hospital where they have recommended a neurological assessment to evaluate a possible cognitive disorder. Once he overcomes this acute problem he is discharged from the hospital and advised to follow treatment with insulin, anti-coagulants, anti-hypertensives, anti-ischaemics and anxiolytic therapy and to stop smoking and stop drinking alcohol, to go on a diet and live life in a different way, including changing his job in the case that he can return to work. During the ambulance journey to the hospital the paramedics electronically send Miguel’s vital signs to the hospital. Medical experts at the hospital use this information to advise the paramedics how best to manage Miguel throughout the journey. (6. Mobile and Emergency) The specialist in charge of Miguel’s care at the hospital is a certified user of the International Diabetic Electronic Advisory Line (IDEAL). This means that she receives regular updates of guidelines for diabetic examinations, treatments and surveillance, and she runs these guidelines against Miguel’s electronic records. (5. Care Protocols, 12. Disease Quality Management) Following successful treatment at the hospital Miguel decides he wants to return home by bus. He uses his smart tag on the bus which allows him to travel at a reduced rate. (16. Electronic Commerce) Miguel’s discharge information is sent to his GP in the form of a clinical message. The agreed care protocol for shared care, between secondary hospital and primary care and professional guidelines are sent with the discharge message. (1. Clinical Message, 5. Care Protocols, 11. Professional Guidelines) Once at home Miguel wants to maintain his quality of life and arranges that his twice daily readings of blood glucose and blood pressure are sent electronically to the local health centre and by return he is advised how to adjust his insulin and anti-


13

hypertensives. He also monitors his progress against the Care Protocol which can be viewed on the television. (1. Clinical Messages, 7. Home-care Monitoring, 5. Care Protocols)

He has to go for an arterial examination of the cardiac vessels in the regional university Hospital, 100 Kms from his home and be monitored by his GP (under indications from the cardiologist, the endocrinologist and the haematology unit in his local hospital) who will have to handle the necessary elements of his temporary disability and eventually put him in touch with social security since his problems seem incompatible with the type of work he does. Miguel and his GP prepare for the arterial examination through tele-consultation (telemedicine) with the cardiologist at the University Hospital. The GP also sends the cardiologist a video clip of Miguel’s past condition. The appointment is booked electronically. (3. Clinical Booking)

Back home, Miguel starts his treatment plan including insulin administration, anticoagulant controls and anti-hypertensives and his new diet (Miguel has always enjoyed good food). His wife accepts a part time job as a nursery assistant. She is very worried about the restructuring going on in the company and the continuous calls from Miguel’s work colleagues and his boss about not reaching the sales standards. She has serious doubts that if they don’t have the income that they had (a very important part of which came from hitting sales targets), it could be difficult for them to send their children to university and pay for the new house mortgage, the house that they moved to just a year ago on the outskirts of the locality. However, for fear of the effect it could have on her husband she has not spoken to him about her worries following the specialist’s advice. Two months later Miguel and Anna decide to go for a holiday to Germany to see their cousins who live there. Once he arrives there Miguel uses the Yellow pages facility to find a doctor in Berlin who speaks Spanish. At the end of the visit to Germany the doctor electronically bills Miguel’s insurance company who in turn refund the doctor for the consultations. (10. Yellow Pages, 15. Reimbursement) 4. New Services Following the development of the set of scenarios for each of the participating regions, together with the generic storyboard, the next task was to describe the corresponding IT services and the technology to be used for each of the selected services. This was another key part of the PICNIC project, since the participating regions (together with the industry) were expected through their description to analyse and define the high-level needs and features of the IT services at a European level. 4.1. Development Methodology The PICNIC regions selected the 12 highest priority WISE services, and named a group chairman for each one. For each service and for each participating region, an overall position statement was provided, summarizing at the highest level, the unique position the IT service intends to fill in the marketplace. This position statement identified the target population, provided a statement of the need or opportunity, the name and category the service belongs in, the key benefit(s), primary existing service alternatives and the IT service principal differentiation.

14


Finally, the service chairmen were asked to deliver a harmonized description of the IT service, having the approval of all participating partners. As a product, a high level view of the IT service capabilities, interfaces to other applications and systems configurations, as well as the perspective behind the IT service, together with a summary of capabilities, assumptions and dependencies was provided [6]. 4.2. Results From the IT service descriptions, as well as the overall statement summarizing at a high level of abstraction, the unique position each IT service intended to fill, it became apparent that there are a lot of “service inter-relations”, and that some of them need co-exist in order to deliver their respective services. This is clearly depicted in Table 2. Table 2. Result of the PICNIC IT services harmonization process. IT Service

Comments


Exchange of structured, patient-related information. Common approach for all (DK, ES, IE, IS, GR). In many cases it requires the Patient ID service.

2. Clinical E-mail

Transfer of unstructured patient-related information. Common approach for all (DE, DK, IS).

4. Shared Records

Seamless access to patient record data. Two approaches (ES, UK) vs. (GR, FI, IS) that can be merged into one. Requires the Patient ID service.


Interaction with healthcare related information through a number of alternative information access devices. Three different approaches exist. The DK approach is Clinical Messages. The UK approach is Shared Records. The IE approach is a combination of Shared Records and Clinical e-Mail. May depend on IT services like the Shared Records, Telemedicine, Mobile and Emergency and Clinical Messages. Can be offered at home.

7. Home Care Monitoring

Looking after patients at home. Common approach for all (FI, GR, IS, UK). May depend on IT services like the Shared Records, Telemedicine, Mobile and Emergency and Clinical Messages.

8. Telemedicine

Medicine at a distance. Different flavours across the regions (DK, GR, IS, UK). Very close to Mobile and Emergency. Can be part of the Home Care IT service. In some pilots, it requires the Clinical Messages and Yellow Pages service.


Communication of epidemiological information to healthcare professionals. Common approach for all (ES, IE). Requires the Shared Records service.

10. Yellow Pages

Up-to-date information about healthcare, social providers and facilities. Common approach for all (DE, DK, GR, UK). Minor differences, mainly deal with end-user categories and access rights.


An environment to create, discuss, bring to a consensus, publish and distribute health and social care related content. Single definition (DE, FI).

15. Reimbursement

Preparation, submission and transmission of claims for payment. Single service with two approaches. IE focuses on the payment of prescription drugs dispensed by community pharmacists. ES involves transferring claims at the point of discharge to the relevant funding agencies. Requires the Patient ID and the Clinical Messages IT service.


Order entry and submission of certain services between business units/ healthcare organizations and citizens. Single definition (DE, FI).

17. Patient ID

Unique identification of patients. Single definition (ES, IE). Basic component in many services.


15

Through this analysis, it became evident that Patient ID seems to be rather more a common component than an independent IT service, and is required by most of the other end-user applications. For example the Clinical Messages, the Shared Records and the Reimbursement services, explicitly require patient identification in order to function. This is also the case for all other services that depend on the three previously mentioned services, or that need to relate to a single identifiable patient. In deploying Telemedicine, it was necessary to develop services that permited remote consultation between professionals in specialised centres, peripheral hospitals and other points of care and that provide citizens with effective healthcare in their homes, in isolated places, and in cases of emergency. The telemedicine service should be available for emergency and the application could be running on mobile equipment. As such, Telemedicine is one of the features offered by the Mobile and Emergency service. In the case of the Home Care IT service, Telemedicine can be applied in the patient’s home either by the patient to the professional or by a healthcare worker to hospital service. In addition to this, Home Care also depends on other services such as Shared Records (to attach clinical findings), Clinical Messages (to send requests) and Mobile and Emergency (e.g. for alarm management). Mobile and Emergency can be defined to be an end-user service, similar to the Shared Records service, but with the additional capability of supporting Clinical Messages and Clinical E-Mail. The only additional capability is the need to support mobility (i.e., access to shared patient and other data from mobile Information and Communication Technology (ICT) devices). In addition to the above-mentioned services, Telemedicine ought be available for emergencies and run on mobile equipment, as well. Surveillance Information IT service can be thought of as a specific in terms of its objective, although technologically it could be thought of as being close to the Shared Records IT service. Taking the above information into account, it was concluded at this stage of the analysis that Home Care Monitoring and Mobile and Emergency were composite services existing as a combination of other, more atomic services. Clinical Messages and Shared Records seemed to form a set of core services, while the Patient ID component seemed to be fundamental, and therefore needed to be extensively prototyped, as a core IT service. Therefore at this stage, the emphasis seemed to be focused on these three services (i.e. Clinical Messages, Shared Records and Patient ID). The diagram in Fig. 3 depicts the existing interrelationships. In brief, it is shown diagrammatically that: •

•

•

Patient ID is not an end-user service, since it does not respond to any great degree to any real-world end-user need directly, but rather indirectly. It is nevertheless a very important service within the IT architecture of a RHCN, providing its functionality (i.e. service) to a number of applications and other IT services. It must be thought of as a fundamental component without which it is almost impossible to develop a number of the remaining end-user services. Home Care Monitoring and Mobile and Emergency are “composite” services that depend on the existence of several “atomic” services (Shared Records, Clinical Messages, Telemedicine, Clinical E-mail, etc.), which are available to mobile users, to the home of a citizen or health professional or are employed in health emergency incidences. E-commerce, Yellow Pages, Public Health Information form a separate set of services that are not directly linked to the patient’s personal clinical management, but rather to adjacent services, linked to ordering and paying for goods and services using tools for electronic commerce, healthcare-related resources, and content.

16

D.G. Katehakis / The PICNIC Story 7. Home-care Monitoring



8. Telemedicine


10. Yellow Pages 2. Clinical E-Mail 15. Reimbursement 4. Shared Records



17. Patient ID

Figure 3. IT services’ interrelation. An arrow represents the existence of a relationship/ dependency between two services pointing at the core service (e.g. 6. Mobile and Emergency 4. Shared Records can be interpreted as “The Mobile and Emergency IT service may (or does) depend on the availability of the Shared Records IT service”).

•

Clinical Messages and Shared Records are the IT services mostly needed as supporting elements of an RHCN supporting Mobile and Emergency, Home-care Monitoring, Reimbursement, Telemedicine, as well as Surveillance Information.

4.3. Core Services and Components Following the services redefinition phase, the level of detail produced provided PICNIC partners with the information it needed to create use-case models. Subsequently, a second template was circulated in order to collect, analyse and define high-level needs and features for each of the IT services initially selected for prototyping (i.e. Clinical Messages, Shared Records, Mobile and Emergency, Telemedicine, and Reimbursement). This template focused on the capabilities needed by the target users, and why these needs exist. As a result, a set of descriptions of functional specification and minimum data sets, for each of the included IT services was provided [7], together with the involved actors, as well as those non-trivial modules (i.e. components), forming subsystems of each IT service, that fulfill a clear function and can potentially form the crux of a common development team effort. Generic use cases for the services depicted the features of each IT service, as identified by the participating regions. The subsequent sequence diagrams produced carried enough detail to provide the needed information for the extraction and classification of a set of 18 common components, distinguished in one of the three following categories: Healthcare Application, Healthcare Common Middleware, and Generic Common Middleware (Table 3). At the end of this stage, quite a large number of software components were identifiable [9], and in the majority of cases could serve the needs of more than one of the initial PICNIC IT services. The PICNIC National Health Advisory Board and the industry board at a PICNIC workshop in December 2000 recommended that the project should focus on high priority, healthcare-specific, common components. The decision regarding the focusing of the service areas to be covered by the project were made by the participating regions in order to select the highest priority areas to concentrate software development resources upon. This was done in order to implement pilots with substantial implementation scale. Component development was therefore concentrated in three groups, around the following high priority areas:


17

Reimbursement

Telemedicine

Mobile and Emergency

Component/ Service

Shared Records

Abbreviation

Clinical Messages

Table 3. Components described through the PICNIC IT services functional specifications. Classification was done, based on [8].

Healthcare Applications Layer MSUS

Message Set Up Service

REAP

Reimbursement Application

SRAP

Shared Records Application

√

√

√ √

√

√

√

√

√

Healthcare Middleware Layer Healthcare Common Services CLPS

Claims and Payments Server

COAS

Clinical Observation Access Server

CEMS

Clinical E-mail Server

COLS

Collaboration Server

PIDS

Patient ID Server

SRDS

Shared Records Data Server

SRIS

Shared Records Indexing Server

SRUB

Shared Records Update Broker

√ √

√

√ √ √ √

√

√

√

√

√

√

√

√

√

√ √

√

√ √

Generic Common Services AUDS

Auditing Server

√

√

√

√

√

AUTS

Authentication Server

√

√

√

√

√

CMCS

Communication Service

√

√

√

ENCS

Encryption Server

√

√

√

√

√

RESS

Resource Server

√

√

√

√

√

TERS

Terminology Server

√

√

√

UPRS

User Profile Server

√

√

√

√ √

√

Bitways Layer

Component Group 1: Messaging Clinical Messaging offers one of the most important functionality in a RHCN, and consists of highly structured patient-related information concerning the treatment of the individual patient. Group 1 concentrated on the exchange of clinical and administrative data between different applications and included the use of already developed standards. Messaging between healthcare records and isolated applications was developed and implemented using HL7 v3 Clinical Document Architecture (CDA) Level 1 standard messages. As a result, a

18


number of HL7 v3 CDA message specifications (XMLS), plus operational eXtensible Markup Language (XML)/ Document Type Definitions for messaging were developed [10]. Component Group 2: Access to Patient Data (APD) Accessing patient data focused on the development of an integrated environment for professionals or citizens who need a uniform way to access parts of patient record data that are physically located in different clinical information systems. Delivering fast, secure and authorized access to distributed patient record information from multiple, disparate sources, was the main objective of this group. This environment should not be confused with autonomous clinical information systems (CIS), message based communication of Electronic Health Record data, centralized Clinical Data Repositories (CDR), or monolithic information systems that have embedded in their structure mechanisms for accessing directly host systems. Group 2 concentrated on the four components identified as required [11] for the provision of on-line access to patient data stored in different locations and applications. Component Group 3: Collaboration Access of healthcare workers (general practitioners, other doctors, nurses, etc.) to specialists is an important tool to improve quality in healthcare by means of quicker diagnosis, quicker response to emergency and guidance for correct treatment and further examinations. Group 3 was involved in the development of an environment for the provision of examination, monitoring, treatment and administration of patients through immediate access to expertise and patient information regardless of where the patient or relevant information is geographically located [12].

5. Open Source Development During the original negotiation process for the PICNIC contract, PICNIC was attracted by the potential offered by OS, despite the fact that the original work plan of the project did not include OS. In the course of events, it became quite evident that there is a plethora of tools and utilities of various kinds that cover many aspects of software development, office automation, system programming, artistic work, etc, and sites like SourceForge.net [13], FreshMeat.net [14], and FreshPorts.org [15] offer a topic oriented repository for OS software projects with a continuously updated index, descriptions and links, as well as search capabilities. Despite the fact that, in the healthcare domain, the case for OS still has to be proven, Open-eMed (previously Telemed) [16] seemed to be highly successful. Subsequently, since sharing of knowledge, as well as source code, was required by PICNIC, in order to deliver similar services throughout Europe by means of the same software components, the PICNIC OS policy was formulated as follows: • • •

All models and specifications generated regarding architecture and standards, scenarios and model for patient centred care, IT response, and common components development must be in the public domain. Common components, developed by PICNIC industrial partners, must be placed in the OS domain (through the appropriate OS license). The software of the pilots and prototypes utilising these OS common components will not be made available in OS. Its intellectual property rights will be owned by the developers and shared within the PICNIC consortium according to the European Union model contract.


19

•

A “PICNIC Open Community” must be established and encouraged, in order to build a community of OS developers who are committed to the further development, enhancement and re-use of the PICNIC components. The common components that were selected to be delivered as OS implementations for the APD component group were: •

COAS for obtaining clinically significant information directly from a CIS and also for sending new content update information. The already existing Object Management Group (OMG) COAS [17] specification served as the basis for the description of the needed interfaces to this service and its further implementation. • PIDS for enabling unique patient identification across the RHCN and for the provision of a master patient index. The already existing OMG PIDS specification [18] served as the basis for the description of the needed interfaces to this service and its further implementation. • SRIS for holding indexing information on the content of the patient data in different patient record segments within the RHCN. • SRUB for the prompt propagation to SRIS of any modification pertaining to the patient data, and therefore being used as a mediation tool for maintaining consistency with live data. The collaboration component group decided to deliver the following OS components: •

COLS for the provision of the platform that allows general practitioners and medical experts to share patient-related information in the context of a teleconsultation session both inside and across RHCNs; and • RESS for the identification of available healthcare related agents (e.g. organizations, devices, software, etc) and the means for accessing them. FORTH of Greece delivered COAS, SRIS, and SRUB components, HP Ireland delivered the PIDS component, while the Swedish company SECTRA delivered the COLS and RESS components. All PICNIC components are available through the PICNIC OS community web site [19], which is an implementation of the OS components of SourceForge.net. Each component’s package includes documentation about the installation of the component and also additional material, guidelines, and test data about its implementation. The OS licence governing PICNIC software components is the Berkeley Software Distribution (BSD) License [20] that allows others to use the OS code and its modifications for any purpose (even commercial) as long as the copyright notices remain intact for the initial developers to get the due credit. Other licenses considered were the GNU General Public License (GPL) [21] along with its less restrictive form the GNU Lesser General Public License (LGPL). For the development of these components a number of OS tools, libraries, compilers, etc. were used. They are listed below: • • •

•

The GNU Compiler Collection (GCC) [22], especially the C++ front end, was used for the compilation of the source code and its libraries in order to provide the run time environment for most of the components. The GNU Make [23] and the Apache Ant [24] utilities were used as building tools for the components executables. Various OS databases are used as data storage means, such as OpenLDAP [25] (i.e. an OS implementation of the Lightweight Directory Access Protocol (LDAP) protocol and the LDAP directory server) and PostgreSQL [26] (an advanced relational database management system). In order to communicate with the data stores some interface mechanisms are needed with their corresponding Application Programming Interfaces (APIs). In addition to

20


• • •

• • • •

the LDAP Application Program(ming) Interface for the C/ C++ programming languages provided by OpenLDAP, the Object Data Base Connectivity (ODBC) API was used. For UNIX and UNIX-like platforms the unixODBC [27] and iODBC [28] ODBC driver managers were deployed. The Jabber XML messaging protocol [29] and the OS implementation of the Jabber server were employed and extended to provide the open messaging platform for the collaborative work of medical personnel. The Concurrent Versions System (CVS) [30] was used as a source code repository during the development of most of the components, in order to guarantee access to the previous versions of source files and controlled source code. The Adaptive Communication Environment (ACE) and The ACE Object Request Broker (ORB) (TAO) [31] were employed as middleware solutions to provide the communication platform for various components and to solve accidental complexities in a cross platform manner. The Boost C++ Libraries [32] that provide a rich collection of utilities to ease the development of C++ programs. The wxWindows Graphical User Interface (GUI) framework [33] that is a truly cross-platform GUI toolkit for C++. The Apache Xerces XML parser for C++ [34]. Finally, the development and testing of the most of the components were performed in OS Operating Systems such as GNU/ Linux [35]; and FreeBSD [36].

During development support was provided through mailing lists and newsgroups. This kind of support is certainly “unpredictable”, since there is no guarantee that the problem you have encountered will be answered soon if at all. Nevertheless, PICNIC found the OS community to be highly responsive and very helpful in various occasions during the development of the components. The majority of issues faced in PICNIC proved to be minor problems that other OS developers had already encountered in the past. Additionally, commercial support was offered in practice: for example in order to have complete and compact documentation for the TAO CORBA ORB it was found necessary to purchase “TAO Developer’s Guide” from Object Computing, Inc. [37]. The objective of the “PICNIC Open Community” was to build consensus for the “PICNIC Open Architecture” as the emerging architecture for RHCNs world wide. This is more than disseminating or promoting the architecture, it involves fostering an active and open dialogue between the PICNIC team and outside parties to create a community of interest around the PICNIC project, the architecture, and the OS components. Success was indicated if, from the OS community perspective, the results created by the PICNIC team were felt to be “owned” by the community as whole.

6. Assessment Plans and Instruments The ‘traditional’ user validation approach to software assessment was not considered to be suitable in the case of the PICNIC components, since the components sit within a regional ICT infrastructure which is not visible to the users. The proof of concept from the users’ perspective is the delivery of innovative services that are facilitated by means of the common functionality offered by the RHCN. Assessment requires not only a technical validation of visible systems and underlying infrastructures, but the economical perspective as well as the social/ organisational and juridical/ ethical perspectives must be integrated into an assessment methodology. Since a regional infrastructure must operate in the context of a national infrastructure and be interoperable with local infrastructures or systems, the di-


21

mension of scale is important for the assessment. Therefore the boundaries of the systems under assessment must be clearly described. Besides the integration perspectives and the hierarchy of system scales, assessment had to address a pre-implementational approach. Since the PICNIC project was established as a European subsidised project to be delivered within a limited period of time, a traditional assessment of all those systems within all these perspectives was not possible. The main reason was that the traditional assessment approach is based upon post-implementational analysis of a systems costs & benefits, while some of the PICNIC pilot systems were planned to be implemented just at the end of the project. The main questions PICNIC had to deal with were whether: •

it is possible to develop an assessment method that can be used before systems are operational and ready to be tested; and • it is possible to integrate this assessment method with traditional assessment methods used to assess systems that are implemented within project time. PICNIC initially had to develop a proactive assessment methodology. In contrast with traditional assessment methods, proactive assessment methodology is a set of coherent methods that can be used to assess systems during design and development stages. According to Remmen [38,39], traditional assessment may be characterised by consequence assessment that is reactive on operational implementations, whereas constructive assessment stresses the importance of interactive involvement of all stakeholders. Proactive assessment is in that classification comprehensive [40,41]; it tries to understand stakeholders opinion on factor-effect relations before implementation. The aim is to enrich design decisions and to optimise the expected benefits by assessment methods. For example, not the real costs but the expected costs are established to predict the real costs and to recalculate break-even points. Also the expected benefits for several stakeholders can be evaluated before even the systems are running in order to minimise the critical success factors. In addition to traditional assessment methods that establish a range of ‘factors’ and ‘effects’, proactive assessment requires the definition of the relation between factors and effects. Since this may depend on regional characteristics and specific medical services, we had to differentiate. However, to be able to compare assessment results, we tried to harmonise and standardise the templates and questionnaires used across the regions as much as possible. Since proactive assessment must be performed in parallel to design and development, it must fit into the development stages of the project. In fact, it followed a three-dimensional approach, as depicted on Fig. 4: •

the stages of the project in which the product becomes less abstract and more physical; • the scale of the product that determines the scope, the context and the sub-systems; and • the perspectives that are relevant for factors and effects, their mutual relation and for the different stakeholders who argue mostly form the perspective of their stake. The second step was to integrate traditional and proactive methods into a coherent methodology. PICNIC established the following regional characteristics: Partner; Name of prototype; Region; Main problems; New scenario; IT solution; Main purpose; Main users; Number of users; Covered patient population; Stakeholders; PICNIC components used; Developers of these components; Developer of prototype; and Integration of components and prototype. Starting with extensive lists of factors and effects based on the FinOHTA report [42], experiences of the Coordination and Continuity in Primary Health Care (COCO) Project, and a large literature review [43–47], the participating regions were asked to select the most


conceptual logic or

concrete

nal

jur idi cal me dic al ga nis at

tec hn ica l

ion

al

interna tio

nationa l

migration system

realization

e th ica l

ation

structure

vision context

regiona l

strategy

organis

22

Figure 4. The three-dimensional CUBE model helps to understand each other in a complex project, dealing with several system-levels, stakeholders and development stages and different people at the same time.

appropriate ones for each service. The stakeholders in the regions selected the following relevant factors: IT-awareness; Current use of IT; Current provision of service (as starting point facts); Organisation of health care (as health care structure issue); Development degree of chosen technology; Security included; Reliability of technology (as technical design decisions); Number of patients; National policy (as service organisation issues); Attitudes and expectations of actors shared; Incentives and disincentives shared (as development decision issues); and Investment costs (as financial issues). The regions determined as possible effects the following: Less costs on treatment; Less costs on diagnosing; Less costs on labour (as economical effects); Change in reliability; Change in process time (as technical effects); More efficient/ faster treatment; Work satisfaction; Less people needed; Easier for patients to get access (as organisational effects); Decision support in treatment; Change in health care process (as medical effects); and satisfaction with Physicians, Nurses, Authorities, Patients, Patient family. PICNIC selected those methods that covered the factors and effects that were pointed out to be relevant by the involved stakeholders receiving services. The following set was constructed: Technical verification; Functional Validation; Costs and Benefit analysis of the ‘before and after situation’ (as traditional methods); Expected benefit optimisation; Alternative analysis; Prediction of effects (as proactive methods). The main instruments were checklists, matrices of factor-effect relations, and stakeholder specific questionnaires adjusted for each region. Besides plenary debates to discuss and reconsider design decisions, stakeholder specific meetings were organised to fill the templates. Stages in the process of assessment in PICNIC are depicted in Fig. 5. The PICNIC participants were also asked to evaluate the newly developed, proactive approach. Answering the questions whether or not it is possible to develop an assessment method that can be used before the systems to be assessed are operational and whether it is possible to integrate this assessment method with traditional assessment methods, it became clear that, like other assessment approaches, proactive assessment has its strength within its own limitations. Proactive assessment promises the maximum you can get with assessment methods in design and development projects. Furthermore, proactive assessment can easily be integrated with traditional assessment. In fact, a following traditional approach establishes experiences that are needed for proactive assessment of following projects. In this


23

STEP 1 Determine the objectives of technology assessment and choose an appropriate approach STEP 2 Determine the system types to be assessed, the different perspectives and the different actors

STEP 3 Develop a general assessment model specifying indicators, effects and methods STEP 4 Specify the systems, their boundaries and environments (technical, social and cultural) STEP 5 Adjust the general model to the characteristics of the specific systems, design evaluation instruments and make detailed plans STEP 6 Collect and analyse evaluation data according to instruments on regional level for each STEP 7 Integrate the regional results in a coherent approach and make a consolidated report STEP 8 Evaluate the whole approach as a validation of the general assessment model

Figure 5. Stages in the process of assessment in PICNIC.

way the Integral Technology Assessment approach may provide the best conditions for a formalized ongoing learning circle. As main recommendations established [48–50] were the following: • • •

•

•

The challenge seems to be to use the PICNIC approach as additional to local architectures and as blueprint at regional and/ or national levels. Security issues should be dealt with at a national level. Arrangement of a National or European (web-based) platform to exchange experiences as well as assessment results may benefit to a common learning circle. Standardised formats to record experiences should be provided to make the information easy accessible. Projects that are funded significantly with public money, and have a limited timescale should always perform proactive assessment, preferably combined with traditional assessment, and should always require open standards, open source, as well as available and accessible documentation. Since proactive assessment requires some experience with traditional assessment methods as well as an experienced conversation leader, participants could be selected by the conversation leader. This leader should provide time and space for annoying and strange questions and ideas.

24


7. The Pilots PICNIC pilots were implemented in co-operation with selected industrial partners within each of the participating regions. This offered the opportunity to test the concepts of the PICNIC architecture and the functionality offered by the PICNIC components in a number of sites delivering similar services, under a different application domain, across Europe. Since security requirements had to conform to the national legislation of each participating region, and in accordance to the regional/ national plans, standards, and requirements, different technical solutions were adopted in each case. A concise description for each of the PICNIC pilots follows in the rest of the Section. 7.1. County of Funen, Denmark The County of Funen signed in May 2001 a contract with the Swedish company SECTRA, to deliver and implement a Radiology Information System (RIS) for all the radiology departments and the nuclear department (338 employees making 260,000 examinations annually). The RIS system was complemented with a picture archiving and communication system. The two systems will form the base for treatment and diagnosing and improve both the quality and functionality in the departments. Odense University Hospital, Radiology Department, have a section for oncology patients, where the patients are examined by radiology images. This section performs 11,000 examinations per year and the patient often comes in to the department for further checkups during the treatment. Some of the patients came from the County of South Jutland and it was necessary to formalize the exchange of images, videos, referrals, diagnosis reports and other relevant clinical information for the patients. The County of South Jutland, during year 2001, implemented a system to connect the emergency departments in the County Hospitals. Essential functionality is transfer of radiology images, still pictures, sound, videoconferences and referrals. The Collaboration Monitor that was developed through PICNIC was a simple application, which included the core functionalities of creating the collaboration context, collecting relevant material, inviting participants, providing real-time collaboration, and supporting event notifications. An example of a medical collaborative activity supported by the Collaboration IT service is described below: • • • • • • • • • • • • •

a GP receives a patient with a skin problem; the GP captures a skin picture in (JPG-format); the GP creates a “collaboration context” for the episode of care; the GP accesses the “collaboration context”; the GP selects a service (set of clinical document templates); the GP updates the collaboration context with a referral using a template provided by the selected service; the GP updates the collaboration context with the skin picture; the GP invites a specialist (hospital or private doctor) to report on the case; the GP requests to be notified when the specialist accesses the collaboration context the specialist logs on to the collaboration IT service (authenticates) and receives the invitation to participate in the collaborative activity; the specialist accepts the invitation to participate in the collaboration and is added to the address book of the “collaboration context”. The event is recorded in the activity log of the “collaboration context”; the specialist accesses the “collaboration context”; the specialist accesses the collaboration items, i.e. the referral and the skin picture;


• • • • • • • • •

25

the GP receives notification that the specialist has entered the context; the GP accesses the “collaboration context” to interact with the specialist in real time; the specialist is aware that the GP is in the context; the specialist posts a message requesting details regarding a vague aspect of the referral; the GP and the specialist engage in chat conference regarding the particular episode of care; the specialist writes an examination report, based on an appropriate template; the specialist updates the “collaboration context” with the report; the specialist updates the status of the “collaboration context”; and finally the GP can access the examination report and inform the patient at the next visit.

The PICNIC components that were validated in the pilot comprised: XMLS, and COLS. 7.2. Pharmacy Patient Validation and Reimbursement, Republic of Ireland Within the health service of Ireland, the General Medical Services (Payments) Board (GMS) was responsible for making all payments in respect of primary care contractors for publicly funded health services, including consultations, appointments, procedures and prescriptions. The GMS reports to and was funded by the Department of Health and Children (DoHC). The GMS makes payments to a total of around 5,500 primary care contractors, including 1,200 community pharmacists. The DoHC have a number of strategies in place which directly support the PICNIC project and were perceived as enabling strategies for PICNIC, including: • •

the deployment of a Unique Patient Client Identifier (UPCI): the Personal Public Service Number (PPSN). This was utilise by the GMS central client eligibility index and was funded by the Information Society via the DoHC; and all public bodies, including GP practices and community pharmacies in Ireland were being linked to a new “Government Virtual Private Network” funded by the Department of Finance.

This infrastructure was the background against which the GMS were developing their prototype and was a vehicle for facilitating the mobilisation of PICNIC within Ireland. The GMS wanted to provide the 1,200 pharmacists, and later another 3,300+ contractors, access to its back-end systems (PIDS database and Claims and Payments system). The prototype included the provision of a “PIDS Access/ Messaging Component”, which was integrated into the pharmacy management applications running in the community pharmacies. Once a pharmacy application vendor integrated this component into their application, the application was able to access the back-end GMS systems to: • • •

verify the identity and eligibility of a client, under the appropriate GMS scheme and the amount spent on prescriptions to date in the current month; update the central GMS system with the value of a prescription dispensed to a client; and upload prescription reimbursement files to GMS and download the corresponding exception file (error report) from GMS.

The integration of the separate systems which presently support pharmacy reimbursement was seen in terms of access to information resources, and in terms of content, structure, and visualisation of healthcare record segments, with the goal of creating a virtual electronic prescribing record.

26


The GMS contracted with HP Ireland to develop the common components and integrate the common components into the pharmacy prototype. The “PIDS Access/ Messaging Component” enabled the communication of XML messages between the pharmacies and GMS, using the PICNIC CDA Level 1 message format. This included the conversion of the prescription reimbursement files and exception files to XML. Once the “PIDS Access/ Messaging Component” was tested with the GMS infrastructure, it was given to the pharmacy application vendors who integrated them into their applications. The PICNIC components that were validated in the pilot comprised: XMLS, and PIDS. 7.3. North Western Health Board (NWHB), Republic of Ireland The NWHB is one of 10 Health Boards within the Republic of Ireland and is responsible for providing Health and Social services for a population of approximately 220,000. Health services are coordinated nationally by the Dept. of Health. The Irish government has a number of strategies in place, which directly support the PICNIC project and are perceived as enabling strategies for PICNIC. These are as follows: • • •

The Health Strategy which sets out six frameworks for change, one of which is information and another which is strengthening Primary Care. The Reach initiative which will enable the citizens of Ireland access to an e-broker service for all public services and which will allow a seamless delivery of service across a number of services at particular “life events”. The use of a unique number is a fundamental part of the e-broker strategy and the PPSN is the identifier to be adopted.

The aims of the NWHB prototype were to • • • •

support the Public Health Nurses (PHNs) to enable them to record more accurate and accessible information about their clients; improve the service to clients by enabling PHNs to review groups of clients and individual clients to determine the service they are receiving and should receive e.g. may set up specific clinics to deal with specific problems in their area; enable demographic details to be recorded once but used many times through the link to the GMS database; and support PHNs in compiling patient and area profiles for use by other health professionals and management to better plan and deliver services.

In summary, the Public Health Nursing service works as follows: •

• •

The PHN may receive a referral from a number of sources and plans to visit a number of patients within a day. Some of these visits are repeat visits (e.g. to do a dressing) and some of these are new visits. At her first visit the PHN records basic patient information and demographics. At the end of the visit a PHN records details about the visit including what tasks/ procedures were carried out and she schedules another visit, if necessary. She may also make referrals to other professionals. At the end of each month the PHN prepares returns showing her activity for the month by care group and she prepares her travel claim which is submitted to her supervisor. At the end of the year the PHN prepares a detailed annual report of her area. In the present system this can take up to a week of her time.

The prototype allowed NWHB to see the use of mobile devices by the largest group of mobile professionals within its service – PHNs. The deployment allowed PHNs access and


27

record the care group and activity for each patient and produce information which can be shared and used by other professional groups. The prototype was also linked with patient identification services in the GMS to allow the PHN to simply enter the PPSN and pull down all of the demographic details associated with that patient. There are approximately 80 full-time PHNs in the NWHB. The pilot system was deployed in 6 PHN areas for a two month period and will be rolled out to all PHNs. The PICNIC components that were validated in the pilot comprised: XMLS, and PIDS. 7.4. Access to Patient Data, Crete, Greece A number of “Research and Technology Development” projects have contributed to the development and funding of HYGEIAnet [51], which involved FORTH, the regional authorities as well the majority of the healthcare organizations of the island of Crete. This participation contributed significantly in understanding the issues related to healthcare delivery and IT, and assisted in shaping the regional strategy for establishing a regional health information network. The strategic objective is to ensure that patients can be confident that the healthcare professionals caring for them have reliable and rapid access, 24 hours a day, to the relevant personal information necessary to support their care. An important consideration has to do with the commitment to evolve from the currently available infrastructure, while adding the new capabilities when they become available. Within that context, the Access to Patient Data service in Crete aims towards the provision of a uniform way of accessing and presenting, seamlessly, integrated health information about a person, within two hospitals, one in Sitia and one in Rethymno. In both cases the medical record exists in a number of both inpatient and outpatient clinics, which do not communicate with each other directly in all cases. Effort was based on extending the currently available integration infrastructure, by means of more robust security and authentication services, as well as the incorporation of a multitude of clinical information systems. A set of standardized interfaces was tested upon operational systems that originate from multiple vendors. The deployed user scenarios involved: • • •

Patient Identification. Browsing the longitudinal health record of the patient. Direct access to clinical information at the place produced.

The platform was built on the PICNIC components and implemented within the boundaries of the hospitals of Rethymno and Sitia, to support a seamless access, to authorized users, over patient clinical information segments, distributed throughout the hospital, and across the areas of responsibility of the aforementioned hospitals. Clinical information systems that were involved in the Rethymno pilot included PATHIS (Pathology Information System), XRFDC (X-Ray Film Digitisation Console), and Cardio-IS (Cardiology Information System), all developed by FORTH, together with the Laboratory information Systems of Greek Informatics (Πληροφορική Ελλάδας), as well as the Administrative, Financial and Pharmacy Information Systems of UniSoft. The clinical information systems that were involved in the Sitia pilot include PHCC-IS (Primary HealthCare Center Information System), PATH-IS (Pathology Information System), RAD (Radiology), and Cardio-IS (Cardiology Information System), all developed by FORTH, together with the Laboratory information Systems by Greek Informatics (Πληροφορική Ελλάδας) and both the Administrative as well as the Financial Systems by Computer Team. The PICNIC components that were validated in the pilot comprised: PIDS, COAS, SRIS, SRUB, RESS.

28


7.5. Collaboration, Crete, Greece The telecardiology collaboration service as well as a teleradiology service already existed and were operational years [52] in several Primary Healthcare Centers of the island of Crete. The tele-consultation environment in use, as well as the underlying collaboration platform of WebOnCOLL [53] have been developed in full by FORTH, and are expected to gain a European dimension through the participation and the utilization of the common specifications of PICNIC. The involved PHCCIS (Primary HealthCare Center Information System), XRFDC (X-Ray Film Digitisation Console), and CARDIS (Cardiology Information System) are all products of FORTH. The OS components developed within PICNIC were used to upgrade the functionality of the collaboration infrastructure and prove the feasibility of an intra-regional collaboration service. Furthermore, the number of the existing pilot sites, both in terms of primary healthcare centers as well as in terms of consultation centers was increased. •

The pilot for Telecardiology involved – the primary health centers of Anogia, Mires, Archanes and the Venizelion Hospital in Heraklion; – the primary health centers of Spili, Perama and the district hospital of Rethymnon; and – the primary health centers of Kandanos and the district hospital of Chania.

•

The pilot for Teleradiology involved – the district hospital of Rethymnon with the Venizelion Hospital in Heraklion (CTs and X-rays); – the primary health center of Anogia and the district hospital of Rethymnon (X-rays); – the primary health center of Perama and the district hospital of Rethymnon (X-rays); and – the primary health center of Kandanos and the district hospital of Chania (X-rays).

Operation Example: A patient arrives at a remote primary care center suffering from severe chest pain. The general practitioner conducts clinical exam, and takes an ECG. The medical history of the patient and his symptoms raise suspicion of myocardial infarction. Should the GP administer thrombolysis? Research has shown that 30 minutes delay in the initiation of thrombolysis reduces the life expectancy by approximately a year. The GP requests help, using the tele-cardiology service, from a regional Tele-cardiology center. The GP requests the creation of a shared episode folder (i.e. a collaboration context). Once the collaboration context is created the GP adds relevant clinical data to the shared episode folder including a teleconsultation request and the recent ECG of the patient. The data that included in the clinical document requesting a second opinion are: demographic data of the patient, the time of initiation of the pain, symptoms, blood pressure, history of patient as regards myocardial infraction, some data related to counter indications of thrombolysis and an ECG. The cardiologist at the tele-cardiology center takes into account these data and perhaps he may request from the GP to send one or more ECGs. Taking into account the data that have been sent to him, the cardiologist consults the GP as regards the procedure of thrombolysis. Finally, the patient may be transferred to the cardiology clinic for follow up. In addition to the above, the Collaboration IT-service has been tested and demonstrated by Odense University Hospital, Denmark and Venizelio hospital in Heraklion, Crete. The Collaboration components have been used to perform an on-line collaboration between Denmark and Greece. This demonstration has been made as a validation of the technical concept by using the RESS and COLS components in applications from different suppliers.


29

The PICNIC components that wer validated in the pilot comprised: XMLS, COAS, SRIS, SRUB, COLS and RESS. 7.6. South & East Belfast Health & Social Services Trust (SEBT) Within the Northern Ireland (NI) Region, Health and Social services are coordinated by the Department of Health and Social Services (DHSS). The DHSS have already a number of strategies in place directly supporting the PICNIC project and are perceived as enabling strategies for PICNIC; • •

the deployment of a UPCI across the whole of Northern Ireland. The UPCI is funded by the NI regional Strategy and will utilise the PIDS component within the PICNIC project All GP practices in the region are being linked to the regional datacomms network by “fixed” lines. This will reduce the complexity of security procedures for the enduser and greatly increase the speed of transmission. This project is also being funded by the regional strategy.

SEBT are responsible for the provision of Community Health and Social Care for the south and east sector of the city of Belfast serving a population of 200,000. SEBT also has a Mental Health Hospital within its organisation. Liaison with the Acute Hospitals within the Greater Belfast area and the GPs within South and East Belfast is recognised as critical in the provision of total patient care. The SEBT area covers 21 GP Practices involving 65 GPs, the potential for the NI region is approximately 990 GPs. It is against this background that the PICNIC project is seen as a vital improvement in the provision of information to improve patient information for the Health Professionals and in so doing improve patient care. The SEBT prototype was used by “out-of-hours” GPs attending a patient outside normal surgery hours. It can be assumed that the patient is not on that particular GP’s list. Therefore, in these circumstances, the GP has no knowledge about the patient and has no information on the patient’s current health, any recent or current treatment, hospital episodes or drug regime. The GP is therefore relying on the information given to her/him by the patient and their own clinical judgement. The PICNIC deployment within SEBT was designed to enable access to GP Practice information, A&E information from the Belfast City Hospital, the local Acute Hospital, and PARIS the Trust’s Patient centred information recording system covering Health, Social Care and Mental Health. The initial GP group was based on one out-of-hours service centre and is seen as stage 1 in a rollout program across such centres in NI and throughout the UK. The Shared Record Server enabled 24 hour a day access for the out-of-hours GPs to access information through the shared records application accessible via a PC or potentially a mobile device. The “out-of-hours” system (i.e., the PICNIC pilot system) enabled a generic search screen. The absence of a unique patient identifier in NI was overcome, as the generic search screen enabled users to retrieve information by requesting names or addresses with certain parameters. From the results screen the user was able to indicate which client/ s where considered to be the subject client and retrieve a minimum data set of information. The information could be further filtered by time parameters or number of encounters. The PICNIC components that were validated in the pilot comprised: PIDS, COAS, SRIS, SRUB, and RESS.

30


8. Technical Validation The objective of the PICNIC technical validation phase was to produce a plan to enable the regions to test the integration of the PICNIC components together with the functioning of the components when installed in the prototype on the pilot sites. A general implementation guideline was produced and was supplemented by each developer producing guidelines for the individual components, in order to provide feedback on the ease of integrating the components and the extent of change required to either the target configuration or the prototype software. Therefore, two testing stages were used, involving component testing, as well as integration testing. •

•

Component testing implies testing individually each unit and module. The test attempted to test the components as individual components where this was possible and carried out a link test to ensure that the prototype system worked as a whole. Each unit and module was tested individually. This phase initially was carried out by the developers, either by the same programmers who were developing the applications or other independent testers. Component testing took place at the same time as components were being developed. Some kind of supervision of this activity was planned, in order to ensure that components were tested correctly. Integration testing aims to demonstrate that the interfaces among all the components work correctly and that the system can work as a whole without faults when installed in the target system, and is not intended to prove the functionality of the system. Integration testing was carried out by the developers and the IT staff of the prototype site and in some cases required user intervention. Integration testing, comprising sub-system and system testing involved a larger number of people and had to be carefully planned. The advisable approach was that integration testing had to be carried out by an independent group of testers, different from the development team. This would consist of the IT staff on the prototype site assisted where applicable by their local IT support organisation.

The conclusions from the testing of the integration of the components showed that no major operational problems were found and all sites were able to implement and run the prototypes. The success of the prototypes on all the sites and the lack of any major problems demonstrated the capabilities of the components to be exploited and deployed in a marketing scenario. It can be claimed based on the test results that the components met the requirements specification and functioned in a highly stable manner. All sites are planning full operational implementation and are confident of systems becoming operational user systems. Guidelines provided for the implementation proved of significant importance and these would potentially require to be further enhanced as deployment takes place in locations not involved with the initial development and deployment of the components. All developers will continue to monitor that generic installation and user guidelines that are of sufficient detail to enable the components to be installed and run on a non-PICNIC site by other than the developer staff. This major piece of work enabled the components to be marketed and fully exploited. Already the PIDS, used on the GMS and NWHB sites, will be further developed as a result of component deployment in the full operational pharmacy system and extension to GPs. FORTH has plans to incorporate the PICNIC components within the development of their national, integrated regional health system. Finally SEBT intends to roll out the PICNIC components to access data on line from GP, A&E and Community systems, incrementally over the next 18 months following the critical path of direct line installations to GPs and extend beyond “out-of-hours” GPs by linking A&E departments.


31

To prepare their components for exploitation on the commercial market the component developers recognised the need to develop the following aspects of the components. •

Pricing structures: – pricing of the components for marketing; – distribution costs and % revenue to local distributors; – capital costs, licence fees and revenue costs; – training and support costs.

•

Support: – on going support for implemented components; – local distributors appointed on a sub-contracting basis; – remote support from developers; – full system documentation; – training packages and implementation guidelines; – commitment to continual enhancement of the components.

•

Service Level Agreements: – Service Level agreements as part of the supply package when the components are purchased.

•

Open Source: – Clarification of the part the OS concept regarding exploitation and further development of the components and quality control in an OS environment.

9. Certification The purpose of the certification work in PICNIC was to document the guidelines and process for certification for OS software developers who are enhancing/ developing components based upon the PICNIC architecture, specifications. In this work, the PICNIC consortium was supported by the Netherlands Organisation for Applied Scientific Research (TNO). 9.1. Component Certification For PICNIC there were two principal reasons for applying a method that assesses the final software product and pays less attention to the process and the internal products: • •

since the software is developed by centres across Europe, each with their own “informatics culture”, it would be difficult to assess all these different processes of software development; and the future users of the OS software will be more interested in a clear description of the quality of the source code then the way it was developed.

Certification is a way in which the quality of software can be demonstrated. The major reason is to secure a minimal level of quality in the products that are subject to the certification process. There are 3 generally accepted approaches to certification, these being: • • •

evaluation performed by the relying party itself (self certification); evaluation performed by someone other than the relying party (full external certification); and evaluation performed by the relying party itself but monitored by someone other than the relying party (self certification with external reference).

32

D.G. Katehakis / The PICNIC Story QUINT (extended ISO/ IEC 9126)

Functionality Suitability Accuracy Interoperability Compliance Security Traceability

Reliability Maturity Fault tolerance Recoverability Availability Degradability

Maintainability Analyzability Changeability Stability Testability Manageability Reusability

Portability Adaptability Installability Conformance Replaceability

Efficiency Time behaviour Resource behaviour

Usability Understandability Learnability Operability Explicitness Customisability Attractivity Clarity Helpfulness User-friendliness Support

Figure 6. Six groups of quality characteristics. Extensions to the ISO/ IEC 9126 are in italic. Addition for use by PICNIC is underlined.

Certification is most often performed by a specially registered organisation that follows specific standards that specify how audits must be executed. What is certified is a statement of conformance by the certified that they conform to a standard in whole or partially. The improvement of the software development method was not an issue in the PICNIC project, hence a method for the assurance of an external software product was chosen. In other words, what was tested was the quality of the software for the end-users (programmers that will modify the common components for local use) rather than the quality of the process of design and implementation. The international standard applicable to this type of evaluation is International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) 9126 [54]. PICNIC selected to use the QUality in INformation Technology (QUINT) method, which is an extension to ISO/ IEC 9126), and where three steps have to be considered when writing the test plan: •

specification of quality requirements; – selection of relevant and important characteristics; – specification of characteristics with indicators, methods and levels;

•

specification of effort; – planning of effort needed for testing; – testing;

•

executing the tests; – performing measurements; – analysing the results.

The first step was to determine if a quality characteristic is relevant in the project (see Fig. 6). Next, the relevant quality characteristics were prioritised. Prioritising quality characteristics is always an important step, because they usually conflict with each other. For instance: execution speed is in conflict with security, readability and changeability of source code, traceability etc. Depending on the goals, the targets for quality characteristics were then set and for each quality characteristic several levels were determined: •

Minimum level: none of the relevant quality characteristics should measure below the minimal level. In case one single characteristic scores below its minimum level, the project fails and the product is unusable.


• • • •

33

Current level: when the software product replaces a current situation, a current level is also available. In general, the acceptable level will be equal to or higher than the current level. Acceptable level: if all characteristics score above the acceptable level, the product has passed the test. Target level: each quality characteristic should have a challenging target level. Maximum level: this is a theoretic level and describes the upper limit of what is possible.

The relative importance of each quality characteristic determined the minimum, acceptable and target levels for the quality characteristic. The required levels of quality characteristics then determined how the developers’ time had to be divided. The fact that in PICNIC the levels for the quality characteristics varied per service was discussed in a workshop held in Copenhagen during the development of the certification approach (February 2003), the output of which was documented and used in the software validation process that followed. The availability of measurable results is expected to help in stating the user requirements and estimating the costs for future healthcare system implementations. 9.2. Certification Model OS software has several intrinsic characteristics that enhance the quality of software: • • • •

sources of OS software are public; others than the authors inspect the software; only well documented software is easily be used by others; and all OS software will not have hidden features that pose a security thread.

Negative aspects of OS software is that it depends on a functioning community that is maintaining the software. In general there is no reason why Open Source software cannot be of a high quality. In order to ensure the minimal quality of submissions of PICNIC common components to their pool of OS software a Quality Management System (QMS) had to be in place. This system described all the relevant responsibilities and procedures in a set of documents: • • • •

the rules that govern the working of the PICNIC committee; the PICNIC common components acceptance criteria; the template for the PICNIC common component validation test report; the PICNIC test harness.

The process described above pertains to the implementation only of the PICNIC common component under consideration and does not pertain to the complete system as put on the market by the manufacturer. The PICNIC trust mark is issued after the successful certification procedure and indicates a proper implementation. The following scenario must be executed in the process that leads to a certificate for a product that has implemented a PICNIC Common Component: • • • •

The manufacturer installs a QMS, including the Notified Body Function (NBF) that conforms to the TNO QMIC® Quality Management system and the management accepts responsibility for the functioning of the NBF; the Notification Body (e.g. TNO) notifies a NBF within the organisation of the manufacturer, and subsequently this manufacturer becomes a PICNIC recognised supplier for this PICNIC common component; the manufacturer uses the PICNIC common components acceptance criteria; and tests the product;

34


•

when the results of the tests indicate that there is a conformance to the PICNIC acceptance criteria the NBF issues a certificate.

This is the process of self certification on the basis of the certificate the responsible organisation will issue the PICNIC trust mark. During the process of testing and certification the Notified Body could perform checks on the functioning of the NBF. PICNIC certification describes the rules for acceptance into the PICNIC pool of components, together with related ongoing tracking and use in measurement. Since the community members will have their own acceptance criteria, it is expected that certification will evolve over time based on the participants’ needs.

10. Conclusions OS software development works! PICNIC used many existing OS components in its developments, enhanced some of these and wrote its own PICNIC components, and the resulting prototype systems were integrated successfully without any major problems. However, undertaking socio-economic assessments of individual components, when they are embedded in an application or service comprising many components, turned out to be a complex task. The PICNIC architecture was validated through the deployment of the components in 6 regional pilots, which were used operationally to deliver benefits to patients and other stakeholders in the RHCN. Whilst most researchers/ developers seem to concentrate on the technical aspects of architecture development, i.e., platforms etc, in fact the most important/ difficult aspect of deploying an architecture relate to the organisational and political aspects of establishing the Regional Health Economy (RHE) who are the users of the architecture and the associated RHCN services. It has been proven that the main issues surrounding the deployment of trans-national ICT services, such as the Collaboration service, relate not so much on the technical/ security aspects, but rather on establishing the correct legal, regulatory and reimbursement procedures, together with the use of a language of common understanding and the appropriate terminology considerations. In trans-national RHE, where these aspects have already been addressed in existing “paperwork” systems, the ICT service can easily be deployed. Despite the fact that this paper did not touch issues related to the architecture, technology, and exploitation aspects of the PICNIC project, it has delivered a concise presentation of the overall story. PICNIC developed a new paradigm for healthcare ICT architecture based on • • • •

a healthcare information infrastructure comprising of a set of OS components that support the architecture; a proactive assessment; a number of case studies with independent evaluation reports; and a certification model.

These products are all available through OS to all, without charge, even though “free” products still have to be marketed to defined customers. European healthcare ICT services suppliers will not speculatively adopt an architecture/ framework of standards, no matter how robust the case for its use, without a clear demand for such a framework coming from the buyers of ICT services. The lead in adopting a RHCN architecture must therefore come from the ICT policymakers in the regional health authorities. Many authorities, however, do not appreciate the need for inter-enterprise integration architecture, as they are still in the business of trying to integrate islands of information within their organisations via “traditional enterprise” approaches. The need for inter-enterprise integration tools/ methods only


35

becomes apparent, therefore, at a later stage of development of the RHCN, when integration across organisational/ regional boundaries is attempted.

Acknowledgements This paper wouldn’t have been possible without explicit contributions from Knut BERNSTEIN (MEDIQ), Ita BROWN (SEBT), Morten BRUUN-RASMUSSEN (MEDIQ), Leslie FINLAY (SEBT), Mary CORRIGAN (NWHB), Vesa PAKARINEN (VTT), David PIGGOTT (Integrity Consulting Partners/ GMS(P)B), Stelios SFAKIANAKIS (FORTH), and Albert E. VLUG (Erasmus University).

References [1] Rumbaugh, J. (1997). OMT Insights: Perspective on Modeling from the Journal of Object-Oriented Programming. [2] Jacobson, I., M. Christerson, P. Jonsson, and G. Overgard (1995). Object-Oriented Software Engineering: A Use Case Driven Approach. Menlo Park, California: Addison-Wesley Publishing Company. [3] Rational Software http://www.rational.com/index.jtmpl. [4] Building Regional Health Care Networks in Europe, John Oates, Henrik Bjerregaard Jensen (editors), IOS Press, 2000. [5] PICNIC Deliverable 3.2, New Model for Providing Services, July 13, 2000. [6] PICNIC Deliverable 4.1, New Services, March 6, 2001. [7] PICNIC Deliverable 4.2, Functional Specification and Minimum Data Set for New Services, March 14, 2001. [8] European Pre-standard CEN/TC251/WG1/PT1-013: Medical Informatics: Healthcare Information System Architecture, Brussels, CEN, November 1995. [9] PICNIC Deliverable 6.1, Identification of Generic Tools and Common Components, Part I, April 25, 2001. [10] PICNIC Deliverable 6.2, Messaging Components Harmonized Specification, May 10, 2002. [11] PICNIC Deliverable 6.3, Access to Patient Data Component Specifications, March 11, 2002. [12] PICNIC Deliverable 6.4, Collaboration IT Service Component Specifications, June 4, 2002. [13] SourceForge.net http://sourceforge.net/. [14] Freshmeat.net http://freshmeat.net/. [15] FreshPorts http://www.freshports.org/. [16] Open e-Med http://openemed.org/. [17] OMG, Clinical Observations Access Service, version 1.0 http://www.omg.org/technology/documents/ formal/clinical_observation_access_service.htm. [18] OMG, Person Identification Service, version 1.1 http://www.omg.org/technology/documents/formal/ person_identification_service.htm. [19] PICNIC Open Source Community web site http://picnic.euspirit.org/. [20] Open Source Initiative – OSI, The BSD Licence http://www.opensource.org/licenses/bsd-license.php. [21] Licences – GNU Project – Free Software Foundation (FSF) http://www.gnu.org/licenses/licenses.html. [22] GCC Home Page http://gcc.gnu.org/. [23] GNU Make http://www.gnu.org/software/make/. [24] The Apache Ant Project http://ant.apache.org/. [25] OpenLDAP Community http://www.openldap.org/. [26] PostgreSQL http://www.postgresql.org/. [27] ODBC and the unixODBC Project http://www.unixodbc.org/. [28] Platform Independent ODBC http://www.iodbc.org/. [29] Jabber Software Foundation http://www.jabber.org/. [30] Concurrent Versions System http://www.cvshome.org/. [31] Real-time CORBA with TAO (The ACE ORB) http://www.cs.wustl.edu/~schmidt/TAO.html. [32] Boost C++ Libraries http://www.boost.org/. [33] wxWIndows Home http://www.wxwindows.org/. [34] Xerces-C++ Parser http://xml.apache.org/xerces-c/. [35] Linux Online! http://www.linux.org/.

36


[36] The FreeBSD Project http://www.freebsd.org/. [37] The ACE ORB http://www.theaceorb.com/. [38] A. Remmen: Pollution Prevention, Cleaner Technologies and Industry. In: A. Rip, T.J. Misa, J. Schot, eds. Managing technology in society. London: Pinter Publishers, 1995; pp. 199–222. [39] J. Grin, H. Van de Graaf, R. Hoppe: Technology Assessment through Interaction. A guide, Den Haag: SDU, 1997. [40] J. Müller, J. Kjaer-Rasmussen, C. Nøhr: Proactive Technology Assessment as a Tool in HIS Development, Proceedings Medinfo 1989, pp. 306–311. [41] C. Nøhr: The evaluation of expert diagnostic systems – How to assess outcomes and quality parameters? Artif Intel Med 1994, pp. 123–125. [42] A. Ohinmaa, J. Reponen: A Model for the Assessment of Telemedicine and a Plan for testing the Model within five Specialities, FinOHTA Report No. 5, 1997. http://www.stakes.fi/finohta/e/reports/005/. [43] H. V. Fineberg, H. H. Hiatt: Evaluation of medical practices. The case for Technology Assessment. N Engl J Med 1979; 301: pp. 1086–91. [44] G.S. Omenn, J.R. Ball: The role of health technology evaluation: a policy perspective, in: Health Care Technology Evaluation. J. Goldman, ed. Berlin: Springer Verlag, 1979: pp. 6–32. [45] E.G. Guba, Y.S. Lincoln: Fourth Generation Evaluation, Sage Publication, Newbury Park, CA, 1989. [46] J. Shemer, T. Schersten, eds.: Technology Assessment in Health Care: From Theory to Practice, Gefen Books; ISBN 9652291226, 1995. [47] C.P. Friedman, J.C. Wyatt, A.C. Smith: Evaluation Methods in Medical Informatics (Computers and Medicine), New York: Springer Verlag, 1997. ISBN 0387942289. [48] PICNIC Deliverable 5.1, Proactive Assessment Model, April 19, 2001. [49] PICNIC Deliverable 9.1, Assessment Plans and Instruments, July 15, 2002. [50] PICNIC Deliverable 9.2, Proactive Assessment of Regional Prototypes, February 28, 2003. [51] HYGEIAnet, the Integrated Health Telematics Network of Crete http://www.hygeianet.gr/. [52] C.E. Chronaki, et al. ‘Preliminary Results From The Deployment Of Integrated Teleconsultation Services In Rural Crete.’ In Proceedings 28th Annual Computers In Cardiology Congress from 23–26 September 2001, Rotterdam, The Netherlands. [53] C.E. Chronaki, D. G. Katehakis, X. Zabulis, M. Tsiknakis, S. C. Orphanoudakis: WebOnCOLL: Medical Collaboration in Regional Healthcare Networks, IEEE Transactions on Information Technology in Biomedicine, Vol. 1, No. 4, December 1997, pp. 257–269. [54] ISO/IEC 9126: Software product evaluation – Quality characteristics and guidelines for their use (1991).


37

PICNIC Architecture Niilo SARANUMMI1 VTT Information Technology, PO Box 1206, FIN-33101 Tampere, Finland Abstract. The PICNIC architecture aims at supporting inter-enterprise integration and the facilitation of collaboration between healthcare organisations. The concept of a Regional Health Economy (RHE) is introduced to illustrate the varying nature of inter-enterprise collaboration between healthcare organisations collaborating in providing health services to citizens and patients in a regional setting. The PICNIC architecture comprises a number of PICNIC IT Services, the interfaces between them and presents a way to assemble these into a functioning Regional Health Care Network meeting the needs and concerns of its stakeholders. The PICNIC architecture is presented through a number of views relevant to different stakeholder groups. The stakeholders of the first view are national and regional health authorities and policy makers. The view describes how the architecture enables the implementation of national and regional health policies, strategies and organisational structures. The stakeholders of the second view, the service viewpoint, are the care providers, health professionals, patients and citizens. The view describes how the architecture supports and enables regional care delivery and process management including continuity of care (shared care) and citizen-centred health services. The stakeholders of the third view, the engineering view, are those that design, build and implement the RHCN. The view comprises four sub views: software engineering, IT services engineering, security and data. The proposed architecture is founded into the main stream of how distributed computing environments are evolving. The architecture is realised using the web services approach. A number of well established technology platforms and generic standards exist that can be used to implement the software components. The software components that are specified in PICNIC are implemented in Open Source.

1. Introduction 1.1. The Context of PICNIC PICNIC was set up to respond to the challenges arising from three global factors (Fig. 1): –

–

Changing operating environment comprising a number of issues like the “new economy” leading to institutional changes, informed citizens demanding personalised health services and the emerging legislation and guidelines on privacy and security of personal information. Changes in healthcare delivery comprising the move towards clinical pathways and evidence-based care, provision of integrated health services (citizen-centred services, continuity of care or seamless care) across organisational boundaries and

1 The text is based on the work done in the architecture work package of PICNIC. Persons who have contributed to that work package are Dimitrios Katehakis and Manolis Tsiknakis, ICS-FORTH, Greece, David Piggott, General Medical Services, Ireland, Leslie Finlay, South & East Belfast Health & Social Services Trust, North Ireland and Brian Bray, Minoru Corp., France.

38

N. Saranummi / PICNIC Architecture The changing environment • new economy • institutional changes • informed citizen • privacy

Past Past Generation Generation RHCN RHCN Connecting “islands” with messaging (EDI, HL7) (loose coupling, federation)

What has changed?

Service delivery changes • integrated care • EBM • customer centered Technology push • Internet, wireless • Content providers

Next Next Generation Generation RHCN RHCN Rethinking of WISE “18 services” • Architecture • Interoperability • Common services (tighter coupling, federation)

Figure 1. Issues driving the next generation regional healthcare network (RHCN).

–

even extending care to outside the walls of care organisations and making the patient a member of the care team (especially in the case of chronic diseases), and moving from care to health, or wellness management Technology push from the quick advancement in Internet and wireless technologies and standards combined with the emergence of content providers and new business models for IT services (e.g. application service providers, ASP, Internet Service Providers, ISP, internet-portals, and eHealth service providers).

Combined these provide both the push and pull towards a next generation regional healthcare network. In the past, it was enough for the care providers in a region to collaborate loosely and to use Edifact and HL7 based messages for information exchange to support collaboration. Today the collaboration needs to be tighter. The reasons that push care providers towards tighter collaboration include meeting national and regional health objectives, cost containment, improving quality, efficient use and allocation of resources and in some countries competition between care providers. Tighter coupling in health services delivery requires upgrading of the regional health information infrastructure by incorporation of regionally available common healthcare specific services. Conceptually the questions PICNIC aimed to study were the following: What IT services are necessary to support the collaboration and co-operation of healthcare organisations (enterprises) in a regional setting; how should the IT systems be interfaced for interoperability and what technologies and standards should be used in the implementation. 1.2. Structure of the Chapter The chapter is organised as follows: Section 2 presents the concepts and issues considered in the design of the PICNIC architecture. This is followed in Section 3 by a discussion of IT system architectures and ways to present them. The following Sections 4 to 8 present the architecture from different viewpoints. Section 9 describes the implementation of the architecture and Section 10 provides the final conclusions. If the reader is interested in more detail about the rationale behind the choices made and the background information used in formulating the architecture, such as relevant standards, industrial technology platforms and previous projects one should go to the PICNIC website where all documentation is freely available (www.medcom.dk/PICNIC).

N. Saranummi / PICNIC Architecture

39

Figure 2. Extension of care outside “hospital walls” creates additional needs for collaboration between providers in order to provide high quality cost-effective services.

2. Inter-Enterprise Integration 2.1. Extending Care – Virtual Health Care Hospitals (as all enterprises) are tightening their internal integration through the Enterprise Application Integration (EAI) approach and in doing that they are making use of existing generic and healthcare specific standards. The Integrating the Healthcare Enterprise (IHE) initiative (e.g.: www.himss.org/ihe) is an example of the co-operation of industry and user communities in furthering this goal. Healthcare enterprise applications and their integration comprise a large set of clinical information systems for specific medical domains such as laboratory, radiology, intensive care, and anaesthesia and operating rooms. Within these, we can find another set of systems such as decision support systems and computer assisted or remotely guided diagnostic and therapeutic procedures based on e.g. virtual reality. The integration of the systems includes interoperability and connectivity at the functional and semantic level, incl. vocabularies and, of course, standards. At the process level, it comprises integrated clinical pathways and evidence based medicine, EBM (e.g.: www.cochrane.org). Parallel to this trend the number healthcare services delivered outside the “hospital walls” has increased tremendously. Health care is migrating out from the hospitals (Fig. 2). Examples include telemedicine, which has been a very popular field of experimentation in the last decade. Today it is mostly seen as a technology enabling the collaboration of healthcare providers over a distance in delivering a service to the patient. This can take place either in a store and forward mode or in real time. Home healthcare is often seen as a modality of telemedicine. Examples include the “home hospital” for episodic and chronic care and follow-up and monitoring of patients after hospital discharge. These operations can be performed with the real or virtual presence of care personnel in the homes. The main characteristics of these two are the extension of the hospital concept towards a virtual hospital (a.k.a. hospital without walls) and that healthcare professionals are clearly in the loop caring for the patients. Chronic disease management programs bring the patient to the centre of the process as the most important actor in the care team. Although chronic disease management involves normally a large team of healthcare professionals from primary to secondary care the outcome of the process is determined mostly by the actions and activities of the patient in complying with the recommended care guidelines. In this area, a number of applications have been created to support collaboration and sharing of information. Disease manage-

40


ment is a step towards a more comprehensive health management regime. Its primary objective is to prevent disease episodes. Wellness or health management in general is a natural corollary of this where the objective is to assist an individual to maintain her/his health status. Today the IT technologies that are applied in this context include e.g. smart environments utilising ubiquitous computing techniques combined with embedded and wearable sensors. eHealth dot.com’s were projected to be a response to the interest of the general public in health and wellness. Unfortunately, initially neither the services offered nor their pricing met the expectations of the customers. Empowering the individual or patient in health and illness management is conceptually a nice idea but its successful implementation is not an easy task. The primary challenge is the development of an application that the individual finds useful and motivating. eHealth applications range from simple web pages that provide information and knowledge to interactive services supporting a number of interaction modalities (e.g. SMS, MMS, email, voice and internet). Equally challenging is their integration into the way healthcare services are provided and reimbursed. The ageing population poses yet another challenge in terms of how to support the independent living of individuals and their continued integration to the society. ICT is part of the solution. The other part is the same as for eHealth, what are the services and who reimburses the cost of utilization. Wireless technologies extend further these new forms of care by allowing patients and care team members to be mobile and still have access to the services. 2.2. Regional Health Economy The trends discussed above are implemented into the structures within which healthcare services are provided in countries. These structures are different and vary from country to country – and sometimes even within national boundaries. In some European countries, the various healthcare entities within a region, e.g. GPs, hospitals, payers, etc., work together in a formal hierarchical organisation, headed by a regional authority of some form, usually with executive powers regarding the governance of the bodies within its jurisdiction. In other countries, the organisation of the healthcare entities, which collectively provide healthcare in a defined geographic region or to a population group, is informal. I.e., they are a ‘loosely coupled’ set of independent organisations, which have come together by mutual arrangement to co-operate in the delivery of healthcare to their client population. It therefore follows that the regional grouping of healthcare organisations will not behave in the manner of a classic ‘enterprise’, where major issues of policy and standards are prescriptively defined and enforced from the parent body at the top of the organisational structure. Furthermore, the funding models for care differ between countries. Accordingly, to define an umbrella term for the groups of organisations (both providers and payers or purchasers) that collectively form a European ‘healthcare region’ we have introduced the term regional health economy (RHE), in order to embrace both the formal and informal structures that exist within Europe. The characteristics outlined above for a RHE were also seen in the PICNIC regions. The organisation of care delivery in the PICNIC regions varied. In some, care providers collaborated based on mutual agreements. In some, a regional authority existed that regulates the relations between care providers. This variation is one factor that must be considered in defining the architecture of RHCNs. The aim, of course, is to find a solution that suits all RHE’s. Figure 3 presents a conceptual model of the relationships between the RHE and the RHCN. The top part of the model describes how the knowledge base of best medical practice and the national health policies and strategies form the framework within which the


Medical Medical knowledge knowledge (EBM, (EBM, best bestpractice) practice)

The combination determines how • care is organised • integrated it can be • client centred the service is

National National health healthpolicies policies Regional Regional purchaser-provider purchaser-provider&& provider provider--provider provider relations relations

Care CareProcesses Processes (shared (sharedcare) care)

IT ITneeds needs Regional Health Care Network

RHCN RHCN Commercial Commercial offering offering

The context: • Norms • Standards

Legislation, policies, provider and payer organisations, health care professionals

41

Figure 3. The structure of the RHE determines what functions the RHCN needs to support and enable.

National NationalAuthorities Authorities Laws, Policies Goals / Strategies

RHCN combines the needs coming from the user side and the products and services coming from vendors

Regional Health Economy, RHE

Regional RegionalAuthorities Authorities “ICT strategy of the RHE” Describes how the interenterprise environment (RHE) makes use of ICT products and services and how the RHCN is to be developed

Care CareProviders Providers Service Provider ICT ICTStrategy Strategy RHC RHCNetwork Network Architecture Architecture Service ServiceProvider Provider

Business plans IT trends

IS Vendor IS Vendor IS Vendor IS Vendor IS ISVendor Vendor Components Components

Systems Systems integrator integrator SW SWtools tools

Figure 4. The business model for creating the RHCN and role of strategies and stakeholders in it.

health care organisations are created and then organised into a regional health economy. The structure of the RHE determines how care is organised, e.g. to what extent it can be claimed to be seamless, citizen centred and shared across providers. The task of the RHCN is to support and enable the information processes involved in delivering and managing care. The RHCN comprises an integrated set of IT applications and common IT services operating on top of a hardware platform and is provided by vendors. Figure 4 presents another view to the relationships discussed above. From top-down, the healthcare organisations form the RHE in order to co-operate in health service delivery. In doing so they implement laws, policies, goals and strategies defined by national and regional (if such exist) authorities. The result of this is a set of regional healthcare services aimed at meeting the health needs of the population at an affordable cost and acceptable level of quality. To support and enable the necessary information processes a RHCN is necessary. To formulate their needs the users will have to develop and maintain a regional ICT strategy that guides the process of procuring the RHCN and in adding new functionalities to it over time. When viewed bottom-up, the RHCN is a result of integrating products from different vendors into an interoperable regional health information infrastructure using systems integration services and making this service network available to users, e.g. in an ASP-mode, by a IT service provider, which is committed to maintain and manage it for the RHE.

42


2.3. Inter-Enterprise Integration The definition of the RHE comprises a variety of ways that healthcare organisations in a region can collaborate. The important thing to realise is that these organisations will retain their independence and that their collaboration with each other is determined by their interests. That also means that there may be competing interests, i.e. healthcare organisations offering similar services. Consequently, the ICT technologies deployed by the healthcare organisations can be different. They will have different technology platforms for the integration of their respective enterprise applications. Due to the way they’ve been taken to use it is probable there is more than one technology platform in use in these respective organisations. Migration into a one common platform therefore is not a simple task. Furthermore, having a common platform depends on the will of the organisations. Similarly, none of the organisations owns the RHCN. Its development will depend on how the healthcare organisations can reach consensus and agreements on where to collaborate and where not. The task of the RHCN is to make data and information securely available in the inter-enterprise environment where it is needed, when it is needed and in the format it is needed. PICNIC’s focus is the RHCN, in other words, inter-enterprise integration. It is not concerned with how the enterprises are internally integrated (the EAI aspect discussed earlier). The same principles can be applied to integrating healthcare organisations at a national level and across national borders (Pan-European). 2.4. Integration of Functions, Common IT Services Message brokering is an effective means of integration for loosely federated systems that need to share only data. Tighter coupling may be desirable in some instances to avoid replicating the same functionality in several applications. Tighter coupling means that certain IT services can be common and used by a number of applications instead of building that IT service inside each application. These common IT services are called middleware services and are characteristic of distributed computer architectures (platforms). The advantage of the messaging approach is that it imposes no unified information model for the whole system. Therefore, it gives freedom of design and implementation of the applications. On the other hand, interoperability is restricted to items that are exchanged by the messages. Instead of a common information model, each application can have its own information models. A common model is needed only for the data that is to be exchanged between applications. The distributed common IT service approach imposes a level of common design, which varies according to the actual composition of the platform. The higher the number of common IT services in the platform the more restrictions there are in the design of the applications. On the other hand, common IT services also make it quicker and easier to design and implement applications as they can utilise these common IT services. Middleware emerged as a result of evolution of computer architectures (Fig. 5) in response to business needs. In the 70’s and 80’s systems were running on mainframes accessed through (dumb) terminals. The emergence of client / servers divided the business logic into two. Part of it resides in the client end and the other part together with the database in the server end. Communication between these parts is through a network (normally using TCP/IP). This architecture utilises PC’s as the clients and allows the server to be located where convenient for support. The next step was a more distributed architecture with a middleware services layer supporting the distributed applications. This allowed a flexible design of the applications as they can rely on basic IT services (such as naming & trading and security) being available in the middleware layer. These 3-tier distributed environments evolved as a solution to support and enable the complex transactions of large business enterprises.


All in one (monolithic) UI Business Logic

Client / Servers GUI

3-tier distributed (EAI) GUI

43 n-tier Internet (Web services) Access devices (PC ... UMTS)

Business Logic

Database

Business Logic Network wired & wireless Applications thin or thick client

Database

Applications

Common Services Network

ASP, Service, ASP, Service, Content etc. ASP, Service, Content etc. Providers Content Providers Providers Common Common Services Common Services Services

Figure 5. Evolution of distributed computer architectures.

The Internet is a fully distributed environment without hierarchy (all nodes are equal). It can be deployed by enterprises both to restructure their internal computing environment with web-based approaches (intranet) and to communicate with the outside world (extranet). Wireless technologies together with various access devices (e.g. PC’s, PDA’s and mobile phones) have added further freedom of choice to enterprises to structure (and migrate) their distributed computing environments. The Internet approach enables the networking of enterprises. Instead of the 3-tier architecture we now have a network of these, n-tier architecture. The other side of this is that the enterprises that are networked still need to negotiate between themselves what they can and are able to share, i.e. how far the federation concept can be taken and what common services (health or IT related) can exist. Distributed architectures and common IT services go hand in hand with objects and object orientation. There are two main industrial consortia working in distributed architectures and common IT services, namely the Object Management Group, OMG (www.omg.org) and Microsoft. OMG comprises all major computer and software vendors including Microsoft. It is a joint venture to define a fully object based architecture. It has published the Common Object Request Broker Architecture, CORBA (www.corba.org) definition based on the Object Request Broker (ORB) and a set of horizontal and vertical common IT services. One of the vertical domains identified is healthcare in which a special healthcare domain task force, HDTF (healthcare.omg.org/) develops healthcare specific common IT services. ORB is implemented by a number of vendors together with some common IT services defined by OMG. Although Microsoft today officially participates into OMG it does it only to provide interfaces and access to its own object based solutions. Interoperability across OMG and Microsoft platforms can be achieved but it requires special means, as Microsoft does not use all the standard features included in object orientation in contrast to OMG, namely inheritance. The Model Driven Architecture, MDA (www.omg.org/mda/ index.htm) initiative is a recent attempt to bring the various approaches under one common umbrella. With the success of the web servers, web browsers and Java as a programming language, Sun’s J2EE has become also a de facto standard platform for building distributed web-based environments. Integration of OMG- and Java-based applications is today a standard feature with the extension of the ORB towards the Internet through the Internet interoperability protocol, IIOP, and the Remote Method Invocation protocol, RMI, at the J2EE side. Web services are being developed by the World Wide Web Consortium, W3C (www.w3c.org) and the Internet Engineering Task Force, IETF (www.ietf.org). Web service technologies will most likely be the means that applications use to communicate with each other. Similarly, component technologies will most likely be the way that applications will be created. W3C has been instrumental in developing standards and solutions for the

44


Internet environment. The steps from SGML through HTML to XML are one such example. Today XML together with its extensions is finding many uses in integrating data and enterprise functions. SOAP (Simple Object Access Protocol) is another example of how XML can be used to transfer function calls between applications. These developments can also be viewed as generation shifts. The 1st generation approach was the original OMG and Microsoft DCOM solutions. The Internet created a need for the 2nd generation with access mechanisms to and from Internet, e.g. the IIOP extension of the CORBA architecture. The further proliferation and quick take-up of the Internet produced the 3rd generation with XML and SOAP (more generally web services) as means to provide tighter integration in widely distributed environments. Large infrastructures normally deploy both messaging and middleware IT services to achieve the desired level of integration. Whatever the technical architecture or platform in real life its selection is only part of the solution. The other part of the solution is migration. In most cases, even in healthcare, there are already existing applications and an existing infrastructure. The task is to add new applications to this infrastructure or to replace existing ones with new or better applications or both. In addition, it is often desirable to continue to make use of the databases that store valuable (patient) data even though the actual applications will be replaced. This is called encapsulation of legacy systems. An implementation strategy or migration path as part of the overall information management and technology strategy is necessary to manage these processes. When migrating from an existing infrastructure towards a new one, several issues with associated costs have to be considered. The first is what changes are necessary in the platform to support the applications. It may be that the existing infrastructure only uses ad-hoc messaging. Decisions have to be formulated how and when to upgrade the platform itself and whether the costs involved are outweighed by the expected benefits and savings. The second set of issues concern the applications that are supported by the platform. Is it better to replace an application that only meets partially the needs of its users or to add new functionality into it? The decision depends on assessing what is available on the market in terms of functionality and cost and comparing these against the costs and risks of upgrading an existing application. The third set of issues deal with integrating the new systems and components into the infrastructure and testing them, taking them into use (including training and assistance of users) and in maintaining and managing the infrastructure. 2.5. What Standards, Methodologies and Technologies to Use The actual realisation of a RHCN depends what IT technologies and IT & software development methodologies one decides to use. Unified Modelling Language (UML) seems to be widely accepted as a way to elicit user requirements. Similarly, Component Based Software Development is emerging as the method to build reusable software. Mainstream IT technologies today are based on the Internet, e.g. standards development activities of the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) including the semantic web and broadband, wireless and mobile communication technologies for anytime anywhere access to information. Hardware and software security aspects and privacy of confidential patient data, overall trust of complex systems and the technologies and standards, such as the Public Key Infrastructure (PKI) and smart card technologies also belong to this area. The services of the RHCN firstly need to integrate the information that is shared between the parties that collaborate in the RHE. The other primary need is to guarantee the security and confidentiality of patient data. Mainstream standards, such as Health Level Seven (www.hl7.org) and Dicom (medical.nema.org/), can be deployed to achieve the re-


45

Access Accessdevices devices Physical users access regional and enterprise applications through various access devices using wired and wireless networks

Physical Physicalnetwork network Enterprise appl’s Regional appl’s

Common services are used by regional and enterprise applications to enable interoperability and to add modularity

Enterprise Enterprisewide wide common commonservices services

Inter-Enterprise Inter-Enterprisewide wide PICNIC PICNICIT ITServices Services

Figure 6. High level RHE information system architecture (intra- and inter-enterprise environment).

quired level of functional and semantic interoperability together with other health care specific standards by e.g. CEN TC 251 and ISO TC 215.

3. PICNIC Architecture 3.1. High Level View to Architecture At a high level, the information system architecture of the RHE is presented as comprising a number of layers (Fig. 6). Users access IT based health services through a number of access devices ranging from normal PC’s to for instance Short Message Service over a GSMnetwork. A physical, wired a/ wireless, network connects the access devices to IT applications. The IT applications include both RHE and healthcare enterprise wide services. The common IT services infrastructure at the healthcare enterprise level enables the required degree of interoperability between enterprise applications, including security and access control. At the RHE, inter-enterprise, level interoperability is enabled by PICNIC IT services. At the level of a real RHE, the architecture is likely to be much more complex for several reasons. First, the care providers in a region have applications running supporting their respective operations. They also have intra-enterprise wide integration platforms of messaging and common IT services. Second, the functionality provided by the RHCN will depend on what IT services the organisations desire to provide to each other and what they “are willing to give up” in order to make this happen. The common IT services infrastructure is therefore case sensitive. It depends on the existing health information infrastructures of the healthcare organisations that make up the RHE. The same applies for regional applications. These will mostly be created “at the cost of enterprise applications”. The healthcare organisations may agree that some functions can be supported by a joint, regional application. The service focus of PICNIC is a conceptual solution to the complexities of large scale interoperability needed in RHCNs. In the regional setting healthcare organisations are expected to retain their independence and their collaboration is determined by their interests. There will also be competing interests. Consequently, there is no single owner of the RHCN. Its development will depend on how the organisations can reach consensus and/or agreements to co-operate. The ownership of the network of co-operating organisations in a region will range from total “anarchy” (all are equal) to a regional authority kind of “big brother”.

46


Table 1. Stakeholders have different views to the architecture because their interests (concerns) are different.

Views

Stakeholder group

Why use it, what are the benefits What does it do, what services does it offer, can I trust it (incl. security) How does it do it, what components & interfaces does it use How does one implement it, what technologies does it use

Vendors, healthcare organisations, RHE’s Users

Developers Implementers (vendor and user side)

Due to this, there is a continuous tension between regional and enterprise needs, i.e., how far federation is extended (or in other words, what is desired or tolerated). The regional inter-organisational environment continues to be distributed and heterogeneous. Consequently also, different technology (execution) platforms will have to co-exist and have to be bridged by gateway solutions to enable interoperability of applications (information systems) running on different execution platforms. The federative nature of the enterprises that collaborate in a RHE requires that the PICNIC IT Services (the RHCN) can be created incrementally. The vendors need to be able to offer new IT services and the users need to be able to decide autonomously what IT services they subscribe. Enterprise applications of the healthcare organisations must be able to use the IT services with minimum interfacing. 3.2. Stakeholder Views to Architecture To ensure that the concerns of the stakeholders in the development of the PICNIC architecture are properly included viewpoints and views have been used. There are several frameworks that can be used to illustrate the views of the various stakeholder groups [1,2]. In the PICNIC context, the stakeholders and their concerns relating to the PICNIC architecture are (see also Table 1): −

− − −

At the strategic level two groups of stakeholders are identified that decide what architectures to base their respective environments on; on one hand the users, the RHE and its constituents the healthcare organisations and on the other hand, the vendors. For both groups the question is “why should I use the PICNIC architecture”. What benefits does it offer to them in implementing their respective strategies. The actual users of IT applications are concerned with what services are available and whether the services function satisfactorily. The developers of IT applications are concerned with what software components it uses and how these can be interfaced into an interoperable IT service environment for the RHE. The implementers are concerned with how to implement these features, services and interfaces in the real world.

In the PICNIC project the stakeholder groups were represented through the National Health Advisory Board, NHAB, which held the strategic view. The participating PICNIC regions represented the users of the RHCN. The PICNIC project team represented the developers of the RHCN. Those that implemented the regional pilots represented the implementers’ interests. In the following, the PICNIC architecture is introduced through these views starting from the service view of what functions are provided and proceeding through the various implementation stages ending with the strategy view providing the arguments for making use of the PICNIC IT Services and architecture.


47

Table 2. Reclassification of the WISE services into services and applications and after that into specific PICNIC IT Services (* =application making use of a resource service).

WISE service Clinical messaging Clinical E-mail Clinical Booking Shared Records Care Protocols* Mobile & Emergency Home Care Monitoring Telemedicine Surveillance Information Yellow Pages* Professional Guidelines* Disease) Quality Management & Research Networks Public Health Information* Continuing Professional Development* Reimbursement Electronic Commerce Patient ID (Person ID) Resource Management*

Classification Service Application Application Service Application + Service Application Application Application + Service Application Application + Service Application + Service Application

Name of PICNIC IT Service Clinical Messaging Service

Access to Patient Data Service Resource Service

Collaboration Service Resource Service Resource Service

Application + Service Application + Service

Resource Service Resource Service

Application Application Service Application + Service

Person Identification Service Resource Service

4. Service View (PICNIC IT Services) The service view describes the IT architecture from the perspective of its users; the healthcare service providers, health professionals, patients and citizens. The IT services include not only those supporting the management and delivery of care by healthcare professionals but also IT services directly accessed and used by patients and citizens. From the RHE perspective, the new IT services support the collaboration of the healthcare organisations in delivering healthcare services to citizens and patients. One of the starting points of PICNIC was the work done in a previous EU supported project named WISE [3]. It produced a list of 18 IT services that were claimed to be needed in a regional collaboration setting. In the analysis phase of PICNIC these 18 services were investigated based on the user requirements derived through the UML methodology. The analysis revealed ambiguities, overlaps and interdependencies between the 18 WISE services. The analysis also showed that additional IT services are required for the next generation RHCN to support collaboration (for a complete description see chapter “PICNIC technology”). The result of the analysis is summarised in Table 2. The PICNIC architecture is based on a middleware layer providing common PICNIC IT Services for the healthcare organisations forming the RHE. This leaves a wide choice on what the modules will be, i.e. how the desired functionality is created. The partitioning of the required functionality is a subjective process based on preferences and availability of products and on the existing infrastructure and the plans to migrate it. The PICNIC IT Services emerging from the WISE analysis and the user requirements analysis of WP 3 are the following: − −

Clinical Messaging Service to transfer structured data between applications Access to Patient Data Service to access patient data stored in separate databases (patient record systems)

48


− − −

Collaboration Service to enable real-time and store and forward collaboration and consultation Person Identification Service to identify patient records and record fragments Resource Service, a generic service needed for identifying available resources and the means for accessing them. Examples of resources include pharmacies on-duty, hospitals and clinics, clinical information systems available at a regional level, methods and technologies available for accessing primary information, and protocols for exchanging information with them. A resource service may also provide information about equipment / devices available at certain facilities, as well as used by certain categories of people, together with the corresponding equipment/ device characteristics.

Additionally in the PICNIC RHCN some IT Services are needed that were not included in the list of WISE services: − −

−

−

−

Auditing Service for recording all performed interactions between middleware services and/ or end-user applications, directly or indirectly. The logs produced are used for both tracing back transactions in time and for charging. Authentication Service to allow access to desired services only for authorised endusers. They are implemented by means of security services that manage the user rights and roles, together with associations to personalised profiles. Its purpose is to certify the role and authority of both users and services (or applications) within the regional healthcare network. Encryption Service for the secure communication of sensitive personal information over and across any healthcare domain related Virtual Private Network (VPN), as well as the Internet. The combination of digital signatures for authentication, public key cryptography for recipient authentication, and Secure Socket Layer (SSL) protocols for secure data-transfer, provide the necessary technological framework for secure communication of healthcare related information across the Internet. Terminology Service may be used in many alternative ways: (1) to aid in the process of entering coded data (information acquisition); (2) to translate coded data elements into human or machine-readable external forms (information display); (3) to transform messages or data records from one form or representation into another (mediation); (4) to inquire about associations which may or may not pertain between various data elements and to assist in the location of various data record sets, which may contain information relevant to the specific topic or entity (indexing and inference); (5) to determine the structure and meaning of a terminology system (browsing), and (6) to aid in the entry, validation, translation, and simplification of composite concepts (composite concept manipulation). User Profile Service tracks the long-term interests of users and are used for maintaining personalised settings and preferences. User profiles are made up of terms/ keywords to describe interesting information, or examples of interesting information, and are utilised for the selective dissemination of information to their owners. User profiles initially are created according to existing stereotypes that are automatically assigned to them, after gathering some initial user-specific information and users may actively contribute to the incremental building of their profiles.

5. Software Engineering View (Software Components) As software systems grow larger, software component technology has emerged as a key enabling technology in managing and building complex systems. The overall goal of the


49

PICNIC architecture is to provide interoperability, scalability, extensibility, security among the IT services and components (both within a healthcare enterprise as well as across healthcare enterprises), and above all to meet the needs of the users and the healthcare organisations. The unified software development process is the adopted methodology used throughout PICNIC [4]. It describes how to elicit, organise, and document required functionality and constraints; track and document tradeoffs and decisions; and easily capture and communicate the healthcare domain requirements. Use case and scenarios have proven to be an excellent way to capture functional requirements and to ensure that these drive the design, implementation and testing of software, making it more likely that the final system fulfils the end user needs. The Unified Modelling Language (UML) was used in order to specify, visualise, and document models of software systems, including their structure and design, in a way that meets all available requirements. UML is the tool used to transform system capabilities into requirements, and use cases including both basic and alternative flows of events in the form of interaction diagrams. In specifying components, adequate care was taken so that their internal semantics are neutral, in the sense that each component ought to be able to be configured differently under the different execution environments it is expected to operate in. In the previous section the PICNIC IT Services were identified and listed. The ITresponse on how these should be realised is described in chapter “PICNIC technology”. A short description, for each of the software components resulting from this exercise, is given in Table 3. Apart from the PICNIC specific middle layer components described above, a number of platform services that provide basic functionality are needed (see chapter “PICNIC Technology”). Figure 7 illustrates how the components are assembled to produce the PICNIC IT Services. As computers and networks become faster and cheaper and interconnection standards evolve new technologies constantly appear for new application niches. The Internet is imposing new integration challenges as it extends into every corner of every organisation. The software engineering view acts as the unifying framework that provides structure and semantics and realises the components potential as more of them become available. Eventually it is expected that the creation of application models that will be in a position to automatically be translated into software (capable of running in the target deployment environment) will eliminate much of the effort currently required for software development. This approach will offer an architecture always ready to deal with yesterday’s, today’s and tomorrow’s execution environment. It will also make application and IT services integration across middleware boundaries easier; while at the same time it is expected to provide much wider cross-platform interoperability among different platform services. The Model Driven Architecture (MDA) that OMG adopted in 2001 focuses exactly on this. With component-based software, the significance of deciding whether it is better to buy an integrated suite from a single vendor or choose individual best-of-breed applications from several vendors is reduced because standardised component interfaces facilitate the combinations of components from different vendors. The web services architecture extends component-based software by allowing some of the components to be operated as IT services that can be discovered through publicly available directories, and provides the means for accessing components spanning the entire Internet.

50


Table 3. PICNIC Components.

PICNIC Component

Description

Clinical Observation Access Service Component (COAS) Collaboration Service Component (COLS) Message Broker Component (MEBR)

Clinical observation access service components are required for obtaining clinically significant information, captured at the point of care, directly from the corresponding clinical information systems. This service requires the implementation of standardized gateways for each clinical information system to enable for secure access to patient record data. Collaboration service components are required to establish a collaboration context that enables not only the active sharing of clinically significant information, but also receiving feedback, feed through and awareness information from all participating actors. Message broker components provide message validation, transformation and routing using a set of built-in and/ or user-defined message formats and message processing rules, which may include functionality such as publish and subscribe, message auditing, message flow analysis, and message enrichment. Patient identification service components allow for the unique association of distributed patient record segments to a master patient index.

Patient Identification Service Component (PIDS) Resource Service Component (RESS)

Shared Records Indexing Service Component (SRIS) Shared Records Update Broker Component (SRUB) Terminology Service Component (TERS)

User Profile Service Component (UPS)

Resource service components are useful for identifying available resources and the means for accessing them. Examples of resources include pharmacies on-duty, hospitals and clinics, clinical information systems available at a regional level, methods and technologies available for accessing primary information, and protocols for exchanging information with them. A resource service component may also provide information about equipment/ devices available at certain facilities, as well as used by certain categories of people, together with the corresponding equipment/ device characteristics. Shared records indexing service components are required to provide the means for locating clinically significant information dispersed throughout any health information network. Shared records update broker components are required in order to provide prompt and consistent propagation of indexing information to the Shared Records Indexing Server. Terminology service components may be used to: − aid the process of entering coded data (information acquisition); − translate coded data elements into human or machine-readable external forms (information display); − transform messages or data records from one form or representation into another (mediation); − inquire about associations which may or may not pertain between various data elements and to assist in the location of various data record sets, which may contain information relevant to the specific topic or entity (indexing and inference); − determine the structure and meaning of a terminology system (browsing); − aid in the entry, validation, translation, and simplification of composite concepts (composite concept manipulation). User Profile service components track the long-term interests of users and are used for maintaining personalised settings and preferences. User profiles are made up of terms/ keywords to describe interesting information, or examples of interesting information, and are utilised for the selective dissemination of information to their owners. User profiles initially are created according to existing stereotypes that are automatically assigned to them, after gathering some initial user-specific information and users may actively contribute to the incremental building of their profiles.


51

Figure 7. PICNIC IT Services and the components from which they are composed.

6. Data View (Semantic Interoperability) The data view is concerned with the semantic interoperability of the PICNIC IT Services and the enterprise applications. The view focuses on the federation of the information domains of the PICNIC IT Services and the enterprise applications respectively in order to share data and the concepts and vocabularies underneath them. Today there are a number of internationally (partly) competing standards relating to message content. Some of these are tied to a certain technology, i.e. do not allow the separation of content from technology. The earliest of these standards is Edifact, which is being used extensively also for healthcare messaging. HL7 V2.x is another example of a widely used message standard that does not separate content from the envelope. There are several Edifact standard messages that have been defined by CEN TC251. Since the mid-90s CEN TC 251 gradually developed and refined an UML-based domain information model methodology that also heavily influenced Health Level Seven’s V3 methodology. True separation is now the accepted norm and work is proceeding on those lines first to set up international standards for content and then to specify implementations with various technologies. HL7’s V3 with its generic Reference Information Model, RIM, is the current goal that is being pursued not only by US but also by several HL7 affiliates across the globe representing both local industries and users. As in all volunteer standards work, the outcome is defined by those who participate. And, a standard is only used if there are benefits in using it. PICNIC decided to use the Clinical Document Architecture standard, CDA, Release One (R1), which has been developed by Health Level Seven [5]. CDA R1 has also been approved as an ANSI standard. In CDA, XML is used to describe the structure of clinical documents. CDA is intended as a framework (architecture) for describing the structure of clinical documents. It focuses on the structuring of clinical documents. Future extensions (R2 and R3) will provide more guidance / requirements for the structure of clinical documents. The standard is based on the notion that “all medical information” is stored and read as documents. CDA seeks to bring structure to these documents in order to make them interoperable. The main difference between R1 and R2 is that in the former only the header is composed using the RIM whereas on R2 also the body part has to comply with RIM. A CDA document is not a message. Messages can be used to exchange CDA documents in which case the CDA document is the payload and the message provides the wrapper. The wrapper can be anything (e.g. HL7 v2.x or Edifact). The message must have an address / recipient. The header the CDA document is meant for the identification of the document not to be used for addressing the document to a receiver.

52


CDA R1 was for a number of reasons: (1) CDA R1 is only concerned with the structure, not the contents with the exception of the header for which there are mandatory requirements; (2) Having a header complying with CDA “does not hurt anyone” as everyone has to provide information about the contents of any clinical document. Hence everyone will have to provide a header; (3) CDA allows documents to be exchanged with XML, which everyone needs. XML implementations are the goal for all concerned and finally (4) CDA offers a migration path towards full RIM compliance once V3 is available. GMS uses CDA in Pharmacy Reimbursement Messaging. FUNEN uses CDA in Collaboration Messaging and FORTH in Clinical Messages for Teleconsultation. 7. Security View The security view of the system refers to two main issues: Security (resilience) of the hardware, operating system and the application software and control of the use of information (patient data). The main focus in PICNIC is the latter especially as we deal with private and confidential patient information. The former, while being equally important, is a more generic issue that will be solved in the selection of the software platform and the tools used to create the execution environment and the applications. 7.1. Security Management in PICNIC Security management is a particular instance of the general information system management functions. Information system security management services are concerned with the installation, maintenance, and enforcement of information domain and information system security policy rules in the information system intended to provide these security services. In addition to these core services, security management requires event handling, auditing, and recovery. Standardisation of security management functions, data structures, and protocols will enable interoperation of security management application processes across many platforms in support of distributed security management. The mechanisms implemented in the system hardware and software concentrate in the execution environments. Most of the implementation of security protection is expected to occur in software. The hardware is expected to protect the integrity of the software. Hardware security mechanisms include protection against tampering, undesired emanations, and cryptography. Implementing the necessary security protection in the execution environments occurs in operating system services, network services, and system management services. The operating system isolates multiple security contexts from each other using hardware protection features (e.g., processor state register, memory mapping registers) to create separate address spaces for each of them. Untrusted software will use end system resources only by invoking security-critical functions through the separation kernel. Most of the security-critical functions are the low-level functions of traditional operating systems. The concept of an information domain provides the basis for security protection. An information domain is defined as a set of users, their information objects, and a security policy. An information domain security policy is the statement of the criteria for membership in the information domain and the required protection of the information objects. Security policy implements regional a/o local requirements and needs. It must be based on national legislation on the protection of personal data when collected, processed and/or transferred and on the laws regulating the practice of medicine and delivery of healthcare services by healthcare professionals. The basic elements in implementing security for information domains that need to communicate with each other are outlined in Fig. 8. Security within each information domain must be established in accordance with the respective security policy. For communi-

N. Saranummi / PICNIC Architecture Trusted End-to-End (E2E) Communication (ISO TR)

Security policy Security measures

Information Information Domain Domain 22

Information Information Domain Domain 11

53

Information Information Domain Domain 33 Information Information Domain Domain nn

Figure 8. Bridging information domains securely.

1st stage

2nd stage

Border security

Authentication

Network layer security

Proof of identity

• Virus scanning • Firewalls • Intrusion detection • Virtual private networking • Denial-of-service protection

• Username / password • Password synchronisation • Public key • Tokens • Biometrics • Single sign-on

3rd stage

Authorisation Permission based on identity • User / group permissions • Enterprise directories • Enterprise user administration • Rules based access control

Figure 9. A layered defence [8].

cation between the information domains a trusted end-to-end communication policy is required. The European data protection directive is currently being implemented into the national legislation of the EU Member States. This means that every EU Member State must have the same level of legal protection of personal data. The same does not apply to healthcare and medicine. There each country still has its own mandate. Consequently, security policies and their implementations in the RHCN’s will be different. However, although they are different, there are several commonalties between the regions and in the technologies deployed. Each will have to address: data protection (including audit trails), data confidentiality (including encryption), authentication of users and authorisation (including assigned roles regulating access rights to e.g. patient data). Additionally, security policies must deal with the informed consent of patients (customers), which is required for legal access to patient data. Consent may also have qualifiers e.g. restricting access to only part of the patient data or restricting the period of time that the consent is given. Finally, the choice of what security features to implement must be based on risk assessment in the context of the intended service. Due to the particular nature of healthcare and the private and confidential information that is produces, stores and processes a number of projects have been carried out over the years on these issues, e.g. RESHEN [6]. 7.2. Security Within Information Domains The general stages for implementing security are shown in Fig. 9. In the following the main elements will be briefly described.

54


Access & User Identification In order to access system resources and patient data users must be identified. I.e. access to resources and data must be controlled so that unauthorised access is prevented. Access rights can be managed on two levels: Authentication that the person is who (s)he claims to be and authorisation permitting access to resources and data based on a qualified role, rolebased access. A concept often associated with access is single-sign-on (SSO). This means that a person that logs into a system and (s)he is authenticated and authorised in a role gets access to all resources and data that that role entitles. In a healthcare context users often have to use several information systems. In such cases SSO is useful as it allows access to all information systems that the user is authorised to use in that role with only one log-in. SSO can be implemented e.g. using the CCOW standard produced by Health Level Seven [7]. Consent (by patient) Information may not be not made available or disclosed to unauthorised individuals, entities or processes without the consent of the patient. This is the fundamental right of individuals that they shall have the power to keep information about themselves from being disclosed to anyone. Therefore, the individual (patient) must agree / consent to disclosing her/his private information. In healthcare, consent refers to a communication process between the caregiver and the patient, and may refer to consent for treatment, special procedures, release of information, and advanced directives (which give instructions regarding the patient’s wishes in special medical situations. There a several kinds of consent: − − −

Expressed consent: Oral or written agreement. Because it is difficult to prove that oral consent was given, most expressed consent is expected to be recorded with a signature. Implied consent: An action other than an expressed consent on the part of a patient that demonstrates consent. For example, the presentation of a person to a caregiver implies to a certain extent consent to at least basic consent. Informed consent: In some countries / some healthcare organisations for a consent to be valid, the patient must be informed, which is “a freely given consent that follows a careful explanation by a caregiver to a patient or patient’s representative of the proposed diagnostic or therapeutic procedure or course of treatment...the patient should be given the opportunity to ask questions, to indicate comprehension of the information provided, and to grant permission freely and without any coercion for performance of a procedure or course of treatment, as well as the opportunity to withhold or revoke such permission at any time without prejudice”. Informed consent to release of information should include the elements of disclosure, voluntariness, comprehension, and competence to consent.

Figure 10 gives an example on how role-based access and consent management can be implemented. Audit trail Audit trails refer to data collected and potentially used to facilitate a security audit. It comprises of a chronological set of records that provides evidence of system activity. These records can be used to reconstruct, review, and examine transactions from inception to output of final results. The records can also be used to track system usage and detect and identify intruders. Audit trails are needed to ensure accountability of actions of individual persons or entities, such as obtaining informed consent or breaching confidentiality.


55

All pt data Pt data that the health professional is permitted to access based on his/her role (role-based access)

The combination of the role with the consent can be viewed as a filter (or a mask) that is applied to pt data when there is need to access it.

Pt data that the health professional can access when his/her role is combined with the consent of the patient

For this filter / mask to be usable there needs to be a mapping from (the different types) of consents and user roles to pt data structures (which implies that pt data must have some structure)

Pt data that the patient is permitting the health professional to access based his/her consent

Health Health Professional Professional User User

* The reason for managing access to pt data through these mechanisms originates from Finnish laws regulating privacy of data and the running of social and health services.

Access Access Control Control Service Service

Application Application

Shared SharedRecords Records Service Service

Access Control Service: Access Access • Based on smart cards with unique identifiers Control Control • Health professionals are authenticated and Service Service thereby given a “role” with corresponding “access rights” • Patient / Clients are authenticated in the same way and grant access to their pt data Patient //Customer Customer by digital signature (“consent management”) PatientUser User resulting in a “mask” to her/his data

Figure 10. Principles in implementing security and privacy policies with patient consent.

7.3. Trusted E2E Communication ISO TC 215 has produced a Technical Report on “trusted end-to-end information flows” [9]. The idea in this approach is that it is the responsibility of the information domains to negotiate under what terms they are able and willing to exchange information. Each information domain has its own security policy stating how e.g. what conditions must be met to access or store / modify patient data. The requesting information domain has to provide information about its security measures to the replying information domain. This may include information about how the user that has originated the request has been authenticated & authorised and that an explicit consent has been given by the patient for this request to access her/his data. It is the responsibility of the replying side to examine these certificates and ascertain their authenticity and based on these decide whether to provide the requested service or deny it. Both sides will additionally have to create audit trails of the transaction independent of whether the service was delivered or not. 7.4. Security Technologies Public Key Infrastructure (PKI) is used to describe the processes, policies, and standards that govern the issuance, maintenance, and revocation of the certificates, public, and private keys that the encryption and signing operations require. PKI is used in order to enable two entities that do not know each other to exchange information using an insecure network such as the Internet. The infrastructure is based upon asymmetric cryptography and each entity (user, information system, etc.) is provided with a pair of keys (a private and public key). Smart cards are mostly associated with PKI and CA’s as an access card containing encoded information and sometimes a microprocessor and a user interface. The security infrastructure comprises the following services:

56


– – –

– –

Certification Authorities (CAs) that control and manage the PKI, publish public key certificates, and impose policies in their domain of authority. Registration Authorities (RAs) that act on behalf of the Certification Authorities (CAs) in order to declare registered in the domain of authority the CA manages. Certificates Management Systems (CMS) for management of certificates during their entire duration of validity. The Certification Authority controls and uses the Certificates Management System (CMS). X.500 directories that store public key certificates as well as public information for the holders of certificates and are used for the verification of digital certificates. The certificate of the users, which is published by the CA, is stored together with the user’s private key, in a microprocessor card.

Digital signature is a means to guarantee the authenticity of a set of input data the same way a written signature verifies the authenticity of a paper document. Digital signatures are required in many cases during the provision health services to a citizen. It comprises a cryptographic transformation of data that allows a recipient of the data to prove the source and integrity of the data and protect against forgery. To sign a document, the document and private key are input to a cryptographic process, which outputs a bit string (the signature). To verify a signature, the signature, document, and user’s public key are input to a cryptographic process, which returns an indication of success for failure. Any modification to the document after it is signed will cause the signature verification to fail (integrity). If the signature was computed using a private key other than the one corresponding to the public key used for verification, the verification will fail (authentication). The digital signing of XML based clinical documents is a special instance where the nature of the clinical workflow may require that each participant only signs that portion of the document for which they are responsible. The joint standards effort between W3C and IETF includes a standard for XML Signature.

8. PICNIC Standards View An in-depth search and evaluation of different possibilities on which to base the PICNIC architecture (the inter-enterprise integration architecture) resulted with the conclusion that web services has the potential to become a widely accepted main stream set of standards for communication and interoperability between peers. This approach has the potential of providing a plug-and-play compatibility extending all the way to the implementation level. This approach enables also a technology neutral implementation of the internal structures of the PICNIC IT Services with interfaces based on widely accepted (although still partly unfinished) standards that W3C and IETF are working on. The communication stack (Fig. 11) allows the IT services to discover other peers and to find out what services these offer. The requests for services are handled using the SOAP protocol and transported to the servicing peer by e.g. HTTP. The network protocol supporting these exchanges is TCP/IP. Web services (and peer-to-peer communication) are a major convergence point for a number of issues today. There is potential for Open Source in a technology neutral environment. Major vendors including Microsoft are embracing the W3C & IETF efforts. The specification of SOAP is in the hands of W3C. The major binding concept is XML, which enjoys a huge acceptance by all vendors. There are also some disadvantages with this choice. The most important disadvantage in selecting web services is that although the main standards are well underway and seem to be maturing and stabilising there are still several additional standards that are needed and are not yet “out of the box”. These include the ways to handle security, identification and


Service Service provider provider Publish

Service Service registry registry

Bind

Find

Service Service requestor requestor

57

stack

standards

purpose

Discovery Discovery

UDDI

Locating services

Description Description

RDF, WSDL

Describing services

Packaging Packaging

XML, SOAP

Requesting / performing services

Transport Transport

HTTP, Jabber

Transporting requests

TCP/IP

Network

Network Network

Figure 11. Web services – The basic protocol stack, standards and their purpose for peer to peer communication.

authorisation (including directory services) in a web services environment2. These are important issues in the healthcare domain. Connections must be secure and confidential patient data must be protected from access by unauthorised users. The web service approach means that interoperability between the PICNIC IT Services and their user applications can be achieved in a technology neutral way. Vendors can build their IT services in any implementation environment of their choosing as long as they use the web services stack and principles for their interfaces (functional interoperability). Semantic interoperability, of course, requires that the PICNIC IT Services and the enterprise applications using them have a federated data model. The concepts of web services and peer-to-peer communication fit well into the PICNIC approach of regional IT services for the RHE. They are built on the same principle as the RHE, i.e. that the components making up the system interoperate on an equal basis (peerto-peer).

9. Strategy View (Why Use PICNIC?) 9.1. PICNIC Architecture Based on the above the principles of the PICNIC architecture is defined as: – –

–

The interfaces to the PICNIC IT Services are based on the W3C & IETF standards. The PICNIC IT Services can be implemented in any technology platform (e.g. ORB/IIOP, Java J2EE or .Net) as long as they can be accessed through W3C & IETF compatible interfaces. The enterprise applications of the healthcare organisations can be implemented in any technology platform as long as they are able to access the PICNIC IT Services through W3C & IETF compatible interfaces.

The final PICNIC architecture of the next generation RHCN is thus based on a RHE wide middleware layer providing messaging and common IT services (Fig. 12). This middleware layer comprises the PICNIC IT Services. The EA’s can interface to PICNIC IT Services using web services. In case they are not directly equipped with such functionality a “Gateway” can be used that translate the EA requests to SOAP / XML and similarly translate the PICNIC replies back to the protocols that the EA can use.

2

Need to update, e.g. choreography work and WS-I.

58

N. Saranummi / PICNIC Architecture Collaboration (consultation, telemedicine)

Integrating patient data (i-EHR)

PICNIC services

Enterprise Application

SRS SRS

Patient validation

Messaging

COLS COLS

CDA CDA

PIDS PIDS

...

interfaces based on World Wide Web Consortium standards

EA

... EA

EA

... EA

...

... ... EA EA

Figure 12. PICNIC architecture for implementing PICNIC IT Services in a Regional Health Economy.

9.2. Why Use It The strategy view comprises the goals and plans that guide and instruct healthcare organisations operating in the RHE, in their deployment of ICT to support and enable their collaboration. These goals are partly determined by national health policies and strategies within which the RHE’s operate. Similarly, the vendors and IT service providers are concerned how the PICNIC architecture fits into their product strategy and business goals (see Fig. 5). For these two stakeholder groups, the questions about the PICNIC architecture are the same; “should I use it, why should I use it, what are the benefits and what are the risks?” PICNIC has made a conscious effort to include the interests of the strategic stakeholder groups. These include care delivery (doctor, nurses, and specialists), subject of care (patient, family of patient, citizen), managers (regional policymakers, project manager), designers (consultant, architect, researcher, technician) and politicians (regional and national, financier, insurance). The resulting PICNIC IT Services and the architecture is a result of that process. Instead of being technology driven the project has derived its results by first analysing the user needs and then proceeding to the specification of software components and development of IT services. For RHE’s and healthcare organisations, the arguments for making use of the PICNIC architecture are that: − − − − − −

PICNIC reduces complexity. The decisions that healthcare organisations have to take to deploy PICNIC results can be made by them at their own will and at the time that best suites them. PICNIC IT Services provide new functionality for healthcare organisations to deliver citizen centred shared care in a RHE. RHE’s can also offer existing and new services to their other network partners using the media of the RHCN. The PICNIC architecture is a validated blueprint for region-wide IT services in a RHE. Validation has been carried out in the regional pilots that have been formally evaluated. The architecture enables competition between vendors by broadening the geographic scope of the potential bidders. Regions can start to take advantage of PICNIC architecture and the PICNIC IT services with minimal migration. Standard service interfaces simplify the usage of the IT services.


−

59

The architecture meets national health IT policy needs enabling healthcare organisations to collaborate and share data in a region. RHE’s can be joined with the same architecture to build a nation-wide IT service infrastructure.

For industry, the main arguments for using the PICNIC architecture are that: –

–

– – – – – – – – –

The PICNIC architecture is a validated blueprint for region-wide IT services in a RHE. Validation has been carried out in the regional pilots that have been formally evaluated. The architecture is based on a cohesive set of main stream web services standards for functional interoperability and HL7 CDA R1 standard for semantic interoperability. Standard service interfaces are an important feature of the PICNIC architecture and simplify the usage of the IT services. The PICNIC IT Services can be added to an existing RHCN autonomously one by one. The IT services can be implemented on a technology platform of the vendor’s choosing. Using PICNIC standards increases the market scope in Europe. The PICNIC Components are certified, which increases customer confidence. PICNIC itself involves numerous regions and vendors. PICNIC disseminates its results to regions in Europe and to vendors. The PICNIC Components are available to anyone in Open Source and can be enhanced by anyone. PICNIC project has initiated a community for continuing evolution of the RHCN; to reach a critical mass of users and developers. PICNIC is starting an Open Source development community of interest to collectively own the result.

PICNIC delivers an open scalable RHCN comprising a defined set if PICNIC IT services with web services based interfaces for the delivery of health services in a Regional Health Economy. The IT services are built using Open Source components. The results have been evaluated by real life regional pilots. 10. Conclusions The goal of PICNIC was to deliver a blueprint for healthcare organisations to provide IT services to RHE network partners. PICNIC has met its aims by − −

− −

Delivering a number of Open Source components, which can be integrated into PICNIC IT Services to provide new functionality of the RHCN; Designing an open scalable architecture based on main stream technologies and standards for future Regional Healthcare Networks (RHCN) to make the PICNIC IT Services interoperable with the enterprise applications of the healthcare organisations participating into a RHE; Demonstrating that the IT services can be implemented by regional healthcare providers into a next generation user-friendly RHCN by pilot projects that have been evaluated by proactive assessment methods; Providing results that can be exploited by RHE’s, vendors and IT service providers throughout Europe and potentially world-wide thus decreasing the fragmentation of the European market for telematic healthcare services and products.

PICNIC dealt with regional healthcare networks. The implicit assumption was that the RHCN’s would be operating within country borders. However, the solutions provided by

60


the PICNIC project do not necessitate this restriction. The PICNIC IT Services can be accessed by anyone. Similarly the security measures with regard to access to confidential patient data can be implemented across country borders. Parallel to PICNIC’s work to develop and pilot the Access to Patient Data IT Service ISO TC 215 has been considering starting a Work Item on this topic. The term they are using for this is “Link Directory”. Essentially it is the same concept where the “links” refer to the physical location of the data. The ISO work only seeks to define a common way to describe links not to how these should be implemented. The Link Directory is closely connected to web services and Object Identifiers (OID’s). PICNIC’s choice to used Health Level Seven’s CDA standard to describe semantic content fits well into these trends. Ultimately CDA documents can be identified by their unique OID’s thus making them accessible through the Link Directory Service. The pilot implemented in Crete and SEBT does not use OID’s but could easily be modified to make use of these once these are widely available. References [1] The Open Group Architectural Framework, version 6 (TOGAF): www.opengroup.org. [2] ANSI/IEEE 1471: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. www.pithecanthropus.com/~awg/. [3] Building Regional Healthcare Networks in Europe, J. Oates and H. Bjerregaard Jensen (editors), IOS Press, 2000. [4] Unified Modeling Language, Version 1.4, OMG Document 01-09-67. www.omg.org/cgi-bin/doc? formal/01-09-67). [5] Reference to HL7 CDA. [6] Regional Secure Health Networks, RESHEN www.biomed.ntua.gr/reshen/. [7] Clinical Context Object Workgroup (CCOW), www.hl7.org/Special/committees/visual/visual.cfm. [8] McConnell & Hamilton: Information assurance in the 21st century. Supplement to IEEE Computer, Security and Privacy, 2002. [9] ISO TC 215 Technical Report: Trusted end-to-end information flows.


61

PICNIC Technology Dimitrios G. KATEHAKIS a, Morten BRUUN-RASMUSSEN b, Vesa PAKARINEN c, David PIGGOTT d and Niilo SARANUMMI e a FORTH, Institute of Computer Science, ([email protected]), Greece b MEDIQ ([email protected]), Denmark c VTT Information Technology ([email protected]), Finland d Integrity Consulting Partners/ GMS(P)B ([email protected]), U.K./ Ireland e VTT Information Technology ([email protected]), Finland Abstract. A key objective of the Professionals and Citizen Network for Integrated Care (PICNIC) project was to provide products for a European and potentially worldwide software market. The approach followed was through the delivery of a number of Open Source (OS) components, to be integrated into applications that deliver similar services across the participating regions, aiming at their exploitation by other regions and the industry. This chapter describes the technology developed during the lifecycle of the PICNIC project, focusing on the three core services of Clinical Messaging, Access to Patient Data, and Collaboration. For each service, the entire process of how to turn its functional specifications into reusable components and common data sets in order to support Information Technology (IT) services for the next generation of secure, user-friendly healthcare networks is presented by means of common documentation tools. Security and privacy issues are also addressed.

1. Introduction Health telematics applications are presently revolutionising the developments not only in diagnosis, treatment, surveillance and rehabilitation of patients, but also on the side of the more collective aspects of healthcare and disease prevention such as clinical trials, epidemiology and health education. Moreover, for the first time in the history of healthcare the emerging Health Information Infrastructure (HII), i.e. telematics networks together with a set of technologies, health telematics applications and services, is making possible the rapid dissemination and sharing of health information and research results. This is leading to knowledge creation and to promotion of innovative approaches based on evidence collected in medical practice all over the world. As it has already been presented in the “PICNIC Story” chapter, the project started with the aim of taking the concept of the 18 Work In Synergy for Europe (WISE) project [1] services required by a Regional Health Care Network (RHCN), in order to deliver a full range of IT services to any “member” healthcare organisation within the RHCN. The methodology followed in order to turn the functional specifications provided by IT into reusable components across services and regions, in order to support the next generation RHCNs, is briefly described in Section 2 (From Functional Specifications to Common Components). More specifically, the process followed for the three services of top priority to the regions (i.e. Clinical Messaging, Access to Patient Data, and Collaboration) is presented in Section 3 (Core IT Services). Section 4 (Software Components) discusses performance and conformance issues related to the components identified and specified to be developed

62

D.G. Katehakis et al. / PICNIC Technology

within PICNIC, while Section 5 (Security and Privacy) addresses issues related to security and confidentiality. Finally Section 6 (Conclusions) concludes on the PICNIC technology. 2. From Functional Specifications to Common Components The kind of common tools and methods needed in PICNIC have been identified as being Unified Modelling Language (UML)-based [2]. During the course of the project certain elements from the Rational Unified Process (RUP) were also introduced in the organization and methodological process followed. The RUP activities create and maintain models, and rather than focusing on the production of large amount of paper documents, it emphasizes the development and maintenance of models (i.e. semantically rich representations of the software system under development) [3,4]. The RUP supports an iterative approach to development that addresses the highest risk items at every stage in the lifecycle, significantly reducing a project’s risk profile. This iterative approach helps attack risk through frequent, demonstrable, executable releases that enable progress (i.e. frequent, executable releases that enable continuous end user involvement and feedback). Because iterations end with an executable release, the development team stays focused on producing results, and frequent status checks help ensure that the project stays on schedule. An iterative approach also makes it easier to accommodate tactical changes in requirements, features or schedule. The RUP describes how to elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions; and easily capture and communicate business requirements. The notions of use cases and scenarios prescribed by the RUP process have proven to be an excellent way to capture functional requirements and to ensure that these drive the design, implementation and testing of software, making it more likely that the final system fulfils the end user needs [5]. In addition, the RUP supports component-based software development. Components are non-trivial modules, subsystems that fulfil a clear function. The RUP provides a systematic approach to defining an architecture using new and existing components. These are assembled in a well-defined architecture, either ad hoc, or in a component infrastructure such as the Internet, .Net, or the Common Object Request Broker Architecture (CORBA), for which an industry of reusable components is emerging [6]. There are nine core process workflows in the RUP, which represent a partitioning of all workers and activities into logical groupings, as shown on Fig. 1. Although the names of the six core engineering workflows may evoke the sequential phases in a traditional waterfall process, the phases of an iterative process are different and these workflows are revisited again and again throughout the lifecycle. The actual complete workflow of a project interleaves the nine core workflows, and repeats them with varying emphasis and intensity. At the initial phase of a project, such as PICNIC, most of the effort is directed towards Requirements, Analysis and Design. The goal is to describe what the system should do and allow the developers and the end users to agree on that description. To achieve this task PICNIC elicited, organized, and documented required functionality and constraints [8]; while at the same time it tracked and documented tradeoffs and decisions. Actors were identified, representing the users, and any other entity that must interact with the system being developed. Use cases were also provided, representing patterns of behaviour each of the selected IT services exhibit. Because use cases were developed according to the actors’ needs, the system was more likely to be relevant to each user. Therefore a harmonisation process had to be applied in order to bring all the related use cases in a state where commonalities, rather than peculiarities, were exposed. Each use case was described in detail.


63

Phases Process Workflows

Inception

Elaboration

Construction

Transition

Business Modelling Requirements Analysis and Design Implementation Test Deployment Supporting Workflows

Configuration Mgmt Project Management Environment Preliminary Iteration(s)

Iter. #1

Iter. #2

Iter. #n

Iter. #n+1

Iter. #n+2

Iter. #m

Iter. #m+1

Iterations

Figure 1. The nine core process workflows (sequence of activities that produces a result of observable value) are divided into six core “engineering” workflows and three core “supporting” workflows (from [7]).

The use-case descriptions showed how the IT service environment interacts step by step with the actors and what it does. The presented summary output results in a design model and optionally an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a ‘blueprint’ of how the source code is structured and written. The design model consists of design classes structured into design packages and design subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases. The final component specification documents produced [9–11] correspond to the elaboration phase, and as such they address the critical use cases identified in the inception phase, which typically expose the major technical risks of the project. While an evolutionary prototype of a production-quality component is always the goal, this does not exclude the development of one or more exploratory, throw-away prototypes to mitigate specific risks such as design/ requirements trade-offs, component feasibility study, or demonstrations to investors, customers, stakeholders and end-users. 3. Core IT Services The application layer of any reference architecture consists of applications, which support user activities in the various areas of an organization. These applications are both information sources and/ or information access points. Clinical, diagnostic, and administrative information systems, diagnostic imaging repositories, medical libraries, and user-oriented services are all part of the application layer. All applications and services of the application layer make use of their own data model and user-interface. Clearly in PICNIC all regions shared the need for integration of systems into an interoperable infrastructure. The main challenge today, in regard to the development of integrated RHCN offering advanced health telematics services, has to do with the development of the appropriate HII that will be in a position to support all the requirements of the healthcare domain. This re-

64


quires good knowledge and understanding of the domain together with the definition of the corresponding and necessary reference architecture, which defines the framework for the integration of heterogeneous, autonomous, distributed information systems that are networked. In addition to that, the definition of public and stable interfaces and protocols is also required together with the provision of the appropriate middleware and user-oriented services. PICNIC developed some of the components that are required by the underlying HII, giving them a European perspective and aiming at piloting them across several European regions. The OS approach ensures that the mechanisms are in place for creating a community of developers sharing a common interest, and creating industries around it to provide the end-users added-value services of high quality. Their development has been concentrated in three groups, corresponding to the three greatest priority areas for PICNIC regions: • Messaging concentrates on the exchange of clinical and administrative data between different applications and includes the use of a various number of already developed standards; • Access to Patient Data focuses on the development of an integrated environment for professionals or citizens who need a uniform way to access parts of patient record data that are physically located in different clinical information systems, and should not be confused with autonomous Clinical Information Systems (CISs), message based communication of Electronic Health Record (EHR) data, centralized Clinical Data Repositories (CDR), or monolithic information systems that have embedded in their structure mechanisms for accessing directly host systems; and • Collaboration is involved with the development of an environment for the provision of examination, monitoring, treatment and administration of patients through immediate access to expertise and patient information regardless of where the patient or relevant information is geographically located. 3.1. Messaging Clinical Messages was one of the first IT services developed in a RHCN and consists of highly structured patient-related information, concerning the treatment of an individual. Messaging makes the exchange of form-based information such as prescriptions, laboratory results, referrals, and discharge summaries almost automatically possible between different healthcare providers. When communicating clinical messages, a “store and forward” e-mail technique is often used providing the opportunity to communicate 24 hours/ day. Because such messaging is suitable for standardisation, national or regional standards make it possible to integrate clinical messages in IT applications, already in use by the professionals. A very common way to set up the messaging infrastructure is through a “message broker”, which is usually installed as a service in the network. The “message broker” is a middleware component, which has the capability of interpreting different messaging protocols and translating between various dialects. This technique can be of great value in preserving existing investment and facilitating the introduction of new technologies. The message broker can interact with an authentication service, which ensures validity of senders and receivers (see Fig. 2). The main actors of the Messaging IT service have been identified in PICNIC to be: • • •

the End User that can be either an Administrator, a General Practitioner, a Nurse, a Physician, a Radiologist or any Healthcare Professional; the Maintainer that represents a person who is responsible for the maintenance, expansion and enhancement of the system with new features; and the Existing IT System that represents current systems that holds the primary source of prescribing and validation information.

D.G. Katehakis et al. / PICNIC Technology Legacy application (no message capabilities)

65

WAP appliance

Wrapper agent Handheld appliance

Authentication service (X.509)

Electronic signature component

Browser appliance

Message Broker Routing component

Laboratory Information System

Encryption component

Radiology Information System

Dialect mapping component

Pharmacy

Patient Admission System

User Interaction and Presentation Information Appliances

… Fat client

Electronic Health Record

Vertical Clinical Applications

Figure 2. The message broker architecture for messaging. Table 1. Use Cases for the Messaging IT Service of PICNIC. Use Case

Short description

Add New IT System

Adds a new system to the federation of IT systems. It is initiated by the Maintainer.

Access Control Rule

Defines, sets and updates the security roles and policies of the users when the try to access clinical information. It is initiated by the Maintainer or the End User.

Keep Information Up-to-date

Accesses the internal data structures so that they are kept up-to-date. It is initiated by the Maintainer or by an Existing IT System.

Access Rights and Authentication

Relates to authentication and the use of passwords and user groups to validate users and allow them to access clinical information.

Message Set-up

It is initiated by the End User and describes how the definition of the clinical message is set up.

Maintain Messages

It is initiated by the End User and describes how an existing definition of the clinical message is maintained (amendments/ deletions)

Access Clinical Information

It is initiated by the End User and describes how clinical information for the provision of the message content is accessed.

Message Communication

It is initiated by the End User and describes how the message is communicated to the intended recipients.

Provide Secure Information Communication

Provides security through all communication paths. It is used by the Access Clinical Information use case.

Keep Auditing Trails

Audits every interaction between the various entities of the system.

Notification

A notification is send to the Maintainer of the system if a change has been made to a Clinical Messages.

Terminology Service

A service or function that assists the user to translate codes between different coding systems.

Features of the Messaging IT Service that can be translated into use cases are listed on Table 1.

66


Add New IT System

Maintain Messages

Notification

Maintainer

Existing IT System

Terminology Service

Provide Security Information

Keep Information Up-to-date Access Rights and Authentication


Patient ID

Message Set-up

Access Control Rule

End User

Message Communication


Figure 3. Main use case diagram for the Messaging IT service.

The corresponding UML diagram is depicted in Fig. 3. The main software entities that can be represented as messaging components are the following: • • • • • • • • • • • • •

Message Set Up Service Component; Claims and Payments Service Component; Clinical Observation Access Component; Patient Identification Service Component; Shared Records Indexing Service Component; Shared Records Update Broker Component; Auditing Service Component; Authentication Service Component; Message Broker Component; Encryption Service Component; Resource Service Component; Terminology Service Component; and User Profile Service Component.

Clinical Document Architecture (CDA) Release 1 Today there are a number of internationally (partly) competing standards relating to messaging content. The earliest of these standards is the United Nations’ Electronic Data Interchange (EDIFACT), which is today being used extensively also for healthcare messaging. Lately this committee has also decided to separate content from technology and does not specify EDIFACT as the only implementation technology. Since the mid-90s the Technical Committee 251 of the European Committee for Standardization (CEN-TC251) [12] gradually developed and refined an UML-based domain information model methodology that also heavily influenced the V3 methodology of Health Level Seven (HL7). Furthermore, today CEN-TC251 and HL7 work closely together in the messaging area. HL7 V2.x is another example of a widely used message standard that does not separate content from the envelope. True separation is now the accepted norm and work is proceeding on those lines first to set up international standards for content and then to specify implementations with various technologies [13]. HL7’s V3 [14] with its generic Reference Information Model is the cur-


67

rent goal that is being pursued not only by the United States but also by several HL7 affiliates across the globe (more than 20 today) representing both local industries and users. Additionally, as mentioned above CEN-TC251 is heavily involved in this as well. Naturally, there are some that fear that this will lead to a standard set by the Americans. As in all volunteer standards work, the outcome is defined by those who participate. On the other hand, a standard is only used if there are benefits in using it. Today CDA Release 1 (R1) is an American National Standards Institute (ANSI) approved standard. CDA is intended as a framework (architecture) for describing the structure of clinical documents. It focuses on the structuring of clinical documents. Future extensions (R2 and R3) will provide more guidance/ requirements for the structure of clinical documents. The standard is based on the notion that “all medical information” is stored and read as documents. CDA seeks to bring structure to these documents in order to make them interoperable. Presently, there is no point (nor possibility) to require the data contained in a RHCN to comply with RIM. Instead, and for the time being, it makes sense to require that the contents that will be exchanged in the form of messages or shared in the context of a shared teleconsultation folder complies with the requirements of CDA R1. This is because: • •

• •

CDA R1 is only concerned with the structure, not the contents with the exception of the header for which there are mandatory requirements. Having a header complying with CDA “does not hurt anyone”. Everyone has to provide info about the contents of any clinical document. Hence everyone will have to provide a header. Why not agree that this header information is structured in accordance with CDA R1? CDA allows documents to be exchanged with the Extensible Markup Language (XML). XML implementations are the goal for all concerned. Again, the same argument: why not agree to structure the header in a common way? CDA offers a migration path towards full Reference Information Model (RIM) compliance once V3 is available.

The CDA Header consists of: • • • • •

document information; encounter data; service actors (such as providers): responsible, authenticators, recipients, originators, organization, etc.; service targets (such as patients); and localization.

A CDA document is not a message. Messages can be used to exchange CDA documents in which case the CDA document is the “payload” and the message provides the wrapper. The message can be in HL7 v2.x or v3. The message contains the data on who the addressee is etc. The header info of a CDA document is meant for the identification of the document not to be used for addressing the document to a receiver. The CDA R1 Body consists of: • • • •

shared xml attributes (id, confidentialities, language); document body and sections (+ captions, non_xml body); document structures (paragraphs, lists, tables); and document entries (character data, content, links, coded, observation media, localization).

68


Table 2. CDA header elements. Element

Contains

Mandatory

id

The document identifier within a specific environment and the identifier of that environment.

Yes

set_id

An identifier that remains constant across all document revisions/versions.

Yes

version_nbr

The version of the document used.

No

document_type_cd

Code Value, Display Name corresponding to the code value, and Code System Name.

Yes

origination_dttm

The date & time the service being documented took place.

Yes

copy_dttm

The date & time a document is released from a document management system that maintains revision control over the document.

No

confidentiality_cd

Code Value, Display Name corresponding to the code value, and Code System Name.

Yes

fulfills_order

Order type & order document id to which the defined document is a response.

No

patient_encounter

Encounter data include an optional, globally-unique encounter identifier; a required encounter time stamp; and an optional encounter location, which includes a globally unique location identifier and an address.

No

authenticator

Authenticator type and signature which can be used to hold a code which shows that an electronic signature is held on file, or is required to be provided for this document.

No

legal_authenticator

Legal authenticator type and signature which can be used to hold a code which shows that an electronic signature is held on file, or is required to be provided for this document.

No

originating_organization

A number of child elements, including originating organization type, name and id.

Yes

provider

Provider type (i.e assistant performer, consultant, or performer) and function (e.g. admitting physician).

Yes

service actor

Service actor type.

No

patient

A number of child elements, including patient type and id.

Yes

local_header

Name and value of local attributes.

No

Harmonised CDA Header The clinical document header for the harmonised PICNIC CDA R1 header message includes all of the elements in Table 2. Table 2 includes those elements within the overall CDA R1 standard that were considered relevant to the participating PICNIC regions in relation to their PICNIC prototypes [15]. Every element has its own sub-structure composed of either child elements and/ or attributes. 3.2. Access to Patient Data Access to Patient Data has been defined by PICNIC to be an IT service for professionals or citizens who need a uniform way to access parts of patient record data that are physically


69

(ii)

VEHR GUIGUI

End User

(iii)

(ii) Interface (iii)

Access Patient Data

Middle Layer (HII)

Interface

IDL Interface Interface CIS

(i)

Interface CIS

Figure 4. In order for the end user to access patient data, (i) individual CISs propagate updated information to the middle layer, (ii) the end user retrieves indexes, selects information of interest and (iii) directly accesses clinically significant information.

located in different clinical information systems. This end-user IT service provides fast, secure and authorized access to distributed patient record information from multiple, disparate sources. This service should not be confused with autonomous CISs, message based communication of EHR data, centralized CDRs, or monolithic information systems that have embedded in their structure mechanisms for accessing directly host systems. In that sense PICNIC provided an environment for integrated, round-the-clock access to clinically significant information which is kept at the place where it is produced and maintained by the most appropriate clinical information system in all cases. From the provided analysis, it has been deduced that the following elements are necessary in order to develop the service: • • •

information propagation from CISs to the middle layer of the HII; a component residing at the middle level of the “architecture” managing the required minimum data sets, as well as indexing; and finally a Graphical User Interface (GUI) to make available the Access to Patient Data to the end users (See Fig. 4).

Unique patient identification, patient consent on sharing the personal information, and organisational commitment in changing the traditional way of work, are all necessary requirements, as well as the existence of the appropriate legal framework that will allow the communication of personal record fragments among the involved actors. The main actors of the Shared Records IT service have been identified to be: • • •

the End User that represents the ultimate user of the system and can be either a Citizen or a Healthcare Professional and expect the service to be able to offer rolebased, secure access to reliable, patient information 24-hours a day; the Maintainer that represents a person who is responsible for the maintenance, expansion and enhancement of the system with new features; and the Existing IT System that represents a system that is a primary source of clinical information.

According to the description provided in the functional specifications harmonised document, the Access to Patient Data IT service features that can be translated into the use cases are listed in Table 3. The corresponding high-level UML diagram is depicted in Fig. 5.

70


Table 3. Use cases for the Access to Patient Data IT Service. Use Case

Short Description

Add New IT System

Adds a new system to the federation of IT systems. The Maintainer initiates this use case.

Access Control Rule

Defines, sets and updates the security roles and policies of the users when the try to access clinical information. The Maintainer or the End User initiates this use case.


Accesses the internal data structures so that they are kept up-to-date. It is initiated by the Maintainer or by an Existing IT System. It uses three “sub-use cases”: Provide Secure Information Communication, Keep Auditing Trails, and Semantic Mapping.

Access Rights Authentication

Relates to authentication and the use of passwords and user groups to validate users and allow them to access clinical information.


It is initiated by the End User and described how he/she can access clinical information. It uses three “sub-use cases”: Provide Secure Information Communication, Keep Auditing Trails, and Semantic Mapping.


Provides security through all communication paths. It is used by the Access Clinical Information use case and the Keep Information Up-to-date use case.


Audits every interaction between the various entities of the system. It is used by the Access Clinical Information use case and the Keep Information Up-to-date use case.

Semantic Mapping

Performs the translation between languages and coding schemes. It is used by the Access Clinical Information use case and the Keep Information Up-to-date use case.

Add New IT System

Adds a new system to the federation of IT systems. The Maintainer initiates this use case.

Access Control Rule

Defines, sets and updates the security roles and policies of the users when the try to access clinical information. The Maintainer or the End User initiates this use case.


Accesses the internal data structures so that they are kept up-to-date. It is initiated by the Maintainer or by an Existing IT System. It uses three “sub-use cases”: Provide Secure Information Communication, Keep Auditing Trails, and Semantic Mapping.

Add New IT System Maintainer

Existing IT System


>

> > Keep Auditing Trails Keep > Information > Up-to-date >

Access Control Rule

Access Rights and Authentication

Semantic Mapping

Retrieve Patient >

Access Clinical Information >

>

>

End User Access Primary Information Sources

Retrieve > Clinical Data Retrieve Clinical Information Pointers

Access Central Database

Figure 5. Main use case diagram for accessing patient data.


71

PIDS GUI Generic Components

COAS

4 3

AUDS

1 2

AUTS

… COAS

SRUB

CIS

CIS

ENCS RESS TERS

SRIS Access to Patient Data

UPS

Figure 6. The access to patient data architecture. (1) Indexing information can be either extracted by SRUB through COAS (pull model), or forwarded by locally installed COASs to SRUB (push model). (2) SRUB is responsible for transforming indexing information to a SRIS readable format. (3) The end user through SRIS accesses indexing information. (4) Once the location becomes known, the end user uses COAS to access clinical data. In most cases, the synergy of one or more of the auxiliary components already identified is required (e.g. TERS, RESS, etc.).

The main software entities that can be represented as access to patient data components are the following: • • • • • • • • • • •

Clinical Observation Access Component (COAS); Patient Identification Service Component (PIDS); Shared Records Data Service Component; Shared Records Indexing Service Component (SRIS); Shared Records Update Broker Component (SRUB); Auditing Service Component (AUDS); Authentication Service Component (AUTS); Encryption Service Component (ENCS); Resource Service Component (RESS); Terminology Service Component (TERS); and User Profile Service Component (UPS).

A brief description of components developed in PICNIC follows, while their synergy is depicted in Fig. 6. Patient Identification Service Component The PIDS component allows for the unique association of distributed patient record segments to a master patient index. PIDS is required by all regions involved with accessing patient data for both identification (ID) and correlation purposes, as well as for the support of active propagation of dynamic information (i.e. to support instant notification, and in that way maintain consistency among the systems that manage patient demographics). PICNIC has adopted the Object Management Group (OMG) PIDS specification [16] that defines the interfaces of a CORBA PIDS that organizes person ID management functionality to meet healthcare needs. The PIDS is designed: •

to support both the assignment of IDs within a particular ID domain and the correlation of IDs among multiple ID domains;

72


IDDomain DomainName

Supports 1

1..*

TraitType Name Mandatory Searchable ReadOnly

1

0..*

1

Trait Value 1..*

Merged 0..1

0..*

0..*

QualifiedID 1 IDValue State 0..* 0..*

1

1 Profile

Correlated

Figure 7. The adopted OMG PIDS conceptual model: “ID Domain” defines a set of IDs among which there is to be one unique person ID value per person represented. A “Qualified ID” is represented by a sequence of characters that one or more systems in an “ID Domain” use to represent a person and bind related information. A “Trait”, which is of a certain “Trait Type”, is an attribute (i.e. information) that can be used to help identify a person. Traits are grouped to create a “Profile”. Examples of traits include name, date of birth, gender, address, etc.

• • • • •

to support searching and matching of people in both attended-interactive and message-driven-unattended modes, independent of matching algorithm; to support federation of PIDS services in a topology-independent fashion; to permit PIDS implementations to protect person confidentiality under the broadest variety of confidentiality policies and security mechanisms; to enable plug-and-play PIDS interoperability by means of a “core” set of profile elements, yet still support site-specific and implementation-specific extensions and customization of profile elements; and to define the appropriate meaningful compliance levels for several degrees of sophistication, ranging from small, query-only single ID domains to large federated correlating ID domains.

The adopted conceptual model of PIDS is depicted in Fig. 7. Shared Records Indexing Server Component The SRIS component is required to provide the means for locating clinically significant information dispersed throughout the RHCN. SRIS manages data determined by the selected federated schema (i.e. indexed information can be related to existing encounters, allergies, personal information of relevance, etc.). SRIS is designed: • • • • • •

to support the ability to locate shared records information in a distributed environment; to leverage related specifications where appropriate (e.g. PIDS, COAS, TERS, RESS, security etc.); to leverage related specifications for local implementations; to support the ability to identify and retrieve properties of the information located (such as indication of the type, size and availability of located information, its format, count of matching instances, etc.); to provide for filtering, such as by patient, provider, information type, time frame, etc.; to support multiple, extensible location types (e.g., universal resource identifiers, COAS interoperable object references, paper-based, etc.); and


73

Patient HCProfessional

1

+attending physician 0..*

1

0..*

0..*

SystemInstallation +system

0..*

HCRecordFragment ID Type Description Date Codes

0..*

Location Type 1

1

1

{disjoint, incomplete} DirectContact PhoneNumber

URI Address

ISOZ39.50

HL7InstanceLocator

...

COASIOR IOR OID

Figure 8. The conceptual model of SRIS. A “Health Care Record Fragment” denotes the entity that contains clinical information, and the context in which this medical act took place. It contains only the indexing information and not the full information itself. “Location” represents a location where detailed information about a “Health Care Record Fragment” can be retrieved from.

•

to support the ability to be accessible from a plethora of devices e.g. PCs, mobile devices, and platforms, like the Hyper Text Transfer Protocol (HTTP) or CORBA.

This conceptual model of SRIS is depicted in Fig. 8. Clinical Observations Access Service Component COAS components are required for obtaining clinically significant information, captured at the point of care, directly from the corresponding clinical information systems. This service requires the implementation of standardized gateways for each clinical information system to enable for secure access to patient record data. PICNIC has adopted the OMG COAS specification [17], where “clinical observations” are defined to be “any measurement, recording, or description of the anatomical, physiological, pathological, or psychological state or history of a human being or any sample from a human being, and any impressions, conclusions, or judgments made regarding that individual within the context of the current delivery of healthcare.” All observations share a few common features: • • • •

they are made on a specific subject of care (e.g., patient, organ, population); they represent a snap-shot of that subject in time, either at a particular time, or over some specified interval of time (time in this context includes the notion of both date and time); they are made, or recorded, by an instrument or a healthcare professional in some clinical context; and they are given (either by the patient, the healthcare institution, or society) some degree of confidentiality.

Observations can be quantitative, qualitative, and recordings. For example, vital signs and clinical laboratory results, trends in measured values, impressions from a clinical exam, correlation of several qualitative impressions, and images and manipulations of images such as digital subtraction angiography. The adopted conceptual model of COAS is depicted in Fig. 9.

74

D.G. Katehakis et al. / PICNIC Technology ObservedSubject 1..* +characterized by 0..* +characterizes HealthRecordEntry 0..1 +contain 0..* +contained in 1..*

+composed of 0..*

CompositeObservation

+composes

Observation ObservationType ObservationTime

0..*

+referenced by

ObservationReference ObservationReferenceType

0..* +references 1..* +qualified by

{disjoint/ complete} AtomicObservation 1..* +references 1 +referenced by

+qualified by 1..* +qualifies ObservationQualifier 0..* 0..* +qualifies 1..* +references ObservationValue 1 +referenced by

Figure 9. The adopted OMG COAS conceptual model. An “Observation” may be Atomic or Composite. An “Atomic Observation” has an “Observation Value” associated with it, denoting the fact, note, or result of an observation. An “Observation Reference” defines an association between Observations.

Shared Records Update Broker Component SRUB components are required for the provision of prompt and consistent propagation of indexing information to SRIS. In other words, the SRUB component is responsible for keeping SRIS up-to-date with new or updated information, and maintains a loose consistency between CISs and the SRIS. Each CIS is associated to a single SRUB that either periodically (on pre-determined time intervals), or on demand, submits properly formatted information to the IS. Because COAS, in the context under consideration, is not designed for providing update/ notification information, it becomes necessary for the SRUB to maintain local indexing information for all the CISs of the federation that it is responsible for. This local indexing information, called Update Cache, is actually the partition of SRIS that corresponds to the specific CIS. The conceptual model of SRUB is depicted in Fig. 10. This design allows for the decoupling of SRIS update from the update of SRUB itself, making it possible to impose different policies in each of them. Two alternative policies that can be employed make use of the pull model and the push model. In the pull model the SRUB actively asks the CIS using the COAS as a gateway for collecting all available information. In the push model the SRUB is passively kept up-to-date, which means that the CIS sends the update information to the SRUB on demand. In this model an implemented event/ notification functionality of the COAS could be used to support these asynchronous updates of the SRUB. Both of these models are useful in practice. The pull model is more general in that the SRUB can extract all the modifications performed inside the CIS. In the downside, the whole data kept in a CIS is a huge volume of data that must be transmitted to the SRUB where the differences must be determined based on the current and the previous datasets. In the push model, only the modifications are transmitted to the SRUB, so the whole process is more efficient. The disadvantage though is that there is no general way to get

D.G. Katehakis et al. / PICNIC Technology HCRecordUpdateQueue MaxSize CurSize

75

HCRecordIndexingCache find_modifications() make_modifications()

insert_into_queue() remove_from_queue() enqueue() dequeue() dequeu_next_n() update_succedded_for() 1

1 0..* Patient 1

SystemInstallation +system

1

0..*

HCRecordUpdateData ID Flag Date

+data 1

0..* 0..* HCRecordFragment

1

1 0..*

Figure 10. The conceptual model of SRUB. Whenever a modification is submitted to SRIS and is committed, SRUB updates its own update cache in order to keep it synchronized. The “Health Care Record Update Queue” is a queue of the changes that need be submitted to SRIS. SRUB, after identifying the modifications required, it inserts them in the “Health Care Record Update Queue”. When it is decided that SRIS must be updated, information is removed from the “Health Care Record Update Queue” and is transmitted to SRIS.

modifications that have to do with “deletions” i.e. with information that does not exist any more. Following the event/ notification way of communication in COAS, a client can register its interest in receiving specific kind of information, e.g. for a specific patient or a specific type of clinical information, or information that satisfies some criteria. In all cases the notifications delivered to the client deal with new or updated information and not with information that is obsolete. Since both of these models are needed, a combination of the two is a rational decision: the push model can be used for frequent updates and less frequently the pull model as a general check and repair method for maintaining consistency. 3.3. Collaboration Telemedicine is an IT service used for the actual care of patients, making it possible to provide expert supervision to other professionals or directly to the patient. During the past ten years a large number of telemedicine projects have developed solutions for healthcare professionals at remote sites, to enable them to have access to the expert opinion of medical specialists via telemedicine in a variety of settings. Today we know that telemedicine is not only for remote sites, where access to the healthcare system is difficult. More and more telemedicine services and applications have been implemented and are used by the healthcare professionals to optimize the treatment of patients. It is foreseen that during the next ten years, telemedicine services will be as important as the stethoscope, to practice medicine. Some of the most important benefits consist in a rise in the quality of treatment and better utilisation of resources. At the same time the same technology helps remove the barriers that geography can put in the way of patient treatment. The healthcare experts are no longer any further away than the nearest Personal Computer (PC) with a network connection. The necessary specialist knowledge is available where it is needed – without the patient having to be moved to receive the best treatment. The objective of PICNIC was to develop a framework where all kind of telemedicine application can be interconnected to perform collaboration between healthcare profession-

76

D.G. Katehakis et al. / PICNIC Technology Profile

Availability

has

Contact

has

isa

Healthcare Professional

receives

Notification

has

sends/ receives

Invitation

Address Book

sends/ receives

Message

participates has

Status

has

records

Collaboration Context

has

records

Activity Log

Collaboration Item

isa Clinical Document

isa X-ray

isa isa ECG

Medical Image

Figure 11. The conceptual model of the Collaboration IT service. “Collaboration Context” maintains all information related to a collaborative activity. All participants are stored in “Address Book”. “Collaboration Items” represent all clinical data that are shared in the context of the collaboration. Those may be “Clinical Documents”, “X-rays”, “ECGs”, “Medical Images”, etc. The “Activity Log” keeps a detailed record of all activity that involves the collaboration context, including any posted “Message” and/ or “Invitation” to participate in the collaborative activity. The “Collaboration Context” may be linked to a workflow, in which case the state of the workflow is stored in “Status”. A “Healthcare Professional” is the typical user of the Collaboration IT service and all personal preferences are stored in a “Profile”.

als. The aim was to develop a set of tools and guidelines, which can be used by all companies to connect their telemedicine applications to the RHCN. The conceptual model for the Collaboration IT service is shown in Fig. 11. A healthcare professional may be interested in particular events concerning a collaboration context and may wish to be notified in a special way and/ or on a specific device. A healthcare professional using the service may play the role of the consultant, participant, or referrer. In the role of the participant, a healthcare professional may participate in a chat conference posting messages, or inviting more specialized healthcare professionals. In the role of the referrer, the healthcare professional uses a CIS that stores patient data and provides access to the Collaboration IT service that facilitates access to clinical information and automatic creation of clinical documents (compliant to the HL7/ CDA R1 architecture), based on templates customized for different clinical problems. These documents could be linked to the problem at hand and the EHR. The main actors of the Collaboration IT service have been identified in PICNIC to be: •

•

the Healthcare Professional who is a generalization of different healthcare individuals (medical expert, medical doctor, nurse, general practitioner, and social worker) that belongs to a health organization and uses the Collaboration IT service in the treatment of a patient. The Collaboration IT-service can be used to establish collaboration with other Healthcare Professionals and share data on-line as well as off-line. The Instant Messaging System is a technology platform that provides presence (online and off-line) for the Healthcare Professional, who participates in the Collaboration IT service. The Instant Messaging System can be considered as part of the


77

Chat Conference Access Collaboration Context

Invite to Collaboration

Edit Profile

Update Collaboration Context

Healthcare Professional

Find Resource

Request Notification Create Collaboration Context

Figure 12. Main use case diagram for the Collaboration IT service.

•

• •

• •

collaboration Context Manager, where the Collaboration Context Manager is the front-end (client) and the Instant Messaging System is the back-end (server). The Notification Agent actor has the responsibility to send notifications to Healthcare Professionals involved in a specific collaboration. The Healthcare Professionals may in advance request and specify what event and conditions he should be notified about. The Clinical Information System actor is any end user application used by the Healthcare Professionals. The Clinical Information System has implemented the needed interface to the use of the Collaboration IT-service. The Collaboration Context Manager actor takes care of storage and retrieval of all clinical data or pointers to clinical data for a collaboration session. The Collaboration Context Manager provides also the capability to Healthcare Professionals to share the clinical data via a CIS. The Collaboration Context Manager communicates with the Instant Messaging system. The Patient actor is an individual that is admitted to the hospital or consults another Healthcare facility for treatment of a specific health problem. The Resource Directory System is a directory service, which gives access to information about healthcare professionals, healthcare organizations and collaboration contexts.

The main use cases for the Collaboration IT Service are shown in Fig. 12. According to the description provided throughout the services description and the subsequent harmonised functional specifications, the Collaboration IT service features can be translated into the use cases listed on Table 4. The main software entities that can be represented as collaboration components are the following: • • • • • • • •

Clinical Observation Access Component; Collaboration Service Component; Patient Identification Service Component; Shared Records Indexing Service Component; Auditing Service Component; Authentication Service Component; Encryption Service Component; Resource Service Component;

78


Table 4. Collaboration IT service use cases. Use Case

Short description

Create Collaboration Context

When the Healthcare Professional encounters a new episode, a new Collaboration Context can be defined, in which all information about the patient can be shared with other Healthcare Professionals. Via the Collaboration Context other Healthcare Professional can be invited to take part in the treatment of the patient.

Access Collaboration Context

Collaboration between Healthcare Professionals for a specific patient, will always take place via a Collaboration Context, where all kind of clinical data are shared. The Collaboration Context includes functions for inviting new Healthcare Professionals, updating the clinical data, which are shared and engaging in a chat conference.

Find Resource

Provides information about all kind of resources available. The resources can be healthcare organizations, healthcare professionals involved in a Collaboration Context. A resource can also be a Collaboration Context itself.

Request Notification

The Healthcare Professionals may request to be notified about specific events relevant to a Collaboration Context and receive notifications as requested.

Invite to Collaboration

The Healthcare Professional may invite other Healthcare Professionals to participate in a Collaboration Context.

Chat Conference

One of the Healthcare Professionals can launch a conference in order to discuss with other Healthcare Professionals.

Update Collaboration Context

The Healthcare Professionals, which have been invited to participate in a specific Collaboration Context and put documents into the context. The documents in the Context are shared information.

Edit Profile

Each Healthcare Professional can edit her/ his personal data and notification preferences that are stored in a Profile, in order to make it possible to fulfil specialised needs.

Collaboration Service COLS

Other Components

CIS

AUDS AUTS ENCS

APACHE

JABBER

TERS UPS PIDS

RESS

Figure 13. The collaboration architecture. The collaboration service comprises of COLS and RESS, while interaction with other components is indirect through the CIS. The Jabber Instant Messaging System [18] can be interfaced in order to improve accountability and keep a detailed record of all the activity in a collaboration context. The Apache HTTP server [19] is used for the exchange of data between the participants.

• •

Terminology Service Component; and User Profile Service Component.

Their synergy is depicted in Fig. 13, a brief description of components developed in PICNIC follows.


79

CollaborationContextManager logon() sendMessage() getContextManager() getResourceManager() addInvitationListener() removeInvitationListener()

ContextManager

has 1

1

createContext() accessContext()

1 has 0..*

1

Context has 1

Listener

ResourceManager createResource() findResource()

invite() addItem() sendMessage() requestNotification() findNotification() addItemListener() addResourceListener() addActivityListener() removeItemListener() removeResourceListener() removeActivityListener() leave()

Figure 14. COLS Class diagram.

Collaboration Service Component COLS components are required to establish a collaboration context that enables not only the active sharing of clinically significant information, but also receiving feedback, feed through and awareness information from all participating actors. COLS is designed: • • • • • • • • •

to support multiple, extensible resource types (e.g. health care professionals, organizations, collaboration contexts, services, devices, pricelists, etc.) with respect to their type and way of expression of internal information; to support the ability to locate resource information in a distributed environment; to provide for filtering, such as by resource type and attribute, type, time frame, etc.; to support for site-specific and implementation-specific extensions and customization of profile elements; to support the ability to be accessible from any devices e.g. PCs, mobile devices, and platforms, like HTTP or SOAP; to support on-line presence of connected users; to support exchange of various type of information free text, structured information by use of standards (eq. EDIFACT, HL7); to support conference facilities (chat, video and sound; and to support subscription and notification of events in a collaboration.

The computational boundary classes of COLS are depicted in Fig. 14. Resource Service Component (RESS) The RESS component constitutes an integral part of the PICNIC architecture to enable for the discovery of existing components and services of the healthcare infrastructure. It is intended to maintain and provide information about all related healthcare agents. According to CEN-TC251 these include any healthcare person, healthcare organization, healthcare device or healthcare software component that performs a role in a healthcare activity [20] within the health system under consideration.

80


This component ought to be the central repository of location information and the place where potential clients (users, components, applications) are directed in order to find and identify the offered components/ services in the distributed environment of a RHCN. RESS components are useful for identifying available resources and the means for accessing them. Examples of resources include pharmacies on-duty, hospitals and clinics, clinical information systems available at a regional level, methods and technologies available for accessing primary information, and protocols for exchanging information with them. A resource service component may also provide information about equipment/ devices available at certain facilities, as well as used by certain categories of people, together with the corresponding equipment/ device characteristics. In this context, it is apparent that any definition of resource ought to include, without being limited to, the following: • • • • •

software entities, e.g. CORBA servers; healthcare facilities, e.g. hospitals, clinics; equipment/ physical devices, e.g. microscope, or computed tomography; healthcare professionals/ hospital personnel; and users.

It is difficult to anticipate every potential kind of resource that exist or could exist in the future and would be of interest, so the implementation of the RESS should be as much generic as possible, without imposing any constraints that could limit its use when future demands for new resources appear. Additionally, the information managed by the RESS for each resource should be expressed in a generic manner. An important consideration has to do with the fact that the attributes for each type of resource varies significantly. For example, for a web server it is important to know the host name, address and port number, while for a physician the name, address and specialty of the subject is important. The resource service will keep information about: • • • • •

type of health care specialist available; pricelist for different type of resources; profile for organization and individual health care specialists; type of information, which can be exchanged (images, video, sound, structured text, unstructured text, booking of resources, type a standard used); and reimbursement.

RESS is designed: • • • • • •

to support multiple, extensible resource types (e.g. people, services, devices, etc.) with respect to their type, relation and way of expression of internal information; to support the ability to locate resource information in a distributed environment; to provide for filtering, such as by resource type and attribute, information type, time frame, etc.; to support for site-specific and implementation-specific extensions and customization of profile elements; to compliance with the overall PICNIC architecture; and to support the ability to be accessible from a plethora of devices e.g. personal computers, mobile devices, and platforms, like HTTP or CORBA.

The conceptual model of RESS is depicted in Fig. 15.

D.G. Katehakis et al. / PICNIC Technology TraitType Name Mandatory Searchable ReadOnly

supports

ResourceDomain Name

1..*

1

81

Trait Value 1

0..*

1

1..* Association Type

0..* 0..*

ResourceType Name 1

0..* Resource ID

1 Profile 1

0..*

1

{incomplete} contains 0..* Staff

User

HcFacility

System

1

Location Type Name

ServiceCatalog

Figure 15. The conceptual model of RESS. Each “Resource” is uniquely identifiable within the context of a “Resource Domain”. Each “Resource Domain” supports several “Resource Types”. Two or more Resources can be interrelated through an “Association”. In a given “Resource Domain”, a number of “Trait Types” are supported for a given “Resource Type”. “Trait” is an instance of a “Trait Type” and consists of its type and value. Finally each “Resource” has a “Profile”, which bundles its entire set of “Traits”.

4. Software Components A formal way to identify the exact nature and role of each of the components required by any health information network was used throughout PICNIC. The unified software development process [21] is the adopted methodology, describing how to elicit, organise, and document required functionality and constraints; track and document tradeoffs and decisions; and easily capture and communicate the healthcare domain requirements. The notions of use cases and scenarios prescribed by the RUP have proven to be an excellent way to capture functional requirements and to ensure that these drive the design, implementation and testing of software, making it more likely that the final system fulfils the end user needs [22]. UML was used in order to specify, visualise, and document models of software systems, including their structure and design, in a way that meets all available requirements. UML is the tool used to transform system capabilities into requirements, and use cases including both basic and alternative flows of events in the form of interaction diagrams. In specifying components, adequate care was taken so that their internal semantics are neutral, in the sense that each component ought to be able to be configured differently under the different execution environments it is expected to operate in. Work conducted in PICNIC identified the health services [23] within a RHCN and an IT response [24]. The analysis of these identified commonalties in models and tools and established a common base for the development of generic tools and common software components [25]. It also led to a description of components identified and an initial high level view of the each IT service’s functionalities, involved actors, as well as the components, forming subsystems of each IT service. These were taken through different steps

82


starting with the initial decisions on which software components to include and how best to develop them were documented, ending with the production of the actual specifications for those components selected to be deployed in more than one region and/ or application domains [26]. Apart from the middle layer components described above, a number of platform services that provide basic functionality are in all technology platforms (e.g. Microsoft, Java, CORBA, World Wide Web Consortium – W3C etc.) are needed so that the ‘global system’ exhibits the required behaviour in terms of security (authentication, encryption, auditing, etc.), concurrency control, event handling, transaction management, workload balancing, etc. 4.1. Performance Issues Any middleware platform should not sacrifice efficiency in favour of usability, flexibility, and feature richness. The performance factor is critical especially in domains such as the healthcare where, in some cases, “the right answer delivered too late becomes the wrong answer”. In such application domains, middleware components’ developers should pay close attention to performance dimensions such as the following: • • • •

Throughput: The component should be able to handle a large number of requests per unit time, e.g. per second or per “busy hour”; Latency: The component should minimise the request/ response processing delay when a client calls an operation; Jitter: The component should minimise the standard deviation of the latency in order to increase predictability and determinism; Scalability: The component should be able to sustain its performance when some external condition changes, such as when the load increases (load scalability) or when the number of hardware units, such as central processing units, increases (system scalability).

Various techniques can be deployed to achieve higher efficiency: •

•

•

Concurrency: multithreading or multiprocessing [27] can increase the concurrency of the system, i.e. its inherent parallelism. Study of the more appropriate collaboration patterns between component’s modules should be done in order to minimise the synchronisation overhead and the threads’ contention for shared resources. Another way to increase concurrency is to utilise asynchronous mechanisms like asynchronous input/ output [28] or asynchronous method calls [29]. Caching: Complex and/ or expensive calculations, or tasks in general, can be minimised by keeping a cache of recent results [30]. Much attention ought to be given to the analysis of what are the system’s resources that should be kept in a cache, in addition to the memory considerations and the cache replacement algorithms. Load Balancing: Distributing workload in a cluster of computer hosts or some other computation nodes such as threads or process usually increase the real parallelism of the system [31]. Additionally, it minimises the danger of a single-point failure and increases the availability of the system.

Achieving these goals is a difficult task most of the times because it is a common phenomenon that these different mechanisms do not collaborate in a synergistic manner. A lot of experience and study is usually needed in order to overcome the inherent complexities in developing and maintaining software components that offer the advantages described above. The use of design and architectural patterns leverages the development of robust, efficient, and reusable middleware components [32].


83

4.2. Conformance Levels Four levels of conformance can be proposed for further consideration. Each one of them is progressive, in that it builds upon prior levels and is necessary for subsequent levels: • • • •

Architecture conformance Interface conformance Semantic conformance Qualified code conformance

Architecture conformance refers to the required interoperability technology. Examples include Microsoft’s Component Object Model/ Distributed Internet Architecture [33,34], Sun Microsystems’s Enterprise JavaBeans/ Java 2 Enterprise Edition [35,36], as well as the Object Management Group’s Component Object Request Broker Architecture [37]. Since 2001, interest has been growing in using Web services, a set of technologies based on XML, as a component model for Internet communications [38]. Interface conformance refers to conformance to one or more interfaces described at the specification part of the component definition. Examples include the classes defined for PIDS, COAS, SRIS, and SRUB. An implementation claiming conformance to any of these classes must conform to all of the interfaces specified for that class. An implementation may claim conformance to multiple conformance classes as long as it is conformant to each one it claims. Semantic conformance refers to conformance related to the semantics used for communicating structures containing values of data. Examples include the various domain models that can be used with PIDS, or for accessing COAS. Qualified code conformance refers to conformance to a naming convention for the use of terms from other standards. Qualified codes are globally unique concept codes formed by combining the coding scheme id and the local concept code within that coding scheme.

5. Security and Privacy Security refers to two main issues: • •

security (resilience) of the hardware, operating system and the application software; and control of the use of information.

The main focus in PICNIC was the latter especially as it dealt with private and confidential patient information. The former, while being equally important, is an issue that must be solved in the selection of the software platform and the tools used to create the execution environment and the applications. Security management is a particular instance of the general information system management functions. Information system security management services are concerned with the installation, maintenance, and enforcement of information domain and information system security policy rules in the information system intended to provide these security services. In addition to these core services, security management requires event handling, auditing, and recovery. Standardisation of security management functions, data structures, and protocols will enable interoperation of security management application processes across many platforms in support of distributed security management. The concept of an information domain provides the basis for security protection. An information domain is defined as a set of users, their information objects, and a security policy. An information domain security policy is the statement of the criteria for membership

84


Figure 16. Bridging information domains securely.

in the information domain and the required protection of the information objects. Security policy implements regional and/ or local requirements and needs. It must be based on national legislation on the protection of personal data when collected, processed and/or transferred and on the laws regulating the practice of medicine and delivery of healthcare services by healthcare professionals. Security within each information domain must be established in accordance with the respective security policy. For communication between the information domains, a trusted end-to-end communication policy must be established (see Fig. 16). The European Union (EU) data protection directive is currently being implemented into the national legislation of the EU Member States. This means that every EU Member State must have the same level of legal protection of personal data. The same does not apply to healthcare and medicine. There each country still has its own mandate. Consequently, security policies and their implementations in the RHCN’s will be different. However, although they are different, there are several commonalties between the regions and in the technologies deployed. Each will have to address the following issues: • • • •

Data protection (including audit trails) Data confidentiality (including encryption) Authentication of users Authorisation (including assigned roles regulating access rights to e.g. patient data).

Additionally, security policies must deal with the informed consent of patients (customers), which is required for legal access to patient data. Consent may also have qualifiers e.g. restricting access to only part of the patient data or restricting the period of time that the consent is given. Finally, the choice of what security features to implement must be based on risk assessment in the context of the intended service. For these reasons the approach adopted in PICNIC for security was that each pilot region will have to implement it in accordance with their national legislation and guidelines and based on their software platform security functions. Due to the particular nature of healthcare and the private and confidential information that is produces, stores and processes a number of projects have been carried out over the years on these issues. These include EU-funded projects such as CHARM (Comprehensive Health Assistance and Resource Management) [39], HARP (Harmonization for the Security of the web technologies and Applications) [40], and RESHEN (Regional Secure Healthcare Networks) [41].


85

1st stage

2nd stage

3rd stage

Border Security

Authentication

Authorisation

Network Layer Security

Proof of identity

Permission based on identity

• Virus scanning • Firewalls • Intrusion detection • Virtual private networking • Denial-of-service protection

• Username/ password • Password synchronisation • Public key • Tokens • Biometrics • Single sign-on

• User/ group permissions • Enterprise directories • Enterprise uses administration • Role based access control • Denial-of-service protection

Figure 17. A Layered Defence (from [42]).

5.1. Security Within Information Domains The general stages for implementing security are shown in Fig. 17. In the following the main elements of authentication and authorisation will be briefly described. Access & User Identification In order to access system resources and patient data users must be identified. I.e. access to resources and data must be controlled so that unauthorised access is prevented. Access rights can be managed on two levels: • •

authentication (the person is who (s)he claims to be); and authorisation (permitting access to resources and data based on a qualified role, role-based access).

A concept often associated with access is Single-Sign-On (SSO). This means that when a person logs into a system, is authenticated and authorised in a role (s)he gets access to all resources and data that that role entitles. In a healthcare context users often have to use several information systems. In such cases SSO is useful as it allows access to all information systems that the user is authorised to use in that role with only one log-in. SSO can be implemented e.g. using the Clinical Context Object Workgroup (CCOW) standards produced by HL7. Consent (by patient) Information may not be made available or disclosed to unauthorised individuals, entities or processes without the consent of the patient. This is a fundamental right of individuals that they shall have the power to keep information about themselves from being disclosed to anyone [43]. Therefore, the individual (patient) must agree/ consent to disclosing her/ his private information. In healthcare, consent refers to a communication process between the caregiver and the patient, and may refer to consent for treatment, special procedures, release of information, and advanced directives. There a several kinds of consent: • • •

Expressed consent: Oral or written agreement. Because it is difficult to prove that oral consent was given, most expressed consent is expected to be recorded with a signature. Implied consent: An action other than an expressed consent on the part of a patient that demonstrates consent. For example, the presentation of a person to a caregiver implies, to a certain extent, consent to at least basic consent. Informed consent: In some countries/ healthcare organisations, for a consent to be valid, the patient must be informed. The patient should be given the opportunity to

86


ask questions, to indicate comprehension of the information provided, and to grant permission freely and without any coercion for performance of a procedure or course of treatment, as well as the opportunity to withhold or revoke such permission at any time without prejudice. Audit trail Audit trails refer to data collected and potentially used to facilitate a security audit. It comprises of a chronological set of records that provides evidence of system activity. These records can be used to reconstruct, review, and examine transactions from inception to output of final results. The records can also be used to track system usage and detect and identify intruders. Audit trails are needed to ensure accountability of actions of individual persons or entities, such as obtaining informed consent or breaching confidentiality. 5.2. Trusted E2E Communication The International Organization for Standardization (ISO) Technical Committee 215 has been working on a Technical Report on “trusted end-to-end information flows” [44]. Figure 18 illustrates the principle. The idea in this approach is that it is the responsibility of the information domains to negotiate under what terms they are able and willing to exchange information. Each information domain has its own security policy stating e.g. what conditions must be met to access or store/ modify patient data. The requesting information domain has to provide information about its security measures to the replying information domain. This may include information about how the user that has originated the request has been authenticated and authorised and that an explicit consent has been given by the patient for this request to access her/ his data. It is the responsibility of the replying side to examine these certificates and ascertain their authenticity and based on these decide whether to provide the requested service or deny it. Both sides will additionally have to create audit trails of the transaction independent of whether the service was delivered or not. 5.3. Security Technologies Public Key Infrastructure and Certification Authorities Public Key Infrastructure (PKI) is used to describe the processes, policies, and standards that govern the issuance, maintenance, and revocation of the certificates, public, and private keys that the encryption and signing operations require. PKI is used in order to enable two entities that do not know each other to exchange information using an insecure network such as the Internet. The infrastructure is based upon asymmetric cryptography and each entity (user, information system, etc.) is provided with a pair of keys (a private and public key). Certification Authority (CA) is a trusted party that can vouch for the binding between names or identities and public keys. In some systems, certification authorities generate public keys. The public key certificate binds a user’s name to a public key signed by a trusted issuer. Smart cards are mostly associated with PKI and CAs as an access card containing encoded information and sometimes a microprocessor and a user interface. The information on the code, or the information generated by the processor, is used to gain access to a facility or a computer system. The security infrastructure comprises the following services:


Downstream Data Flow: Front to Back-end, Source to Consumer

87

Data Flow: to Third Party

Chain of Trust • Subject of care health record • Provider business (operations) record • Healthcare professional service record Privacy/ Confidentiality: Individually Identifiable Information

Individually Identifiable or Dis-identified or Aliased

Interchange Content: e.g., • Patient/ member health records • Patient account, insurance records • Clinical data • Administrative and operational data • Measures/ indicators: performance, quality compliance, utilization, productivity, costs

Interchange Content: e.g., • Claims, attachments • Public health reporting • Measures/ Indicators • Research extracts

Accountability of: • Individuals: Healthcare Professionals, Authors, Scribes, Verifiers, … • Business units: Departments, Services, Specialities • Organizations: Providers, Health Plans, … Auditability, Traceability, Audit Trails: • Access/ use record • Originate/ amend/ verify/ translate record content • Disclose/ transmit/ receive record content • Process/ aggregate/ derive/ summarize/ extract record content Authentication: • User Authentication: proof of individual identity • Source/ Origin authentication: proof of source/ origination, authorship • Validation: proof of verification (e.g. automated device input)

Data integrity: • Accuracy, consistency, continuity, completeness, context, comparability Persistence: • Permanence, Indelibility, revision by amendment only • Data states: initial and each subsequent amendment

Persistence Contexts: • Accountability • Data Integrity • Clinical • Administrative/ Operational

Figure 18. Trusted end-to-end information flows (from [44]).

• • • • •

CAs that control and manage the PKI, publish public key certificates, and impose policies in their domain of authority. Registration Authorities that collect the required eligibility certificates from interested parties, verify their authenticity, and subsequently inform CAs. Certificates Management Systems (CMS) for management of certificates during their entire duration of validity. The CA controls and uses the CMS. X.500 directories that store public key certificates as well as public information for the holders of certificates and are used for the verification of digital certificates. The certificate of the users, which is published by the CA, is stored together with the user’s private key, in a microprocessor card.

Digital Signature Digital signature is a means to guarantee the authenticity of a set of input data the same way a written signature verifies the authenticity of a paper document. Digital signatures are re-

88


quired in many cases during the provision health services to a citizen. It comprises a cryptographic transformation of data that allows a recipient of the data to prove the source and integrity of the data and protect against forgery. To sign a document, the document and private key are input to a cryptographic process, which outputs a bit string (the signature). To verify a signature, the signature, document, and user’s public key are input to a cryptographic process, which returns an indication of success for failure. Any modification to the document after it is signed will cause the signature verification to fail (integrity). If the signature was computed using a private key other than the one corresponding to the public key used for verification, the verification will fail (authentication). The basic process for the exchange of digitally signed messages is outlined below: •

• • • •

The sender of the message produces the digest of the message (i.e. the representation of the message in the form of a single string of digits using a one-way hash function) which it/ she/ he subsequently encrypts with its/ her/ his private key. This way the digital signature is formed. The digital signature and the sender’s certificate are dispatched with the message. The certificate contains the identity of sender and its public key. The recipient confirms the sender’s certificate, and then using the public key of the sender calculates the initial digest of the message. The recipient also produces the digest of message directly from the received message. If the two digests are same then the signature is authentic.

Digital signatures can be attached to any electronically transmitted message, including ones transferring EHR data. The digital signing of XML based clinical documents is a special instance where the nature of the clinical workflow may require that each participant only signs that portion of the document for which they are responsible. Older standards for digital signatures do not provide the syntax for capturing this sort of high-granularity signature or mechanisms for expressing which portion a party wishes to sign. The joint standards effort between W3C and the Internet Engineering Task Force (IETF) includes a standard for XML Signature [45,46]. It is being created with the ability to sign only specific portions of the XML tree rather than the complete document. This will be relevant when a single XML document may have a long history in which the different components are authored at different times by different parties, each signing only those elements relevant to them.

6. Conclusions PICNIC by following a top down approach has identified the need for certain key components. These components, when implemented within the regional pilots, are expected to realize their potential as more of them become available. This is because component-based software development shifts the focus from new software development to the integration of existing components to perform new tasks; while at the same time it addresses the issues of large-scale system development in the areas of coupling, distribution, and multiple platforms. The Internet is imposing new integration challenges as it extends into every corner of every organisation. Today, the issue of dealing with new platforms and applications that must interoperate with legacy systems becomes more important. As computers and networks become faster and cheaper and interconnection standards evolve new technologies constantly appear for new application niches. In developing the next generation RHCN, an architecture is required, being a strategic resource with the potential of enabling and sup-


89

porting the RHCN in meeting its goals (see also the Architecture chapter). The software engineering view of this architecture acts as the unifying framework that provides structure and semantics and realises the components potential as more of them become available. Eventually it is expected that the creation of application models that will be in a position to be translated automatically into software (capable of running in the target deployment environment) will eliminate much of the effort currently required for software development. This approach will offer an architecture always ready to deal with yesterday’s, today’s and tomorrow’s execution environment. It will also make application and IT services integration across middleware boundaries easier; while at the same time it is expected to provide much wider cross-platform interoperability among different platform services. Today the new Model Driven Architecture (MDA) that OMG adopted in 2001 [47] focuses exactly on this. With component-based software, the significance of deciding whether it is better to buy an integrated suite from a single vendor or choose individual best-of-breed applications from several vendors is reduced because standardised component interfaces facilitate the combinations of components from different vendors. The web services architecture, which today is still being developed, extends component-based software by allowing some of the components to be operated as IT services that can be discovered through publicly available directories, and provides the means for accessing components spanning the entire Internet.

Acknowledgements The authors would like to thank everyone involved in the implementation of the “IT Response” and “Common Components Development” work packages of the PICNIC project; namely: Paddy BURKE (Ireland), Ita BROWN (United Kingdom), Richard CAMPIN (United Kingdom), Ana CARRIAZO Perez de Guzman (Spain), Jaime Nieto CERVERA (Spain), Catherine CHRONAKI (Greece), Jose Antonio COBENA (Spain), Paraic COLREAVY (Ireland), Mary CORRIGAN (Ireland), Declan McCORRY (United Kingdom), Baldur JOHNSON (Iceland), Leslie FINLAY (United Kingdom), Caroline GALLAGHER (Ireland), Hulda GUDMUNDSDOTTIR (Iceland), Anna HAFBERG (Iceland), Jose Maria de la HIGUERA (Spain), Stefan IGELMANN (Germany), Timo ITALA (Finland), Tove KAAE (Denmark), George KAVLENTAKIS (Greece), Ole LYKKE (Denmark), Alpo KOMMINAHO (Finland), Stavros KOSTOMANOLAKIS (Greece), Evi MAVROGIANNAKI (Greece), Tuire MIKOLA (Finland), Marino G. NJALSSON (Iceland), Pentti PALOMAKI (Finland), Thorgeir PALSSON (Iceland), Susann Duedal PEDERSEN (Denmark), Alkis POULIS (Greece), Jakob POULSEN (Denmark), Michael PSARROS (Greece), Manuel Lopez SERRATO (Spain), Stelios SFAKIANAKIS (Greece), Theo STIDSEN (Denmark), Manolis TSIKNAKIS (Greece), Jari VIITANEN (Finland), and Manuel VILLACORTA (Spain).

References [1] Building Regional Healthcare Networks in Europe, J. Oates and H. Bjerregaard Jensen (editors), IOS Press, 2000. [2] UML Home Page http://www.uml.org. [3] Grady Booch, Object Solutions, Addison-Wesley, 1995. [4] Ivar Jacobson, M. Griss, and P. Jonsson, Software Reuse—Architecture, Process and Organization for Business Success, Harlow, England, AWL, 1997. [5] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p.

90


[6] Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, Los Alamitos, CA, 1996, pp. 140. [7] Maria Ericsson, Developing Large-scale Systems with the Rational Unified Process, Rational Software White Paper, 2000 http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/ sis.pdf. [8] PICNIC Deliverable 4.2, Functional Specification and Minimum Data Set for New Services, March 14, 2001. [9] PICNIC Deliverable 6.2, Messaging Components Harmonized Specification, May 10, 2002. [10] PICNIC Deliverable 6.3, Access to Patient Data Component Specifications, March 11, 2002. [11] PICNIC Deliverable 6.4, Collaboration IT Service Component Specifications, June 4, 2002. [12] Technical Committee 251 of the European Committee for Standardization http://www.centc251.org/. [13] R. Dolin et al. “An Update on HL7’s XML-based Document Representation Standards.” Proc. Of AMIA 2000. [14] HL7, ‘Version 3 Standard Clinical Document Architecture Framework Release 1.0’, 2000. [15] David Piggott, Catherine Chronaki, Morten Bruun-Rasmussen, Dimitrios G. Katehakis, Vesa Pakarinen, Niilo Saranummi, Jari Viitanen, Timo Itälä, Reporting Experiences from Using the HL7 Clinical Document Architecture in the PICNIC, HL7 International CDA Conference, Berlin, Germany, October 7–10, 2002. [16] Object Management Group, Healthcare Domain Task Force, Person Identification Service Specification http://www.omg.org/technology/documents/formal/person_identification_service.htm. [17] Object Management Group, Healthcare Domain Task Force, Clinical Observation Access Service Specification http://www.omg.org/technology/documents/formal/clinical_observation_access_service.htm. [18] Jabber Software Foundation http://www.Jabber.org. [19] The Apache Software Foundation http://www.apache.org/. [20] European Committee for Standardization (CEN/TC 251), WG I, Information Models: “ENV 13606 – Electronic Healthcare Record Communication”, 1999. [21] Jacobson I., Booch G., Rumbaugh J., “The Unified Software Development Process”, Addison-Wesley, 1999. [22] Jacobson I., Christerson M., Jonsson P., Övergaard G.: “Object-Oriented Software Engineering—A Use Case Driven Approach”, Wokingham, England, Addison-Wesley, 1992, 582p. [23] PICNIC Deliverable 3.2 “New Model for Providing Services”, July 11, 2000 (www.medcom.dk/picnic). [24] PICNIC Deliverable 4.1 “New Services”, March 6, 2001 (www.medcom.dk/picnic). [25] PICNIC Deliverable 4.2 “Functional Specification and Minimum Data Set for New Services”, March 14, 2001 (www.medcom.dk/picnic). [26] PICNIC Deliverable 6.1 “Identification of Generic Tools and Common Component, Part I”, July 10, 2001. PICNIC Deliverable 6.2 “Specifications of Messaging Common Components”, May 10, 2002. PICNIC Deliverable 6.3 “Specifications of Access to Patient Data Common Components”, March 11, 2002. PICNIC Deliverable 6.4 “Specifications of Collaboration Common Components”, June 4, 2002 (www.medcom.dk/picnic). [27] D.A. Solomon: Inside Windows NT, 2nd edition, Microsoft Press, 1998. B. Lewis: Threads Primer – A Guide To Multithreaded Programming, Prentice Hall, 1995. [28] Information Technology – Portable Operating System Interface (POSIX) – Part 1: System Application: Program Interface (API) [C Language], 1995. [29] Object Management Group, CORBA Messaging Specification, OMG Document orbos/98-05-05 ed., May 1998. [30] P. Cao and S. Irani: Cost-aware WWW proxy caching algorithms, Proceedings of the USENIX Symposium on Internet technologies and Systems (USITS), Monterey, CA, Dec. 1997. [31] O. Othman, C. O’Ryan, D.C. Schmidt The Design and Performance of an Adaptive CORBA Load Balancing Service, http://www.cs.wustl.edu/~schmidt/PDF/load_balancing.pdf. [32] D.C. Schmidt, M. Stal, H. Rohnert, F. Buschmann, Pattern-Oriented Software Architecture, volume 2, Wiley, 2000. [33] Microsoft Component Object Model http://www.microsoft.com/com/default.asp. [34] Christopher Et Al Blexrud, Jonathan Crossland, Dino Esposito, Jason Hales, Whitney Hankison, Vishwanath Honnaya, Tim Huckaby, Slava Kristich, Edward Lee, Rockford Lhotka, Brian Loesgen, Stephen Mohr, Simon Robinson, Ash Rofail, Brad Sherrell, Scott Short, Dan Wahlin, Professional Windows DNA: Building Distributed Web Applications with VB, COM+, MSMQ, SOAP, and ASP, Wrox Press Inc; 1st edition, September 29, 2000. [35] Enterprise JavaBeans Technology http://java.sun.com/products/ejb/. [36] Java 2 Platform, Enterprise Edition (J2EE) http://java.sun.com/j2ee/. [37] CORBA Web Site http://www.corba.org/. [38] Web Services Activity, W3C Architecture Domain http://www.w3.org/2002/ws/.


91

[39] CHARM (Comprehensive Health Assistance and Resource Management) IST-2000-25389 project http://www.charm.cup2000.it. [40] HARP (Harmonization for the Security of the web technologies and Applications) IST-1999-10923 project http://www.telecom.ntua.gr/~HARP/HARP/HARP1.htm. [41] RESHEN (Regional Secure Healthcare Networks) IST-2000-25354 project http://www.biomed.ntua.gr/ reshen. [42] McConnell, Hamilton: Information assurance in the 21st century, supplement to IEEE Computer, Security and Privacy – 2002. [43] DIRECTIVE 2002/58/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications) http://europa.eu.int/eur-lex/pri/en/ oj/dat/2002/l_201/l_20120020731en00370047.pdf. [44] ISO/ CD TC 215: TR 21089, Health Informatics – Trusted end-to-end information flows. [45] The XML Signature initiative: Joint W3C/ IETF XML-DSig Working Group http://www.w3.org/ Signature/. [46] XML Signature W3C Recommendation. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/. [47] OMG Model Driven Architecture. http://www.omg.org/mda/.

92


How to Use the PICNIC Results David PIGGOTT Director, Integrity Consulting Partners Abstract. Integrity Consulting Partners (ICP) is an independent consulting firm, specialising in healthcare ICT support, with a range of major projects delivered for European public healthcare clients in the areas of systems specification and design, procurement and project management of system implementations. ICP has had a strategic relationship with the General Medical Services (Payments) Board (GMS(P)B) in Ireland over a six year period, and has undertaken many key projects for the Board during that time. Accordingly, when the GMS(P)B became a partner in PICNIC, ICP were contracted to assist in the delivery of the project. In Phase 2 of PICNIC, when the GMS(P)B became the PICNIC Project Co-ordinator, project management and technical support in this role were provided by ICP. David Piggott lead the firm’s work on PICNIC and facilitated the development of many key PICNIC deliverables, including the PICNIC Architecture and Exploitation Strategy. This chapter summarises the recommended approach to the implementation of the PICNIC concepts and standards, including a suggested way forward for procuring support on the deployment of the PICNIC products.

1. Introduction In order to apply the results of PICNIC and realise the PICNIC Architecture in a particular regional setting, a series of steps must be taken to determine the work that needs to be done and the most suitable application of the PICNIC Open Source software components that PICNIC developed. The seven main steps comprise: • Initial project definition • Planning for implementation of the Architecture • Procurement of technical support and/or implementation resources • Design of the Technical Architecture and federated schema of RHCN data • Development of the middleware platform and integration of PICNIC components and legacy applications • Testing & verification of all elements of the RHCN • Deployment. Each of these steps is explained in the following paragraphs. 2. Initial Project Definition The first task is to define the Regional Health Economy that is going to be the organisational context for the establishment of the RHCN, by identifying the parties (i.e. the healthcare providers – hospitals, primary healthcare centres (PHCC), other caring agencies/institutions, funding bodies, healthcare planning/purchasing organisations, etc.) who want to collaborate by exchanging information to improve services to their patients & clients. These bodies need to make a formal agreement to work together to establish the

D. Piggott / How to Use the PICNIC Results

93

RHCN, including agreeing how the implementation costs are going to be funded. In a region with a single ‘main player’ organisation, such as a Regional Health Authority (RHA), this body can often take the lead and propose a funding model, but in regions where no such primacy exists, a ‘consortium’ needs to be formed, with a management structure which enables decisions to be taken effectively on such issues. The RHE should be bound together by the definition of a ‘Mission Statement’, which sets out the goals and objectives to be delivered via the means of the RHCN. Once the RHE has been defined and agreement has been reached to work together, the scope of the RHCN, in terms of its range of services and incorporation of legacy Enterprise applications, need to be defined and agreed. This also has to be formalised, to provide a sound basis for subsequent planning decisions. Lastly, a project team needs to be established, with a defined remit, budget and mandate for making certain decisions, to take forward the detailed work of planning & designing the RHCN. 3. Planning Phase In the planning phase, the first step is to identify the main features of the existing Regional IT systems & network and the IT services that are already provided through it. The strengths and weaknesses of the existing Regional IT systems & network need to be investigated and documented, so that the strengths can be built upon and the weaknesses addressed by specific elements of the new RHCN. The next step is to review in detail the functionality and outputs of the existing regional systems/IT services, and decide which PICNIC IT Services (and therefore, which PICNIC components) should be used in the new RHCN. Depending upon which organisations within the RHE currently provide these services, this may require some transfer of systems, services and functions from individual organisations within the RHE to a ‘shared service’ at overall regional ‘RHCN’ level, in order to provide and overall consistent service to all parties in the RHE with coherent mechanisms for providing security and authentication services. Following this review of regional IT systems, the next task is to identify the relevant Enterprise Applications used by the various organisations in the RHE. These can often be existing Hospital Information Systems (HIS) or Electronic Patient Records (EPR) systems, or alternatively, administrative systems (e.g. Stores systems or Billing systems) that need to be interfaced with a PICNIC IT Service to enable sharing of information across the RHE or access to regional resources such as the Regional Patient ID Service for access to or confirmation of unique patient identity (UPI) numbers. In parallel with the above, a major task is to decide how security will be handled. If necessary identify/review national legislation, regional protocols, existing security policy (-ies) in the RHE and available security solutions (e.g., PKI) that fit into the PICNIC infrastructure. The next important task is to decide on what technology platform the PICNIC Components will be run, by reviewing the options (e.g. Java, .Net, Corba) and the current platforms in use at the various bodies within the RHE. Often a hybrid platform will be needed, in situations for example where the larger administrative bodies are historically committed to Unix/Java based applications, whereas smaller entities, such as PHCC< have established systems based mainly upon Microsoft based applications. In these cases, the PICNIC middleware becomes the ‘glue’ which joins the two heterogeneous environments together. Another task is to decide how the servers that will deliver the PICNIC IT services will be configured, as this could be archived by one ‘central’ server/cluster, or could be several servers connected via intranet/internet, depending upon the volume and complexity of RHCN services that are required within the RHE. Based on the outcomes of these planning steps, the final tasks are to develop a detailed Project Plan, setting out timescales, deadlines and deliverables, plus a definitive Business

94


Case, detailing the costs and benefits of establishing the RHCN, to confirm the commitment of the RHE to the project and to underpin the subsequent implementation work. 4. Procurement Phase Following the planning phase, a decision has to be made on the extent to which technical support is required on the design, build, testing and deployment of the RHCN. Some larger RHA with extensive experience in large-scale IT systems implementation may be able to handle a large part of the design and build in-house, using their own resources or those available from across the RHE, but even these authorities may need assistance with the creation of a full RHCN encompassing major systems integration effort across multiple organisations involving state of the art, developing technologies such as web-services. A more common scenario across European RHEs is a requirement for technical assistance from a suitably qualified and resourced ICT systems & services vendor to help with the design of the RHCN and the building/testing of the middleware platforms and systems integration efforts. The first step, therefore, is to scope the nature and type of ICT support services required and draw up a Statement of Requirements that can be issued as an Invitation to Tender (ITT) to prospective suppliers through the means of a procurement. As it is likely that the scale of the required services will exceed the financial thresholds for procurement in Europe, the most likely procurement route would be a Services Directive procurement advertised by a Contract Notice published in the OJEC. Following the conclusion of the procurement, a contract can then be let with a vendor(s) to design, develop, test, implement and integrate the RHCN ‘system’, as required. 5. Design Phase The design phase, with or without the support of an ICT services supplier, encompasses two main steps, these being the design of an overall Technical Architecture for the RHCN, and the development of a ‘federated schema’ for the data to be exchanged between systems in the RHCN. The first step is to design the RHCN Technical Architecture, based on web services technologies, for both the RHCN IT Services and for the end-users, i.e., the users a of Enterprise Applications in RHE organisations through which the PICNIC IT Services will be accessed. This task will have to take into account key legacy systems, probable network loading, location of key functions using RHCN services, etc. The RHCN design will also have to take in account the range of RHCN services required, applicable PICNIC components, need for other components, etc., in order to provide the full range of services needed by the RHE. The next step is to design the ‘federated schema’ for the data to be used in the RHCN: It is necessary to identify the ‘export schema’ in the Domain Information Models/EntityRelation-Diagrams of each of the Enterprise Applications that needs to be integrated into the RHCN, and map these into a federated schema encompassing all RHCN shared data. The resulting schema is a Regional Data Model for the RHE, which should be crosschecked against the original RHCN mission statement goals and objectives to ensure that all of the original aims of the project can be fulfilled with the data available from the model. 6. Development Phase The development phase comprises the development of the regional middleware platforms, configuration of PICNIC components and development of interfaces between the RHE or-


95

ganisations’ Enterprise Applications and the RHCN middleware platform. Depending upon the status of the existing regional ICT network, it may also include the development of additional network links/capacity. The first task is to establish the operating environment for the RHCN middleware platform, including the initialisation of the PICNIC IT server(s). The next step is then to configure the PICNIC components, using the federated schema and local/national data, to form the PICNIC IT Services. Following this step, the next task is to configure the interfaces between the RHCN middleware platform and the Enterprise Applications using web-services technologies and integrate the Enterprise Applications with PICNIC IT services. Following this, we can then design, develop and update the functionality of the Enterprise Applications to make full use of the PICNIC IT services. The final task is then to integrate the new PICNIC IT services with the added-functionality Enterprise Applications. 7. Testing and Verification Phase The Testing & Validation phase covers the testing of the PICNIC IT Services in the RHCN and the testing of the whole integrated system encompassing both the RHCN services and the RHE Enterprise Applications. The first step is to test fully all services/components/ systems in the RHCN, using a comprehensive unit test, system test and acceptance test process. This testing should also include’ scenario tests’, where simulated user environments and utilised to test end-to-end business processes. Secondly, the scope of the testing is extended to cover the interfaces to the RHE Enterprise Applications and the functionality within the Enterprise Applications. Finally, we test and validate the whole process and all services/components/applications in the RHCN and ‘satellite’ Enterprise Applications. 8. Deployment Phase The Deployment phase comprises: • Piloting the new RHCN in a few real-time operational contexts • Operationalising the PICNIC IT services and roll-out into the RHCN • Enlarging the number of new applications using RHCN services. The fist step is to define a pilot the for the new RHCN, based on a defined business need and a single PICNIC IT service integrated with one or two Enterprise Applications. This will allow the benefits of the RHCN to become apparent whilst containing the level of technical complexity to allow for a reasonably rapid deployment of the pilot service in a few real-time operational contexts. Once the pilot has been proven, the lessons of the pilot deployment can be taken on board and any technical adjustments that may be needed made to the RHCN before large-scale deployment of the new RHCN services is commenced. The next step is to operationalise the PICNIC IT services and roll-out into the RHCN, usually on a phased basis, service by service, as determined by business needs, operational priorities and the level of technical complexity/risk involved. Finally, we can enlarge the number of new/enhanced Enterprise Applications using RHCN services. 9. Suggested Procurement Route The suggested tendering approach is to use the EU Services Directive Negotiated Procurement route to procure ICT Technical Assistance in the design, build, test and deployment of the RHCN. A model Contract Notice for this approach is shown in Inset A below, followed by a model Invitation to Tender for issue to prospective PICNIC ICT services suppliers, at Inset B below.

96


Inset A. – Model PICNIC ICT Support Services OJEC Contract Notice

EUROPEAN UNION Publication of Supplement to the Official Journal of the European Communities 2, rue Mercier, L-2985 Luxembourg Telefax: (+352) 29 29 44 619, (+352) 29 29 44 623, (+352) 29 29 42 670 E-mail: [email protected] On-line notification: http://simap.eu.int

CONTRACT NOTICE Works

Reserved for the Publication Office

Supplies Date of receipt of the notice __________________

Services X

Identifier _________________________________

Is this contract covered by the Government Procurement Agreement (GPA)?

NO

SECTION I: CONTRACTING AUTHORITY I.1) OFFICIAL NAME AND ADDRESS OF THE CONTRACTING AUTHORITY Organisation

For the attention of

The Regional Health Economy on behalf of: [list all RHE organisations]

RHE Chief Executive Officer

Address

Postal code

Town

Country

Telephone

Fax

Electronic mail (e-mail)

Internet address (URL)

I.2) ADDRESS FROM WHICH FURTHER INFORMATION CAN BE OBTAINED: As in I.1

⁪

See Annex A

If different, see Annex A

I.3) ADDRESS FROM WHICH DOCUMENTATION MAY BE OBTAINED: As in I.1

⁪

See Annex A


I.4) ADDRESS TO WHICH TENDERS/REQUESTS TO PARTICIPATE MUST BE SENT: As in I.1

⁪

See Annex A


I.5) TYPE OF CONTRACTING AUTHORITY*

⁪ Regional/local level X Central level

⁪ Body governed by public law X EU Institution

Other

YES


97

SECTION II: OBJECT OF THE CONTRACT II.1) DESCRIPTION II.1.1) Type of works contract ( in case of works contract)

⁪

Execution

Design and execution

⁪

Execution, by whatever means of a work, corresponding to the requirements specified by the contracting authority

⁪

II.1.2) Type of supplies contract ( in case of supplies contract )

⁪

Purchase

Rent

⁪

Lease

⁪

⁪ A combination of these

Hire-purchase

⁪

II.1.3) Type of service contract ( in case of service contract )

Service category 7 (Computer and Related Services) and 11 (Management Consultant Services and Related Services) II.1.4) Is it a framework agreement ?

NO

X

YES

⁪

II.1.5) Title attributed to the contract by the contracting authority * “PICNIC IT SEVICES Technical Implementation Support” II.1.6) Description/object of the contract (use continuation sheet if necessary ) Procurement of services for the support of RHE Project Team in Regional Healthcare Network Design, Build, Test and Deployment in accordance with the PICNIC Architecture and utilising PICNIC (and other) components, The Contracting authority wishes to award a contract, or a series of contracts, which may be divided into lots and sub-lots, to one or more suitably qualified firms (consultancy /systems integration/IT service provider) in respect of the provision of services as itemised above II.1.7) Site or location of works, place of delivery or performance Any of the premises of the organisations listed in Section I.1 above or such other locations as may be stipulated by the Contracting Authority. NUTS code. II.1.8) Nomenclature II.1.8.1) Common Procurement Vocabulary (CPV) *

Main object

Main vocabulary 74.14.10.00-9

Additional 72.00.00.00-5 objects 72.25.00.00-2 72.20.00.00-7 72.21.00.00-0 72.22.00.00-3 72.22.10.00-0 72.24.50.00-4 72.26.00.00-5

Supplementary vocabulary (when applicable)

Business and Management Consultancy Services Computer and Related Services System Maintenance and Support Services Software programming and consultancy services Programming services of packaged software products Systems and Technical Consultancy Services Business analysis consultancy services Contract systems analysis and programming services Software-related services

98


II.1.8.2) Other relevant nomenclature (CPA / NACE / CPC) ___________________________________ II.1.9) Division into lots (for details about lots use Annex B as many times as needed) NO

⁪

YES

X

Tenders may be submitted for:

one lot

X

several lots

X

all lots

X

II.1.10) Will variants be accepted (where applicable) NO

⁪

YES

X

However, Contracting Authority reserves the right to decline variants II.2) QUANTITY OR SCOPE OF THE CONTRACT II.2.1) Total quantity or scope (including all lots and options, if applicable)

Approximately €X to €Y million per annum. II.2.2) Options (if applicable). Description and time when they may be exercised (if possible)

N/A II.3) DURATION OF THE CONTRACT OR TIME LIMIT FOR COMPLETION Either: Period in month/s: minimum X (estimated) with a Contracting Authority option to extend,

⁪⁪⁪ (from the award of the contract) Starting ⁪⁪/⁪⁪/⁪⁪⁪⁪ and/or ending ⁪⁪/⁪⁪/⁪⁪⁪⁪

and/or days

Or: (dd/mm/yyyy)

SECTION III: LEGAL, ECONOMIC, FINANCIAL AND TECHNICAL INFORMATION III.1) CONDITIONS RELATING TO THE CONTRACT III.1.1) Deposits and guarantees required (if applicable) Legal, financial and performance related security may be required by the Contracting Authority prior to award of contract(s). Further details available in Tender Documentation. III.1.2) Main terms of financing and payment and/or reference to the relevant provisions (if applicable) See Tender Documentation III.1.3) Legal form to be taken by the grouping of suppliers, contractors or service providers to whom the contract is awarded (if applicable) Whilst no particular legal form is required, at this stage, if any bids are submitted from a group of firms, the Contracting Authority has the right to request an explanation from any such group, in terms of the relationships defined within any such grouping and how it will be structured and managed. Such groups must identify a lead contractor with whom the Contracting Authority will liaise. III.2) CONDITIONS FOR PARTICIPATION III.2.1) Information concerning the personal situation of the contractor, supplier or service provider and information and formalities necessary for the evaluation of the minimum economic, financial and technical capacity required Candidates must submit the evidence of economic, financial and technical capacity required for qualification stage, in a formal Expression of Interest document, setting out their responses to the information requirements as set out in Section III.2.1.1, III.2.1.2 and III.2.1.3 below. Three copies of all the information and one electronic copy must be submitted before the deadline to


99

the contract address set out in Annex A. The information of economic, financial and technical capacity required for qualification stage as set out in Section III.2.1.1, III.2.1.2 and III.2.1.3 must be submitted in respect of :(i) each Candidate; and (ii) where a Candidate comprises a consortium or grouping of bidders, each member of the Candidate consortium; and (iii) each sub-contractor All information must be submitted in English or accompanied by an English translation. Any questions in relation to evidence of economic, financial or technical criteria should be submitted to the contact listed in Section I.1. A minimum number of three tenderers may be invited to negotiate. III.2.1.1) Legal position – means of proof required Proof of legal status of the candidate must be submitted as may be reasonably required by the Contracting Authority, (for example evidence of a current certificate of incorporation). III.2.1.2) Economic and financial capacity – means of proof required Candidates are required to submit the following information: a) audited accounts for the last three financial years; b) any relevant financial statements or reports for the last three years; c)

written confirmation that the bidder is not subject to any of the conditions set out in Article 29 of the Services Directive (92/50/EEC as amended);

d) evidence of insurances (including inter alia professional indemnity insurance; public liability insurance; employer’s liability insurance); e)

copy of tax clearance certificate.

III.2.1.3) Technical capacity – means of proof required Candidates are required to submit in writing the following information: a) a statement of technical capacity and abilities in the area for which services are sought including: (i)

details of the total numbers of suitably skilled and experienced consultants employed or retained by the Candidate in respect of each category of services as defined in Section II.1.6;

(ii)

the numbers, capabilities and skills of the consultants available to undertake the Services as set out in Section II.1.6, details of the relevant experience of the consultants (together with CVs) nominated to undertake the Services, whether or not the proposed consultants are employees of the bidder or sub-contractors and a list of all suitably experienced consultants and identifying each consultant’s relevant experience,

(iii)

b) a statement of the amount of the services which the Candidate intends to sub-contract and the list of names and addresses of sub-contractor(s) together with relevant experience of sub-contractor(s); c)

a list of all relevant major contracts won by the Candidate and its sub-contractor(s) (awarded by public and private bodies) and the value thereof for the last three years highlighting: (i)

previous experience of PICNIC/RHCN implementation

(ii)

other major consulting projects in the public and health sectors;

(iii)

the role of the Candidate (and/or sub-contractor(s)) in each project; and

(iv)

the current status of each project,

d) any recent independent research reports on the Candidate and/or sub-contractor(s) (e.g. Gartner, Forrester); and

100


e)

a statement as to whether any legal proceedings or claims have issued or are pending against the Candidate and/or sub-contractor(s) in the last five years in relation to consultancy services generally and PICNIC related services, in particular, including details of any proceedings or claims settled.

III.3) CONDITIONS SPECIFIC TO SERVICES CONTRACTS III.3.1) Is provision of the service reserved to a specific profession? YES ⁪ NO X If yes, reference of the relevant law, regulation or administrative provision III.3.2) Will legal entities be required to state the names and professional qualifications of the personnel responsible for execution of the contract? NO

⁪

YES

X

SECTION IV: PROCEDURE IV.1) TYPE OF PROCEDURE

⁪ ⁪ X

Open Restricted Negotiated

Accelerated restricted Accelerated negotiated

⁪ ⁪

IV.1.1) Have candidates already been selected? (for negotiated procedure only and if applicable) NO

X

YES

⁪

If yes, provide details under Other information (section VI)

IV.1.2) Justification for the choice of accelerated procedure (if applicable) N/A IV.1.3) Previous publication concerning the same contract (if applicable) Not applicable IV.1.3.1) Prior information notice concerning the same contract (if applicable) Not applicable Notice number in OJ content list

[INSERT PIN NO/DATE]of

⁪⁪/⁪⁪/⁪⁪⁪⁪ (dd/mm/yyyy)

IV.1.3.2) Other previous publications Notice number in OJ content list

⁪⁪⁪⁪/S ⁪⁪⁪-⁪⁪⁪⁪⁪⁪⁪ of ⁪⁪/⁪⁪/⁪⁪⁪⁪ (dd/mm/yyyy)

IV.1.4) Envisaged number of suppliers which will be invited to tender (when applicable) Number

⁪⁪

or:

Minimum

3

/ Maximum

⁪⁪

IV.2) AWARD CRITERIA A) Lowest price or

⁪

B) The most economically advantageous tender in terms of: X B1) Criteria as stated below (in descending order of priority where possible) ⁪ 1 Experience

4 Quality of Approach

2 Price

5 Capacity to deliver


3 Proposed Timescales for delivery

101

6 Response times

and such other criteria as may be set out in the tender documentation In descending order of priority : or:

NO

B2) Criteria as stated in contract documents

X

YES

⁪

X

IV.3) ADMINISTRATIVE INFORMATION IV.3.1) Reference number attributed to the file by the contracting authority * IV.3.2) Conditions for obtaining contract document and additional documents

⁪⁪/⁪⁪/⁪⁪⁪⁪

Obtainable until

(dd/mm/yyyy)

Price (where applicable) _____________________ Currency ________________________________ Terms and method of payment ___________________________________________ IV.3.3) Timelimit for receipt of tenders or requests to participate (depending whether it is an open, restricted or negotiated procedure)

NEGOTIATED PROCEDURE (dd/mm/yyyy)

or

days from dispatch of notice

Time (when applicable): IV.3.4) Dispatch of invitations to tender to selected candidates (In restricted and negotiated procedure) Estimated date :

(dd/mm/yyyy)

IV.3.5) Language or languages in which tenders or requests to participate can be drawn up ES

DA

DE

EL

⁪

⁪

⁪

⁪

EN

FR

IT

NL

PT

FI

SV

Other (s) – third country

⁪

⁪

⁪

⁪

⁪

⁪

___________________

IV.3.6) Minimum time frame during which the tenderer must maintain its tender (in case of an open procedure) Until

⁪⁪/⁪⁪/⁪⁪⁪⁪

(dd/mm/yyyy) or

⁪⁪⁪

12 months and/or days from the deadline stated for receipt of tenders

IV.3.7) Conditions for opening tenders IV 3.7.1) Persons authorised to be present at the opening of tenders (where applicable) IV.3.7.2) Date, time and place Date Place

⁪⁪/⁪⁪/⁪⁪⁪⁪

(dd/mm/yyyy)

Time: __________________________

102


Inset B. – Model Statement Of Requirements For Picnic ICT Support Services PICNIC ICT SUPPORT SERVICES MODEL INVITATION TO TENDER

1. INTRODUCTION This Invitation to Tender (ITT) for the provision of PICNIC Technical support consultancy services for Regional Health Economy (RHE) for and on behalf of its constituent healthcare organisations. The RHE comprises those organizations listed at paragraph 2.1.b. Tenderers should submit their tenders, listing their responses to the ITT requirements, in accordance with the instructions on the submission and format of tenders as set out in Section 3 of this ITT. Tenders will be evaluated in accordance with the evaluation criteria set out in Section 4 of this ITT. Tenderers may, at the discretion of the RHE, be asked to present their tenders to an Evaluation Team, which will then assess the Tenderers on the basis of their tenders and presentations. This ITT comprises:•

Section 1 – Introduction;

•

Section 2 – Statement of Requirements;

•

Section 3 – Submission and Format of Tenders;

•

Section 4 – Evaluation Criteria.

2. STATEMENT OF REQUIREMENTS 2.1. Project Scope The definition of the project scope set out below is based on the goals and objectives of the project and its interrelations with the other strategic projects ongoing in the RHE. The scope of the PICNIC IT SERVICES implementation covers the following business functions, organisations and technical components: a) Business Functions: The scope of PICNIC IT SERVICES support contract encompasses the implementation of a Regional Health Care Network (RHCN) and integration with supporting IT systems and standard business practices, including inter alia the following functions: • [insert list of RHE business functions]. b) Organisations The scope of the PICNIC IT SERVICES implementation covers all of the health agencies within the RHE, encompassing the following: • [insert list of RHE organisations]. c) Technical Components In terms of the components to be implemented under the auspices of PICNIC IT SER-


103

VICES, and other technical aspects of the project, which will be delivered by the PICNIC IT SERVICES supplier, these are currently defined as: PICNIC Components •

Shared Records Indexing Service (SRIS)

•

Shared Records Update Broker (SRUB)

•

Clinical Observation Access Service (COAS)

•

Patient Identity Service (PIDS)

•

Collaboration Service (COLS)

•

Resources Service (RESS)

•

Clinical Document Architecture XML DTDs (XMLS).

Additional Components {insert other components required, e.g.} • • •

OpenLDAP Jabber Apache

Other Technical Components • • •

Integration with other RHE regional IT systems/networks Integration with RHE legacy applications Development of data standards, a regional data model and common coding structures

2.2. Technical Implementation Partner Scope The scope of the PICNIC IT SERVICES PICNIC consultancy covers: • • • • • • • • • • • • • • • • • •

Design Business Process Design Technical Architecture Design Regional Data Model Design Component Configuration Development Reports Enhancements Interfaces Data Conversions Upgrades Build Testing Deployment Security Training End-user Training Technical Training.

104


2.3. Consultancy Support Requirements The requirements for consultancy support for each of these key areas is set out below: 2.3.1.

The overall requirement is for the PICNIC IT SERVICES contractor to support the delivery of the technical components of the PICNIC IT SERVICES Programme of Work*, in accordance with the project plan/timetable and the project/PICNIC scope defined at para 2.2 above. State your understanding and acceptance of this requirement. *NB1. The PICNIC IT SERVICES Programme of Work comprises the following elements: planning, specification, pilot (system build, test and deployment in one agency), roll-out of all services to all RHE agencies.

2.3.2.

Support is required for PICNIC IT SERVICES in accordance with a defined project management structure. The PICNIC IT SERVICEC supplier will be included in an integrated ‘PICNIC IT SERVICES National Project Team’, comprising RHE and PICNIC IT SERVICES supplier staff, organised into a project structure covering the main functional and technology delivery areas. The PICNIC IT SERVICES supplier will provide a Technical Manager (TM) who will report to the overall RHE Project Manager. State your understanding and approach to working in this organizational structure.

2.3.3.

The PICNIC IT SERVICES Programme of Work should be delivered in accordance with the defined project phasing. The PICNIC IT SERVICES supplier should undertake the system configuration, testing and deployment of the PICNIC IT SERVICES in the RHCN as defined in the Project Plan. Outline your approach to undertaking these tasks.

2.3.4.

In addition, Tenderers should quote for an option for a further phase at the end of the programme to support the transition from existing RHE IT support structures to a shared service based operation within the new RHCN structure. State your understanding and tendered offering in relation to this requirement.

2.3.5.

The work of the PICNIC IT SERVICES supplier will include support on the development of a Technical Architecture for the RHCN. State your understanding and tendered offering in relation to this requirement.

2.3.6.

The work of the PICNIC IT SERVICES supplier includes the configuration of all PICNIC & other components modules as listed above. The Tenderer is required to outline their approach to undertaking this component configuration.

2.3.7.

The work of the PICNIC IT SERVICES supplier will include the development, testing and implementation of specified interfaces, data conversions and components (PICNIC and other). State your approach to delivering this requirement.

2.3.8.

The work of the PICNIC IT SERVICES supplier will also include the configuration, testing and documentation of appropriate security mechanisms to support the work of the RHCN. State your approach to delivering this requirement.

2.3.9.

The work of the PICNIC IT SERVICES supplier will also include Data Migration tasks, including: • •

Conversion of existing RHE data to the RHE Data Model standards Migration of data from legacy systems.


105

State your approach to delivering this requirement. 2.3.10. Support is required for a range of training and education tasks within the overall PICNIC IT SERVICES implementation programme. The Tenderer is required to specify a training model/approach to training development, including end-user training and technical training. 2.3.11. At the conclusion of the Pilot RHCN Service build, test and deployment phase, there will be a formal ‘User Assurance Test’ process to ensure that the system meets the PICNIC IT SERVICES Business & Technical requirements (as defined in the RHCN Functional & Service Specification) prior to being rolled out to other RHE agencies. The PICNIC IT SERVICES supplier will be responsible for the coordination and direction of this UAT, under the overall management and direction of the project by the RHE. The PICNIC IT SERVICES supplier will be responsible for the organization and coordination of RHE staff participating in the UAT process. The PICNIC IT SERVICES supplier will be responsible for the execution of the UAT, documentation of the outcome and reporting on progress and results to the SIP. State your approach to delivering this task.

3. SUBMISSION & FORMAT OF TENDERS 3.1. Submission of Tenders THE CLOSING TIME/DATE FOR RECEIPT OF TENDERS IS: [insert time/date for responses]. Please note that any Tender received after this date/time will not be considered. The Tender shall be fully responsible for the delivery of the Tender. The RHE does not bind itself to the Tender with the lower stated Tender Sum or indeed any Tender. The RHE will not pay any compensation, costs or expenses whatsoever in connection with the preparation and/or submission of the Tender. 3.2. Tender Format Tenderers must structure their tenders in accordance with the following main headings: 1 Management Summary; 2 Introduction; 3 PICNIC IT Services 3.1

Overview/General

3.2

Design

3.3

Component Configuration

3.4

Testing & Validation

3.5

Deployment

3.6

Training

4 Pricing. Sections 3 of the Tender must contain responses to the tender requirements listed in Sections 2 of the ITT, in the same sequence and cross-referenced to the ITT numbering

106


scheme. Section 4 of the Tender (Pricing) must contain responses to the tender requirements listed in Section 2.9 of the ITT, in the same sequence and cross-referenced to the ITT numbering scheme. Tenders must be free-standing documents and not crossreferenced to other sources. Tenderers should note that non-compliant tenders may not be considered. The decision of the RHE on this matter will be final.

4. EVALUATION CRITERIA Tenders received in response to this ITT will be evaluated and shortlisted on the basis of providing the most economically advantageous solution, taking into account the following criteria, not necessarily listed in order of importance: • Degree of fit of the tendered PICNIC consultancy support to the PICNIC IT SERVICES requirements; • Suitability of the project plan and implementation approach in responding to the needs/priorities of the RHE; • Overall cost of the proposed solution; • Understanding of the scope of the required PICNIC IT SERVICES support; • Experience of tendered team on similar projects in the past.

PICNIC Components The PICNIC components can be downloaded from the PICNIC Open Source website (https://forge.euspirit.net/projects/picnic/) or the PICNIC project website (www.medcom. dk/picnic), and comprise the following components: • • • • • • •

Shared Records Indexing Service (SRIS) Shared Records Update Broker (SRUB) Clinical Observation Access Service (COAS) Patient Identity Service (PIDS) Collaboration Service (COLS) Resources Service (RESS) Clinical Document Architecture XML DTDs (XMLS).

Each component is included in a zip file, together with its OS license and installation documentation.

PICNIC Consultancy Guidance on the use of PICNIC components and application of the PICNIC Architecture is obtainable from a number of PICNIC partners and advisers, including, inter alia: • • • •

The Danish Centre for Health Telematics, Denmark (www.medcom.dk) VTT Information Technology, Finland ([email protected]) Minoru, France ([email protected]) FORTH, Institute of Computer Science, Greece ([email protected])


• • •

Erasmus University, The Netherlands ([email protected]) Hewlett Packard, Ireland ([email protected]) Integrity Consulting Partners, UK ([email protected]).

107

108


Canada Health Infoway – Towards a National Interoperable Electronic Health Record (EHR) Solution Dennis GIOKAS Chief Technology Officer, Canada Health Infoway Inc., Montreal, Canada Abstract. Canada Health Infoway Inc. (Infoway) is leading Canada’s initiative to develop interoperable electronic health records (EHRs) and accelerate their adoption nationwide. Specifically, Infoway’s core business is to invest with its partners— primarily provincial and territorial governments—in the development of robust, interoperable EHR solutions and in their deployment and replication across Canada. This partnership approach produces results faster, more cost-efficiently and more effectively than if any one partner acted alone. This chapter presents a high-level view of Infoway’s seven-year plan to have the basic elements of interoperable EHRs in place across 50 percent of Canada by the end of 2009. In particular, the chapter discusses the business and technical approaches that have been developed to pursue Infoway’s aggressive goal. These approaches allow individual jurisdictions to deliver local and regional solutions costeffectively while contributing to a larger, interoperable national system.

1. Introduction 1.1. Scope and Objectives This chapter describes Canada’s initiative to develop and deploy an interoperable, secure, and pan-Canadian electronic health record (EHR) solution. Though Infoway and its partners are designing the solution to work within the administrative realities of the Canadian healthcare system, the business and technical approaches we have adopted are attracting international recognition and interest. The objectives of this chapter are, therefore, (1) to share what Infoway has learned to date about the development and deployment of practical EHR systems, and (2) to describe how Infoway is organizing for future challenges. The chapter begins with a brief description of healthcare delivery in Canada and its challenges. This backdrop provides the context and motivation for the government’s creation of Canada Health Infoway (Infoway), an independent corporation with a unique mandate: to exploit information technology to improve the quality, access and timeliness of healthcare. This section also describes how Infoway has been uniquely organized to address these objectives and ensure success across multiple jurisdictions with varying priorities. This introduction is followed by a detailed view of the business requirements and technical architectures that have been developed to guide Infoway’s investments. Finally, the last section describes Infoway’s view of how the elements of electronic healthcare information systems will roll out to deliver an increasingly efficient and effective healthcare system.

D. Giokas / Canada Health Infoway

109

1.2. The Canadian Healthcare System Since 1968, Canada has had a predominantly publicly financed healthcare system. The national health insurance program is fulfilled through 14 interlocking provincial and territorial plans, linked through adherence to national principles set at the federal government level. The system is designed to support over 31 million people where roughly 20% live in rural and remote areas. The Canada Health Act [1] of 1968, established through federal legislation, provides national criteria and conditions related to insured healthcare services and extended healthcare services that the provinces and territories must meet in order to receive the full federal cash contribution under the Canada Health and Social Transfer (CHST). The aim of the Canada Health Act is “to protect, promote and restore the physical and mental well-being of residents of Canada and to facilitate reasonable access to health services without financial or other barriers.” Five important principles are embodied in the Act: 1. Public Administration: The administration and operation of the healthcare insurance plan of a province or territory must be carried out on a non-profit basis by a public authority responsible to the provincial/territorial government and subject to audits of their accounts and financial transactions. 2. Comprehensiveness: The health insurance plans of the provinces and territories must insure all medically necessary health services (insured services — hospital, physician, surgical-dental) and, where permitted, services rendered by other healthcare practitioners. 3. Universality: All insured persons in the province or territory must be entitled to 4. public health insurance coverage on uniform terms and conditions. Provinces and territories usually require that residents register with the plans to establish entitlement. 5. Portability: Residents moving from one province or territory to another must continue to be covered for insured health services by the home province during a minimum waiting period, not to exceed three months, imposed by the new province/territory of residence. Residents temporarily absent from their home provinces or territories, or from the country, must also continue to be covered for insured healthcare services. 6. Accessibility: Reasonable access by insured persons to medically necessary hospital and physician services must be unimpeded by financial or other barriers, such as discrimination on the basis of age, health status or financial circumstances. Reasonable access in terms of physical availability of medically necessary services has been interpreted under the Canada Health Act as access to insured healthcare services in the setting where services are provided and as services are available in that setting. Although, the federal Canada Health Act establishes standards related to insured healthcare and extended healthcare services, it is the responsibility of Canada’s jurisdictional governments—14 provinces, territories, and federal government—to actually deliver these services. To ensure conformance, the federal government helps fund the jurisdictional healthcare system only if the jurisdiction is in compliance with the Act. The provinces and territories plan, finance (with federal funding assistance) and evaluate the provision of hospital care, physician services, public health and some aspects of prescription care. This system of federal governance and provincial delivery is called Medicare. The aim of Medicare is to ensure all eligible residents of Canada have reasonable access to medically necessary insured services on a prepaid basis, without direct charges at the point of service.

110


1.3. Healthcare Challenges In April 2001, a commission of inquiry was launched to assess the future of Canada’s public healthcare system, and to recommend policies and measures respectful of the jurisdictions and powers in Canada required to ensure the sustainability of a universally accessible, publicly funded health system over the long term. The results were captured in the Romanow Report [2], November 2002, which highlighted the following issues: • •

•

•

Without changes, the current Medicare system is unsustainable. Faced with escalating costs, an increasingly aging population and scarce financial resources, the system must find better ways to deliver healthcare if it is to survive. The Medicare system needs to expand its focus. In the early days, Medicare could be summarized in two words: hospitals and doctors. That was fine for the time, but it is not sufficient for the 21st century. Despite the tremendous changes over the past 40 years, Medicare still is largely organized around hospitals and doctors. Today, however, home care is an increasingly critical element of Canada’s health system, e.g. day surgery has replaced the procedures that once took weeks of convalescence in hospital. Drugs, once a small portion of total health costs, are now escalating and among the highest costs in the system. The system must evolve to be more inclusive of all components of healthcare requiring more sophisticated tracking and accountability. The Medicare system needs to be more integrated and coordinated. Canada must transform its healthcare system from one in which a multitude of participants, working in silos, focus primarily on managing illness to one in which practitioners work collaboratively to deliver a seamless, integrated array of services to Canadians— from prevention and promotion to primary care, hospital, community, mental health, home and end-of-life care. Accountability and progress will depend on better information. Information is a key ingredient. Better information will facilitate evidence-based decision making. There is a need to accelerate the integration of health informatics, to provide for a secure electronic health record infrastructure for Canadians that respects their right to privacy and gives them greater input into shaping the system’s future.

2. The Creation of Canada Health Infoway 2.1. The Political Impetus By the late 1990s, several provincial reports were advocating the need for a compatible, integrated system of health records to be developed on a priority basis. The Fyke Commission [3], as an example, stated: “The electronic health record is the cornerstone of an efficient and responsive healthcare delivery system, quality improvement and accountability.” These reports also recognized that the few electronic information initiatives that were in place were standalone investments: each attempted to solve one problem, at one time, in one place. Against this backdrop, in September of 2000, the First Ministers unanimously agreed “to work together to strengthen a Canada-wide health infostructure.” They committed to developing electronic health records, including the enhancement of technologies such as Telehealth, and the development of common data standards to ensure compatibility of health information. In doing so, they acknowledged the dramatic benefits that flow from timely access to current, accurate and complete information.


111

Extensive consultation and negotiation ensued. The result was the creation of an independent, not-for-profit corporation called Canada Health Infoway Inc. (Infoway). Infoway was launched in late 2000 with an initial investment of $500M (all dollars in CDN). The memorandum of understanding between the federal government and Infoway along with the Infoway business plan [4] approved in June 2002 set the framework for how the money would be invested. In February 2003, the First Ministers decided to expand Infoway’s mandate to include Telehealth, recognizing that effective Telehealth services require strong EHR solutions as the foundation. This was supported with $100M in funding. At the same time they funded Infoway with an additional $500M (CDN) to accelerate the development and deployment of the EHR. Recognizing the role information technology can play in controlling infectious disease outbreaks, brought to light following the SARS crisis, the federal government provided Infoway with $100 million for a new Public Health Surveillance mandate in June 2004. 2.2. Focus on EHRs Healthcare professionals make clinical decisions based on knowledge. Access to relevant and reliable clinical information is critical to this process. In fact, information is the lifeblood of an effective healthcare system. To ensure the best possible care, the information must be accurate, up-to-date, available and accessible whenever needed by those who provide healthcare services. Furthermore, interoperable EHR solutions help to break down the silos of information between providers as well as between services delivered by a single provider. An EHR is the ideal way to accumulate and structure patient-centric clinical data. It can then be queried to find the patient information relevant to a specific point of care and provider. By breaking down the information silos that currently exist, EHRs provide integrated patient-centric clinical information that extends beyond the walls of any one healthcare setting to support the fundamental 5R’s of clinical decision-making: • • • • •

The right information About the right patient Available to the right person In the right place At the right time

The EHR supports coordinated patient assessment, improves patient safety, and facilitates the identification of potential and real health risks. Comprehensive EHR systems also provide decision-makers and health managers with the extensive data they need to plan and allocate resources appropriately and efficiently. Furthermore, EHRs provide the opportunity for health organizations to accumulate vast amounts of structured patient-centric data that can be used to better track trends and issues in the overall healthcare system and health of its client populations. The EHR can facilitate the referral process by supporting the interoperability of information between points of care that ensure levels of speed, accuracy, completeness, reliability and clarity never before achievable. Finally, the EHR can enable decision support (not decision making) by applying validated scientific and businessoriented rules to patient information. For all these reasons, Infoway’s focus is on the development and deployment of interoperable EHRs across Canada. Today, many systems store clinical data electronically. These systems have data repositories often called EMRs (electronic medical records) in primary care settings, and CDRs (clinical data repositories) in acute care settings. These data repositories tend to have the following characteristics:

112


• • • •

Store operational data within the clinical system they support. Are provider-centric or organization-centric, not patient-centric. Support the data needs and functional requirements of a specific provider or healthcare organization type—for example, acute care versus general practitioner, versus nurse, versus pharmacist. Are configured such that data is not interoperable or sharable across the continuum of patient care or across providers’ organizational boundaries.

In contrast, an interoperable EHR is designed to: • • • •

Provide longitudinal records of clinical data and encounter information. Be patient-centric. Support access to patient information by any authorized individual, anytime, from anywhere. Structure data to support various providers of care, contexts of care and disease classes; it is conceptualized as a multi-dimensional data store that can be queried on any number of dimensions (including time) with whatever clinical application a provider is using.

Infoway is organizing itself and supporting programs to deliver this value to Canadians. The following sections describe how. 2.3. Timing Many factors converged to strongly suggest the timing was right to launch an EHR initiative. Budget pressures had caused a perceivable decline in the quality of healthcare delivery. In response, the Canadian public demanded a more accessible, responsive and efficient system. In particular, to achieve this, they asked for greater collaboration among the various jurisdictions. Concurrently, elements of healthcare technology were maturing, along with the deployment of more powerful and robust computing and communications infrastructures. Administrators, providers and patients alike were growing more attuned to the technology that had become available, and were beginning to understand the value such technology could generate. All these factors contributed to the creation of a strong political will to allocate funding toward the exploitation of new technology in a more collaborative environment. As a result Infoway was launched to foster and accelerate the development and adoption of electronic health information systems. 2.4. Mandate and Organizational Structure Canada Health Infoway has a unique mandate: To foster and accelerate the development and adoption of electronic health information systems with compatible standards and communication technologies on a pan-Canadian basis, bringing tangible benefits to Canadians.

This mandate not only represents a formidable technical challenge, but also an organizational one since, as mentioned above, the responsibility for healthcare delivery in Canada has devolved to the fourteen Canadian provincial and territorial jurisdictions. The response to this challenge was the establishment of a partnership between the fourteen Deputy Ministers of Health from all jurisdictions. Each member has an economic and vested interest in supporting Infoway’s success by ensuring the corporation’s federally provided funds are best leveraged across their individual jurisdictions. The structure of Infoway reflects a deliberate attempt to create an entity responsible for implementing the common goal held by the various levels of government in a collaborative,


113

cost-effective and timely manner. Infoway is organized around three basic principles defined in its funding agreement and endorsed by all member governments: 1. The collaboration of each member jurisdiction is required on an equal basis. 2. Each member has an administrative role in Infoway. 3. No individual member or jurisdiction has a priority administrative role. These principles of shared accountability are reflected in Infoway’s structure and operations. Specifically, this means that Infoway membership is restricted to the federal, provincial and territorial Deputy Ministers of Health, who represent their respective governments. 2.5. Accountability Infoway is equally accountable to its fourteen jurisdictions. The measures of accountability are consistent with good corporate governance and reflect the unique multi-jurisdictional structure of the corporation. In addition to standard reporting requirements such as financial audits and annual reports, several elements have been added: • • • •

At least every five years, an independent third-party evaluation will be conducted to measure overall performance in achieving the outcomes identified in the funding agreement. An annual compliance audit will be undertaken specific to the terms and conditions of the funding agreement with the Government of Canada, and the findings reported to all Infoway members. Under the terms of the funding agreement, project default provisions have been established, including a reimbursement requirement. Infoway has adopted a ‘gated funding’ approach commonly found in private enterprise; this means funds are only dispersed once pre-established milestones are met.

3. Infoway’s Business Model Infoway’s corporate objective is to have the basic elements of interoperable EHR solutions in place across half of the country (by population) by the end of 2009. This section outlines the business strategy and operational approach Infoway has developed to meet this objective. Recognizing the complexity of accelerating EHR solution development, and with no fool-proof solutions or guidelines to ensure success, Infoway’s strategy will continue to be dynamic and will be adjusted in response to learning and experience. 3.1. Business Strategy Infoway’s strategy consists of six complementary elements: 1. Target strategic investment programs: Infoway has identified nine program areas for investment. These include the first six key building blocks of EHR solutions: Registries, Interoperable EHR (clinical data across the continuum of care), Drug Information Systems, Diagnostic Imaging Systems and Laboratory Information Systems, and Public Health. The seventh program is Telehealth (a channel for healthcare delivery) with a focus on Tele-medicine, Tele-homecare, Tele-learning, and Tele-triage. The eighth program is Infostructure (architecture and standards) which along with Registries are foundational programs, for without them interoperable EHR solutions and seamless sharing of information would be impossible. The ninth program is Innovation and Adoption, which focuses on end users and technical in-

114


2.

3.

4.

5.

novations that are complementary to Infoway’s mandate. Each investment program will have many projects. Leverage investments: Infoway’s success will be measured by the extent to which it leverages its investments to maximize benefits to its member jurisdictions. Accordingly, Infoway’s approach builds on existing initiatives and invests in solutions for reuse so they can be replicated and deployed in other jurisdictions across the country. This approach (further detailed in Section 3.5) drives down costs and shortens implementation cycles. Collaborate with health ministries and other partners: Acceleration of EHR solution development is truly a collaborative effort. Infoway’s investments have been closely aligned with the priorities and objectives of health ministries and other public sector partners. These stakeholders are the builders and implementers of technology solutions. Strategic planning is therefore an essential element of Infoway’s strategy—to align investment programs with each jurisdiction’s EHR strategies. Infoway’s planning approach entails initial consultations to clarify jurisdictional EHR strategies and priorities, and to identify mutual areas of interest. Detailed planning determines how best to deploy solutions and plan for investment in a specific jurisdiction. In 2004, Infoway undertook a major collaborative three-year planning exercise with provinces and territories resulting in a collectively defined investment strategy. Develop strategic alliances with the private sector: Effective alliances with the private sector will help Infoway to better leverage its investments and to better align Infoway’s strategies and the business directions of the IT industry. Infoway influences market dynamics and creates mutually beneficial arrangements in several ways. For example, its investments create market demand for health information systems, increase opportunities for sales of technology and services, and influence solution and application development. Furthermore, Infoway’s emphasis on interoperability and vendor-neutral architecture and standards ensures a more inclusive marketplace for potential IT partners. Infoway’s strategy of promoting reusable assets benefits both IT vendors and Infoway partners. Solutions that can be replicated across the country offer IT vendors the potential for repeat sales. This approach also creates opportunities for Infoway’s partners to leverage scale to reduce costs or obtain upfront financing from vendors and suppliers. In this context, Infoway is helping the industry align their solutions with Infoway’s architecture and standards. Section 4 provides a deeper understanding of the values of establishing a common architectural framework. Focus on end-user acceptance: Giving healthcare professionals the tools and information they require to provide quality care is not enough: they first need support to help them integrate the technology into their regular activities. Consequently, Infoway—through its partners and investments—engages healthcare professionals during both the design and implementation of EHR solutions. This promotes a better understanding of the organizational and behavioural changes required for the successful introduction of new technology. This process is formally known as Change Management, and is critically linked to technology development. As a result, Infoway is investing considerably in change management initiatives. Indeed every technology program has a complementary change management component. In Canada, this approach is a major factor in increasing the success of healthcare information technology programs. In addition, Knowledge Transfer activities are embedded in all Infoway investments to facilitate the identification, capture and dissemination of project informa-


115

tion and best practices. Facilitating knowledge-sharing with those involved in the design, implementation and use of EHR solutions accelerates overall progress. Finally, every initiative must generate real value—measurable benefits—for the end-user, the healthcare client and the healthcare system. To ensure this is true of all Infoway projects, a formal benefits evaluation is built into every program. At a minimum, solutions should deliver healthcare efficiencies (better use of resources and of provider’s time); improve accessibility to patients; improve the quality of care and healthcare outcomes (through services such as computerized physician order entry, access to relevant clinical data, and decision support); and ensure patient safety (through services such as drug utilization review). 6. Invest with public sector sponsors: All Infoway investment projects must have a public sector sponsor that contributes financially to the project. This approach enhances accountability and success by ensuring that both Infoway and its partners jointly share the project’s risks and rewards. It also allows Infoway to maximize its investment capital and reward early adoption through tiered funding (discussed further in Section 3.6). The public sponsor leads the development and implementation, with Infoway playing the role of Strategic Investor (see Section 3.3). 3.2. Program Priorities Infoway’s business plan focuses on nine strategic investment areas, described below. They are the culmination of extensive consultations, collaboration and research with stakeholders across the country in every jurisdiction and throughout the healthcare system. Collectively, these priorities will move the healthcare system towards a comprehensive, interoperable EHR and, in turn, support a wide range of existing and future applications. The first two programs ensure interoperable EHR solutions. The focus on interoperability is across the continuum of care, within jurisdictions and across the country. 1. Interoperable EHR program has three objectives. First, it is made up of the EHR itself, a software solution including a database system, which will hold clinically important data needed across the continuum of care. By way of example, this data repository will hold a person’s health profile: encounter information, health history, family history, problem lists, referral notes, discharge abstracts, and immunizations. Secondly, it is the collection of common and reusable components in support of a diverse set of health information applications. It is referred to as the Health Information Access Layer (HIAL) further described in Section 4.3. The HIAL consists of software components, data definitions (data models, nomenclatures, vocabularies, coding standards) and messaging standards for the EHR. It focuses on reducing integration costs by defining a common solution architecture, common services and a set of integration and interoperability standards. Solutions associated with infostructure help to ensure the interoperability of systems and the reuse of common components. Third, there is investment in the development of compliant interfaces for clinical applications to facilitate integration with the infostructure. 2. Registries are required to uniquely identify healthcare providers (people and organizations), clients and locations of care. A Provider Registry is an index of caregivers with a description of their roles within any given jurisdiction. It facilitates the secure flow of health information between providers and hospital, clinics and other healthcare sites. A Client Registry is a secure directory of patients, accessible across all points of care, within a region, a province, and ultimately nationwide. A Location Registry identifies all healthcare sites where services are delivered to patients. The next three investment programs will provide support for four very important clinical data domains (subject areas) required in an EHR.

116


3. Drug Information Systems enable physicians to view a patient’s complete drug profile online, order a prescription electronically and receive notification of adverse drug events automatically. These systems also allow the pharmacist to view the order online, and send a message for inclusion in the patient's drug profile once the prescription is dispensed. It is expected that drug information systems will help reduce prescription errors and adverse drug complications and improve diagnosis while enabling greater efficiencies. 4. Diagnostic Imaging Systems enable authorized healthcare providers to view online a patient's diagnostic images, such as X-Ray, MRI and CT, and reports, regardless of where the test was conducted. These systems ensure faster turnaround times, better access to services, reduced duplication, increased productivity and lower costs due to the elimination of film. 5. Laboratory Information Systems enable secure online viewing of patients’ lab test results by authorized providers, regardless of where the tests were completed. Lab systems will reduce duplicate testing, improve quality and operational effectiveness through standardization and automation, optimize scarce resources, improve accessibility and timeliness, and reduce costs through economies of scale. 6. Public Health Surveillance systems support the systematic gathering and analysis of information on infectious diseases. Infoway’s focus in this program will be towards: Case Management – the testing of individual clients who may have a infectious disease or may have been in contact with a person who has an infectious disease. Surveillance and Reporting – the detection of potential infectious disease outbreaks that could pose a public health threat. Outbreak Management – the administration of measures (e.g., immunization) that can prevent or mitigate infectious disease incidence. Health Alert Network – the timely issuing of alerts to the appropriate public health authorities when risks and outbreaks are detected. The next three programs round out Infoway’s investment approach. The Telehealth program focuses on exploiting a channel for healthcare delivery. It will exploit the investments made in EHR solutions by ensuring convergence and integration. Infostructure focuses on systems architecture and design, standards and governance. The Innovation and Adoption program focuses on emerging technologies and factors effecting adoption by end users. 7. Telehealth is the use of telemedicine-enabled medical devices, communications and information technology to deliver healthcare services over distances, including remote and rural areas. It will enable Canada, with its expansive geography, dispersed populations and significant Aboriginal and minority language communities, to deliver improved healthcare quality to its rural, remote, Aboriginal, Inuit and officiallanguage minority communities. 8. The Infostructure program’s focus is architecture and standards. The definition of the overall business and technical solution architecture is a key deliverable of this program. In addition, standards for interoperability and the processes and tools to gain pan-Canadian adoption of standards are funded from this program. 9. The Innovation and Adoption program will focus on understanding adoption barriers, studying success stories and outlining a national adoption strategy. Infoway will also invest in emerging technologies which show promise for overcoming adoption barriers or enhancing the capabilities and value of the Electronic Health Record. Investment criteria includes demonstration of significant clinical value and alignment with key areas of healthcare renewal – reducing wait times, improving access, primary care, home care, pharmaceuticals, public health, health human resources, health innovation, aboriginal health and accountability.


117

Figure 1. Infoway’s role as strategic investor focuses on initial investment in a solution and its deployment. Our unique role is in providing strategic leadership.

Although each of these nine programs could deliver value on their own, the goal of Infoway is to develop a broad, interoperable and expandable EHR architecture that incorporates them all. The framework that brings them together, the EHRS Blueprint [5], is explained in Section 4. Adherence to this architecture is critical; it becomes a key criterion for determining in which projects Infoway will invest. 3.3. Operational Model As illustrated in Fig. 1, Infoway is a strategic investor that seeks out best-of-breed solutions and other opportunities that can be leveraged to support a more efficient and sustainable healthcare system. Infoway works in partnership with health ministries, regional authorities, other healthcare organizations as well as IT vendors and suppliers. Collaboration with health ministries and other partners allows Infoway: (a) to align priorities; (b) to plan the associated technology and adoption activities required (such as Change Management and Knowledge Transfer) and effectively deploy new solutions; and (c) to determine overall costs, including Infoway’s required contribution, as well as implementation schedules. As a strategic investor, Infoway focuses on both the investment in an initial solution and its development for reuse and subsequent deployment. Infoway’s specific responsibilities are to: • • • •

Set standards and requirements for robust, interoperable, replicable product solutions; Provide leadership in researching and setting strategic direction for EHR development to speed implementation; Establish success criteria; Release or withhold funds based on status and quality of project results using a gating methodology.

Given the nature of its role, Infoway on its own does not build, directly implement or hold proprietary EHR solution components. At the same time, Infoway is not a granting agency; it plays an active role in monitoring the progress and quality of deliverables for

118


Figure 2. Infoway’s project management process. As an investor Infoway works with health ministries and other partners to develop robust, reusable and interoperable EHRS components that can be replicated and deployed to multiple jurisdictions Canada-wide.

each funded project. This collaborative and highly engaged approach requires that Infoway provide timely guidance and advice to support project continuation throughout its lifecycle. 3.4. Engaging Stakeholders Implementation of EHR solutions involves a wide range of stakeholders. Infoway works actively to build partnerships and alliances with co-investors and project implementers (health ministries, public sector sponsors, regional health authorities, hospitals and others), as well as with technology enablers (vendors and suppliers), and the international community active around the EHR agenda. Infoway consults, identifies mutual interests, negotiates project investments and collaborates with its stakeholders to achieve common goals. Healthcare providers and their associations, regulatory colleges, IT trade associations and academia are also key stakeholders whose involvement is crucial to the successful implementation and adoption of EHR solutions. Infoway’s primary role with these stakeholders is building awareness of and stimulating interest in EHR solutions. Ultimately, active involvement of these stakeholders in the design and implementation of EHR solutions is achieved through Infoway’s public sector partners. Beyond the healthcare and professional IT communities, Infoway is also working to raise awareness among the Canadian public of the direct benefits of its investments. Every individual will be touched by and will gain from a more effective healthcare system based on a secure, lifetime electronic health record. 3.5. Project Management This section describes the process (Fig. 2) for identifying, developing, launching and deploying projects. This process is not strictly linear. In addition, there are a number of feedback loops between various activities in the chain. 1. IM/IT Planning: In this phase Infoway works with members to understand their healthcare requirements and priorities, which help guide Infoway’s business plan and multi-year strategic investment plans. Once the business plan has been developed and endorsed by member Deputy Ministers of Health, Infoway can engage in joint budget planning, establishing strategic alignment between the organizations. 2. Jurisdiction Planning and Infoway Estimate: In this phase Infoway works with the member jurisdictions to develop a three-year jurisdictional IT investment plan, high


3.

4.

5.

6.

119

level enterprise architecture, and investment budget estimates. These estimates are for the full project costs. From those estimates it is determined which of those project costs are eligible for Infoway investment and the approximate investment in that project available from Infoway. This estimate better enables the jurisdiction to get approval for its share of the investment from its treasury board. Investment Program Planning: This step in the process develops the investment program strategy. The investment program strategy takes the high-level program objectives, as identified in the business plan, and defines them in greater detail. Based on members’ requirements, the EHRS Blueprint, and the six elements of the Infoway business strategy, a solution is developed for each program along with a set of investments, or projects, that deliver components of the solution over time. Bestof-breed solutions developed by jurisdictions and their technology providers become elements of the solution. Commercial products are often components of the solution as well. A project may deliver on any number of objectives, such as: • New solution where one may not exist; • New or enhanced functionality to an existing solution; • Modifications to the solution to make it more scalable, portable and/or interoperable, particularly with the interoperable EHR; • Modifications to the solution to make it standards based; • Integration of a solution into an enterprise. Some projects are designed to pilot and evaluate new business models, such as shared services across jurisdictions, or strategies for end-user adoption. Project Investment and Planning: The key deliverables of this phase include an ‘asis’ view of the proposed IT solution as it relates to one or more of Infoway’s investment programs; a ‘to-be’ state of the IT solution and how it maps against the Infoway EHRS Blueprint; and a strategic migration plan with identified projects to be considered for Infoway investment. Critical in this phase is how organizations leverage previous investments, and how they reuse and replicate via toolkits in order to enhance return on investment. A formal contract is written and signed prior to entering the next phase. Project Phase 1: Project investment, be it an investment in a new solution or replication of an existing solution, is initiated with a scoping and planning phase. This phase details the proposed activities, timeline, milestones and deliverables for the investment. At times when more than one partner is contributing to solution delivery, a detailed project charter is created to document responsibilities. Project Phase 2: This phase follows a typical software development lifecycle— business design, technical design, build, test, deploy and implement—with the added integration of some additional milestones and deliverables such as Change Management. It is within this phase that Infoway contracts with partners based on a gated funding methodology. Funds are released when pre-agreed-to work products are delivered, such as design documents or software modules. Milestones may be based on fulfilment of business objectives; for example, the delivered solution has delivered on a specific metric such as a provider adoption rate or usage metric (e.g. 90 percent of prescriptions written electronically). Also integrated into the project lifecycle is toolkit development. Toolkits hold the assets that form the basis of the subsequent Infoway reuse, replication and deployment strategy. Work products of the project are made available for use by other partners. Once solutions have been in production, Infoway does a benefit evaluation. The objective is to measure the actual outcomes against the plan.

120


Figure 3. The Infoway replication continuum. Replication drives down cost, accelerates timelines, reduces risk and realizes interoperability. The greatest benefit is derived when the same solution is replicated.

A key deliverable of Project Phase 2 is the solution replication toolkit. Toolkits, which hold the reusable assets and intellectual property from Infoway investment projects are used by members to accelerate their timelines, reduce cost, and reduce their implementation risk. As Fig. 3 shows, there are varying degrees of use. At a minimum, and as criteria for investment, we expect jurisdictions to replicate the functional specification of the solution and the standards for interoperability. For example, each implementation of computerized physician order entry of drugs must meet a minimum functional definition and must use the same integration and interoperability standards. This will enable a physician to order a drug for anyone and have it dispensed at a pharmacy anywhere, regardless of where the client’s EHR is and how it is implemented. 3.6. Investment Formula Infoway has defined investment formulas (Fig. 4) to reflect its strategic objectives of collaboration and re-use. Establishing funding transparency facilitates planning and contract negotiation. The allocation principles provide a tiered-funding formula: • • •

to encourage and reward innovation and early adoption to recognize the variable complexity of various program areas to support fully the cost of interoperability and reuse components, namely standards and toolkits

4. EHRS Architecture Blueprint The specification of a common framework and set of standards for designing, developing and deploying interoperable, reusable EHR solutions is the key to achieving Infoway’s mandate. Without such a specification, healthcare solutions across Canada would be a patchwork of incompatible systems and technologies. Infoway’s EHRS Architecture Blueprint was developed based on domestic and international best practices, and confirmed through extensive consultations across Canada. These included looking at: •

Ways to uniquely identify the actors in a healthcare encounter. This was particularly challenging given that multiple jurisdictions and healthcare delivery organization all had their own mechanisms for identity management.


121

Figure 4. Infoway’s investment formulas.

• • • • • • •

The optimal way of making data available to authorized providers from multiple systems. Mechanisms to make data semantically consistent. Mechanisms to make systems scalable and high performing. Mechanisms to make systems secure and private. Approaches for adoption of the IT systems by healthcare providers. Mechanisms to make systems portable and configurable to a diverse set of requirements. Approaches to integrate systems in a loosely coupled manner.

The Blueprint is a fully validated, architectural framework that lays out the business and technical considerations and approaches that will ultimately guide the development and implementation of sustainable EHR solutions in Canada. It provides a valuable framework within which individual jurisdictions can develop their own cost-effective EHR solutions while delivering reusable solutions to other jurisdictions. This section begins with a brief discussion of the benefits of a common framework, addresses essential requirements and design principles, and concludes with a high-level presentation of the architectural solution. Please note that deployment models and a technical architecture [5] have also been defined, but are too detailed to present in this document. 4.1. Benefits The benefits of the EHRS Architecture Blueprint are compelling. The Blueprint will help jurisdictions and Infoway develop technical roadmaps, and facilitate rapid development and deployment of compatible EHR solutions. The Blueprint is the starting point that will form the basis across Canada of a common definition and specification of the business and technical architecture for an interoperable EHRS. It protects existing investments by building on systems already in place across different jurisdictions. For a system designer, the Blueprint provides system agility, advanced integration capabilities, demonstrable cost efficien-

122


cies through standardization and the ability to rigorously define system development and migration strategies: • Increased agility – Adaptability to meet the changing needs of the healthcare system and of healthcare providers and patients – Faster delivery of new applications and continued ROI from legacy applications – Easier integration of diverse applications and more flexibility during mergers, acquisitions and new business relationships, as they pertain to information systems and technologies – Adoption of a common set of technical and data standards and of a common architectural model •

Facilitates integration – Timely access to critical clinical patient information across the healthcare network with consistency and accuracy – Awareness of all organizational knowledge (by organization, department and service), and of where that knowledge resides and can be accessed – Adoption of a common set of technical and data standards

•

Cost efficiencies – Requirements to facilitate appropriate technology procurement and vendor management – Concentration of required skill-sets – Increased reuse of technology investments – Enhanced opportunity for financial ROI from legacy applications

•

Documented and clearer system development and migration strategies – Priorities, timelines, options and benefits – Focused investment in the right areas at the right time

Infoway sees the Blueprint as an important vehicle for fulfilling its mandate of promoting and investing in pan-Canadian EHRS. As such, all projects funded by Infoway must comply with the Blueprint architecture. The Investment Model discussed in Section 3.6 ensures that jurisdictions are fully funded in developing the specific standards for Blueprintcompliant interfaces. 4.2. Guiding Principles Following are a list of guiding principles that have informed Infoway’s architectural decisions for the EHRS Blueprint. •

•

Patient centricity. The EHR is meant to store, maintain and provide access to information for the foremost purpose of treating patients and making clinical data available to authorized caregivers. Unlike many current provider IT systems, which tend to be provider-centric or organization-centric, the EHR is patient-centric. Customization for clinical-data viewing. Patients, care providers and healthcare authorities will access the EHR in different contexts of care. Notwithstanding the significant quantities of data amassed and the location of authorized requestors of information, the EHR must be able to provide customized views of data aligned with each requestor’s needs and purpose. Customization of data gives a user the ability to view the data they want in the form they want when they want it. Users can have data presented and formatted in the context of the use case and can use the information to conduct what-if scenarios.


•

•

•

•

•

•

•

•

•

123

Value-add for providers. The EHR must be designed with a constant focus on the added value its data can bring to healthcare providers and their organizations. The EHR must be capable of fulfilling the requirements of today’s and tomorrow’s mission-critical activities undertaken in the day-to-day delivery of healthcare. Information timeliness and accuracy. Patients and healthcare professionals need to make decisions on an ongoing basis in the process of treating illnesses and other health-related conditions. An EHR is expected to support any resource involved in the process of care with timely, complete and accurate information. The EHR is an authoritative and reliable source of clinical information. Jurisdictional flexibility. EHR solutions may be developed, implemented and operated across different areas of the country, under different circumstances and in different contexts. The EHRS Blueprint must allow for maximum flexibility to accommodate diverse approaches. First and foremost, it must support providers across the continuum of care in the local and regional jurisdictions. Interoperability and integration. EHR components will exist across different jurisdictions and different provider types and delivery settings. The EHRS Blueprint Architecture must ensure the system’s integration and systems interoperability of all the components. It must allow for gradual and incremental implementation paths in any given jurisdiction. Standards-based. EHR solutions require standards-based systems in which to operate. The EHRS Blueprint Architecture must rely on recognized standards in the worlds of information technology and healthcare for the development of a servicesoriented architecture. These standards are fundamental to the successful interchange of information. Each system must be able to communicate with other key components of the solution. Currently many incompatible and non-interoperable systems and standards exist. In addition, some incompatible versions of solutions within the same standard have been deployed across the country. Through adoption of the EHR, standardization must occur. Standardization also implies a common definition of the EHR solution. This will save costs on a national basis and enable costeffective systems integration and interoperability. Replicability. The EHRS Blueprint architecture must be built to maximize the potential for reusability at all levels. It must be based on recognized industry practices that favour component designs and reusability driven by design patterns that support healthcare delivery in Canada. This principle is expected to be vital to generate economies of scale in the development of a pan-Canadian EHR. Legacy system and solution leverage. The EHRS Blueprint Architecture must take into account systems and solutions that exist as applications in healthcare organizations or as jurisdictional-level solutions. It must leverage the established capabilities and information repositories of such solutions, and allow for integration and added value to be provided by EHR data. Existing investments in IT for any jurisdiction or organization must be allowed to survive and prosper through their normal lifecycles. The EHRS Blueprint Architecture must support integration strategies to support legacy and emerging IT solutions in healthcare. Granular and flexible design to accommodate phased rollouts. Different jurisdictions must be able to create rollout plans that can be adapted to their existing planning strategies, capabilities, resources, systems and business objectives. The EHRS Blueprint Architecture must provide sufficient granularity and flexibility in its design for initiatives to be put in place and succeed in small incremental steps, generating near-term business results and return on investment. Scalability. The EHRS Blueprint Architecture must offer solutions that can be deployed in small operational contexts and sustain growth both in terms of geographic

124


Figure 5. The solution: Distributed, message-based, peer-to-peer network of EHRS systems.

•

• •

•

•

coverage, number of systems, number of users and concurrent transactions. Ultimately, it must scale to support a population base that exceeds 31M people. Extensibility to support future growth. The EHRS Blueprint architecture must be built to handle today’s healthcare practices while being able to accommodate future needs. Healthcare and medicine are dynamic domains that must be supported. The architecture must also be open to new business domains such as social health. Cost-effectiveness. The EHRS Blueprint architecture must be defined to maximize the effectiveness of every dollar invested in EHRs across different jurisdictions. Security and privacy. The creation of an EHR infrastructure across Canada generates a new level of accessibility to information about individuals’ health histories. The EHRS Blueprint Architecture must provide for stringent, rigorous and best-ofbreed security and privacy policies and principles to be applied continually and throughout every aspect of any of its components. Support for innovation and competition. The creation of EHRs across Canada allows for new classes of applications that may leverage health-related information to provide better care, or that may even change the way care is delivered. As such, the EHRS Blueprint Architecture must be vendor-neutral to allow for innovation and competition from any organization or vendor who wishes to develop EHR-enabled solutions. Design elements must be plug-and-play with open interfaces to facilitate swapping vendor components. Comprehensiveness. The EHRS Blueprint Architecture must be comprehensive in addressing all areas of business process, system services and information technology.

4.3. The Solution The Infoway EHRS Blueprint is a peer-to-peer network of interoperable electronic health record solutions deployed across Canada, as shown in Fig. 5.


125

4.3.1. Overview Figure 5 presents a high-level view of the components of any EHRS and their interrelationships. It depicts two EHRS’ that are interconnected with one another through services grouped in a layer called the Health Information Access Layer (HIAL). The HIAL allows the abstraction of infostructure systems (EHRi) from applications that create and/or use EHR content. This network of interconnected EHRS’ across the country delivers the vision of a peer-to-peer, distributed network of interoperable systems. These interoperated systems could exist at the local, regional, provincial or even national level to meet requirements of particular healthcare organizations (military, veterans’, Aboriginal or other). Each EHRS would enable communications with a given set of applications covering a defined geography of points of care. These points-of-care also include applications used by patients or healthcare providers from homes or business offices. Connecting to one of the EHRS entry points provides secure, validated and audited access to all information available across the network. 4.3.2. Components Within one EHRS, an EHRi will store, maintain and provide access to EHR data about patients that have had access to the healthcare system in the given jurisdiction. This EHRi will receive data from operational systems used in healthcare organizations or directly by care providers and patients. Conversely, it will also provide data back to the same operational systems for use by care providers involved in the circle of care for any given patient. The EHRi is composed of multiple systems that need to participate and interact with one another, namely: • • •

EHR System situated at the center of the EHRi that maintains the clinical picture and history of all patients/persons; Domain Repositories that store, maintain and provide subsets of clinical information pertinent to the clinical picture of a patient, such as drugs or medication profiles, laboratory test results, and shared diagnostic imaging repositories; Registry Systems providing identification resolution services for key entities that need to be identified in the context of any transaction (such as patients, providers, system users, locations where services are provided, consent policies that apply to a transaction’s context).

The HIAL is an interface specification for the EHR Infostructure (OSI Layer 7) that defines service components, service roles, an information model and messaging standards required for the exchange of EHR data and execution of interoperability profiles between EHR services. The HIAL could be implemented in a variety of ways. The EHRS Blueprint depicts it as an independent system solution acting as a gateway between operational systems and jurisdictional level systems participating in the EHR Infostructure. This architecture provides independence, an application abstraction layer, between the tens of thousands of operational systems that need to be connected to the EHR Infostructure. Providing for this application abstraction layer is a key objective, given each jurisdiction in Canada will have different physical deployment models of systems. The HIAL thus provides a consistent view of the enterprise, and ultimately the EHR, to all operational systems. Operational systems represent all the applications used by healthcare organizations or care providers that store, manage and or provide access to clinical data for patients. Operational systems also generically called applications interact with one EHRi in a given jurisdiction. This interaction is instantiated by way of message exchanges between applications and the HIAL.

126


Figure 6. EHRS conceptual system architecture model.

4.3.3. Key Features The key features delivered by the proposed solution are: •

Harmonization of definitions and standards between all EHRS for full interoperability: – EHRi’s are able to communicate by exchanging messages across any number of jurisdictions;G – Applications communicate by exchanging messages with an EHRi within a given jurisdiction; – Regardless of a jurisdiction’s EHRi configuration, all applications view the EHRi in one consistent way everywhere in the country; andG – Data semantics, security, privacy, transactional, policy and administrative meta-data are exchanged and interpreted similarly between EHRi’s.

•

Interoperability is instantiated between the core components of an EHRi (EHR, registries and domain repositories). Standards are established so all users of the system agree on the semantic meaning of the information stored and accessed from the EHRS. Policies and agreements are established between all jurisdictions that maintain and operate an EHRS.

• •

The conceptual diagram of Fig. 6 describes the highest-level view of the EHRS. Its purpose is to identify the key components that participate in and enable the creation of EHRs. Since the EHRS Blueprint provides a vision for the future state of the solution, this conceptual model does not make any statements about the current state of Canadian healthcare IT systems nor about the migration strategies that will be required to implement the solution. The model is organized into three layers based on the geographical and functional contexts of the various components. It shows several horizontal columns that represent the important building blocks and concepts that permeate all layers.


127

4.3.3.1. Architecture Layers The top most layer of the conceptual diagram is the cross-jurisdictional layer. This layer includes components that aggregate data such as surveillance databases. The EHRS locator maintains the appropriate links between EHR Infostructures across Canada identifying where EHR data for a person physically resides. The EHRS locator will manage this linkage via a nationally unique identifier for the person. The jurisdictional layer contains components that will typically reside at a specific jurisdiction (for example, province, territory or regional health authority). Governance models will vary from region to region, and the assumption is that there will be variability on how these components are deployed across the country. Other factors include the leverage and integration of legacy systems, including domain repositories, as well as scalability, security and privacy. The point of service level includes all operational application systems that generate, collect and manage the clinical data that will be part of the EHR. These systems will be found at all point of service locations where healthcare is delivered to the population. The EHR data and services container highlights the fact that a combination of both the EHR central system and the domain repository systems is required to have a complete set of clinical data for patients in an EHRi. The EHR is the heart of the EHRS. It is the EHR service that provides secure access to patient-centric clinical data contained in its repositories. The EHR contains information about healthcare encounters for each patient and often also stores detailed clinical data replicated from point of service applications. If necessary, information from the EHR is combined with other clinical data from one or more domain repositories to provide a patient’s complete longitudinal health record. Domain repositories are systems in the EHRi that store and provide access to specific clinical data, typically at a jurisdictional level that is not replicated in the EHR. With the information that is provided by the domain repositories, the EHRi service can offer a complete longitudinal view of EHR data to users and client applications. Unlike the EHR, the domain repositories have responsibilities beyond just providing EHR data. These systems will typically be the operational data stores for jurisdictionallevel domain functions, such as drug prescribing and dispensing. Typical examples of domain repositories include: drug; diagnostic imaging (PACS); and laboratory. Registries are directory-like services that focus on managing data pertaining to one conceptual entity (such as patients). Their primary purpose is to respond to searches using one or more pre-defined parameters in order to find and eventually retrieve the unique occurrence of such entity and a unique system identifier. Consequently, registries will not contain clinical or encounter-specific information. Those data are stored in the person’s EHR. These foundational EHRi registry services are important because they are the authoritative sources of identification for these entities; they effectively enable information exchange between disparate systems by establishing known relationships between distributed objects. Examples of EHRi registries include client, provider and location registries. The client registry uniquely identifies individuals across a large segment of a regional healthcare continuum, typically an entire jurisdiction. It is the single most important foundational service in the EHRi: it would be impractical to combine EHR data from different systems without easily knowing how a patient is identified in each application. Demographic information (name, gender, address, date of birth) stored in the client registry enables sophisticated algorithms that assist in finding the right individual during patient lookups and searches. In the same way the client registry enables identification of patients, the provider registry is responsible for maintaining unique identifiers for each healthcare professional and healthcare organization that is in any way delivering services to patients at the various

128


EHRi points of service. These registries will inevitably include directories of physicians, nurses and pharmacists across the country. In addition, the provider registries will continually expand to include a broader spectrum of healthcare providers, such as physiotherapists, midwives, mental health professionals, social workers and others. As the name implies, the location registries are comprehensive directories of all healthcare sites where services are delivered to patients. These locations include hospitals, ambulatories, doctors’ offices, walk-in clinics, diagnostic and treatment centres, and laboratories. A location registry provides consistent identification of where a service is provided to a patient. The location registry likely does not provide security services per se, but participates in supporting the applicability of security rules that relate to the location where a health service may be provided to a patient. For example, different security rules and authorizations to view data may be applied when a user is working from home rather than in an identified health facility. There are natural interrelationships among the client, provider and location registries. For example, a physician practicing at a community clinic is the family doctor for several patients. The EHRi and its registries provide a solid framework to establish, maintain and disseminate these dependencies. These interrelationships are also key to defining the role(s) and authorizations of an organization or individual who needs access to the EHR. For example, a nurse’s authorizations may change based on provider organization and location. In a hospital setting, the same nurse’s authorizations in the ER may be quite different from those granted when she is working in a hospital ward or home care setting. 4.3.3.2. Registry Deployment Models The most common deployment model will be one in which the EHRi registries are deployed at the jurisdiction level, very likely at the provincial or territorial level. This is a natural result of how the governance of health services in Canada has been mandated. Although this model works well for the segment of the population that traditionally has very limited mobility, it does pose a challenge to the not-so-uncommon scenario in which a patient receives medical care across jurisdictional boundaries. For these cases, it is necessary to establish mechanisms that link related objects across the country. One approach, called peer-to-peer allows similar jurisdictional registries to exchange information directly. Another option is creation of a cross-jurisdictional EHRi service called an EHRS locator (shown in Fig. 6 above), to maintain the appropriate links to specific registries across Canada. It is reasonable to expect that the Infoway EHRi will employ both approaches; choice will vary depending on the type of EHRi registry involved and what systems operational policies will allow. 4.3.3.3. Interoperation At its most basic level, the EHRS can be described as a collection of client applications for updating and accessing EHR data. The solution element that actually makes it possible for these systems to interoperate is the common interface specification called the Health Information and Access Layer (HIAL). The HIAL defines the various service roles, and the information model and messaging standards required for the exchange of EHR data and the execution of interoperability profiles between EHR services and client applications. When complete, HIAL will be an extensive collection of message specifications and transaction processing and brokering rules that could be implemented using different approaches. One approach is for HIAL to stand as an independent system layer that manages all incoming requests from operational systems and brokers transactions between systems participating in the EHR Infostructure to resolve and respond to these requests. Other approaches may involve components of these same specifications and rules implemented by various system interfaces collaborating in the EHRi. Although each system interface will


129

only need to implement a subset of the HIAL specifications, there will be several common elements used across all or most interfaces. For simplicity, these service components can be grouped into two categories: common services and communication bus. Common Services is the set of basic software service components used by EHRi application interfaces to process message exchanges with other applications according to the HIAL specification. They include auditing, security and privacy services. Communication bus represents the set of basic software service components that provide support for network and application protocols, low-level message assembly, routing and delivery between EHRi systems. (Both are further described in the Service Architecture section that follows.) Larger healthcare organizations, such as hospitals, will typically have multiple clinical systems in operation, often integrated through message brokers. These organizations are represented in the left-hand corner of the lower tier of Fig. 6. A clinical data repository (CDR) is also included. The box in the middle of the lower layer represents organizations that have a number of source systems that integrate individually with the EHRi but are not integrated with each other. These organizations do not enjoy the benefits of having a single point of access to the EHRi, but can still have access to EHR data as long as each system implements a HIALcompatible interface. The last group on the right-hand side of the lower tier in Fig. 6 represents small or independent facilities, such as physician offices, that only have a single client application. For these facilities, the client application must use a HIAL interface to update and access EHR data. Health surveillance applications are used to perform health surveillance activities. It is expected that information pulled into these databases will be on an anonymous or deidentified basis only. 4.3.3.4. EHRi Data Domains The types of data contained in the EHR are varied and have a number of dimensions. One of the challenges of building a data model that can contain information and address the needs of current and future modalities is to provide for a data/message model that is both flexible/extendible and yet provides sufficient structure so that the data in the EHR can be used for decision support purposes (i.e. it is structured). Figure 7 offers a high level, conceptual view of the data model that will underlie the Infoway pan-Canadian EHRS. It is conceptually represented by more than one dimension such that the provider may view the data along any two or more dimensions. The views are mass customized by the provider applications based on provider role, encounter type, encounter location and clinical use case. The data stored in the EHR, is that which is deemed by the healthcare providers to be clinically relevant over the continuum of care. We expect the data to be quite wide ranging. By way of example, over time we anticipate it will contain family history, health profile (patient history, problems, issues, function, well being), care encounters, immunizations, clinical or discharge summaries, clinical notes (observations and diagnostic information), diagnoses, medication information, care plans, treatments, risks and warnings (allergies), laboratory results, diagnostic images and reports. • • •

Time: The EHR is a longitudinal, patient-centric record of clinical data. Data: The data axis describes the different semantic types of clinical data that will be available in the EHR. Practices: This axis relates to the different medical practices that are involved in providing care, both from a role-based perspective, and from a type-of-careprovided (expertise) point of view.

130


Figure 7. EHRi data domains.

• • •

Disease: Data in the EHR will be categorized based on disease types and categories. This axis describes that categorization. Data types: At a physical level, data will be represented in a number of formats. This axis describes some of the different formats of the data. Registries: The registries participate in the data model, providing information that is not strictly clinical in type, but is required to make the data useful.

4.3.4. Service Architecture As seen previously, the EHRS is made possible by creating the right conditions for collaboration and data exchange between well-defined system components called services. In general terms, a service is a system (or part of a larger system) that groups related functionalities used by multiple other components, hiding the details of the implementation and providing published interfaces to allow proper use of these functions. A service-oriented architecture, such as the one proposed for the EHRS, uses the identification and definition of a collection of interoperable services as the centrepiece of its approach. This collection of services relies on a common language (or standard specification) to enable the distribution of business processes across two or more services. The HIAL is this common language for the EHRS business services, providing both a semantic (reference information model) and a syntactical (standard messages and application roles) foundation for interoperability. This section will describe how the EHRS business services map to the various entities shown in the conceptual architecture model in Fig. 6, and detail sample process flows which demonstrate the various services that come into play. 4.3.4.1. Service Types One consequence of using a service definition as suggested above is that it can describe a wide variety of system components. In fact, within the realm of the EHRS, system components can be grouped into four service types: 1. EHRS business services: These systems were highlighted in the conceptual architecture and are the key components visible to the various other systems that participate


131

Table 1. Views and properties of business services.

View

Properties

Functional View

Business services have loosely coupled interrelationships Distributed processes are performed through the exchange of HL7 XML messages between business services. EHR data contained in the XML messages conform to a standard HIAL information model (HIM). The behaviour of each EHRS business service conforms to a published application role defined by standard HIAL interoperability profiles (HIP). Service Level Business services will comply with standard service level objectives (SLO) defined by View Infoway, including connectivity (bandwidth), availability (uptime), capacity (TPS), performance (response time), reliability, security (physical, data, networking) and others. Application systems that are a source of EHR data or that are clients of EHRS business services are not required to meet the SLO. Accessibility View Communication between all EHRS systems is secured through robust encryption mechanisms. Access to patient EHR data is restricted by consent rules defined by that patient. These consent rules must be available to all EHRS business services, must conform to any applicable jurisdictional privacy legislation, and must be fully compliant with the Personal Information Protection and Electronic Document Act (PIPEDA) of April 13, 2000. [6]

in the EHRS. Their ‘business’ is EHR data and all supporting functions required to make it available across the entire health continuum. 2. EHRS service components: All EHRS services will require and share several common software functions (such as data replication, security and message communication). These service components include many industry standard technologies that have been tried and proven in other non-EHRS solutions. Promoting the reusability of these components will provide for a faster, more consistent adoption of the HIAL specification. 3. EHRS integrated services: These services create a convenient, single access point to two or more EHRS services. In some cases, specific implementations might include other value-added services not defined in the core EHRS services. Integrated services are fundamental mechanisms for reducing implementation costs, simplifying access to the EHRS services and promoting extensibility and innovation within the EHRS. 4. EHRS transitioning services: EHRS transitioning services bridge the gap between non-HIAL-compatible legacy systems and EHRS services. Of particular interest is their ability to make incompatible HL7 v2.x messages conform to the HIAL v3+ specifications. In addition, due the unavoidable differences between jurisdictional legislations and implementations, this service type also includes services that will harmonize inter-jurisdictional discrepancies. 5. EHRS business services: The most visible components of the EHRS architecture are the business services. They define the basic components of the infostructure required to deliver interoperable EHR data to systems across Canada. Many EHRS business services will be specified as the EHRS architecture is further refined in subsequent versions of this blueprint. At this initial stage, the following services have been identified: • • • • •

EHR services DI domain services Drug domain services Laboratory domain services Patient registry services

132


Figure 8. EHR and HIAL architecture drill-down.

• •

Provider registry services Location registry services

Definitions for all business services will become available as these systems are developed in the course of Infoway-funded projects. All will share certain common characteristics, which can be described using three separate views: functional, service level and accessibility: Figure 8 illustrates how an EHRS business service will be structured. EHR services, a subset of EHRS business services, will likely be the most complex services in the EHR infostructure, as they will be involved in many different and complex interoperability profiles. Figure 8 shows the main components that are part of an EHR service implementation. 4.3.4.2. Repository Components The EHR repositories provide storage for all data required for the fulfillment of EHR services. These repositories will be typically implemented using a combination of relational databases, object databases, LDAP and other related technologies. The following table further outlines each of the repositories. Table 2. Description of the repositories.

Repository

Description

EHR Database

This repository contains client-centric longitudinal clinical data. Various types of data (such as structured and non-structured documents, voice files and waveforms) belonging to multiple clinical domains can be stored in the EHR database. This database should not include EHR data that is also available from a separate domain repository service (such as PACS, drug or laboratory). These repositories store all configuration information related to a particular EHR service deployment. This includes policy information, internal configuration of the EHR, HIAL configuration, mapping information, profile information with respect to code-decode libraries, external components, management snap-ins, information about domain repositories and registries, and deployment configuration. This configuration information will enable the EHR service to function and interoperate with other EHRS business services. This repository holds security-related information such as user credentials, authorization and data filtration information, security profiles, and security credentials.

Configuration Repositories

Security Repository


133

Figure 9. EHR and HIAL service architecture drill-down.

4.3.4.3. Service Components Figure 9 shows a drill-down representation of the many service components involved in an EHR service implementation. Service components are grouped into three distinct categories: EHR Services, HIAL Communication Bus Services and HIAL Common Services. 4.3.4.4. EHR Services EHR services components provide the actual business logic that allows EHR data to be stored, searched and accessed by patient applications. Business Services Business services handle business messages (such as service requests) sent by patient applications for processing. Services in this component manage internal business workflow, assembly of responses, application of business rules and integration with various other business engines and components. Table 3. Description of business services.

Service Component Workflow Service

Description

The workflow service is responsible for maintaining lists of active work elements and the workflow schedules/process. It assembles work elements and uses an executable engine to execute the workflow. Domain Business These will contain individual business components with a standard interface that uses Components other services to pull or push information into the EHR, as well as to access various registries and repositories. These components will be executed as part of the designated workflow for a business request. Business Rules This service will provide a collection of business rule components and associated data Service that will be used to process business functions. These rules will be data-driven instead of hard-coded in program logic. Normalization This service will take various concepts from different sources, normalize and store them Service in the HER’s internal form. This service could be extended to include normal values based on incoming and outgoing profiles. Assembly A business request may include calls to various components providing multiple result Service sets. These result sets will be assembled together in the appropriate output format by the assembly service. This service will use assembly templates to carry out its function.

134


Data Services This component handles the interfaces to data repositories and uses metadata to manage the influx and outflow of data. Included in this component are key management and extract/transform/load (ETL) services that maintain integrity and support bulk loading of data. Table 4. Description of data services.

Service Component

Description

Key Management Service

As data is brought in from various sources, there will be cases where certain primary source database record keys are not unique across source systems. The key management service will generate and manage keys during insert and update operations in the EHR repository. The data service will hold metadata for operations carried out on repositories and also services to abstract data access services for specific database management systems. The Extract Transform and Load (ETL) service will interact with ETL tools or ETL like components to bulk load transactions into EHR repositories. This service will provide data replication to other data sources—replication provided by data management systems or specialized replication products.

Data Service

ETL Service Replication Service

4.3.4.5. HIAL Common Services HIAL common services comprise various service components. Integration Service Components Integration service components manage integration, message brokering and service catalogue functions. Table 5. Description of integration service components.

Service Component

Description

Service Catalogue Service Broker Service

Every business message supported by the EHR is registered using the service catalogue service. This service manages the service catalogue along with a service description. Proxy generators can use the service description to create proxy classes. This service reads the business message that has been transformed to the canonical form and instantiates the appropriate workflow that will be used to process the business request. Mapping Service The mapping service helps create a map file that translates a source document format to the destination format. This service can be used to map from XML to flat file and other formats and vice versa. Queuing Service This service provides store and forward capabilities. It can use message queues as well as other persistence mechanisms to store information. This service can be used for asynchronous types of operations.

Interoperability Service Components This set of components is made of services that handle resolution functions, which interact with various repositories, registries and with the EHRS locator. It also includes specific services that provide interoperability between EHRi’s. The interoperability between EHRi’s is instantiated through standard message exchanges and business transactions from one EHRi to another. The HIAL via the Interoperability Service Component will trigger and manage these inter-EHRi transactions.


135

Table 6. Description of interoperability service components.

Service Component

Description

Search & Resolution Service Interoperability Service

This service is used to interface with resolution services present in registries such as client, provider and other registries. It could be used for other search capabilities. This service uses the EHRi locators and other mechanisms to interoperate across multiple EHRs, domain repositories and registries.

Security Service Components This component comprises authentication and authorization services and includes policy and permission management functions as well as interfaces to security mechanisms used for the above functions. Table 7. Description of security service components.

Service Component

Description

Authentication Service

This service provides an interface to validate the user accessing EHR business services. The authentication service will attach to various configured mechanisms for authentication such as userid/password or certificates. This service will enable configuration and management of user permissions and more specifically defined roles for access to functions and data.

Permission Management Service Policy Management Service Security Service

Policy management services will provide an interface to configure and manage policies for access, auditing, logging, consent and other policies that may be required for a streamlined and smoothly running EHR. This service will manage the implementation of security from the perspective of confidentiality, data encryption and integration with various authentications, authorization and auditing functions.

Subscription Service Components These services provide the capabilities to subscribe to events and manage alerts and notifications functions when enabled. Table 8. Description of subscription service components.

Service Component

Description

Publish & Subscribe Service

This service provides functions at two levels—at the integration level where subscribers of data are provided with content over appropriate integration channels, and at a higher level where users can subscribe to specific content. When the specific condition is observed or a subscribed content is published, then the user is notified with that information. This service manages subscribers and publishers. Alerts are parameters that a user can specify to control a system or an agent’s behavior. When an alert condition trips, the service will notify the user. This service ties into and works very closely with the Publish/subscribe service. An example of an alert could be “Alert me if the blood test result is outside the normal range.” The notification service could then email the physician with the result along with other information based on configuration settings.

Alerts & Notification Service

136


Management Service Components This component provides services to configure the EHR and the associated HIAL, and offers services to carry out management functions. Table 9. Description of management service components.

Service Component

Description

Configuration Service

This service is used to configure the EHRi. This includes configuration of the EHR data repository, the system, the metadata, the service components, database schema support, security, session and the caching mechanism. This service provides a common interface to manage various aspects of the EHRi. Whereas configuration services handle the system-level configuration, management services handle the user configuration aspects of the system.

Management Service

Context Service Components This component manages the context and provides session and caching services. Table 10. Description of context service components.

Service Component

Description

Session Management Service Caching Service

This service manages user sessions. A user session will contain information such as session ID, function and role information, authorization information and other information that the system may choose to store to provide efficient access to information. This service is used to manage the cache and will provide functions related to cache responses based on configured settings. These settings may include time to live, persistence, cache cycling, and role-based caching.

General Service Components This component provides services for auditing, log management and general error and exception handling. Table 11. Description of the general service components.

Service Component

Description

Auditing Service This service enables configuration of information auditing and provides the interfaces needed for audit support within other services. The audit service will manage its own data source and use other services such as workflow, data service, and reporting. Log This service is used to manage application, system, security and other such logs. Log events will be raised in various services. Those based on configuration will be logged in Management Service an event log. The log could be persisted in a flat file, a relational database, or a system event log repository. Other services, such as alert/notification services, could be integrated with the log management service to add value. Error & This service provides an interface to raise and manage errors and other business-level Exception exceptions. Exceptions can range from system/application-level exceptions to those Handling found as a result of corrupt or dirty data and other such conditions. Service

4.3.4.6. HIAL Communication Bus Services These services support low-level communication between EHR services, other EHRS business services and patient applications.


137

Protocol Service Components These components deal with the network, transport and application-level protocols. They will support pluggable modules to support various protocols. Table 12. Description of the protocol service components.

Service Component

Description

Network Protocol Service Application Protocol Service

The network protocol service will provide communication capabilities over the physical network. The primary network protocol that will be supported is TCP/IP. These are services that will support application-level protocols that hold the payload. Simple Object Access Protocol (SOAP) will be supported. Other remote call protocols such as RMI and DCOM can be plugged into the application protocol service.

Messaging Service Components These components are made up of services that handle a message after the application and network protocol wrappers are stripped off. Some of the services in this component include parsing, serialization, encryption and decryption, encoding and decoding, transformation and routing. Table 13. Description of the message service components.

Service Component

Description

Parser Service

This service will parse the messages that come in through the protocol layer. The parser will provide support for input formats such as XML, flat files positional, and flat file fixed field length. Serialization This service will package the message in the destination format from the internal caService nonical form. This could be XML, flat file positional, or flat file fixed field length. The serialization service is concerned with data/message persistence Encoding & This service will encode and/or decode a message from and to different coding formats Decoding Service such as Unicode, UTF-8, and Base64. Encryption & This service encrypts and decrypts messages. Encryption services will be based on Decryption Service industry best practices including consideration for use of IPSEC, X509 V3 digital certificates, and a common set of baseline cryptographic algorithms and key lengths. Transformation This service will use the maps generated by the mapping service for the different mesService sage definitions and transform them to the HER’s canonical form. This service will also transform messages from the canonical form to the output format. Routing Service This service will route messages to the various internal integration channels based on a Publish/subscribe model.

4.3.5. The System in Action The EHR interacts with other healthcare applications to deliver a seamless EHR: •

• •

The information stored in the EHR and in domain repositories is patient-centric and longitudinal. Logically, it forms a lifetime health history for each individual. Clinical data for any encounter is stored in only one EHR, located in the patient’s home province or territory, or wherever he or she receives care. Patient information may be organized into multi-dimensional categories such as time, clinical data type (lab, drugs, clinical notes), practice area, and disease class. All data clinically relevant over time is retained. Applications and source systems are key elements of the solution. Authorized healthcare providers use applications to view and navigate a patient’s EHR. These include applications at the point of care that a provider is interacting with a patient.

138


EHRS Solution (EHRS) EHR Infostructure (EHRi) EHR Data & Services Registry Services

EHR Repository Services

Domain Repository Services

HIAL

Common Services Communication Bus Communication Bus

Applications Appl

Appl

Appl

Appl

Figure 10. Key EHRS architecture concepts.

•

•

•

In this solution, data is pushed or published into the EHR from applications or source systems. The same applications read and use data out of the EHR. EHR data is viewed from applications that providers use in their daily activities. These applications are responsible for visualization of data. For example, a primary care doctor using a physician management system may view four sets of data on their system—one from the patient’s EHR, another from the physician management system’s physician order entry module (i.e. for a new prescription or lab test). Yet another from the physician management system’s database regarding the patient’s last visit, and the fourth set an input screen for the doctor’s clinical notes pertaining to the current visit. An EHR is not an online transaction processing (OLTP) store for any clinical system used in points of service; rather, applications will store data in the OLTP data store of the application. In near real-time, the clinical data pertaining to that encounter is replicated into the EHR via the EHRi. The interface between applications and EHRi is message-based. Most of the messaging will be for the purposes of reading and writing clinical information in and out of the EHR. As such, messages will be based on industry standards such as HL7 and DICOM. Applications may also use the value-added services of the EHRi, remotely invoking a service method. These may be supported via mechanisms such as SOAP and remote call protocols such as RMI and DCOM.


139

5. Implementation of the Blueprint Implementation of the Blueprint will take many years of effort. Infoway is committed to a phased implementation strategy. The phasing strategy in each of these programs will proceed along two dimensions— according to functionality and jurisdictional rollout. 5.1. Phasing Strategies The clinical programs, based on the Infoway business plan, are focused on three clinical data domains: laboratory test data, diagnostic images and reports, and drug information. The functional phasing strategy roughly mirrors the following progression: 1. Make information from source systems available and viewable to clinicians. For example, a laboratory test is viewable from the EHR by any authorized provider regardless of where it was done. 2. Support physician order entry. Orders for lab tests will be captured electronically by clinicians and made available electronically at whatever location(s) lab specimens are gathered and actual test(s) are performed. 3. Provide decision-support for the clinicians. The infostructure programs (the Health Information Access Layer and Registries) will be phased based on degrees of functionality that enable more services for interoperability over time. It will roughly progress as follows: 1. Services to connect various systems via the communications bus: • basic services for privacy and security • basic interoperability services for early solution deployment • search and resolution services for patients and providers within a jurisdiction • broker services for basic message handling • system and user configuration services completed to support operational systems • alert/notification services at a technical level (for error handling) • completed session management services for applications using the EHR infostructure 2. EHR assembly and normalization services: • support for requests for EHR data-spanning domains and repositories • program business components for additional registries and labs • key management services to manage the linkage of data and data services for EHR including database management systems • extended interoperability services for additional domains and jurisdictions • enhanced search/resolution service to span jurisdictions and add facility registries • broker services for advanced/expanded message handling and message content mapping services between multiple deployed EHR solutions • more advanced functionality as needed by jurisdictions and solutions • added alert/notification services for business purposes (such as clinical exceptions or triggers) 3. The final release will focus on many of the higher level services to support advanced business functionality: • workflow • enterprise-wide scheduling

140


6. Conclusion Infoway’s mandate to invest in the deployment of an interoperable EHR will take many years of effort. It is not just about money, programs and projects. It’s about the people and the will and means to effect change. What we have before us in Canada is a very ambitious challenge; some even say a daunting task. Infoway is the facilitator and catalyst for change. In addition, what has been presented here from a Blueprint perspective is an “end-state” view. In other words, from a conceptual architecture perspective it defines where we ideally want to be. It is the “to-be” state of healthcare’s information technology enterprise for the EHRS. As we move towards our goal of providing the basic elements of interoperable EHR for 50% of the population by the end of 2009, we realize that the Blueprint view is many years out, most likely beyond our 2009 target. But the Blueprint provides Infoway and its members with a clear statement of direction and definition. Adherence to the standards and guidelines expressed in the Blueprint is required for investment. What Infoway has done from an investment perspective is understand the “as-is” state. Thus, the investment programs are designed to advance the agenda in increments (a traditional IT migration plan) over time bringing us closer to the end state. But more importantly, the programs and projects bring us closer to our high level business objectives – increase efficiency in the healthcare system, improve the quality of care and healthcare outcomes, and ensure patient safety.

References [1] Canada Health Act, 1984, c. 6, s. 1. http://laws.justice.gc.ca/en/C-6/index.html. [2] Final Report: Building on Values: The Future of Health Care in Canada, Commission on the Future of Health Care in Canada, Quebec City, November 2002. http://www.hc-sc.gc.ca/english/pdf/romanow/ pdfs/HCC_Final_Report.pdf. [3] Fyke, Kenneth J., Fyke Commission, Caring for Medicare: Sustaining a Quality System, Commission on Medicare, Saskatchewan, April 30, 2001. http://www.health.gov.sk.ca/mc_dp_commission_on_ medicare-bw.pdf. [4] Building Momentum: 2003/04 Business Plan, Canada Health Infoway, Inc., Montreal, 2003. http://www. infoway-inforoute.ca/pdf/2003_CHI_BusinessPlan.pdf. [5] Electronic Health Record Blueprint Solution Architecture, Version 1.0, Canada Health Infoway, Inc. July 31, 2003. http://knowledge.infoway-inforoute.ca. [6] Personal Information Protection and Electronic Document Act (PIPEDA), Office of the Privacy Commissioner of Canada, April 13, 2000. http://www.privcom.gc.ca/legislation/02_06_01_e.asp.


141

The Story of MedCom Claus Duedal PEDERSEN a and Christina Elisabeth WANSCHER b a MedCom, Rugaardsvej 15, 2., 5000 Odense C, Denmark b Danish Centre for Health Telematics, Rugaardsvej 15, 2., 5000 Odense C, Denmark Abstract. This chapter describes the development of the electronic communication in Denmark and the background behind the Danish project organisation MedCom. Since 1996, there has been an IT-strategy in the healthcare sector by the Danish government, which has been under constant development. These strategies have laid the foundation for MedCom, which was established in 1994 in order to build a Danish Healthcare Data Network. Today, the Healthcare Data Network forms an integral part of the everyday work of the Danish healthcare sector, since the dissemination and use of it has risen sharply since it was established.

1. Pioneering Spirits Lead the Initiative The first seeds for the Danish Healthcare Data Network were sown in the late 1980s, when pioneers each saw the opportunities to establish electronic communication in the healthcare sector. They were inspired by other sectors using electronic communication and the cost effectiveness of these solutions. The first practical trials involved forwarding prescriptions from general practitioners to pharmacies. It was the pioneers, who more or less singlehandedly conducted the trials aimed at reaping the benefits from the new technology. The technology was based on EDI (Electronic Document Interchange), which is the exchange of documents electronically between IT systems in structured form by using the international standard “UN-EDIFACT” [1]. The principle of a very high degree of user influence in the development of the Healthcare Data Network was adopted at that early stage, and it is very much a basic principle of the network today. The users define requirements and preferences, after which the technical experts find ways of responding to the users’ needs. The intention of creating a Healthcare Data Network has been to achieve rapid and secure forwarding of data, but also to avoid errors. Previously, the same text was read and typed several times by different people, increasing the risk of errors creeping in, which never was for the advantage of the patient. Now the text is typed once and automatically fully integrated into the recipient’s computer system. It is therefore clear, that the actual implementation of the Healthcare Data Network has meant organisational changes in order for a paper-based organisation to make the most of the network. In many areas, the implementation has prompted a review of old routines and the introduction of more flexible and efficient procedures. Thus, higher quality and better efficiency are ensured – two principles that are of paramount importance in the development of the Healthcare Data Network. In the beginning, the pioneers worked alone with several communication projects. However, in the early 1990s, the County of Funen became the first regional authority to commit itself to the building of a regional healthcare data network. FynCom was established in 1994 on an initiative from the County of Funen. Here all projects that focused on electronic communication in the healthcare sector were collected. FynCom became a part

142

C.D. Pedersen and C.E. Wanscher / The Story of MedCom

of the Danish Centre for Health Telematics, which acted as an umbrella organization for FynCom and the national organisation for the Danish Healthcare Network, MedCom. 1.1. MedCom Pulls the Threads Together The same time as FynCom was established in 1994, MedCom was founded too. The MedCom organisation was formed in order to strengthen the development and implementation of a nationwide Healthcare Data Network and to be the organisation that would pull the threads together and secure the successful completion of the local and regional projects – all dealing with electronic communication in the healthcare sector. Just one year later, the project was mentioned in a publication from the Ministry of Research [2] “the Ministry of Health will in co-operation with the counties, municipalities and the other parties of the healthcare sector present a plan of action for the establishment of a healthcare data network, which has been established in a MedCom project”. MedCom started as a project organisation with a limited lifetime of only two years. The MedCom I project focused on the development of the network between 1995 and 1996. However, this was followed by the MedCom II project, where the focus was on consolidation and expansion between 1997 and 1999. In 1999, MedCom was established as a permanent organisation but continued to work in project periods. Between 2000 and 2001, the focus of MedCom III was dissemination and quality improvement. Today, MedCom is in its forth project period where the Internet technology is used in order to expand the possibilities of the Healthcare Data Network. This means that MedCom is neither a user nor supplier to the Healthcare Data Network; MedCom functions as an impartial prime mover, negotiator and coordinator in the development work. In the following, the different project periods will be described in detail. 1.2. Different MedCom Project Periods The purpose of the first project period in MedCom was to develop nation-wide standards for the most common communication flows between medical practices, hospitals and pharmacies [3]. These were referrals and discharge letters, laboratory requests and results, X-ray letters, prescriptions and national health insurance billing, which totalled over 2.5 million messages each month. A major element in the construction of the Healthcare Data Network was the international standard, UN-EDIFACT. All electronic communication was based on five UN-EDIFACT [4] standards: MEDREQ for requisition, MEDRPT for reporting laboratory results, MEDREF for referrals, MEDDIS for discharge letters and MEDRUC for reimbursement claims. The developers of the systems for the general practitioners and other system providers were involved in the standardisation process. The aim was to build up a market for software solutions for IT communication in the healthcare sector. Standards were tested in 25 pilot projects that were spread across the whole country. Additionally, extensive efforts were made to secure dissemination of IT communication. The communication on the Healthcare Data Network then was based on VANS (Value Added Network Service). In the VANS network a telecom operator makes a mailbox available, which stores the sender’s messages. From there, the recipients can collect their messages at their wish. The messages are directly and fully integrated into the recipient’s computer system. When the general practitioner then sends an electronic referral to the hospital department, this message contains a number of data items relevant to the patient’s treatment. These data items are included in the hospital’s patient record and used throughout the course of treatment. The discharge summary from the hospital department to the general practitioner similarly contains data on the treatment that the patient has received and the


143

Figure 1. VANS and its functionalies.

need for follow-up, rehabilitation etc. Data from the discharge summary are automatically integrated into the general practitioners own patient’s record. The experiences of the first MedCom project period were many: Several barriers had to be overcome in the early stages, since no one really knew the potential of IT communication in practice. It was therefore necessary to commit more resources to the consensus process than expected to reach a standard for each communication type, because both users and developers had to be involved. Also support from all players in the healthcare sector, from authorities, system providers and health professionals was crucial. However, the dissemination of the standards proceeded slowly. A decision was therefore taken to carry out a second project – the second MedCom project period. The primary purpose of the second period of MedCom, which ran between 1997 and 1999, was to ensure rapid and massive dissemination of the standards developed under the first MedCom period [5]. A cornerstone in this dissemination process was co-operation agreements with regional and local projects: During the second project period, MedCom therefore carried more than 200 projects through. As a part of the dissemination, MedCom worked consistently with making the extent of the communication visible by using the so-called EDI-top. The EDI-top showed the number of messages communicated for each county and message type. This was done both as part of the information and as a motivating factor for the regional health networks. Another part of the effort was to make available clear and precise information about software suppliers that had been certified for the specific communication forms. Alongside the expansion of the EDI communication was a TeleMed project, which was initiated in 1998. The aim was here to critically examine the need for and opportunities presented by the new forms and techniques of communication. An agreement was reached in relation to the TeleMed project between MedCom and project managers for 10 sub-projects on a three-month pilot operation in the areas of image communication, information systems and text communication [6]. Among other things, the agreements contained guidelines for documenting the effects of the individual solutions. The development of the Healthcare Data Network was characterized by both victories and defeats. The experience gained was that persistent and consistent project management was crucially important. Therefore, if local pilot projects did not live up to the expectations and goals, they were phased out. Similarly for the system providers – if they did not live up to demands and obligations – it was made clearly visible to the others. In the same way the results of each individual region were made visible month by month on the EDI-top [7].

144


The exchange of experience was of great significance for the development work as more and more players were connected to the Healthcare Data Network. Parallel with the dissemination of the Healthcare Data Network, focus was directed at the need for organisational development in the clinics. Without this element, it would be difficult or impossible to harvest the advantages of the new technology. At the end of the second project period all Danish hospitals, pharmacies and 66% of the general practitioners plus 16 local authorities were using the Healthcare Data Network. Altogether there were over 2,000 different organisations with many thousands of daily users. In 1999, the Health Ministry published a national strategy for IT in the healthcare sector [8]. The focus of the strategy was the communication between the various partners in the healthcare sector. IT should support an effective exchange of information and communication of patient related data in order to ensure a cohesive and coherent patient treatment. Furthermore, the electronic communication should be used to support the health professionals in getting access to relevant information across the different systems. MedCom was mentioned in the strategy, since the project had reached a high degree of acceptance and remarkable results. Because of this, the parties behind MedCom decided to make MedCom a permanent organisation in 1999. It was then said that: “MedCom shall contribute to the development, testing, dissemination and quality assurance of electronic communication and information in the healthcare sector with a view to supporting patient focused care”. This sentence has continued to be the focus of MedCom. With approximately five years of existence, the Healthcare Data Network had proven its worth but also shown its weaknesses. One challenge was that the actual standards were not precise enough. There was a need for quality assurance, further expansion of the network and a new system for the hospital communication, which became some of the focus areas behind the third MedCom project period, which ran between 2000 and 2001 [9]. In close co-operation between health professionals and developers, consensus was reached on new, more accurate standards documented in publications called The good EDI letters [10], which comprised both technical and health related recommendations. The publications were published as soon as new standards were developed. An actual test function was also established with a number of tasks primarily in the form of validation of standards and counselling for software suppliers [11]. The test function could then be the impartial party resolving interpretations and disagreements. Suppliers to the Healthcare Data Network now had to be approved and certified. Local dissemination projects continued as well as the establishment of new pilot projects for communication between hospital departments and laboratories. Web technology pilots were also carried through – and they paved the way for the fourth project period, which MedCom is presently in [12]. Alongside the dissemination of the Healthcare Data Network, the Internet gained ground in the society. Communication primarily in the form of e-mails and websites had reached a level no one could have dreamt of just a decade ago. Until 2002, significant parts of the Healthcare Data Network had been based on traditional EDI communication over the VANS-based net. However, development and dissemination of the Internet made it clear that parts – and in the long run all – of the health communication should be made Internet based, which was a primary focus of the IT-strategy [13], which will be described in the following.

2. The National IT-Strategy During the years, the National IT-strategy has laid the foundation for the IT development in the health care sector in Denmark. In May 2003 a new strategy 2003–2007 [14] was published and replaced the previous one. The new strategy identified local initiatives, which


145

should be implemented nationally. The aim was to strengthen the coordination of the IT deployment as a prerequisite for an effective use of IT in the health sector. IT use should contribute to fulfilling the overall political goals for the health care system, e.g. a high level of quality and patient satisfaction, shorter waiting lists, efficiency, effectiveness, and freedom of choice. Listing the visions and objectives of the 2003–2007 strategy, these are: • • •

The development of IT in the health care sector must contribute to a better interaction between the citizen and the health sector and it must support the individual in attending to his or her own health and treatment. IT must ensure that the individual citizen/patient will experience continuous care even though he or she is in contact with several sections of the health care sector. The exchange of patient data must therefore be seamless. For the health professionals IT must act as an integrated tool in the daily clinical work place. It must not only be a tool to register information but also to find information, which will be relevant for the decisions taken in the patient treatment. IT will also be a tool, which will ease the communication between other health professionals both internally and across institutions and sections.

In order to implement the visions and objectives stated, the strategy sets forth initiatives, which would strengthen the development and use of Electronic Health Records (EHRs). These are [15]: •

Co-ordinated implementation of EHRs – based on the Basic Conceptual Model for EHR Clinical Process (B-EHR) – pilots to clarify organisational and technical issues – large scale implementation planned from January 2004

•

A national terminology server and organisation – to underpin the continued work on classification and modelling

•

A public Health Portal provided during 2004 – citizen access to health information – physician access to up-to-date patient medication lists – intercommunication for health professionals

•

The National Patient Registry transformation into a registry based on ‘Clinical Process’ and continuity of care – for better planning – for clinical quality development – for health professionals’ easy access to patients’ medical history.

3. The Internet Enters the Healthcare Data Network In 2002, the MedCom steering committee decided that Internet technology should be used to the advantage of the Healthcare Data Network and the network entered the Internet age in order to exploit the widespread proliferation of Internet as well as its new communicative opportunities. The very fact that the communication advanced from the VAN system’s “push” strategy to the possibility for Internet’s “pull” was very important. Now the recipient has the opportunity to get information also when the sender did not know that it was requested. The “pull” possibility is therefore an important supplement to the EDI communication, and it could lead to a more cohesive treatment of the patients in the healthcare sector.

146


The task in using the Internet technology was to establish a closed, secure IP-based network for all parts of the Danish healthcare sector and thereby establish a number of services. By using the Internet technology there was an obvious potential provided by this technology for new types of communication among all parties that use the healthcare system – professionals and citizens alike. 3.1. The Architecture of the Healthcare Data Network The architecture of the Danish Healthcare Network consists of two interconnected types of networks: The technical infrastructure consists of an “old” VANS network that handles the messages based EDIFACT communication (see Fig. 1) and a “new” IP-based network (see Fig. 2). The two networks are connected so that it is possible to send EDIFACT messages between them, which have been set up by the development of a mail standard, which allows the participants to send EDIFACT from the old VANS to the new Internet-based network. The IP-based network consists of a central hub that connects all existing closed secure networks in the Danish healthcare sector into one large national net. The network is based on three levels of security: •

First level: The connection is established by the use of a VPN (Virtual Private Network) connection, to ensure the transmission security. • Second level: An “agreement system” has been established, which makes it possible to control the incoming and outgoing data flow to and from the local network to the Healthcare Data Network. The network structure is established by reusing the existing IP structures. A wide range of public RIPE IP addresses1 is available for the network. The local IP addresses are “translated” into a Healthcare Data Network address using NAT (Network Address Translation). As an extra security provision a new top domain (www.health.medcom) was established, which is only available from within the Healthcare Data Network. This solution was necessary in order to be able to maintain the original IP-structure in the local healthcare networks that were connected to the Healthcare Data Network. The alternative was to make a “national IP-plan” for the network and make the necessary changes in all the local networks. This solution was used in Norway – but it was not realistic in Denmark. Today, the new top domain created for the IP-based network ensures that none of the healthcare services can be accessed via the public Internet. The use of VPN and the creation of the top domain allow the partners and users in the Healthcare Data Network to reuse the existing Internet connections. This has been essential since all organisations already have broadband Internet connections. • Third level: Access to systems requires a user-id and password. This will in the future in many cases be replaced by a national PKI solution. The solution with the closed network makes it possible to give access to healthcare systems across organisation without having the risk of attacks from the outside, which could damage or close down the system.

4. A Network to a Service-Loaded Portal for Denmark In December 2003, the citizens of Denmark were offered a better overview of the healthcare sector as well as information about health, medicine, illnesses and their prevention on a new Health Portal, sundhed.dk. 1 A RIPE address is a “public IP-address” that cannot be used as an internal network address. For further specification see http://www.ripe.net/.


147

The Health Portal was the result of the Danish government’s IT strategy 2003–2007 [16]. In the spring of 2001, the board of directors of the Association of County Councils decided on the initiative of establishing a common public health portal in collaboration with the other public stakeholders of health care: The Ministry of Internal Affairs and Health, The National Board of Health, the Copenhagen Hospital Corporation, the municipalities of Copenhagen and Frederiksberg and the National Association of Local Authorities in Denmark. In the National IT-strategy 2003–2007 [17], it was stated that “The purpose of the health portal is to bring together present and future information and communication in the field of health care. It is the intention to create a common electronic main entrance to the health care service, which can improve insight and better dialogue between the citizen and the health care service as well as support electronic communication and sharing of knowledge internally in the health care service”. The overall goal of the Health Portal is: • • • •

To bring together future electronic communication between patients and the health care service. To function as a communication tool for the stakeholders of the health care service. To give citizens and/or patients an overview of the organization of the health care service and information related to the use of the health care service; and support the patient in attending to his own health and his health care situation. To put expert information at the disposal of health care professionals.

The Health Portal would be established one step at a time. During the first phase emphasis would be on the need for overview and for targeted information as well as on communication, thus supporting the encounter between the general practitioner and the patient. During the following phases the scope of the Health Portal would gradually be widened towards increasing degrees of integration, communication and process support for the entire health care service. The aim was that during the first phases the Health Portal would present all citizens with the opportunity to create their personal health home page on the Internet. The personal health home page would also present targeted information about the services provided by the health care system. This would provide a better overview of available options and the individual’s care situation. It will also give access to personal data registered in the health care service, including medication and, in the longer term, to data in the EHR. To the healthcare professional, the purpose of the Health Portal was to support the clinical IT workplace and the IT tools already in use. The portal therefore had to ensure easy and personal access to targeted professional information, clinical guidelines and decision support systems. The aim was that this would help improve quality, coordination and cross-disciplinary cooperation in the health care service. The Health Portal should also enhance the quality level and the efficiency of the clinical decision process by ensuring better access to updated information on the health status of patients. It should be possible to obtain information on present and previous episodes of care through safe access to the individual’s electronic medicine profile, medical history data in the National Patient Registry, diagnostic laboratory systems, existing EHR systems etc. In the National IT-strategy 2003–2007 [18] it is stated about the Health Portal that “In particular, the portal must support coherence of episodes of care where several actors of the health care service are involved and thus minimize loss of information in situations where a patient is referred from one health care provider to another. During the first phases of the health care portal, special focus will be directed at health care in pregnancy and the implementation of the electronic shared patient record. In due course more features will be added to the portal.”

148


Figure 2. The Healthcare Data Network and the Health Portal.

When the Health Portal, sundhed.dk, aired in December 2003, the entire Danish health service was brought together on the Internet by virtue of the Healthcare Data Network. As it is described in Fig. 2, the Healthcare Data Network delivers the technical infrastructure to the Health Portal by establishing safe connections between all the parties in the healthcare sector (laboratories, pharmacies, GP practices, local-, regional- as well as central authorities). Today, the Health Portal has several functions, as it not only informs the citizen of health related issues; it also offers the citizens several opportunities to interact with the health care sector. The functions that are available to all users are among others: • • • • • • •

Prescription renewal E-booking at own general practitioner Email consultation with own general practitioner Information about health, illnesses and prevention Hospital patient information (examination, treatment, post-treatment) Waiting list information and information about quality and performance Access to current status concerning public reimbursement in personal medical expenses.

In addition, the health professionals have been given access to patient sensitive information on the Health Portal by using an electronic authentication and authorisation. This signature is a part of a national project giving a software-based signature to all citizens and employees in Denmark. The signature is distributed by TDC (Danish Telecom). Through the Health Portal it has been possible to bring together the regional information systems. This ensures that citizens as well as health professionals would be able to find information and communicate across administrative regions directly without being limited by either time or geography. In May 2004, the collaboration between the Health Portal and the Healthcare Data Network was recognised by the prestigious eAward at the High Level Conference for the health ministers of the European Union [19].


149

Figure 3. Baltic eHealth and the infrastructure.

5. International Projects Very early in the process, the Danish development included also an international dimension. This was based on a desire to enter into a close teamwork with related communication projects abroad. Experience has shown that aiming at international teamwork was both right and necessary. Numerous examples show how national project experience has been an advantage internationally – and vice versa. To a great extent the situation and perspectives for the use of information and communication technology in the Danish healthcare sector are characterized by ideas and experience from similar projects in practically every EU member state. At the same time, we are witnessing that the Danish development work has also had an impact on how other countries have chosen to use the potential of the new technology. Over the years, the Danish Healthcare Data Network has thus grown in close interaction with other corresponding initiatives, such as under the auspices of a large number of international collaboration projects [20]. Alongside, the MedCom project with the Healthcare Data Network, an international office in the Danish Centre for Health Telematics has participated in a number of European projects. The newest project is Baltic eHealth [21] co-funded by the Baltic Sea Region INTERREG III B programme, which will not only connect the Danish Healthcare Data Network to the Swedish “SJUNET” and the Norwegian Health Net but also to two regional networks in Estonia and Lithuania.

150


Today, Denmark, Norway and Sweden each have their own national healthcare networks. The challenge of Baltic eHealth is both to create a solution, which will make the Internet technology available to health professionals’ different networks, while making it safe to transmit person-sensitive data. The Baltic Health Network created in the project will secure these networks, reusing as much of the existing equipment and infrastructure as possible. The aim behind Baltic eHealth is not only to prove that eHealth can be securely and efficiently transmitted across regions creating benefits for the citizens and health professionals by testing it in two different trails: eRadiology and eUltrasound. The aim will also be to see if eHealth can be a tool in counteracting rural migration by providing highly specialised medical expertise even to the outer regional areas of the region. 5.1. New Possibilities with the Collaboration Server The Collaboration Server is a set of open source components and was developed in the PICNIC-project, which was supported by EU under the 5th Framework program, which begun in January 2000 [22]. Today, the Collaboration Server is an open source telemedicine IT-platform that enables the user to engage in IT supported collaboration, by using the platform for on-line and off-line communication. This exchange of all kinds of health care information and documents follows well-defined guidelines. The open source approach allows all other health care system providers to integrate the collaboration component with their existing system, which means that the Collaboration Server is under constant development. Many analyses show that there is a great need for exchange of information between hospital and home care when elderly people are admitted to the hospital. Information that could be relevant to exchange between the two could be: Information about current medication, function level, rehabilitation and planning of discharge. To meet these needs, the Collaboration Server has proven its functionality. The use of the Collaboration Server for communication between hospital and home care is currently being tested in a project, which includes a home care unit in the Copenhagen municipality and Hvidovre Hospital. The pilot project shows that the Collaboration Server can support present communication between the hospital and the home care unit. This means that some of the paper-based communication can be transferred to an electronic form instead. This can be the case for: •

• •

Electronic exchange of text documents with either admission or discharge notification. Today these are stored in paper-based journals. However, via the electronic exchange it should be possible to “copy-paste” the information to the home care unit. This should increase the quality since the data does not have to be re-typed. Electronic messages between health professionals, the municipality and the home care unit during hospitalisation to replace certain telephone conversations, i.e. concerning further information. Electronic chat between health professionals, the municipality and the home care unit, i.e. to supplement consultations.

It is clear that there are many perspectives in the use of the Collaboration Server, since its services can be applied to many areas of the healthcare sector. The technology, which we have at our disposal here, will in the future show many advantages to the patients and health professionals – all by the virtue of the Healthcare Data Network developed by MedCom. The collaboration server is now available on the Danish Healthcare Data Network. MedCom has installed a server that is free of charge for all partners in the healthcare sector. To secure the right use of the service a number of pilot projects has been launched. The pilot projects will focus on four areas for the use of the collaboration server:


• • • •

151

Communication between hospitals in connection with the need for second opinion cases, or patients that are treated on more than one hospital. Communication between hospitals and homecare units especially with regards to admitted elderly people. Communication between psychiatric departments and social workers with regards to children. Accessing the collaboration server from different mobile devices.

6. New Communications and the Future Use of the Healthcare Data Network Today, the use of the Healthcare Data Network has greatly expanded since its beginning 10 years ago. In May 2004, the 10th anniversary was celebrated. More than 2,6 million messages are transmitted every month on the network, which is about 75% of all communication between the partners in the Danish health care sector. In 2004, the European Commission Information Society Directorate – General (DG INFSO) asked the Danish Centre for Health Telematics (MedCom) and the Association of Chartered Certified Accountants (ACCA) to investigate the cost benefits of using electronic instead of paper-based communication. Since a full analysis of the cost benefits of electronic communication in the Danish health care sector would take significant resources, it was chosen that the study should only focus on patient referrals to a hospital. The study, which was published in May 2004 [23], focused on the quantifiable cost benefits and showed significant savings. If there was a full adoption of the electronic patient referral, this would give a potential saving of 3,5 million Euros. The study showed that not only where there considerable savings in time and money, but also in the quality of the patient referral to the benefit of the patient. Today, the Healthcare Data Network also plays an important role as the technical backbone for the integration of electronic healthcare records based on the national Basic Electronic Healthcare Record (B-EHR). In this work the National Board of Health has decided to base the semantic integration on SNOMED terminology (that will replace the ICD terminology) and a National terminology database. This work has been launched at the end of 2004 and the plan is that the B-EHR and the new terminology will be implemented in all hospitals within the next couple of years.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]

DS, Danish Standard (1995): IT-health for all in the year 2000. Ministry of Research (1995): The IT-political plan of action. MedCom (1996): A Danish health care data network in two years. http://www.unece.org/trade/untdid/. MedCom (1999): MedCom2 in print. MedCom (1999): TeleMed. See www.medcom.dk. Ministry of Health (1999): National Strategy for IT in the healthcare sector. MedCom (2001): The healthcare communication of the future. MedCom publications. Can be found at www.medcom.dk. The Danish Centre for Health Telematics (1996): Introduction to EDI in the health sector. MedCom (2003): MedComIV; Status, plans and projects”. Ministry of Interior and Health (2003): “National IT-strategy for the Danish Health Care Service 2003–2007”. [14] Ministry of Interior and Health (2003): “National IT-strategy for the Danish Health Care Service 2003–2007”. [15] Lippert, S., “The National Strategi for Health Informatic”, Presentation at MIE 2003.

152

[16] [17] [18] [19] [20]


See section 4 regarding a description of the national IT-strategy. National Health Portal 2003–2007, p. 45. National IT-strategy 2003–2007, p. 45. Sundhed.dk and MedCom (2004): One Portal for Citizens and Professionals. The Danish Centre for Health Telematics, County of Funen (2003): Health communication in development. [21] See www.baltic-ehealth.org. [22] See “PICNIC story” in this book. [23] ACCA and the Danish Centre for Health Telematics (2004): The cost benefit of electronic referrals in Denmark. Summary report. The report can be ordered by writing to [email protected].


153

The openEHR Foundation Dipak KALRA, Thomas BEALE and Sam HEARD CHIME – Centre for Health Informatics and Multiprofessional Education, University College London, Holborn Union Building, Highgate Hill, London N19 5LW Email: [email protected] Abstract. The openEHR Foundation is an independent, not-for-profit organisation and community, facilitating the creation and sharing of health records by consumers and clinicians via open-source, standards-based implementations. It was formed as a union of ten-year international R&D efforts in specifying the requirements, information models and implementation of comprehensive and ethico-legally sound electronic health record systems. Between 2000 and 2004 it has grown to having an online membership of over 300, published a wide range of EHR information viewpoint specifications. Several groups have now begun collaborative software development, within an open source framework. This chapter summarises the formation of openEHR, its research underpinning, practical demonstrators, the principle design concepts, and the roles openEHR members are playing in international standards.

1. Introduction openEHR was formed in 2000 to combine international efforts in the design and implementation of generic, comprehensive and medico-legally sound electronic health record systems, while at the same time acting as a conduit for international standards. It united the activities, research results and ongoing efforts of teams working primarily in the UK and in Australia, but also integrated work accumulated over ten years across Europe. The goal of openEHR is to exemplify good designs for interoperable EHR systems through open source components, and to validate and refine these through practical clinical demonstrators. The openEHR Foundation was formalised as a not-for-profit company in 2003. This chapter summarises the antecedents that led to the formation of openEHR, including the research and demonstrator activities and the general health informatics context in which specifications and standards for the EHR are being developed. It outlines the formation of openEHR, and the steps that have been taken to establish it as a community and as a Foundation. The key features of the architectural approach to representing, storing and communicating EHR data are described. It outlines the present plans for software development, and the roles openEHR members are playing in international standards.

2. What is openEHR? The openEHR Foundation is an independent, not-for-profit organisation and community, facilitating the creation and sharing of health records by consumers and clinicians via opensource, standards-based implementations. Its mission statement is:

154

D. Kalra et al. / The openEHR Foundation

“To improve the clinical care process by fostering the development and implementation of open source, interoperable EHR components. These components should be based on internationally agreed requirements and address the need for privacy and security, while supporting the development of interoperable and evolving clinical applications.”

openEHR aims to: • • • • • •

promote and publish the formal specification of requirements for representing and communicating electronic health record information, based on implementation experience, and evolving over time as health care and medical knowledge develop; promote and publish EHR information architectures, models and data dictionaries, tested in implementations, which meet these requirements; work closely with standards bodies, so that openEHR specifications and designs embody the best aspects of relevant standards, subject to good design principles and practice; validate the EHR architecture through comprehensive implementation and clinical evaluation; maintain open source “reference” implementations, to enhance the pool of available tools to support clinical systems; and collaborate with other groups working towards high quality, requirements-based and interoperable health information systems, in related fields of health informatics.

Technically, openEHR is founded upon formal software engineering methods. It proceeds with domain and problem analysis, formulates requirements and design principles, then develops architectural specifications, and then initiates implementation projects which, through iterative refinement and testing, are used to validate and improve the architecture and requirements. The process and deliverables of these activities are all managed by a formal change control process and version management tools.

3. International Research on Representing the EHR Realising the electronic health record has been at the heart of the European Union’s Third, Fourth and Fifth Health Telematics Framework Programmes. Considerable research has been undertaken over the past twelve years to explore the user requirements for adopting EHRs (for example, published by the Good European Health Record project [1–5] and the EHCR Support Action [6]). These have formed the basis of architecture formalisms to represent and communicate personal health data comprehensively and in a manner which is medico-legally rigorous and preserves the clinical meaning intended by the original data author, (e.g. the GEHR architecture [7], and the CEN standards ENV12265 [8] and ENV 13606 [9]). These results have at their heart the recognition that personal health data is often very sensitive and always to be regarded as confidential. Other research has identified the additional requirements to support the communication of EHRs within federated communities of healthcare enterprises to support shared patient care across sites (the Synapses project [10–12]) and middleware architectures to integrate across R&D projects (SynEx [13]). EHR demonstrators have been established in many European countries, through these R&D projects and subsequently through national programmes, as the strategic importance of EHRs has grown. University College London has been developing, evaluating and refining an implementation of the EHR service architecture based on the results of these European projects and relevant CEN standards, with a principal demonstrator in cardiology. In Australia a successor to Good European Health Record, the Good Electronic Health Record project, has enabled various federal government-funded projects to establish dem-


155

onstrators of an EHR server as an integrator of clinical information to support diabetes shared care and for laboratory test results. These research projects, standards and demonstrators have played a strong role internationally in defining the widely-accepted requirements for and information architecture characteristics of EHR systems. They are each summarised briefly in the rest of this section, as these results have provided the primary input for the first generation of openEHR specifications. 3.1. The Good European Health Record Project The Good European Health Record project, GEHR, (Project No. A2014, 1992–5) explored the clinical and ethico-legal requirements for the comprehensive adoption of electronic records in place of paper systems, and proposed a first generic information model for the EHR [14,15]. The research was funded through the EU Health Telematics research programme (Advanced Informatics in Medicine) from 1991–95. The GEHR project consortium involved 21 participating organisations in seven European countries, and included clinicians from different professions and disciplines, computer scientists in commercial and academic institutions, and major multi-national companies. The project explored the clinical requirements for the wide-scale adoption of Electronic Healthcare Records (EHCRs) in place of paper records within primary and secondary care and across specialities. It also developed and evaluated prototypes based on a proposed standard architecture in these settings [16]. The architecture model, an exchange format, term sets and the specifications of access and integration tools were all placed in the public domain. Doctors, nurses and other allied professions from across Europe were involved in deriving a set of clinical and technical requirements covering: • • • • •

the requirements for the comprehensive recording of consultations with patients for a wide range of disciplines in primary and secondary care [1]; the requirements for the portability of health records between different institutional systems independently of the technology or of the applications at those sites [2]; the requirements for the communication of health records between clinicians involved in sharing the care of patients, whether via telecommunications networks or intermittently-connected devices such as smart cards [3]; the ethical, medico-legal and security issues which arise when using EHRs as the sole medium for recording and storing patient-related information [4]; the educational needs at an undergraduate and postgraduate level in order to enable the clinical workforce to adopt EHRs [5].

The results of the project strongly emphasised the primary purposes of the record being to support the continuing care of individual patients, and for clinicians to be able to demonstrate the competence and quality of care they have provided. The final key publication from the GEHR project was a formal model of the health record architecture based on these requirements [7]. Several prototype healthcare record applications were developed within the GEHR consortium, some of which are now commercial systems in clinical use (e.g. Fig. 1, taken from the pioneering Health.one system designed by Alain Maskens, Health Data Management Partners, Brussels). The GEHR requirements have contributed into subsequent European standards work in the field [8], and subsequent EU Health Telematics projects such as Synapses and EHCRSupA built on these foundations. Members of the original team working at the GEHR coordinating partner are now working at UCL and at Ocean Informatics, Australia, and have, some years later, together created the openEHR Foundation.

156


Figure 1. Example screen from Health.one developed during the GEHR project.

3.2. The Synapses Project The Synapses project (Project No. HC1046, 1996–8, EU fourth Health Telematics R&TD framework) extended the GEHR results to include the realisation of a longitudinal and multi-enterprise EHR through a federation of clinical databases and systems: a federated health record (FHR) server. Health care enterprises and regions need to federate a very large number of diverse feeder systems, which may be scatted across hospital departments, specialised units, primary care and other community settings [10]. The electronically stored information may be distributed over many sites, in a range of legacy databases. Each of these legacy systems store information relating to different aspects of a patient’s health or illness. The care of any one patient may potentially require a healthcare professional urgently to review clinical information from several of these in a consistent manner. The Synapses approach to this challenge utilised the methodology of database federation to a standard and comprehensive schema (the federated healthcare record architecture), mediated and managed through a set of middleware services [17]. The emphasis was to facilitate data sharing between federated clinical systems rather than to integrate the systems that supply or use the data [18]. The specifications of the Synapses information models and interfaces were placed in the public domain [12]. Several healthcare sites prototyped the Synapses results including: the Royal Marsden Hospital [19]; the Amsterdam Academic Medical Centre’s diabetes clinic system [20,21]; the ARCHIMED server at the University Hospital of Geneva [22]. Trinity College Dublin has piloted the use of a Synapses server in the intensive care unit of St James Hospital to federate blood gas and laboratory data. A key feature of the Synapses approach was the distinction of a generic EHR reference model (the federation schema) from a formal approach to defining and managing constraint-based specialisations of that generic model, defined as a “data dictionary” service


157

containing clinical object meta-data definitions. The UCL demonstrator site was one of the first live EHR systems to implement this object dictionary approach, which is a precursor to the openEHR archetype concept discussed below. 3.3. The EHCR Support Action The EHCR Support Action (Project No. HC3001, 1997–2000) developed a detailed and complete information model for the EHR, contributing to the Synapses FHR design. EHCR-SupA reviewed the experience gained across Europe in the use of early architecture models (e.g. GEHR) and of the first CEN EHCR Architecture pre-standard ENV 12265 in order to develop proposals for a revised version of the standard. It collaborated closely with industrial experts in several EU countries to ensure that the features in the proposed architecture met the requirements both of industry and of users. It also collaborated with PROREC [23] to ensure that the proposed architecture, accompanied by educational materials, could be disseminated within European countries to departments of health, healthcare professional organisations and to healthcare information systems developers. Amongst the main project results were: • • •

a consolidated set of requirements synthesising the publications of several EU projects and national bodies [6]; a set of recommendations to CEN for the revision of ENV 12265 [24]; guidelines and educational materials on the subsequent CEN pre-standard ENV 13606 [25].

The requirements published by EHR SupA provided a significant input to a recent ISO Technical Specification Requirements for an Electronic Health Record Reference Architecture (ISO TS 18308) [26]. 3.4. The SynEx Project The SynEx project (Project No. HC4020, 1998–2000), within the EU Fourth Framework programme. SynEx defined a middleware architecture for the delivery of collaborating health information components [13]. These included federated health record, terminology, decision support, security and demographic services, as shown in Fig. 2 below. The SynEx architecture provided a middleware and component-based framework for the implementation of the EHR server at UCL, and its demonstration in the domain of cardiology at the Whittington Hospital [27]. 3.5. The Australian Good Electronic Health Record Project The Good Electronic Health Record project arose in Australia in 1997 through colleagues who were involved with the original Good European Health Record project described above. In 1997, the Good European Health Record architecture was recommended for use across Australian general practice by a major IBM consultancy commissioned by the federal government [28]. This prompted former key Australian GEHR participants, now living in Australia, to redevelop the GEHR model based on the principle of “two-level modelling” [29]. In this approach, the technical information model layer was cleanly separated from a second layer of formal descriptions of domain concepts, expressed in the form of “archetypes”, as shown in Fig. 3 below [45]. This resulted in the separation of the development and standardisation of general information concepts from those of the clinical domain which are generally more variable and standardised in a completely different commu-

158


Figure 2. Components and services within the SynEx middleware architecture.

Figure 3. Diagram showing the separation of models and instances required for the “two-level modelling” approach.

nity. New implementations and tools were developed based on the new approach, and were released as open source. It became clear that the Synapses/UCL work had incorporated a sufficiently similar two-level approach that further collaborative design work on the concept should be pursued. Organisations in several countries became interested in the archetype approach, which has since become a key part of openEHR, as well as European and US health informatics standards work.


159

An initial demonstration trial of the GEHR kernel funded by the Australian Federal Government was undertaken during 1999–2000 [30]. A second Federally funded project to develop a translation process from a large existing State wideclinical data repository to a GEHR record server was also successfully completed and demonstrated that a small number of well designed archetypes could standardise a great deal of clinical communication. GEHR was recommended as a candidate EHR architecture for the Australian national electronic “health event summary” project called HealthConnect, which will see the development of an Australia-wide EHR network to be implemented progressively over the next 10 years [31,32]. One of the major projects funded by HealthConnect is an openEHR-based EHR system for use in a diabetic shared care environment, in Brisbane. This project is ongoing (projected completion mid 2005), and is based on the openEHR 0.9 release, and a set of early diabetic care archetypes. Experience gained from the implementation of the Australian GEHR projects led to further major improvements to the modelling approach, as well as the development of a set of design principles for the EHR; these have been a major input into openEHR. 4. EHR Demonstrators Contributing to the openEHR Specifications Seeking empirical validation and experience from operational clinical demonstrators has been a cornerstone of the openEHR methodology. It is all too easy to become engrossed in the details and fine tuning of information models on paper at the expense of practical feedback from real users in live clinical contexts. This chapter has so far highlighted a long pedigree of research projects that have underpinned the specifications now published by openEHR and the knowledge of its founding technical team. This section summarises the implementations and demonstrator settings that have been established and critically evaluated by the team in order to propose the openEHR specifications. These new specifications, however, must now also be validated in new implementations and demonstrators, which are now being planned. 4.1. UCL Federated Health Record Service Implementation work on a set of EHR services that could support operational clinical practice began at UCL in 1998–9. The information architecture was based on the results of the Synapses project, described above, including the dual-model approach of a generic reference model and a formalism for defining and interfacing clinical object definitions (now known as archetypes). The demonstrator has evolved over that time, refined through the experience gained from different clinical domains and deployment settings. The principal test-bed has been the department of Cardiovascular Medicine at the Whittington Hospital, in north London. A second demonstrator has been demonstrating and testing the same EHR components in South West Devon, since 2001, as part of an NHS Electronic Record Demonstration Implementation programme (ERDIP) [33]. The federated health record (FHR) components are delivered via a set of middleware services that enable a requesting service (e.g. a healthcare professional using a client clinical application, or another middleware service such as a decision support agent) to access electronic health record information from a diversity of repository servers (feeder systems). The Federated Health Record (FHR) implementation at UCL provides the means by which Record Components (aggregate sets of entries forming part of a patient’s federated health record) can be retrieved, added or revised according to a schema defined in the Archetype Object Dictionary. These actions take place in accordance with the user’s role-based privi-

160


Figure 4. Core FHR record server components handling the request for and retrieval of patient records.

lege and the sensitivity of the Record Components involved, and are registered in an access audit trail. The London demonstrator incorporates the following UCL-developed component services: •

•

• •

Federated Health Record services: a scalable run-time FHR environment supporting distributed access to record components from new and legacy feeder systems. The FHR services incorporate a principal record database, using Oracle, which can be used as a local cache and provides a robust repository for data originating from feeder systems that are to be decommissioned. Other database bindings that have been evaluated include ObjectStore, MySQL and a variety of XML persistence services. Archetype (Object Dictionary) Client and services: a means of facilitating feeder system sign-up and of navigating a federation environment. It enables clinicians or engineers to define and export the clinical schemata and data sets mapping to individual feeder systems, and to relate these to the schema requirements of clinical applications accessing the record server. Persons Look-up services: storing a core demographic database to search for and authenticate staff users of the system and to anchor patient identification and connection to the patient’s federated healthcare record. Expert Advisory (Decision Support) services: for anticoagulation management, to calculate the patient’s next treatment regimen and next monitoring interval. This service is provided through specific agents called from a dedicated client and these return data to this client. Decision support agents have also been written and tested for tele-medical use in the management of asthma patients in conjunction with a home monitoring device [34].


•

161

Web-based clinical applications: have been written, using Java servlets, to provide end user access to the patient records held within the FHR server. These are currently being used by clinical teams to manage patients requiring anticoagulation therapy, the assessment of non-acute cardiac chest pain and the management of chronic heart failure.

All of the main components are written in Java. The federated access to distributed clinical databases is managed through a set of directory services accessed via the Java Naming and Directory Interface (JNDI). The components are deployed within a middleware environment managed through Novell Directory Services and JINI, an open standard service-integration technology. This overall approach will allow the ongoing development of flexible and portable applications with high-level graphical user interfaces to be made where such applications can inter-operate across diverse architectures and infrastructures. The whole infrastructure has recently been ported to IPv6, and demonstrated using secure wireless IPv6 access from several international locations [35]. Further details of this information architecture and demonstrator settings may be found in [36,37]. 4.2. Australian GEHR Record Server Kernel The Australian GEHR record server was built on the two-level redesign of GEHR carried out in Australia, and constituted the first implementation of a true archetype validator. The architecture is illustrated below in Fig. 5.

Figure 5. System architecture of the Australian GEHR record server.

162


In this system, archetypes were represented as XML documents which were parsed by a Java component, and converted from serial to object format in the GEHR kernel, which was implemented in the Eiffel language. Data was created by making calls to the kernel API, which included functions in which desired archetypes could be specified. Once the required archetypes were loaded in memory, a default data composition was created, and the actual user data added as new elements or modifications to the default structure. All changes effected by the user, whether additions, deletions or modifications, were tracked by the inmemory archetype validator, and either passed or blocked. Once the user was finished, the data was committed. Archetypes were developed for basic GP recording, as well as diabetic notes. 4.3. Australian DSTC Implementation The Distributed Systems Technology Centre (DSTC), a research centre in Queensland, Australia, also developed a distributed XML-based GEHR system. Although using archetypes, this system did not include formal archetype validation; rather the effort concentrated on building a distributed system of EHR servers, and developing a design approach for distributed EHR security. The DSTC project also developed an archetype editor, shown in Fig. 6 below, based on the visual design philosophy of the UCL object dictionary editor, and the Australian GEHR archetype model.

5. Standards for Representing and Communicating the EHR 5.1. CEN EHCR Architecture Standards Since 1990 CEN has regarded the Electronic Healthcare Record as one of the most important areas for the establishment of European standards. It has so far published two generations of EHR standard, in 1995 and 1999.

Figure 6. Example screen-shot of the DSTC Archetype editor.


163

ENV 12265 Electronic Healthcare Record Architecture [8] (1995) was a foundation standard defining the basic principles upon which electronic healthcare records should be based. Over 80% of its requirements (published in a Supporting Annexe) were derived from GEHR project deliverables. The architecture was one key input to the design of the Synapses federated healthcare record architecture and to the UCL EHR demonstrator. A four-part successor standard for Electronic Healthcare Record Communication, ENV 13606, was published in 1999. •

• • •

Part 1, the Extended Architecture [9], built on ENV 12265 and defined additional components for describing the structures and semantics in EHCRs conforming to a range of requirements to allow the content of a healthcare record to be constructed, used, shared and maintained. Part 2, the Domain Termlist, defined a set of terminological measures to support various degrees of interoperability of the EHCRs created on different systems or by different teams on the same system [38]. Part 3, the Distribution Rules, specified a set of data objects that represent the rules for defining access privileges to part or whole EHCRs, and the means by which security policies and attributes can be defined and implemented [39]. Part 4 defined a set of messages to enable the communication of part or whole EHCRs in response to a request message or a need to update a mirror repository of a patient’s EHCR [40].

Since 1999 several demonstrator projects and a few suppliers have elected to use ENV 13606 in an adapted form as their means of EHR interoperability between systems and enterprises. Regrettably the adaptations made to ENV 13606 have been rather ad hoc, so the exchange of EHR information between demonstrators or systems is not possible, thus rather defeating the object of such a standard. 5.2. CEN Task Force 13606: EHRcom The EHRcom Task Force was set up to review and revise the 1999 four-part pre-standard ENV 13606 relating to Electronic Healthcare Record Communications, and to produce a formal standard (EN) [41]. The overall goal of this standard is to define a rigorous and durable information architecture for representing the EHR, in order to support the interoperability of systems and components that need to interact with EHR services: • • • • •

as discrete systems or as middleware components; to access, transfer, add or modify health record entries; via electronic messages or distributed objects; preserving the original clinical meaning intended by the author; reflecting the confidentiality of that data as intended by the author and patient.

In tackling this challenge, the goal has been to specify the information architecture required for interoperable communications between systems and services that might request or provide EHR data. This standard is not intended to specify the internal architecture or database design of such systems. Nor is it intended to prescribe the kinds of clinical applications that might request or contribute EHR data in particular settings, domains or specialities. This revision has drawn on the practical experience that has been gained in implementing ENV13606 and other EHR-related standards and specifications through commercial systems and demonstrator pilots in the communication of whole or part of patients’ EHRs, and on contemporary research findings in the field. This standard is building on

164


ENV 13606, updating it in order to make it more rigorous and complete, to accommodate new requirements identified, to interoperate with new specifications such as HL7 version 3, and to incorporate a robust means of applying the generic models to individual clinical domains through archetypes. The R&D inputs on which ENV 13606 was based have moved forward since 1999 and important new contributions to the field have been taken into account. The openEHR Foundation, integrating threads of R&D in Europe and Australia, has played a leading role in the development of this new standard. An important aspect of the new CEN standard will be its support of archetypes: any part of an EHR being communicated may reference the archetypes to which it confirms, and the standard will define an archetype interchange specification. Some elements of the openEHR Archetype Definition Language will form part of this interchange specification. 5.3. HL7 Standards Relevant to the EHR The Health Level Seven (HL7) organisation was formed in the United States in March 1987. It arose initially to tackle the growing diversity of messages developed within the US health insurance industry. The HL7 protocol is a collection of standard formats that specify the interfaces for electronic data exchange in healthcare environments between computer applications from different vendors. The focus of the HL7 organisation, and its practical experience base, has historically been the interface requirements of large healthcare enterprises. Despite its wide uptake internationally, the problems of inconsistent implementations of Version 2 and the unsystematic growth of message segment definitions have limited the realisation of interoperability. A key feature of Version 3 is the Reference Information Model (RIM): a means of specifying the information content of messages through an information model that clarifies the definitions and ensures that they are used consistently. The RIM is a formal information model representing the superset of core classes and attributes that are required (in various combinations) by the different HL7 version 3 messages. Message definitions are created via an incremental refinement process beginning with the RIM, and passing through various intermediate models, including Restricted Message Information Models (RMIMs) and Hierarchical Message Definitions (HMDs). The transformation process allows the renaming, “cloning”, removal (of optional parts), and constraining of the elements of the preceding model to produce each next one. 5.4. The Clinical Document Architecture The HL7 Clinical Document Architecture (CDA) is a generic RIM-derived structure for the communication of clinical documents, and has sometimes been regarded as the HL7 equivalent of a record architecture, although it was designed as a clinical document transfer mechanism. Level One of the CDA 1.0 is a formal ANSI standard. This XML-based specification includes a header with document authorship information, organisational origin and patient identifiers, and a body whose basic structure consists of Sections and data structures, derived from XHTML [42]. Its data types are taken from HL7 V3. CDA Release Two is a draft specification, approaching final standardisation, for the structural organisation of fine-grained information inside a document. In this regard it is close in scope to that of the inner hierarchies of an EHR architecture. A three-way collaboration now exists between the work on CDA Release 2, the CEN EHRcom Task Force, and openEHR, to harmonise these specifications as far as possible. There has been agreement on a hierarchical containment structure for the EHR based on openEHR and CEN 13606 work. This is the first widely agreed standard architecture for the shared EHR and consists of:


• • • • • • •

165

The EHR: The collection of all Compositions and Folders Folders: Organisers for Compositions – allows symbolic links and for sets of Compositions to be defined. Compositions: The unit of commital to the EHR and transfer between EHR systems – by an accountable person at a known time. Sections: Organisers for Entries within the Composition Entries: This is the semantic unit of clinical information, that is the meaning of any information has to be seen within the context of an Entry to ensure adequate clinical interpretation. Clusters: Organisers of elements within Entries. Elements: name value pairs with appropriate datatypes.

The openEHR model contains further constructs and with inclusion of an ‘organisers’ within the clinical statement model in HL7 version 3, the alignment of this architecture across all standardisation domains appears assured. CDA Release Three is anticipated to utilise a template approach to constrain the permitted structure of clinical documents. A CDA Release Three document will therefore need to cite the valid HL7 Template definition to which it conforms. This work within HL7 has deliberate overlap with the archetype approach of openEHR. 5.5. HL7 Templates Specification The Template Special Interest Group is actively developing a specification for constraints to be applied to RIM-derived message model artefacts using the Message Interchange Format (MIF). This work is drawing upon the openEHR archetype approach, and it is expected that some parts of the openEHR Archetype Definition Language will form part of this future HL7 standard. Other formalisms being reviewed as potential contributors to this specification include OWL and OCL [43]. A joint project between Mayo Clinic and openEHR is investigating the addition of semantic representation of archetypes by testing ADL/OWL interoperability. The CDA (Release 3) is expected to be one of the first HL7 artefacts to incorporate templates. 5.6. HL7 EHR Functional Specification The EHR Technical Committee has released an EHR System Functional Model as a draft standard for trial use. This standard describes an inclusive set of functions that might be available in EHR systems in particular settings – now and in the future. The standard also describes how to generate a profile. A profile is a subset of functions for a particular purpose – perhaps to describe a current system, the requirements for a future system or for regulation. This set of functions removes the barrier to describing EHR systems and their capability in a standard manner, and enables us to begin to describe the information and infrastructure required to support this functionality. The EHR Technical Committee will continue to work in the area of demand side standardisation. 5.7. OMG HDTF One other group of standards deserves mention with respect to the EHR, namely the OMG’s Health Domain Taskforce (originally known as CorbaMed) specifications. CorbaMed is important because it not only supplied useful specifications for distributed health information systems, it pioneered a now accepted “separation of interests” in the health informatics space, by defining the boundaries and scope of each specification. Only some of

166


the resulting specifications have achieved significant use today, namely PIDS (Person Identification Service), TQS (Terminology Query Service), and RAD (Resource Access Decision), however they have had a strong influence on a lot of later work in health informatics, including projects such as PICNIC, as well as openEHR. 6. The Formation of openEHR By late 1999, the two research teams at the University College London (UK) and Ocean Informatics (Australia) recognised that each had achieved valuable insights and results in the design and implementation of interoperable electronic heath records. The two teams’ work had a considerable degree of overlap in approach and some complementary strengths, which both felt should now be combined. Despite considerable research on generic information models to represent and communicate EHRs, and two generations of CEN standard, uptake of such specifications commercially has been limited. Reasons for this have included the perceived complexity of building robust and scalable systems according to a generalised hierarchical model, the lack of an easy means of specifying domain models (e.g. of the simple such as “blood pressure”, to the complex such as “discharge summary”) and the apparent success of individual businesspurpose specific messages. Many national health services have an established infrastructure for the communication of healthcare data such as laboratory results and billing information, using EDIFACT or Health Level Seven version 2 messages. These approaches have proved successful for fixed clinical data sets, but have not yet proved their scalability for dynamically created information, as generally occurs in complex illness management or as the underpinning for whole-person shared clinical care. Another important challenge to overcome is the tendency for purchasers of health software to focus on the look, feel and end-user functionality of the systems they buy, and their anticipated costs of purchase and maintenance. Interoperability has not hitherto been a high priority for purchasers, and there is also a recognised reluctance on the part of vendors to lose the potential customer lock-in they have by not being interoperable. Engineering interenterprise and inter-vendor EHR interoperability into clinical systems is therefore championed neither by purchasers nor vendors, despite being considered important for many years by clinical end-users (for example, see [44]). Formalising our cooperation would permit the mutual peer review of work done, and offer a pathway to combine the best components of different approaches. This has included harmonisation of the approaches that had been developed in Europe [20,41] and Australia [45] and the work by others. Effective collaboration to promote the value of generic and interoperable EHRs would require creation of an open organisation under which those working on the same problem could operate. Harmonised specifications would then make the implementation efforts of each involved party more effective as the components would be fully interoperable. Implementation of design specifications is vital to evaluating their practical utility and correctness, and for identifying areas for refinement or change. Live clinical demonstrator settings are critical to bringing our work closer to a wide range of users, and to ensure that the solutions are matched to evolving clinical, technical, organisational and ethico-legal requirements. An open source approach has been chosen in view of: • •

our wish to promote an interoperable (non-proprietary) approach to the representation and communication of EHRs; the limited capacity of technical and clinical experts in the area and our wish to work with a broad group of developers internationally;


• • •

167

our wish to grow a community of interest in the promotion of good EHR systems; our need to establish implementations in diverse settings; our belief that a move to an open and shared engineering process would speed development considerably.

Thus openEHR was born. 6.1. Establishing openEHR The first phase of our joint activity has been establishing an identity, an international community of interest, and a web site at http://www.openEHR.org. This ‘e-community’ has grown considerably over the past three years, with over four hundred openEHR members now registered. Of three discussion lists, the technical one is the most active. In-depth discussions have ranged from wide-sweeping debates on health information security, to the detailed, such as the effective handling of translation of EHR record elements – bringing us into contact with other health informatics communities such as clinical guidelines, terminology, ontology, images, and security. With the latest developments in openEHR processes, these lists will become a key part of a managed, community-based process of review and collaboration on openEHR deliverables. The second phase, chronologically, has been to combine the experience gained in the specification of the information architecture for a set of EHR middleware services (a record server). This work has taken place largely between the key architects at Ocean and UCL, drawing on results from the R&D projects, demonstrators and standards described earlier in this chapter. Although much progress can be made through e-mail and document exchange, the more complex issues have benefited from and at times required face-to-face brainstorming sessions, sometimes over a few weeks, in order to arrive at a consensus. Through all of our work in the EHR domain, for each of us amounting to well over a decade, it has proved imperative to adopt a requirements-based approach to understanding how to model the EHR. Thanks to the efforts of Thomas Beale and colleagues, an evolving set of specifications has been published on the openEHR web site, enabling the community to provide much valued feedback. Some groups, including the DSTC in Australia, have begun implementation using the draft specifications, and have helped significantly to improve their technical rigour. We continue working to extend the international community of interest through conferences and other meetings. In this regard, we have been very helpfully supported by the EuroRec Institute (http://www.eurorec.net) that has frequently promoted our work within its activities and events. openEHR has now reached the stage of a stable release, “Release 0.9”, that integrates all of the background work described earlier, along with that of other projects and standards efforts, including CEN 13606 and HL7 CDA, as well as the works of ISO TC215. This version also marks the starting point of a formal change management process, a newlyappointed Architecture Review Board, and web-capable version management tools. From Release 0.9 onward all changes to specifications and software are documented with change requests (CRs), executed according to the change management plan, according to the decisions of the ARB. The community is able to view all deliverables as well as CRs in progress, and can provide input at any point. The ARB provides formal management as well as expert opinion. The main aim of openEHR in 2004 is to publish a 1.0 release, proposals for which already include significant implementation-based feedback. It is hoped that this release will form a stable basis for more widespread implementation work. Later releases will then concentrate on APIs (taking input from projects which have used the OMG HDTF specifications), archetype tools, and reference implementations.

168


The third task has been to establish the openEHR Foundation and formal processes for managing the publication and dissemination of deliverables as open source components. A set of legal instruments, including memoranda and articles of associationhave been adopted. The Foundation is formally registered as a UK-based company, and is run as a not-for-profit organisation. Its founding corporate shareholders are UCL and Ocean Informatics, and it is open to the inclusion of other sponsoring shareholders as the Foundation grows and develops. In order to provide adequate legal protection of the openly published deliverables of openEHR, the Foundation has registered the name “openEHR” as a trademark, and developed copyright notices and open source licences for the open and legally safe use of documents and software (the software licence is the Mozilla “tri-license”, allowing the user to choose the MPL, GPL or LGPL licenses as they see fit). The website also incorporates a formal data protection policy and declaration. The consequence of making deliverables openly and freely available is that the openEHR Foundation is actively seeking sponsorship and donations from industry and from governments to contribute to its very real running costs. This is now also a very exciting time, with important new standardization activities in HL7 and CEN taking significant input from members of our group. Reciprocally, we have found that the participation in these standards bodies has provided fresh ideas to further develop the openEHR specification. Our goal is harmonize the openEHR specifications with those activities in order to ensure that any adopter of openEHR record server components can easily conform to relevant EHR interoperability standards. Furthering this harmonisation has somewhat delayed the specification release to 2004 but with substantial benefit.

7. Key Features of the openEHR Technical Approach 7.1. Requirements for Representing and Communicating the EHR The very extensive investigations of user and enterprise requirements that have taken place over twelve years, through research work summarised above, have sought to capture the diversity and specialisation across primary, secondary and tertiary care, between professions and across countries. These requirements have been distilled and analysed by expert groups across Europe in order to identify the basic information that must be accommodated within an EHCR architecture to: • • •

capture faithfully the original meaning intended by the author of a record entry or set of entries; provide a framework appropriate to the needs of professionals and enterprises to analyse and interpret EHRs on an individual or population basis; incorporate the necessary medico-legal constructs to support the safe and relevant communication of EHCR entries between professionals working on the same or different sites.

Much of this and other background research has now been consolidated within an ISO Technical Specification [26]. However, the field is continually evolving, and openEHR members continue to play an active role in identifying and refining requirements, and collaborating with groups internationally to contribute to the published literature. It is a goal of openEHR that its technical specifications are clearly mapped back to requirements. An original mapping was published by Beale in 2002 [46], and more detailed cross-mapping spreadsheets, including CEN and HL7 standards, are presently being produced for inclusion in another PhD thesis, for publication during 2004.


169

7.2. Design Principles A number of key design principles underpin the openEHR specifications, of which the following are key: • • • •

• • •

Separation of technical and knowledge spaces (two-level approach), with the technical (i.e. information and service) models which make up the openEHR Reference Model, being developed “archetype-” and “template-ready”; Separation of models according to the principle of “separation of interests”, which enables each to be created and implemented in a relatively independent, tractable manner; A multi-layer semantic model of record content (also accepted by CEN TC 251 and HL7): Folder, Composition, Section, Entry, Data Structure, Data Type; A clear analysis of “context” attributes of EHR data, showing how the audit details (who/when/where/how/why) of various activities (a clinical action on a patient, a patient consultation, committal of data to the EHR, attestation, and so on) should be modelled; A clear design basis for versioning of EHR and demographic data, supporting the requirements for physical indelibility of information, logical integrity, and mediolegal protection of both clinicians and patients; Re-usable data structures, which take into account temporal and spatial complexity in real clinical data (e.g. multiple samples of an ECG or an Apgar result); An implementable set of universal clinical data types.

Some of these are described in more detail below. 7.3. The Two-Level Modelling Approach The challenge addressed by the two-level approach to the design of the EHR communications information architecture has been to devise a scalable model for representing any conceivable health record entry. This needs to cater for records arising from any profession, speciality or service, whilst recognising that the clinical data sets, value sets, templates etc. required by different health care domains will be diverse, complex and will change frequently as clinical practice and medical knowledge advance. The two-level approach distinguishes a Reference Model, used to represent the generic properties of health record information, and Archetypes (conforming to an Archetype Model), which are meta-data used to represent the specific characteristics of the various kinds of clinical data that might need to be represented to meet the requirements of each particular profession, speciality or service. The Reference Model is presented as an ODP Information Viewpoint Model, representing the global characteristics of health record entries, how they are aggregated, and the context information required to meet ethical, legal and provenance requirements. This model defines the set of classes that form the generic building blocks of the EHR. It reflects the stable characteristics of an electronic health record. Such a generic information model for the EHR needs to be complemented in the knowledge domain by a formal method of communicating and sharing the named hierarchical structures within EHRs, the data types and value ranges that actual record entries may take, and other constraints, in order to ensure interoperability, data consistency and data quality. Archetypes each define (and effectively constrain) allowed combinations of the building-block classes defined in the Reference Model for particular clinical concepts by specifying particular record component names, data-types and may even constrain values to particular ranges. A useful analogy is that of language illustrated in the table below.

170


Table 1. Language analogy of the role of archetypes. Grammar: rules for constructing sentences Dictionary of words The rules for constructing meaningful sentences

Reference information model Terminology Archetypes

Thus archetypes can be viewed as a statement of the rules by which terms and other data may be constructed into meaningful health information; without such rules we can create an infinite number of meaningless sentences or ‘clinical statements’. Archetype instances themselves conform to a formal model, known as an Archetype Model (which is related to the Reference Model) and are expressed in various forms. The standard form accepted by openEHR is as archetype description language (ADL) – text files which can be revised and shared between systems. Although the ADL and Archetype Model are stable, individual archetype instances can be revised or succeeded by others as clinical practice evolves. Version control ensures that new revisions do not invalidate data created with previous revisions. A sharable ADL is being developed for use with openEHR, HL7 and CEN. Archetypes expressed in ADL will correspond to HL7 RMIMs and CMETs, which may well be able to be expressed in ADL against the HL7 RIM. Early work by Ocean suggests this is possible. Archetype Repositories. In each enterprise or region there is a diversity of health information stored on paper and in legacy feeder systems. The range of archetypes required within a shared EHR community is presently unknown, but it is clear to enable key information interoperability requires a small set. The potential sources of knowledge for developing such archetype definitions will include: • • • •

health information which is used for semantic processing within current systems health information used in secondary data collections the clinical data schemata (models) of existing systems; the lay-out of computer screen forms used by these systems for data entry and for the display of analyses performed; • data-entry templates, pop-up lists and look-up tables used by these systems; • shared-care data sets, messages and reports used locally and nationally; • the structure of templates and forms used for the documentation of clinical consultations or summaries within paper records; • the pre-co-ordinated terms in terminology systems. In order to realise the full benefits of local or national shared EHR repositories, enterprises should agree, wherever possible, on common archetypes. The existence of a common Reference Model and Archetype Description Language will encourage the mapping and transposing of the individual schemas towards a shared EHR. A shared Archetype repository is essential to facilitate this convergence across sites or regions. In the short term, the archetype definitions can be used to inform clinical standards in all fora, and provide a standard means of expressing query statements for systems – akin to the ‘virtual medical record’ proposed by the HL7 Decision Support group. In the longer term, it is anticipated that the involvement of national health services, academic organisations and professional bodies in the development of such definitions will enable this approach to contribute to the pursuit of quality evidence-based clinical practice. 7.4. Linkage to Other Project Groups and Formalisms While there is agreement that the semantics of health information involve general agreement on data-types, vocabulary and some structure, to this point these structures have been confined to specified messages or particular information systems. Vocabulary enthusiasts


171

continue to pursue the structure of code phrases, assuming the ever increasing complexity will be managed by more and more powerful systems. By starting with archetypes – which are as we have said are clinical models ‘removed’ from the reference model – it is possible to get broad agreement on what vocabulary is required for each point in the archetype. ADL allows this to be specified within the archetype as a constraint on external terminologies, or as a set of terms described within the archetype itself. The power of this approach and the level of abstraction allows collaboration amongst a wide range of experts working in the field. The result is that the linkages with other projects are beginning to grow. Important related work with which openEHR members are collaborating and learning are: • • • • •

The work at the Mayo clinic to develop a web-based ontology approach to health information using OWL – the aim is to generate a repository for archetypes that can be used for development Similar work in the CLEF project working with Alan Rector in the field of oncology and national reporting Work with Partners and IHC on new generation EHR systems Generic interfaces to EHR systems with Pete Johnson and Ian Purves at SCHIN Implementation efforts around the CorbaMed specifications at Maastricht and Crete

These efforts are leading to a greater understanding of the issues and a more robust approach to archetypes and the two level modelling approach in general.

8. Ready for Implementation openEHR has reached a point where its specifications are starting to be used, both by private organisations as well as government projects, such as HealthConnect in Australia. An open source reference openEHR EHR server is under construction in the UK. The archetype concept, and the Archetype Definition Language (ADL) has been sufficiently well defined that there are doctoral students in medical informatics studying it in the UK, Spain, Denmark, among other countries; open source ADL software is also being built, both in Australia, and as part of a joint project between the Australian government/Ocean Informatics and Mayo Clinic. The output of these projects includes archetype viewers, editors, an archetype repository. A concerted effort to develop a shared component that can read a template (a specification of how a set of archetypes will be used) and provide an in memory schema for applications to populate is now under way. This tool will allow the generation of openEHR compositions that can be safely shared as data by all EHR systems cognisant of the openEHR reference model and as semantic content by all systems cognisant of the archetypes in use. In future, semantic interoperability may be reduced to agreeing to use a set of archetypes, data sharing to using the reference model as a pattern in system implementation. Some voices will recoil from a shared EHR architecture but openEHR demands no implementation within systems. Rather a shared approach and logical view of the information within their systems. It is a challenge worth the effort and there is still much work to be done. We invite you to join us in achieving the goals.

References [1] Ingram D., Southgate L., Kalra D., Griffith S., Heard S. and others. The GEHR Requirements for Clinical Comprehensiveness. European Commission, Brussels; 1992; The Good European Health Record Project: Deliverable 4. 19 chapters, 144 pages.

172


[2] Ingram D., Hap B., Lloyd D., Grubb P. and others. The GEHR Requirements for Portability. European Commission, Brussels; 1992; The Good European Health Record Project: Deliverable 5. [3] Ingram D., Lloyd D., Baille O., Grubb P. and others. The GEHR Requirements for Communication Capacity. European Commission, Brussels; 1992; The Good European Health Record Project: Deliverable 6. [4] Ingram D., Murphy J., Griffith S., Machado H. and others. GEHR Educational Requirements. European Commission, Brussels; 1993; The Good European Health Record Project: Deliverable 9. [5] Heard S., Doyle L., Southgate L. and others. The GEHR Requirements for Ethical and Legal Acceptability. European Commission, Brussels; 1993; The Good European Health Record Project: Deliverable 8. 9 Chapters, 68 pages. [6] Dixon R., Grubb P.A., Lloyd D., and Kalra D. Consolidated List of Requirements. EHCR Support Action Deliverable 1.4. European Commission DGXIII, Brussels; May 2001. 59 pp. Available from http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v1_3.PDF. [7] Lloyd D., Kalra D., Beale T., Maskens A., Dixon R., Ellis J., Camplin D., Grubb P., and Ingram D., Editors. The GEHR Final Architecture Description. European Commission, Brussels; 1995; The Good European Health Record Project: Deliverable 19. 11 chapters; 250 pages. available from http://www.chime. ucl.ac.uk/HealthI/GEHR/EUCEN/del19.pdf. [8] Hurlen P., Editor, Project Team 1-011. ENV 12265: Electronic Healthcare Record Architecture. CEN TC/251, Brussels; 1995. [9] Kay S. and Marley T., Editors, Project Team 1-026. ENV 13606: EHCR Communications: Part 1 Electronic Healthcare Record Architecture. CEN TC/251, Stockholm; 1999. [10] Kalra D., Editor. The Synapses User Requirements and Functional Specification (Part A). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1a. 6 chapters, 176 pages. [11] Grimson W. and Groth T., Editors. The Synapses User Requirements and Functional Specification (Part B). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1b. [12] Grimson J., Grimson W., Berry D., Stephens G., Felton E., Kalra D., Toussaint P., and Weier O.W. A CORBA-based integration of distributed electronic healthcare records using the synapses approach. IEEE Trans Inf Technol Biomed. Sep 1998; 2(3):124–38. [13] Sottile P.A., Ferrara F.M., Grimson W., Kalra D., and Scherrer J.R. The holistic healthcare information system. Toward an Electronic Health Record Europe ’99. Nov 1999; 259–266. [14] Ingram D. The Good European Health Record Project in: Laires, Laderia Christensen, Eds. Health in the New Communications Age. IOS Press: Amsterdam; 1995; pp. 66–74. [15] Griffith S., Kalra D., Lloyd D., and Ingram D. A portable and communicable architecture for electronic healthcare records: the Good European Healthcare Record Project (AIM project 2014). Greenes, R.A. and others, eds. Medinfo 8. 1995; 223–226. [16] Ingram D., Griffith S., Maskens A.P., Kalra D., Lloyd D., and Southgate L. The Good European Healthcare Record project – the results of a three year project to design a common architecture for healthcare records across Europe AIM project A2014. Future of Patient Records – Care for Records of Care. May 1995; 415–419. [17] Grimson J. and others. Synapses – Federated Healthcare Record Server Brender, J. and others, Eds. Proceedings of MIE 96. IOS Press: Amsterdam; 1996; pp. 695–699. [18] Kalra D., Editor. The Synapses Object Model and Object Dictionary. EU Telematics Application Programme, Brussels; 1997; The Synapses Project: Deliverable USER 1.3.2. [19] Kalra D., Milan J., Austin T., Ingram D., Lloyd D., Grimson J., and Grimson W. Synapses in Use: Supporting Cancer Care at the Royal Marsden Hospital. Proceedings of IMIA International Working Conference on Electronic Patient Records in Medical Practice. 1998a; 97–101. [20] Toussaint P.J., Kalshoven M., Ros M., van der Kolk H., and Weier O. Supporting shared care for diabetes patients. The Synapses solution. Proceedings / AMIA Annual Symposium. 1997; 393–7. [21] Weier O., Kalshoven M., van der Kolk H., Leguit F., Ros M., and Toussaint P. The federated healthcare record to support shared diabetes care. Medinfo 9. 1998; 1:103–6. [22] Thurler G., Borst F., Breant C., Campi D., Jenc J., Lehner-Godinho B., Maricot P., and Scherrer J.R. ARCHIMED: a Network of Integrated Information Systems. Methods of Information in Medicine. Mar 2000; 39(1):36–43. [23] PROREC: please see http://www.eurorec.org. [24] Dixon R., Grubb P.A., and Lloyd D. Interim report to CEN. EHCR Support Action Deliverables 3.1 and 3.2. European Commission DGXIII, Brussels; Sep 1998. Available from http://www.chime.ucl.ac.uk/ HealthI/EHCR-SupA. [25] Dixon R., Grubb P.A., and Lloyd D. Guidelines on the interpretation of CEN EHCRA. EHCR Support Action Deliverable 2.4. European Commission DGXIII, Brussels; May 2000. Available from http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA.


173

[26] Schloeffel P, Ed. Requirements for an Electronic Health Record Reference Architecture. ISO/TS 18308: 2002. [27] Kalra D., Austin A., O’Connor A., Patterson D., Lloyd D., Ingram D. Design and Implementation of a Federated Health Record Server. Toward an Electronic Health Record Europe 2001, Paper 001: 1–13. Medical Records Institute for the Centre for Advancement of Electronic Records Ltd. [28] IBM Consulting Group Health Practice. GPCS Consultancy Report: Clinical & Administrative General Practice Computer Systems. Commonwealth Department of Health and Family Services, Australia; Sep 1997; Document ID: GPCSCR-1. [29] Beale T. The GEHR software architecture for a reliable EHR. Toward an Electronic Health Record Europe ’99. Nov 1999; 328–339. [30] Schloeffel P., Heard S., Beale T., and Rowed D. The Good Electronic Health Record (GEHR) in Australian General Practice. Toward an Electronic Health Record Europe ’99. Nov 1999; 340–346. [31] National Electronic Health Records Taskforce. A Health Information Network for Australia. Department of Health and Aged Care, Commonwealth of Australia; Jul 2000. [32] Heard S. The Good Electronic Health record: trial of a standard healthcare record in Australian general practice. Br J Healthcare Comput Info Manage. 2000; 17(1):24–26. [33] South West Devon ERDIP Evaluation Report Summary. Available from: http://www.swdhis.nhs.uk/ erdip/library/deliverables/EvaluationReportVol1.pdf. [34] Kalra D., ed. MEDICATE Disease Management System: Design Specification, System Verification and Administration. Available from: http://www.ehr.chime.ucl.ac.uk/docs/UCL-ComponentReport-M-v2 %201.pdf. [35] Kalra D., Ingram D., Austin A., Griffith V., Lloyd D., Patterson D., Kirstein P., Conversin P., Fritsche W. Demonstrating wireless IPv6 access to a Federated Health Record Server. Proceedings International Conference on Computational Science 2004, Krakow, Poland. [36] Kalra D. Lloyd D. Austin T. O Connor A. Patterson D. Ingram D. Information Architecture for a Federated Health Record Server, in Mennerat F. (ed.) Electronic Health Records and Communication for Better Health Care Proceedings of EuroRec ’01. Studies in Health Technology and Informatics 2002 Issue 87: 47–71. IOS Press. ISSN: 0926-9630. [37] Kalra D. Clinical Foundations and Information Architecture for the Implementation of a Federated Health Record Service. PhD Thesis. University of London, 2003 [Available from http://www.ehr.chime. ucl.ac.uk/docs/Kalra,%20Dipak%20(PhD%202002).pdf]. [38] Rossi Mori A., Kalra D., Rodrigues J.M. and others, Editors, Project Team 1-027. ENV 13606: EHCR Communications: Part 2 Domain Termlist. CEN TC/251, Stockholm; 1999. [39] Hopkins R. and others, Editors, Project Team 1-028. ENV 13606: EHCR Communications: Part 3 Distribution Rules. CEN TC/251, Stockholm; 1999. [40] Markwell D. and others, Editors, Project Team 1-029. ENV 13606: EHCR Communications: Part 4 Messages for Exchange of Information. CEN TC/251, Stockholm; 1999. [41] Kalra D., Freriks G., Lloyd D., Klein G., Beale T., Heard S., Schloeffel P., Maskens A., Mennerat F., Ingram D. Towards a revised CEN standard for Electronic Health Record Communication, in Brown P (ed) procs Mobile-Health Europe 2002. Medical Records Institute. April 2002. [42] Dolin R.H., Alschuler L., Beebe C., Biron P.V., Boyer S.L., Essin D., Kimber E., Lincoln T., and Mattison J.E. The HL7 Clinical Document Architecture. J Am Med Inform Assoc. Nov 2001–Dec 2001; 8(6):552–69. [43] http://www.hl7.org/Library/Committees/template/HL7v3templates33feb282005M1%2Ezip (Last Accessed 15 April 2005). [44] Waegemann C.P. Medical Record Institute’s survey of electronic health record trends and usage. Toward an Electronic Health Record Europe ’99. Nov 1999; 147–158. [45] Beale T. Archetypes – An Interoperable Knowledge Methodology for Future-proof Information Systems. 2000. Available at http://www.openehr.org/downloads/archetypes/archetypes.pdf. [46] Beale T. openEHR/ISO 18308 Conformance Statement. Available at http://www.openehr.org/ repositories/spec/latest/publishing/requirements/conformance/iso18308/REV_HIST.html.

174


The National Programme for IT in England Jeremy THORP Director of Development, NHS Information Authority Abstract. The National Programme for IT in England has been designed to support the modernisation of the National Health Service, and the Government aims of delivering a high-quality service designed around the needs of the patient. This article describes the architecture for the core component of the NHS Care Record Service including the application, information and security architectures and the requirements for supporting standards and technologies.

1. Introduction This paper provides an overview of the architecture developed to support the National Programme for IT in England. “The NHS Plan” (2000) set out the Government’s modernisation agenda and vision for the NHS. The fundamental premise is that the NHS is moving towards care services which: “offer people fast and convenient care delivered to a consistently high standard with services available when people require them, tailored to their individual needs.” 1 The aim is to transform the health and social care system so that it produces faster, fairer services that deliver better health and address health inequalities. A number of key service targets were identified as follows: •

Improve service standards – Max time for 1st O/P – 3 months by 2005 – Max waiting for admission – 6 months by 2005 – Max A&E wait – 4 hours by 2004 – Hospital appointments booked for patient’s convenience by 2005

•

Improve health and social care outcomes for everyone – Reduced mortality from heart disease – 40% by 2010 – Reduced mortality from cancer – 20% by 2010 – Reduced inequalities – 10% reduction in infant mortality by 2010

•

Improve value for money

2. The Scale of the Task The United Kingdom National Health Service (NHS) is a massive and hugely varied health service delivery organisation. In a typical week: 1

The NHS Plan.

J. Thorp / The National Programme for IT in England

• • • • • • • • • • •

175

1.4 million people will receive help in their home from the NHS 6.0 million people will visit their GPs More than 800,000 people will be treated in NHS hospital outpatient clinics 700,000 will visit a NHS dentist for a check-up NHS district nurses will make more than 700,000 visits Over 10,000 babies will be delivered by the NHS NHS ambulances will make over 50,000 emergency journeys NHS Direct nurses will receive around 25,000 calls from people seeking medical advice Pharmacists will dispense approximately 8.5 million items on NHS prescriptions NHS surgeons will perform around 1,200 hip operations, 3,000 heart operations and 1,050 kidney operations. Labs and associated services will provide results on millions of tests.

This equates to roughly 3 Million critical processes per day. If totally supported by a single electronic records system, this would result in approximately 30 million transactions per day on a 24 hour, 7 days a week basis.

3. National Service Frameworks The NHS is committed to moving towards more standardised and pre-booked models of healthcare. Where quality healthcare is delivered wherever the patient lives or seeks treatment. NSFs (National Service Frameworks) are leading the way in defining the care standards; Integrated Care Pathways (ICPs) are key tools in the implementation of these goals. NSFs have been produced for a number of conditions and patient groups (Cancer is included in this discussion) • • • • • • •

Cancer Mental Health Coronary Heart Disease Older people Children Renal Long Term Conditions

The NSF’s core aim is to increase the standard of care offered to patients. This is done by a variety of methods. • • •

Statements / recommendations of best practice Development of high level care pathways Changes in clinical practice/process (2 week wait for urgent Cancer referrals, Introduction of Rapid assess chest pain clinics, use of the single assessment process).

Each NSF has an information strategy. These are to monitor, audit and performance manage the NHS. The outputs so far have been • • • • •

Standardised audit reports Cancer 2 week wait reports MINAP data (Myocardial Infarction National Audit Project) Dataset production. Cancer Datasets, waiting times, minimum dataset.

176


Development of the NSF’s has been done with little or no assumptions of the IT to support them, or the impact that The NHS Care Record Service (NHS CRS) could have on improving Health Care.

4. National Programme for IT In recognition of these imperatives, the Government established the National Programme for IT (NPfIT) for the NHS, which comprises four major deliverables for meeting the requirements of the NHS Plan: • • • •

A robust infrastructure to support modernised health and social care, including a national approach to authentication, security and confidentiality; Electronic booking of appointments; Electronic transfer of prescriptions; The NHS Care Records Service (NHS CRS).

The implementation of the NHS Care Records Service is designed to enable the NHS to move away from the concept of a number of separate information systems based primarily around existing organisational structures towards a situation in which professionals are provided access to a single integrated service. The services will include access to records and the functionality needed to support clinical and care practice. Implementation of these services will lead to a number of important outcomes for: • • •

Service users – where a modern IT-enabled NHS will directly and visibly impact on how they interact with the care system and on their experience as consumers of care services Health and care professionals – involved with direct patient and service user care, who will have safe, fast, modern IT to support them routinely in their work Managers, researchers and other professionals – not involved in direct patient care to have ready access to high quality, confidential, information.

The requirements for such a service will continue to develop, and there is therefore a need for local flexibility and tools, and for commitment from suppliers to provide enhancements as part of the service.

5. Enterprise Architecture The NHS is a federation of organisations providing healthcare to people and they each have their own set of targets and priorities. However, in order to provide seamless care to the patient they have to collaborate with each other. These organisations and the way they need to work together represent the NHS wide challenges and there is a need an NHS Enterprise IT architecture that can respond to this. The following pages describe how such an architecture is being developed. It is critical to connect the IT investments to the expected and actual improvements in business performance. This connection is at the heart of the thinking in the National Programme. A requirements tracking system is being implemented; this will relate requirements back to specific business requirements and targets. The key principle is to have care services which are fundamentally designed around the patient/service user and their need for and receipt of care, and is not designed based on the institutions which make up the NHS and which are likely to undergo change. This will lead to service improvements, regardless of where care is provided, as per Fig. 1.


177

Figure 1. Each Care Sector Will Benefit from the NHS Care Record.

Figure 2. Process Flow for “Mary”.

The development of a plan for NHS IT must be based on a clear understanding of the core business processes undertaken within the NHS. The focus of the National Programme for IT is to improve patient care, and therefore the Programme components are based around operational use for clinicians and other carers. Figure 2 represents a “typical” process flow for a lady with a leg ulcer.

178


The range of services provided for patients consist of a set of generic care processes and activities that cover: • • • • • • •

Prevention (e.g. vaccination and immunisation programmes) Promotion (e.g. targeted advice on diet, lifestyle etc.) Screening (e.g. to enable early detection of specific diseases in at risk individuals) Surveillance (e.g. of vulnerable and at risk persons) Assessment, investigation and diagnosis Care planning Treatment and the provision of care and support, which may be: – Initial treatment – Maintenance or ongoing management of chronic conditions – Rehabilitation – Palliative and respite.

•

Care review and “discharge”.

The logical architecture for the NHS Care Records Service is therefore based around the application of these core generic processes across a range of care settings (eg primary care, acute care, etc.) and for a range of condition types (e.g. the National Service Framework areas such as Cancer as Coronary Heart Disease). This is illustrated in Fig. 3 below.

LSP E LSP C LSP D LSP A LSP B

Local Services

Information Reporting

Mental Health

Social Care

Acute Care

Primary Care

Information Capture

Community

150 - 153 Care Setting

User Environment

Generic Functions

Mental Health Older People

113 Prescribing

Cancer

110 - 111 Order Communications 101 User Tools 730 Information Governance

National Services

200 Personal Spine Information Service

211 Personal Demographics Service

360 Transaction & Messaging Service

106 Clinical Documentation

103 Prevention and Screening

1. NASP Core Modules

311 Clinical Spine Application

385 Secondary Uses Service

3. Other Application Services

Renal

104 - 105 Care Assessment, ICP’s

380 Terminology Service

CHD Children’s

107 Care Management

350 Spine Directory Service

B

Diabetes

Other Functions 114 - 115 Diagnostic Services

124 Analysis

160 – 168 NSF’s

Long-Term etc.,

730 Information Governance

780/440 Interfaces

770 Clinical Communications

2. NASP Standards & Interfaces

370 Workflow & Rules Service

769 ETP

N3

E-mail and Directory Service

NeLH

4. Other Service Providers

Figure 3. Logical Architecture for the NHS Care Records Service.

e-Bookings

179


Primary Care

eBooking

Pseudonymisation Service

Extraction Engine

PACS

ETP

Secondary Uses Services

Security Services

PDS

NHSmail

PSIS

User Directory

Transaction and Messaging Spine

London

North East

North West & West Midlands

Southern

Eastern

New National Networking

Existing National Services

New NASP Services

New LSP Services

Figure 4. Overview of Application Architecture.

6. Application Architecture The key to the National Programme has been to take the logical architecture and to define the national local components that form the physical architecture (Fig. 4). From this it may be seen that there are national components: • • • •

Networking, e-mail and directory services; National NHS Care Records Service; E-bookings; Electronic Transmission of Prescriptions.

At the local level, there are five clusters. Each has a Local Service Provider responsible for the local NHS Care Records Service, including primary care and PACS functionality. At the highest level there will be a single ‘virtual’ patient record. This record will be written, accessed and maintained by ‘local’ clinical systems as part of normal clinical care. Clinical information gained in one location will be available and ‘shared’ with carers with a legitimate relationship. Information from the clinical record will also become available for ‘legitimate secondary use’ so that clinical audit and evidence based care as well as commissioning and planning may all take place using the same high quality sources. Local clinical systems will perform to present to the user, according to context, role and experience, a view of a patient’s life-long record which is appropriate to them. Appropriate tools to allow the user to perform their task(s) will also be provided by the local system. The local system will assemble the record view(s) from local as well as remote sources. This assembly will be automatic and seamless so that the highest possible clinical care is delivered. To complement the ability to bring together all appropriate pieces of the clinical record will be a single knowledge and decision support framework ensuring equity of treatment, advice and activity. This same framework will also ensure accurate and appropriate application of NSF targets throughout the country.

180


7. Information Architecture Information in the NHS can be divided into four categories and these have different characteristics and are used by different sections of the healthcare community. • •

• •

Individual Patient Care centred information relates to a single individual user of healthcare services. It is a life-long store of relevant information for the treatment of that patient. Services Management, including administration, covers the provision of services to individuals, and the management of groups of resources as a whole. This covers a wide range of resources, including physical resources (beds, ambulances, theatres, devices) and people, that directly impact individual patient care. The management of resources as a whole includes financial administration. Clinical Knowledge: the base of knowledge built up over time, and providing best practice guidance including the specification of care standards and Care Pathways. Some of these are enforced by the specification and execution of ‘Business Rules’. Healthcare Quality and Performance Measures – information being largely available as a bi-product of patient care and used for the monitoring of healthcare quality as a ‘Secondary Use’.

Information that is to be made commonly available flows from local systems through to national systems – managed by the Transaction and Messaging Service. Information that is to be used for secondary purposes is forwarded to the Secondary Uses Service. Reporting processes utilise the Secondary Uses Service. The NHS Care Record is formed by the integration of patient-based information held in local systems and the systems that form the NHS Care Record Spine (PDS and PSIS). The patient’s NHS Number is key to this integration and is a requirement for any information to be part of an NHS Care Record. Clinical information must be encoded consistently and, for the purposes of individual patient care, this encoding is SNOMED CT. Information for other purposes may use the other approved encoding systems OPCS and ICD.

8. The NHS Care Record Elements The NHS Care Record Elements are blocks of information on which the NHS Care Record is built. The do not define the database structure, the screen layouts or the access routes to data. But they are a point from where these can be further defined. Work to define the NHS Care record has been on going from the inception of the National Program for IT. It was developed through the OBS and the requirements for suppliers (ICRS NASP and LSP). The elements are viewed from a clinical and non-technical view of the record. Clinicians will view the NHS Care Record from a number of places (Fig. 5) • • •

Via a current legacy application; Via a new NHS Care Record compliant system developed by LSPs; Via the Clinical Spine Application.

Users will log on to the Clinical Spine Application or local System, select a patient and a screen of patient data will be displayed. Data is then presented to the user under a number of elements. In the document, NHS Care Record Elements, we define these elements and any sub-elements and the relationships between them. The NHS Care record elements will guide the design of the PSIS (Personal Spine Information Service) and the navigation of the CSA (Clinical Spine Application). Messaging

181


Diagnosis 1 Diagnosis 2

Patient Work list

Diagnosis 3

Diagnosis

Diagnosis 4 Problems / Issues User Logs on

Select Patient

Verify Patient

Initial view of Patient record

Diagnosis 5 Detail 4a1

Plan Circumstances

Social Context Services

Detail 4a2 Detail 4b1

Encounters

Detail 4b2 Demographic look-up

Risk/Warnings

Level 1 Elements

Level 2 Elements

Figure 5. Access to NHS Care Record Elements.

required to populate the PSIS will need to conform to the structure of the NHS Care Record Elements. For LSPs there are a number of other considerations that need to be taken into account when relating the record elements with the systems to be deployed. We would expect that when presenting clinical data on patient record the NHS Care Record elements would provide the navigation structure. However, when supporting clinical and administrative workflow and data entry then the application needs to support the particular task in hand. We are also aware that LSP suppliers need to support the current situations as well as the future. We would expect that the suppliers will, as they develop their solutions, move toward supporting the structure outlined in this document.

9. Information Governance Traditional security models focus on the “bastion”, of impenetrable barriers keeping the undesirable away from that which is considered unsuitable, and maintaining the purity of that inside the “walls”. This model has moved in recent years towards a more flexible and dynamic model, supporting an overlapping of multiple security methods, primarily based upon the User’s role within the organisation. Neither of these models suits the NHS. Information Governance within the NHS is characterised by a multiplicity of highly complex, shifting, dynamics, which involve three principal characters: • • •

Clinicians; Administrators; and Patients.

This Information Governance Architecture takes a radical view of these necessarily entwined entities with the separation of User-centric Security Architecture from that of Patient-centric Confidentiality Architecture (Table 1).

10. Security Architecture The major security and usability principles underlying the choice of architecture are:

182


Table 1. Information Governance Architecture. User-centric

Patient-centric

Consent

Role Based Access Control (RBAC)

Sealed Envelope

Legitimate Relationships Security Architecture

Confidentiality Architecture

1. Seamless Logon. The architecture must lead to an ultimate goal of NHS users being able to login using the same credentials from any system access point. 2. Logon Resilience. No single point of failure should render the NHS network unavailable because of the inability to authenticate or authorise users. 3. Common View of Access Control Rights. Users should for the most part be given access control rights from a national standard set, though it is accepted that local variations may sometimes be needed. 4. Communications security. Patient identifiable data must be protected against communications eavesdropping attacks. In general this means that the data must be encrypted in transit.

11. Legitimate Relationships The Legitimate Relationships mechanism is used to ensure that only Users engaged in direct clinical care with the patient have the implied consent of the patient to access the patient’s data. Without such consent, the data cannot normally be accessed. Legitimate Relationships can be expressed with individuals or work groups. In the latter case, if an individual is a member of the work group, then the individual’s legitimate relationship with the patient is implied. Legitimate relationships can be created in any of a number of different ways: 1. by a clinician who has a legitimate relationship with a patient declaring that another user or work group has a relationship with the patient; 2. by a user acting in an role authorised to declare the relationship on legal grounds or for administrative or clinical audit reasons; 3. by an authorised user declaring that they themselves require such a relationship for patient care purposes. An example of this might be a clinician in a particular role in an Accident and Emergencies department; 4. by automatic means following the execution of system functions that result in a change in a patient’s care, for example a referral or transfer of a patient. Legitimate Relationships can also be removed in any of the above ways. Finally, access rights of competent patients who wish to see their own data could be modelled in terms of such patients always being considered to have a legitimate relationship with themselves. Suppliers developing applications, execution of whose functions will result in the creation and/or removal of legitimate relationships are responsible for ensuring that the necessary changes are made. They are expected to use a messaging interface to indicate the required changes. Legitimate Relationship specifications will be held centrally. The functionality supporting the recording and management of Legitimate relationships will be supplied and oper-


183

ated by the NASP. The technology supporting manual setting of Legitimate Relationships will be supplied by the NASP but, when deployed in an LSP cluster, managed by the LSP. The functionality controlling Legitimate Relationship data will receive Legitimate Relationship nominations through the messaging interface using message formats to be defined by the Authority. It is the NASP’s responsibility to ensure that such nominations are appropriately authorised and are not spoofed.

12. Confidentiality Architecture The concept of a Sealed Envelope has two distinct sub-components, the Patient’s Sealed Envelope and the Clinician’s Sealed Envelope. The Patient’s Sealed Envelope is a device which enables a patient to restrict access by individuals to certain parts of their record. This restriction could be implemented in either or both of two ways. Firstly, the patient could be required to select specific data items within their care record. The restrictions would then apply only to the selected items. Other data items, even if they are covering the same topic, would not automatically be sealed. Any subsequent copies of the sealed data item would be sealed, but already existing ones would not. This implementation involves marking the data in the actual record in some way to indicate its nomination by the patient. Secondly, the patient could be permitted to choose categories or types of data within their care record (“all data relating to this problem”, or “all data relating to this episode”). The specification of what is sealed would then be by data type rather than data instance and would be able to be managed separately from the patient’s record itself. It would therefore be able to be applied both retrospectively to past events and to data yet to be created. This approach requires that the data is given a type in the record that can sensibly be used to identify categories of data that fit most patients’ sealing requirements. The types of item that would be suitable for sealing are the subject of further work by the Authority. The Clinician’s Sealed Envelope enables a clinician to restrict access by an individual to certain parts of a patient’s record along similar lines.

13. Standards The NPfIT architecture is being delivered using open systems standards and leading-edge approaches and technologies. Within the Enterprise Architecture, standards are critical to enable the exchange of information and process collaboration, both locally and nationally. Standards therefore have been and are being defined to deliver maximum interoperability between the components of the architecture to support the operation of a seamless NHS. The standards for NHS nomenclature are illustrated in Fig. 6. It is important to note that the standards are interface/interoperability standards as opposed to product standards, such that there continues to be local choice around the applications implemented to provide functionality, provided that these applications support the standard nationally-defined interfaces. In order to better support the joined up care process around the patient journey, it is, of course, essential that much tighter integration exists in the proposed solutions than is apparent in the legacy systems today. The level of integration will therefore increase year on year as products and product sets develop, and the type of integration will move from data integration to functional and process integration.

184


Figure 6. The standards for NHS nomenclature.

NHS Service providers are contractually bound to support and comply with NHS-wide standards for data definition and interchange and are committed to the implementation and migration activities needed to support the uptake and use of these standards, both in the local systems implemented today and those that will be delivered in the future.

14. E-Gif The eGovernment Interoperability Framework provides a means to adopt the Internet and World Wide Web specifications for all government systems. A strategic decision to adopt XML and XSL as the core standards for data integration and management of presentational data is made therein and this includes the definition and central provision of XML schemas for use throughout the public sector. The e-GIF only adopts specifications that are well supported in the market place. It is a pragmatic strategy that aims to reduce cost and risk for government systems whilst aligning them to Internet Standards. The Framework also sets out policies for establishing and implementing metadata across the public sector.

15. Clinical Codes All new NHS systems are required to support SNOMED CT, however, currently implemented systems do not support SNOMED CT and will require substantial updates (to their data models, screens, reports and programs) if they are to be enhanced to support this standard.


185

In some cases, this investment will be appropriate as is the case for existing systems that are to persist and participate in the NPfIT architecture, however, for others, this will be either unfeasible or would not provide an acceptable return on investment and these systems will be phased out and replaced by NPfIT- compliant systems as soon as possible. A coherent approach to SNOMED CT development, systems’ developments to support SNOMED CT, user training in SNOMED CT and roll out of SNOMED CT compatible systems is being defined and it is recognised that existing clinical terminologies and classifications will continue to be used in the period of transition. Read Codes or Clinical Terms v3 (CTv3) are widely used in primary care and form the basis of the metrics on which General Practitioners will be paid. Early versions of Read Codes (4 byte) are still in use, but are not easily mapped to SNOMED CT as one code may incorporate more than one clinical concept (e.g. acute myocardial infarction and Cardiac Rupture). In these cases, the code and the term chosen by the clinician is required to be certain of the concept recorded. The messaging standards therefore incorporate both, such that semantic integrity is maintained. The International Classification of Diseases (ICD) is an internationally accepted WHO classification that assigns codes to diagnosis and procedures and is currently in its tenth revision. ICD10 is used for the central reporting of diagnoses relating to clinical activity and will continue to be so used until its successor is defined. The UK Office of Population, Censuses and Surveys have defined a classification of surgical operations and procedures, which is in its fourth revision (OPCS4), which is used in a similar way. There is ongoing work to define the appropriate successor to OPCS4.

16. Data Standards Messaging specifications define data elements and constraints on their values. In many cases, the definitions of the data and their allowable values are already defined in the NHS Data Dictionary. Since, the scope of the NHS CRS is largely clinical whereas the data dictionary is primarily administrative, additional definitions are required. The Communications and Messaging team is augmenting the data dictionary to cover these new areas and reconcile differences between existing NHS Data Dictionary standards and those of the HL7 v3 RIM. Of course, in addition to standard definitions of data items, it is necessary to tie down the domains from which the allowable values for data items may be drawn. These domains will be international standards, such as SNOMED CT, wherever this is possible and makes sense.

17. Messaging In order to provide a consistent approach to messaging, the Authority has embraced the HL7 version 3 international standard, in conformance with the strategic direction outlined by the NHS Information Standards’ Board. By moving data and communications standards development into an international standards environment, the Authority expects to benefit from international collaboration and achieve economies for both the Authority and information systems suppliers to the Authority. HL7 v3 is expected to provide considerable advantages to the Authority and its supplier organisations by lowering the cost of developing and maintaining interfaces, decreasing ambiguity and confusion, at the same time increasing the reliability of a consistent standard. The Authority is currently undertaking a programme of work to define the interopera-

186


NCASP

NWCS

Model

Clinical datasets

Data Dictionary

Data Model

Language

to TMS

Technical standards ( e.g. XML) Security

Protocols Messages

to GPs

Comm issioning datasets

Pathology results

HL7 v3 Messages

To be rationalised into a Single underlying model Reference Information Model

Terminology, Classification and Groupings, including SNOMED, ICD, NIC, HRGs and dm+d Figure 7. The relationship between terms, datasets and messages.

bility standards within the context of the HL7 v3 standard and its Reference Information Model (RIM). The relationship between terms, datasets and messages is illustrated in the Fig. 7.

18. Organisation Codes The coding of organisations is currently performed in several systems, the primary of which is the Organisation Codes Service (OCS) database, which provides the authoritative national lists for a wide range of NHS organisations and medical practitioners of interest to the NHS, both NHS and independent. NHS.UK provides a web interface to OCS, allowing OCS data to be viewed. The Directory will hold organisation details including organisation type, site, departments and work areas in addition to details of NHS staff, provided by local NHS organisations and it will become the repository for the content current provided through OCS.

19. Conclusion Contracts for the core elements of the National Programme for IT were awarded in late 2003 and early 2004. The Programme is now working closely with the successful suppliers to turn the architecture into live products. Implementation has been scheduled according to five phased releases, with the first components due to go live in July 2004.


187

Implementing Interoperable Secure Health Information Systems Persephone DOUPI a, Pekka RUOTSALAINEN a and Hanna POHJONEN b National Research and Development Centre for Welfare and Health – STAKES, Centre of Excellence for Information and Communication Technology, Helsinki, Finland b Rosalieco Oy, Helsinki, Finland a

Abstract. Ensuring the privacy and confidentiality of individuals has made security an indispensable component of health information systems. Delivery of healthcare services beyond the enterprise level to the regional, national or cross-border area places new challenges for security implementation. We review the current status and uptake of security measures in healthcare settings across European countries and examine in more detail some of the leading eHealth applications. Drawing on the findings of this analysis, we propose a generic model for streamlining the security implementation process on any level -local, regional, national or cross-border. Finally, we address the future prospects and requirements for advancing secure delivery of healthcare services across European borders.

1. From Healthcare Ethics to Health IS Security Ethical principles, such as confidentiality and the privacy of the individual, have traditionally acted as cornerstones of healthcare work. The need to ensure the observation of these principles in the relatively new context of the electronic and, more recently, online environment has made security an indispensable component of health information systems. Security includes all administrative, physical and technical measures intended to ensure the integrity of data and information systems, thereby safeguarding individuals’ privacy and confidentiality rights. All actions involving an individual’s health-related information (collection, storage, access, processing, editing, distribution etc.) need to be performed in a secure manner. The privacy of any patient must be respected and sensitive data, such as health-related data should not be made available or disclosed to any unauthorised individual or computer process. Security can be perceived in two related, but distinct levels: secure communication, consisting of secure connectivity and secure message transfer and secure co-operation in distributed systems based on networks or application security [1]. When thinking about the security aspects of communications, a useful concept is that of security domain. A security domain is an information processing area inside which a common security scheme, as well as common security services exist. Domains are characterised by the environment in which they operate, the technology they employ and especially the policy they apply [2]. The security policy of a domain covers legal, ethical, physical, organisational and technological dimensions. There are different complexity levels of security domains, each level requiring additional services for its support. In the context of healthcare, the most common security domain (a basic domain) is a healthcare unit or enterprise. The delivery of healthcare services

188

P. Doupi et al. / Implementing Interoperable Secure Health Information Systems

beyond the enterprise level to the regional, national or cross-border area places the emphasis on communication; therefore, the focus of this chapter will be on the considerations and factors relevant to strategic decision making for implementing secure communications in healthcare. We will first discuss the ethical framework, as well as the corresponding requirements defined in pertinent European and national legislation for the secure utilisation and functioning of information systems in healthcare. We shall then review the current status and uptake of security implementations in healthcare settings across European countries. Using case examples from the MEDITRAV Assessment project (IST 1999-11490, WP11) [3] we will examine in more detail how specific leading European projects have perceived and realised security measures. Finally, we shall present a model of the security implementation process from the perspective of a healthcare enterprise and discuss the challenges and future prospects of advancing secure health information systems to cross-organisational, cross-border settings. 2. The Ethical – Legal Framework 2.1. Principles of General and Professional Ethics The principles of general and professional ethics are grounded on concepts of civil rights, as they are reflected in constitutional provisions and national laws. The respect and protection of civil rights have influenced strongly the professional ethics of healthcare [4,5], where privacy and confidentiality have supported patients in building a trustful relationship with their doctors, as well as with other healthcare professionals involved in their care. Similar principles have been more recently reflected in the ethical codes and guidelines of professional associations in the health informatics field [6]. Some of the practical implications of these principles are the requirements to be fulfilled for the transmission of data to take place lawfully: • • • • • •

Necessity to establish the existence of a patient-doctor relationship in the online environment; Necessity to establish the relevance of the requested data and information in the context of the specific episode of care or encounter (need-to-know principle); Necessity to indicate and uphold the purpose of use of the collected or accessed data. Exceptions to the aforementioned requirements are: Emergency situations, or Explicit consent of the individual in question, provided that there is a means available to indicate and verify online the validity of the subject’s (informed) consent.

2.2. EU Legislation A number of EU directives have provided the starting point and scaffold for the legal framework of operations in the online environment, both in a broader scope and more specifically in the context of healthcare related actions. The most widely known and tonesetting document is Directive 95/46 on ‘the protection of individuals with regards to the processing of personal data and on the free movement of such data’ or what is commonly referred to as the Data Protection Directive [7]. In order to observe the requirements set out in the Data Protection Directive at the level of a single healthcare unit or enterprise (basic security domain), the services to be imple-


189

mented are those addressing basic security requirements (as defined in ITU-T x.805) and therefore also referred to as basic security services. These are: identification, authentication, access control, integrity, confidentiality, non-repudiation, accountability and audit. The implications of the Data Protection Directive in networked healthcare environments have been the subject of substantial analysis [8]. However, additional EU legislative documents – perhaps less explored in the healthcare context- also impact the design, planning and implementation of online healthcare services. These are: • •

• • •

EU Recommendation R (97) 5 on the protection of medical data [9,10] (Although not equally binding to Member States as the Directive, the recommendation is of interest because the provided guidelines elaborate further on the provisions of the Data Protection Directive, addressing explicitly and in more practical detail issues related specifically to the processing of medical data); EU Directive on e-signatures [11]; EU Directive on electronic communications [12]; EU Directive on information society services and e-commerce [13].

2.3. National Law and Regulations In the period between 1995 and 2000, national laws concerned with personal data protection have been amended and updated in order to conform to European law. Still, significant variability remains in the actual interpretation, implementation and monitoring of the provisions of the Data Protection Directive [14] meaning, in effect, that cross-border transactions should not be undertaken on the assumption of a clear legislative background. Furthermore, the legal framework in which healthcare services are delivered is created by a much wider array of applicable legislation, both generic (criminal and civil law, statutory, regulatory and contractual obligations) and healthcare-specific. In the case of Finland, for example, where the individual’s right to privacy is granted in the Constitution, the legal provisions having a bearing on healthcare practice activities include, among others, the following: • • • • • • • • •

Personal Data Act Act on the status and rights of patients (informed consent, right to restrict access, right to access own health data (not available in all countries). Act on Specialised Medical Care Health Insurance Act Pharmacy Act Act on specific nation-wide health registers (discharge register, cancer register etc.) Act on the privacy and security of telecommunications Act on healthcare professionals. Decree on managing and preserving patient information – Regulations on preserving times of patient records (addressed also in the Personal Data Act and the Act on the rights of patients).

2.4. Institutional Policies The general institutional policies of healthcare organisations constitute terms of reference for best practice. The main function of these policies is to translate the ethical and legal framework requirements to practical recommendations and guidelines that are in harmony with the everyday functioning and purposes of the specific organisation, taking into account its specific features and characteristics.

190


HIS

HIS

Application

Application

EHR

Secure data transfer

EHR

non-repudiation Query

Data processor

Response

• User rights • security policy • legislation • consent • data integrity • identification • external use of data (reimbursement, planning)

Data controller • security policy • legislation • access control and data transfer rules • authentication users and entities • data availability • role management • notary functions • signatures • encryption • audit logs

Figure 1. Basic roles and requirements in communication between security domains.

2.4.1. Communication Between Security Domains In the communication between security domains, there are two basic roles besides that of the data subject; the data controller and the data processor. (The Data Protection Directive defines also the roles of ‘third party’ and ‘data recipient’, although these concepts have not been reflected uniformly in the national legislation of all Member States). In principle, each healthcare enterprise should be prepared to satisfy the requirements of either basic role. A generic representation is provided in Fig. 1 and outlined below. •

•

•

The data controller has the responsibility to check that all necessary conditions for transfer of or access to patient data are met (e.g. established patient-doctor relationship, need-to know, consent for data processing, necessary identifications, restrictions set by the patient). The data controller has to check that the data processor has an acceptable security policy. Again, the acceptability of the security policy depends on the specific process to be executed and the requirements placed by the legal and ethical framework. If these are not satisfied, the controller should inform the patient before any data transfer or access occurs. The data processor should manage data following the rules for non-repudiation and confidentiality.

When two or more basic security domains intend to share information, in addition to basic security services, also infrastructural security services will be needed in order to facilitate open communication between enterprises and various users. Typically these requirements arise at the level of a regional or national domain when in addition to basic, enterprise-level security the following services will be needed: • • • •

Security policy bridging Inter-organisational identification Certification Privilege and role management services.


191

Cross-border communication forms the widest security domain, enabling the sharing of sensitive information in a trusted way over borderlines. At this level, services like security policy bridging, automatic security negotiation, cross-border identification, certification and health professional registration will be needed.

3. EU Countries and Implementation of Healthcare IS Security 3.1. Policy A national security policy regarding the utilisation of information and communication technology in general exists in all EU-countries (except Portugal). Most countries have implemented Directive 95/46/EC and have also set up a Data Protection office or authority. Laws defining the framework for use of digital signatures and certification services in accordance with EU guidelines have been enacted in most countries, except Poland where the relevant strategy is currently under development. Nevertheless, only few EU-countries, such as Denmark and the United Kingdom, have defined a national security policy specific to healthcare. In Denmark, the national healthcare security policy applies to hospitals, pharmacies, GP practices and patient information. The UK, within the context of the national programme for Integrated Care Records, has defined security requirements that will form the backbone of all future electronic health record (EHR) use in the NHS [15]. Germany has begun drafting a national security policy for healthcare. Finland has launched a national project to define the requirements for a secure e-health communication platform. Iceland has established a security strategy for the Icelandic Healthnet, while Luxemburg has installed its own HealthNet as a secure network for health professionals. At EU-level there is no harmonisation process in progress in this domain. 3.2. Infrastructure Many European countries e.g. UK, France, Italy, Finland, Denmark, Czech Republic, Germany (several of the federal states), The Netherlands and Slovenia are at advanced stages of design, development or implementation of their own solution for a secure healthcare platform. One of the national secure infrastructure candidates is Public Key Infrastructutre (PKI), with Finland and the UK already in the process of defining a national PKI infrastructure for healthcare. Many countries are also working intensively on using smart cards as security tools. Typically, smart cards are used for the identification of both patients and professionals but there are also plans to use chip-cards as a means of portable data storage (Germany and France). Germany and Finland have plans to implement second-generation smart cardbased identification systems for health professionals. Finland is also developing mobile phone-based identification and certification services for citizens. France is moving from the present Sesam Vitale implementation to the utilisation of second generation chip cards. Hungary has already implemented a smart health professional card and Estonia has established a national ID-card with e-signatures. 3.3. Networks Among EU-countries we encounter both healthcare-specific infrastructures and secure infrastructures that can be used for commercial, as well as health-related applications. The

192


Netherlands, Cyprus, the Czech Republic and Italy belong to the group having various sector-specific networks. Denmark, France, Iceland, UK, Luxembourg and Iceland have implemented a national secure infrastructure for healthcare. On the other hand, six of the EU Member States do not possess at present a secure infrastructure for healthcare (Greece, Portugal, Slovenia, Poland, Latvia, Lithuania). Countries that have already had long experience in enterprise-wide health information systems have initiated the process of connecting them in regional level networks of various configurations. In some cases these infrastructures are used only for one healthcare solution (e.g. a regional PACS system). Sweden, Norway and Germany have many secure regional healthcare networks, which are typically based on virtual private network (VPN) technology. Internet-based solutions are rare and usually limited pilots only. In Spain and Finland there are regional projects running where link directories are used to “connect” distributed legacy systems. The next logical step for countries where mature regional networks exist, such as Finland and Germany, is the interconnection of those regional networks to form a national network. In some cases national networks are already operational, as for example in Denmark, France, Iceland, Luxembourg, Norway, Sweden and the UK, although their configuration and ways of use differ substantially. Cross-border activity between these networks is presently very limited. 3.4. Data Availability – EPR Models & Communication Standards In today’s model, data is collected and managed by healthcare delivery entities. Therefore, we commonly encounter distributed enterprise-wide records inside each region. Methods are needed to interconnect them and produce a virtual record. It is possible to build a regional (Phase 1) or even national (Phase 2) virtual record using a “link directory” model. In this model the link repository can also be regional or even national. Regional links can be connected further with the help of higher-level repositories to form a national virtual record. Other alternatives are the creation of a centralised EPR repository or the use of an integration platform (middleware solution). With regard to communication, there are different solutions for making data stored in different information systems available securely beyond the local level. The most common approach is to send messages between different information systems. These messages are typically based on international standards like HL7, DICOM or EDIFACT. Sometimes also integration engines or brokers are used as a middleware to convert standard messages to another standard, e.g. HL7 messages to DICOM. Messaging is effective in point-to-point connections between two organisations, but tends to become more complicated as the number of interacting healthcare organisations increases. Another approach to access of information residing in another information system is remote web usage, which seems to be common in Scandinavian solutions. Healthcare portals are the third possible mechanism for integrating healthcare information systems in a secure and interoperable way. Portals can be regional, national or even international and they offer easy security and access management, single-sign-on, customisation and searching capabilities. Besides offering a central access and presentation layer, at its best a portal can be viewed as a framework for information systems, providing an underlying architecture that enables system consolidation, scalability and interoperability with built-in data and application integration technologies. There exists, however, a need for integration brokers and cross-platform certification for performing authentication and information exchange between different portals.


193

4. Case Studies – Findings of the MEDITRAV Assessment Project In the context of the MEDITRAV IST Project, the partners of Work Package 11∗ (which operated independently of the core project activities) undertook the task of conducting an assessment of the MEDITRAV platform and related technologies and services, comparing the approach adopted by alternative solutions in Europe. The total study period was nine months, from January to September 2003 and the main emphasis was placed on e-services, interoperability and security [16]. In addition to the platform proposed and developed by the MEDITRAV project itself, one regional system was assessed in depth (HUSpacs), while four other systems underwent a descriptive analysis (MedCom, Sjunet, SESAM Vitale and NHS Direct Online). In this section we present the main findings and conclusions of the assessment regarding the security aspects of the six systems we reviewed. 4.1. MEDITRAV At present, there is no common healthcare provision model in Europe, nor a pan-European service network that would facilitate monitoring and provision of required services to European citizens outside their country of residence. The main focus of the MEDITRAV project was on clinical aspects of healthcare provision to travellers, for persons with a chronic disease (such as diabetes, asthma, cardiac disease) who are frequently in need of healthcare services. More specifically, MEDITRAV aimed to explore the feasibility and requirements for a traveller’s information record (TIR) solution supporting clinical (medical) data availability across European countries. The intention was to address not only the technical, but also the organisational and managerial aspects of such a service, by involving all players that interact in the provision of healthcare services on the European level. In that context, MEDITRAV would also interface with initiatives focused mainly on administrative aspects, such as the electronic E111. Due to a number of unforeseen problems, the MEDITRAV project was unable to achieve most of the targets set at the beginning and had to narrow down its scope. Nevertheless, the challenges encountered by the project serve in bringing forward the real bottlenecks and obstacles of developing, implementing and delivering cross-border healthcare services. 4.1.1. Security Assessment Findings Technically the MEDITRAV platform is developed on recent technology (W2000 Server, Java script, C++ language, dynamic web structure creator on XML, SSL technology and XML Smart card technology) able to utilise available elements for logical security standard assurance. Taking into account all the time aspects and project organisation barriers, the model can be viewed as a sophisticated system achieving the designed features and able to be extended thanks to the open program architecture. Organisationally, the platform would require further feedback from clinical use, experiences on a broad user platform and efficiency evaluation for particular types of users. Given the fact that the pilot testing concerned a limited group of users and the implementation within the organisation structure of one hospital, no physical security strategy was demanded.

∗

Stakes, SchlumbergerSema UK and Hospital District of Helsinki and Uusimaa (HUS).

194


4.1.2. Commentary In the model proposed by MEDITRAV, issues related to patient privacy and confidentiality, access to data, as well as fitness of the proposed model to the legal requirements of certain countries warrant further investigation. For example, the card issuing authority is assumed to be the social security provider or a (private) insurance company. In addition, the card issuing authority can function as the host of the Central Web server – containing a database of patient records (TIRs), demographics and photograph, medical history (including lab and examination results), as well as administrative and insurance data. The implications, as well as the acceptability of such a configuration, particularly in a cross-border setting remain unclear. 4.2. HUSpacs (Finland) The HUSpacs (HUS: Helsinki and Uusimaa Hospital District) [17] is a regional information system focused on the digital archiving and handling of image information in a hospital district consisting of twenty one hospitals and several healthcare centres. The main goal has been to achieve a film-less imaging environment, so that all radiological examinations are digital standardised images that can be accessed anywhere throughout the network. The assessment took place in the HUS Cancer clinic and its focus was on data management methods used for preserving the confidentiality, security and sensitive nature of patient data. The aspects of interest were: confidentiality, integrity, authentication, nonrepudiation, access-control and availability. These aspects were studied through structured interviewing of various user groups at the Cancer Clinic (radiologists, nurses, clinicians in the chemotherapy clinic, wards and policlinics), system administrators and a representative of the software provider. Technical security aspects were studied with the application of a security criteria checklist. 4.2.1. Security Framework The data security policy document of the regional hospital network has been defined by technical specialists and has been approved by both the HUS management and a user representative. All employees have access to that policy, as well as to the security guidelines through the hospital Intranet. In addition, the security guidelines are also placed on notice boards. At the individual level, most health professionals have participated in training on data security and data protection principles and guidelines. However, it seems that there is big variety in knowledge and skills on data security. In the hospital environment the professionals are too busy to study guidelines during their regular working days. They need to have separate training and updated guidelines easily available. 4.2.2. Security Implementation – General Physically data security has been ensured using access control, backups are done at various locations, there is erasure of temporary data upon logout and there are plans for implementing a full logout when the user leaves his/her workplace. All external services are organised via a double firewall implementation and data encryption is performed between workstations and the server. At the logical level, a public key infrastructure (PKI) solution has been tested technically and will be taken into use in the near future, as well as e-signature and secure email encryption.


195

4.2.3. Identification, Authentication and Access-Control User profiles are used to specify the privileges of the users. That means that every employee has the privilege to use only those tools that are necessary in his/her work. All of the interviewed professionals use many information systems in their daily work. To each of these systems, they log in separately – a rather time-consuming procedure. Therefore the users sometimes leave a session running when they leave the workstation. In this situation, any other person who can enter the premises can use the open information system. If log-in procedures were faster, the security of the work routines would improve. In Finland the patient’s consent is required in order to access or transfer patient data from one organisation to another. HUS, the Helsinki and Uusimaa Hospital Region, is legally one organisation, so no consent is needed for transferring patient data between constituent healthcare organisations. However, consent is required when data is accessed outside the HUS region, (as is often the case in the Cancer Clinic that acts as a specialised treatment unit for the whole country). At present, consents are often faxed from one hospital to another. If the organisations were using interoperable information systems this could be done automatically and in a more secure way. Finnish law also states that it is necessary to be able to trace who has accessed patient data. In HUSpacs, every time that patient data is accessed the system records to a log file the data items that were accessed, as well as the time of the transaction and the IP address of the computer that initiated the transaction. 4.2.4. Integrity, Non-Repudiation Integrity means that data remains unchanged during data input, processing and transfer. Data integrity is principally ensured by the use of the HL7 standard. In addition, in the HUSpacs system users are not allowed to delete or modify the original images from the image archive. Non-repudiation means that those participating in the transaction cannot afterwards repudiate their participation. In HUSpacs, the log files can guarantee non-repudiation, although the distribution of log information into different files slows down performance. Indications of vulnerability in the system logs are taken into account in configuring firewalls and anti-virus systems and the data security standards are applied on a regional level. 4.2.5. Data Availability The data accessed in the HUSpacs system are mostly digital images. Because the images must be of as good quality as possible, they are saved with high resolution and they cannot be “packed” significantly with algorithms that reduce image quality. Thus the images take up considerable disk and archiving space and demand good data transmission facilities to make fast and easy access possible anywhere inside the hospital network. 4.2.6. Cross-Border Activities The HUSpacs project did not have any national or cross-border targets, but rather the aim was to provide a seamless access to radiological images in a hospital district environment. This goal was achieved, but the full potential of the underlying PACS infrastructure is not yet utilised. The regional PACS archive would facilitate building of superimposed valueadded services, i.e. consultation and second opinion services, remote guidance of imaging examinations etc. Exploration of the possibilities for building a so-called global reporting service, where time differences could be utilised to get 24/7 reporting of radiological images revealed a variety of obstacles, including uncertainty in legal and trade union issues. Another study

196


undertaken in the context of possible co-operation between HUS and East Tallinn Central Hospital also showed that there are still legal barriers in building cross-border imaging services. 4.2.7. Commentary The most important benefit reported by the users was that the HUSpacs-system helps to find the images. In earlier times film images were often lost, or difficult to access, many were distributed and stored in different places. Now all the images are in the archive and can be accessed there, while the problem of missing images has been minimised. It is important that images are accessible at the point of care and earlier imaging results of the patient are also available in the process of diagnosis or treatment. Improved access of images means also that patients do not need to come to the clinic many times, or carry their old images with them. This improves efficiency of the unit and convenience for the patients. Patient data security in HUSpacs is principally implemented following the legal and organisational regulations. Minor problems occur in the system e.g. with log files, confidentiality and authentication, which are expected to be overcome with the planned PKI-solution using healthcare professional cards. 4.3. MedCom (Denmark) The Danish healthcare data network, MedCom [18] is a co-operative national programme between authorities, organisations and private companies linked to the Danish healthcare sector. The aim of the programme that was launched already in 1995 is to enable electronic communication between all parties in the health and social sector – both administrative and clinical. Today more than 2.5 million messages are sent per month between different stakeholders and more than 3500 hospitals, pharmacies, home care providers, GPs and specialists are connected to the healthcare network. 4.3.1. Security Framework The security framework of MedCom is based on the national security standards DS-484-1 and -2, which have references to ISO 17799. There is a national agreement on the security policy for local networks, that network owners have to sign before they are allowed to connect to the national healthcare network. Although security policy is county-based (DS 4841 and 2 and local register regulations), the policies are quite similar and therefore have not caused any problems regarding communication. 4.3.2. Security Implementation – General Password-protection as well as firewalls are used as security measures against external attacks. There is no encryption as part of the EPR archive, neither during communication, except in VPN tunnels over the Internet. Plans for cross-border communication are based on the use of the Internet and XML. 4.3.3. Identification, Authentication and Access Control Registration services operate on a local level and it is also possible to provide user IDs to users from another organisation. A national data repository of healthcare professionals (LDAP) is planned, but not yet implemented. An EAN number is used for organisations and identification is contract-based. A unique patient number (the civil registration number of each patient) is used as key.


197

A national certification organisation will be established. At this stage, there is no certification policy available. The citizens’ PKI will be a soft certificate, but there are no plans for ID tokens for citizens. The responsibility for the access control policy implementation and management, as well as for privilege management is allocated to the local level. Role management is not available yet and access is password-based. Informed consent of the data subject is required for access and transfer of data. Currently, a medical doctor provides the indication of consent to the information system without any signature of the patient. Access to the EPR is monitored through audit logs. 4.3.4. Integrity – Non-Repudiation There is no defined integrity policy. At the time of the assessment, the EU e-signature legislation was not in use and e-signature technology was not yet employed in the context of EPRs. Currently e-signatures are being used, in connection to the recently launched healthcare portal [19]. 4.3.5. Data Availability Communication of data is achieved through open messages in a closed environment (VPN technology), without the use of encryption or integrity control. The mailboxes are created on the basis of contracts with telecom operators who are treated as trusted parties. The recipients can collect their messages from the mailboxes when desired. 4.3.6. Cross-Border Activities The MedCom targets did not originally include cross-border functionality, but recently there have been initiatives to connect MedCom and two other Scandinavian healthcare networks, namely the Swedish (Sjunet) and the Norwegian healthcare network. Two different categories of cross-border eServices for professionals have been planned: radiological consultations and remote guidance of ultrasound examinations for pregnant women. The model used is derived from the PICNIC project. The most critical issues when expanding to trans-national services are the following: •

• •

EDIFACT works well on the national level, but when expanded to cross-border communication on the European level different messaging schemes have to be considered. Either use of HL7-based messages must be considered as an option, or EDIFACT mapping services are needed. Strong authentication for professionals must be in use in both countries and crossplatform certification between different countries will also be needed. It is unclear how language issues will be dealt with in cross-border treatment and consultations (both in terms of the transfer and use of patient information and in terms of patient-professional communication). Also, the reimbursement scheme is not clearly specified.

4.3.7. Commentary The MedCom project did not initially have very specific targets regarding data security and privacy. By choosing a closed private network as a communication platform acute demands for encryption and strong authentication were decreased. The approach of delivering user rights to remote consultants for local web servers works relatively well, as far as the organisation that manages user accounts and access to services is concerned. However, as the range and diversity of available services increases, an individual user may need to have multiple account identifiers and passwords. This leads

198


to potential security problems because users might write down their passwords, or store them on the computer system. Strong authentication of professionals, combined with single sign-on would be preferred. In the process of migration to Internet and VPN technology, strong authentication of both professionals and citizens is recommended. This is also a prerequisite for cross-border communication. The citizen smart card would also facilitate the handling of patient consents. 4.4. Sjunet (Sweden) Sjunet [20] is the Swedish infrastructure for communication of healthcare data and services, including various forms of telemedicine. Besides a technical communication platform, Sjunet is also a co-operative network. Sjunet started in 1998 as a regional project between seven counties. Today almost all Swedish hospitals and primary care centres are connected to the network. Since 2001, Carelink, a collaborative organisation for ICT in Swedish healthcare, has been responsible for Sjunet in close co-operation with all the parties involved. 4.4.1. Security Framework A security policy has been defined on the national level but the responsibility for its implementation lies at the county council level. The contracts signed between Carelink and the respective country council list a number of security requirements and Carelink maintains the right to inspect their implementation. A certification policy has been defined on the national level, as well as a health professional registration policy comprised of a link meta-directory and CA services. 4.4.2. Security Implementation – General Sjunet is an IP-based, closed fiber-optical network, separate from the Internet. VPN technology over the Internet is used in external links; today only in the tele-radiological consultation link to Barcelona. The establishment of some further VPN links has been planned for 2004, mainly for small healthcare organisations and vendors. Firewalls are utilised in every Sjunet connection i.e. the county councils and other organisations have a firewall between their local network and Sjunet. Password protection is also in use and there is a security committee of Sjunet, as well as an incident response team. 4.4.3. Identification, Authentication and Access Control There is an ID policy for professionals primarily based on PKI certificates and at least in Uppsala also GSM technology is employed (using the mobile phone’s SIM card as a smart card). At the moment there is no ID policy regarding patient or organisational entities. The healthcare professional registration policy is local. In three counties professional smart cards are used and registration is performed locally. Regionally there are LDAP directories of employees, that can be accessed through the LDAP meta-directory available on the national level. Privilege management and responsibility of access control are assigned to the local level with passwords used as a access management method. The county councils deliver passwords also for remote consultants, both in Sweden and abroad (e.g. consultants in the telemedicine clinic in Barcelona). This means that some specialists can have several passwords if they give second opinions for many county councils. Usually the password provides access to external consultation servers that are located in a demilitarised zone, in the


199

firewall between the local network and Sjunet. In some cases, however, direct access to information systems is also allowed. In principle, patient consent is asked when transferring information beyond the county councils, but not for usage inside the region. 4.4.4. Integrity – Non Repudiation Software signatures exist in some applications, but not in all; for example, e-prescriptions are not signed. Auditing is performed in legacy systems, not on the Sjunet level. 4.4.5. Data Availability Sjunet itself does not encrypt data. Data encryption is performed by the applications, but has not been implemented as a part of the EPR archives. 4.4.6. Cross-Border Activities Cross-border tele-radiology services have been established with the Telemedicine Clinic™ in Barcelona: specialists in Spain provide remote reporting for three county councils in Sweden. One of the specialists is a Swedish doctor – licensed in Sweden – and therefore taking the responsibility of the reports. For the transfer of medical files, there is a VPN connection between a node in Sweden and the remote clinic. The current bandwidth is 2 Mbps. IPSEC tunnelling and encryption are utilised to provide private, dedicated connections between the sites. In the future, a PKI-solution for strong authentication will be used; today the access is password-protected. Reports are given in English or Swedish and archived also in English or Swedish as a part of the patient’s EPR in Sweden. The remote specialists have access to PACS consultation servers that are separate for each county council. It is also possible to guide examinations remotely. There is a lack of radiologists in Sweden and since the customers of this service have been most satisfied, the intention is to expand its offer to include other areas of Sweden. In addition, there are plans for cross-border services between Denmark, Norway and Sweden in the field of remote reporting in radiology and remote guidance of ultra sound examinations for pregnant women, as mentioned earlier. 4.4.7. Commentary Data security and privacy were important goals in the project from the very beginning. By changing from an Internet-based VPN network to a closed private network, security was further increased. Professional smart cards are used in the three largest county councils – not as a pilot, but in real production. The citizen smart card might encourage the development of eServices for the citizen also. The reasons for the decision to change the communication platform from VPN over the Internet –design to a closed private network were improved security and quality of service regarding the guaranteed minimum bandwidth. One of the underlying reasons might be Sjunet clients’ extensive utilisation of video communication in its various forms: this is a time critical solution not easy to run over Internet. There are three ways of communicating between professionals in Sjunet: file transfers, video conferencing and remote usage of consultation servers located in the demilitarised zones of the firewalls. The approach of delivering user rights to remote consultants for local web servers may lead to security problems when the range and diversity of available services increases and an individual user may need to have multiple account identifiers and passwords.

200


The Sjunet targets did not originally include cross-border functionality but recently there have been such. There are, however, some problems still to be solved: • •

• •

The remote professionals are not strongly authenticated There is no semantic interoperability regarding natural language. It is therefore unclear how foreign specialists can comprehend a consultation request and the background medical data (in Swedish), and conversely how the treating clinicians will interpret the consultation report. Same considerations apply to the patients themselves, who should also be able to understand the reports concerning their condition. It is not explicitly stated how the patient’s informed consent is obtained or whether and when it is needed in case of remote reporting. Issues regarding professionals qualifications and/or professional liability depending on country of registration and practice warrant further exploration.

4.5. SESAM – Vitale SESAM Vitale is a microprocessor card for citizens, used in combination with a healthcare professional card (CPS) to enable financial transactions in the French National Social Security system [21]. The CPS card represents a nation-wide identification that authenticates the owner by the use of cryptographic keys and digital signatures and ensures data integrity and confidentiality. The SESAM Vitale card contains the insured persons’ identification (currently the default are the members of a family, with individual sub-cards issued upon request) and administrative data (name, address, insurance company, insurance number, complimentary insurances etc.). The card is designed in such a way that it can only be read using secret keys from a CPS card placed in the same reader unit. The future Vitale Evolution card is planned to be personal and to integrate medical record data. The French IT security authority DCSSI has certified both the CPS and the Vitale cards as ITSEC E3 high level. There are today 357 000 CPS cards and 40 million Vitale cards in use, from two suppliers selected by open tender. Card administration is located in SESAM Vitale GIE, a nonprofit organisation financed by a co-operative of all health insurance institutions in France. The same organisation controls acceptance tests for software vendors and terminal manufacturers, and regulatory work for SESAM Vitale itself. 4.5.1. Security Framework To avoid fraud, healthcare professionals must be authenticated for all electronic transactions. In a similar way, patients must be authenticated and their insurance rights verified. In addition to these basic principles: • • • •

The integrity of the transactions must be guaranteed Both the practitioner and the patient must digitally sign the healthcare electronic forms The access to private data must be limited to authorised persons All network sessions must be protected for confidentiality every time it is necessary

Therefore, when the data processing system of the healthcare professional creates an eform it executes the following steps: • •

It authenticates both the patient and the healthcare professional It controls the insurance coverage of the patient


•

201

And finally adds the digital signature of both parties

Confidentiality is guaranteed through encryption of the information. For the medical record data envisioned for the next generation Vitale evolution card, the management of access rights will be more complex. Personal health data has to be shared with the authorised healthcare professional, while kept secret from anybody else. That is why the solution adopted verifies the information access rights of the professional card prior to the delivery of any private data. 4.5.2. Security Implementation – General The overall system is based upon the RSS (Réseau Social Santé) network, that is operated by CEGETEL, a French telecom operator. RSS behaves as an Intranet connecting the different health actors. It ensures the transfer of the electronic transactions (claims, refunding) between the healthcare professionals and the CPAM locations (CPAM: Caisses Primaires d’Assurance Maladie). The RSS allows also the exchange of information between professionals and secure access to medical databases. 4.5.3. Identification – Authentication and Access Control The card of the CPS family is an essential security component of all systems containing medical and administrative information. With the card, only the authorised persons can access the databases. Users can electronically sign each one of their transmitted messages, provided they are using a suitable application. The technical choices that enable the production of this signature offer better guarantees than the traditional paper-based method. The use of the card also enables confidential sending of data by encoding them. A stolen or lost card will be immediately revoked, and a new one will be sent. A card is blocked after three erroneous attempts at the PIN input and can the be unlocked with the CPS-Gestion program or by visiting the nearest Social Security office with the card and releasing code. Medical secretaries cannot use the CPS card of the professional in charge of a practice. They will use a “Carte de Personnel d’Etablissement” (CPE), which will enable them to carry out the authorised operations under the proper name. A retired doctor can also have a card. Holding a diploma is necessary and sufficient to obtain a CPS card. So, the fact of being retired does not withdraw the right to obtain a CPS. Before producing a card, the GIP “CPS” requests the control of the information by the proper authorities. Once these data are validated the GIP “CPS” can issue the card. 4.5.4. Integrity Because SESAM Vitale files are electronically signed and encrypted, they cannot transfer viruses to any direction. However, viruses, Trojan horses and intrusion can affect those programs that create, transfer and read SESAM Vitale files and damage them permanently so that they are no longer operational. Virus protection is recommended and for enhanced security, the workstation should be reserved for professional use only. 4.5.5. Data Availability SESAM Vitale FDS transmission is operated in such a manner that the doctor collects all claims to one payer in a ‘lot’ (which means that claims are not sent on-line, but rather per order). When the ‘lot’ is finished, it is encrypted with the doctor’s PKI-key and transferred electronically to a folder (‘fichier’) for transmission to its destination. There may be multiple lots and multiple folders in process.

202


The end-user’s system automatically sends folders to destinations where they are collected by a computer called Frontal. Frontal checks that folders are formally correct, and encrypted and signed with valid encryption keys of the identified doctor. Frontal will send an acknowledgement of successful receipt to the doctor if the folder is technically okey and all claims have the correct destination. If however something is wrong (packet damaged, doctor not known, wrong insurance company etc.) the system will send a negative acknowledgement to the doctor, allowing 48 hours for corrections. Depending on the cause, the doctor will then correct the problem and re-transmit those forms (in a new lot/folder). Finally, Frontal will transfer all accepted claims to the Insurance Company’s claims processing system for reimbursement. The doctor will receive information from the Claims processing systems via the Frontal servers, e.g. accepted/rejected claim, payment information etc. 4.5.6. Cross-Border Activities SESAM Vitale GIE has acted as project coordinator for a number of EU Smart Card projects such as NetLink and Transcard that are now completed and currently for the Netc@rds project, that is under deployment over the borders of several countries, including France, Germany, Greece and Austria. The Netc@rds project aims to become a Pan-European interoperable social security card-network combining the Netc@rd data set, smart card and secure network server. All connections to the server are planned on high-level security like SSL 3.0. 4.6. NHS – Direct Online NHS Direct Online [22] is an information web site providing health information and advice to citizens and patients of England. The web site is supported on a 24-hour basis by a nurserun advice and information telephone service, NHS Direct, where users of the site are referred if there are any uncertainties or indications for seeking urgent treatment. Wales and Scotland have their respective telephone services and corresponding web sites (NHS Direct Wales and NHS24), but there is co-ordination to ensure consistency in information provision across the UK. A privacy policy statement is available on the web site, disclosing its privacy practices. These cover the following areas: information collection and use, cookies, log files, links to other web sites and processing of user feedback. A secure, customised area of the web site called Healthspace is being piloted since 2003. Healthspace allows users to store information related to their health – such as their blood group, medication, allergies and medical appointments. It may also act as a mailbox for health news of interest to the user and for confidential e-mail responses from nurses to health information requests submitted to the site’s online enquiry service. Upon request, an e-mail alert service for medical appointments can also be activated. In the future, the area may also be able to give individuals access to their health records when these become available electronically. Healthspace is available exclusively to residents of England over the age of 18 and it is meant only as an information service, complimentary to the regularly provided services of qualified healthcare professionals. The service can be used anonymously, on the basis of a self-provided user name and password. Users can delete their information, but not their Healthspace account even if it would be empty.


203

The security statement of Healthspace indicates that information is encrypted and held in a secure location with restricted access. Connections are established using the Secure Socket Layer protocol and the site is being monitored to prevent virus attacks.

5. Streamlining the Implementation of Secure Health Information Systems 5.1. Background In crafting our way forward towards future developments, there are some useful lessons to learn from the experiences of currently running systems. A typical approach to the development of e-health applications has been to start from a functionally restricted application and after its successful local implementation to expand the application to cover other regions or the whole country. After this, the following step has been to try to use the already developed technological infrastructure to support additional applications. The findings we derived from the case evaluations presented in the previous section indicate that the described method does not produce the best possible results from the security point of view. In addition, expanding a solution based on restricted security services to cover the more demanding security requirements of cross-organisational applications is a rather complicated and costly way to proceed. As an example, it is relatively easy to get short-term benefits through the expansion of a closed point-to-point video consultation network without security services to cover the whole country. But later on, it is a challenging task to integrate more demanding services to the same network (e.g. to support home care). Ideally, the system architecture will be designed in such a manner that it can address both domain-specific and cross-domain security requirements at the same time. In the following sections we outline a generic model of the implementation process that enables the development of both local and cross-domain healthcare information systems fulfilling ethical, legal and normative security requirements. 5.2. General Principles As illustrated in Fig. 2, a number of factors impact the implementation of a secure health information system (HIS). The issues to be considered depend primarily on the level on which the IS aims to function (i.e. regional, national, cross-border) in combination with the intended system targets, particularly the processes or transactions in which the system will be used. Generally, the implementation process involves a sequence of actions that are described here in a ‘linear’, step-wise manner for the purposes of analysis. In reality, however, these steps are inter-related (as Figs 3 and 4 illustrate) and usually progress as parallel or overlapping processes. •

•

Step 1: Analysis of the relevant legal-ethical framework. The set of applicable requirements and provisions needs to be identified and analysed for each type of transaction the enterprise in question intends to embark on. This is a complex process, requiring close collaboration and expert input from the organisation’s legal and possibly ethics department, informatics experts and healthcare professionals. Step 2: Process Model of Data Management A process model of the data management inside the organisation, as well as between organisations (focusing on the transactions to be executed) can be constructed using a modelling language such as UML. For all states of a transaction or activity we have to indicate which data will be accessed, modified or transferred,

204


2 Legal frameworks and norms (de jure standards)

1 System Targets

5 Barriers

Secure HIS

(depending on implementation level)

Development and Implementation Process

3 Policies, Agreements (de facto standards)

4 Available Technology

Figure 2. Determining factors of a secure HIS development and implementation process.

•

•

for what purpose, by whom and to whom and at which stage of the healthcare process. Drawing on the results of the analysis in the Step 1, it is also necessary to identify which laws, regulations and/or security rules impact each activity. Step 3: Security Policy Building Definition of the organisation’s security policy, connecting the legal and regulatory framework requirements with the institutional policy regulations and the measures selected for their realisation (safeguards). If there are plans for transactions beyond the organisation’s boundaries or if the boundaries of the organisation are by nature cross-border, an extension of this step is required addressing the needs of interorganisational (or inter-domain) security policy and of negotiation means for the bridging of security policies with other organisation(s). Step 4: Selection of IT tools and services for security When defining the secure architecture the IT tools and services to be employed in the implementation of the organisation’s security policy must be identified and selected. The selection can be achieved by juxtaposing the security services and safeguards established during Steps 2 and 3 with the security services existing in the available architectures.

We shall now look in more detail and discuss issues pertinent to Step 3 and Step 4. 5.3. Security Policy Building 5.3.1. Enterprise (Single Domain)-Level Security Policy The security policy of any domain consists of several layers: generic principles, administration-dependent principles, technology-dependent guidelines and installation dependent measures [23]. Existing security management standards can be used as a starting point, such as the ISO 17799 (Code of practice for information security management) and CEN CR 14301 (Framework for security protection of healthcare communication).


205

Ethical and legal requirements Formal rules

Input data

Acti vity

Data transfer

Data transfer

Activity

Output data

Activi ty

Patient Risks Data processor Safegua rds leve l 1 Safegua rds le ve l 2

S E C U R I T Y L E V E L S

Security policy, needed security services and safeguards

Figure 3. Illustration of the security building process (integrating Steps 1 to 3).

Drafting the security policy of an organisation (Step 3 in our model) can be based on the results produced through the preceding Steps 1 and 2. Figure 3 illustrates the integration and interrelation of the first three steps of the model. The starting point is to have knowledge of all legal, ethical and normative security requirements applicable at domain and cross-domain level (as discussed in Section 2). Then, a process model of data management has to be constructed. For each single process (or activity) we have to define: • • • • • • •

Input data and its relation to the patient Who is processing data, why and for what purpose Which computer processes are processing data Pertinent security risks Legal and normative requirements connected to the processing of data in the context of the specific activity Possible special confidentiality needs Security and confidentiality requirements concerning the data transfer between processes.

After all activities have been analysed we can formulate our domain-specific security policy, including needed security services and safeguards. Security needs derived for any activity can be connected to selected safeguards, since different safeguards offer different security levels. Beyond the drafting of an enterprise’s security policy, methods and measures also need to be specified for the dissemination, monitoring and auditing of the policy, as well as for its regular update in response to changes in legal requirements, developments in technology and evolution of healthcare processes and practices. 5.3.2. Security in Inter-Organisational Communication The next step is to formulate a cross-domain security policy. The model described in Fig. 3 can also be applied for this purpose only in this case the different activities would belong to or be executed in different security domains. As a result, we will have to define additional

206


security requirements connected to cross-domain data transfer and sharing (see also Table 1). From these requirements we can deduce the needed security services and safeguards for cross-domain communication. The security policy determines the level of trust that must be achieved for communication between different security domains to take place. In addition, the security policy must outline the security services and mechanisms selected for the implementation of the selected level of trust. For example, if the security policy of a domain states that strong authentication is needed and PKI-services have been selected as the mechanism for its implementation, then existing certification policy standards can be used as a guideline: • • •

ITU-T X.800 series of standards (Security Architecture Framework) ITU-T X.500 series of standards (Directory services and Authentication), IETF X.509 RFC (Certification Policy and Certification Practice Statement Framework) ISO/TS 17090 (3-part PKI standard).

In the context of inter-organisational communication, the following aspects guide the process of creating an adequately secure environment. •

•

•

“Weak link” Phenomenon Avoidance In most eHealth applications, any data that is protected as securely as possible will always be vulnerable if one application does not observe the appropriate security standard and enables a tunnel for attack (hence the need for security policy bridging). Adequacy of ID Tokens Assuming different kind of platforms for eHealth, the following rule has to be applied: the less secure the platform used is, the more secure token for authentication must be demanded. An Internet-like, less secure platform will allow inexpensive eHealth services to expand which could wrongly tend to save costs for identification means. However, when two services need to observe the same level of data privacy, then the one operating on a less secure platform has to invest more in protection (authentication of accessing entities on one hand, outgoing data protection on the other hand) than the one operating on a secure protocol or through private communication channels. Primary discrimination of Applications or Services Level Standards should place different security level demands on e-Health services, in accordance with the kind of data these services process. Services could be then distinguished on the basis of data sensitivity classification groups as, for example, anonymous services, targeted services, shared services etc.

The security provided by various platforms can be assessed on the basis of existing criteria (such as the ITSEC compliance forecast). The results can also act as input for security audit guidance, a long-term and complex process ideally starting already at the initial phase of a project. 5.3.3. Security Policy Bridging Security policy bridging is the process through which the rules specifying the procedures and mechanisms employed by each organisation for the maintenance of its systems’ security are analysed and compared against those of the organisation or organisations with which it aims to interact in the process of healthcare services delivery. The results of the security policy bridging process will determine whether interaction is possible and under which provisions it can be completed.


207

Security policy, needed security services and safeguards

Selection of security architecture, services and safeguards

Needed non available security services or safeguards

Architecture 1

Security services

Safeguards

Architecture 2

Security services

Safeguards

Available architectures

Figure 4. Selection of the security architecture on the basis of available infrastructure.

The items that are considered in the policy negotiation process, the means through which these items are operationalised, as well as the methods by which the policy bridging itself takes place may vary, depending on the level of transaction (regional, national, crossborder) and on the existing infrastructure. The method most commonly employed today for security policy bridging is the negotiation of bilateral agreements or contracts, which takes place in the off-line, physical environment. Bilateral agreements are used both in the regional/national and, presently limited, cross-border setting since often there are no more than two parties involved. However, as the number of partners or organisations involved in the policy bridging process increases, the solution of employing Trusted Third Party services [24,25] might constitute a more feasible approach, particularly in cross-border applications where the complexity of policy analysis, comparison and matching is considerably higher. Establishing a secure environment for shared care without pre-defined sender-receiver relations, as in the advanced stages of cross-border communications, will rely on the use of future technologies and infrastructures –presently in very limited or experimental use– that will enable the use of dynamic negotiation between the interacting parties. 5.4. Selection of IT Tools and Services for Security – Defining the Secure Architecture At each operation level of a secure health IS – local, regional, national or cross-border – a number of choices need to be made regarding its architecture and its implementation within the corresponding security framework, as concisely presented in Table 1. Figure 4 represents the process of constructing and selecting a secure architecture. To build a secure architecture we have to analyse the security services existing in the available information system architectures and match those with our previously defined security policy requirements. In the case a mismatch exists, we have either to select another security architecture or add external security services to out system. Most commonly, the architectures used in the healthcare domain are either point-topoint or middleware approaches. The HL7 approach enables communication between any system regardless of their internal architecture. Principally, it is a point- to- point information interchange method. CORBA, which is based on the object-oriented paradigm, belongs to the class of middleware architectures [26].

208

Table 1. Matching of security requirements and corresponding tools depending on implementation level.

•

Security policy Item A patient-doctor relationship is needed Only those professionals who are participating to the explicit care process have the right to access

ENTERPRISE LEVEL Selected security level Strong identification 100% relationship control Only role based access control is allowed

•

Prevention of unauthorised use of information and system resources

Highest level

•

Non-repudiation proof of the integrity and origin of data

100% integrity of data data origin is proven no false data sender no false data recipient

•

Data confidentiality data is not made available or disclosed to unauthorised individual or computer process Data is not made available or destroyed in unauthorised way (during storing and communication)

Consent based data transfer Strong authentication of Individuals and entities All data will be encrypted

•

• •

Secure data preservation Long term preservation

Closed network, no Internet connection Notary e-archives

Security services Health professional registration services Health professional identification Services Privilege management Citizen identification Patient identification Audit logs Role-based access control Common privilege management Privilege distribution services Consent management Authorisation services Audit trail services Encryption services TTP-services for entities

Available tools LDAP-register

Encryption services Informed consent management

Digital signatures Qualified signatures DES, Triple DES, RSA Anonymization Digital signatures Qualified signatures DES, Triple DES, RSA VPN-networks Audit logs

Authentication services Encryption services Audit trail services Network monitoring

Encryption Data metafile management Data content management Archive management services e-water mark services audit-logs virus control

Hardware tokens Passwords Card-verifiable certificates Biometrics PKI certificates Access tables Additional passwords Pawn codes Privilege control software Access policy servers LDAP-directories Digital signatures Digital envelopes Time stamps Digital watermarks certificates

Digital signatures Organisational signatures (DES, Triple DES, RSA) PKI certificates


• • • • •

Legal – ethical framework Medical ethics principles International regulations National law & regulations Institutional security policy Rules for good practice

Table 1. (Continued). REGIONAL – NATIONAL LEVEL

•

Security level

Security policy item • •

Basic security items PLUS:

Security services

Tools Bilateral agreement Policy bridging repository Common registration register Common LDAP directory services Certificates PKI-key management VPN S-MIME SSL S-HTTP SOAP-messages Health professional cards PMI with privilege attributes PSW distribution

100% match is required

Security policy bridging services

•

Inter-organisational security policy matching Inter-organisational identification

Strong identification of organisations

National TTP-services

•

Communication security

Data integrity at 100% level

Encryption services Message sealing

•

• •

Legal – ethical framework EU Directives International legislation – agreements

Prevention unauthorised use of information and system resources from connected domains

Security policy item • •

National level items, PLUS:

No unauthorised access

CROSS-BORDER LEVEL Security level

National identification and authorisation services Common privilege distribution services Common privilege management Services Common role management services Security services

Bilateral agreement Policy bridging repository

Cross-boarder PKI-services Cross border ID-services

Bilateral agreements Automatic negotiation PSW-distribution Secure tokens VPN-networks SSL Soap envelopes Common certification register Linked certification registers Certification attributes

• •

Cross-border identification of users and entities

•

Communication security

1. 100% data integrity

Encryption services

Certification & registration of healthcare professionals

2. Utilisation of open networks in secure way 100% match of certifications

Secure e-mail services Encryption services Certification matching services

•

209

Security policy bridging

Security policy is equal or higher that data controllers policy Strong identification of all users and entities

Cross border security policy matching

Tools


• • •

Legal – ethical framework Medical ethics principles Institutional policies National law & regulations Requirements of EU legislation (possibly)

210


CORBA, HL7 and any other architecture can include security services in a varying degree. In the case of HL7 for example, we are speaking of application-to-application security services, including a very limited number of middleware services. Application-level security means that traffic is encrypted before it is submitted to the network or operating system [27]. Typically, application level security uses domain-specific security services. In the HL7 environment encryption services are needed in order to achieve communication security. One possibility is to store transferred data in secure envelopes. CORBA includes both domain-related and middleware services and provides a large set of security services (e.g. identification, authentication, authorisation, integrity protection confidentiality protection and non-repudiation). In the CORBA approach security is defined for domains and security functions are implemented through CORBA’s object request broker. CORBA RADS (Resource Access Decision Services) administrates access decision policies [28]. It also supports authorisation with dynamic attributes. In RADS the access decision object consults the policy evaluator modules responsible for interpreting access policy. Using the method we outlined in Fig. 1 it would be possible to derive policy rules for use by the RADS access policy evaluator server. In practice, the means and tools by which the security requirements will be fulfilled in the context of a system’s architecture largely depend on the status of the available infrastructure on a national level, as well as on its projected future development. In many cases, it will not be feasible to implement all required security services and safeguards at the same time and therefore a migration plan will be needed. If our security architecture has been defined from the beginning to cover not only local and regional, but also national and crossborderline communication migration will not be a problem. Besides the existing infrastructure, a number of other aspects that come into play in the selection and deployment of a secure architecture (and are related to the factors depicted in Fig. 2) are highlighted below. Costs Initial investment costs for the development and implementation of secure health IS and applications are considerable Therefore, cost will often be a deciding factor in the trade off between level of security desired and corresponding technological solutions adopted for its implementation. The absence of a clear framework for the reimbursement of founding costs of eHealth applications, as well as the insufficient funds made available for this purpose hinder the progress towards IT-enabled, networked healthcare practices. Interoperability and Standards It is well known that interoperability-related problems, both on the technical and on the semantic level, act as a barrier in the exchange and integration of data. Interoperability is relevant already in the context of one organisation, but as the examples from our case studies indicated when we progress to more advanced stages (regional, national, crossborder/international level), the complexity of the problems to be addressed increases while the feasibility of presently available solutions decreases. Standardisation has been promoted as a plausible solution to the problem of achieving the urgently needed interoperability and compatibility of hardware and software across countries and indeed, considerable progress has been achieved. A note of caution however; although standards are viewed as the necessary means to interoperability, the variability observed in the implementation phase when standards are actually adopted may often reproduce the problem they intend to solve [29]. User friendliness – User Acceptance Inadequate usability and reliability of technological solutions can also hinder the progress towards adoption of security services. Tools that are not user friendly and have not been


211

developed with a deep and clear understanding of clinicians’ everyday tasks, require too much effort and energy in order to be used, an investment clinicians are unwilling to make since it may compromise their main task, i.e. the provision of patient care. Given the multi-professional and multi-regional co-operation needed for e-Health to be realized, we should keep in mind that issues of user friendliness are also applicable to other end-users, beyond the strict health professional context. Education & Training of End Users There is a need to increase awareness and understanding of legal and ethical requirements in everyday practices and the way they translate into the provisions of the organisation’s security policy and the use of security measures and tools. Educating and training health information systems users on security matters should be an ongoing, continuous process. Acquisition of relevant skills and knowledge is an essential component of end user acceptance, but also of the effective observation of security provisions [30]. Conversely, training of information technology and computer specialists in understanding the ethical requirements and obligations connected to applications and practices in the domain of healthcare is of equal importance.

6. Secure European Cross – Border Communications: Present & Future 6.1. Status of Affairs Current implementations of regional and national healthcare information systems in Europe tend to focus on discrete areas, each with particular characteristics and demands. At the moment, there is no comprehensive solution functioning that would cover the full spectrum of eHealth applications [31]. Issues related to data security and potential infringement on citizens’ rights to privacy and confidentiality remain an overarching concern in the deployment of information systems in healthcare settings. Different solutions – both technically and conceptually- have been adopted as a response to these concerns. Overall, however, the levels of security implemented across European healthcare systems until now are generally low, signifying inadequate awareness of the corresponding needs and requirements. At the same time, this is also an indication of the restricted nature of existing systems that allows (at least at the early stages) the management of security concerns with less demanding means. Cross-border transactions were not envisioned and planned for at the phase of conception of most existing systems. As a result, cross-border level activities today are for the most part pilots with a lot of problems still unresolved, rather than established services. Still, as the trend and interest towards cross-border services is gradually increasing, revision and upgrading of policies, as well as adopted technological solutions will be required. Closed private networks seem to be a trend in today’s Europe. By choosing a closed private network as a communication platform acute demands for encryption and strong authentication are decreased. Closed networks also offer today better quality of service regarding guaranteed bandwidth. The next stages of the Internet and the more expanded use of PKI technology and crossborder platform certification are expected to solve a lot of problems and the transition from closed private networks to Internet platforms is anticipated. Strong authentication is an important prerequisite for cross-border communication, as well as a potential enabler for the adoption of eServices for the citizens.

212


6.2. Barriers Matters relevant to security aspects cannot be viewed independently of the general environment in which healthcare information systems are being developed and implemented. In this context, a number of other issues also beg attention and increased efforts for progress to be achieved. 6.2.1. Infrastructure For several countries infrastructure does pose a problem, albeit on different levels; from the poor condition of the basic telecommunication infrastructure, or the inadequate development of a nation-wide network dedicated to healthcare, to the insufficient maturity of PKI. Substantial investments and strategic longer term planning are needed to support crossborder activities. 6.2.2. Legal and Ethical Framework Harmonization In principle some form of uniformity exists on the regional level with regard to the ethical and legal framework (with the exception of countries where regions are clearly more autonomous). Still, on the national level, there is a need to upgrade existing legislation or to draft the necessary legal framework from scratch. European Union Directives have had considerable influence on national legislation and practices, but the national level adoption and implementation of the Data Protection Directive requirements remain parts of an ongoing process. Considerable variations have been identified in the understanding, definition and interpretation of such basic concepts as, for example, ‘personal data’, reasons for exemption from informed consent or the data subjects’ vital interests. Given the fact that the Directive was introduced with the intention to resolve precisely the problem of national level incompatibilities that was recognised after the introduction in 1980 of the Council of Europe Convention ‘for the protection of individuals with regard to the automatic processing of personal data’ [32] this observation underlines the need for continuous and enhanced efforts towards the harmonisation of the legal framework on the European level. 6.2.3. Interoperability – Standardization The lack of standardisation is a problem with respect to both the actual tools used and the collaboration between different organisations. In this context, the complexity of healthcare records appears to be one of the major issues. Agreements with regard to the patient data that needs to be collected and the means and methods by which it is to be exchanged are missing. The problem of incompatible formats (both for textual and image data) or of applications at large presents an often crucial challenge. In addition, issues of semantic interoperability – now relatively contained due to the limited use of detailed EPR data in transactions – will come steadily to the foreground with increased urgency. On the level of technology, interoperability problems do exist, but they are primarily a matter of co-ordination rather than lack of technological solutions. Areas where further research is required for the development of new solutions is that of automatic or dynamic identification of entities and individuals, a major enabler towards the achievement of ad hoc cross-border transactions.


213

6.2.4. Financing – Business Models One of the main barriers of eHealth are the problems associated with financial aspects. eHealth applications have yet to find a successful business model for their implementation and longer term sustainability and evolution. For some of the smaller European countries, implementing the changes and solutions associated with eHealth is an undertaking requiring capital investment and human resources that exceed national capacity. Furthermore, the cost of the telecommunication services required for their regular use is (at least in some countries) high and often there is no clear concept as to what should be the financing model. Additionally, reimbursement models for the users of eHealth services are absent in most countries. 6.3. Towards the Future There is still considerable work ahead before the vision of European-wide eHealth applications becomes a reality. Thus far, dispersion of efforts has had a negative impact on both the technological and the human perspective. The creation of a pan-European secure infrastructure is a major prerequisite in the development process. There is now a clear need for the definition of a national security policy for healthcare in all EU-countries that will be harmonised at EU-level. At the same time, the accumulated experiences across countries could inform the development of a set of clear and pragmatic guidelines for interoperable and secure healthcare information systems implemented at a national level, but able to support cross-border services delivery. As we progress towards the future, there is yet one point to keep in mind. Until now, most emphasis has been placed on creating the necessary infrastructure and services for use almost exclusively by and for healthcare professionals. New issues and requirements will emerge as services targeted to citizens and patients are becoming more prominent, particularly with regard to citizen access to and control over their health data.

Acknowledgements Parts of this document are based on the findings of the MEDITRAV Assessment study. The authors would like to acknowledge the contributions of the other members of the MEDITRAV Assessment Work package project team, as well as those of national experts on healthcare IT strategies and implementations. Also, the collaboration of system managers and users of the systems reviewed in the case studies is greatly appreciated.

References [1] Blobel B, Katsikas S. Patient data and the Internet – security issues. Chairpersons’ introduction. Int J Med Inform 1998; 49: S5–S8. [2] Blobel B. The European TrustHealth Project experiences with implementing a security infrastructure. Int J Med Inform 2000; 60: 193–201. [3] MEDITRAV Project Description. Available at: http://dbs.cordis.lu/fep-cgi/srchidadb?ACTION=D& CALLER=PROJ_IST&QF_EP_RPG=IST-1999-11490. [4] World Medical Association: International Code of Medical Ethics (1949, 1963, 1983). Available at: http://www.wma.net/e/policy/c8.htm. [5] International Council of Nurses: The ICN Code of Ethics for Nurses. Available at: http://www.icn.ch/ icncode.pdf. [6] IMIA Code of Ethics for Health Information Professionals, Available at: http://www.imia.org/English_ code_of_ethics.html.

214


[7] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 “on the protection of individuals with regard to the processing of personal data and on the free movement of such data”. [8] Dierks C. Legal and Social Implications of Health Telematics in the EU. In: Advanced Health Telematics and Telemedicine. The Magdeburg Expert Summit Textbook. B. Blobel and P. Pharow (Eds.) IOS Press, 2003. 143–148). [9] Recommendation No. R (97) 5 of the Committee of Ministers to Member States on the Protection of Medical Data. [10] Explanatory Memorandum to Recommendation No. R (97) 5. [11] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 “on a Community framework for electronic signatures”. [12] Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 “concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communication). [13] Directive 2000/31/EC of the European Parliament and of the Council of 8 June 2000 “on certain legal aspects of information society services, in particular electronic commerce, in the Internal Market (“ecommerce Directive”). [14] Analysis and impact study on the implementation of Directive EC 95/46 in Member States – Technical Annex. Available at: http://europa.eu.int/comm/internal_market/privacy/docs/lawreport/consultation/ technical-annex_en.pdf. [15] National Specification for Integrated Care Records Service. Consultation Draft, Department of Health, 2002. Available at: http://www.dh.gov.uk/assetRoot/04/07/16/76/04071676.pdf. [16] MEDITRAV Deliverable 11.2. “Towards a Secure and Interoperable European eHealth Platform”, Annex 2. Assessment Results. October 2003. [17] http://www.hus.fi. [18] http://www.medcom.dk. [19] http://www.sundhed.dk. [20] http://www.carelink.se. [21] http://www.sesam-vitale.fr/html/ps/index.asp. [22] http://www.nhsdirect.nhs.uk. [23] Gritzalis D., Kokolakis S. Security Policy Development for Healthcare Information Systems. In: B. Blobel, P. Pharow (Editors), Advanced Health Telematics and Telemedicine. The Magdeburg Expert Summit Textbook. Studies in Health Technology and Informatics, Vol. 96, IOS Press Amsterdam, 2003. [24] Katsikas S., Spinellis D, Iliadis J, Blobel B. Using trusted third parties for secure telemedical applications over the WWW: The EUROMED-ETS approach. Int J Med Inform 1998; 49: 59–68. [25] Blobel B. Advanced tool kits for EPR security, Int J Med Inform 2000; 60: 169–175. [26] Blobel B., Analysis, Design and Implementation of Secure and Interoperable Distributed Health Information Systems, IOS Press, Studies in Health Technology and Informatics, Volume 89, 2002. [27] Rubin A, Geer D and Ranum M., WEB Security Sourcebook, Wiley Computer Publishing, 1997. [28] Resource Access Decision specification, OMG. Available at: http://www.omg.org/cgi-bin/doc?formal/ 2001-04-01. [29] The application of ICT Standards. Phase 1: Defining priorities. ProEHTEL DeliverableD6/T1.2. December 2002. Available at: http://www.ehtel.org/SHBlob.asp?WCI=ShowD&F=english%2Fdti50670% 2FPROEHTEL-Del_06-T1.2-Application_of_ICT_Standards-Phase_1.pdf. [30] Rigby M. Protecting the patient by ensuring end-user competence in health informatics systems – Moves towards a generic health computer user “driving licence”. Int J Med Inf 2004; 73 (2): 151–156. [31] MEDITRAV Deliverable 11.1. “The State of ehealth in Europe”, March 2003. [32] Stanberry, B. Using and Sharing Health Information in the 21st Century. A Handbook for Information Governance, EHTEL , Thematic Group 6 (Law and Ethics) Report. Available at: http://www.ehtel.org/ SHWebClass.ASP?WCI=ShowCat&CatID=1.


215

Lessons Learned from PICNIC Manolis TSIKNAKIS a and Niilo SARANUMMI b a Institute of Computer Science, FORTH PO Box 1385, GR-71110, Heraklion, Crete, Greece b VTT Information Technology PO Box 1206, FIN-33101 Tampere, Finland

Health care professionals need to be able to reach information about a patient anytime, anywhere… We need a health information system that automatically gives health professionals access to the patient-specific medical knowledge required for diagnosis and treatment…to detect and prevent errors before they happen… Lack of timely information creates huge, unnecessary costs. Tommy Thompson Fmr. Secretary of Health and Human Services, USA NHII Conference 1st July 2003 Abstract. This chapter reviews the PICNIC experience from conception to its realisation and draws conclusions on several fronts. It puts PICNIC within the current framework of needs and requirements, summarises shortly its main contributions, and discusses its main contributions. Special emphasis is given to understanding the needs and requirements resulting from a fragmented ICT market and the implications and possibilities that PICNIC has created for a consolidation of the market.

1. Introduction Health care is a sector, which today experiences a number of pressures both from inside and outside. The continuing innovation in medicine and health care technologies expands the methods and tools available in health care. Combined with citizen empowerment the demographic changes of an ageing European population stretch the limits of what countries can afford to offer as services within their national health systems. Governments are confronted by the urgent need to find means to contain the rise in health care expenditure without compromising quality, equity and access. Consequently, new ways to organise and deliver health services are being investigated and experimented. Public-private partnerships in care delivery are emerging. Citizens and patients are given more responsibility in the management of their own health and chronic illnesses. Growing world evidence suggests that organized, networked systems of care, and not just competent health care providers, are imperative to address the new demands of health care. Organized systems of care include all levels of health care, the patient interaction

216

M. Tsiknakis and N. Saranummi / Lessons Learned from PICNIC

level, the health care organization and community level, and the policy level. All these levels interact and influence each other. Health care information systems are “a prerequisite for coordinated, integrated, and evidence-informed health care” [1]. Health information networks are increasingly used to facilitate the sharing of health care related information among the various actors in the field. This sharing of information resources is generally accepted as the key to substantial improvements in productivity and better quality of care, a stance strongly supported from the experiences reported in this book. Despite the need for integrated information systems, the efficient and effective management of change to overcome organizational and cultural issues has not been adequately addressed. The current urgent needs, as stated very vividly by Tommy Thompson, Former Secretary for Health and Human Services, USA, in the 2003 NHII Conference (referred to in the beginning of the chapter), are today confronting the health care authorities in most developed countries. It was the realisation of these urgent needs that prompted, something like six years earlier, the PICNIC consortium to conceive and develop the PICNIC vision. PICNIC begun its work based on the firm belief that innovation is rarely the result of random acts of creativity; rather it arises from a deep understanding of the changing environment and the implications of those changes for a given type of an organization. As a result, PICNIC devoted considerable resources to thoroughly analyze the changing health care environment, understand the drivers of change and predict the implications they will have on the Health care Delivery Entities (HDE’s). PICNIC’s focus was on the Regional Health Care Networks (RHCN), in other words, on inter-enterprise integration. PICNIC did not concern itself with how the enterprises, the HDE’s, are internally integrated. The same principles can be applied to integrating health care organisations at a national level and across national borders (Pan-European).

2. The Changing Environment Considering the dynamics in health care, the traditional system model of health care has emphasized hierarchical structures with strict separation of organisational responsibilities within the framework of health care. This hierarchy can be seen through the following points: • • • •

Strict organisational division of responsibilities between primary care (e.g., municipal GP-led health centres) and secondary care (e.g. regional or specialist-led hospitals). Geographical separation of patient care responsibility (e.g., within primary and secondary care). Separation of duties between different health care professional groups (i.e., physicians and nurses) and specialties as well as separation of patients from the care process. Separation between public and private care providers within the different levels.

In the healthcare information and communication technology context, these hierarchical divisions can be seen in the implementation and scope of information and communication systems used by care facilitators. Separation is actually amplified when exchange of information is considered. Conventional health ICT systems, supporting overall service provision, are centralized and follow these boundaries closely, while system interoperability is often minimal. Furthermore, direct patient access to electronic patient record information is typically minimal or non-existent. Similarly for professionals, the use of integrated ICT systems and services is restricted to their primary working facility.


217

This traditional system model faces several challenges and structural changes are unavoidable. For example, aging populations, limited resource allocations, increasing specialization in medicine requiring convenient consultation tools, and trends towards patient and non-physician empowerment drive the system towards the breaking down of strict organizational and other boundaries (e.g., towards process-orientation and ad-hoc networking) in the search for better results. As a corollary of empowerment, the role of the health care customer is changing from a passive user of publicly funded services towards that of an informed health consumer [2] that also has some buying power and decision making authority on what services to use. These developments result in an evolution from hierarchies to networks and from ICT systems to services and integrated service provisioning environments. For health care providers the evolution from hierarchies to networks breaks up stagnant and monolithic hierarchies into networks where each node in the network adapts its responsibilities as well as its resource allocations in a dynamic way. Such networks enable seamless care chains where information is handled in a process-oriented way and flows seamlessly between different nodes; process-orientation enables the specialisation of provider resources, which is a potential solution for increasing efficiency. The nodes of the model can represent both organisations and individual care process participants (i.e., health professionals and patient or consumers).

3. The Supply Side As discussed in detail in previous chapters the PICNIC project was set up to respond to the challenges arising from, among other factors, “Changes in healthcare delivery comprising the move towards clinical pathways and evidence-based care, provision of integrated health services (citizen-centred services, continuity of care or seamless care) across organisational boundaries and even extending care to outside the walls of care organisations and making the patient a member of the care team (especially in the case of chronic diseases), thus supporting the gradual move from care to health, or wellness management.” Co-operation and collaboration is central to health care organisations in providing services to citizens and patients. However, such collaboration and cooperation can not be imposed on these organisations. It is most likely that they will retain their autonomy and independence when they have come together to co-operate in the delivery of health services to their client population and collaboration will be determined by their mutual interests. HDE’s are expected to form trusted relationships first, and then use an appropriate technological infrastructure to integrate their processes, data, and systems. Therefore, this sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. Responding to such requirements is a challenging task. These requirements lead to a level of complexity of ICT requirements, which can only be met by companies with a sufficient size to provide the skills and service level required to cope with the complex, distributed and heterogeneous ICT environment in the health care sector of the future. In addition, to be able to provide turnkey solutions rather than just products, these companies should have a sufficient investment capacity to develop their technology and skills base. Further consolidation of the industry is therefore required. On the other hand, analysis of the supply side shows that today numerous fragmented actors offer local and partial solutions to the health care community. Although, a lot of investment has gone into this, first focusing on Enterprise Applications and their integration and later on regional networks (inter-enterprise integration), the results to date have been

218


relatively meagre. The European health informatics marketplace is still fragmented and ICT investment in health care lags behind other information and knowledge intensive sectors, such as banking. A strategically important issue therefore is the development of an open, scalable and evolvable Healthcare Information Infrastructure (HII) and the reference architecture needed to support it. The HII must primarily provide the framework for the effective integration of distributed and heterogeneous components, ensuring overall integrity in terms of functional and information inter-working, while advances in network technology should enhance and extend applications, rather than replace them or make the obsolete [3]. The HII must also be able to provide integrated support to clinical, organizational, and managerial activities, and in the near future to provide a single user interface for access to the global health carerelated information and knowledge space. Up to now, the lack of a common information infrastructure has prevented health care professionals from being able to mine and analyze disparate data sources. Similarly, the lack of a unifying architecture has proven to be a major roadblock for industry to develop interoperable and open solutions. In summary, today there is no unifying infrastructure or common standards for the technologies that most health care organisations need and use. This means that health professionals cannot share their data or benefit from the innovative services that are been developed by other health care professionals and organisations. The results and contributions that PICNIC has made must therefore be evaluated within such a complex and dynamic environment, taking into consideration also the contributions that PICNIC has made towards the European Health Informatics and Telematics industry. The following sections summarize briefly these contributions.

4. Contributions of PICNIC 4.1. The Regional Health Economy A significant conceptual contribution of PICNIC is the development of the notion of the Regional Health Economy (RHE). The definition of the RHE comprises a variety of ways that health care organisations in a region can collaborate. The important thing one must realise is the fact that health care organisations in a regional setting will continue to retain their independence and that their collaboration with each other will be determined by their individual interests. This also means that there may be competing interests, i.e. health care organisations offering similar services. The RHCN, therefore, needs to support and enable RHE’s of different organisational relationships. These range from a fully unified regional health care enterprise operating as one organisation with one common mission, strategy and management to health care organisations that exist as independent organisations but collaborate and share tasks in accordance with agreements or contracts that they negotiate. Consequently, the ICT technologies deployed by the health care organisations can be, and usually are, different. They will have different technology platforms for the integration of their respective enterprise applications. Due to the way they’ve been taken into use, it is probable that there is more than one technology platform in use in these respective organisations. Migration into a one common platform therefore is not a simple task. Furthermore, having a common platform depends on the will and coordinated actions of all involved organisations. Such a coordinated action of all actors in a RHE is very difficult to achieve. A regional health information network, therefore, will be developed through a process of selforganisation. The PICNIC view, therefore, is that a RHCN must be viewed as an Internet-


219

enabled, distributed system linking computational, data repository and data production resources to enable (real or virtual) organisations with geographically dispersed facilities to more efficiently use their resources. The task of the RHCN is to make data and information securely available in the inter-enterprise environment where it is needed, when it is needed and in the format it is needed. In achieving the above objectives, we see a need for: • • • •

Highly flexible and dynamic sharing relationships. The dynamic nature of sharing relationships means that we require mechanisms for discovering and characterising the nature of the relationships that exist at a particular point in time; Sophisticated and precise levels of control over how shared resources are used, including fine grained and multi-stakeholder access control, delegation, and application of local and global policies; Sharing of varied resources, ranging from programs and data to computers and, potentially sensors; Diverse usage models, ranging from single user to multi-user and from performance sensitive to cost-sensitive.

Therefore, a very important outcome of PICNIC is the postulation that there is not a single owner of a RHCN, implying that none of the organisations owns the RHCN. The ownership of the network of co-operating organisations in a n RHE will range from total “anarchy” (all are equal) to a regional authority kind of “big brother”. RHCN’s development, in most cases, depends on how the health care organisations can reach consensus and agreements on where to collaborate and where not. 4.2. The PICNIC Architecture The federative nature of the enterprises that collaborate in a RHE requires that the PICNIC IT services (the RHCN) can be created incrementally. The vendors need to be able to offer new IT services and the users need to be able to decide autonomously what IT services they subscribe. Enterprise applications of the healthcare organisations must be able to use the IT services with minimum interfacing. In enabling the gradual, un-coordinated development of the complex technological infrastructure required by a RHCN, the definition of a reference architecture becomes of paramount importance. An architecture, seen as a formal description of an information technology (IT) system, is organised in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. This type of multi-tier approach depends heavily on the existence of both generic and health care specific middleware services/ components, and imposes a level of common design that varies according to the actual composition of the platform. The PICNIC architecture includes both generic and health care specific middleware components and services. Health care specific components are needed, among other, for patient identification, indexing of health data, resource(s) location, authorisation, terminology etc., whereas generic components are required to support low level, platform dependent functionalities related to concurrency control, directories, event handling and notification, licensing, security (authentication, encryption, auditing, etc.), timing, transaction management etc. Key to the realization of the above vision is standardization, so that the diverse components and services that make up such a computing environment can be discovered, accessed, allocated, monitored, accounted for, billed for, etc., and in general managed as a

220


single virtual system – even when provided by different vendors and/or operated by different organizations. A significant, therefore, contribution of PICNIC is the definition of the final PICNIC architecture for the next generation RHCN, which is based on a RHE wide middleware layer providing messaging and common IT services. This middleware layer comprises the PICNIC IT services. 4.3. The PICNIC Components/Services Having defined the problem to which PICNIC was responding and the architectural framework required, PICNIC went on to define, in an open source framework, a significant number of the most critical services (components) required by the service scenarios selected for implementation. The analysis conducted, as part of PICNIC, identified health services, delivered commonalties in models and tools and established a common base for the development of generic tools and common software components. This process led to an initial high level description of components and the development of the actual specifications for those components selected to be deployed in more than one region and/ or application domain. The components delivered by PICNIC include the Clinical Observation Access Service (COAS) used for obtaining clinically significant information, the Collaboration Service (COLS) required to establish and manage a collaboration context that enables the active sharing of clinically significant information, the Message Broker (MEBR) used for providing message validation, transformation and routing using a set of built-in and/ or userdefined message formats and message processing rules, the Patient Identification Service (PIDS) used for enabling unique association of distributed patient record segments to a master patient index, the Resource Service (RESS) used for identifying available resources and the means for accessing them, the Shared Records Indexing Service (SRIS) used for managing indexing meta-information required for locating the distributed clinical information, the Shared Records Update Broker (SRUB) used for providing prompt and consistent propagation of indexing information to the Shared Records Indexing Server, the Terminology Service (TERS) required for the unified management of coded elements, and to support the transformation of messages or data records from one form or representation into another (mediation), and the User Profile Service (UPS) which is used to track the long-term interests of users and are used for maintaining personalised settings and preferences. These components, the process for the analysis of requirements, the selection of the functionality encapsulated in them and the definition of their boundaries is fully described in a relevant chapter of this book.

5. Benefits PICNIC delivered an open scalable RHCN architecture comprising a defined set if PICNIC IT services with web services based interfaces for the delivery of health services in a Regional Health Economy. The IT services were built using Open Source components. The results have been evaluated by real life regional pilots. Preliminary evaluation of services deployed in the PICNIC pilots indicates that organizations, patients, health professionals and industry have all benefited from the deployment and use of the services. Collaboration among providers and consumers of health care has improved and continuing education has become a possibility. The acceptance of services from medical staff and patients have resulted in a relatively high rate of health improvement, cost containment, improved quality of care and easier access to health services.


221

The PICNIC services have facilitated better accessibility of medical experts, allowed the optimization of material and medical staff resources, and rendered possible the education of patients on topics such as medical complications and technological advances. More specifically the observed benefits can be categorized as follows: Benefits for Healthcare Organisations HDE’s have benefited from the fact that they were presented with a complete plan on which they could base their strategy for the development of their information access policy. Expert opinion is available through RHCN services reducing the rate of patient referrals to the specialists. As a result, there has been a significant reduction in hospitalization days, loss of work days of family members and relatives, and duplication of unnecessary examinations. Significant productivity gains were observed in other pilots (eReimbursement). Benefits for Patients Access to care has greatly improved in all categories where eHealth services have been employed. The services allow instant access to medical expertise from remote and isolated populations. Health emergency episodes are remotely managed allowing experts to guide the responding staff in their management of the patient and facilitating access to care and, most importantly, access to care by a specialist. Benefits for Industry PICNIC’s open source approach has significant implications for the ICT industry. The distributed common IT service approach imposes a level of common design, which varies according to the actual composition of the platform. The higher the number of common IT services in the platform the more restrictions there are in the design of the applications. On the other hand, common IT services also make it quicker and easier to design and implement applications as they can utilise these common IT services. The PICNIC architecture enables the development of interoperable IT services across a wide array of environments, without precluding any programming model, while at the same time it provides a set of loosely coupled components and their interrelationships. It enables implementations that are scalable and extensible by (a) providing for modular components, each at a level of granularity appropriate to meet the other goals; (b) being sufficiently extensible to allow for future evolution of technology and of regional health economy goals; and (c) applying the principle of simplicity in the sense that it does not impose high barriers to entry for its intended audience.

6. Developing a RHCN: Lessons Learned Despite the ability of improving the efficiency and effectiveness of health care services, ICT can be utilized fully only if it is integrated with traditional health care. However, there are several technical, economic, organizational and behavioural barriers to the diffusion of information technologies in health care [4]. The deployment and use of PICNIC services in several RHCN’s faced several such barriers like conservative attitudes, questionable selfsustainability, unclear reimbursement systems, computer illiteracy among medical personnel, organizational structures not supporting ICT, and legal and social barriers to the exchange of patient information. The impediments to creating viable, integrated regional health economies and delivery systems that rely on computerized information revolve around the fragmentation problem:

222


many pieces of information, in many formats, on many platforms, in many stakeholder environments, in too many geographic locations. The technical issues in creating such an environment are only part of the problem, which PICNIC has successfully addressed. The other part of the problem relates to all those issues blocking the further development of the next generation of RHCN’s. They revolve around the organizational changes associated with the move towards an integrated RHCN. Large capital investment is required and the rate of return is often perceived as more uncertain than that on other investment alternatives. Other issues include the inability of management to adequately support the implementation initiative, failure to understand the range of services associated with continuum-of-care delivery systems, inability to overcome individual stakeholder resistance to allowing information to flow among all entities within the RHCN, and inability to convince major HDE’s in a region to accept a role as a team player in the integrated care delivery environment of a RHCN. Other barriers were implementation specific. They centred on the problems encountered by stakeholders in their transition to integrated service delivery within a RHCN. In the past, information has been considered proprietary. The development of an integrated RHCN supporting a range of eHealth services raise a key question: should access to information determine competitive advantage, or should information be made available among stakeholders so that market advantage is acquired through the creative use of information and not access to it? Ownership of patient information has been the subject of much debate. However, governing the stewardship of and access to medical information is the more urgent and practical issue. Legislation is required, which identifies the rules by which information can be shared, and provides guidelines allowing access based on the ‘need- toknow’ principle. The introduction of PICNIC services in a given regional setting required interconnected changes. Peckham [5] points out the importance of good communications within the organizations to achieve such an interconnected change in health service delivery. The U.S. Institute of Medicine in its report, “Crossing the Quality Chasm: A New Health System for the 21st Century” [6] acknowledges the need of an integrated health system based on self-organizing subsystems to achieve a shared purpose. Local adaptation, innovation, and initiative are essential ingredients for successful implementation of integrated RHCN’s. Horizontal and vertical channels of communication are required to address the new approach to health care. Given the complexity and diversity of health systems moving towards the new approach, improvements in health care systems must develop from within, from people who have the ability to change their behaviour based upon experience and reflection. Dawson [4] argues that the first step in achieving change is for those involved to realize that change is possible: “Work in health cannot be subject to mass standardization and detailed hierarchical control. It needs to be customized to the context. Unless there is local ownership and commitment to solve the inevitable problems which arise, to train and motivate the people in the front line of action, to assemble appropriate resources and support, then […] health indices are unlikely to improve.” An important lesson stemming from the PICNIC experiences is that to encourage change, a major part of implementation initiatives should concentrate on removing resistance through educational programs, establishment of new priorities and patterns of behaviour. In practice, however, regardless of careful management plans, hierarchies persist, relationships and technologies develop, and specialties become ingrained [7]. In this sense, PICNIC advocates that no one single organisation, or individual can claim ownership to the RHCN. Rather, RHCN’s evolve dynamically as users and organizations adapt to the changing requirements, formulate partnerships, and develop their sharing relations and policies that govern these relationships.


223

The complexity of the transition is huge, since full-blown regional health care networks are still in the embryonic stage in most countries, although significant national and international activities are underway. Examples of such initiatives include: •

•

•

•

•

In the USA, the Medicare Prescription Drug Improvement and Modernization Act (MMA) was signed at the end of 2003 including, among other new initiatives, important provisions for Health Information Technology (HIT). MMA requires the Centers for Medicare and Medicaid Services (CMS) to develop standards for electronic prescribing, which is expected to be a first step toward the widespread use of EHRs [8]. In addition, the MMA requires the establishment of a Commission on Systemic Interoperability to provide a road map for interoperability standards in order for the majority of the US citizens to have interoperable electronic health records within 10 years. In Canada, the Canadian Health Infoway, an independent, nonprofit corporation initiated, as the result of the Canadian federal government’s announcement in September 2000, to accelerate the development and adoption of modern systems of Information Technology (IT) in health care, aims to foster the development of secure and interoperable EHR systems across Canada. Its objectives are to develop mechanisms to enable consumers to access health information that they can use, to facilitate the work of healthcare providers through technology, and to create a unified network of electronic health records across the continuum of care. A more detailed presentation of the Canadian initiative can be found in this book. In England, the “The NHS Plan” in 2000 set out the Government’s modernisation agenda and vision for the NHS [9]. The fundamental premise is that the NHS is moving towards care services which: “offer people fast and convenient care delivered to a consistently high standard with services available when people require them, tailored to their individual needs.” More information of the derived architecture, common services, data and security standards can be found in this book. In Germany, the central associations of self-administration committed themselves in 2002 “to develop a new infrastructure for telematics on the basis of a general framework architecture, to improve and/ or introduce the electronic communication (electronic prescription, electronic discharge letter by the physician) and to introduce the former health insurance card as an electronic health card in the future” [10]. In Denmark, the origins can be traced back to the 90’s when the messaging network, Medcom was initiated. The infrastructure is now being completed by the creation of the national health portal (Sundhetsportalen). More information about this process is to be found in this book.

Similar national level HII initiatives are underway e.g. in Australia, Estonia, Finland, Ireland, Lithuania, the Netherlands and Scotland. At the international level several initiatives have similarly gained in support. In 2004, the EU Commission published a European eHealth Action Plan that encourages member countries to coordinate their actions in the HII creation [11]. At the standards setting and application area Dicom (medical.nema.org/ dicom.html) and Health Level Seven, HL7 (www.hl7.org) standards have been found to be useful in the implementation of the HII’s. One very important initiative that stems mainly from industrial stakeholders and end user organisations is the Integrating the Healthcare Enterprise initiative. IHE is based on the realisation that optimal patient care requires efficient and seamless access to all relevant information. However, and despite technology advancements, healthcare enterprises have not yet begun to realize the full potential of ICT to reduce medical errors, and enhance the overall quality of clinical care. To do so requires a framework for

224


information sharing that meets the needs of care providers as well as patients, while at the same time gains acceptance among the companies that build the systems they rely on. The IHE initiative comes at this point to provide a process for building a detailed framework for the implementation of standards. At the same time it tries to leverage the interoperability solutions in multiple domains (radiology, cardiology, clinical lab, enterprise) in order to enable an open, cross-vendor, interoperability framework, based on established standards (e.g. DICOM, HL7, etc.). The Integrating the Healthcare Enterprise (IHE) initiative (http://www.ihe.net/) offers a framework for information sharing designed to optimize clinical workflow. Systems implemented in accordance with IHE can streamline the flow of clinical information, reduce errors and improve efficiency. IHE strengthens the information link between different departments – for example, between referring physicians and consulting physicians - to enable the enterprise to function as a single unit in providing optimal clinical care. At the same time offers to vendors, IT departments, clinical users and consultants a common framework to understand and address clinical integration needs. Subsequently it delivers a clear path toward acquiring integrated systems and enables information technology specialists to concentrate on improving the core functionality of systems, rather than developing and maintaining redundant, point-to-point interfaces. The IHE Technical Framework is a detailed, rigorously organized document that provides a comprehensive guide to implementing the defined integration capabilities. The Technical Framework delineates standards-based transactions among systems required to support specific workflow and integration capabilities. The consequence that stems form PICNIC experiences, which is also supported by international experiences, is that if such integration strategies are to be realised in a reasonable time span a more ambitious level of IT investment than the current 1.2% is required [12]. Such an increase is key to gaining commitment from the industry and investors. This will require a paradigm shift in hospital management and healthcare authority policies, to consider ICT as a major strategic factor. PICNIC provides the roadmap for such a transition. It provides an elaborate analysis of the future health care environment in a regional setting. It has developed detailed use cases of the future services and has defined an architecture through which HDE’s can implement their information integration and access strategies. It has specified the most critical services of such and architecture in an open source model; thus it enables the consolidation of the ICT supply side accelerating the, much needed, information integration and access process.

7. PICNIC in Relation to the Future Scenarios of Individualized Care As we look into the future of post-genomic medicine and individualised health care and the new challenges we should ask whether there are lessons learned in PICNIC that can assist us in responding to the new requirements and challenges. So, let us briefly look into the future. A future scenario is described fully in [13] and part of it re-presented below. Imagine that for selected cancer patients, biopsies are taken before, during and after treatment, made anonymous and the analyses stored promptly in an accessible fashion. These biopsy samples are subjected to gene-expression and proteomic analysis, and these molecular data are also stored accessibly. Imagine also that the patient's data can readily be compared with those from other trials. And imagine that one can drill down into clinical and other databases in an intelligent search in hours rather than months. One end-point might be the rapid identification of individualized molecular profiles correlated with sensitivity or resistance to therapy.


225

This vision requires common standards of data storage at each level of investigation, new frameworks for cross-referencing terms and their biological contexts (‘ontologies’) between disparate types of data, and new bioinformatics tools to make it all practicable. The benefits? Quicker routes to identifying patients’ individual characteristics that make one treatment more appropriate than another; easier integration of genomics research into clinical trials; and much readier access by basic molecular and cell biologists to the early lessons that can be drawn from even a few patients, as well as from large-scale, randomized clinical trials.

Information arising from post-genomics research, and combined genetic and clinical research on one hand, and advances from high-performance computing and informatics on the other, is rapidly providing the medical and scientific community with new insights, answers and capabilities. The breadth and depth of information already available in the research community at large, presents an enormous opportunity for improving our ability to reduce patient mortality, improve therapies and meet the demanding individualization of care needs. While the goal is clear, the path to such discoveries has been fraught with roadblocks in terms of technical, scientific, and sociological challenges. The deluge of data that largescale sequencing, transcriptomic and proteomic studies have produced to date is a case in point. In addition to the immense volume, data collected using a variety of laboratory technologies and techniques are often published without the background information (method of capture, sample preparation, statistical techniques applied) that is needed to reproduce results. The situation is even more problematic in the clinical research domain, where data collection is still often performed on paper forms that differ from study to study, even when the same types of data are being collected. Rarely clinical biostatisticians are able to make good use of data collected on studies they were not directly involved with, largely due to incomplete or non-existent annotation and standardization of the information. This data problem has pushed the biological community to partition and compartmentalize their data for easy digestion and maintenance. While this approach worked in the past for simple systems containing a relatively small number of interactions, modelled by a small number of datasets, biomedical informaticians are finding it difficult to model more complex systems. The simplicity and digestibility of the compartments described above have made it almost completely impossible to cross compartmental boundaries without consulting an expert [14]. The repercussions of the compartmental approach have produced a bottleneck in the road to discovery. To make this more concrete, computational approaches to data analysis and discovery typically rely on formalisms in terms of syntax, context, and format in order to perform reproducible and consistent experiments (the backbone of hypothesis driven science). These formal definitions are severely lacking in the biological sciences.

8. HealthGRIDS Access to many different sources of medical data, usually geographically distributed, and the availability of computer based tools that can extract the knowledge from that data are key requirements for providing a standard health care provision of high quality. Various research projects in the integration of biomedical knowledge, advances in imaging, development of new computational tools and the use of these technologies in diagnosis and treatment suggest that GRID based systems can make a significant contribution to this goal. The benefits of improved access are raised to a new level, not merely enhanced by integration over a GRID.

226


GRID computing aims at the provision of a global ICT infrastructure that will enable a coordinated, flexible, and secure sharing of diverse resources, including computers, applications, data, storage, networks, and scientific instruments across dynamic and geographically dispersed organizations and communities (Virtual Organizations or VO). GRID technologies promise to change the way organizations tackle complex problems by offering unprecedented opportunities for resource sharing and collaboration [15]. Just as the World Wide Web transformed the way we exchange information, the GRID concept takes parallel and distributed computing to the next level, providing a unified, resilient, and transparent infrastructure, available on demand, in order to solve increasingly complex problems. GRID’s can be classified into Computational, Data/Information/Knowledge, and Collaborative GRID’s [16]. The goal of a Computational GRID is to create a virtual supercomputer, which dynamically aggregates the power of a large number of individual computers in order to provide a platform for advanced high-performance and/or high-throughput applications that could not be tackled by a single system. Data GRID’s, on the other hand, focus on the sharing of vast quantities of data. Information and Knowledge GRID’s extend the capabilities of Data GRID’s by providing support for data categorization, information discovery, ontologies, and knowledge sharing and reuse. Collaborative GRID’s establish a virtual environment, which enables geographically dispersed individuals or groups of people to cooperate, as they pursue common goals. Collaborative GRID technologies also enable the realization of virtual laboratories or the remote control and management of equipment, sensors, and instruments. Depending on the individual point of views, it may mean rather different things to different people. On the (bio)medical side, GRID application services are believed to be capable of fostering the emergence of a major new paradigm, the Non-hypothesis Based Medicine (NHBM), which will complement and extend the current Evidence Based Medicine (EBM). For our purposes a GRID is an Internet-enabled, distributed system linking computational, data repository and data production resources to enable (real or virtual) organisations with geographically dispersed facilities to more efficiently use their resources. GRID systems and applications aim to integrate, virtualise, and manage resources and services within distributed, heterogeneous, dynamic “virtual organizations”. The realization of this goal requires the disintegration of the numerous barriers that normally separate different computing systems within and across organizations, so that computers, application services, data, and other resources can be accessed as and when required, regardless of physical location. This definition is very close to the problems a RHCN is responding to, i.e. creating a virtual healthcare enterprise (a RHE) by allowing diverse, dynamic sharing relations among the participants in such a VO. GRID computing provides a novel approach to harness distributed resources, including applications, computing platforms or databases and file systems. Applying GRID computing can drive significant benefits by improving information access and responsiveness, and adding flexibility, all crucial components in solving the data warehouse dilemma. GRID computing, also, introduces a new concept to IT infrastructures because it supports distributed computing over a network of heterogeneous resources and is enabled by open standards. GRID (Services) Computing is based on an open set of standards and protocols (i.e., Open GRID Services Architecture: OGSA) that enable communication across heterogeneous, geographically dispersed IT environments. This effort is articulated through the Global GRID Forum GGF). Building on both Grid and Web services technologies, the Open GRID Services Infrastructure (OGSI) defines mechanisms for creating, managing, and exchanging information among entities called GRID services. Succinctly, a GRID service is a Web Service that conforms to a set of conventions (interfaces and behaviours) that define how a client interacts with a GRID service. These conventions, and other OGSI mechanisms associated with


227

GRID service creation and discovery, provide for the controlled, fault-resilient, and secure management of the distributed and often long-lived state that is commonly required in advanced distributed applications. Over the last two years GRID computing has undergone a significant shift towards the adoption of a service-oriented paradigm, and the increasing support for and utilization of commercial Web Services technologies. The Open Grid Services Architecture (OGSA) was a first effort in bringing GRID technologies and Web Services together. The recent announcement of GGF to base the implementation of OGSA on the forthcoming Web Services Resource Framework (WSRF) is a further significant step in this direction and will allow the utilization of standard Web Services technologies, which enjoy large scale industry support, for GRID computing. Future developments of GRID technologies will be characterized by a full adoption of the service-oriented paradigm and Web Services technologies, a complete virtualization of resources and services, and the increased utilization of semantic information and ontologies (cf. Semantic GRID) [17]. It is our view that, much of the work done in PICNIC in terms of (a) adoption of a service oriented architecture, (b) open standards and (c) the specification of the most important middleware services required for the implementation of a scalable RHCN, seen as a distributed virtual organisation, can be directly re-used in the new technological paradigm of GRID computing.

9. Conclusions Health care is characterized by shared and distributed decision making and management of care, requiring the communication of complex and diverse forms of information between a variety of clinical and other settings. These information needs of patients and health care providers should be anticipated and the information delivered in a timely and error-free manner to remote locations, maintaining communication, coordination and co-operation between users. Health care providers are all too often faced with incomplete information to guide clinical decisions. Patient history is said to be 90% of the diagnosis, but patient mobility among providers inadvertently scatters needed clinical information across multiple sites out of a physician’s reach. Our ability to link unaffiliated sites to share patient data with each other closes the information gap that has traditionally impaired the delivery of the highest possible quality of care. Our position is that the difficulties and failures of medical decision making in everyday practice are largely failures in knowledge and information coupling, due to the overreliance on the unaided human mind to recall and organize all relevant details. They are not, specifically and essentially, failures to reason logically with the medical knowledge once it is presented completely and in a highly organized form within the framework of the patient’s total and unique situation. In this context, the ability of health care professionals to be informed, to consider and to adapt quickly to the potential changes and advances of the emerging genomic-based medical practice, worldwide, is of crucial importance for future clinical decision making processes. Impaired access to clinical data outside a given health care enterprise is at the heart of the duplicative medical procedures that represent 10–20% of all health care expenditure by public and private payers. It is estimated that for medical imaging, such duplication, in the US alone, represents $9–17B annually (http://www.synfluence.com/mission.html). By developing integrated health care networks interconnecting and networking providers, we target this waste in a way that cannot be accomplished by other means. More impor-

228


tantly, we do so while increasing the timeliness and accuracy of care rather than restricting it. The PICNIC project responded to these urgent needs, which have since become increasingly apparent, and was instrumental in setting ways to achieve interoperability and information integration. Its service oriented architecture and open source approach become much relevant in the light of new technological frameworks (i.e. grid computing). So, as indicated in the introduction to this book, “Most of the work for a successful deployment of regional health information networks in Europe is still ahead of us, and we believe that the PICNIC project has shown the way in many respects”.

References [1] WHO. Innovative care for chronic conditions: building blocks for action (No. WHO/NMC/CCH/02.01). France: World Health Organization, 2002. [2] Deloitte Research. The Emergence of the e-Health Consumer, 2001). [3] M. Tsiknakis, D.G. Katehakis, S.C. Orphanoudakis. An Open, Component-based Information Infrastructure for Integrated Health Information Networks, in International Journal of Medical Informatics, Vol. 68, Issue 1–3, December 18, 2002, pp. 3–26. [4] S. Dawson. Managing, organising, and performing in health care: what do we know and how can we learn? In A.L. Mark & S. Dopson (Eds.), Organisational Behaviour in Health Care: the research agenda (pp. 7–24). Basingstoke: Macmillan.3, 1999. [5] M. Peckham. Developing the national health service: a model for public services. The Lancet, 354, 1999, pp. 1539–1545. [6] U.S. Institute of Medicine (IOM). Report: Crossing the Quality Chasm: A New Health System for the 21st Century, 2001. [7] Anderson, R.A., & McDaniel, R.R. (2000). Managing health care organizations: where professionalism meets complexity science. Health Care Management Review, 25(1), 2000, pp. 83–92. [8] T.G. Thompson, D.J. Brailer. The decade of Health Information Technology: Delivering consumercentric and information-rich health care, Framework for strategic action, Office for the national coordinator for health information technology, Department of Health and Human Services, and the United States Federal Government, July 21, 2004. (http://www.hsrnet.net/nhii/materials/strategic_framework. pdf). [9] UK NHS Information Authority, An information strategy for the modern NHS 1998–2005, A national strategy for local implementation, July 2001, (http:// www.nhsia.nhs.uk/def/pages/info4health/contents. asp). [10] T. Gottfried, W. Dietzel, C. Riepe, Modernizing healthcare in Germany by introducing the eHealthcard, Swiss Medical Informatics Journal, 2004, No 52. [11] Communication from the Commission to the Council, the European Parliament, the European Economic and Social Committee and the Committee of the Regions. e-Health – making healthcare better for European citizens: An action plan for a European e-Health Area. COM (2004) 356, Brussels, 2004-04-30. [12] Deloitte & Touche. (2000). The emerging European Health Telematics industry; market analysis.: Prepared for the European Commission-Directorate General Information Society. [13] Nature. Making data dreams come true. Editorial, Nature 428, 2004, p. 239. [14] J.R. Nevins, E.S. Huang, H. Dressman, J. Pittman, A.T. Huang e M. West, “Towards integrated clinicogenomic models for personalized medicine: combining gene expression signatures and clinical factors in breast cancer outcomes prediction”, Human Molecular Genetics, vol. 12, 2003, pp. 153–157. [15] “Next Generation GRID(s)”, European GRID Research 2005–2010 Expert Group Report, 16th June 2003, (http://www-unix.GRIDforum.org/mail_archive/ogsawg/pdf00024.pdf). [16] I. Foster, C. Kesselman e S. Tuecke (2001) “The Anatomy of the GRID: Enabling scalable virtual organizations”, International Journal of High Performance Computing Applications, 15(3), 2001, pp. 200–222. [17] M. Cannataro and D. Talia. “Semantic and Knowledge Grids: Building the Next-Generation Grid”, IEEE Intelligent Systems (ISSI-0095-1203) – Special Issue on E-Science, 19(1), 2004, pp. 56–63.


229

Glossary of Terms Term

Definition

Application

A complete, self-contained program that performs a specific function directly for the user. This is in contrast to system software such as the operating system kernel, server processes and libraries, which exists to support application programs. 1 Design, the way components fit together. 2 An arrangement of components intended to fulfil some need. [Tuttle, 1994]. 3 The fundamental organisation of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution [ANSI/ IEEE Std 1471-2000]. A property of a real-world object which can be characterised by a set of values. Information about a patient, relevant to the health or treatment of that patient, that is recorded by or on behalf of a healthcare professional (ENV13606-1). System for recording, retrieving and manipulating information in electronic health records. (see also application).

Architecture

Attribute Clinical information Clinical Information System Component Component architecture

Coupling

Domain information model Electronic Health Record (EHR)

Enterprise Federation

Health information infrastructure Healthcare agent Healthcare organisation Health Service Identifier Information Interface

An object adhering to a component architecture. A notion in object-oriented programming where “components” of a program are completely generic. Instead of having a specialised set of methods and fields they have generic methods through which the component can advertise the functionality it supports to the system into which it is loaded. This enables completely dynamic loading of objects. The degree to which components depend on one another. There are two types of coupling, “tight” and “loose”. Loose coupling is desirable for good software engineering but tight coupling may be necessary for maximum performance. Coupling is increased when the data exchanged between components becomes larger or more complex. Conceptual model describing common concepts and their relationships for communication parties required to facilitate exchange of information between these parties within a specific domain of healthcare (ENV13606-1). Health record in computer readable form. A longitudinal record of an individual’s health and healthcare – cradle to grave. Note: Other names used in this context include EHCR for electronic healthcare record in computer readable form (ENV13606-1) and EPR for electronic patient record and PHR for personal health record. A voluntary community in which administration is a co-operative activity on a peer to peer basis. Principles: freedom to join, freedom to leave, subject to agreed obligations, retain significant autonomy, no single administrator. (See also coupling). Infrastructure for health that provides shared resources for healthcare agents and patients enabling information to flow in an appropriately structured, identifiable (unambiguous) and secure way. A healthcare person, healthcare organisation, healthcare device or healthcare software component that performs a role in a healthcare activity (ENV13606-1). A structured grouping of healthcare agents involved in the direct or indirect provision of health services to an individual or to a population (ENV13606-1). Service provided with the intention to directly or indirectly improving the health of the person or population to whom it is provided. Attribute used for identification. Thing told, knowledge, (desired) items of knowledge, news. A boundary at which interaction occurs between two systems, processes, etc.

230

Integration Interoperability

Middleware

Open Source

Patient Person (patient) identifier

Platform

Server

Service Software Broker Software Component

User

Glossary of Terms

Combination of diverse application entities into a relationship which functions as a whole. 1 A state which exists between two application entities when ,with regard to a specific task, one application entity can accept data from the other and perform that task in an appropriate and satisfactory manner without the need for extra operator intervention. 2 The ability of software and hardware on multiple machines from multiple vendors to communicate. 1 Implemented service specifications that, typically, support open and distributed computing. 2 Software that mediates between an application program and a network. It manages the interaction between disparate applications across the heterogeneous computing platforms. The Object Request Broker (ORB), software that manages communication between objects, is an example of a middleware program. 3 The term middleware is used to describe separate products that serve as the glue between two applications. It is, therefore, distinct from import and export features that may be built into one of the applications. Middleware is sometimes called plumbing because it connects two sides of an application and passes data between them. Common middleware categories include: TP monitors, DCE environments, RPC systems, Object Request Brokers (ORBs), Database access systems, Message Passing. A method and philosophy for software licensing and distribution designed to encourage use and improvement of software written by volunteers by ensuring that anyone can copy the source code and modify it freely. The term “open source” is now more widely used than the earlier term “free software” (promoted by the Free Software Foundation) but has broadly the same meaning – free of distribution restrictions, not necessarily free of charge. There are various open source licenses available. Programmers can choose an appropriate license to use when distributing their programs. The Open Source Initiative (www.opensource.org) promotes the Open Source Definition. Person who is the subject of health action. A means to provide positive recognition of a particular individual (patient) for all people in a population. A universal healthcare or patient identifier provides the identifier for use in healthcare transactions. Specific computer hardware, as in the phrase “platform-independent”. It may also refer to a specific combination of hardware and operating system and/or compiler, as in “this program has been ported to several platforms”. It is also used to refer to support software for a particular activity, as in “This program provides a platform for research into routing protocols”. A computer program that provides services to other computer programs located in the same or other computers. The computer that a server program runs in is also frequently referred to as a server. Work performed (or offered) by a server. A software program that acts as an intermediary for others. A unit of composition with contextually specified interfaces and explicit context dependencies that can be deployed independently and is subject to third-party composition. In the context of this document a component may run on one or more servers to offer a health service. (See also component). 1 A human being using the system to issue requests to objects in order to get them to perform functions in the system on his behalf. [OMG97]. 2 A person or a process who accesses a computer system. [O’Reilly, 1992].

Glossary of Terms

Abbreviations and Acronyms Abbr.

Description

ASP CDA CEN COCIR

Application service provider Clinical Document Architecture Release 1 and Release 2, www.hl7.org European standards organisation, www.tc251.org The European coordination committee of the radiological and electromedical industry, www.cocir.org Common object request broker architecture Microsoft’s object technology Evidence based medicine European Association of Radiology, www.ear-online.org Electronic Data Interchange for Administration, Commerce and Transport Electronic healthcare record architecture [ENV 13606, a CEN prestandard] General practitioner Digital telephony standard Health information infrastructure Healthcare Information and Management Systems Society, www.himss.org Healthcare information system architecture [ENV 12967, a CEN prestandard] Health Level Seven Inc. (ANSI accredited standards development organisation), www.hl7.org Hypertext markup language Information and communication technology Intensive care unit Interface definition language Institute of Electrical and Electronic Engineering, www.ieee.org Integrated health environment, initiative of RSNA and HIMSS Internet interoperability protocol Information technology and management International standards organisation, www.iso.org Internet service provider Information technology International telecommunication union Instant messaging system, based on XML, available in open source Java 2 Enterprise Edition Proprietary programming language Laboratory information system Middleware National health advisory board, part of the management structure of PICNIC Organisation for Economic Co-operation and Development, www.oecd.org Object Management Architecture Object management group Personal digital assistant (handheld device) Public key infrastructure Resource Description Framework [W3C standard] Regional healthcare network Regional health economy Reference information model, part of HL7’s object oriented Version 3 standard Remote method invocation Reference model of open distributed processing Remote procedure call Radiological Society of North America, www.rsna.org Rational unified process Structured graphic markup language Simple object access protocol [W3C standard] Transport protocol most commonly used in the Internet environment

CORBA (D)COM EBM EAR Edifact EHCRA GP GSM HII HIMSS HISA HL7 HTML ICT ICU IDL IEEE IHE IIOP IMT ISO ISP IT ITU Jabber J2EE Java LIS MW NHAB OECD OMA OMG PDA PKI RDF RHCN RHE RIM RMI RM-ODP RPC RSNA RUP SGML SOAP TCP/IP

231

232

TTP UDDI UML VPN W3C WHO WISE WSDL XML

Glossary of Terms

Trusted third party Universal Discovery, Description, and Integration [W3C standard] Unified modelling language Virtual private network Wordwide web consortium, www.w3.org World health organisation Working In Synergie for Europe, a EU-funded project in the 4th FP Web Services Description Language [W3C standard] Extensible markup language

233


Author Index Beale, T. Bruun-Rasmussen, M. Burke, P. Doupi, P. Giokas, D. Heard, S. Kalra, D. Katehakis, D.G. Nolan, R. Paindaveine, Y.

153 61 v 187 108 153 153 4, 61 vii ix

Pakarinen, V. Pedersen, C.D. Piggott, D. Pohjonen, H. Ruotsalainen, P. Saranummi, N. Thorp, J. Tsiknakis, M. Wanscher, C.E.

61 141 61, 92 187 187 37, 61, 215 174 215 141




Regional Health Economies and ICT Services (Studies in Health Technology and Informatics Shti)

Global Health Informatics Education (Studies in Health Technology and Informatics)

Medical And Care 3 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Advances in Information Technology and Communication in Health - Volume 143 Studies in Health Technology and Informatics

Medical and Care Compunetics 2 (Studies in Health Technology and Informatics, Vol. 114) (Studies in Health Technology and Informatics)

Research into Spinal Deformities 5 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

International Perspectives in Health Informatics - Volume 164 Studies in Health Technology and Informatics

Plaque Imaging: Pixel to Molecular Level (Studies in Health Technology and Informatics, Vol. 113) (Studies in Health Technology and Informatics)

E-Health: Current Situation And Examples Of Implemented & Beneficial E-Health Applications (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Connecting Medical Informatics and Bio-Informatics (Studies in Health Technology and Informatics)

Aging: Demographics, Health, and Health Services

Evaluation Methods in Biomedical Informatics (Health Informatics)

Information Technology Essentials for Behavioral Health Clinicians (Health Informatics)

The Economics of Obesity, Volume 17 (Advances in Health Economics and Health Services Research) (Advances in Health Economics and Health Services Research) ... Economics and Health Services Research)

The Conservative Scoliosis Treatment:1st SOSORT Instructional Course Lectures Book (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

MEDINFO 2007: Proceedings of the 12th World Congress on Health (Medical) Informatics (Studies in Health Technology and Informatics)

eHealth Beyond the Horizon - Get IT There:Proceedings of MIE2008 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Analysis, Design and Implementation of Secure and Interoperable Distributed Health Information Systems (Studies in Health Technology and Informatics, 89)

Information Technology in Health Care 2007 - Proceedings of the 3rd International Conference on Information Technology in Health Care: Socio-technical ... Studies in Health Technology and Informatics

Telenursing (Health Informatics)

Neuroeconomics (Advances in Health Economics and Health Services Research)

Information Technology Solutions for Healthcare (Health Informatics)

Beyond Health Insurance: Public Policy to Improve Health (Advances in Health Economics and Health Services Research)

Basic Engineering for Medics and Biologists (Studies in Health Technology and Informatics)

Principles of Health Interoperability HL7 and SNOMED (Health Informatics)

Challenges And Opportunities of Healthgrids: Proceedings of Healthgrid 2006 (Studies in Health Technology and Informatics)

Wearable eHealth Systems For Personalised Health Management: State Of The Art and Future Challenges (Studies in Health Technology and Informatics)

Biomedical Informatics: Computer Applications in Health Care and Biomedicine (Health Informatics)

Medical and Care Compunetics 4 (Studies in Health Technology and Informatics)

Regional Health Economies and ICT Services (Studies in Health Technology and Informatics Shti)

Global Health Informatics Education (Studies in Health Technology and Informatics)

Medical And Care 3 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Advances in Information Technology and Communication in Health - Volume 143 Studies in Health Technology and Informatics

Medical and Care Compunetics 2 (Studies in Health Technology and Informatics, Vol. 114) (Studies in Health Technology and Informatics)

Research into Spinal Deformities 5 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

International Perspectives in Health Informatics - Volume 164 Studies in Health Technology and Informatics

Plaque Imaging: Pixel to Molecular Level (Studies in Health Technology and Informatics, Vol. 113) (Studies in Health Technology and Informatics)

E-Health: Current Situation And Examples Of Implemented & Beneficial E-Health Applications (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Connecting Medical Informatics and Bio-Informatics (Studies in Health Technology and Informatics)

Aging: Demographics, Health, and Health Services

Evaluation Methods in Biomedical Informatics (Health Informatics)

Information Technology Essentials for Behavioral Health Clinicians (Health Informatics)

The Economics of Obesity, Volume 17 (Advances in Health Economics and Health Services Research) (Advances in Health Economics and Health Services Research) ... Economics and Health Services Research)

The Conservative Scoliosis Treatment:1st SOSORT Instructional Course Lectures Book (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

MEDINFO 2007: Proceedings of the 12th World Congress on Health (Medical) Informatics (Studies in Health Technology and Informatics)

eHealth Beyond the Horizon - Get IT There:Proceedings of MIE2008 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Analysis, Design and Implementation of Secure and Interoperable Distributed Health Information Systems (Studies in Health Technology and Informatics, 89)

Information Technology in Health Care 2007 - Proceedings of the 3rd International Conference on Information Technology in Health Care: Socio-technical ... Studies in Health Technology and Informatics

Telenursing (Health Informatics)

Neuroeconomics (Advances in Health Economics and Health Services Research)

Information Technology Solutions for Healthcare (Health Informatics)

Beyond Health Insurance: Public Policy to Improve Health (Advances in Health Economics and Health Services Research)

Basic Engineering for Medics and Biologists (Studies in Health Technology and Informatics)

Principles of Health Interoperability HL7 and SNOMED (Health Informatics)

Challenges And Opportunities of Healthgrids: Proceedings of Healthgrid 2006 (Studies in Health Technology and Informatics)

Wearable eHealth Systems For Personalised Health Management: State Of The Art and Future Challenges (Studies in Health Technology and Informatics)

Biomedical Informatics: Computer Applications in Health Care and Biomedicine (Health Informatics)

Medical and Care Compunetics 4 (Studies in Health Technology and Informatics)

Recommend Documents