Collaborative Patient Centred Ehealth: Proceedings of the Hit healthcare 2008 Joint Event: 25th Mic Congress, 3rd International Congress Sixi, Special ... in Health Technology and Informatics)

COLLABORATIVE PATIENT CENTRED EHEALTH Studies in Health Technology and Informatics This book series was started in 199...

Author: E. De Clercq | G. De Moor | J. Bellon | M. Foulon | J. Van Der Lei

12 downloads 736 Views 2MB 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

COLLABORATIVE PATIENT CENTRED EHEALTH

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, Prof. A. Famili, Prof. A. Hasman, Prof. L. Hunter, Dr. I. Iakovidis, Dr. Z. Kolitsi, Mr. O. Le Dour, Dr. A. Lymberis, Prof. P.F. Niederer, Prof. A. Pedotti, Prof. O. Rienhoff, Prof. F.H. Roger France, Dr. N. Rossing, Prof. N. Saranummi, Dr. E.R. Siegel, Dr. P. Wilson, Prof. E.J.S. Hovenga, Prof. M.A. Musen, Dr. U. Fors and Prof. J. Mantas

Volume 141 Recently published in this series Vol. 140. P.H. Dangerfield (Ed.), Research into Spinal Deformities 6 Vol. 139. A. ten Teije, S. Miksch and P. Lucas (Eds.), Computer-based Medical Guidelines and Protocols: A Primer and Current Trends Vol. 138. T. Solomonides et al. (Eds.), Global Healthgrid: e-Science Meets Biomedical Informatics – Proceedings of HealthGrid 2008 Vol. 137. L. Bos, B. Blobel, A. Marsh and D. Carroll (Eds.), Medical and Care Compunetics 5 Vol. 136. S.K. Andersen, G.O. Klein, S. Schulz, J. Aarts and M.C. Mazzoleni (Eds.), eHealth Beyond the Horizon – Get IT There – Proceedings of MIE2008 – The XXIst International Congress of the European Federation for Medical Informatics Vol. 135. T.B. Grivas (Ed.), The Conservative Scoliosis Treatment – 1st SOSORT Instructional Course Lectures Book Vol. 134. B. Blobel, P. Pharow and M. Nerlich (Eds.), eHealth: Combining Health Telematics, Telemedicine, Biomedical Engineering and Bioinformatics to the Edge – Global Experts Summit Textbook Vol. 133. J. Hammer, M. Nerlich and S. Dendorfer (Eds.), Medicine Meets Engineering – Proceedings of the 2nd Conference on Applied Biomechanics Regensburg Vol. 132. 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 16 – parallel, combinatorial, convergent: NextMed by Design Vol. 131. R. Latifi (Ed.), Current Principles and Practices of Telemedicine and e-Health

ISSN 0926-9630

Collaborative Patient Centred eHealth Proceedings of the HIT@HealthCare 2008 joint event: 25th MIC Congress, 3rd International Congress Sixi, Special ISV-NVKVV Event, 8th Belgian eHealth Symposium

Edited by

Etienne De Clercq Université Catholique de Louvain, Brussels, Belgium

Georges De Moor Universiteit Gent, Ghent, Belgium

Joseph Bellon Soins Infirmiers & Informatique, asbl (Sixi), Reves, Belgium

Michel Foulon Beroepsorganisatie voor Verpleegkundigen NVKVV-vzw, Brussels, Belgium

and

Johan van der Lei Erasmus MC, Universiteit van Rotterdam, Rotterdam, The Netherlands

Amsterdam • Berlin • Oxford • Tokyo • Washington, DC

© 2008 The authors and IOS Press. 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 978-1-58603-922-6 Library of Congress Control Number: 2008936294 Publisher IOS Press Nieuwe Hemweg 6B 1013 BG Amsterdam Netherlands fax: +31 20 687 0019 e-mail: [email protected] Distributor in the UK and Ireland Gazelle Books Services Ltd. White Cross Mills Hightown Lancaster LA1 4XS United Kingdom fax: +44 1524 63232 e-mail: [email protected]

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

Collaborative Patient Centred eHealth E. De Clercq et al. (Eds.) IOS Press, 2008 © 2008 The authors and IOS Press. All rights reserved.

v

Preface Medical Informatics in Evolution Evolution in Hardware Twenty-five years ago, in 1983, the first MIC congress was organized, in collaboration between the Dutch VMBI, founded in 1971, and the Belgian MIM, founded in 1974. This collaboration proved to be a golden choice. But who of the participants of the current MIC ever used 5- or 7-hole paper tapes or punched cards, 5¼ or 3½ inch diskettes, DEC-tapes or digital magnetic tapes? Who still remembers the time that the speed of computers was measured in thousands of instructions per second, that computers had magnetic core memory, and that removable magnetic disks had a storage capacity of a mere hundred thousand bytes? Besides, who can still read his old digital files, produced by a mainframe or minicomputer of those early years? Perhaps, the most impressive observation is that Moore’s Law (that the number of transistors on integrated circuits doubles every two years) has proven to be valid for half a century, until today.

Evolution in Software Indeed, incredibly many changes took place regarding computer hardware. But this is not less the case with respect to the software. Are there still any MIC-participants who ever programmed in Assembler, Fortran, Cobol, ALGOL? Are there still systems operational in MUMPS or Basic? Anyway, the writers of this foreword, who stood at the cradle of both associations, VMBI and MIM, have experienced all this – although they can hardly remember these developments, because of the extremely high speed by which they occurred.

Evolution in Manware The expectations in the ‘ancient times’ of VMBI, MIM and MIC were tremendous but nobody was able to predict the advent of the PC (cf. MITS’ Altair 8080 in 1974), of the world-wide web in 1991, and the public start of the Internet in 1992; and who at that time had ever heard of computer viruses and computer crime? Who was concerned about computer security, data confidentiality and privacy protection? Nobody expected the incredibly fast proliferation and processing speed of computers and their application for actually all aspects of society, including health care. Who could have predicted, that not the hardware or the software, but that manware, the human factor, would be the crucial factor for successful applications in the medical domain? Anyway, this remark pertains to all applications in society. If there is anything special that we have discovered during the last 25 years, it is that computers can only be successfully applied when

vi

processing systems can be formalized and when to be automated processes are repeatable and procedures can be standardized.

Evolution in Disciplines All this applies in particular to health care, where the human factor is perhaps the most prominent of all computer applications in whole society. Our processing methods have become more and more abstract, and are less and less dependent on concrete hardware and software. In the beginning, Medical Informatics was foremost an art, an applied technology. In the early eighties, books written by Marsden S. Blois, François Grémy and others introduced the term of Medical Information Science (instead of Medical Informatics), hereby emphasizing the differences in information processing in medicine. Gradually, R&D departments were founded in universities to develop advanced training and education programs. Medical Informatics evolved from a domain of computer applications to a multidisciplinary field, where medical students, MSc and PhD students were trained and progressively adopted the methods used in this field. As it became clear that specific methods were lacking for medical informatics applications we decided to borrow and adapt some from adjacent scientific disciplines such as physics, statistics and informatics. Therefore, it also became evident that Medical Informatics is not a fundamental scientific area on its own, but an applied field. It is at most an ancillary science, only existing for the benefit of health care. It is not an independent, ‘stand-alone’ domain, such as astronomy, geology or biology. As medicine itself is a combination of many different disciplines, medical informatics bears the same characteristics. For every different application in medicine and health care, multidisciplinary teams are composed to solve specific problems. Likewise, different people, disciplines and skills are required for computer interpretation of medical signals or images than for the construction of electronic health records or for the development of modern hospital networks providing seamless access to patient data, or again for R&D pertaining to the development of systems for intensive care units. Home care and remote patient monitoring even involve participation of patients in the management of their condition, hence their influence and input in the design of such systems cannot be underestimated.

Evolution in Types of Processes In Medical Informatics three types of processes play a central role: (1) organizational (2) patient-related and (3) decision making-related. The first type deals with settings, such as a hospital care setting or a primary care setting; the second is related to health and disease (i.e. to patients); the third type of process aims at assisting in decision making and therapy and evolves in the brains of healthcare professionals. Hence, in all domains data, information, and knowledge play a key role. As these three processes evolve, dealing with individuals – patients, doctors, and nurses – because of that human factor there are obviously limitations imposed by formalization and standardization. This is why medical informatics R&D most often bears a multidisciplinary character. This is caused by the fact that (1) medical informatics deals in essence with the entire and very complex domains of medicine and health care (2) R&D is conducted by individuals originating from multiple and distinct scientific disciplines (3) R&D should

vii

not only incorporate knowledge from the natural sciences but should also be based on ‘soft’ knowledge stemming from the behavioral sciences and medical experience, and should also take into account ethical aspects.

Evolution in Patient Involvement Nobody could have predicted the enormous impact of the PC and the Internet on modern society, including health care. The patients are also increasingly using the computer and are browsing the Internet to find answers related to their health condition. Since the moment that PubMed was made accessible to patients, the number of consultations by patients has grown by a factor of 10. Patients and their relatives or friends are increasingly interested to obtain information from MEDLINE or other resources on specific diseases and health related matters. This is also why the reliability of such information is crucial. For this reason, about 15 years ago HON (Health on the Net), founded by Jean-Raoul Scherrer in cooperation with the EC, developed the HON Code of Conduct for medical websites. Websites which comply with the HON Code of Conduct are allowed to use the HON logo as a sign of the higher reliability of the information they present.

Evolution of Biomedical Informatics In parallel to medical research medical informatics is evolving constantly. It is only about fifteen years ago that basic medical research was primarily concerned with problems in physiology, anatomy, embryology, or immunology; fundamental research in biomedicine was generally done on the level of organs and organisms. Nowadays, the challenges are of a different nature where many research projects are primarily conducted at the level of biomolecules and cells. This is partly the effect of the unravelling of the genome and the proteome. Genomics (the study of the genome and the genes) and proteomics (the study of the proteins produced by the cell on the basis of information encoded in the genes) have also a profound effect on modern clinical research and population-based research. Therefore, a new branch of informatics in medicine emerged under the name of bioinformatics (or biomedical informatics). Despite these rapid and important changes it will still take a considerable amount of time before the newly gained insights in biomolecular and bioinformatics research can be translated into clinical and medical practice, i.e., into new diagnostic and therapeutic techniques.

Evolution in eHealth R&D In the last 15 years, the European Commission has supported major research, development and deployment programs which also facilitated international cooperation. Over the years the nomenclature used to designate our field also evolved from medical informatics, to medical telematics, to ICT in health and now to eHealth. Today’s research priorities focus on personalized systems, on modeling and simulation (VPH), on accelerating the convergence of biomaterial development (nanotechnology and microsystems) and on blurring the boundaries between the fields of research and care. De-

viii

ployment initiatives address cross-border communication (e.g. of health record summaries and e-prescriptions) and on interoperability between eHealth systems in general. In this rapidly evolving (and rather technical) environment one significant challenge remains: more consistency and continuity to support in a substantial way the longer term views such as semantics research (following Basic Formal Ontology principles), international standardization, and eHealth systems’ quality labeling and certification. Without these, interoperability will continue to be an illusion.

Evolution in Expectations and Future Needs In the past, there have been some unrealistic expectations regarding the possible contributions of medical informatics to health care such as the predictions in the 1970s on the expected impact of medical decision-support systems and expert systems on health care. However such contributions appeared to be very modest, to say the least. The same applies to the overly optimistic expectations regarding the introduction of electronic health records. Although the technology is widely available all these developments appear to be far more complex than expected. Many effects related to (1) the human factor and (2) obstacles which we regard as informational in nature, were underestimated and still continue to slow down our efforts. The need for an improved understanding of the nature of medical knowledge to better serve health remains to be emphasized. Medicine and health care offer us wonderful opportunities (but assign us also a heavy and unique responsibility) to better understand and describe the human nature in all the interrelated levels influencing health. Let us therefore join forces (biomedical, ICT staff and clinicians) to address this challenge! Rotterdam, Jan H. van Bemmel Gent, Georges J.E. De Moor August 2008

ix

Acknowledgements The editors wish to thank all authors, as well as reviewers who selected the papers and made proposals to improve their quality. We express also our gratitude to Mrs Nathalie Malevé and Mrs Catherine Bauwens for the follow up and technical editing.

This page intentionally left blank

xi

Dear congress participants, It is a privilege for the VMBI to co-organize this year’s MIC in collaboration with our Belgian colleagues from the MIM, Sixi and NVKVV, the Belgian Ministry of Public Health and the Dutch Nursing Informatics association V&VN. The 25th anniversary of this event is proof for the need to keep increasing our strains in the field of Medical and Nursing informatics. Technique is no longer the major item as the programme shows you, but human and organizational processes are becoming more and more important. From within our Dutch association the urge to continue and extend the international collaboration is high. So, it is an honour for us to present and to sponsor this exceptional edition of the 25th MIC Proceedings. Special thanks to the BIGN foundation which made the sponsoring happen. We hope that you’ll enjoy the lectures and use the material in further education, research or profession. Johan van der Lei, Chairman VMBI


xiii

Contents Preface – Medical Informatics in Evolution Jan H. van Bemmel and Georges J.E. De Moor

v

Acknowledgements

ix

Part One. Keynotes’ Papers Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT William T.F. Goossen Knowledge Driven Health – Microsoft Vision for Future Health Care Octavian Purcarea

3 11

Part Two. Scientific Papers 1. Primary and Secondary Care Networking Health Networks: Actors, Professional Relationships, and Controversies Caroline Artoisenet, Michel Roland and Marie-Christine Closon

23

LISA, the Next Generation: From a Web-Based Application to a Fat Client Noëlla Pierlet, Werner Aerts, Mark Vanautgaerden, Bart Van den Bosch, André De Deurwaerder, Erik Schils and Thomas Noppe

32

Trans-eCare: Creating a Transparant Data Exchange Platform Heidi Buysse, Pascal Coorevits, Geert Thienpont and Georges De Moor

38

2. Transeuropean eHealth Legal Aspects of E-HEALTH Stefaan Callens and Kim Cierkens

47

eHealth Services and Directive on Electronic Commerce 2000/31/EC Jean-Marc Van Gyseghem

57

A Data Protection Framework for Transeuropean Genetic Research Projects Brecht Claerhout, Nikolaus Forgó, Tina Krügel, Marian Arning and Georges De Moor

67

3. Electronic Patient Records From a Paper-Based to an Electronic Registry in Physiotherapy Ronald Buyl and Marc Nyssen Certification of Electronic Health Record Systems and the Importance of the Validation of Clinical Archetypes Georges De Moor, Dipak Kalra and Jos Devlies

75

82

xiv

An Electronic Out-of-Hours Health Record Koen Thomeer and Marc Nyssen

92

4. Secondary Usage of EPR Data Electronic Patient Record Data as Proxy of GPs’ Thoughts Etienne De Clercq, Viviane Van Casteren, Pascale Jonckheer, Peter Burggraeve and Marie-France Lafontaine

103

Privacy Protection Through Pseudonymisation in eHealth F. De Meyer, G. De Moor and L. Reed-Fourquet

111

5. Hospital Patient Record Eliminating the Paper Medical Archive by Bulk Document Scanning of Historic Folders and Implementing Revised Workflows for Scanning New Documents Erwin Bellon, Michel Feron, Klaas Peeters, Matthias Sweertvaegher, Paul Neyens, Herman Homble, Christel Ons, Rita Lagae and Bart Van den Bosch

121

The Implementation of an Electronic Nursing Record in a General Hospital in the Netherlands: Lessons to Learn R. Verwey, R.A.B. Claassen, M.J. Rutgers and L.P. de Witte

130

Open Source Electronic Health Record and Patient Data Management System for Intensive Care Jacques Massaut and Pascal Reper

139

Part Three. Technical Reports Related Papers The Use of a Compliant EHR when Providing Clinical Pathway Driven Care to a Subset of Diabetic Patients: Recommendation from a Working Group J. Devlies, E. De Clercq, V. Van Casteren, G. Thienpont, M.F. Lafontaine and G. De Moor Health Data Exchange, Health Data Sharing and Decentralised Clinical Data Collections – Recommendations from a Belgian Expert Group Jos Devlies, Georges De Moor, Etienne De Clercq and André Vandenberghe

149

162

Subject Index

213

Author Index

215

Part One Keynotes’ Papers


Collaborative Patient Centred eHealth E. De Clercq et al. (Eds.) IOS Press, 2008 © 2008 The authors and IOS Press. All rights reserved. doi:10.3233/978-1-58603-922-6-3

3

Using Detailed Clinical Models to bridge the gap between clinicians and HIT Dr William TF GOOSSEN Director Results 4 Care B.V., Amersfoort, the Netherlands, [email protected]

Abstract. Two level object modelling has been introduced in recent health care IT standards, such as Health Level 7 version 3, CEN/ISO 13606 and OpenEHR. Generic functions of electronic health records and electronic messages can be developed in such a way that they become independent of the clinical data, but allow its data management. Clinical data are elicited from clinicians and modelled in the form of clinical statements or archetypes. Such clinical statements or archetypes can be standardized and inserted into the technology upon choice of clinicians. This allows flexibility in development using collections of standardized models. Detailed clinical models (DCM) thus make clinical data explicit, allowing its use in multiple standards and multiple technologies. This paper presents an overview of work for DCM including a workshop in Brisbane in 2007 and project proposals for HL7, CEN and ISO joint standardization work. Keywords. Standards, Computerized Patient Records, Vocabulary, Controlled

1. Introduction to Detailed Clinical Modelling Recently we see many efforts to standardize clinical data so it can be deployed in different health care information technologies (HIT). Clinicians, regulatory agencies, organisations responsible for health statistics and institutions for quality control, among others, have a vast interest in clinical data standards. Also standards organisations on national and international levels have recently shown an interest in this work. This interest exists in particular for agreed purposes such as statistical reporting, the deployment of clinical data for continuity of care, and personal health records and electronic patient records. However, we already see an explosive growth of such initiatives and developments, each with its own purpose and methods applied, with different levels of quality and usefulness. The Detailed Clinical Model (DCM) workshop of August 25 2007 in Brisbane, Australia, followed up on current discussions within the health informatics Technical Committees of CEN and ISO, HL7 and OpenEHR. These discussions especially concern the area of archetypes (CEN), templates (HL7) and care information models (Netherlands). All care information models, clinical templates, archetypes, (technical) templates, clinical fragments, reusable bits, detailed clinical models and more synonyms aim at three parts: 1) formalising, structuring or standardizing clinical data elements, 2) Modelling these independently of the technical implementation, and 3) applying them in different technical representations, such as electronic health records, electronic messages and data warehouses or data repositories. A fourth area of concern is quality control of these three parts. This paper reports on the main results of the workshop, and on current work underway in the different standards organisations.

4

W.T.F. Goossen / Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT

2. Background of Detailed Clinical Models According to Huff et al, clinical information models describe the structure of clinical data that are stored in electronic patient records, sent between clinical systems, and referenced in decision support rules [1]. Rector et al where among the first that modelled the electronic patient record [2]. They separated the clinical observation models and the meta-information about these observations [2]. Additionally, Johnson found that traditional modelling approaches of clinical data lead to complex schema’s consisting of hundreds of entities and representing a rich set of constraints about the patient care domain [3]. This is not efficient in electronic patient records. Johnson thus transformed these complex models into a generic schema resulting in a small database of a dozen tables which is efficient for patient-oriented queries and is highly flexible in adapting to the changing information needs of a health care institution [3]. With respect to DCM, Johnson found that, in particular, changes involving the collection of new data elements where accommodated via this generic model [3]. Beale describes how small constraint models of domain concepts – archetypes – can be added to the knowledge environment, significantly improving interoperability, software economics and quality of care for electronic patient records [4,5]. The core approach is the two level modelling in which a reference model guiding system development and archetypes defining clinical content are separated out. The CEN 13606 series, OpenEHR and HL7 v3 CDA and Care Provision messages use this two level modelling approach [6, 7, 8]. There exist examples of DCM development and use. Huff et al describe several tools that where developed to use and maintain DCM, including tools to guide consistent interface development, data entry screens, clinical reports and decision support modules [1]. Parker et al describe the use of detailed clinical models in the SAGE project for clinical guideline representation and exchange [9]. They argue that common detailed clinical models give precise semantics and make the task of mapping between models manageable [9]. They have applied HL7 RIM artefacts, in particular the observation class and attributes to specify guideline content [9]. Parker et al envision a standard method for creating and sharing detailed clinical models to bring us closer to semantic interoperability [9]. De Bel describes the development of an HL7 v3 compliant electronic patient record system in which the database is configured against the HL7 reference information model [10]. This system allows DCM to be integrated in the electronic patient record, speeding up development, querying and definition of user interfaces. Ocean informatics is developing a set of tools for archetype development and a repository for maintenance [11]. Other tools are under development for complete electronic patient record systems. Van der Kooij et al evaluated a series of instances of Detailed Clinical Models www.zorginformatiemodel.nl) from projects carried out by the Dutch National ICT Institute for Health Care (NICTIZ) [12]. In this evaluation knowledge was determined that serves as quality criteria for DCM [12]. Items include version management, aim of scoring instrument for target populations, appropriate application of the instruments, interpretation guidelines for results, e.g. what is the significance of scores, copyright issues, among others [12].


5

3. Summary of Detailed Clinical Model Workshop outcomes The workshop revealed four areas of further work in standardisation: 1) clinician involvement, 2) agnostic modelling, 3) quality criteria for DCM, and 4) repository to store and find DCM internationally [13]. Each of these areas is described briefly. 3.1. Involve clinicians in Detailed Clinical Model development It is important to involve clinicians in the work of requirements setting. Evaluations of electronic health record systems show consequently that this is a core part for success (e.g. van Gennip and Talmon, [14] and subsequent studies beyond the scope of this paper). Especially the core component: ‘clinical information’ must be developed with clinician involvement. Hoy et al describe the Scottish project where the focus is on clinician’s information needs in specific areas of concern: e.g. complete assessment of motor functioning, family history or activities of daily living, urine continence and so on [15]. They argue that the need identified is the development of context-specific domain models as the basis for standard components for building clinical information systems. Thus, there is a need to structure information around discrete clinical concepts in a way that supports system development and interoperability. Hoy et al state that the process by which clinicians formalise objects in the world and actions that change them in ways that allow developing systems to help us achieve our goals are the main driver behind current standardisation [15]. The panel recommends the following plan: • Develop teaching modules for engaging clinicians in standards work • Set up a review process for engagement of clinicians, determination of clinical usefulness and quality • Establish guidance for using existing guidelines and protocols for modelling (in practice these guidelines are usually not specific enough on data element level). • Raise clinical content capture to professional organisational responsibility • Model evaluation criteria readable by the average clinician 3.2. Modelling Detailed Clinical Models agnostically from technology The different standards try to achieve – at the conceptual level – the same: construct models of clinical artefacts that are reusable over patients, time, location, purpose. In the experience of the Dutch projects with Care Information Models, the most time consuming part of this is to collect, analyse and organise the clinical content. In addition: clinical expertise is scarcely available. Therefore it is imperative to develop an agnostic modelling approach where all the clinical effort is respected and the technical representations and implementations are sorted out from there. Benson presented an example project in which such a more or less agnostic modelling has been applied using UML as representation format [16]. Currently HL7 uses the R-MIM format, which is an UML dialect, and XML. OpenEHR uses the ADL and software to express the models, and can deal with XML as well. Benson showed that standard UML format can be used and might be a helpful starting point from which XML, R-MIM and ADL can be derived [16]. Grieve includes further comments on the

6


constraint formalisms that can convert the Detailed Clinical Models into the technical representations needed for the implementation [17]. The focus thus moves to a three step modelling approach with feedback loops as illustrated in Figure 1:

Figure 1. From clinical domain via agnostic modelling to technical implementation.

The panel recommended to: • Continue with the current different formats to develop Detailed Clinical Models, based on acceptance of the different Standard Reference Information Models. • Determine in near future a sharable formalism for DCM • Develop tooling that help capture clinical knowledge. • Limit the discussion between HL7 v3 and CEN 13606 / openEHR to the real EHR content, such as CDA and Care Provision • Support ongoing work to bridge the controversy, although this will be hard and expectations need to be managed. 3.3. Detailed Clinical Model Repository Garde presented his ideas on a repository for Detailed Clinical Models [18]. He argues that at present, there are several repositories available, but often from a project based approach, using various formats and formalisms. According to Garde, if we are going to harmonise the different materials that are out there, we need to be able to find each others materials [18]. Examples of repositories in different formats, but with similar intentions of sharing reusable quality clinical content exist. There are several requirements for the formalisms used and thus for the repository to facilitate finding the right materials, partly based on materials from the Detailed Clinical Models website [19] . Thus, the idea brought forward is to establish a standard repository of clinical content that can function similarly to the power adapter we all use travelling around the world. The panel recommends the following plan: • Organise an international repository for Detailed Clinical Model content management • Set up governance processes around this repository • Apply a comprehensive (internationally relevant) clinical content management system


•

7

Look at existing organisations such as IHTSDO, HL7, CEN and ISO for procedures to organise this.

3.4. Quality criteria for Detailed Clinical Models Goossen – Baremans developed a set of quality criteria that guide the development of the Dutch Detailed Clinical Models (called Care Information Models) [20]. These care information models have been developed since 2003 for a Dutch national project for information exchange in stroke care, which was carried out on behalf of NICTIZ [21]. Recommendations of participants of a workshop in 2005 in the Netherlands have been incorporated into the current approach to set quality criteria [12, 20]. A full Detailed Clinical Model expression should consist of 18 desirable components [12, 20]. Concept name and version management are considered important meta information. Meta data are relevant for identification of the detailed clinical model, usages, definitional, administrative and relationships among concepts. During the workshop participants agreed that the following meta-information must be considered: • Establish meta information of DCM using ISO IS 11179 [21]. • Check and review the clinical content of the DCM, e.g. based on metaanalysis and levels of confidence if and when available. • Language and translation of DCM: change of language should not change the model, thus model on conceptual level. • Vocabulary binding, using binding of name (variable and code) and value (code) pairs based on a slot approach to allow synonym terms and codes to be used in the DCM based on relationships.

4. Ongoing projects in standardisation of DCM On a national scale, several health organisations and national health informatics strategies focus on developing sets of templates, archetypes and so on. There is put a lot of effort in DCM. Examples include Australia, Canada, Scotland, the Netherlands, UK, among others. Denmark and Sweden are considering starting this kind of work. Therefore, there is now sufficient interest to move to international standardisation work. 4.1. HL7 v3 DCM creation and repository HL7 accepted a proposal to actually create DCM and align this with different working groups within the HL7 organisation. The intent of the HL7 workgroup patient care project proposal is to create and maintain in a repository a set of detailed clinical models that can be transformed from a generic model into EHR profile, HL7 templates, and V3 Clinical Statements, Clinical Document Architecture and Care Provision messages for referral and record exchange. These DCM’s should also function in the ISO/CEN 13606 and OpenEHR series of standards and tools. The HL7 DCM project builds further on past and existing efforts on archetype development from OpenEHR and CEN 13606, HL7 template initiatives, HL7 Clinical Statement and R-MIM development, and clinical domain expressions in different health care associations with

8


the workgroup name Clinical Interoperability Council. The purpose is to organize clinical content in such a manner that it becomes multi useable in different standards and different technologies, thus supporting both the Joint work of HL7 CEN and ISO and semantic interoperability between systems. Ongoing work is currently to flesh out the Glasgow Coma Scale with respect to background, name value pairs and vocabulary and modelling. This is already informing HL7 v3 generic models for assessment scales. 4.2. ISO New Work Item Proposal DCM ISO TC 215 Working Group 1 has an interest and requested a New Work Item Proposal on DCM. The focus here will probably be on a 4 part standard development covering the four areas of the Brisbane workshop. At the time of writing the proposal still has to be written and voted upon, but lines of discussion have gone the following way: The NWIP will focus on a 4 part standard, each covering one aspect of the above four topics from the Brisbane Workshop: Facilitate clinical involvement in information requirement gathering and standards setting. Potentially this includes input, process and outcome parameters leading to identification and specification of name value pairs and appropriate terminology and coding for that. This will also include criteria for review of quality of information in DCM by stakeholders and governance issues. Define modelling requirements, guidelines and principles, including the linking of DCM to ISO data types standard, IHTSDO (Snomed CT) work, and other ISO and CEN materials. UML is considered as the formalism to apply for DCM. This part will link DCM to 13606 series and 18308 (EHR) and HL7 CDA and Care Provision among others, in order to facilitate tooling that makes the process automatable according to that which is depicted in figure 1. Establish quality criteria for DCM and the collection of DCM into fully clinical documents, record messages or clinical templates. The first being the clinical details and the latter their combination in recognizable and clinically relevant formats. These would include the meta information requirements following ISO 11179. Formulate criteria for DCM repositories, including meta information to allow indexing and finding what is needed for interoperability projects.

5. Discussion and Conclusions Participants of this workshop on Detailed Clinical Models were members from ISO, CEN, HL7, openEHR and other groups. There was a general understanding of these 35 experts that it is important to take this work on DCM further. The four action areas identified include clinician involvement, quality of detailed clinical models, representation formalisms and establishing and maintaining repositories. Since then, presentations and discussions under the Joint Working Group umbrella of HL7 CEN and ISO has illustrated a strong interest and continuation of the preparations. Both HL7 and ISO are looking at project proposals and some work is actually taking place. During the Brisbane work shop participants discussed the question whether we can get one representation model for DCM that covers all of the requirements for different standards and different technical developments. Will DCM support GUI design, database design, EHR design, message design, algorithm design, rule-based DSS


9

design? That is not answered yet and can only be addressed via testing. True semantic interoperability however goes beyond the individual variable and terminology bound to it. The context of healthcare requires more in depth approaches. On top of this intrinsic need, the pragmatics of resources – always necessary for their primary task of caring for patients – requires that we spare clinicians. Clinicians should not have to worry about all the technical nuances. However, they would need to be able to verify and control the quality of content in order to trust the EHR and the message content presented to them. Semantic interoperability starts with standards, but ends with a clinician making the right decision based on stored or communicated information. Consensus is emerging on the representation of Detailed Clinical Models being standards and technology independent. Existing examples of models made for similar purpose include the openEHR archetypes, HL7 R-MIMs / (technical) templates and other HL7 or local materials, but most are standard or technology bound. One particular concern with the development is whether DCM can build upon the existing work, not limiting it. The uptake among modellers and developers is crucial for the success. The outcomes of this workshop are relevant for joint standards work of ISO, CEN, HL7 and openEHR, but also of many clinical communities wishing to use EHR and messages for better patient care based on evidence to achieve quality care and appropriate patient outcomes. The current projects both on local, national and international level focus on achieving this in the near future.

References [1] Huff SM, Rocha RA, Coyle JF, Narus SP. (2004). Integrating detailed clinical models into application development tools. Medinfo. 2004;11(2004) 1058-1062. [2] Rector, A.L, Nowlan, W.A, Kay, S., Goble, C.A., Howkins, T.J. A Framework for Modelling the Electronic Medical Record. Methods of information in medicine, 32 (1993) 109-119. [3] Johnson SB. (1996). Generic data modeling for clinical repositories. J Am Med Inform Assoc. (1996) 328-339. [4] Beale, T (2000). Archetypes Constraint-based Domain Models for Futureproof Information Systems. Web documents. Accessed 13 January 2008. http://www.openehr.org/publications/archetypes/archetypes_beale_web_2000.pdf [5] Beale T. (2003). Archetypes and the EHR. Stud Health Technol Inform.;96 (2003) 238-244. [6] CEN TC 251 (2007). EN 13606. Brussels, CEN. [7] OpenEHR. Web documents: http://www.OpenEHR.org/ Accessed 8 July 2008 [8] Health Level 7. Standards. WWW documents. http://www.hl7.org/ Accessed 8 July 2008. [9] Parker CG, Rocha RA, Campbell JR, Tu SW, Huff SM. Detailed clinical models for sharable, executable guidelines. Medinfo. 2004;11,(2004) 145-8. [10] Bel, E de (2005). Ontwikkeling van een Elektronisch Patiëntendossier op basis van HL7 V3. HL7 Magazine (2005), 3. [In Dutch] [11] Ocean informatics. Product range. Web documents: http://oceaninformatics.biz/CMS/index.php Accessed 8 October 2007 [12] Kooij Judith van der, William T.F. Goossen, Anneke T.M. Goossen-Baremans, Nelleke Plaisier. Evaluation of Documents that Integrate Knowledge, Terminology and Information Models. In: Park HA, Murray P, Delaney C (Eds). Consumer-Centered Computer-Supported Care for Healthy People. Proceedings of NI2006. Amsterdam etc. IOS Press. (2006) Pp. 519-522. Studies in Health Technology and Informatics, volume 122. [13] Goossen WTF. Detailed Clinical Models: Report of a Workshop in Brisbane, August 25, 2007. Amersfoort, Results 4 Care, the Netherlands (2008). [14] Gennip EMSJ van en Talmon JL (Eds.) Assessment and evaluation of information technologies in Medicine. Amsterdam, IOS Press (1995). [15] Hoy D, Hardiker NR, McNicoll IT, Westwell P. (2007). A feasibility study on clinical templates for the national health service in Scotland. Stud Health Technol Inform. 129 (2007) 770-774.

10


[16] Benson T . UML modelling for clinical data. Presentation materials for DCM workshop in Brisbane, August 25, 2007. [17] Grieve G (2007). Presentation on CEN 13606 and HL7 v3 modeling. Presentation materials for DCM workshop in Brisbane, August 25, 2007. [18] Garde S (2007). A repository of repositories. Presentation materials for DCM workshop in Brisbane, August 25, 2007. [19]. Detailed Clinical Models (DCM) (2008). Website. Visited Jan 13, 2008. http://detailedclinicalmodels.org/wiki/index.php?title=Main_Page). [20] Goossen-Baremans ATM (2007). Quality Criteria for Detailed Clinical Models. Presentation materials for DCM workshop in Brisbane, August 25, 2007. [21] Goossen WTF. Model once, use multiple times: reusing HL7 domain models from one domain to the other. In: Fieschi M, Coiera E & Jack Li, YC: (Eds). Proceedings of the 11th World Congress on Medical Informatics Medinfo 2004. Amsterdam IOS Press, (2004) 366-370. [22] ISO (2004). ISO/IEC 11179 metadata registry. Geneva, ISO.


11

Knowledge driven Health – Microsoft vision for future health care Octavian PURCAREA, MD Health Industry Solution Manager, Worldwide Health, Microsoft

Abstract: Today’s healthcare systems are facing huge challenges related to the aging of population, availability of resources, development and availability of new technology and individual empowerment. A Microsoft Healthcare belief is that people are the key to success, whether success is measured by healthy patients or a healthy bottom line, that knowledge is a strong enabler of transformation of healthcare delivery, that IT is an agent of change and last, but equally important, Health IT needs to be available to many, not just some. The article will provide some arguments about heath IT contribution and Microsoft vision regarding the future of delivery of health care. Key words: Medical Informatics; eHealth; Information and Communication Technology; Evidence Based Management; Quality Management, Personal Heath Record, Information Systems, Knowledge, Decision Support Systems, workflow management, prevention, early diagnostic, treatment.

1. Introduction In every area of the Health ecosystem, organizations that develop deliver and pay for Health products and services are increasingly challenged to provide better and safer care to more patients in less time and at a lower cost. Every area of Health is facing tough challenges, and addressing them is no easy task in a working environment that is overloaded with disconnected information and fragmented with disparate technology systems - especially while also balancing the diverse demands of government services and regulators, health payers, researchers, providers, patients, and consumers. In the past, solving these issues with technology has been expensive and overwhelming. The technology solutions available weren’t affordable and they regularly took too long to implement and, then, didn’t meet user needs. Moreover, they often required extensive training to learn to use—something time-challenged health professionals couldn’t afford to do. We believe it is time for a different approach. At Microsoft, we are working on IT solutions for every area of health. We understand that Health is not just about Hospitals – it is about all the care, services and products delivered to people by the many organizations throughout the entire Health ecosystem, including Providers, Payers, Health and Social Service agencies, Life Science organizations and consumers. Our innovative technology and partner solutions range from streamlining the way patient orders are recorded in hospitals, to enabling Health Payers to compete in a consumer-focused market, to helping pharmaceutical companies gain greater returns on their R&D investments and to helping consumers take charge of their care by keeping

12

O. Purcarea / Knowledge Driven Health – Microsoft Vision for Future Health Care

track of all their health information. The core of the new approach is the knowledge driven health.

2. Principles: Microsoft vision is articulated around several principles: • It’s about People Microsoft understands that people are the key to success, whether success is measured by healthy patients or a healthy bottom line. Microsoft puts the need to provide software that helps the people who deliver and receive health services at the top of the list. We believe that the benefits of health IT investments have to be felt personally, by making jobs and lives easier and safer. We also know that the users of systems need to be involved in the initial design and ongoing evolution of the systems they are being asked to use. That is why we promote the use of software tools that are simple and familiar, and perhaps even fun to use. If individuals feel the benefits of health IT, then the systemic potential of the systems will also be realized. But first, above all things, it is about people. • We focus on knowledge. People make decisions based on knowledge, not just data. That is why our solutions don’t just bring data together, they provide the information, facts and awareness of changes needed for knowledge-based decisions. In an industry often plagued by data overload, healthcare professionals need all pertinent information to be tailored and a keystroke away for the decisions they need to make to help their patients and improve their organization. • IT is an Agent of change. Advanced software solutions that connect a wide range of medical technologies and data into a seamless whole will provide a complete picture of health. But that isn’t the ultimate end goal. Rather, those advance software solutions will enable a change to an information-centered approach to medicine that can shift the priorities of Health from treatment and cure to prevention and life-long wellness. It has the power to put individuals as the center of the Health system, empowered with the pertinent information needed to control their own well-being. And an information-centered Health system offers the opportunity for a rich marketplace of resources and services that will increase efficiencies and cut costs across the spectrum of care. And last, but equally important, • Health IT needs to be available to many, not just some For too long, the solutions implemented to help solve some of the most significant issues in the Health ecosystem have been so complex and expensive that only the richest can afford to implement them, and then it can take years to realize the benefits. That is why Microsoft is dedicated to offering our economical, easy-to-implement-anduse, off-the-shelf technology to our health customers and partners so they can develop solutions that quickly and directly benefit everyone. We believe there is value to be gleaned to provide a better ROI and faster, easier implementation. Because although the Health industry has specific needs, it also has a lot of needs that have already been solved in other industries. The challenges of Health will take a long time to fix, and there is a long list of technology companies, large and small, that have been in and out of the health


13

solutions world. This does not help patients trust and belief that money spent on health IT is money well spent. At Microsoft, we have taken a long term view and made investments that are consistent with that view. And based on our past successes in other industries, we believe there is no company with a better track record of solving long-term and difficult problems.

3. Microsoft future vision: The main elements of the Microsoft future vision captures the essence of current health industry trends, including the rising tide of citizen empowerment in healthcare, the availability of information everywhere and cost containment. 3.1. Citizen empowerment: The future of healthcare will be based on active participation of individuals to the management of their health status. Health information, Health education and remote monitoring are the key elements of this vision. Collaboration with health professionals for the interpretation of various physiological functions and fine tuning of the physical exercise and behavioral factors are made possible by today technology. Virtual Visits with General Practitioners or case managers would allow prevention, precocious intervention and early diagnostic of disease and possible enrollment in clinical studies. 3.2. Support to Health Professionals A range of light weight intelligent devices will allow Health Professionals to better manage the whole care workflow of their patients. They will be receive in real time important information regarding the status of their patients, receive alerts concerning the treatment and plan the future steps being inform about the latest medical guidelines relevant to their patient. The tools will help manage and track patient medications in the hospital setting as well as locate needed equipment to conduct his patient visits. 3.3. Evidence based management The challenges regarding increasing cost of healthcare could be tackled by evidence supported information about the available resources, performance of health professionals and compliance to medical guidelines (care pathways). This information gathered and managed by the health professionals could pave the way to a new generation of quality management techniques based on evidence. 3.4. Knowledge driven healthcare The essence of how information technology will truly help transform Health to better connect people and data, facilitate improved collaboration, and better inform everyone involved with the best knowledge at hand, in the timeliest manner while eliminating geographic barriers is what the Microsoft vision for Knowledge Driven Health is all about.

14


Microsoft Knowledge Driven Health encompasses solutions, technologies, products, and services from Microsoft and its partners that connect people to systems and data, improving collaboration and informed decision making to facilitate knowledge-driven delivery of care, services, and products. It equips people who work in the healthcare ecosystem with intuitive tools so they can provide safer, higher-quality care, services, and products to more patients and citizens in the most time- and cost-efficient manner. Microsoft’s contemporary and flexible technology solutions allow organizations to not only streamline, but transform processes. They leverage existing IT investments and make previously disconnected systems and information within and across organizations easily accessible, so people can collaborate across the healthcare ecosystem to share and analyze information and turn it into knowledge-driven action for improved operational, and personal and public health outcomes.

4. Impact Once implemented, the Knowledge Driven Health vision can have a significant impact across the spectrum of Health organizations: • Providers1 have the information they need when they need it, so they can take knowledge-driven action for improved patient, clinical, and business outcomes. Using innovative approaches and easy-to-use, flexible technology tools, healthcare professionals are able to provide safer, higher-quality, more accessible care that is patient-centric, evidence-based and time- and costefficient. And because Knowledge Driven Health solutions are economical and quick to implement, the benefits of increased caregiver and patient satisfaction and better business performance are quickly realized. • Health Payers2 can transform health plans from transaction-based enterprises into highly collaborative, knowledge-driven organizations that enable consumers, providers, and employers to make informed choices that improve personal health, the quality and affordability of care, the customer experience, and their bottom lines. A faster time to market for new innovative products and services and an expanded capacity to handle more complex customer interactions with fewer staff are other positive outcomes from improved technology in this area. • Life sciences organizations 3 can facilitate seamless collaboration between industry professionals, customers, and business partners, which can lead to breakthroughs in research and product innovation, business performance, and supply chain optimization. • And Public Health 4 organizations can connect their people and systems, improving collaboration for more informed decision making. This allows organizations to more efficiently provide services to a broader population,

1

See http://www.microsoft.com/industry/healthcare/healthplans/default.mspx See http://www.microsoft.com/industry/healthcare/healthplans/default.mspx 3 See http://www.microsoft.com/industry/healthcare/lifesciences/default.mspx 4 See http://www.microsoft.com/industry/healthcare/lifesciences/default.mspx 2


15

help protect and promote better health, and enhance citizen health status and social services outcomes while managing the cost of service delivery.

5. Infrastructure: Microsoft Knowledge Driven Health starts with the principle that a system of successful, high-quality healthcare is built on an integrated infrastructure. In an environment in which a hospital, health payer, or other health-associated organization may have as many as 200 separate, disconnected systems for creating and storing information, the underlying objective is to create a standards-based technology framework by which people can easily access and navigate the information stored inside. Microsoft defines this framework with our Connected Health Framework – Architecture and Design Blueprint. It is a set of vendor-agnostic best practices and guidelines for building electronic health solutions based on a service-oriented architecture (SOA) and industry standards. The Architecture and Design Blueprint provides health organizations with an approach to developing information networks with common business and technical design definitions. The framework is organized in 3 layers: Health Solutions Knowledge Driven Health solutions enable health providers to build connected, security-enhanced and highly interoperable ehealth solutions that span people, processes and systems. These solutions help to reduce complexity and increase organizational agility, deliver intuitive and productive user experiences, and amplify the impact of healthcare professionals and patients. Shared Services The second layer of the framework, Shared Services, includes solutions that allow healthcare organizations to standardize, streamline, and better coordinate common services for increased operational efficiencies. By aggregating technology resources, shared services solutions help manage both content and relationships among health professionals and patients, enabling health organizations to fundamentally improve the effectiveness of information sharing, healthcare delivery, and processes. Connected Health Platform To deliver an optimized Connected Health Platform, it is necessary to have a proven and robust infrastructure and the 3rd layer of the framework addresses just that. Microsoft’s infrastructure provides a security-enhanced, scalable, and interoperable foundation for seamless, organization-wide capabilities.

6. Successful implementations and results: Eastern Health is the second largest healthcare provider in the State of Victoria, Australia. They provide public healthcare services to a population of 800,000 people across an area of 2,800 square kilometers. With more than 7,000 staff working in five hospitals, Eastern Health relied on e-mail and voice mail to contact its practitioners. Although they already used e-mail messaging and telephony services extensively, it was not providing effective communications across all levels at all times. The organization already had BlackBerry devices and Palm Treo Smartphones deployed for

16


mobile messaging in clinical, radiological, and administrative areas, but needed to better support their mobile practitioners. Eastern Health wanted an integrated messaging solution to streamline collaboration and cut operating costs. Using Microsoft Exchange Server 2007 with Unified Messaging in conjunction with Microsoft Office Communications Server 2007, Eastern Health has created a unified communications environment that offers extended capabilities and improves patient outreach. The new system provides a one-stop gateway for collaboration that is scalable for future expansion, cost-effective, and helps improve patient care. Now, email, voice mail, and faxes are delivered to users’ inboxes, and users can access that information from familiar clients such as the Microsoft Office Outlook 2007 messaging and collaboration client, or from a telephone using Microsoft Office Outlook Voice Access. With Office Communications Server 2007, users can send instant messages and see the availability of other employees through presence awareness which is linked to the presence status they set in their Outlook calendar or Office Communicator. The Eastern Health project clearly demonstrates a solution that focuses on People making both its staff and patients’ lives much easier and safer5. Another example of successful implementation, of a solution for health professional’s collaboration is the Washington Hospital Center, the largest private hospital in the Washington, DC, who faced the common challenge of controlling hospital-acquired infections. Relying on multiple databases and systems, infectioncontrol clinicians struggled to access the complete information needed to trace where infected patients had been in the hospital, to minimize their exposure to other patients, and to satisfy governmental reporting requirements. The hospital implemented a solution based on Microsoft Amalga™, the Unified Intelligence System, initially developed at Washington Hospital Center and acquired by Microsoft in 2006. Microsoft© Amalga™, the new version of the product formerly known as Azyxxi, allows hospital enterprises to take advantage of the data sitting in clinical, financial and administrative silos. Without replacing current systems it offers an innovative way to capture, consolidate, store, access and instantly present data in meaningful ways for leading edge institutions. The system helps users to correlate information from multiple systems and gather valuable intelligence that can help support patient care, organizational quality objectives and operational efficiency. With its flexible data capture, storage and presentation capabilities, Amalga quickly delivers rich, role-based, customizable views and allows users to adapt the system to their workflow and preferences. With Amalga, the infection-control department now has minimized infection exposure, fewer costly patient transfers, comprehensive device tracking, up to 3 days faster reporting and up to 3 hours saved weekly in MRSA compliance reporting.6 Another example is Bumrungrad International Hospital that treats more than 1.2 million patients from 190 countries each year. They use Microsoft Amalga Hospital Information System to efficiently manage clinical workflow, billing, regulatory compliance, and medical records. Microsoft Amalga HIS is a state-of-the-art, fully Integrated Hospital Information System complete with picture archiving, patient and

5 See : http://www.dimensiondata.com/NR/rdonlyres/E54E1B77-359B-4C33-A63FD68F72761DC5/8494/EasternHealth20071.pdf 6 See : http://www.microsoft.com/industry/publicsector/partnersolutionmarketplace/CaseStudyDetail.aspx?casestud yid=4000001100


17

bed management, laboratory, pharmacy, radiology, pathology, financial accounting, materials management and human resource systems. Since automating patient data and medical images, implementing filmless radiology, and transforming its workflow with Amalga HIS, Bumrungrad has decreased the cost of care, at a time when global healthcare costs are soaring. Gross profit margins increased to 33%, a significant increase from the low 20s in 1997, and they realized a 40 % growth in total number of patients. The hospital has not increased its IS or back-office staff and was able to eliminate its old medical records unit, and convert its 10,000 square feet to a kid-friendly, revenue-generating pediatric clinic7. Interesting example is the one of Hospital de São Sebastião near Porto, Portugal. They wanted to implement a unified technology environment to serve the needs of patients rather than depend on isolated systems for each healthcare professional and department within the hospital. So, their 11-person in-house IT group built a patient record and management system using Microsoft commodity products for one-tenth of the cost of traditional commercial systems and had users relying on the system only six months after the original idea was conceived. First deployed in the emergency department, their Medtrix EPR solution was developed as a Web-based application using Microsoft® Visual Studio® .NET 2003 and the Microsoft .NET Framework. The application provides physicians an integrated view of all clinical information relating to patients, starting with hospital admissions. The workflow of patients has been improved according to the hospital personnel, as well as the waiting time. The delay between prescription and administration of drugs is sensible reduced due to the voice recognition feature, automatic transfer of prescription to the nurses and pharmacy8. Let’s take a look at Asklepios, the largest private hospital group in Germany with holdings in the US. They wanted to provide streamlined processes and rapid access to patient data, with standardised IT infrastructures to efficiently manage all of its hospitals and facilities. Their goal was to optimize interactions between medicaltechnical equipment and facilities and create the conditions necessary for flexible, demand-orientated assignment of doctors and nurses. To achieve this, Asklepios launched a large-scale project, known as OneIT, to standardize its computing environment on the Microsoft platform and enhance its delivery of medical services. With uniform data services, a single Active Directory domain, and a stable high-speed network, all barriers to information sharing between hospitals have been removed. The scale of the project was unprecedented in the history of the Germany healthcare industry. Due to meticulous preparation, the migration of hospitals with 300 to 600 computers was managed in just one week. The number of servers in the architecture was reduced from 120 to 20, resulting in a substantial increase in availability. The results of the conversion phase are well evidenced. A study based on a total cost of ownership (TCO) model—carried out by Asklepios, Microsoft, and Intel®— showed that the OneIT standardization project not only simplifies administration and increases security, but also delivers cost savings per client of almost one third. Availability of IT services has been substantially increased, while waiting times and

7 8

See http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000001796 See http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=49389

18


downtime have dropped. In addition, users can log on to any computer, increasing their ability to work effectively from any location.9 HealthVault Personal Health Record (PHR) is one example of successful attempt to empower individuals to manage their own health. This secure Web Personal Health Record allows healthy individuals and patients to store their medical data making it accessible with their consent to the health professional of their choice. Moreover, following multiple alliances with the medical devices industry, a wide range of individual measurements such as weight, blood pressure, pulse, ECG, blood sugar level and others can be collected in HealthVault. Agreements between a number health institutions and Microsoft allowed the patients affiliated to these institutions to have their medical data transferred in HealthVault10. Many of the aspects related to the increased quality and efficiency of care will need thorough scientific validation but as a first remark we must point out the large interest of many individuals around the world that HealthVault faces today.

7. Conclusion: As a company, Microsoft is driven by the desire to improve lives through technology. Good health is central to quality of life. That is why Microsoft is so committed to finding solutions to help transform the Health ecosystem and improve people’s health and lives around the world. Microsoft would like to help health professionals, organizations and funding authorities to deliver better Health care more efficiently and cost effectively.

9

See http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=201211 See http://healthvault.com/

10

Part Two Scientific Papers


1. Primary and Secondary Care Networking



23

Health networks: actors, professional relationships, and controversies Caroline ARTOISENET a,1 , Michel ROLAND b, Marie-Christine CLOSON a a Health Systems Research - Université Catholique de Louvain, Belgium b Public Health School - Université Libre de Bruxelles, Belgium

Abstract. In recent years international policies have aimed to stimulate the use of information and communication technologies (ICT) in the field of health care. Belgium has also been affected by these developments and, for example, health electronic regional networks (“HNs”) are established. Thanks to a qualitative case study we have explored the implementation of such innovations (HN) to better understand how health professionals collaborate through the HN and how the HN affect their relationships. Within the HNs studied a common good unites the actors: the continuity of care for a better quality of care. However behind this objective of continuity of care other individual motivations emerge. Some controversies need also to be resolved in order to achieve cooperative relationships. HNs have notably to take national developments into account. These developments raise the question of the control of medical knowledge and medical practice. Professional issues, and not only practical changes, are involved in these innovations. Keywords. Health network, innovation, cooperation, professional relationships, electronic health records

1. Background In recent years international policies have aimed to stimulate the use of information and communication technologies (ICT) in the field of health care and have led to the establishment of health networks [1; 2; 3]. The use of ICT should make it possible to improve coordination and the efficiency and quality of care, thanks to a better exchange and sharing of information between the various health actors [4]. ICT can be an important support for care networks and integrated care, which are also gradually being set up. Belgium has also been affected by these developments: for example, the public health ministry funds local and regional networks (“health network”)2 and a national “eHealth” platform is being set up, in order to improve electronic exchanges of patient data between health practitioners3. General practitioners (GPs) can also receive annual financial support from the Sickness and Disability Insurance system for the costs of the software for computerising their patient records.

1 Corresponding Author: Caroline Artoisenet, Clos Chapelle-aux-Champs 30.41, 1200 Bruxelles, Belgium; E-mail: [email protected] 2 https://portal.health.fgov.be/portal/page?_pageid=56,4280388&_dad=portal& _schema=PORTAL 3 https://portal.health.fgov.be/portal/page?_pageid=56,4280428&_dad=portal&_schema=PORTAL

24

C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies

However, few doctors use their computing tools (such as electronic health records) for medical purposes and for exchanging information concerning their patients with other professionals [1; 4; 5; 6]. The implementation of electronic networks has turned out to face several barriers. Indeed, several studies have suggested that such networks show inconsistent outcomes, which may be related to difficult and variable implementation [1] due, for example, to the preferences of existing support staff, difficulties in integrating systems, [5] and organisational failures [7]. This research explores the implementation of two Belgian health networks (HN), in order to understand how an HN is formed and how physicians collaborate through the HN. In the first phase we followed the actors-partners of the HNs being studied in order to understand the project supported by HNs and the controversies surrounding these HNs. In the second phase of our research (2009) we plan to interview GPs and specialists (as potential users of HNs) to investigate how an HN can be used (or not) by them and their perceptions of these initiatives. A specific research methodology has been worked out. After having explained this methodology, we present our initial results and then discuss them. We finish by drawing conclusions from the first phase of our research and outlining new perspectives for research.

2. Methodology 2.1. Subject: Health networks This study focuses on a particular form of ICT: the health network. Following international developments, some HN projects are being established in Belgium. These aim to improve the quality of care by developing the electronic exchange of information between health actors (physicians), thereby improving cooperation between actors. The two HNs studied are at the conception and implementation stage. Technically, the data will remain in the original location of creation (a hospital, for example) and only a “master patient index” will be centralised and provide an index for information issued to authorised professionals [8]. Initially, these HNs will be open to all physicians (primary and secondary health care) in their region. 2.2. Approach The conception and implementation of HNs do not only involve technical issues. Although often neglected, organisational and professional elements are involved before, during, and after the implementation of these technological innovations. Thanks to a qualitative approach, we will be able to understand the process of their implementation, how the actors coordinate their actions in order to participate in the design of the HN, and how they cooperate. The setting-up of an HN raises a series of questions, which a quantitative approach cannot answer. 2.3. Process In the first phase of our research, the “primary” actors of the HNs studied have been followed: actors that participate in the conception and implementation of the HNs. Data were collected from observation data and thirteen face-to-face semi-structured


25

interviews with primary actors of the HNs (4 general practitioners or GPs, 6 representatives of hospitals, and 2 sponsors) and with non-active actors in the HNs (“negative cases”: 1 representative of a hospital). We made sure that the interviews included private, public, and academic hospital representatives. All the actors contacted agreed to participate in the interviews. In addition, they allowed the researcher to participate in their meetings concerning the HN. The interviews were recorded and transcribed, either by the researcher or by a secretary under the supervision of the researcher. The data were collected and analysed by using a framework developed from grounded theory [9], a qualitative research method that emphasises the generation of the theory from the data collected, thanks to open-coding (“coding” referring to the labelling of key points in the text), axial coding (creating links between the codes, thereby giving rise to new codes), and selective coding (choosing a central code linked with satellite codes) of the material. The investigations developed on the basis of the data collection around the following questions: who are the actors of the HN, what are the goals of the HN, what are the relationships between the actors (e.g. in relation to medical information), and what are the main problems with which the actors are confronted? After the collection of data and the initial empirical analyses, we drew on two major sociological currents: the actor-network theory and the sociology of professions, which help us to understand the emergence of HNs and the process of participation by physicians in HNs. 2.4. Quality control Some authors have suggested criteria and strategies to improve the rigour of a qualitative design [10; 11]; these strategies should, however, be used with caution [12]. The criteria include credibility and reflexivity. Triangulation is a strategy intended to increase the credibility of our results and implies, for example, combining several techniques, sources of data, and points of view: findings were triangulated from the different data collection methods; we used different sources of data (face-to-face interviews, observation data, writing data); we varied the profile of interviewed actors. With a view to reflexivity, the researchers who participated in the research have varied backgrounds: a physician, an economist, and sociologists. They participated in the working meeting and in each step of the research. An expert committee provided a benchmark for identifying and assessing the relevance of preconceptions.

3. Results The two HNs studied are focused on primary and secondary health care. They are in the conception and implementation stage, so they are not yet operational for practitioners. These two HNs follow broadly the same logic: do not centralise the data. The data remain in the original location of creation and only a master patient index is centralised [8]. After informed consent of the patients and identification, it will be possible for practitioners to integrate data into their electronic patient records.

26


3.1. The quality and continuity of care Within the HNs studied, a project or “common good” [13], unites the interviewed actors around the network: continuity of care for a better quality of care, through access to and sharing of medical information4. The objective of our network is the objective of the actual physicians, the physicians who treat patients. It is the continuity of care. … we concentrate on the real objective, that is, to treat patients in an appropriate way (public hospital)

This common good brings together some actors who, a priori, were not required to form an alliance. Indeed some hospitals can be in competition in the health market. There is a lot of competition for us, for our particular hospital. So that is why Mister X wanted to participated in the network. He has a lot of difficulty in attracting patients, as his hospital is in the European market. (private hospital)

Even if some actors consider that they have not enough time to actively participate in the network for the moment, they still support it: “it is better to be in than to be out.” There is, accordingly, a “transmission” effect of the network, which propagates the necessity of participation in the network in the field of health care. We are not very involved in this project. We are working in our hospital in order to be ready later, to participate at a later date in this network, which is important. I think that all the hospitals of the region that want to provide an excellent service will have to be in the network. (private hospital)

3.2. Health professionals as primary actors in the health network At first, some health professionals (GPs and professionals in hospitals), who know each other and have some shared interests, seized the opportunity of a national fund to create an HN. By doing this, they have mobilised all the relevant actors (medical professionals from primary and secondary heath care, at first, but also funders) within a particular geographic territory, interesting and involving them in the building of the network. So the network is maintained thanks to volunteer actors (in a bottom-up configuration). Participation in the HN is not compulsory (unlike in the UK, for example). But the actors respect certain “rules of the games”, such as the national standards kmher. Within an HN one of the actors, a GP, is gradually emerging as the spokesperson of the network and the translator of the objectives of the network to new actors, providing an intelligible link between heterogeneous activities and actors [14]. We have observed that this spokesperson organises and directs the meetings and is an important link with various funders and medical associations. He considers that “they [other actors in the network] trust me; I have received a mandate to go to the funders, to deliver information”. During the meetings this spokesperson also plays the role of 4

The activity report and the charter of the non-profit organisation that organises an HN confirm this.


27

mediator in cases of conflict between the network’s actors, notably in case of conflicts between hospitals. Several spokespersons can appear for only one HN: the spokesperson of the HN can be chosen according to the actors who he has to meet and according to the social network the potential spokesperson is already invested. 3.3. Relationships between health profession actors Each individual actor sees particular benefits in collaboration on the objectives of the HN. For example, quality of care means different things to different actors: improving public health (as mentioned in interviews with a GP and an academic hospital) or better follow-up of the patient (making more time for patients and reducing redundant medical procedures, as mentioned by another GP interviewed). For another (public) hospital the network also offers an opportunity to renew its computer system and to align itself with the other hospitals. Two other private hospitals participate in the HN in order to improve their image among GPs: e.g. a hospital has an interest in encouraging GPs to refer patients to it. And a better service provided to GPs can increase the number of patients referred to a particular hospital. We have decided to open our data to the GPs. Otherwise, we run the risk that GPs will not send us any more of their patients. So we are aware that we have to make every conceivable effort to try to be attractive to GPs. It is they who send us their patients. Thus it is clear that we really should rather look after the clientele of general practitioners. (private hospital)

The objectives and the added value offered by the network need to be repeated often in order to consolidate the network. The adherence of all the actors is repeatedly expressed during meetings. This makes it possible for the actors to unite around the common good of the network. 3.4. Controversies Some controversies need to be resolved in order to achieve cooperative relationships. These concern, in the first place, matters such as the network’s charter (how are the actors represented and how are decisions taken?), the choice of technical solutions, access, and write rights in relation to records. The two HNs quickly adopted a noncentralised solution for the structure of the network: they do not want to create a centralised electronic patient record. After all, the network actors have had to agree on who is authorised to access the records, for how long, etc. The two HNs do not exist in a vacuum. They have to take national developments into account: the national context plays a role in the development of the network. The success of projects other than the network can influence the progress of the network. Actors of the HNs studied would like to see a national platform looking after the system of access and the security, problems with which all networks are confronted. However the actors must cope with a lack of transparency and communication from actors in other projects such as national eHealth platform. The system of access and the security of the exchange should be set up at a national level so that we do not have problems later in combining all the networks. (private hospital)

28


We have approached eHealth [national platform] regularly to know if its services were available to us. But we have not received any answers. It is interesting to observe the contempt that they have for initiatives coming from physicians. (public hospital)

These external influences can hamper the development of HNs, but may also promote it. They can hamper because a national platform should look after the security of networks: security is an issue that involves major costs and national strategic choices (notably in regard to the law about the protection of private data). This partly explains why the regional HNs studied are still in the development phase. Recent developments in the national eHealth platform (formerly “BeHealth”) and other national telematics applications such as Ecare5 (for sickness and disability insurance), however, may lead to increased support from future professional users for regional HNs (in order to oppose these national initiatives). Indeed, some health professionals fear supervision by the sickness and disability insurance system and the health insurers of their data, and thus of their practice. There is the project of Ecare and others projects of the INAMI-RIZIV [sickness and disability insurance authority]; the INAMI-RIZIV is becoming active in this domain. It is surprising. Physicians have the impression of having been swindled by the INAMI-RIZIV. So there is a sort of war that is preparing for [between regional HN and national projects] and with us [the HN] as weapon. (public hospital)

Finally, there is also controversy about the funding, which is annual and not longterm. This type of funding can put at risk the durability of the project and its monitoring. In particular, the source of funds can be the subject of controversy. For example, some actors do not want health insurers or the sickness and disability insurance system to finance such networks. They fear they might lose their autonomy and also fear that the insurers would gain increasing control over professional practice. I distrust the INAMI-RIZIV [sickness and disability insurance authority]. For me it is an intermediary between the ministry and the health insurers. It is more a supervisory body than an organisation that supports projects. It is not its role. (private hospital)

3.5. And what about the patients? Among the actors actively mobilised by the networks, the patient is relatively missing. A legal framework, however, obliges the medical professional to obtain the informed consent of the patient before exchanging information concerning him/her. Currently in the two HNs, patients must give their consent in order to authorise the exchange of their data between professionals and patients will have access to the list of the professionals who have accessed their data [15; 16]. However, direct access by patients to their own data is not yet under consideration.

5

Recording system for medical data in relation to certain specific pathologies


29

4. Discussion 4.1. The HN as an professional obligatory passage point Thanks to its objectives (quality and continuity of care) the HN tends to become an “obligatory passage point” [17] so that it becomes indispensable: in order to improve the quality and continuity of care, health professionals have to participate in the HN. The two initiatives studied are bottom-up initiatives and this has boosted their potential success: it is health professionals who work on the HN and support it. To consolidate the formation of the network, some “objects” (charter, minutes of meetings, etc.) pass through the network. They can be considered as collective intermediaries that link the actors to each other [13]. 4.2. A market of interdependent and distinct parties As we have observed, it is sometimes necessary to repeat the objectives and reaffirm the adhesion of the members of the HN. Indeed, behind the objective of continuity of care other individual motivations emerge. For example, some actors collaborate with the HN in order to attract more patients and consequently to be more competitive on the health care market. Indeed. health care is in a market of interdependent and distinct parties that struggle for resources, favourable public opinion, territory, and control [18; 19]. These parties have different interests, cultures, and goals that can be in tension with each other, although significant alignments are possible (e.g. around the common good of care continuity); each seeks to advance its own interests [18]. The medical profession is no longer necessarily dominant in the health market. So spontaneous and professional initiatives of an HN can be at the heart of professional issues. The implementation of a professional network and participation in this network can become a means of resisting external constraints and restoring professional dominance. EHealth platform and initiatives from the sickness and disability insurance authority can be seen as external constraints for the professional actors. Regional networks need some secure processes of identification and authentication of the professional, identification of patients, and need data exchanges to be made secure. A national platform such as eHealth can meet these needs. However, regional networks feel threatened by the way this national platform is being set up: they consider that there has been very little dialogue with the existing networks and with professional associations [20], whereas the regional and local networks were conceived and supported by professionals themselves (top-down configuration versus bottom-up configuration). The latter kind of configuration increases the chances of success by decreasing the fear of “big brother” controlling practice. As a consequence, regional networks now have the support of various professional associations and have signed common statements questioning some aspects of the eHealth platform [20]. The history of the eHealth platform reinforces the fear of “big brother” and supervision of practice. Indeed, the platform was conceived on the model of the Crossroads Bank for Social Security and by the designer of that Bank. Consequently, some professionals fear links between medical data and social security data. The objectives are also wider than those aimed at by regional networks: support for public policy and exchange of data with health funders. They will have the means to carry out public health analyses thanks to the data collected. Accordingly, this raises the question of the control of medical knowledge: “A fundamental change in the balance of power

30


has come from the ability now of employers or government to analyse the practice patterns of providers more systematically than they can themselves” [18]. 4.3. The patients At the heart of the HN are the patients. The need for the informed consent of patients has not been overlooked by the HNs. One of the HNs has already written a regulation for the protection of data privacy. This provides protection for patients, as well as a means of supervision. Through access to the list of professionals who have accessed his/her data, the patient can influence the correct functioning of the system. In this way professional access to data will be controlled by patients. 4.4. Limits Thanks to a qualitative methodology we are now in a better position to understand how and why health professionals participate in the conception and implementation of HNs, which project is supported by the HN, and the controversies the actors have to deal with. A number of strategies have been used in order to improve the rigour of our design and validate the results: triangulation of data technique and coding, a multidisciplinary team and an expert committee to lessen the influence of preconceptions on the results. However, some limits to this study need to be reported. The first phase of this study focused only on the primary actors of the HNs and not on private users. The second phase of the study, however, will make good this lack. This study took place in a particular context, which is constantly evolving. More work is needed to determine whether these results are observed in other settings and to see how the HNs studied will evolve in the light of recent national events. We can, however, be confident about the fact that some professional issues will be spontaneously highlighted too.

5. Conclusions This study suggests that not only technical, but also professional issues are involved in the building of HNs. These findings have some implications for public health policies. Professional issues, and not only practical changes, must be taken into account in order to improve professionals’ use of these systems, and reap all their potential benefits, such as collaborative practice. This means, for example, ensuring the security and the supervision of data, as well as a better follow-up of patients. The technical infrastructure should be flexible enough for users and should allow users to respond to their professional needs. This raises the question of the balance between a minimal standardisation and the possibility of personalisation of the use of network. To be used, the network must be able to answer the needs of the user. As professional issues underlie the use of technological tools such as HNs, the manager and funder of the network are also important choices for the health professionals in order to ensure that these professionals actually use the network. Further research is planned to investigate, in particular, the consequences of participation in such HNs for the practice and more particularly for the doctor-patient relationship. More work is needed to investigate the building of HNs, the participation


31

of health professionals, and their collaboration. Over the coming months we will follow the evolution of these two HNs with regard to the development of the national eHealth platform and practitioners’ perception of such initiatives: once they have been designed, HNs still have to be used by professionals.

Acknowledgements Project financed by the Brussels Capital-Region

References [1] [2]

[3] [4] [5] [6]

[7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]

[19] [20]

Scott J.T., T.G. Rundall, T.M. Vogt and J. Hsu (2005). Kaiser Permanente’s experience of implementing an electronic medical record: a qualitative study. Br. Med. J., 331, 1313-1316. Hendy J., B.C. Reeves, N. Fulop, A. Hutchings and C. Masseria (2005). Challenges to implementing the national programme for information technology (NpfIT): a qualitative study. Br. Med. J., 331, 331336. Coiera W.E. (2007). Lessons from the NHS National Programme for IT. MJA, 186, 3-4 Garrido T., L. Jamieson, Y. Zhou, A. Wiesenthal and L. Liang (2005). Effect of electronic health records in ambulatory care : retrospective, serial, cross sectional study. Br. Med. J., 330, 581-585. Reider J. (2002). Practical use of computers in the family practice office setting, American Academy of family physicians (AAFP). Annual Scientific Assembly. Mackelbert Y. (2005). Community health care : « vers une continuité des soins en temps réel ». Communication à la conférence « Vers la e-Société - L’économie de la connaissance et l’innovation en Europe et en Belgique », Belgique, présentation powerpoint. Berg M. (2001). Implementing information systems in health care organizations: myths and challenges. Int J Med Inform, 64, 143-156. Van de Velde R. (2005). Project « Abrumet » - Proposal for a Regional Medical Network. Telematics Symposium, Brussels. Strauss A. and J. Corbin (1990). Basics of qualitative research: grounded theory procedures and techniques. Newbury Park: Sage Publications, 288. Malterud K. (2001). Qualitative research: standards, challenges, and guidelines. Lancet, 358, 483-8. Mays N. and C. Pope (1995). Rigour and qualitative research. Br. Med. J., 311, 109-12. Barbour RS. (2001). Checklists for improving rigour in qualitative research: a case of the tail wagging the dog?. Br. Med. J., 322, 1115-7. Amblard H., P. Bernoux, G. Herreros, Y.-F. Livian. (2005). Les nouvelles approches sociologiques des organisations. Paris: Seuil, 292. Latour B. (2005). La Science en action. Paris: La Découverte, 664. Alsteens G., JP. Binon, J. Braeckeveldt, J. Bury, et al. (2006). Le réseau santé wallon. Spécifications techniques et fonctionnelles. 71. Cahier spécial des charges relatif au projet BHIP – Brussels Health Information Platform. Accès sécurisé centralisé aux dossiers médicaux des patients. (2007), 94. Callon M., B. Latour (1991). La Science telle qu’elle se fait. Paris: La Découverte, 390. Light D.W. (2000). The Medical Profession and Organizational Change: From Professional Dominance to Countervailing Power. in Bird, C.E., Conrad, P., Fremont, A.M. (eds), Handbook of medical sociology, 5e Edition, New Jersey: Prentice hall, pp. 201-216. Timmermans S. and E. Kolker (2004). Evidence-based medicine and the reconfiguration of medical knowledge. Journal of Health and Social Behavior, 45, 177-93. Conseil National de l’Ordre des Médecins, ABSym-BVAS, AMF, CARTEL-GBO, SVH, GBS-VBS, FAG, DOMUS MEDICA, FMMCSF, ABRUMET, FRATEM, SSMG, et al. (7 juillet 2008). Projet de loi relatif à l’institution et à l’organisation de la plate-forme eHealth. Communiqué commun des associations médicales belges. http://www.absymbvas.be/ABSyM/Comdepresse.htm/compresse080710.pdf

32


LISA, the next generation: from a webbased application to a fat client Noëlla PIERLET, Werner AERTS, Mark VANAUTGAERDEN, Bart VAN DEN BOSCH, André DE DEURWAERDER, Erik SCHILS, Thomas NOPPE Department of Information Technology, University Hospitals Leuven, Belgium

Abstract. The LISA application, developed by the University Hospitals Leuven, permits referring physicians to consult the electronic medical records of their patients over the internet in a highly secure way. We decided to completely change the way we secured the application, discard the existing web application and build a completely new application, based on the in-house developed hospital information system, used in the University Hospitals Leuven. The result is a fat Java client, running on a Windows Terminal Server, secured by a commercial SSL-VPN solution. Keywords. Web access, electronic patient file, referring physician.

1. Introduction Back in 2000, the University Hospitals Leuven successfully rolled out an in-house developed web application, called LISA [1]. LISA stands for “Leuvense Internet Samenwerking Artsen”. It is an application written for referring physicians so that they can look at the live electronic medical record of their patients. This way, the physicians can follow the trail of their patients throughout the hospital, see their lab-results, the scheduled exams, the radiology images and the conclusions of the physicians in the hospital. At that time, the application was secured by one-time passwords, all communication between the browser of the physician and the hospital was encrypted with the latest encryption technology (AES, [2]) and the web application itself was designed on top of a portal server. The application gained a lot of popularity amongst physicians and patients, and soon commercial variants came on the market. In this paper we investigate why we decided not to continue with this technology, which approach we took, and what the consequences are of the choices we made.

2. Limitations of the Old Setup 2.1. The User Experience At about the same time the LISA application was being rolled out, the hospital information system (HIS) used in the University Hospitals Leuven, was being rewritten from an application with a graphical user interface (GUI) based on the X Window System, the standard toolkit to build GUI’s on UNIX-like operating systems, to a fat Java client, with a GUI based on Swing, a widget toolkit for Java. Where possible,

N. Pierlet et al. / LISA, the Next Generation: From a Web-Based Application to a Fat Client

33

isolated components were being outsourced, and integrated in the new HIS, to speed up development. While new functionality was introduced in our HIS, we found it difficult to extend LISA with the same functionality and possibilities because of the limitations of HTML. User interaction elements that are natural to applications like double-click and dragand-drop were not possible in a web browser. It was impossible to integrate the outsourced components in the LISA application. All the functionality that we put in the HIS ourselves had to be completely rewritten before we could integrate it in the LISA application. The technology of the portal server the LISA application was running on, was different from the technology of the HIS, so only 2 developers had the knowledge necessary to change and extend the LISA application. 2.2. The Security Setup The technical constraints we put on the browser and the computer of the physician, were also a problem. The encryption and decryption of all communication between the hospital and the browser of the physician was handled by a java servlet running in the browser. When we started the roll-out of LISA, the java plug-in was not installed in the browser most of the time. Installation of the plug-in was far from easy and required a lot of interaction of the user. If the plug-in was installed because the physician used a home-banking application, often the installed java plug-in had a conflicting version. At that time, we also had to cope with the differences between the plug-in provided by Microsoft and the plug-in provided by Sun Micro Systems. After a while, when the majority of the browsers had a java plug-in, the next problem arose: popup-blockers prevented the opening of new windows. Most of our users weren’t aware that they had activated a popup-blocker when downloading the Google toolbar or installing the latest service pack of their OS. Last but not least, there was the fight with the firewalls. Our servlet was actually a java implementation of a secure shell client, connecting to port 22 of our firewall. Unfortunately, the standard configuration of a lot of user firewalls seemed to block all communications going to port 22. A lot of energy was spent trying to figure out the technical problems, time that was better spent developing new functionality.

3. Do We Need a New Application? The LISA application was written as a portal application, based on proprietary software. Unfortunately, this proprietary software was discontinued. Considering the fact that a partial rewrite was necessary to continue development of LISA, considering the double effort that had to be delivered to provide the functionality and all the efforts put in supporting the physicians with their technical problems, the IT department decided to suspend the development of the LISA application and to look for an alternative.

34


4. The Search for Alternatives 4.1. The Requirements The requirements of the new application were clear, but complex. As medical data are very sensitive, strong authentication and encryption were required. But the technical setup should not impose too stringent requirements on the computer of our users. At the same time, the security solution chosen for the LISA project should also be extendible for users of the University Hospitals Leuven, to access the network of the hospitals in a secure way, to allow them to work from home. The whole setup should be user friendly, intuitive. The new application should at least provide access to the same information that was available in the existing LISA application, including the radiological images, which require a special viewer. Technologies should be investigated that give the user the experience of a real application, instead of a web site. This rich user experience includes a near instant response time and extended interaction possibilities, for example by double-clicking, sorting of columns by clicking on the header, drag-and-drop and cut/copy/paste. [3] Double development had to be minimized. Every java developer in the IT department had to be able to write code for the new application. No proprietary software should be used. 4.1.1. Security Requirements For strong authentication, we decided to continue using the existing system. Since 2000, we use the Digipass 300 of Vasco Security Systems [4]. It is a small device that, after entering a pin-code, generates a one-time password. All servers and software to use this kind of authentication were already available. Our users were familiar with it, as this device was used for authentication in web-LISA. The communication protocol used with the web-LISA was secure shell, with AESencryption technology. As we had problems with connections to port 22, we preferred using the SSL/TLS protocol, as most firewalls do not have problems with port 443. 4.1.2. User Requirements It is obvious that an application should be user friendly. Making the whole setup user friendly is not only about making a decent application, it involves also an easy installation of software, automatic distribution of new updates of any software component used and last but not least handling the whole authentication process, which most of the time consists of authentication with different accounts, on different security levels, and with different credentials. In the University Hospitals Leuven, courses are organized for nurses and physicians to learn all the functionality of the HIS. We considered it to be unfeasible to travel around the country and organize lessons for all our referring physicians to learn them to use the LISA application. 4.2. The Solution Since the start of LISA, web technology has evolved tremendously. New techniques for creating interactive web applications and rich Internet applications (RIAs) are available, like Ajax, a collection of technologies used for building dynamic web pages on the


35

client side, and Adobe Flex, an application framework for building RIAs that can run in the browser or on the desktop[5]. The moment we had to make the decision how to proceed with the new version of the LISA application, most of our developers were not familiar with those new techniques. General adoption by the IT market was not clear yet for some techniques, others were considered not mature enough to be used in a production environment. To maximize code re-use and the possibility to integrate thirdparty components and to minimize the development time, we opted to build the LISA application as a fat Java client with a Swing user interface, just like our HIS. There are different commercial solutions available to give users access to remote applications. The quality of the radiological images available in the LISA application was a limiting factor. To improve graphic responsiveness when scrolling through images and to save bandwidth, some of these solutions use compression techniques with reduced quality of the images as a result. The quality after compression is important as a fine detail on a scan can make a huge difference for the resulting diagnosis. The quality of the compressed images, the scalability of the setup and the price of the investments that had to be done, were taken into account when comparing the different solutions. In the end, we have chosen to run the application on a Microsoft Windows Terminal server, as this was a technology we already used in our hospital, the quality of the images was comparable to the competitors, and the price was more favorable. While a developer started working on the new LISA application, in parallel, different commercial products were investigated to see if they could provide a solution for the security requirements. It turned out that securing access to a terminal server was not the biggest problem. Integration with our digipasses was natural, as almost all systems supported radius authentication. Several solutions were available. The breaking point turned out to be the multiplicity of credentials that had to be used. A login and a one-time password had to be used to setup the secure connection. Then another login and a password were necessary to gain access to the terminal server. A third login and password were needed to login in the application. A single sign-on solution was needed. It took a search of several months, with a lot of meetings with various commercial companies to finally find Juniper Networks’ Secure Access. Their software gave us the possibility to pass credentials around so the end-user has to logon only once, when in fact he is authenticated on three different levels.

5. The Final Picture Development of an initial version of the fat LISA client only took about two months. The initial version contained all the functionality of the existing web application. The application was installed on a terminal server and a preliminary setup was made to secure the access to the terminal server. At that time, a think tank was formed with ten referring physicians. They were selected based on their technical knowledge of computers and their intensive usage of the web-version of LISA. Their input was of priceless value. They told us that certain functionality that seemed important to us was not helping them at all. So we decided not to add the possibility to make appointments for their patients, as this was too timeconsuming for them. Vice versa, some features, that didn’t cost much development

36


time, such as the possibility to send a clinical report to their own patient file, made a lot of difference to them. They started testing the application for three months. During those three months, further development was done. The remarks of our testing physicians were taken into account and new functionality, that was already available in our HIS, was added to the new LISA application. During the testing period, the Juniper solution was found and a proof of concept was installed. After a successful test of the single sign-on solution, the number of testusers was increased: users, who let us know they were not pleased with the old application, were added to the group. As those sceptic users became very enthusiastic users, we were convinced that we were back on the right track. In January 2008, we were pleased to announce a new LISA application to our users. In the beginning, we let them choose between the old and the new application. Soon we noticed that users, who tried the new application, kept using the new application. Apparently the new functionality and increased speed were convincing. In April 2008, we stopped the web application. One year after the start of the development of the new LISA application, our migration was complete.

6. Evaluation 6.1. Growing Functionality Since the initial release for our test-users, a lot of functionality that was not available in the web application was added to the new LISA application. Our LISA users now have access to the images of their patients, taken by our physicians, for example to follow up the evolution of wounds. Lab results were already available in the web-based LISA application. In the new application, they can compare the results of the different tests over time and put them in a graph. We now have an intense cooperation with oncologists who use our application to calculate the doses of chemo they prescribe. The fertility dossier is a component of our HIS that was developed by a third party. We successfully integrated this component in LISA. A pilot project was set up to share our fertility dossier with other fertility centres, by means of LISA. 6.2. Easier Support Our helpdesk is happy with the migration to the new application. Because the application is running on a computer on the network of the University Hospitals Leuven, they can, with permission of the user, take over his screen and advise him. 6.3. Uncomplicated Software Upgrades On first connection to the LISA application, the Juniper box installs some software on the computer of the user. These installations all happened without any problem. In some occasions, an update of the operating system was necessary, but this was documented by Juniper.


37

New versions of the LISA application are easy to install as we have full control of the terminal server and the software components installed on it. 6.4. Code Reuse The code reuse of our HIS is maximal. Some components, developed especially for LISA, even found their way into our HIS. Other developers have joined the project and are writing components for LISA just as they do in our HIS. 6.5. What Do the Users Say? When we decided to stop supporting the old LISA application, we sent an e-mail to all the LISA-users to inform them about the changes. A lot of users, who hadn’t been using web-LISA for a long time for several reasons, started using the new LISA application again. 6.6. Negative Aspect There is one aspect that became more cumbersome: printing. In the web application, we didn’t have to think about printing. One just had to use the print-button in the browser. Printing through a terminal server turned out to be more complex and required some extra development.

7. Final Conclusion The complete revision of the LISA project made clear to the referring physicians that the University Hospitals Leuven are committed to keep investing in the project. The new architecture opens up more possibilities and several new features and functionality are planned: an interesting future lays ahead for LISA.

References [1] [2] [3] [4] [5]

E.Bellon et al., Web-access to a central medical record to improve cooperation between hospital and referring physicians, Studies in health technology and informatics, 93 (2002) 145-153 National Institute of Standards and Technology, Federal Information Processing Standards Publication 197: Advanced Encryption Standard, http://www.itl.nist.gov/fipspubs Dick Berry, The user experience, Part 1, http://www.ibm.com/developerworks/library/w-berry2.html Vasco, Case Study University Hospitals Leuven, http://www.vasco.com/products/casestudies.html Flex overview, http://www.adobe.com/products/flex/overview

38


Trans-eCare: Creating a Transparant Data Exchange Platform Heidi BUYSSEa, Pascal COOREVITSb, Geert THIENPONTb, Georges DE MOORb a Dept. of Medical Informatics & Statistics, Ghent University, Belgium b Research in Advanced Medical Informatics and Telematics vzw, Belgium

Abstract. Home health care (HHC) organizations as well as hospitals encounter information-tracking problems regarding their patients. When a patient is admitted to the hospital, it is not always possible/easy to find out if this person already had HHC and if so, by which organization it was provided. HHC organizations also not always know to which hospital a person is admitted. At discharge, although discharge documents exist, HHC organizations not always receive the necessary information. However, sharing information between the different care-partners involved is important, among others for the continuity of care. Hospitals will gain better insight in the provided home care before admission, and HHC organizations will get a more complete and direct insight in the course of care at the hospital. In doing so, they are better prepared to provide the necessary care for the patient admitted to the hospital or returning at home. Discussion with the partners involved in the IBBT-Trans-eCare project resulted in tracking the current problems, defining goals and presenting a solution to meet the defined problems. Keywords: eHealth, data-exchange, chronic diseases, hospital, home care services

1. Introduction Life expectancy increases resulting in a growing proportion of elderly with chronic diseases and disabilities. In Belgium, according to the national Health Interview Survey 2004 [1], almost a quarter of the population suffers from at least one chronic disease and the risks increase with age. In this health survey, six clusters of chronic diseases were distinguished, namely 1) musculoskeletal diseases, 2) lung diseases, 3) neurological diseases, 4) heart diseases, 5) cancer and 6) diabetes. Co-morbidity occurs in eight percent. In the age group of 75 plus, 31% suffers from more than one chronic disease from different clusters. A lower degree of education is also associated with higher possibilities to report suffering from one or more chronic diseases which is also confirmed by Dalstra et al. [2]. In the European Union, the chronically ill wants to stay at home as long as possible and additionally, hospitals want to discharge people as early as possible [3;4]. An important goal is thus increasing co-operation between organizational levels [5-7] to make sure there is continuity of care. Interaction and information-sharing between the actors involved then becomes necessary [8-11]. The focus of this study lies in describing current problems regarding informationtracking for hospitals as well as home care organizations and in proposing possible solutions. This study is part of the IBBT-Trans-eCare project. It aims at supporting the home care process using Information and Communication Technology (ICT), where

H. Buysse et al. / Trans-eCare: Creating a Transparant Data Exchange Platform

39

one of the focuses explicitly lies on data exchange between the professional actors involved.

2. Research Design and Methods Firstly, a general discussion between the different technical as well as social partners took place in order to identify the project’s goals. The technical partners were specialized in information security and broker architecture. The social partners involved in the project were the Ghent University Hospital and the HHC organizations Wit-Gele Kruis and Solidariteit voor het Gezin. Each partner was represented by at least a manager and another person relevant for this project e.g. social nurse for the hospital, head HHC nurses for HHC organization and so on. Consequently, the actors to be involved to reach these goals had to be identified which was done through discussions between key personnel from the social partners. In-depth discussions with the actors from hospital and HHC organizations made clear what information was available, how it was stored, who was responsible and how information was shared (if it was shared at all) between different actors. These discussions took place with each actor individually. Afterwards, this information was analyzed and presented in a meeting to the social partners. This meeting was then followed by a general meeting at which social as well as technical partners were present. Social partners were hereby also represented by technical people. Nursing staff are very good in expressing what they do and where technology could help them improve care but they are mostly not aware of the current ICT-situation in their organization. A final discussion between nursing staff, technical people from the social partners and people from the technical partners revealed information-tracking problems where after possible solutions were proposed. Technical information was shared between the involved partners to work out the proposed solutions and a time-schedule was presented to the project leader.

3. Results The actors involved in this project can be divided into social and technical partners. Social partners are hospitals and home health care organizations, while the latter are more specialized in information security and broker architecture. Technical as well as social partners emphasized the importance of setting realistic user-driven objectives with the remark that the input from the social partners was crucial. 3.1. Actual Situation Before communication about a patient becomes possible, some problems need to be identified. HHC organizations not always know if a patient is admitted to the hospital and in case they know a patient is admitted, they not always know in which hospital the patient is. Also the hospital nursing staff recognizes such problems. They not always know if a patient already received HHC before admission and if yes, they do not

40


always know from which organization. In both situations, communication between the HHC organization and hospital regarding the patient is impossible resulting possibly in discontinuity of care. To solve these problems some HHC organizations visit the hospitals on a fixed day; others call the hospitals to get the information required. Hospitals mostly call the different HHC organizations to know if a patient is known by any HHC organization. Nowadays, communication between the HHC organizations and hospitals is not computerized. When a patient receiving HHC is admitted to the hospital, HHC stamps a document which is afterwards filled in by hand by the HHC nurse. Subsequently, this document is transferred to the hospital by mail. However, quite some information filled in manually could be automatically extracted from the electronic HHC patient record. In a similar manner, when a patient is discharged from the hospital, information from the hospital could be automatically communicated to the HHC organization. Even though discharge information is available, the HHC organization not always receives this information. Patients sometimes hold the information for themselves or the General Practitioner is keeping all the information. Sharing information between the different care-partners involved – in casu the hospital and HHC organizations – is important, among others for the continuity of care. Hospitals will gain better insight in the provided HHC before admission, and HHC organizations will get a more complete and direct insight in the course of care at the hospital. In doing so, they are better prepared to provide the necessary care for the patient admitted to the hospital or returning at home. However, if automation takes place, it is of utmost importance that the persons in question not only receive but also read the information. 3.2. Possible Solution with ICT It is important to define ‘a known patient at HHC’. Different scenarios can be distinguished (Figure 1). For a first scenario (A), a patient can be unknown whereby no further information-consultation is possible. Only a new application for HHC can be done. In a second scenario (B), a patient is known at the HHC organization but there exist no actual contacts, defined as current date minus 24 months, and thus no further information-consultation is possible. Actual contacts are here defined as date of pull minus 24 months. This period was chosen based on the in-depth discussion with the social nurses of the hospital. For them, in order to provide the necessary care, it is important to have an as complete picture of the patient and thus also have a view on the history of (home health) care given before admission. Currently, they mostly lack this information. In this scenario B, a new application for HHC is possible. The patient can be actually known (there are actual contacts) at the HHC organization (scenario C). Further information-consultation is thus possible if the under mentioned conditions are met. At the last scenario D, it could be that the patient is known and actually known but with a temporary discontinuity of care. However, because the patient is actually known, the same conditions hold as in scenario C.


41

Figure 1: possible scenarios for defining a known patient at a home health care organization

For an actually known patient, information-sharing between the HHC organization and the hospital is possible under certain conditions. Only authorized users should have this opportunity and the role-relationship should be clearly defined. Furthermore, patients should have signed a paper granting permission to exchange information. A push or pull scenario could be a possible solution to meet the first problem, knowing where a patient is admitted or from which HHC organization the patient received HHC. In a push scenario, an alert is pushed. However, this alert can only be pushed if the organization that wants to send it, knows to whom it has to send. Otherwise there will be an overload of alerts with probably nobody noticing them. Furthermore, after sending an alert, a pull from the receiver still has to follow. Conversely, in a pull scenario the person who needs the information initiates the action. As mentioned earlier, it is of utmost importance that the persons in question not only receive but also read the information. If the person seeking for information initiates the pull, it is quite certain that he also will read the information. Even if the initiator does not know where the patient is admitted (received HHC) or from which organization he/she received HHC (is admitted to which hospital), the secured server containing role-relationships will transfer the pulls to the local hospital (HHC organization) systems. If a patient is actually known and the person who pulls for information is authorized, further information exchange is possible depending on the defined roles. These roles are defined by the Board of Directors of the concerned hospitals and HHC organizations. For this project important roles are among others ‘social nurse of the hospital’, ‘head nurse of each department at the hospital’, ‘HHC nurse’ and ‘administrative worker HHC organization’. Although each person has a certain role, there still should exist a relationship with the patient concerned. The patient has to sign a paper giving explicit consent to exchange information between his HHC organization and the hospital. Once this paper is signed, the concerned rolerelationships are added to the database on the secured server. If the patient recalls his permission, the concerned role-relationships are immediately removed from the database whereby no further access is possible. The unique identifier used in this project is the Belgian national ID because as well as the concerned hospital as HHC organizations currently use it. Figure 2 describes a pull-scenario for the HHC organization but the same is possible for the hospital pulling for information to know where a patient received HHC before admission.

42


Figure 2: A pull-scenario for home health care to know to which hospital a patient is admitted.

After a positive result from a pull, the information can be consulted but not be copied to a local computer. However, a discharge letter or other information especially addressed to the concerned person/organization can be imported to the local electronic patient record. Not allowing information to be copied has certain advantages, among others that only the most recent and updated information can be consulted and that the owner of the information remains the same. Furthermore, every organization/hospital decides which information may be consulted, based on role definition allowing each organization to follow its own policy. In a first phase it has been decided to only communicate information that is important for the continuity of care and that is technically quite easy to implement. At present, communication between hospital and HHC organization will use the existing KMEHR-standard message structure. If a patient is admitted to the hospital, the HHC organization could share information such as HHC coordinator, information of the contact person of that patient and the relationship with him/her, care schedule of the last two months and care profile (Weckx-scale or Katz-scale). The hospital could transfer the discharge document in an electronic format that could directly be captured in the electronic HHC patient record. A first test will run in December 2008 where after an evaluation will take place. Both participating HHC organizations and the Ghent University Hospital will, if the evaluation is positive, continue to use the proposed solution in the future.


43

4. Conclusion Home health care organizations as well as hospitals encounter information-tracking problems regarding their patients. With IBBT-Trans-eCare a solution is proposed to solve both problems. The Belgian Government recently (10 July 2008) approved the government bill on establishment and organization of the eHealth-platform [12]. It is a secure electronic exchange platform and has the intention to make exchange of information possible between all healthcare actors thereby respecting privacy. The aim of the eHealthplatform is to improve the quality of care and safety of the patient by means of sharing relevant patient-information and information regarding the provided care in a good and organized manner. Another advantage will be the administrative simplification for patients as well as health care professionals and institutions. The eHealth-platform will also support the health policy by relaying information from research and analysis. The described project shares the same goals as the eHealth-platform but on a smaller scale. Once the eHealth-platform is fully functioning, it should be easy for the concerned partners to move over. However, the project is important. HHC organizations not always are aware of the technical possibilities and are sometimes afraid to implement something new. The in-depth interviews revealed the importance of discussions between the different partners and searching for lacks in the current information-exchange where ICT could reveal a solution. Although this was not the scope of this paper, nurses in hospitals as well as in HHC encounter a lot of stress and burn-out (a known phenomenon): a fast search in PubMed revealed >100 hits for ‘nurses burn-out’. Therefore, implementing something new should not lead to an extra work-load. The proposed solution will be evaluated from both a technical as well as a social viewpoint. After a positive evaluation, the exchange of information will be expanded to other important data. In this stage however, it was chosen to start with relevant and limited information consultation and exchange. Further research should provide more insight in the possible positive results of using pull scenarios for electronic consultation/exchange of information.

Abbreviations HHC: Home Health Care IBBT: Interdisciplinary Institute for BroadBand Technology Trans-eCare: Transparant ICT platforms for eCare ICT: Information and Communication Technology KMEHR: Kind Messages for Electronic Healthcare Record

Acknowledgements Trans-eCare is an IBBT-project in cooperation with the following companies and organizations: Televic, Androme, Custodix, In-HAM, Solidariteit voor het Gezin, UZGent, Wit-Gele Kruis, ICBN/Intex-UGent, MIG/RAMIT-UGent, CUO-KULeuven, ICRI-KULeuven, EDM-UHasselt, and SMIT-VUB. IBBT is an independent multidisciplinary research institute founded by the Flemish Government, to stimulate ICT innovation. http://www.ibbt.be/en/project/transecare

44


References [1]

Wetenschappelijk Instituut Volksgezondheid. Gezondheidsenquête België 2004. http://www.iph.fgov.be/epidemio/epinl/crospnl/hisnl/his04nl/hisnl.pdf (last accessed 29-4-2008). [2] Dalstra JAA, Kunst AE, Borrell C, Breeze E, Cambois E, Costa G et al. Socioeconomic differences in the prevalence of common chronic diseases: an overview of eight European countries. Int J Epidemiol 2005; 34(2):316-326. [3] Demiris G. Electronic Home Healthcare: concepts and challenges. Int J Electronic Healthcare 2005; 1(1):4-16. [4] Scheepmans K, Debaillie R, De Vliegher K, Paquay L, Geys L. Succesfactoren en hinderpalen in de thuiszorg: de beleving van de mantelzorger. 384.02, -55. 2005. Brussel, Federatie van Wit-Gele Kruisverenigingen van Vlaanderen. [5] Lind L, Sundvall E, Karlsson D, Shahsavar N, Ahlfeldt H. Requirements and prototyping of a home health care application based on emerging JAVA technology. Int J Med Inform 2002; 68(1-3):129-139. [6] Celler BG, Lovell NH, Basilakis J. Using information technology to improve the management of chronic disease. Med J Aust 2003; 179(5):242-246. [7] Kobb R, Hoffman N, Lodge R, Kline S. Enhancing elder chronic care through technology and care coordination: report from a pilot. Telemed J E Health 2003; 9(2):189-195. [8] Ryan P, Kobb R, Hilsen P. Making the right connection: matching patients to technology. Telemed J E Health 2003; 9(1):81-88. [9] Chu S. Implementing Health Event Summary Using Clinical Document Architecture: The Application of Clinical Process Analysis Methodology. The journal on Information technology in Healthcare 2003; 1(4):279-301. [10] Helleso R, Lorensen M, Sorensen L. Challenging the information gap--the patients transfer from hospital to home health care. Int J Med Inform 2004; 73(7-8):569-580. [11] Waldo B. Telehealth and the electronic medical record. Nurs Econ 2003; 21(5):245-6, 210. [12] Belgian Government. The bill on establishment and organization of the eHealth platform. https://www.behealth.be/behealth/goTo.do?news.action&newsid=_001 (last accessed 11-8-2008).

2. Transeuropean eHealth



Legal aspects of E-HEALTH a

Stefaan CALLENS a, Kim CIERKENS b Lawyer at the Brussels Bar, Professor of Health Law KULeuven b Lawyer at the Brussels Bar

Abstract. Cross-border activities in health care in the European single market are increasing. Many of these cross-border developments are related to e-Health. EHealth describes the application of information and communication technologies across the whole range of functions that affect the health care sector. E-health attracts a growing interest on the European level that highlights the sharp need of appropriate regulatory framework able to ensure its promotion in the European Union. Some Directives constitute a step in this direction. Both the Data Protection Directive, the E-Commerce Directive, the Medical Device Directive and the Directive on Distance Contracting are some of the most important European legal achievements related to e-Health. Although the directives are not adopted especially for e-health applications, they are indirectly very important for e-Health. Firstly, the Data Protection Directive applies to personal data which form part of a filing system and contains several important principles that have to be complied with by e-Health actors processing personal data concerning health. Secondly, the E-commerce Directive applies to services provided at a distance by electronic means. Many e-Health applications fall within this scope. Thirdly, the Medical Devices Directive is of importance for the e-Health sector, especially with regard to e.g. the medical software that is used in many e-health applications. Finally, the Directive on Distance Contracting applies to contracts for goods or services which make use of one or more means of distance communication; E-Health business may involve the conclusion of contracts.

Despite these Directives more developments are needed at the European level in order to make sure that e-Health will play an even more important role in health care systems than is the case today. The new e-Health applications like electronic health records, e-health platforms, health grids and the further use of genetic data and tissue involve new legal challenges. Several member states are introducing electronic health records or e-Health platforms. The use of electronic health records that contain data of several health actors poses new risks with some legal consequences. Recently, grids are being used in some ambitious medical and healthcare applications. In order to be truly effective such grid applications must draw together huge amounts of data from disparately located computers – which implies data sharing across jurisdictions and the sharing of responsibilities by a range of different data controllers. E-Health will also enhance the further use of human tissue and genetic data. More and clear guidelines on the reimbursement criteria for telemedicine and on liability would also be very useful. Guidance at the European level can be given as to the criteria that (tele-) health sessions will have to comply with for reimbursement purposes, since it is still unclear when e-Health sessions will be reimbursed. It is clear that the existing European legal framework is not finished yet and that more specific European rules are needed. Keywords. e-Health, legal aspects, telemedicine.

47

48

S. Callens and K. Cierkens / Legal Aspects of E-HEALTH

1. Introduction The European single market in health care is developing despite the existence of many different health care systems. Cross-border activities in health care are increasing. Many of these cross-border developments are related to e-Health [1]. E-Health describes the application of information and communication technologies across the whole range of functions that affect the health care sector1. E-Health gets a lot of attention at the EU level. This is not new and not so surprisingly. In the action plan for a European e-Health Area of 20042 health and health care formed a key part of the Commission’s vision of an information society in which a new generation of computerized clinical systems, advanced tele-medicine services, and health network applications improve health, continuity of care and allow citizens to be more involved in and assume more greater responsibility for their own health. The Commission believed that e-Health would be an instrument for restructured, citizencentred healthcare systems and, at the same time, respecting the diversity of Europe’s multi-cultural, multi-lingual healthcare traditions3. It is obvious that the Commission, because of the existence of e-Health, is enacting more and more rules that are related to health care and that these rules have an important impact on the health care systems. Through enacting these European rules on e-Health, the Commission is creating a legal framework for the health care systems. In this presentation 4 [2], we will describe some important European legal achievements related to e-Health (section II). In spite of the existing legal rules, there is still a lot of work to do challenges to promote E-Health on the European level (section III).

2. European legal achievements related to E-HEALTH This section highlights some European rules regarding e-Health that are of importance for health care systems. These European rules have an impact on national health care systems and are often not known by the health care actors. Both the Data Protection Directive, the E-Commerce Directive, the Medical device Directive as the Directive on Distance Contracting will be described shortly. The Directive on the protection of individuals with regard to the processing of personal data and on the free movement of such data 5 contains several important principles that have to be complied with by e-Health actors that process personal data concerning health. If national health care systems or other e-Health actors will create health grids, electronic national records, information systems that may be used for treatment purposes, quality review purposes, research purposes, etc. they have to 1

See also: European Commission, ‘Accelerating the Development of the eHealth Market in Europe’, eHealth Taskforce Report 2007, p. 10. 2 European Commission, Communication from the Commission. E-Health-making healthcare better for European citizens: An action plan for a European e-Health Area, COM (2004) 356 final; See also: http://ec.europa.eu/information_society/activities/health/policy/index_en.htm. 3 European Commission, Communication from the Commission. E-Health-making healthcare better for European citizens: An action plan for a European e-Health Area, COM (2004) 356 final. 4 This presentation is based on an article of S. Callens: “Analysis and evaluation of the EU legal framework on e-health”. 5 Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data, OJ 1995 L 281/31.


49

comply with the principles of the Data Protection Directive. Article 8 of the Directive prohibits the processing of personal data concerning health. However, this prohibition does not apply where the processing of health data6 is required e.g. for the purposes of preventive medicine, medical diagnosis, the provision of care or treatment or the management of health-care services, and where those data are processed by a health professional subject under national law or rules established by national competent bodies to the obligation of professional secrecy or by another person also subject to an equivalent obligation of secrecy. According to the Data Protection Directive personal data used in e-Health projects must be processed fairly and lawfully. Furthermore, data must be collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes. The data must be adequate, relevant and not excessive in relation to the purposes for which they are collected and the data must be kept in a form which permits identification of data subjects for no longer than is necessary and for the purposes for which the data was collected or for which they are further processed. The data subject has also to be informed about the processing of his personal data. Health care actors that are applying e-Health may be considered as information society services and may have to comply to the European Directive on certain legal aspects of information society services in the Internal Market (the so-called Electronic Commerce Directive)7 [3]. The E-Commerce Directive applies to information society services. Information society services are defined as any service normally provided for a remuneration, at a distance, by electronic means for the processing (including digital compression) and storage of data, and at the individual request of a recipient of a service8. The E-Commerce Directive may apply to online medicine as well as to services consisting of the transmission of information via a communication network, or in providing access to a communication network [4]. The Directive obliges the e-Health actors who act as an information society service to render easily, directly and permanently accessible to the recipients of the service and competent authorities, information on the service provider, where his activity is subject to an authorization scheme, the particulars of the relevant supervisory authority, any professional body or similar institution with which he is registered, which professional title he has obtained, which Member State has granted this title, which applicable professional rules in the Member State of establishment are applicable and what means exist to access them. According to the Directive, Member States must ensure that e-Health actors who act as information society services indicate any relevant codes of conduct to which he subscribes and information on how those codes can be consulted electronically.

6

ase C-101 Lindqvist [2003] ECR I-12971: The European Court of Justice stated in the Lindqvist case that the act of referring, on an internet page, to various persons and identifying them by name or by other means constitutes “the processing of personal data wholly or partly by automatic means" within the meaning of Article 3(1) of Directive 95/46. Such processing of personal data in the exercise of charitable or religious activity is not covered by any of the exceptions in paragraph 2 of that article. The fact mentioned on the internet that an individual has injured her foot and is on half-time on medical grounds constitutes personal data concerning health within the meaning of Article 8(1) of the Directive. 7 Directive 2000/31 on certain legal aspects of information society services, in particular electronic commerce, in the Internal Market (Directive on electronic commerce), OJ L 2000 178/1. For more guidance on the Directive see reference 3. 8 At a distance means that the service is provided without the parties being simultaneously being present.

50


The Medical Device Directive 9 harmonizes the rules pertaining to the free circulation of medical devices in the EU. This Medical Device Directive is of importance for the e-Health sector, especially with regard to e.g. the medical software that is used in many e-health applications10. In the Directive’s context, manufacturers are obliged to place on the market or to put into service only medical devices that do not compromise the safety and health of patients, users and other persons, when properly installed, maintained and used in accordance with their intended purpose. The manufacturer must design and manufacture medical devices in such a way that some essential requirements are met, such as to take into account the generally acknowledged state of the art and to eliminate or reduce risks as much as possible. Devices that are in accordance with the national provisions transposing the existing European harmonised standards will be presumed by EU member states as compliant with the essential requirements laid down by the Directive11. E-Health business may involve the conclusion of contracts. These contracts contain the description of the various parties’ obligations and, often, special clauses. A contract related to e-Health concluded between professionals and consumers may be the subject of a contract at a distance. The Directive on Distance Contracting12 will apply to any contract concerning goods or services concluded between a supplier and a consumer under an organized distance sales or service-provision scheme run by the supplier, who, for the purpose of the contract, makes exclusive use of one or more means of distance communication up to and including the moment at which the contract is concluded. In good time prior to the conclusion of any distance contract, the consumer shall be provided with sufficient information e.g. the identity of the supplier, the main characteristics of the services, the price of the services, the arrangements for payment, delivery or performance, the existence of a right of withdrawal etc. The consumer must receive written confirmation or confirmation in another durable medium available and accessible to him of the information mentioned above, in good time during the performance of the contract, unless the information has already been given to the consumer prior to conclusion of the contract in writing or on another durable medium available and accessible to him. For any distance contract the consumer shall have a period of at least seven working days in which to withdraw from the contract without penalty and without giving any reason.

9

Article 1 Directive 90/385 on the approximation of the laws of the Member States relating to active implantable medical devices, OJ 2007 L 247/21; Article 1 Directive 93/42 concerning medical devices as modified by Articles 1 and 2 of the Directive 2007/47 amending Council Directive 90/385 on the approximation of the laws of the Member States relating to active implantable medical devices, OJ 1993 L 169/1, Directive 93/42 concerning medical devices, OJ 1993 L 169/1 and Directive 98/8 concerning the placing of biocidal products on the market, OJ 1998 L 123/1. 10 The Medical Device Directive defines a medical device as any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, together with any accessories, including the software intended by its manufacturer to be used specially for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for among other things the purpose of diagnosis, prevention, monitoring, treatment or alleviation of disease, injury or handicap and the control of conception. 11 Article 5 Directive 93/42 concerning medical devices. 12 Directive 97/7 on the protection of consumers in respect of distance contracts, OJ 1997 L 144/19.


51

3. Legal challenges to promote E-HEALTH Many recent developments still need to be clarified at the EU-Level in order to make sure that e-Health will play an even more important role in health care systems than is the case today. The new e-Health applications such as electronic health records, ehealth platforms, health grids and the further use of genetic data and tissue involve new legal challenges. More and clear guidelines on the reimbursement criteria for telemedicine and on liability would also be very useful. 3.1. New challenges because of new e-Health applications 3.1.1. Electronic health records and e-health platforms Several Member States are shifting from using electronic health insurance cards to electronic health records or e-Health platforms in order to have13 an availability of health data for medical treatment and allied purposes. It is argued by public authorities that electronic health records or e-Health platforms may improve quality of care14 and patient safety and also can be used as an instrument to control the rising demand for (and cost of) health services 15 16 . They should facilitate appropriate treatment of patients by providing health professionals with a better knowledge of the patient’s history and of previous interventions by other colleagues 17 . According to the Commission improvement of patient safety can be achieved if information concerning patients is managed in a more systematic manner by everyone concerned with health care provision or standards18. Nevertheless, the use of electronic health records that contain data of several health actors poses new risks with some legal consequences. The Data Protection Commission at the European level, the so-called Article 29 Data Protection Working Party 19 , has adopted an interesting document on the 13 In Belgium, a draft proposal of law is proposed in April 2008 which will set an “e-Health platform”. The e-Health platform aims to optimize the quality and continuity of the healthcare, to optimize the safety of the patient, to promote the administrative simplification, and to support the health policy. This aim is to exchange information between all actors in the healthcare sector, organised with guarantees for the safety of the information and the privacy protection. The e-Health platform will, contrary to an electronic health record, be a decentralized way to store and exchange medical data. The E-Health platform does not contain the data itself, but is a place for healthcare actors where the data can be found. The patient will have to give his explicit written informed consent before his data will be added to the platform (Privacy Commission, advice nr. 14/2008 of 2 April 2008 “regards the draft law on e-health p. 10-11 en 25). 14 Secure and fast access to patient information will, however, require the interoperability of health records. 15 European Commission, Communication from the Commission. E-Health-making healthcare better for European citizens: An action plan for a European e-Health Area, COM (2004) 356 final, p. 5. 16 The lack of standards has pushed up the cost of development and customisation, which has held the eHealth industry back from more substantial investment in e-Health solutions (European Commission, Communication from the Commission. E-Health-making healthcare better for European citizens: An action plan for a European e-Health Area, COM (2004) 356 final, p. 13). 17 European Commission, Communication from the Commission. E-Health-making healthcare better for European citizens: An action plan for a European e-Health Area, COM (2004) 356 final, p. 8. 18 European Commission and Member States, EHealth Conference 2007 Declaration, 17 april 2007 (available at: http://ec.europa.eu/information_society/activities/health/docs/events/ehealth2007/eh_declaration20070417_e n.pdf). 19 See articles 29 and 30 Data protection Directive: Article 29 sets up a Working Party on the Protection of Individuals with regard to the Processing of Personal Data, hereinafter referred to as 'the Working Party'. The working Party advises and makes recommendations on all matters relating to the protection of persons with regard to the processing of personal data in the Community.

52


processing of personal data relating to health in electronic health records (EHR)20. The Working Party recommends to lay down special safeguards for the electronic health record system in a special comprehensive legal framework. This framework has to provide for, amongst others, the following safeguards: a patient should at any time have the possibility to prevent the disclosure of and the access to his/her personal data; only relevant information should be entered into an EHR and it might be useful to create different data modules within an EHR system with different access requirements; a special arbitration procedure should be set up for disputes about the correct use of data in EHR systems; a single special institution must be made responsible towards the data subject for the proper handling of access requests21. EHR systems and e-Health platforms introduce a new risk scenario. More categories of persons may get access to data if hospitals, pharmacies, labs, sickness funds etc. that are processing health data are becoming members of (international) groups. The Article 29 Working Party has stated that consent to process health data in EHR must be explicit. It is true that the Data Protection Directive does allow for the processing of health data without explicit consent. Article 8.3 of the Data Protection Directive for example allows for processing by a health professional subject to secrecy rules for the purposes of preventive medicine, medical diagnosis, the provision of care or treatment or the management of health care services. However, the Working Party is of the opinion that this Article 8.3 cannot serve as the sole legal basis for the processing of personal data in an EHR system. Too much persons can have access to health data (such as allied hospitals, the general practitioner etc.). Moreover, EHR’s can be used for several purposes. Therefore, we need a reflection on the impact of Article 8.3 of the Directive 22 and also on the legal rules regarding the processing of personal data concerning health for other purposes than treatment purposes such as research, quality review, etc. Several Member States formulated for the processing of medical data for research purposes strict rules whereas other Member States enacted more flexible rules. Article 8 of the Directive leaves too much room for different legislation in the Member States. This is not good for the establishment of on internal market in which international quality review projects, epidemiological studies, clinical trials and postmarketing surveillance projects are emerging. It is regretful that article 8 of the Directive does not contain more specific rules for the processing of medical data for research purposes. More specific rules at the European level are needed. 23 20 Article 29 Data Protection Working Party, ‘Working Document on the processing of personal data relating to health in electronic records (EHR)’, 00323/07/EN, WP 131; This document aims to provide guidance on the way to apply the data protection legal framework to electronic health record systems. 21 Article 29 Data Protection Working Party, ‘Working Document on the processing of personal data relating to health in electronic records (EHR)’, 00323/07/EN, WP 131, p. 13. 22 The first paragraph of article 8 of the Privacy Directive prohibits the processing of personal data. This paragraph shall not apply where processing of the data is required for the purposes of preventive medicine, medical diagnosis, the provision of care or treatment or the management of health-care services, and where those data are processed by a health professional subject under national law or rules established by national competent bodies to the obligation of professional secrecy or by another person also subject to an equivalent obligation of secrecy (article 8, 3 of the Privacy Directive). 23 Since EHR systems may contain many data for a long period of time, the new (European) legal framework should also foresee among other things the need for a comprehensive logging and documentation of all processing steps which have taken place within the system, combined with regular internal checks and follow-up on correct authorisation, regular internal and external data protection auditing (See also EUROPEAN COMMISSION, Draft Recommendation on eHealth interoperability, 16 July 2007, Annexe 1, p. 15). It will also be an important challenge for the legislator to guarantee that all groups in society (including lone parents, homeless persons, elderly and disabled persons, isolated communities etc.) have equal access to the electronic health record.


53

3.1.2. Health grids Since several years initiatives are taken to analyse the impact of health grids24 in health care systems. The grid was devised for use in scientific fields, such as particle physics and bioinformatics, in which large volumes of data, or very rapid processing, or both, are necessary. A grid has also been used in some ambitious medical and healthcare applications25. However, there is a tension between the spirit of the grid paradigm and the requirements of medical or healthcare applications. On the one hand the grid stores data at the most convenient way according to performance criteria. On the other hand, a hospital or other healthcare institution is required to maintain control of the confidential patient data and to remain accountable for its use at all times26. In order to be truly effective such grid applications must draw together huge amounts of data from disparately located computers – which implies data sharing across jurisdictions and the sharing of responsibilities by a range of different data controllers27 28. The SHARE report 29 shows the applicability of the European Data Protection Directive to health grids. Since not all Member States have transposed the Directive in the same way and since the Directive itself allows the Member States to adopt legislative measures to restrict the scope of some obligations and rights there are differences in the level of protection granted to personal data between EU Member States, which might be a problem for the implementation of the health grid technology on the whole territory of the European Union30. If health grids are really to grow to their full potential, robust guidelines developed specifically for the health grid context will have to be developed and adopted31. 3.1.3. Further use of genetic data and tissue E-Health will make sure that the difference between human tissue and computer data that refer to the human tissue becomes very small. E-Health will enhance the further use of human tissue and genetic data. The Human tissue and blood and the (genetic) data derived from tissue are increasingly being used and stored for treatment and other purposes such as research purposes [5]. Several European documents already refer to the use of human tissue such as the Directive 2004/23/EC on setting quality and safety standards for the donation, procurement, testing, processing, preservation, storage and distribution of human tissues and cells and the Regulation on Advanced Therapy

24 A grid is a new technology which aims to enhance the services already offered by the internet. It offers rapid computation, large scale data storage and flexible collaboration by harnessing together the power of a large number of commodity computers or clusters of other basic machines. 25 See www.healthgrid.org. 26 See www.healthgrid.org. 27 SHARE, ‘Bottlenecks and challenges and RTD responses for legal, ethical, social and economic aspects of healthgrids’, Roadmap I, 2008, p.19 (available at http://eu-share.org/deliverables.html). 28 SHARE is a European initiative defending the Grid concepts and the introduction of new technologies in the medical sector, involving e-health or e-infrastructures into medical research. Its main goal is intended to ensure the successful take-up of HealthGrid by creating a roadmap for essential technology development in the coming years (See www.healtgrid.org). 29 SHARE, ‘Bottlenecks and challenges and RTD responses for legal, ethical, social and economic aspects of healthgrids’, Roadmap I, 2008. 30 SHARE, ‘Bottlenecks and challenges and RTD responses for legal, ethical, social and economic aspects of healthgrids’, Roadmap I, 2008, p. 19. 31 31 SHARE, ‘Bottlenecks and challenges and RTD responses for legal, ethical, social and economic aspects of healthgrids’, Roadmap I, 2008, p. 25.

54


Medicinal Products32. However, these documents remain too vague to provide health care systems clear and detailed rules on the further use of genetic data and tissue. It will be a challenge for Europe to provide a more detailed legal framework with rules to the (further) processing of tissue and data which is becoming an international issue (and no longer a national one).

3.2. Towards more guidelines on the reimbursement criteria for tele-medicine The E-Commerce Directive does not regulate the reimbursement of tele-medicine services, which falls under the competence of the Member States. European and international tele-medicine projects have often failed because they were too expensive for the patients and reimbursement by their health insurance funds [6]was not possible33. An essential condition for reimbursement was never fulfilled in the domain of tele-medicine, i.e. the physical presence of the (tele)-physician with the patient at the moment of performing the medical action. This refusal to reimburse medical costs if there is no physical presence might have been reasonable in a period without ICT. Nowadays the question arises as to whether or not the criterion of physical presence for the reimbursement of treatment forms an obstacle to the free movement of services. The Member States can indeed, owing to a lack of harmonization at Community level, determine for themselves the conditions under which a person can or must subscribe to a social security regime and under which the right to benefit exists34 [7]. The Court of Justice has, however, regularly stressed that the Member States also have to comply with Community law in the implementation of a social security system. It is not just because mention is made to a rule of social security law that Articles 49 and 50 of the EC Treaty cannot be applied when judging a provision of social security law35. The legislation of European Member States which requires physical presence for reimbursement does not forbid a patient from having recourse to a tele-physician established in another Member State. It only makes the reimbursement thereof impossible. Alongside the justification mentioned in Article 46 EC Treaty (in particular the public health), the Member State may see it as an imperative reason of common interest by which an obstacle to the trade in services can be justified36 [8]. However, whether or not the reimbursement of medicine at a distance does in fact have an important effect on the financial balance of the social security system it still needs to 32 At the level of the Council of Europe, we would refer to the additional protocol on tissues of human origin to the Biomedicine Convention, as well as to Recommendation 2006/4 on research on biological materials of human origin. Rules regarding the use of human tissue and blood do differ often between the Member States. 33 The Standing Committee of European Doctors is pleading for a reimbursement of tele-medical services by the national social security system in the same way as any other form of medical service (Standing Committee of European Doctors, The Practice of tele-medicine in Europe: analysis, problems and CPME recommendations, (2002M/027), p. 18). 34 The Court of Justice has, however, regularly stressed that the Member States also have to comply with Community law in the implementation of a social security system: see e.g. Case C-120/95 Decker [1998] ECR I-1831, para 23; Case C-158/96 Kohll [1998] ECR I-1931, para 19; Case C-157/99 Smits-Peerbooms [2001] ECR I-5473. 35 In the Kohll case the Court of Justice has stressed that the requirement for preliminary consent of the insured person’s health insurance fund, before the patient can claim (ambulatory) medical costs in another Member State, is a barrier to the free delivery of services (Case C-158/96 Kohll [1998] ECR I-1931, para. 35). 36 Case C-158/96 Kohll [1998] ECR I-1931, para. 41; S. CALLENS, ‘International Tele-medicine and the Law’, in Books of proceedings I of the 13th World Congress on Medical Law (Helsinki, 2000).


55

be examined. It seems to us that the reimbursement of certain types of tele-medical interventions will have to be accepted. If the safety of the patient is guaranteed and if the tele-medical treatment is cost neutral, it is to be expected that exceptions to the physical presence requirement will have to be allowed under Community law. It is obvious that guidance (at the European level) can be given as to the criteria that (tele-) health sessions will have to comply with for reimbursement purposes. 3.3. Towards a European legal framework on liability and tele-medicine One of the important questions in cases of liability and tele-medicine will be whether or not the tele-medical transaction is the most suitable approach to treat the patients. Physicians must always consider whether or not tele-medicine poses an increased risk for the patient, for instance, in an emergency situation where a delay of the necessary medical intervention would pose a greater risk for the patient than a prompt intervention with telehealth. It can well be expected that more and other type of persons than in a classic medicinal treatment will undoubtedly be held liable, if during the telemedicinal session something goes wrong. The technical failure of some devices used during a tele-medicinal session can lead to liability claims against software producers or Internet providers. In the case of a defective medical device, the European Directive on product liability 37 has to be considered. This Directive establishes the general principle that the producer is liable for damages caused by a defect in his product38 39 [9]. The EU should play an important role even with regards to the liability issue if the e-Health actors are submitted to different liability schemes. Some countries like France and Belgium recently enacted so called no-fault legislation related to health care [11]. The no-fault issue is already known in the EU Directive on products liability [10] but is increasingly expanded to other domains like the delivery of health care40. However, many countries do not use the no-fault issue with regard to the treatment of a patient by a health care professional. It is not good for patients or health care professionals if this right is regulated all over Europe in a different way. This will not promote the use of tele-medicine and access to health care. Therefore, EU legislation should enforce Member States to provide similar rules for compensation which would enhance the free movement of patients and of health care services and at the end the access to health care and e-Health.

37 Directive 85/374 of 25 July 1985 on the approximation of the laws, regulations and administrative provisions of the Member States concerning liability for defective products, OJ 1985 L 210/29. 38 A product is defective when it does not provide the safety which a person is entitled to expect, taking all circumstances into account, including the presentation of the product, the use to which it could reasonably be expected that the product would be put and the time when the product was put into circulation. 39 Tele-medicine might, however, make it sometimes easier to know who made a mistake since teleoperations may be taped and be kept together with the file. This could facilitate answering the question of what went wrong during the session (see reference 9). 40 On this moment there exist no European rules concerning the no fault liability for all types of health care. The Member States apply their own liability rules. This results in different liability rules in the different Member States. At the European level the no fault liability has only be introduced for certain specific issues related to health care.

56


4. Conclusion Many health care players (like sickness funds, hospitals, labs) are being part of a European network of health care actors and may feel the need to communicate between Member States health data for treatment and other purposes. Through enacting European rules on aspects of e-Health, the Commission created a legal framework for the health care systems. Some Directives, like the Data Protection Directive and the ECommerce Directive play an important role for health care systems, through the use of e-Health applications. However, the existing legal framework is not finished. The current European rules remain often too vague. It is obvious that the issues which health care players may deal with, have to be addressed at the European level. Some important legal issues as well as technological developments need a clear legal answer.

References [1]

S. BOILLAT and S. CALLENS, ‘The sale of medicinal products by mail-order in Europe’, in Yearbook of European Medical Law (Sweden: Lidingo, 2005), pp. 57-62. [2] S. Callens: “Analysis and evaluation of the EU legal framework on e-health” in T. Hervey en R. Baeten (eds.), Health systems governance in Europe: the role of EU law and policy, (in print). [3] S. Callens, ‘Tele-medicine and E-Commerce Directive’, European Journal of Health Law (2002), 9:93109. [4] P. Van Eecke, ‘Electronic Health Care Services and the E-Commerce Directive’, p. 375. [5] J.A. BOVENBERG, Property Rights in Blood, Genes and Data. Naturally Yours? (Leiden: Martinus Nijhoff Publishers), p. 23. [6] S. CALLENS, ‘Tele-medicine and European Law’, Telehealth Law 2 n°. 3 (2002), 34-40. [7] H.D.C. ROSCAM ABBING, ‘Public health insurance and freedom of movement within the European Union’, European Journal of Health Law (1999), 1. [8] S. CALLENS, ‘International Tele-medicine and the Law’, in Books of proceedings I of the 13th World Congress on Medical Law (Helsinki, 2000). [9] B. Sluyters, ‘Telegeneeskunde’, T.v. Gez. R. (1999), 273. [10] C. VAN SOOSELAERE, P. WILSON, J. HERVEG and D. SILBER, “eHealth…. But is it legal?”, Eurohealth 13 n° 2 (2007), 2. [11] S. CALLENS en L. MARTENS, “Naar een foutloze aansprakelijkheidsregeling in de gezondheidszorg (?)” in Recht in beweging. 15de VRG-Alumi-dag 2008, Antwerpen, Maklu, 2008, 473-490.


57

eHealth services and Directive on Electronic Commerce 2000/31/EC a

Jean-Marc VAN GYSEGHEMa,b, 1 Senior researcher Research Centre on IT and Law (University of Namur, Belgium) b Attorney at Law at the Bar of Brussels (Belgium)

Abstract. We often restrict the analysis of eHealth services to a concept of privacy. In this article, we'll demonstrate that other legislation can apply to those services as Directive 2000/31/EC on Ecommerce. By creating telematic networks or infrastructure, eHealth services are offering information services. But what are the consequences with such concept? What are the duties and rights for the actors of the network(s)? We'll try to answer to some questions, even if it won't be exhaustive. Keywords. Health Services, Public Health Informatics, Legal Liability, Consumer Health Information

1. Introduction The medical practice is changing quickly and in this context, practitioners use new technologies to improve its efficiency. The use of these technologies raises new legal issues which are often misunderstood. That misunderstanding scares practitioners and patients as well. The main technology used by hospitals is the Internet when relying on Internetbased networks to allow the sharing of data (medical, administrative, etc.) between several actors active in the Health sector. We are in the eHealth generation! But, what is an eHealth service? Jean HERVEG and Yves POULLET explained that "eHealth is characterized by the use of information and communication Technologies in Healthcare"[1]. They add to their saying that "eHealth projects aim to create telematic networks or infrastructure at local, regional, national, European, international, or even worldwide level"[1]. The words "networks" and "infrastructure" involve the sharing of information as said before but involve also the concept of availability for a certain public. We also have to point that these eHealth services offer an added value to the data to the profit of the physicians by giving them a new perspective of use (short medical file for urgent action, hyperlinks, etc…), of the patient, of the researcher, etc… The question which comes in mind is the following: in which extent can the sharing of data and the public access be qualified as a service of the information society in the meaning of Directive 2000/31/EC on Ecommerce [2]? 1 Special thanks to Jean HERVEG, Lecturer at the Faculty of Law (University of Namur) and senior researcher at the Research Centre on IT and Law (University of Namur) who has kindly red the text over.

58

J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC

In this paper and due to a question of length, we'll analyze only some aspects of the Directive 2000/31/EC related to the concept of eHealth services. Therefore, we'll put some other points aside such as the internal market and free movement principles, the concept of sanction and the status of Education in relation to the Directive on eCommerce.

2. Directive 2000/31/EC on Ecommerce By contrast to the usual approach of the eHealth service – focusing on the patient and the practitioner from a data protection point of view -, we propose to analyse the legal qualification of the network and the infrastructure. 2.1. Scope of the Directive The Directive 2000/31/EC covers all information society services which include services between companies (B2B - business to business), between companies themselves and consumers (B2C - business to consumers) and free services delivered to recipients. It covers on-line services like databases, selling of medicines (ePharmacy) [3]. The aim of the Directive is to guaranty the transparency on the net [4]. The scope of the Directive is quite wide and concerns all information society services even in sector which has a high level of protection as public health, etc… The Directive sets a minimum of requirements to be fulfilled in order to achieve its objective by eliminating disparities within the European Union 2 . That means that national laws transposing the Directive cannot be less strict. The article 1(5) of Directive 2000/31/EC sets up some exceptions to its application which are not relevant here from our point of view in this contribution. Attention must be paid to the fact that this Directive doesn't deal with personal data - as mentioned in the Recital 14. Therefore this Directive 2000/31/EC is a regulation which juxtaposes with Directive 95/46/EC [5]and they may coexist as it often occurs in Privacy matters. 2.2. The information society service The concept of information society services is "any service, normally provided for remuneration, at a distance, by electronic means and at the individual request of a recipient of services"3. The keywords are: • The service must be provided for remuneration. It doesn't matter if the service is paid by the recipient himself or not. That means that the payment can come from another source (like advertising, etc.) than the recipient. We have to consider that all activities are included in the concept of services (article 50 of the European treaty – version 97/C 340/03), except the ones

2

Recitals 6 and 10 of the Directive 2000/31/CE. Article 1(2) of Directive 98/48/EC of the European Parliament and the Council of 20.07.1998 amending Directive 98/34/EC laying down a procedure for the provision of information in the field of technical standards and regulations. 3


•

•

59

offered by the State without economic consideration in accordance with its social, cultural, etc. duties before they are opened to payment4. Reading Article 50 of the European Treaty, we can set that all activities, except the ones realized by the Member State and related to its missions (i.e.: culture, justice, etc…), are likely to be "services" in the sense of Article 50 of the Treaty. What about eHealth? We have to keep in mind it costs a lot to set up an eHealth services and has to be financed from a way or another. Therefore, it will need a financial support. In theory and in an economical point of view, services can be paid by the users of the service, advertisements, public funding, etc…. It’s a question of choice and the source doesn't matter because the concept of remuneration is very broad. We therefore have to conclude that eHealth services will, most of the time, be remunerated for in the sense of Article 50 of the European treaty, from a way or another. The service must be provided at distance which means that the parties are not physically and simultaneously present5. That includes online databases or advices which does not request the presence of the patient. A contrario, "medical examinations or treatment at a doctor's surgery using electronic equipment where the patient is physically present"6 won't be a service of the information society [3]. What about eHealth? Obviously, the different parties dealing within an eHealth environment will never (or exceptionally) be physically or simultaneously present. Therefore, eHealth fulfils, most of the time, this criteria. The service has to be made by electronic means which means that "the service is sent initially and received at its destination by means of electronic equipment for the processing (including digital compression) ad storage of data, and entirely transmitted, conveyed and received by wire, by radio, by optical means or by other electromagnetic means"7. In the concept of electronic means, the recital 18 includes only the online services and not the offline one. In the hypothesis of both services, the Directive will apply to, and only, the online one. Are also excluded services which are not provided by electronic or inventory system as telefax services, voice telephony services, the supply consisting in material goods even if it implies the use of electronic means (for example: train ticket, money, etc…). What about eHealth? The entire eHealth environment is based on the Internet and/sometimes on the Grid technology, which means that the service is usually provided by electronic means. All the transmissions of data (which

4 See Recital 19 of the Directive 98/48/EC of 20.07.1998 amending Directive 98/34/EC laying down a procedure for the provision of information in the field of technical standards and regulations. In this recital, we should understand article 50 instead of article 60 (European Treaty – version 97/C 340/03). 5 See also Annex V to the Directive 98/48/EC of 20 July 1998 amending Directive 98/34/EC laying down a procedure for the provision of information in the field of technical standards and regulations. 6 Annex V to the Directive 98/48/EC of 20 July 1998 amending Directive 98/34/EC laying down a procedure for the provision of information in the field of technical standards and regulations. 7 Article 1(2) of Directive 98/48/EC of the European Parliament and the Council of 20.07.1998 amending Directive 98/34/EC laying down a procedure for the provision of information in the field of technical standards and regulations.

60


•

are in a numeric form) will obviously be realized through the Internet. Therefore, eHealth fulfils this criterion in this extent. The service must be provided at the individual request of a recipient of services which means that the service is provided through the transmission of data on individual request. That excludes all services provided without individual request as television and radio. What about eHealth? First of all, we have to define the notion of “recipient of services” in an eHealth environment. Actually, depending on the service, we may consider several recipients like the physicians, the patients, the researchers, etc. seeking information. Obviously, their request will take place in the offer of a service in response to their individual request when asking for a medical document, medical information, data for scientific research, etc. The individual request can occur at the beginning of the relation between the user and eHealth services. It means that the transmission of data to a user does not have to follow, at each time, a special request. The contract between eHealth service and the user can provide, for example, that the information will be sent as soon as there is an update, for instance.

We see that eHealth services fulfil, most of the time, the different criteria of information society services. The consequence is that most of the eHealth services falls within the scope of the Directive and must respect the obligations in matter of information and other duties concerning the conclusion of contracts by electronic means8 and regarding commercial communications. A way to get out of the scope of this Directive would consist in providing an offline service excluding de facto all on-line services (see above), which obviously does not fit with the concept of the eHealth environment. Concerning regulated profession as well as health on line, on line medicine in the surrounding of commercial communications, the Members States have to ensure that the use of such commercial communication "is permitted subject to compliance with the professional rules regarding, in particular, the independence, dignity and honour of the profession, professional secrecy and fairness towards clients and other members of the profession"9. 2.3. Provider of a service of the information society Directive defines the service provider as "any natural or legal person providing an information society service"10. The definition is very broad since it includes all persons dealing with commercial activity 11 . The duties towards the recipient are mainly informational. At the level of eHealth, we have to consider it's a provider of a service of the information society as soon as it's a "natural or legal person providing an information society service". We have seen above that eHealth includes information society services. Hence we have to precise this quality by saying it's a provider. 8

Article 9 and following of the Directive 2000/31/EC. Article 8.1 of the Directive 2000/31/EC. 10 Article 2(b) of the Directive. 11 By commercial activity, we have to understand service for payment in the sense of the article 50 of the European treaty and the interpretation given by the European court of justice (Cfr. above). 9


61

What about eHealth? The question is to know who can qualify as a provider of information society services in the eHealth environment. The "natural or legal person providing an information society service" could be the physician and/or the patient and/or the researcher and/or lab, etc. When could it be the case? We have to determine very carefully who really provides the service. Is this the physician or the patients? We can already set that could be hardly feasible for them in terms of administration and so on. Obviously, physicians, patients and researchers transfer information (data) to each of them through or with the collaboration of eHealth services which give the infrastructure (see above). The physician makes available some patient's data to other physicians, patients, researchers, etc. through the eHealth network/service and vice versa. Therefore, there's a kind of services given by each one. We have to check again the key words defining information society service which are service provided by remuneration, at a distance, by electronic means and at the individual request of a recipient of services. The main discussion is about the remuneration once we consider that the other elements are met. We remind that by remuneration, we have to understand any kind of retribution. For sure, the physician gets retribution from the patient and, in some situation, from Member States. The question is to determine what kind of remuneration is got by the physicians. Is it for therapeutic purpose to the patient or to give the service of furnishing the information through the eHealth services? Giving an answer to this question is to resolve the question to know if he can be considered as provider or not. Actually, the physicians is paid, most of the time, to cure the patients and, in most of the European legislations, he is legally obliged to get information from other physicians and from the patient itself as he has to give information to other physicians and the patient. In a wider dimension, it can be useful for the patient to have his data sent to researchers. The physician does not get any specific remuneration, directly or not, for this specific service which is included in its therapeutic duties towards the patient12[6]. Therefore, the physician cannot be considered as a service provider because the criterion of remuneration is missing. On the other hand, it would be different if he creates a website or will send, getting specific remuneration, data to other persons. The same question is put forward for the researcher. Actually, he often gets remuneration from Member States, EU, etc. Following the example of the physician, we can consider this remuneration is given for the research and not for the availability of some results for physician and patient consisting in giving the results of the research to this last one which is part of its work of researcher. From our point of view, the remuneration cannot be considered in relation to the service. What about the patient? It would be outrageous to consider that the patient takes remuneration to transfer information to his physician or to a researcher. Even the Directive 2001/20/CE of the European Parliament and of the Council of 4 April 2001 on the approximation of the laws, regulations and administrative provisions of the Member States relating to the implementation of good clinical practice in the conduct of clinical trials on medicinal products for human use prohibits incentives or financial inducements except for compensation. That shows how it is impossible to consider the patient getting remuneration when sharing data in the matter of therapeutic services as an eHealth service. 12 For opposite position, see Patrick Van Eecke, "Electronic Health Care Services and the E-Commerce Directive", A Deacade of Research @ the Crossroads of Law and ICT, Brussels, Larcier, 2001, p. 375.

62


At this point, we may consider that actors using eHealth services do not get most of the time, any remuneration for making available data through the eHealth infrastructure. Their remuneration is related to the therapeutic finality for the physician and a finality of research for the researcher and a finality of healthy life for the patient. Therefore, they can not be considered under scope of the Directive 2000/31/EC. 2.3.1. General information Article 5 specifies the kind of general information accessible by an easy, direct and permanent way in any case and in any service of the information society. If the provider practices a regulated profession, he has to deliver some more information as described in the article 5, f.13. Besides the general information, the Directive makes provisions for several more precise services as commercial communications and contracts concluded by electronic means. What about eHealth? In its quality of provider, eHealth services have to respect this duty of information as any other provider. In some cases, eHealth services can use commercial communication as a way to finance the service offered. In that hypothesis, it has to take care of the special informational duties. What about contracts concluded by electronic means? We have to start from the hypothesis that there will be contract between eHealth services and the actors using such services concerning duties and right of the different parties. Those contracts needed in a data protection framework designed for each eHealth service will, certainly, be concluded by electronic means and, often, between non consumer parties except with the patient. 14 That means, in practice, that the information given to the non consumer user can be reduced to ashes in the sense of the Directive 2000/31/EC if there's an agreement between the parties. Within the eHealth environment, this possible substantial reduction of information will facilitate the work... Pay attention to the fact that this information is not required if the contract is concluded exclusively by exchange of electronic mail or by equivalent individual communications. The interpretation of this paragraph must be restrictive and concerns the process of the contract which is made entirely by Email or equivalent individual communication. For practical reasons, the contracts within the eHealth services should be – if not yet – electronic. 2.4. Recipient of the service The Directive defines the recipient of the service as "any natural or legal person who, for professional ends or otherwise, uses an information society service, in particular for the purposes of seeking information or making it accessible"15. The Directive wants to limit the concept of information society service to open networks, excluding “private” networks accessible only to the members of the legal entity16. 13

Article 5, f of the Directive 2000/31/EC. Consumer is defined like "any natural person who is acting for purposes which are outside his or her trade, business or profession" (article 2(e) of the Directive. 15 Article 2(d) of the Directive. 16 See recital 20 of Directive 2000/31/EC. 14


63

What about eHealth? In the architecture and the purpose of any eHealth service, there will be several recipients acting at the same time or not or through the same eHealth service or not. Those recipients may be the physicians, the patients, the researcher, the labs, etc. and outside a one only and same legal person. 2.5. Intermediary service providers The Directive has created a special category of provider which is called "intermediary service provider". No definition of this kind of provider is given by the Directive but each of the three kinds of such intermediary service provider is defined differently on the field of the liability. The objective of this Directive 2000/31/EC in this particular matter is to reduce the liability of this actor working in the information society which will have to fit in a category to get the benefit from this reduction of liability17. The exemptions from liability set in this Directive cover only cases where the activity of the information society service provider is limited to the technical process of operating and giving access to a communication network over which information made available by third parties is transmitted or temporarily stored, for the sole purpose of making the transmission more efficient; this activity is of a mere technical, automatic and passive nature, which implies that the information society service provider has neither knowledge of nor control over the information which is transmitted or stored18. The conditions to benefit from this exception of liability depend on the kind of intermediary services offered: • Mere conduct: A total absence of liability is set when an information society service is provided that consists of the transmission in a communication network of information provided by a recipient of the service, or the provision of access to a communication network, if the provider does not initiate the transmission, does not select the receiver of the transmission and does not select or modify the information contains in the transmission19. That includes the automatic, intermediate and transient storage of the information transmitted in so far as this takes place for the sole purpose of carrying out the transmission in the communication network, and provided that the information is not stored for any period longer than is reasonably necessary for the transmission20. • Caching: Where an information society service is provided that consists of the transmission in a communication network of information provided by a recipient of the service, there is no liability for the automatic, intermediate and temporary storage of that information, performed for the sole purpose of making more efficient the information's onward transmission to other recipients of the service upon their request 21 . But to benefit from that

17 On the question of liability of the intermediary service provider, see Tribunal de grande instance de Paris, 3ème chambre, 1ère section, 15 avril 2008, www.juriscom.net/documents/tgiparis20080415-Lafesse.pdf; Tribunal de grande instance de Paris, 3ème chambre, 1ère section, 15 avril 2008, www.droittechnologie.org/upload/jurisprudence/doc/254-1.pdf; 18 Recital 42 of Directive 2000/31/EC 19 Article 12,3 of Directive 2000/31/EC. 20 Article 12,2 of Directive 2000/31/EC. 21 Article 13.1 of Directive 2000/31/EC.

64


•

exemption of liability, the provider has to prevent himself to modify the information, and to comply with conditions on access to the information, etc.22 Hosting: Where an information society service is provided that consists of the storage of information provided by a recipient of the service, there is no liability for the information stored at the request of a recipient of the service, on condition that the provider does not have actual knowledge of illegal activity or information and, as regards claims for damages, is not aware of facts or circumstances from which the illegal activity or information is apparent; or , upon obtaining such knowledge or awareness, acts expeditiously to remove or to disable access to the information23. There is no exemption of liability when the recipient of the service is acting under the authority or the control of the provider24.

The limitations of liability of intermediary service providers set in this Directive do not affect the possibility of injunctions of different kinds. Such injunctions can in particular consist of orders by courts or administrative authorities requiring the termination or prevention of any infringement, including the removal of illegal information or the disabling of access to it25. In order to benefit from a limitation of liability, the provider of an information society service, consisting of the storage of information, upon obtaining actual knowledge or awareness of illegal activities has to act expeditiously to remove or to disable access to the information concerned26. The removal or disabling of access has to be undertaken in the observance of the principle of freedom of expression and of procedures established for this purpose at national level. This Directive does not affect Member States' possibility of establishing specific requirements that must be fulfilled expeditiously prior to the removal or disabling of information27. The Directive encourages the non imposition of a general obligation on providers, when providing the services mere conduit, caching and hosting, to monitor the information that they transmit or store, nor a general obligation actively to seek facts or circumstances indicating illegal activity. Meanwhile, it promotes an obligation for information society service providers promptly to inform the competent public authorities of alleged illegal activities undertaken or information provided by recipients of their service or obligations to communicate to the competent authorities, at their request, information enabling the identification of recipients of their service with whom they have storage agreements28. What about eHealth? Can we consider any eHealth service as an intermediary service provider and benefit from the reduction of liability set by the Directive (see above). Will it only store the information from the providers to give the opportunity to the recipient to get it? The eHealth services make a kind of processing of the data coming from outside. For example, they change the structure of the information, they create a list containing 22

Article 13,1 of Directive 2000/31/EC. Article 14,1 of Directive 2000/31/EC. 24 Article 14,2 of Directive 2000/31/EC. 25 Recital 45 of Directive 2000/31/EC. 26 See Tribunal de grande instance de Toulouse, référé, 13 mars 2008, www.legalis.net/jurisprudenceimprimer.php3?id_article=2246; Tribunal de commerce de Paris, 8ème chambre, 20 février 2008, www.legalis.net/jurisprudence-decision.php3?id_article=2223. 27 Recital 46 of Directive 2000/31/EC. 28 Article 15, 2 of Directive 2000/31/EC. 23


65

hyperlinks to the information stored in another place as in a hospital, they create a short medical file for urgent action, etc. The qualification of the eHealth service towards Directive 2000/31/EC will be very factual and it's quite difficult to give an answer within this contribution. However, we can point even if the eHealth services won't change the content of a medical report they will process the data itself by organizing it (for example: hyperlinks29 [7]) and extracting information (for example: short medical file for urgent action) in an objective of valorisation of the data. It's often one of the purposes of the service offered to the users. The eHealth service can also be intermediary service provider for a part of its activity and "full" service provider for another part of it [7]. In consequences, we have to consider that eHealth service can be both an intermediary service provider and a service provider. It depends on its real activity. About the question of the liability of the eHealth services as service of information society provider, we'll have to return to the national regulations because the Directive 2000/31/EC doesn't deal with that issue. Obviously, this question will have to be analysed in another contribution. 2.6. Codes of conduct The Directive also encourages 30 the drawing up of codes of conduct at Community level, by trade, professional and consumer associations or organisations, designed to contribute to the proper implementation of Articles 5 to 15 and the accessibility of these codes of conduct in the Community languages by electronic means.; In the eHealth context, it would be an appropriate initiative to adopt a code of conduct at the European level to secure the users/actors.

3. Conclusion In terms of conclusion, we certainly have to consider that any eHealth service will be considered as a service of the information society in the sense of Directive 2000/31/EC on Ecommerce and will have to respect the rules set by it. The Directive is not a danger for the eHealth services and even can offer a security to the provider at the level of liability if he can be considered as an intermediary service provider. Concerning this last issue, we'll always have to analyze the real activity to work out either it's a "full" provider or an intermediary one. If it's a "full" provider, its liability will be regulated by common national law unlike for a intermediary provider. As seen before, the difference between those two concepts is not only a question of words! Apart from that, the duties for the provider is mainly informational with some variation depending on whether he's "full" provider or an intermediary one, whether he's in charge of contract by electronic means and if the contract are made between non consumers or not, etc.

29 See Tribunal de grande instance de Paris, référé, 26 mars www.foruminternet.org/specialistes/veille-juridique/jurisprudence/IMG/pdf/tgi-par20080326.pdf. 30 Article 16 of Directive 2000/31/EC.

2008,

66


Honestly and at this point of the study which is in progress, we don't see any way out to the Directive 2000/31, except if we offer an offline service, what would be a nonsense confronting to the whole concept of the eHealth services. To close this contribution, we point out the fact that eHealth service do not play alone! Indeed, in this environment, several actors work together with a willing of respect of their own duties coming from other legislation. As whispered before, the developer of any eHealth service must also pay attention to other laws or legislations as 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.

References [1]

[2]

[3] [4]

[5]

[6] [7]

Herveg Jean and Poullet Yves, "Wich Major Legal Concerns in Future e-Health", in The Information Society : Innovation, Legitimacy, Ethics and Democracy in Honor of Professor Jacques Berleur s.j., Boston, Springer, 2007, p. 159-160. Directive 2000/31 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 (Directive on electronic commerce), http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32000L0031:EN:HTML. van Doosselaere Céline, Herveg Jean, Siber Denise and Wilson Petra, Legally eHealth. Putting eHealth in its European Legal Context, Legal and regulatory aspects of eHealth, study report March 2008, p. 21. Dumoulin Marie, "Information et transparence sur les réseaux", in le commerce électronique européen sur les rails? Analyse et proposition de mise en œuvre de la directive sur le commerce électronique, Bruxelles, Bruylant, 2001, p. 95. Directice 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, http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML. Van Eecke Patrick, "Electronic Health Care Services and the E-Commerce Directive", A Deacade of Research @ the Crossroads of Law and ICT, Brussels, Larcier, 2001. Montero Etienne, "La Responsabilité des prestataires de service sur les réseaux", le Commerce électronique européen sur les rails, Cahier du Crid, 2001, p. 276


67

A Data Protection Framework for Transeuropean genetic research projects Brecht CLAERHOUT a,1, Nikolaus FORGÓ b,2, Tina KRÜGEL b, Marian ARNING b Georges DE MOOR a a

b

Custodix, Belgium Institute for legal Informatics, Leibniz University of Hanover, Germany

Abstract. The paper proposes a data protection framework for trans-European medical research projects, which is based on a technical security infrastructure as well as on organizational measures and contractual obligations. It mainly relies on pseudonymization, an internal Data Protection Authority and on a Trusted Third Party. The outcome is an environment that combines both good research conditions and an extensive protection of patients´ privacy. Keywords. Data protection, pseudonymization, anonymization, genetic research

1. Introduction This paper is motivated by the EU research project ACGT (Advancing ClinicoGenomic Trials on Cancer 3 ), which aims at the development of a trans-European cancer/gene grid network to promote better and more efficient curability. Within ACGT the authors are responsible for the technical security structure on the one hand and legal, especially data protection, issues on the other hand. Trans-European genetic research projects such as ACGT are of great value for the fight against diseases such as cancer. At the same time it is of high importance to safeguard patients´ rights, in particular their right of privacy concerning medical data. The tension between human-genetic research and the legal aspects of data protection is obvious: A person’s genetic data provides a massive amount of information such as the person’s descent, ethnical origin, information on possible future medical conditions (with a certain probability), and much more. Each individual’s genetic data is unique and can be of importance even for unborn blood relatives. This makes genetic data highly sensitive and its processing has to be carried out under strict regulations, combining all technical, organizational and liability based measures.

1 Brecht Claerhout, Custodix NV, Verlorenbroodstraat 120 bus 14, 9820 Merelbeke, Belgium; [email protected]. 2 Prof. Dr. Nikolaus Forgó, Institute for legal Informatics, Leibniz Univerity of Hanover, Königsworther Platz 1, 30167 Hanover, Germany; [email protected]. 3 http://www.eu-acgt.org/.

68

B. Claerhout et al. / A Data Protection Framework for Transeuropean Genetic Research Projects

2. Data protection issues in trans-European genetic research projects According to Art. 8 para 1 of Directive 95/46/EC the processing of genetic data is in general prohibited, as it has to be qualified as personal data. Personal data shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number […]. The most relevant exemption to the prohibition of data processing is the data subject’s consent. However, the wording of the consent causes several problems when it comes to research in genetic data: It must be considered that to consent in advance to each data processing is almost impossible as normally, in the course of a project, new research methods are developed which may demand other operations to be performed upon the data than those the patient has consented to. But a vague consent, that covers all these unclarities, may not be seen as valid. If, in contrast, the wording of the consent is very specific, new research methods are not covered and even after years the patients would have to give new consents. The expenditure in organization and the practical problems which arise (is the patient still able to give consent?) are obvious. In the end medical progress would be jeopardized. Therefore it would be best if the researcher used non-personal data for the research, because anonymized data are out of the scope of the Directive 95/46/EC. The Directive is applicable in cases of the processing of personal data only. If data is rendered anonymous, the data subject requires no further protection, because re-identification is impossible due to the lack of reference to the said person. Therefore the processing of anonymous data offers the best protection for the said person. Consequently, when genetic data has to be processed, it must be considered carefully, whether it is possible to process it anonymously. But the question arising is whether genetic data can be rendered anonymous at all or in contrast always has to be qualified as personal data because of its uniqueness. The crucial point is how to define the term “anonymous”. The Directive itself does not contain any explicit definition of this term. Only Recital (26) of the Directive contains an explanation: “(26) […] whereas the principles of protection shall not apply to data rendered anonymous in such a way that the data subject is no longer identifiable […].” According to this wording, data can only be classified as anonymous if reidentification of the data subject is impossible for everybody. But the unique quality of genetic data causes the problem that despite comprehensive anonymization the reidentification of the said person still is possible if relevant additional knowledge such as genetic information exists in another database. In this case the identification of the data subject would always be possible by a matching procedure. Therefore a complete anonymization of genetic data is impossible [1]. Apart from that, as far as medical research is concerned, anonymized data is often not helpful anyway. In order to be able to follow the course of a patient’s disease and to observe the patient’s reaction to the treatment, the patient must be identifiable. At the same time researchers often replace the data subject’s name etc. with a label, in order to preclude identification of the data subject or to render such identification substantially difficult. The person can only be re-identified by using the appropriate key. The data is “pseudonymized”. The question arising here is whether such pseudonymous data still has to be considered to relate to an “identifiable” person or if this data could be seen as (de facto) anonymous data for the researcher not having the appropriate key. According to a recent opinion of the Article 29 Data Protection Working Party in the fields of


69

clinical research medical data could be seen as anonymous data if a) in the specific framework the re-identification is explicitly excluded and b) appropriate technical measures have been taken in this respect [2]. In those cases such key coded data are not subject to the rules of data protection legislation.

3. Data protection framework With respect to these legal requirements the following data protection framework was designed for ACGT: 3.1. Data Protection Authority From a practical point of view in research projects compliance often is a crucial issue. Hence to guarantee compliance of the project with data protection legislation it is in a first step essential to put the project consortium in the position to audit such compliance. Otherwise all investment in project policies, technical infrastructure or organizational measures is not worth the effort. Therefore it is appropriate to establish an authority that is both legally able to enter into binding contracts with the project participants and empowered to inflict a penalty for infringement. To be able to conclude contracts, this Data Protection Authority has to be a legal body, empowered by the project consortium, but independent in its decisions. Once this authority is established, policies integrated in binding contracts can be set up, which implement and/or legally confirm measures such as the following: 3.2. Pseudonymization As shown above pseudonymous genetic data in the context of clinical research may not be subject to the rules of data protection legislation, if appropriate policies as well as organizational and technical measures are set up. To ensure that the processing of genetic data within ACGT is de facto anonymous a legal/technical framework is set up that builds on a state of the art pseudonymization and the integration of a Trusted Third Party. The primary legal conditions of this framework are: • All technical and organizational measures as well as obligations, such as the irrevocable prohibition of matching procedure in order to re-identify a patient, are codified in binding contracts signed by all participants of the project. • All data transmitted to and processed within the project must be pseudonymized before entering the network by a unique state of the art pseudonymization. • To monitor and audit compliance with data protection policies as well as to give patients one central contact for any questions or complaints concerning the processing of their data, it has to be guaranteed that the internal Data Protection Authority is the central data controller within the project, whereas all users of the network process data only on behalf of this controller. • To build up a network with only one central data controller makes a strict organizational and technical separation necessary between data stored and analyzed in the hospitals for medical treatment and the data stored and analyzed on behalf of the research project. Separate databases, adequate

70


•

access control and contractual obligations have to be implemented to ensure this separation. Re-identification where it is needed for therapy reasons only must solely be possible involving the Trusted Third Party that provides the software tool for the pseudonymization and holds the cryptographic authorizing the reidentification.

3.3. First fall back scenario: informed consents Nevertheless the data protection framework in projects like ACGT should be structured like a safety net, as for all genetic data that can NOT be qualified as “de facto anonymous” a different solution is needed. If the researcher can establish the link between data and data subject there is need for a legal permission, as in those cases the genetic data is personal data in the sense of the Directive 95/46/EC, and the Directive therefore is applicable. Thus, in a second step, the data processing is legitimated in the traditional way: by informed consents of the patients. To obtain informed consents in every case has several advantages: First of all, it involves the patient in the whole procedure. This leads to transparency, generates trust and is required for ethical reasons anyway. At the same time it gives legal certainty in those cases where researchers can establish the link between data and patient, even though they might not even know they can. Hence the data protection safety net builds on the de facto anonymization of genetic data as a basic principle, with a legitimation via informed consents as a fallback scenario. It therefore combines both, the protection of the patients’ privacy and the legal certainty for the researchers involved. 3.4. Second fallback scenario: Exceptions for genetic research in national legislation For the unlikely event that for a specific patient both the de facto anonymization fails and the informed consent does not exist, does not cover the specific use or is invalid, as a second fallback scenario the particular national legislation has to be analyzed with regard to an exemption according to Art. 8 para. 4 Dir. 95/46/EC. Member States may, for reasons of substantial public interest, lay down further exemptions from the general prohibition on processing sensitive data, e.g. scientific research, see Recital (34). The problem with this exemption is that Member States are free to implement it. Whether the Member State whose law is applicable for the data processing operation in question, has introduced such an exemption in its national law, has to be analyzed individually. However, this analysis ought to be made by the Data Protection Authority for each individual case as those national provisions differ and can change at any time.

4. Technical implementation of the data protection framework The ACGT Service Oriented Architecture (SOA) has a layered structure. The lower layers of the platform that provide basic functionality such as resource allocation, job management, etc. are based on the Globus Toolkit [3] and GRIDGE [4]. On top of those, the ACGT Business Processes Services reside providing a “biomedical grid layer” to ACGT [5] (i.e. semantic mediation, a master ontology service, knowledge


71

discovery tools, etc.). Common security functionality such as secure communication, user authentication, virtual organization (VO) management, etc. are based upon the functionality provided by these layers (e.g. the Gridge Authorization Service GAS responsible for VO management). However, such standard components fall short of offering a means to meet the demands for treating sensitive biomedical data explained in the previous sections. The two major implications of the data protection framework on the ACGT platform are the data de-identification and pseudonymization requirement and the need for controlling the context in which data is used (so that this data can be treated as de facto anonymous for the data controller). 4.1. De-identification and Pseudonymisation Toolkit In order to meet the de-identification demands laid out in the legal analysis, a tool [6] was created for exporting pseudonymous data from the (internal) hospital data stores to their anonymous ACGT counterparts (i.e. the ACGT accessible data sources, also physically residing in the hospitals). The tool is innovative in a sense that it offers a generic solution regardless of the type of data to be treated or of de-identification requirements. It consists of a “workbench” and a “wizard”. The “workbench” serves at defining the mechanics (data protection profile) through which data is exported for sharing, the “wizard” allows to easily apply those profiles on various data sources. The workbench allows domain experts and privacy professionals to: • create a mapping from a specific data format such as flat files (e.g. CSV), imaging data (e.g. DICOM), microarray data, structured data (e.g. XML, databases) to a generic data model • define the set of actions that should be performed on the generic data model in order to de-identify data (i.e. the data protection profile) Once that a data mapping and a data protection profile is created in the “workbench”, end users (i.e. physicians) can easily export several data sources at once by using the wizard (logically, this operation can also be automated). Privacy processing actions such as creating a pseudonym (randomly assigned, through encryption of immutable identifiers, etc.), freetext de-identification, basic encryption, calculation of relative dates (to obfuscate absolute birthdates), etc. are defined towards the internal generic data model. The big advantage of this approach is that a single privacy protection profile can be applied to various data sources. It also provides a base for extending the tool with privacy risk analysis functionality and more complex information content reductions algorithms (e.g. local suppression and generalization routines). The privacy transformations are provided as a library (also usable by developers through an API), hence the functionality of the tool can be easily extended to suit new requirements (e.g. a new freetext de-identification routine or a new input data format). 4.2. Protecting the Context of Anonymity Sensitive data processed within ACGT can only be treated as “de facto” anonymous if the context in which it is used can be controlled by the internal Data Protection Authority (data controller): i.e. sensitive data should only be accessed by people and organizations legally bound to the ACGT policies. ACGT relies on the (legally bound)

72


service and data providers on the platform to enforce this “contextual anonymity”. In this task they are (technically) supported by a separate central authorization service managed by the Data Protection Authority, which specifically deals with data protection policy decisions. Decisions made by this separate authorization service are only based on data protection aspects of the access request (i.e. the request could still be denied based upon evaluation of other security rules regardless of the data protection decision). These decisions are made though interpretation (rules engine) of data protection policies based on the existing legal contracts and data protection metadata associated with the datasets that need protection. This system of privacy related metadata relies on the “ACGT data wrappers” which are part of the basic ACGT framework and allow to associate generic metadata to data handled on the ACGT infrastructure. Note that this approach is quite similar to the concept of “sticky policies”. This system of central data protection policy management allows the ACGT data providers and services to comply effortlessly with the rules laid down in the data protection framework, and relieves the ACGT Data Protection Authority liability in case that one of the data providers intently violates data protection legislation. In addition to policy management, this system provides a form of information flow management and audit trail for the ACGT Data Controller.

5. Conclusion This paper proposes a data protection framework for trans-European genetic research projects. It recommends a graded safety net and the establishment of an internal Data Protection Authority as well as the involvement of a Trusted Third Party. The ultimate ambition is to process only de facto anonymous genetic data. To gain de facto anonymous genetic data, we propose a pseudonymization which can only be revoked in cooperation with a Trusted Third Party. The Data Protection Authority is the central data controller that monitors and audits paticipants´compliance with the project’s data protection policies. This has to be obtained by binding contracts which empower the Data Protecting Authority to inflict a penalty for infringement. If achieved, the proposed framework is on the one hand in line with European regulations and on the other hand easily manageable for researchers.

References [1] [2] [3] [4]

[5]

[6]

T. Weichert, Der Schutz genetischer Informationen, in: DuD 2002, p. 133 (134). Article 29 Data Protection Working Party, Opinion 4/2007 on the concept of personal data, p. 20. I. Foster, Globus Toolkit Version 4: Software for Service-Oriented Systems, IFIP International Conference on Network and Parallel Computing, Springer-Verlag LNCS 3779, pp. 2-13, 2006. J. Pukacki, M. Kosiedowski, M. Kupczyk, M. Wolski, M. Adamski, P. Grabowski, M. Jankowski, C. Mazurek, N. Meyer, R. Mikolajczak, J. Nabrzyski, T. Piontek, M. Russell, M. Stroiński, M. Wolski, Programming Grid Applications with Gridge, Computational Methods in Science and Technology, 12(1), 47-68 (2006). M. Tsiknakis, M. Brochhausen, J. Nabrzyski, J. Pucacki, S. Sfakianakis, G. Potamias, C. Desmedt, D. Kafetzopoulos, A Semantic Grid Infrastructure Enabling Integrated Access and Analysis of Multilevel Biomedical Data in Support of Post-Genomic Clinical Trials on Cancer, Digital Object Identifier: 10.1109/TITB.2007.903519 (to appear), http://ieeexplore.ieee.org/xpl/tocpreprint.jsp?isnumber= 26793&punumber=4233. CAT – Custodix Anonymisation Tool. Retreived August 17, 2008 from http://cat.custodix.com/.

3. Electronic Patient Records



75

From a paper-based to an electronic registry in physiotherapy a

Ronald BUYLa1, Marc NYSSENa Department of Biostatistics and Medical Informatics, Faculty of Medicine, Vrije Universiteit Brussel, Belgium

Abstract. During the past decade the healthcare industry has evolved from paperbased storage of clinical data into the digital era. Electronic healthcare records play a crucial role to meet the growing need for integrated data-storage and data communication. In this context a new law was issued in Belgium on December 7th, 2005, which requires physiotherapists (but also nurses and speech therapists) to keep an electronic version of the registry. This (electronic) registry contains all physiotherapeutic acts, starting from January 1, 2007. Up until that day, a paper version of the registry had to be created every month. This article describes the development of an electronic version of the registry that not only meets all legal constraints, but also enables to verify the traceability and inalterability of the generated documents, by means of SHA-256 codes. One of the major concerns of the process was that the rationale behind the electronic registry would conform well to the common practice of the physiotherapist. Therefore we opted for a periodic recording of a standardized “image” of the controllable data, in the patient database of the software-system, into the XML registry messages. The proposed XSLT schema can also form a basis for the development of tools that can be used by the controlling authorities. Hopefully the electronic registry for physiotherapists will be a first step towards the future development of a fully integrated electronic physiotherapy record. By means of a certification procedure for the software systems, we succeeded in developing a user friendly system that enables end-users that use a quality labeled software package, to automatically produce all the legally necessary documents concerning the registry. Moreover, we hope that this development will be an incentive for non-users to start working in an electronic way. Keywords. Electronic Health record (EHR), Physiotherapy, Registry, XML

1. Introduction In recent years we notice an increased pressure to improve management of clinical information. Healthcare providers are encouraged to store their data in digital formats [1,2]. Keeping electronic patient data is not only the task of general practitioners, specialists or hospitals anymore. As physiotherapists grew more autonomous and claimed their own place within the healthcare domain, they were also expected to keep track of the treatments in a more structured way. A Royal Decree issued on 03-10-1999 enforces the use of the physiotherapy record in Belgium. Although electronic record

1 Corresponding Author: Ronald Buyl, Departement of Biostatistics and Medical Informatics, Faculty of Medicine, Vrije Universiteit Brussel, Laarbeeklaan 103, B-1090 Jette (Brussels); E-mail:[email protected]

76

R. Buyl and M. Nyssen / From a Paper-Based to an Electronic Registry in Physiotherapy

keeping is often considered as a burden, well organized data will help physiotherapists to make sound clinical decisions, based on relevant and accurate data at the right time. Many studies [3, 4, 5] have shown that keeping structured electronic data has important benefits, and most of the authors agree that the electronic medical record will be instrumental in helping to improve the quality of the healthcare system. The most important benefit of introducing an electronic physiotherapy record system is the increased accuracy and improved reporting [6]. This not only has a positive effect on the final outcome for the patient, but also decreases the probability of mistakes, thanks to build-in decision support systems, which will help with therapy planning. Another important advantage is the improved efficiency, resulting in time saving. Electronic physiotherapy record systems enhance the possibility to input data (30% time profit [7]), process the data, but especially help one to retrieve data from the system in a fast and straightforward manner. Also exchangeability and improved communication with other healthcare providers are considered as fundamental advantages. Besides these advantages, Vreeman et al. [6] report some barriers that slow down the development of electronic physiotherapy record systems. As stated earlier the attitude of the physiotherapist plays a key role in this process. Many physiotherapists are still not convinced about the advantages of electronic record keeping. Figures from the national board of physiotherapy show that, at this moment, 18355 physiotherapists are active in Belgium. From these only 30-50% [8, 9] are storing their data electronically. Similar data can be found in other European countries. Only by convincing the end-users there will be a bright future ahead for the electronic physiotherapy record. This article describes the first step that was taken in Belgium to store clinical physiotherapy data in an electronic way: the electronic physiotherapy registry. This electronic version of the physiotherapy register, that replaces the old paper one, includes elements that can later be used in the realization of a fully integrated electronic physiotherapy record. Although it is part of the general structure of the dataexchange between the involved healthcare parties, the electronic physiotherapy registry does not include data-communication with other electronic record systems as can be seen in figure 1.

2. Materials and methods 2.1. Structure of the electronic registry According to a new law issued on December 7th, 2005, physiotherapists (but also nurses and speech therapists) are required to keep an electronic version of the registry, which lists all physiotherapeutic acts performed after January 1st, 2007. Up until that day, a paper version of the registry had to be created every month. This hand written (or printed out) paper version had to be provided in a bound and page numbered official register. Registration comprised all the acts carried out by the physiotherapist, sorted by date. The registry was the official document that could be controlled by the medical inspection at all times.


77

Figure 1: Dataflow scheme

The content of the current electronic version of the physiotherapy registry does not differ very much from the paper-based format. Following items were considered sufficient to verify the process of the acts of a physiotherapist (for every act performed): • Date of the act • Name of the patient • Nomenclature number of the act We opted for an XML-message to structure the registry. XML has already proven its strength as an electronic language for the communication of medical data [10, 11, 12]. Furthermore Kmehr-Bis2, an XML messaging scheme is used very effectively as a national standard in Belgium for the exchange of medical documents, such as discharge letters, lab results and medical prescriptions. Our main concern for creating an electronic version of the physiotherapy registry was that it would conform well to the daily practice of the physiotherapist, without creating extra workload for the end user. On the other hand, two important issues had to be solved: inalterability and traceability of the data. Inalterability was obtained by creating a sha-256 hash code3 as a secure fingerprint of the produced messaged. This sha-256 code is stored as a separate variable within the database of the record system. Traceability was solved by incorporating the sha-256 code of the previously generated document in every new created message (see figure 2). This procedure makes it possible to trace not only justifiable modifications from the past 12 weeks, but also enables one to detect fraud within the registry.

2

Kmehr-BIS: Kind Messages for Electronic Health Records, Belgian Implementation Standard: http://www.chu-charleroi.be/kmehr/htm/kmehr.htm [13] The SHA hash functions are five cryptographic hash functions designed by the National Security Agency (NSA) and published by the NIST as a U.S. Federal Information Processing Standard. SHA stands for Secure Hash Algorithm. Hash algorithms compute a fixed-length digital representation (known as a message digest) of an input data sequence (the message) of any length. 3

78


Figure 2. Use of SHA-codes in registry messages

2.2. Implementation mechanism The implementation of the electronic physiotherapy registry was the main criterion of the second certification procedure for software systems in physiotherapy, which was held at the end of 2006 [11, 12]. This certification procedure was already successfully applied to software systems for general practitioners. Because physiotherapists are given an incentive for using a quality labeled software package, it is the hope of the Ministry of Health that this will encourage the end-users who still record on paper, to start using electronic physiotherapy record systems. For this labeling session the following test criteria were used: • Registry messages must be generated weekly on an automatic basis, but can be generated manually whenever suitable • Registry messages must be stored separately for each individual physiotherapist using the software package • The variable that contains the SHA-256 code of the current generated registry message, is stored for each physiotherapist and a timestamp is added • Starting from the registry messages, the software package must be able to generate a list (show on the screen and print) containing all acts of a specific date sorted by patient name or all acts for all patients sorted by date for any given time period. The software packages were evaluated on the basis of (amongst others) these criteria by making use of a test scenario that consisted of a number of fictitious patients that had to be entered into a “clean” software system. 2.3. Control mechanism Currently the messages are stored locally within the software system, but in the future an exportation to a central repository is possible (see figure 1, purple arrow). A specific XSLT scheme4 has been developed, to verify and format the registry messages.

4 XSLT is designed for use as part of XSL, which is a stylesheet language for XML. More information on: http://www.w3.org/TR/xslt


79

Figure 3. Example of output of XSLT control schema.

To evaluate the implementation and certification process of the electronic register, a survey was held amongst the software producers. More than 70% of the software producers (13/18) responded, representing approximately 80% of the physiotherapist that use a certified software package. The results of this survey can be found in table 1. The general comments on the implementation and certification process were positive, although some producers stated that the period for implementation (2 months) was too short. Table 1. Results of the software producers survey Register (n=13) The electronic register is an improvement for physiotherapists The electronic register helps physiotherapists to meet all legal constraints The electronic register is user-friendly Implementation procedure (n=13) I am satisfied with the implementation / certification procedure The test scenarios were useful for the implementation of the register The proposed method was easy to implement The proposed method was well documented

% agreement 81.8% 63.6% 72.8% 63.6% 81.8% 63.6% 63.6%

3. Discussion We developed a system that, in a fairly easy way, made the transition from a paper based to an electronic registry for physiotherapists possible. The final result is a clearly outlined method for generating an electronic registry that meets all the legal constraints, as well as controls the traceability and the inalterability of the produced documents. The system was fairly easy to embed into the existing software systems for physiotherapists and its implementation was accepted very well by the software

80


producers. Hopefully the results of this work can contribute to the future development of a fully integrated electronic physiotherapy record. We paid special attention to the user-friendliness of the system, making sure that physiotherapist using any of the eighteen certified software packages will not have to worry about producing their monthly registry, since this is generated automatically. This initiative can also be an incentive for the non-users to start using a certified software package. Further research however is needed to investigate the acceptance of the system by the end-users, namely the physiotherapists in the field. At this moment the controlling authorities are able to check the integrity of the generated registry messages, possibly together with the history of the SHA-variable. Besides the fact that the software systems are able to present a list of all acts per date as well as a list of the acts for one patient for a certain period, with standard XML tools. A history of all legitimate adaptations within a certain period can also be produced. The methodology was thoroughly checked in a test environment and during the homologation sessions. The next step is to perform an in-the-field analysis of the produced messages and compare the results with the data found in the physiotherapist’s records. The provided XSLT scheme together with the freely available source-code of the SHA-256 hashing procedure form a basis allowing the controlling authorities to create additional programs, to automate the verification process by tracking the chain of consecutive SHA-256 codes in each of the produced messages.

References [1]

Pekka Ruotsalainenan, Bryan Manning: A notary archive model for secure preservation and distribution of electrically signed patient documents, International journal of medical informatics 76 ( 2007 ), 449– 453 [2] Marcel Lucas Müller, Frank Ückert, Thomas Bürkle, Hans-Ulrich Prokosch: Cross-institutional data exchange using clinical document architecture (CDA), International journal of medical informatics 74 (2005), 245-256 [3] Laing K. The benefits and challenges of the computerized electronic medical record. Gastroenterol Nurs, 2002, 25, 41-45. [Medline] [4] Markle Foundation. Connecting For Health. Achieving Electronic Connectivity in Healthcare: A Preliminary Roadmap From the Nation’s Public and Private-Sector Healthcare Leaders. New York, Markle Foundation. Accessed: 2008-04-01 at (Archived by WebCite® at [http://www.webcitation.org/5WkarIVX1) [5] Verdonck, P. et al. Het elektronisch medisch dossier, Huisarts Nu, 2004, 33 (2) Available in Duch [6] Vreeman D.J, Taggard S.L, Rhine M.D, Worrell T.W. Evidence for electronic health record systems in physical therapy. Phys Ther, 2006, 86 (3), 434-446. [Medline] [7] Shields R.K, et al. An acute care physical therapy clinical database for outcomes research. Phys Ther, 1994, 74, 463-470. [Medline] [8] Research data from National board for physiotherapy (in Dutch): Onderzoeksgegevens uit een studie van de Nationale Raad voor de Kinesitherapie (2004), personal communication on 05.02.06 [9] Belgian Senate debate (in Dutch): Belgische Senaat, Wetsvoorstel tot opheffing van artikel 76 van de wet betreffende de verplichte verzekeringvoorgeneeskundigeverzorging en uitkeringen, gecoördineerd op 14 juli 1994, zitting 29 juni 2005 [10] Buyl R, De Smedt A, Nyssen M. Evidence based testing of electronic medical record systems for general practitioners, Family Medicine and Primary Care Review, 2006, 8 (2) [11] Buyl R, De Smedt A, Nyssen M. Quality labelling of Electronic Medical and Paramedical Record Systems: A Current Status, J. Qual. Life Res, 2005, 3 (3), 78-81


81

[12] Buyl R, Nyssen M. Eindrapport Kinelectrics. FOD Volksgezondheid,veiligheid van de voedselketen en leefmilieu. Accessed 2008-04-01 at (Archived by WebCite® at http://www.webcitation.org/5Wka3PvVG) (available in Duch and in French) [13] Kind Messages for Electronic Healthcare Records Belgian Implementation Standard http://www.health.fgov.be/telematics/kmehr/

82


Certification of Electronic Health Record systems and the Importance of the Validation of Clinical Archetypes a

Georges DE MOOR a, Dipak KALRA b, Jos DEVLIES c Dept. of Medical Informatics and Statistics, Ghent University, Ghent b CHIME, University College, London c The EuroRec Institute, Ghent

Abstract. If Electronic Health Record (EHR) systems are to provide an effective contribution to healthcare across Europe, a set of benchmarks need to be set to ensure the quality of such systems. This article describes the results of the EU funded QRec- project and emphasizes the need for validation of clinical archetypes to support the semantic interoperability between EHR systems and other interacting eHealth applications. Keywords: Electronic Health Record, Quality, Certification, Clinical Archetypes

1. Introduction ICT has the potential to make a significant contribution to the better management of healthcare provision. This cannot be achieved without the availability of trustworthy Electronic Health Record systems (EHRs) that provide all necessary clinical information requirements thus enabling the sharing of timely and up-to-date patients’ medical data to support “high quality care” and “continuity of care”. Interoperability and security to protect the privacy of persons and the confidentiality of patients’ data are also prime requirements for such EHRs. The EuroRec Institute is a not for profit organization (http://www.eurorec.org) promoting the development and use of high quality EHR systems. One of its main missions is to support the development of EHR systems quality labeling and certification. EuroRec is organized as a permanent network of National ProRec centers in Europe and is liaising at international level with other bodies such as CEN/BT and CEN/TC251, ISO/TC215, WHO, openEHR, HIMSS, CCHIT and Canada Info Highways. The EuroRec Institute provides services to the following types of stakeholders: industry (the developers and vendors), healthcare providers, (the buyers), health care authorities and policy makers, and patients.

G. De Moor et al. / Certiﬁcation of Electronic Health Record Systems

83

2. The Rationale for the QRec-Project and for Quality Labeling and EHR systems’ Certification in General Investment in healthcare ICT has been comparatively low compared with other sectors. High investment risk for purchasers and low definition of European market requirements for suppliers has contributed to this. This is particularly the case for largescale investment for electronic health record systems at regional or national levels. Given the increasing complexity of EHR systems requirements and the risk of system deficiencies or failure to meet expectations, there is a need for an assessment process to assure the quality (cf. safety and privacy issues) of EHRs on the market and to ensure their interoperability with other systems. Without an agreed set of functional criteria to underpin the introduction of robust and sustainable EHRs, major ICT investments are potentially at risk. Given a set of quality criteria around which suppliers and their healthcare customers can collaborate openly, the introduction of effective EHR solutions across European member state boundaries becomes a reality. Several EU member states have already proceeded with EHR systems quality labeling and/or certification, but these attempts differ in scope, in legal framework under which they operate, in policies (legal and financial incentives), in organization and perhaps most importantly in the quality criteria used for benchmarking. Harmonization therefore appears to be a must. EuroRec’s “QRec” Specific Support Action (IST-27370-SSA, 2006-2008) has therefore addressed both the certification criteria and the certification procedures. EuroRec and partners have developed formal methods and created the mechanisms for the quality labeling and certification of EHR systems hereby focusing in a first stage on primary and acute hospital-care settings [1]. The longer term strategy is to encompass in a later stage also other eHealth software products and services (in particular decision support systems and other modules that interact with EHR systems) [2;3].

3. The QRec Deliverables The QRec project ended June 2008 and has delivered: • A first series of validated, fully indexed and translated (in 12 languages) quality criteria and functional requirements (+ 1500) for EHR systems; • A typology of indexes : business functions ((50 in 8 subcategories), care settings (18 in 3 subcategories) and component types (18 in 4 subcategories); • A quality assurance approach of EHR archetypes (i.e. formal sharable models of clinical domain concepts; cf. openEHR/EN 13606 archetypes, see further) for enabling the semantic interoperability in e-Health; • A repository of European and International coding systems in use for EHRs, as well as an inventory of EHRs related international standards; • Test scenarios and proposed certification mechanisms enabling both selfcertification (e.g. by the industry itself) and external certification (e.g. by health care authorities or other recognized bodies);

84


A series of tools (the EuroRec Composer, Certifier, Documenter, Procurer and Scripter) for profiling EHRs for national certification processes, for product documentation or for procurement purposes (see figure 1).

Figure 1: The EuroRec Use Tools

The different use tools can be described as follows: The Q-REC Composer™ enables the licensee to select the required criteria (the EuroRec Fine Grained Statements), to create a “QRec basket” to be used in a certification session, in product documentation or in a procurement document. The Q-REC Certifier™ enables the licensee to structure the selected Fine Grained Statements (of a Q-REC Basket) by completing them with aspects of importance within the given certification context (e.g. criteria to be considered as mandatory versus optional). The Q-REC Scripter™ enables the licensee to write scenarios for a given certification or procurement. Each of the scenarios is linked with the Fine Grained Statements of relevance. The Q-REC Documenter™ enables the licensee to select and structure Fine Grained Statements of (a Q-REC Basket) in a way that they can integrated in product documentation (and hereby using more standardised descriptive statements). The Q-REC Procurer™ enables the licensee to structure the selected Fine Grained Statements (of a Q-REC Basket) by completing them with aspects of importance within the given procurement context and with other information enabling the correct interpretation of the procurement.


85

4. Semantic Interoperability and Clinical Archetypes Considering the importance of semantic interoperability in eHealth, one of EuroRec’s further activities will be to play a role in the validation of clinical archetypes. The following part therefore introduces and illustrates clinical archetypes. Clinical archetypes are a formal, rigorous and standardised (interoperable) specification for an agreed consensus or best practice representation of clinical data structures (within an electronic health record) [4]. They provide a standardised way of specifying EHR clinical data hierarchies and the kinds of data values that may be stored within each kind of entry. An archetype defines (or constrains) relationships between data values within an EHR data structure, expressed as algorithms, formulae or rules. An archetype may logically include other archetypes, and may be a specialization of another archetype. In order for it to be managed and used appropriately, its metadata needs to define its core concept, purpose and use, evidence basis, authorship, versioning and maintenance information. Figure 2 shows an example of the content of an archetype. This illustrates a hierarchical data structure representing the components of the documentation of an adverse reaction, usually to medication. Each line represents a data item that may be entered within a patient’s EHR to document one allergy. The main data items are the therapeutic agent (e.g. penicillin) and its category (e.g. penicillins). Additional details are provided using the subsequent items, such as the details of the reaction and how certain the observer is that the reaction has indeed been caused by the drug. For each node in the archetype hierarchy the icon adjacent to the name indicates the data type of the patient-specific value: textual, coded, date or time, quantity etc. When authoring an archetype, additional details need to be provided about each node such as the number of occurrences that are permitted within instances of EHR data, the terminology values that may be used, numeric ranges and measurement units. This archetype therefore defines the “shape” within an EHR for representing adverse reactions, and thereby offers some predictability to any application or system component that needs to query EHR data to obtain adverse reaction information.

Figure 2: Schematic diagram of an archetype for adverse reaction (to medication)

86


The requirement for clinical teams to share patient record information to support longitudinal continuing care and to follow multi-professional care pathways is well recognised [5;6]. Delivering shared regional or national Electronic Health Records is now central to every e-Health programme. It is also recognised that the support of shared care through records that are only human readable is not sufficient: patient safety management and the pursuit of evidence based care require computable information that can be linked to and queried by alerting components, decision support and clinical pathway systems [7-11]. The efficient management of health services and the support of public health and clinical research through audits and population analyses also require EHRs that can semantically be processed. All these purposes of use ideally require that the clinical findings within EHRs are represented and organised consistently across vendor products and communities of use: semantic interoperability [12]. Two methods to support semantic interoperability for electronic health records are available today: messages and archetypes/templates.

Messages An older way to support semantic interoperability is the use of messages. It is a characteristic of messages (EDIFACT, DICOM, HL7v2, HL7v3) that in one message specification (message standard) several viewpoints are defined rather than just one: • Enterprise viewpoint will contain the use case, i.e. the standardised work process; • Information viewpoint contains the Message Information Model; • Computational viewpoint is about the choreography of messages in the interaction schemas; • Engineering viewpoint is the level where the XML schema is defined. In any message specification changes can occur at any or all layers. Work processes change, new data elements need to be stored or exchanged, new interfaces are needed, etc. Even the smallest change will lead to a new version of the message. Since the implementation of messages in all EHR-systems in a uniform way (e.g. via the IHE process) is time and money consuming, it is clear that messages do not facilitate innovation because the flexibility and adaptability of this technology is poor, which has historically defended the case for an architectural approach to representing the electronic health record [13-16].

Archetypes/Templates based on ISO EN13606 and openEHR In healthcare, archetypes and templates express the requirements from the Enterprise viewpoint level as constraints on the Reference Model. The Reference Model of the EN13606/openEHR is not the same as the Reference Information Model of HL7 and is a very generic model of any health record or document [17]. The resulting collection of defined archetypes and templates constitute the Information Viewpoint.


87

The European standard EN13606 defines how archetypes and templates are produced in a standardised way. Therefore the European EHR-standard is operative on the Information Viewpoint level only. openEHR has extended the European EHRstandard to the Computational Viewpoint so that EN13606 conformant EHR-systems become possible (other standards will govern the other ODP layers). Archetypes and templates can play a key role in semantic interoperability [18]. Archetypes define what is maximally documented in the world about a specific health record entity. Templates define what in a specific context at a specific point in time, will be stored, retrieved, presented, exchanged and archived. In part, clinical meaning within an EHR will be expressed through the structure of the archetype/template, and in part the meaning will be expressed through codes from coding systems. A way to view this metaphorically is: • codes are the words in a dictionary; • the structure of the archetype/template is the grammar; • with both codes and archetypes sentences can be formed that make or do not make sense; • but archetypes define what makes sense; • and templates define what makes sense in a specific context. In the case of EN13606/openEHR archetypes provide a lot of flexibility and adaptability. Using archetypes, healthcare providers can define and re-define at any moment templates that are needed in their work process at that point in time. Systems based on archetypes and templates support easy customization and localization, and rapid evolution to meet new clinical requirements [19]. Clinical archetypes are thus a knowledge representation that defines the way in which an EHR Reference Model is to be applied to represent particular clinical entities (i.e. particular kinds of finding, assessment, hypothesis, plan or intervention). An archetype defines a data structure, including optionality and multiplicity, data value constraints, and relevant bindings to natural language and terminology systems. Figure 3 shows an example of an archetype for adverse reaction to medication, authored using an archetype editor developed by the University of Linköping in Sweden (this editor is available as open source software from openEHR) (http://www.openehr.org). This figure shows, in the main central panel, a hierarchical data structure that represents the components of the documentation of an adverse reaction, for example the type of reaction and its severity. The drug to which this reaction arises is represented within a cluster called “Administration information” (not expanded in this screen shot). For each node in the hierarchy the icon used indicates the data type of the patient-specific value: textual, coded, date or time, quantity etc. The right hand panes show (upper pane) the number of occurrences that are permitted within instances of EHR data and, for coded entries (lower pane), the terminology values that may be used. Other panes (not shown) permit other constraints to be applied such as numeric ranges and measurement units.

88


Figure 3: Example screen showing the main portion of an archetype for adverse reaction (to medication)

5. Validation of Clinical Archetypes To support semantic interoperability clinical archetypes need to be shared and used consistently by EHR system vendors and their users, so that the EHR data they create is consistently organised [20]. Archetypes therefore need to be shared and managed as a common knowledge asset, and incorporated into the design of clinical applications, rather like a terminology system. Many of the formalisms and tools needed for archetypes to be a global resource are now in place. One notable challenge in designing libraries of archetypes to meet broad areas of clinical practice, for example to cover the complete clinical information needs of a speciality or professional discipline, is to ensure that archetypes are evidence based or meet de facto agreed clinical needs (e.g. established by consensus, or reflecting existing practice). Given that many archetypes may be needed to cover a given domain, it is also important for them to be mutually consistent and bind to terminology systems in appropriate and consistent ways. This is necessary in order to minimise the diversity of ways in which a given kind of EHR data might be represented. The authors therefore believe that clinical archetypes need to be quality assured, since they will direct the ways in which clinical data are captured, processed and communicated. It is important that the design of individual archetypes is an accurate and faithful reflection of good practice for the clinical disciplines in which each of them might be used. They need to be optimally designed for their purpose, and


89

considered trustworthy within their intended communities of use. This requires not only sound methodologies for designing each archetype in accordance with, for example, published clinical guidelines or peer consensus, but rigorous and robust processes for validating any given archetype against its clinical evidence base and in the context of other archetypes alongside which it might be used. Pan-European (or international) applicability will be an increasingly-important requirement for good quality archetypes. If record-sharing communities are to construct safe EHR instances in accordance with archetypes, and to trust EHR data conforming to archetypes, a formal process of verification and certification is needed for archetypes that provide assurance of their suitability and safety. The EuroRec Institute is partnering the openEHR Foundation in developing governance practices for archetype development, and the quality criteria and editorial policies by which certified libraries of archetypes can be recognised. As part of the quality labelling and certification of EHR-systems, it may take joint responsibility for the governance of archetypes and templates alongside the openEHR Foundation, since these artefacts play an extremely important role in semantic interoperability in Europe. EuroRec is starting discussions with bodies like the Commission, CEN/TC251, ISO/TC215 and openEHR in order to create a framework where all can become responsible for a defined aspect in their natural roles.

6. EuroRec’s Future Plans The EuroRec Institute has expressed its ambition to become a European Agency responsible for the Certification of EHR systems and for semantic interoperability for related eHealth applications. It therefore will continue to invest in the future: • by maintaining and enriching its central repository of validated certification criteria; • in the study of the quality criteria related to the secondary use of EHRs as potential e-sources for e.g. e-Clinical Trials and other e-Research; • by investigating the certification of EHRs in other care settings (e.g. ehomecare and personal health records); • in the validation of clinical archetypes. As the barriers between the different types of Electronic Health Record systems and other eHealth related applications are fading away, EuroRec also intends to broaden its future scope of work to the quality labeling of other types of eHealth systems, including e.g. Decision Support Systems: good clinical care needs the combination of health records and medical knowledge [21;22].

7. Conclusions The time has arrived to go one step further and to pilot and implement in Europe (including in the Eastern European Member States) the EHRs quality labeling and certification process – in compliance – with the ‘good practice requirements’ elaborated by EuroRec. A number of Member States (already certifying at their own national level) are also demanding to join in a more European wide effort. All this

90


could start through piloting and implementing the EuroRec solutions (e.g. through the objective 6.2 of the CIP programme in FP7). There is also widespread and world-wide recognition that a formalised and scalable means of defining and sharing clinical data structures is needed to achieve the value of investment in e-Health. Clinical archetypes are gaining acceptance as the best of breed and best supported approach for defining these structures, reflected in its international standardization [4;23]. Large and comprehensive sets of archetypes are needed that cover whole clinical domains in a systematic and inclusive way, catering for the inevitable diversity of use cases and users but helping to foster consensus and best practice. For these to be endorsed by health systems, implemented by vendors and trusted by end users, these archetypes need to be quality assured and to be published and maintained by reliable certified sources.

References [1] [2] [3] [4] [5] [6]

[7]

[8] [9] [10]

[11] [12]

[13]

[14] [15] [16] [17]

De Moor GJE. Improving the Quality of Health Record Systems. eStrategies Projects. British Publishers. 2007; 28-29 De Moor GJE. Certification of Electronic Health Record Systems in Europe. European Parliament Magazine. 2008; 109-110 De Moor GJE. Improving EHR Systems through Quality Labeling. Healthcare IT Management. 2008; Vol 3; Issue 2; 29-30 International Standards Organization ISO/EN 13606 Dodd W. and Fortune J. An electronic patient record project in the United Kingdom: can it succeed? Greenes, R. A. and others, eds. Medinfo 8. 1995; 301-304 Vari S.G., Brugal G., Godo F., Bercic B., Nagy G., Avar G., Adelh D., and Lagouarde P. Regional and international integrated telemedicine network for organ transplant (HC 4028 & IN 4028 European Commission DGXIII). Proceedings / AMIA Annual Symposium. 2000; 873-7 Bates D.W., Cohen M., Leape L.L., Overhage J.M., Shabot M.M., and Sheridan T. Reducing the frequency of errors in medicine using information technology. J Am Med Inform Assoc. Jul 2001-Aug 2001; 8(4):299-308 Weed L.L. Clinical judgment revisited. Methods of Information in Medicine. Dec 1999; 38:279-86 Straus S.E. and Sackett D.L. Using research findings in clinical practice. BMJ. Aug 1998; 317(7154):339-42 Bates DW, Kuperman GJ, Wang S, Gandhi T, Kittler A, Volk L, Spurr C, Khorasani R, Tanasijevic M, Middleton B. Ten Commandments for Effective Clinical Decision Support: Making the Practice of Evidence-based Medicine a Reality. J Am Med Inform Assoc 2003, 10: 523-530 O’Connell R, Poljak A, Powsner S. Forms that Inform. Methods of Information in Medicine 2004; 43: 247-255 Lewalle P, Rodrigues J, Zanstra P, Ustun B, Kalra D, Surjan G, Rector A, Stroetmann V, Virtanen M. A deployment and research roadmap for semantic interoperability: the EU SemanticHEALTH project. In Andersen S, Klein G, Schultz S, Arts J, Mazzoleni C. eHealth Beyond the Horizon – Get IT There Proceedings of MIE2008. Studies in Health Technology and Informatics, Volume 136: 635 - 640. IOS Press, Amsterdam, 2008. ISBN 978-1-58603-864-9 McDonald C.J., Overhage J.M., Dexter P., Takesue B., and Suico J.G. What is done, what is needed and what is realistic to expect from medical informatics standards. International Journal of Medical Informatics. Feb 1998; 48(1-3):5-12 Shortliffe E.H. The evolution of health-care records in the era of the Internet. Medinfo 9. 1998; 1 Suppl:8-14 Dolin R.H. Outcome analysis: considerations for an electronic health record. MD Computing. Jan 1997Feb 1997; 14(1):50-6 Dudeck J. Aspects of implementing and harmonizing healthcare communication standards. International Journal of Medical Informatics. Feb 1998; 48(1-3):163-71 Kalra D. Electronic Health Record standards. Methods of Information in Medicine 2006; 45 Suppl 1: S136-44


91

[18] Kalra D, Blobel B. Semantic Interoperability of EHR Systems. In Bos L, Blobel B (eds) Medical and Care Compunetics 4. Studies in Health Technology and Informatics, Volume 127: 231 - 245. IOS Press, Amsterdam, 2007. ISBN 978-1-58603-751-2 [19] Beale T. Archetypes Constraint-based Domain Models for Future- proof Information Systems. The openEHR Foundation 2001. Available from: http://www.openehr.org/publications/archetypes/archetypes_beale_web_2000.pdf (Last accessed August 2008) [20] Kalra D, Tapuria A, Freriks G, Mennerat F, Devlies J. Management and maintenance policies for EHR interoperability resources. Q-REC Project no. IST 027370, Deliverable 3.3. The European Commission, Brussels, 2008. [36 pages] [21] Kalra D. Clinical foundations and information architecture for the implementation of a federated health record service. PhD Thesis. Univ. London. 2003 [22] Kalra D. Barriers, approaches and research priorities for semantic interoperability in support of clinical care. SemanticHealth Project no. IST 027328, Deliverable 4.1. The European Commission, Brussels, 2007. [33 pages] [23] Kalra D, Lloyd D. ISO 13606 Electronic Health Record Communication Part 1: Reference Model. ISO TC/215, Geneva. 2008. [99 pages]

92


An Electronic Out-of-Hours Health Record Koen THOMEER a,b,1, Marc NYSSEN b a Domus Medica, Belgium b Department of Statistics and Medical Informatics (BISI), Vrije Universiteit Brussel, Belgium

Abstract. In this paper, we describe the design, creation and testing of a new Web-Based Electronic Health Record for Out-of-Hours (OOH) use with special emphasis on coding matters. The context is the Belgian health system, in which a patients´ health record keeper is a specific GP, to whom the OOH reports, generated by any colleague who meets this patient during week-end or night shifts should converge. The system enables structured and secured acquisition of the records, intermediate storage and transmission to the GP´s who keep the respective records. In the first part of the paper, the design and implementation of this web-based application are highlighted in view of the SOEP registration methodology and explaining how coding was implemented, so that the users apply it seamlessly. Currently, the web-based OOH health record has been deployed and is en effective use by GP´s of the Domus Medica association. In the second part, a first evaluation is made, based on feedback by a group of pilot users, this evaluation shows good acceptance by field users. Keywords. Physicians, Family; After-Hours Care; Medical Records Systems, Computerized; User-Computer Interface; Evaluation Studies; Questionnaires.

1. Introduction In Belgium, primary health care (PHC) is provided by general practitioners (GP’s) and this mostly in private practices [1]. Therefore out-of-hours (OOH) care is organized in rotation in those private practices for each specific area. When a patient consults an out-of-hours GP, this GP has no access to the patient’s health record. What's more, the GP’s Electronic Health Record does not allow him to make an electronic record of the patient’s visit that can be sent to the patient’s regular GP. To solve this situation, the members of the Flemish GP society (Domus Medica) designed an OOH database application [2]. It was the first large-scale application implemented by GP's for GP's without external funding. Since mid-2003 this database has been made available as Freeware and since then it has been continuously improved, driven by feedback from the GP user base. Unfortunately, this application gives rise to problems regarding installation and updates on the local PC. Finally, compatibility issues with the operating system and MS Office can be mentioned. The application can hardly be used with non-Microsoft operating systems, such as Mac-OS and Linux or UNIX. 1 Corresponding Author: Koen Thomeer, Department of Statistics and Medical Informatics (BISI), Vrije Universiteit Brussel, Laarbeeklaan 103, 1090 Brussels, Belgium; E-mail: [email protected].

K. Thomeer and M. Nyssen / An Electronic Out-of-Hours Health Record

93

Therefore, we decided to design and implement a new web-based application that will solve the difficulties experienced with the present MS Access based application. This paper describes the design and the user evaluation of the new out-of-hours health record.

2. Material and Methods The aims of the web application were to enable out-of-hours record gathering with a user-friendly and efficient interface. The main tasks of this web application are: • to record the patient’s visit to an OOH GP and send an structured electronic record of the visit to the patient’s own GP • to enable the OOH GP to assign codes to different elements of the report • to store this coded data on the server for further analysis We have opted for a web-based system because it does not give rise to installation or configuration issues and it is platform independent. Also, a web-based application can be designed with a ´look and feel´ comparable with websites such as Yahoo! and Google with which computer users have gained familiarity, leading to immediate adoption. Secondly, we have chosen to use open source programs as much as possible. Thirdly, we have chosen to provide a 'keep it simple' interface. This means that the functionalities are logical and intuitive and that the GP can master them easily. Fourthly, we opted for a highly secure environment, especially because the application is accessible via the Internet. This means that there has to be a reliable authentication procedure with an encrypted communication protocol coupled with a logging mechanism in the background. 2.1. Step by step description of the functionalities realized by our out-of-hours health record web application. 2.1.1. Authentication, Access and Encryption First, the user has to introduce his login and password. These are filled in via the registration window. The password in the database is kept in SHA1 format. If it is correct, the user goes on to the second authentication step. In the second step the user has to insert the 'paper token' that he received after registering. The web application displays a random number between 1 and 20 and the user has to introduce the letters that are listed after this number on his 'paper token'. The user has only 6 attempts to complete a correct authentication. If he does not succeed, the account will automatically be blocked. This page and the following pages are secured in three ways: • there is only the possibility of using an encrypted connection with strong ciphers • only connections from Belgium are accepted with the Apache GeoIP module [3]

94


•

every action (authentication, viewing records, sending records, ...) is logged. The user is informed about this feature: he can check his own logbook and acknowledges that he can be sanctioned for misuse.

2.1.2. Filling in records - Medical Part (Figure 1) Ideally, the record consists of what clinicians have heard, seen, thought and done [4]. So we did implement the SOEP system [5]: subjective (heard: patient complaint), objective (seen: clinical/technical examination), evaluation (thought: possible diagnosis), planning (done: medication, sending to hospital, prescribing physiotherapy, ...). For each of these subparts, we provided the possibility to write in 'free text' because it is not possible to code everything (nuances, descriptions, ...). For the subjective and evaluation part it is possible to code with the IBUI thesaurus [6]. We selected the IBUI-thesaurus, because it is much easier for the user to find the correct term because the thesaurus includes jargon, idiomatic expressions, synonyms, etc. Secondly, each IBUI term is linked with one ICPC-2 code and one ICD-10 code: this facilitates scientific research afterwards. In the web application there are three ways to find the correct IBUI code: • ICPC → IBUI: first, the user has to click on the right ICPC-code in the ICPCtree: he gets a list of IBUI terms which are related to this ICPC-code. • search term → IBUI: the user has to type in a search term. The user has then to select the right IBUI term from a list of corresponding terms • list of most used IBUI-terms: this list has been copied from the former web application of the Flemish GP association (Domus Medica). (This list is said to contain 80% of the codes used during OOH visits.) The user has only to select the right IBUI term. In all three cases, when hovering with the mouse pointer over an IBUI-term, the user sees descriptions of the related ICPC and ICD codes. For the medication under the planning part, we have linked the medication to a Belgian CNK code (Code National – Nationale Kode). The actions under the planning part (referral to hospital, administration of vaccination, application of pressure bandage, ...), are linked with the ICPC-2 codes. 2.1.3. Record verification and acceptance After the user acknowledges that the report is ready, he gets a final overview of its contents (without input fields or buttons). He can then choose to accept it as finalized. 2.1.4. Transfer of Record to EHR of patient’s GP The record will be sent to the EHR of the patient’s GP in MediDoc or Kmehr-Bis [7] format (depending on the choice of the receiving GP). An external program (MediBridge) does the secured transfer from the server to the PC of the receiving GP. 2.1.5. Storing the records on the server. All the record fields are stored in the tables of the database server. In this way, it is possible to analyze the data records afterwards.


95

Figure 1. Medical Part (Fill in Record)

2.2. Evaluation of the web application We have made an evaluation of our web application to find out whether or not it meets externally validated usability criteria, using the computer system usability questionnaire (CSUQ)[8]. We posted a message on the electronic mailing list of the Flemish GP society (Domus Medica). Every GP interested in participating would be accepted. Because we were aiming for less than 30 participants we did not plan to analyze the participants’ profile. To the CSUQ list (Figure 2), we did append one question to evaluate the usability of coding the subjective and evaluation part (Q3) and another question to evaluate the

96


medication module (Q4). Question 17 of the CSUQ was not used in our questionnaire because the Dutch translation of this question leads to about the same formulation as question 16 in the CSUQ (Q18). The user could score from 1 (strongly disagree) to 7 (strongly agree) or say that the question was 'not applicable' to him.

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20

Overall, I am satisfied with how easy it is to use this system It was simple to use this system The coding of the Subjective and Evaluation part was simple The prescribing of the medication was simple I can effectively complete my work using this system I am able to complete my work quickly using this system I am able to efficiently complete my work using this system I feel comfortable using this system It was easy to learn to use this system I believe I became productive quickly using this system The system gives error messages that clearly tell me how to fix problems Whenever I make a mistake using the system, I recover easily and quickly The information (such as online help, on-screen messages, and other documentation) provided with this system is clear It is easy to find the information I needed The information provided for the system is easy to understand The information is effective in helping me complete the tasks and scenarios The organization of information on the system screens is clear The interface of this system is pleasant This system has all the functions and capabilities I expect it to have Overall, I am satisfied with this system

Figure 2. Questionnaire

3. Results From the mailing list we received replies from 28 respondents who were interested in participating. Out of these, 18 completed the whole procedure (Two Patient Cases and Evaluation Form). 3.1. Analyzing used codes First we analyzed the results of the two experts, who did validate the codes selected by the users. This gave us a surprising result: on the Subjective and Evaluation part, there was only agreement on 8 of the 15 codes selected by the users. Due to this lack of agreement by the experts, we did no further analysis of the codes selected by the users. On the other hand, the chosen action and prescribed medication codes were all correct. 3.2. Time needed to complete the two hypothetical cases The time needed was the same for two cases: about 5 minutes (median) each, with an interquartile range of 2 to 10 minutes. This is a good score, taking into consideration the fact that it was the first time the participants had used the web application. In the comments, some participants mentioned that the learning curve to use the application would be easy.


97

3.3. Results from the questionnaire The median of all the subscales (System Usefulness, Information Quality and Interface Quality) was 6, which means this is a good score. The Overall Score was also 6 with an interquartile range of 5 to 6. The special question about the usefulness of the Coding for the Subjective and Evaluation part (Q3) scored less, but was still acceptable: 5, with a interquartile range of 4 to 6. The special question about the usefulness of the Medication module (Q4) scored also well: 6, with a interquartile range of 4 to 7.

4. Discussion 4.1. Usability Testing Our web application obtained a rather good score for usability (median of 6 for System Usefulness, Information Quality and Interface Quality). This means that the 'Keep It Simple' concept has succeeded. However, because of the small and selective sample (the pioneers), we think that these results might be biased. At the time of writing, we only had 28 responses. As deployment evolves, more users become available and a broader enquiry in a wider environment is planned. 4.2. Coding Matters We surmise that the disagreement among the experts is the consequence of the absence of a National Coding Manual and of courses in coding. This paper does not wish to take a position as to whether or not coding is the task of the GP, but coding does provide a rich variety of possibilities for different stakeholders. Because our web application does keep the inserted codes in the database, this provides a great opportunity to implement Computerized Clinical Decision Support and use the data for scientific research. 4.3. Open Source We almost succeeded in using only Open Source software to elaborate this concept. The only problem was the MS Windows based application MediBridge that performs the encrypted communication between the EHRs. We regret that the MediBridge source code is closed, because we have no certitude about the encryption and the confidentiality of the medical data. We hope that this project will contribute to the advancement of Medical Informatics. Willingness to share advances with others, who can then add their own unique contributions, furthering progress in the field, is critical to vitality and overall growth. This has largely occurred via scientific literature in past decades. Now, as computer technology and software become more critical, sharing computing methods becomes a parallel to academic journals[9].

98


4.4. The Future 4.4.1. Computerized Clinical Decision Support (CCDS) Because the GP can code different parts of the visit, this makes it possible for the web application to notify the GP of the existence of a clinical guideline about the coded problem. At the moment there exists in Dutch different websites with good quality guidelines: Domus Medica [10], Folia Pharmacotherapeutica [11] and Nederlands Huisartsengenootschap [12], but somehow doctors do not implement them [13]. This notification component could provide a solution for this issue. 4.4.2. Development of a Centralized Electronic Health Record This web application has most of the components of an Electronic Health Record. We believe that with the appropriate funding it would be possible to develop a web-based EHR that complies with the recommendations of the EMDMI Working Group [14]. It would have the same advantages as this OOH web application, but to a greater extent.

5. Conclusion We did succeed in creating a new Web-Based Out-of-Hours Health Record. The usability testing, relying on the responses of 18 GP's, scored very well. It did not lead to suggestions for major improvements. We could not score the correctness of the codification selected by the participants because there was no agreement between two external experts. We believe that this was due to the lack of a National Coding Manual. We nearly succeeded in using only Open Source Software to make this Health Record but we were limited by that fact that we could not avoid using a MS Windows based communication program. We believe that the Open Source concept will contribute to the advancement of Medical Informatics.

References [1] [2] [3] [4] [5] [6] [7]

[8] [9]

Corens D. Health system review: Belgium. Health Systems in Transition 2007; 9(2):1-172. Domus Medica. Information Page OoH Mailer. http://www.wvvh.be/Page.aspx?id=465. 2008. Ref Type: Electronic Citation License Information about GeoIP Lite. http://www.maxmind.com/download/geoip/database/LICENSE.txt. 2007. Ref Type: Electronic Citation Rector AL, Nowlan WA, Kay S. Foundations for an electronic medical record. Methods Inf Med 1991; 30(3):179-186. Verdonck P, Strobbe J, Steenackers J, Van Royen P, De Naeyer P, Govaerts F et al. Het elektronisch medisch dossier. Huisarts Nu 2004; 33(2):58-68. Thesaurus. http://www.chu-charleroi.be/Kmehr2/Thesaurus/Thesaurus-Note-Fr.pdf. 2005. Ref Type: Electronic Citation Telematics Commission Wgd. Advice nr 4: Telematic Standards in relation to the Health Sector. https://portal.health.fgov.be/pls/portal/docs/PAGE/INTERNET_PG/HOMEPAGE_MENU/GEZONDH EIDZORG1_MENU/AUTOMATISERING1_MENU/SYMPOSIA1_MENU/AVIS25_MENU/AVIS25 _DOCS/A04-UK.PDF. 2001. Ref Type: Electronic Citation Lewis JR. Computer Usability Satisfaction Questionnaires: Psychometric Evaluation and Instructions for Use. Int J Hum Comput Interact 1995; 7(1):57-78. Erickson BJ, Langer S, Nagy P. The role of open-source software in innovation and standardization in radiology. J Am Coll Radiol 2005; 2(11):927-931.


99

[10] Aanbevelingen voor goede medische praktijkvoering. http://www.domusmedica.be/Page.aspx?id=710 . 2008. Ref Type: Electronic Citation [11] Folia Pharmacotherapeutica. http://www.bcfi.be/folia/index.cfm?FoliaWelk=RECENT. 2008. Ref Type: Electronic Citation [12] Index NHG-richtlijnen. http://nhg.artsennet.nl/uli/?uli=AMGATE_6059_104_TICH_L228897645 . 2008. Ref Type: Electronic Citation [13] Van Linden A, Heymans I, Mambourg F, Leys M, De Prins L, Dieleman P et al. Feedback: onderzoek naar de impact en barrières bij implementatie – Onderzoeksrapport: deel 1. 9A. 2005. KCE Reports. Ref Type: Report [14] De Clerq E, Piette P, Strobbe J, Roland M, Steenacker J, Vandenberghe A et al. Structure of the Electronic Patient Record. Version 2.0. EMDMI Working Group. 2003. Ref Type: Generic


4. Secondary Usage of EPR Data



103

Electronic Patient Record data as proxy of GPs’ thoughts Etienne DE CLERCQ1, Viviane VAN CASTEREN2, Pascale JONCKHEER3, Peter BURGGRAEVE4 and Marie-France LAFONTAINE2 1 Health Systems Research, Université Catholique de Louvain, Brussels, Belgium 2 Scientific Institute of Public Health (IPH), unit of Epidemiology, Brussels, Belgium, 3 Société Scientifique de Médecine Générale (SSMG), Brussels, Belgium 4 Domus Medica (Flemish Institute of General practitioners), Berchem, Belgium

Abstract. Data currently available in primary care Electronic Patient Records (EPR) can potentially be used to study quality of care. In this paper we investigate to which extend these data can reflect GPs’ “thoughts” that are an important issue when considering GPs’ practice and quality improvement cycle. Within the Resoprim project, we mainly used the consolidated data of three software systems, 26 practices, 1 554 hypertensive patients and 1 977 contacts. Extracted data from the EPR were: some diagnoses, some drugs, referral events, marital status, some parameters (smoking status, height, weight, blood pressure). As “gold standard” of GPs’ thoughts we used an electronic questionnaire at the end of each contact. Measures of missing and incoherent values were used to assess our “gold standard”. Sensitivity, positive predictive values, correctness and global completeness were used to measure the quality of the automatic extracted data (our proxy). For the “gold standard”, the global percentage of missing values is 1.88% and of incoherent values is 3.92%. For most of the practices, the PPV or the correctness of automatic extracted drugs and automatic extracted parameters is high (>95%). The PPV of automatic extracted diagnoses is variable (42.1% to 94.9%). The sensitivity of automatic extracted diagnoses and drugs is lower than 67%. For most of the practices the sensitivity of automatic extracted parameters (excl. smoking status) is higher than 95%. The global completeness of height and weight is lower than 76%. Referrals are badly recorded or extracted. Currently in Belgium, without additional investigations, databases built on data extracted from EPRs can hardly be considered as good proxies of what is thought or known by the GPs. To use them as proxies, we should at least develop tools such as electronic questionnaires to calibrate them. As priority, we suggest an improvement of the extraction procedure design, of the current software interfaces and of the quality control of the extraction modules in order to improve respectively the extracted drugs sensitivity, the global completeness of extracted parameters and the PPV of extracted diagnoses. Training GPs could also be helpful. Keywords. Medical records, Primary health care, Data collection, Computerized patient records.

1 Dr Etienne De Clercq, HSR – ESP – UCL, Clos Chapelle aux Champs 30.41, 1200 Brussels Belgium; Email: [email protected]

104

E. De Clercq et al. / Electronic Patient Record Data as Proxy of GPs’ Thoughts

1. Introduction Data currently available in primary care Electronic Patient Record (EPR) can be used for various research purposes. Opportunities and challenges have been described [1, 2]. In the scope of quality of care assessment, EPR may help to appraise the technical dimension of the quality, i.e. the conformance with specification or clinical guidelines, mainly for its process and outcome aspects [3]. Many studies related to quality of care critically reported on documented performance as measured by chart extraction [4-6]. In the practice, GP’s acts are influenced by many factors such as patient’s will, physician’s own skill and knowledge, time constraints, organizational issues, but also by what the practitioner knows (or thinks) about patient’s health status and about performed actions. Therefore, GP’s thoughts are an important issue when considering GP’s practice and quality improvement cycle. A long time ago, Rector stated that “information in the medical record is not about what was ‘true’ of the patient, but what was observed and believed by clinicians”[7]. In this paper, we investigate to which extend extraction of routinely collected EPR data in primary care can reflect GPs’ “thoughts”. As far as we know, this issue has not yet been treated in the literature.

2. Material and Methods Our research was performed within the Belgian ResoPrim project framework. This project involved 26 volunteer GPs’ practices which between them used three different labelled software systems (out of the 19 currently used in Belgium). Thirteen GPs were using software1, five software 2 and 8 software 3. From these practices, data were prospectively collected over 6 weeks in early 2005 around the theme “hypertension and cardiovascular risk factors”. Quality control and quality assessment procedures (using a dummy patients technique) were conducted for the extraction modules developed by each software package. More details are provided elsewhere[8]. For this study, we used data related to • some specific diagnoses: hypertension, diabetes, hypercholesterolemia and cardiovascular event (myocardial infarction, angina pectoris, coronary revascularisation, stroke, transient ischaemic attack, carotid surgery, leg claudicatio, aorto-femoral revascularisation). • some drugs: aspirin, statin, and drugs related to hypertension; • referral “event”; • marital status; • some parameters: height, weight, smoking status, systolic and diastolic blood pressure. As a proxy for GPs’ “thoughts”, we used an electronic questionnaire (see Table 1). At the end of each contact with a patient the GP had to answer the first 4 questions. For hypertensive patients seen at GP’s office (according to the first 2 questions), the GP answered to the whole questionnaire (14 questions) and, for the 5 parameters, the GP had also to validate, complete or correct the data extracted from the EPR. These validated parameters were used as “gold parameters”. To assess various ways to build questionnaires (and to improve its acceptability for the participating GPs), only three


105

questions were mandatory (Q1, Q2 and Q4) and Q5.0 and Q5.x were mutually exclusive. The value “unknown” was foreseen for the questions Q3, Q4 and Q6 to Q14. Using (paper) questionnaires during (after) a contact is currently a well accepted technique for instance in the Belgian Sentinel Network (cf. http://www.iph.fgov.be/ epidemio/epien/index10.htm). After each contact data were automatically extracted from the EPR. For diagnoses we extracted ICPC2 and ICD10 codes, for drugs we extracted ATC codes, for the referrals, we extracted “events”. To improve the completeness of data extracted, we searched for diagnoses codes in various places in the EPR (problem list, diary, personal past history, list of healthcare elements, family past history). We also extracted indirect codes (i.e. codes deduced by the software systems according to information available in the EPR). For the drugs we extracted drugs prescribed during the contact and active drugs including active chronic treatments. We only extracted a complete set of data for hypertensive patients seen at GP’s office (according to the first 2 questions). We extracted from the EPR the various parameters and the marital status. No data were currently available in the EPR for the educational level.

Table 1. Electronic questionnaire Q1 Q2 Q3 Q4

Contact at GP’s office /home visit / other? Hypertensive patient? (yes / no) Education level: superior? Marital status: married?

Q8 Q9 Q10 Q11

Q5

Drugs currently taken for hypertension Q5.0: none Q5.1to7: beta-blockers, diuretics, calcium antagonist, ACE-inhibitors, sartanes, alphablockers, central working agent Does your patient take low dosed aspirin?

Q12

Q6

Is it a new case of hypertension? Patient known with hypercholesterolemia? Is the patient suffering from type 2 diabetes? Patient with personal past cardiovascular event? Patient with family past cardiovascular event?

Q13

Patient referred to a specialist for his hypertension during this contact? Q7 Does your patient take a statin? Q14 Patient referred to a cardiologist for his hypertension during the year 2004? Extracted parameters presented in a table to be validated/corrected/completed: height, weight, smoking status, systolic and diastolic blood pressure. Note 1: Q1, Q2 and Q4 are mandatory questions Note 2: : Possible value for Q3, Q4, Q6 to Q14: Yes / No / Unknown Note 3: Q5.0 and Q5.1 to 7 are mutually exclusive

For the questions, to improve our confidence in the electronic questionnaire as “gold proxy” for the GPs’ thoughts, we measured two indicators for each practice: the percentage of patients with missing value (for the 11 optional questions) and the percentage of patients with incoherent values (a kind of double entry method). For questions 3, 4 and 8 to 14, incoherent values are calculated for patients with at least two contacts during the registration period and some logically incompatible answers to a same question. For example for Q10: first answer ‘yes’, second answer ‘no’. For Q5, we were also able to calculate incoherent values for software 3 that failed to implement properly the mutually exclusive property of Q5.0 and Q5.x (during a same contact, a positive answer to Q5.0 and to Q5.x is incoherent).

106


To compare automatic extracted (AE) data and the “gold standard” (answers to the questions) we used for each practice, sensitivity (proportion of patients with a positive AE data out of all the patients with a positive answer to the related question) and Positive Predicted Value (PPV, i.e. the proportion of the patients with a positive answer to a question out of all the patients with a positive AE data related to that question). For all the parameters but the smoking status, we measured the sensitivity (proportion of patients with an AE parameter out of all the patients with a validated parameter), the correctness (proportion of patients with an AE parameter that has the same value as the validated parameter out of all the patients with the AE parameter) and the global completeness of the validated parameters (i.e. the proportion of all the patients with a validated parameter). For the smoking status, we measured the sensitivity (proportion of patients with a positive AE smoking status out of all the patients with a positive validated smoking status), the correctness (the proportion of the patients with a positive validated smoking status out of all the patients with a positive AE smoking status) and the global completeness (the proportion of all the patient with a validated smoking status). We applied these indicators to all the hypertensive patients attending GP’s office during the six weeks period. This population was identified by the answers to the first two (mandatory) questions. For questions 1 and 2, sensitivity and PPV were calculated for the whole population of patients attending GP’s office. According to the results of the quality procedures (e.g. data not properly extracted from the EPR) and sometimes to the study design (e.g. data only related to one contact), some indicators were not applicable (n.a.) to some combinations of question and software system(s).

3. Results We mainly used the consolidated data of all three software systems, 26 practices, 1 554 hypertensive patients (out of 7 831) and 1 977 contacts (out of 10 914). 3.1. Gold proxy (see table 2) In the questionnaire, the global percentage of missing values is 1.88 %. It ranges by question from 0.97% to 4.76% and by practice from 0% to 8.33%. For 95% of the applicable combinations “Practice-question” (out of 265), the percentage of missing values is less than 5%. For question Q3, Q5 and Q14, respectively 2, 8 and 3 practices have a missing percentage higher than 5%. Six practices have one question with a high percentage of missing value (in-between 10% and 75%).


107

Table 2. Missing and incoherent values in the questionnaire (“gold standard”) % of missing values % of incoherent values Total Total Soft 1 Soft 2 Soft 3 Soft 1 Soft 2 Soft 3 Questions (730 pat.) (354 pat.) (470 pat.) (1554 pat.) (244 pat.) (178 pat.) (207 pat.) (629 pat.) Q3 n.a. 0.00% 12.55% 3.80%*** 9.84% 3.37% 2.42% 5.56% Q4 n.a. n.a. n.a. n.a. 6.56% 3.37% 6.76% 5.72% Q5 4.25% 3.39% 1.91% 3.35% n.a. n.a. 8.72%* n.a. Q6 2.19% 0.56% 0.43% 1.29% n.a. n.a. n.a. n.a. Q7 1.78% 0.85% 0.21% 1.09% n.a. n.a. n.a. n.a. Q8 1.09% 1.59% 1.78% 0.56% 0.43% 2.46% 1.12% 0.97% Q9 0.97% 4.93% 1.78% 0.28% 0.21% 6.15% 5.62% 2.90% Q10 1.64% 0.85% 0.64% 1.16% 1.64% 1.12% 0.00% 0.95% Q11 1.64% 0.56% n.a. 1.54%** 2.87% 2.25% n.a. 1.75%**** Q12 1.78% 1.13% 0.43% 1.22% 6.56% 2.81% 2.90% 4.29% Q13. 1.78% 0.56% 0.43% 1.09% n.a. n.a. n.a. n.a. Q14 9.59% 0.56% 0.43% 4.76% 9.59% 6.74% 5.31% 5.25% n.a. = not applicable for various design of technical reasons. * denominator = 470 patients; ** denominator = 1084 patients; *** denominator = 824 patients;**** denominator = 422 patients

The global percentage of incoherent values (excluding Q5) is 3.92%, ranging by question from 0.95% to 5.72% and by practice from 0% to 10.42% (1 practice with only 3 patients excluded). The higher incoherent percentage for one combination “Practice-question” is 29.17% (1 practice excluded). For 77% of the applicable combinations “Practice-question” (out of 192, 1 practice excluded), the percentage of incoherent values is less than 5%. Twenty “Practice-questions” have a high percentage of incoherent values (in-between 10% and 29.17%). For Q5, most of the incoherences (39/41) are related to only one practice (out of 8). 3.2. Sensitivity and PPV of automatic extracted data (see table 3) For the drugs (Q5 – Q7) the PPV is ranging from 91.5% to 94.1% and the sensitivity from 34.1 to 59.34%. For the diagnoses (Q2, Q9 and Q10), the PPV is ranging from 42.1% to 94.90% and the sensitivity from 53.6% to 67.1%. For the referrals (Q13 and Q14), the PPV and the sensitivity are low (

Collaborative Patient Centred Ehealth: Proceedings of the Hit healthcare 2008 Joint Event: 25th Mic Congress, 3rd International Congress Sixi, Special ... in Health Technology and Informatics)

MEDINFO 2007: Proceedings of the 12th World Congress on Health (Medical) Informatics (Studies in Health Technology and Informatics)

Proceedings of International congress of mathematicians

Proceedings of International congress of mathematicians

Proceedings of International congress of mathematicians

The Roads to Congress 2008

Trends in Acarology: Proceedings of the 12th International Congress

Information Technology Solutions for Healthcare (Health Informatics)

Chaos and Fractals (International Congress)

Proceedings of the 25th International Congress of Papyrology, Ann Arbor, July 29-August 4, 2007

Proceedings of the International Congress of Mathematicians, August 21-29, 1990, Kyoto, Japan (International Congress of Mathematicians Proceedings)

Proceedings Of The 15th Scandinavian Congress

Proceedings of the Ninth International Congress on Mathematical Education

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

Health Continuum And Data Exchange In Belgium And In The Netherlands: Proceedings of Medical Informatics Congress (MIC 2004) & 5th Belgian e-Health Conference ... in Health Technology and Informatics,)

ECM-2008, Amsterdam, European Congress of Mathematics

Global Health Informatics Education (Studies in Health Technology and Informatics)

International Perspectives in Health Informatics - Volume 164 Studies in Health Technology and Informatics

Party Polarization in Congress

Medical And Care 3 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Party Influence in Congress

Parties in Congress

Strengthening Congress

Healthcare Informatics

Parties in Congress

Issue Politics in Congress

Party Polarization in Congress

Charnel Congress

Party Influence in Congress

Charnel Congress

Acts of Congress

Collaborative Patient Centred Ehealth: Proceedings of the Hit healthcare 2008 Joint Event: 25th Mic Congress, 3rd International Congress Sixi, Special ... in Health Technology and Informatics)

MEDINFO 2007: Proceedings of the 12th World Congress on Health (Medical) Informatics (Studies in Health Technology and Informatics)

Proceedings of International congress of mathematicians

Proceedings of International congress of mathematicians

Proceedings of International congress of mathematicians

The Roads to Congress 2008

Trends in Acarology: Proceedings of the 12th International Congress

Information Technology Solutions for Healthcare (Health Informatics)

Chaos and Fractals (International Congress)

Proceedings of the 25th International Congress of Papyrology, Ann Arbor, July 29-August 4, 2007

Proceedings of the International Congress of Mathematicians, August 21-29, 1990, Kyoto, Japan (International Congress of Mathematicians Proceedings)

Proceedings Of The 15th Scandinavian Congress

Proceedings of the Ninth International Congress on Mathematical Education

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

Health Continuum And Data Exchange In Belgium And In The Netherlands: Proceedings of Medical Informatics Congress (MIC 2004) & 5th Belgian e-Health Conference ... in Health Technology and Informatics,)

ECM-2008, Amsterdam, European Congress of Mathematics

Global Health Informatics Education (Studies in Health Technology and Informatics)

International Perspectives in Health Informatics - Volume 164 Studies in Health Technology and Informatics

Party Polarization in Congress

Medical And Care 3 (Studies in Health Technology and Informatics) (Studies in Health Technology and Informatics)

Party Influence in Congress

Parties in Congress

Strengthening Congress

Healthcare Informatics

Parties in Congress

Issue Politics in Congress

Party Polarization in Congress

Charnel Congress

Party Influence in Congress

Charnel Congress

Acts of Congress

Recommend Documents