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
This page intentionally left blank
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
This page intentionally left blank
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].
W.T.F. Goossen / Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT
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
W.T.F. Goossen / Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT
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
W.T.F. Goossen / Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT
•
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
W.T.F. Goossen / Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT
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
W.T.F. Goossen / Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT
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
W.T.F. Goossen / Using Detailed Clinical Models to Bridge the Gap Between Clinicians and HIT
[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.
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-11
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
O. Purcarea / Knowledge Driven Health – Microsoft Vision for Future Health Care
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
O. Purcarea / Knowledge Driven Health – Microsoft Vision for Future Health Care
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
O. Purcarea / Knowledge Driven Health – Microsoft Vision for Future Health Care
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
O. Purcarea / Knowledge Driven Health – Microsoft Vision for Future Health Care
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
O. Purcarea / Knowledge Driven Health – Microsoft Vision for Future Health Care
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
O. Purcarea / Knowledge Driven Health – Microsoft Vision for Future Health Care
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
This page intentionally left blank
1. Primary and Secondary Care Networking
This page intentionally left blank
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-23
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
C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies
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
C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies
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.
C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies
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
C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies
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
C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies
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
C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies
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
C. Artoisenet et al. / Health Networks: Actors, Professional Relationships, and Controversies
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
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-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
N. Pierlet et al. / LISA, the Next Generation: From a Web-Based Application to a Fat Client
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
N. Pierlet et al. / LISA, the Next Generation: From a Web-Based Application to a Fat Client
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
N. Pierlet et al. / LISA, the Next Generation: From a Web-Based Application to a Fat Client
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.
N. Pierlet et al. / LISA, the Next Generation: From a Web-Based Application to a Fat Client
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
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-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
H. Buysse et al. / Trans-eCare: Creating a Transparant Data Exchange Platform
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.
H. Buysse et al. / Trans-eCare: Creating a Transparant Data Exchange Platform
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
H. Buysse et al. / Trans-eCare: Creating a Transparant Data Exchange Platform
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.
H. Buysse et al. / Trans-eCare: Creating a Transparant Data Exchange Platform
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
H. Buysse et al. / Trans-eCare: Creating a Transparant Data Exchange Platform
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
This page intentionally left blank
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-47
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.
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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.
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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.
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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).
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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
S. Callens and K. Cierkens / Legal Aspects of E-HEALTH
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.
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-57
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
•
•
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
•
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
•
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
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
J.-M. Van Gyseghem / eHealth Services and Directive on Electronic Commerce 2000/31/EC
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
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-67
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
B. Claerhout et al. / A Data Protection Framework for Transeuropean Genetic Research Projects
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
B. Claerhout et al. / A Data Protection Framework for Transeuropean Genetic Research Projects
•
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
B. Claerhout et al. / A Data Protection Framework for Transeuropean Genetic Research Projects
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
B. Claerhout et al. / A Data Protection Framework for Transeuropean Genetic Research Projects
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
This page intentionally left blank
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-75
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.
R. Buyl and M. Nyssen / From a Paper-Based to an Electronic Registry in Physiotherapy
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
R. Buyl and M. Nyssen / From a Paper-Based to an Electronic Registry in Physiotherapy
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
R. Buyl and M. Nyssen / From a Paper-Based to an Electronic Registry in Physiotherapy
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
R. Buyl and M. Nyssen / From a Paper-Based to an Electronic Registry in Physiotherapy
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
R. Buyl and M. Nyssen / From a Paper-Based to an Electronic Registry in Physiotherapy
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
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-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. / Certification 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
G. De Moor et al. / Certification of Electronic Health Record Systems
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.
G. De Moor et al. / Certification of Electronic Health Record Systems
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
G. De Moor et al. / Certification of Electronic Health Record Systems
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.
G. De Moor et al. / Certification of Electronic Health Record Systems
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
G. De Moor et al. / Certification of Electronic Health Record Systems
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
G. De Moor et al. / Certification of Electronic Health Record Systems
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
G. De Moor et al. / Certification of Electronic Health Record Systems
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
G. De Moor et al. / Certification of Electronic Health Record Systems
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
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-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
K. Thomeer and M. Nyssen / An Electronic Out-of-Hours Health Record
•
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.
K. Thomeer and M. Nyssen / An Electronic Out-of-Hours Health Record
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
K. Thomeer and M. Nyssen / An Electronic Out-of-Hours Health Record
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.
K. Thomeer and M. Nyssen / An Electronic Out-of-Hours Health Record
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
K. Thomeer and M. Nyssen / An Electronic Out-of-Hours Health Record
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.
K. Thomeer and M. Nyssen / An Electronic Out-of-Hours Health Record
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
This page intentionally left blank
4. Secondary Usage of EPR Data
This page intentionally left blank
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-103
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
E. De Clercq et al. / Electronic Patient Record Data as Proxy of GPs’ Thoughts
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
E. De Clercq et al. / Electronic Patient Record Data as Proxy of GPs’ Thoughts
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%).
E. De Clercq et al. / Electronic Patient Record Data as Proxy of GPs’ Thoughts
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 (<37%) Table 3. Sensitivity and Positive Predictive Value of Automatic Extraction vs questionnaire
Q2 Q3 Q4
Soft 1 (3.367 pat.) N** Sens. PPV 869 69.30% 96.20% 991 n.a. n.a. 1746 27.70% 92.40%
N**
Soft 1 (730 pat.) Sens. PPV
N** 516 235 814
Soft 2 (1.326 pat.) Sens. PPV 38.80% 92.60% n.a. n.a. 46.20% 93.30%
N**
Soft 2 (354 pat.) Sens. PPV
Soft 3 (2.741 pat.) N** Sens. PPV 595 43.70% 93.90% 471 n.a. n.a. 1354 18.30% 91.90%
N**
Soft 3 (470 pat.) Sens. PPV
Q5 (1 to 7) 671 76.30% 96.79% 325 38.46% 98.43% 396 47.73% Q6 259 49.40% 93.40% 130 20.00% 96.30% 174 21.80% Q7 183 54.60% 93.50% 120 25.00% 100.00% 143 37.10% Q8 30 43.30% 14.40% 27 18.50% 33.30% 44 38.60% Q9 235 85.50% 39.90% 177 13.60% 77.40% 173 n.a. Q10 105 89.50% 59.50% 51 47.10% 68.60% 84 51.20% Q11 142 12.70% 75.00% 59 32.20% 52.80% n.a. n.a. Q12 101 n.a. n.a. 42 n.a. n.a. 64 n.a. Q13. 130 7.70% 31.30% 12 8.30% 4.80% 36 22.20% Q14 180 17.80% 33.30% 128 15.60% 43.50% 155 n.a. *: related to 1084 patients N** number of patients with a positive answer to the question Sensitivity and PPV were calculated for the automatic extraction procedure n.a.: not applicable for various technical reasons
80.43% 95.00% 84.10% 17.00% n.a. 89.60% n.a. n.a. 38.10% n.a.
N** 1980 1697 3914
N** 1392 563 446 101 412 240 201 207 178 308
Total (7.434 pat.) Sens. PPV 53.60% 94.90% n.a. n.a. 28.30% 92.60% Total (1554 pat.) Sens. PPV 59.34% 34.10% 41.00% 34.70% 54.61*% 67.10% 18.4*% n.a. 10.70% 16.88*%
92.70% 94.10% 91.50% 17.10% 42.1*% 66.80% 61.7*% n.a. 25.70% 36.60*%
108
E. De Clercq et al. / Electronic Patient Record Data as Proxy of GPs’ Thoughts
3.3. Quality of automatic extracted (AE) and validated parameters (see table 4) In the software systems, ‘never’ was used as default value for the smoking status. It was thus impossible to calculate the completeness. The percentage of smokers and past smokers are respectively 11.5% and 11.3% (soft. 1 and 3). For all the other parameters, the completeness of the validated parameters varies between 68% and 97.30%. For all the five parameters, the correctness is very high (from 97.87% to 99.80%). The sensitivity for the smoking status (value ‘smokes’) is 66.67% (78.85% for the value ‘stopped smoking’ for the software 1). For the other parameters, the sensitivity ranges from 77.20% to 92.30%. 58% of the practices (15/26) have sensitivity higher than 95% for all the parameters, but the smoking status.
Table 4. Quality of automatic extracted and validated parameters Validated parameters Smoking status
Height
Weight Systolic blood pressure Diastolic blood pressure
completeness Sensitivity (AE) Correctness (AE) completeness Sensitivity (AE) Correctness (AE) completeness Sensitivity (AE) Correctness (AE) completeness Sensitivity (AE) Correctness (AE) completeness Sensitivity (AE) Correctness (AE)
Soft 1 (730 pat.) n.a. 91.50% 97.70% 57.90% 97.60% 100.00% 68.10% 98.00% 99.60% 98.50% 98.30% 98.30% 98.20% 98.50% 98.50%
Soft 2 (354 pat.) n.a. n.a. n.a. 79.90% 55.10% 99.40% 81.10% 61.70% 97.30% 92.70% 68.90% 97.40% 92.70% 68.60% 98.30%
Soft 3 (470 pat.) n.a. 13.60% 100.00% 74.50% 70.30% 99.60% 83.40% 78.80% 98.40% 98.90% 99.60% 99.80% 99.40% 99.40% 99.80%
Total (1554 pat.) n.a. 66.67%* 97.87%* 68.00% 77.20% 99.80% 75.70% 82.70% 98.80% 97.30% 92.30% 98.70% 97.30% 92.30% 98.90%
Global completeness is measured for the validated parameters Correctness and sensibility for smoking status are calculated for “smokers” n.a.: not applicable for technical reasons * related to 1200 patients
4. Discussion For the questions, the percentage of missing values for simple questions (answer: yes/no/unknown) is very low. Therefore more complex question design, such as Q5 with mutually exclusive parts, or mandatory questions (Q1, Q2 and Q4 were mandatory with a strong technological control, all the other questions were optional) does not seem very useful or required (see table 2). Missing and incoherent values (for Q3 and Q6 to Q14) may be considered as a partial measure of the gap between what is thought by the GP and what is recorded in our “gold standard” (unknown is a possible value). For these questions, incoherent values were only measurable for patients attending GPs’ office at least twice (40% of the hypertensive patients) Given the quality of our “gold standard”, we think that a PPV and a sensitivity of 90% for the automatic extraction (AE) is quite acceptable. To assess this quality, alternative methods such as think aloud techniques could have been considered but they can hardly be implemented in a GP’s running environment.
E. De Clercq et al. / Electronic Patient Record Data as Proxy of GPs’ Thoughts
109
For drugs we found a high PPV but an unexpectedly [9, 10] low sensitivity. Even if we took into account all the active drugs as registered in the EPR (plus all the drugs prescribed during the pilot phase), the sensitivity was not higher than the diagnoses sensitivity. This is valid for drugs with (Q5, Q7) or without (Q6) compulsory prescription. Means to improve it could be: to take into account all the drugs prescribed during a longer period, e.g. the 3 last month, to improve the ‘active drugs’ management by the software systems, to stimulate GPs to use their prescription software modules. For the diagnoses the sensitivity is not very high, even if we took into account all the rubrics of the various EPR systems (problem list, past medical history, diary, etc.), including codes derived by the software systems. For each of the three software systems, diagnoses codes are effectively spread over several rubrics. More challenging is the PPV, which is variable by practice and by code. This hampers the ability to identify homogeneous groups of patients. This could be related to the quality of the software extraction modules (confusion between personal past event and family history, calculation of the derived codes by the software systems) or to the ways questions are presented to the GPs (Q2 = mandatory, Q9 and 10 = optional and included in a broader list of questions). In the latter case, it raises the issue of using questionnaires as “gold standard” for diagnoses. This will be investigated later using data of the second phase of the Resoprim project. For the referrals, sensitivity and PPV are low. This could be progressively improved by stimulating the exchange of computerized referrals thanks to the development of secured messaging systems, electronic signatures and unique patient identification systems. Smoking status is badly encoded and extracted. For all the other 4 parameters, the correctness and, for most of the practices, the sensitivity are rather good. Therefore we can wonder if the semi-automatic data extraction procedure (i.e.: secondary validation by the GP after extraction) is very useful. Only for six practices (out of 26), the number of patients with documented parameters was improved by more than 10%. To increase the sensitivity, an alternative strategy could be applied: first to improve the software interfaces and second, to persuade GPs to write down in their EPR what they have measured. To improve the completeness of some parameters (height, weight) is still challenging. It requires a change in GPs’ behaviour to measure them.
5. Conclusions Currently in Belgium and 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. Therefore, to make them usable in well defined contexts [11], we strongly advise to develop tools, such as an electronic questionnaire, in order to calibrate these proxies. As technical priorities, 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 completeness of extracted parameters and the PPV of extracted diagnoses. Training GPs could also be helpful to improve the quality of data recording.
110
E. De Clercq et al. / Electronic Patient Record Data as Proxy of GPs’ Thoughts
Acknowledgments We thank all the GPs and the industrial partners involved in the data collection. This work benefits from grants of the Belgian Federal Public Planning Service Science Policy (Nr I2/AE/207 and Nr I2/2F/207).
References [1]
de Lusignan S, van Weel C. The use of routinely collected computer data for research in primary care: opportunities and challenges. Family Practice 2006; 23:253-63. [2] De Clercq E, Van Casteren V, Jonckheer P, Burggraeve P et al. Research networks: can we use data from GPs’ Electronic health Records. Stud.Health Technol. Inform. 2006; 124:181-6. [3] Campbell SM, Roland MO, Buetow SA. Defining quality of care. Soc Sci Med 2000; 51(11):1611-25 [4] Dresselhaus TR, Peabody JW, et al.. Measuring compliance with preventive care guidelines: standardized patients, clinical vignettes, and the medical record. J Gen Intern Med 2000; 12(11):782-8. [5] Kerr EA, Smith DM, Hogan MM, Krein SL, et al.. Comparing clinical automated medical record, and hybrid data sources for diabetes quality measures. Jt Comm J Qual Improv 2002; 28(10):555-65. [6] Kirk SA, Campbell SM, et al. Assessing the quality of care of multiple conditions in general practice: practical and methodological problems. Qual Saf Health Care 2003; 12(6):421-7 [7] Rector AL et al. Foundations for an electronic medical record. Meth Inf Med 1991;30:179-86. [8] De Clercq E, Van Casteren V, et al. Resoprim – Are GPs’ Electronic Health Records suitable for use in Public health Research?, Scientific Institute of Public Health ed., Brussels, January 2008, 64 pp. Report D/2008/2505/03. http://www.iph.fgov.be/epidemio/epien/re_pr_en/D_2008_2505_03.pdf [9] Thiru K, Hassey A, Sullivan F. Systematic review of scope and quality of electronic patient record data in primary care. BMJ 2003;326:1070. [10] Luck J, Peabody JW, Dresselhaus TR, Lee M, Glassman P. How Well Does Chart Abstraction measure Quality? A Prospective Comparison of Standardized Patients with the Medical Record. The American Journal of Medicine 2000; 108:642-49. [11] Nicole Boffin, Van Casteren V, et al. P. Elektronische dossiergegevens en kwaliteit van zorg: ervaring uit Resoprim over hypertensiepatiënten. Huisarts Nu. 2008;37(3):131-38.
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-111
111
Privacy Protection through Pseudonymisation in eHealth a
F. DE MEYER a, G. DE MOOR b, L. REED-FOURQUET c Dept. Of Medical Informatics & Statistics, University Hospital Ghent, Belgium b Dept. Of Medical Informatics & Statistics, Ghent University, Belgium c e-HealthSign LLC, Wallingford, USA
Abstract. The ISO TC215 WG4 pseudonymisation task group has produced in 2008 a first version of a technical specification for the application of pseudonymisation in Healthcare Informatics 0. This paper investigates the principles set out in the technical specification as well as its implications in eHealth. The technical specification starts out with a conceptual model and evolves from a theoretical model to a real life model by adding assumptions on the observability of personal data. Keywords. Privacy, Privacy Enhancing Technology, Pseudonymisation
1. Introduction In 2008, the current version of the ISO TS 25237 technical specification was released by the International Standardisation Organisation Health Informatics Technical Committee – security working group (ISO TC 251 WG4). Work started in 2005. The scope of this working group is “defining standards for technical measures to protect and enhance the confidentiality, availability and integrity of health information, and also accountability for users, as well as guidelines for security management in healthcare”. The TS 25237 document has been issued as a Technical Specification (TS) and not as a standard. ISO rules state that “When the subject in question is still under development or where for any other reason there is the future but not immediate possibility of an agreement to publish an International Standard (IS), the technical committee may decide that the publication of a technical specification would be appropriate”. Technical specifications shall be reviewed at least every three years to decide either to confirm the technical specification for a further three years, revise the technical specification, process it further to become an International Standard or withdraw the technical specification. After six years, a technical specification shall be either converted into an International Standard or withdrawn. ISO member bodies may adopt technical specifications and publish them as documents having the same level of authority as the ISO/TS. The document is a first in its kind on de-identification through pseudonymisation and constitutes the foundation for potential future standards.
112
F. De Meyer et al. / Privacy Protection Through Pseudonymisation in eHealth
2. The rationale for pseudonymisation Pseudonymisation provides a means to link information together originating from the same entity across multiple data records or information systems without revealing the identity of the entity. The primary risk mitigated by pseudonymisation is privacy violation. The term “pseudonymisation” may cause confusion. For readers unfamiliar with privacy protection, the word “pseudo” may invoke a negative bias. Moreover, “pseudonymisation” is only a specific instance of privacy enhancing technology 0. It is a de-identification concept. Nevertheless, for the sake of consistency with the technical specification, this document will continue to use the term “pseudonymisation”. A pseudo-identity is therefore a means to link data together and by definition does not automatically lead to identification of a data subject. The advantage of using pseudonymised data instead of unrelated records from which all identifying data has been removed is the possibility to group data collected at different moments or coming from different sources. This is particularly useful in research applications that are interested in the aggregation of data or when cases are to be grouped without revealing identities. Ethical and legal regulations prefer or may even require that research data be collected with the identifying data elements removed. In many applications this is only possible after the various data elements have been aggregated. The aggregation process itself requires a way to link the collected source data elements together. If privacy enhancing technology is not available, the linking is based on identifiable data, which in itself is against privacy protection. Pseudonymisation, when properly designed and implemented, allows the grouping of de-identified data, without revealing identities. It reconciles privacy requirements with flexibility in data linking. Research is not the only beneficiary of pseudonymisation. Pseudonymisation can also be implemented in those branches of an application chain where there is no requirement to reveal identities. An example is the de-identified testing of body samples in a laboratory and the insertion of the results in the patient record. An example scenario of this is given in the informative annex of the technical specification.
3. History of pseudonymisation Though the possibilities of de-identification through pseudonymisation are still not fully exploited throughout all application domains in eHealth, the concept is not completely new. From 1993 onwards various papers have been published on the use of pseudonymisation and privacy enhancing techniques for eHealth applications. In 1995, Germany regulated the setup of cancer registries. The setup was based upon a trusted pre-processing of identifying data by a separated trusted entity. The technology was based upon the management of encrypted control numbers 0. This has been implemented in the Cancer Registry of Lower Saxony (CARLOS). In 1996, KITH, the Norwegian centre of medical informatics published a paper called “Socio-technical aspects of the use of health related personal information for management and research” 0. There, a description is given of the technical aspects of secure information management that includes a pseudonymisation model based on double layered third party pseudonymisation. The following application fields were
F. De Meyer et al. / Privacy Protection Through Pseudonymisation in eHealth
113
thereby mentioned: epidemiological research, public health research, clinical research and evaluation as well as management, administration and finance. All these applications centred on the collection of epidemiological and research data by governmental institutions. In those days, however, most security projects in eHealth were more targeted on the introduction and use of electronic signatures and on access control. It was not until the end of the nineties that dedicated privacy enhancing technology provision became available. The EU has co-financed two projects that enhanced the take-up of privacy enhancing techniques: the PRIDEH (2001-2003) 0 and PRIDEHGEN (2001-2004) 0 projects. The latter also includes privacy issues of genomic data. The Healthgrid community also became interested in privacy enhancing technology 0. Currently, privacy protection services are available on the eHealth market either as dedicated trust service providers or as part of data management applications. The so called Article 29 Data Protection Working Party has issued a number of documents in which pseudonymisation and other de-identifcation practices are recommended (e.g. opinion 4/2007 on the concept of personal data and the working document on the processing of personal data relating to health in electronic health records).
4. Structure and scope of technical specification ISO TS 25237 4.1. Definitions, terminology and conceptual model Terminology and definitions as defined in legislation, and more in particular EU directives, are the starting point for the conceptual model. These are key to understand what is meant by identifiability, anonymity, pseudonymisation etc. Based on the relevant terminology, a conceptual model is derived that further clarifies the relationship between the entities mentioned in the definitions and clauses of the data protection regulations. The concept of identifiability in the specification is wider than normally used in legal documents. The bottom line is that a single data subject can be singled out from amongst its peers, even based on characteristics that in various circumstances can be seen as non-identifying. The conceptual model includes paths from identifiable data to de-identified data, explained in generic terms, independent of technologies that can be used to achieve this. 4.2. Real world modelling A compelling reason for drafting a technical specification is to provide guidance for decreasing the gap between theoretical conceptual models and the real world. The assessment of identifiability of data is strongly influenced by perception. From a legal point of view, the delineation between identifiable and anonymous is often seen as sharp because a theoretical definition is dualistic without a grey zone in between. Yet, this grey zone exists. Neither theory nor practice can completely eliminate this grey zone. Instead of being stuck in an endless “yes-no” debate, the technical specification proposes a way to shift the “boundary of ambiguity”. This reconciliation is achieved by translating the legal clauses found in recital 26 of the Data Protection Directive (DPD) into what is called a “real life model”. Recital 26 states: “to determine
114
F. De Meyer et al. / Privacy Protection Through Pseudonymisation in eHealth
whether a person is identifiable, account should be taken of all the means likely reasonably to be used either by the controller or by any other person to identify the said person; whereas the principles of protection shall not apply to data rendered anonymous in such a way that the data subject is no longer identifiable; whereas codes of conduct within the meaning of Article 27 may be a useful instrument for providing guidance as to the ways in which data may be rendered anonymous and retained in a form in which identification of the data subject is no longer possible” 0. Statements such as “all the means likely reasonable” and “by any other person” are rather vague. Since the definition of “identifiable” and “anonymous” depends upon the undefined behaviour (“all the means likely reasonable”) of undefined actors (“by any other person”) the conceptual model should include “reasonable” assumptions about “all the means” likely deployed by “any other person” to link observational data to data subjects. It should try to define as many elements as possible in a policy. In the specification this translates into “levels of assurance of privacy protection”. The classification provided in the specification is a first attempt. It consists of three levels. It is desirable to keep the number of levels to a minimum, while linking a particular level to a set of criteria that can easily be applied to each level. This approach is an improvement with respect to current common practices that are more or less in line with level 1 assurance. This level consists of clearly identifying data or easily obtainable indirectly identifying data. Examples of level 1 assurance are the rules of thumb as they can for instance be found in the HIPAA rules 0. These include for instance that names, addresses, phone numbers should be deleted from the data. Assurance level 2 consists of making assumptions about what kind of data that can be gathered by an attacker. This observational data is included into the model. Assurance level 2 requires a risk analysis that includes assumptions about types of attacks and attackers. An example of this is the assumption that an attacker can obtain discharge records from hospitals stating identities and discharge dates. In itself not highly revealing, but in combination with other observations, this can lead to privacy infringements. As a result it is possible to define more clearly what is stated in recital 26. Levels 1 and 2 risk analysis are “static” analyses that are not modified by the amount of data or actual instances of the data. Level 3 assurance and the associated risk analysis takes into account live repositories. One of the issues encountered in live databases is the presence of outliers or rare data that could lead, in combination with observational data, to identification of data subjects. 4.3. Categories of data subjects Though the majority of privacy issues are focused on patient privacy, other entities may require protection as well. Patient privacy is the focus because of compulsory privacy regulations. In practice, regulation is not the only motivation for protecting identities. An important group of entities that may require identity protection are health professionals or health care enterprises. This may be a requirement imposed by statistical blinding, but may also be required in e.g. peer ranking research of which the outcome can be considered sensitive for the participating organisations. Not only persons or legal entities may have their identification protected. This goes as well for systems or even molecules (e.g. in drug discovery projects where
F. De Meyer et al. / Privacy Protection Through Pseudonymisation in eHealth
115
pharmaceutical research institutes have a need to share basic research information, without exposing intellectual property details) 4.4. Re-identification Pseudonymisation can be a one way process, but technically it is possible to reverse the de-identification in controlled circumstances and in a way foreseen during the design of the system. The technical specification describes this in a more detailed way. In fact, re-identification and de-identification can be considered building block of identity management systems. Privacy protection should address more than just identifiability of an entity. Often privacy is already breached if a sensitive characteristic can be associated with an entity. An example is the assessment whether a data subject belongs to an HIV positive or negative group, without necessarily being able to identify the data subject in the group. An observer would not know which record is yours in the record set, but he would know that your record is in a particular group and therefore is able to tell if you have a particular disease or not. 4.5. The Pseudonymisation process A considerable part of the content of the technical specification has been devoted to the pseudonymisation process. It does not claim exclusivity nor exhaustiveness, but aims at a realistic and trustworthy way to design, implement and use pseudonymisation in a practical way. The specification contains an overview of the build-up of entities in the communication model from the data source up to the data target where the pseudonymised data is further handled. A key concept in the model is that de-identification service and re-identification service provision are to be delivered by a trusted third party (TTP). A trusted third party is not to be confused with a TTP used for issuing cryptographic keys for digital signatures and encryption for confidentiality applications, though both share the concept of a trusted operation based upon policies and delivered by independent specialised providers. The specification contains an example of a possible workflow and how the data can be prepared. Interoperability issues are also briefly mentioned. 4.6. A policy framework for pseudonymisation services Pseudonymisation services have in common with other data security services that the operation of the components has to be driven by a policy in order to achieve the desired effects. The privacy policy document is not only important as a reference for the operation of a trust service, but should also explain to all parties involved what can be expected of the operation and what residual issues are left unsolved that should be countered by for instance access control. Data security measures consist of a set of complimentary technical and organisational measures. Policy documents serve as references for the overall operation of all entities involved in the de-identification process and relevant parts of it should be reflected in the policy of each of these entities.
116
F. De Meyer et al. / Privacy Protection Through Pseudonymisation in eHealth
4.7. Pseudonymisation scenarios In an informative annex, the specification lists a number of common healthcare pseudonymisation scenarios. These take into account the kind of identification that is being protected, the sensitivity of the data, single or multiple data sources and their relationships, primary and secondary use of data, the type of context and a number of other parameters. Eight scenarios are listed. The scenarios include examples where irreversible de-identification of the data is required for research purposes, and where de-identification is only a temporary episode when the users of the data during that episode have no need to know the identities of the data subjects but where after that episode, controlled reversible de-identification is required. This is for instance the case when biosamples are sent to a testing lab without the lab personnel being allowed to see the associated names of the data subjects. The results are re-identified and automatically entered into the EHR at the end of that episode.
5. Further work to be done 5.1. Re-identification risk analysis The technical specification rests upon the interpretation of identifiability of data. It is clear that further research is required into the aspects of re-identification. The technical specification refers to re-identification risk analysis, but limits itself to presenting a model that extends a rather reduced view as encountered into the data protection directive towards a more realistic real life model that allows to formally take into account assumptions about data that can be obtained by an attacker. As a result, it shifts the border of ambiguity between identified, identifiable and anonymous data. It is more realistic to talk of “anonymised” data instead of “anonymous data”, the latter being a rather theoretical concept, while “anonymised” reflects that all precautions reasonably possible and commensurate to the threats have been made to prevent identification. Further study of risk analysis models can significantly contribute to model for privacy protection. 5.2. Legal uncertainty The inclusion in the technical specification of an easy to understand real life model that contains the elements to be taken into account to assess the level of assurance of the anonymity of the data is intended to bridge the gap between legal and ICT or data management experts. Legal experts admit that a degree of legal uncertainty for various aspects of eHealth remains. Privacy is one group of these issues. In order to reduce the legal uncertainty, the European Commission has carried out a project called “Legally eHealth” that included a study on legal and regulatory aspects of eHealth 0. This is without any doubt an initiative that will contribute to the deployment of eHealth. This document does nevertheless contain a statement that is contradictory to the opinion of other legal experts in the field 0. The Legally eHealth document states that though anonymous data is not subject to data protection requirements, the processing carried out to render data anonymous is considered to be a processing of personal data. As a
F. De Meyer et al. / Privacy Protection Through Pseudonymisation in eHealth
117
consequence the process of data anonymisation should be covered by data protection requirements as any other type of processing of personal data. However, stating by default that the process of anonymisation of data is in itself considered a fully fledged form of processing of personal data is contradictory to the rationale for introducing de-identification services. The technical specification agrees that privacy policies can reflect that even certain types of de-identified data may require additional data security protection (e.g. because of data that could easily be obtained by an attacker if brought outside the context for intended use). As a minimum, the authors believe that a distinction should be made depending on the role of the de-identification trusted third party in a specific contractual setting with the controller(s) of the data on which behalf it is acting. The role of the trusted party may be limited to de-identifying the data that is sent to it under responsibility of the controller of the data, or the role may be more elaborate and consist of joining data from various controllers. In the latter case, the trusted party should take more elaborate legal precautions. In the first case however, the trusted party is only performing technical services on behalf of the controller of the data and thus should be exempted from the full legal procedure required for collecting and processing of personal data. This issue should be clearly resolved once and for all. 5.3. Interoperability The objective of the technical specification is to lower the threshold for the use of deidentification and pseudonymisation in eHealth. Various methods and standards however co-exist in eHealth on how to store, process and communicate data. Some of these differences are touched upon in the informative technical annex of the technical specification, but these should be further elaborated as well. It may be beneficial that subdomains in eHealth (e.g. clinical research) reflect how privacy protection through de-identification services can contribute to relevant business cases, thereby using the technical specification as a starting point and guide. The domain of research in eHealth, based on patient data is especially interesting. It can unlock new applications in eHealth such as translational medicine and contribute to the cost efficiency of clinical research in general. The technical specification has made a good start of that but in the coming years, more concrete applications of pseudonymisation should be worked out which will lead to more complete guidelines for the application of pseudonymisation.
6. The future of pseudonymisation specifications The availability of the technical specification is an important stimulus to the take up of privacy enhancing technologies. Feedback to standardisation organisations will allow evolving the technical specification to a full standard. Various parts of the specification have been included in the HITSP/C25 0, HITSP/T24 0 and HITSP/TP22 0 documents in the U.S. that give guidance to pseudonymisation and identity management. The section on further requirements lists a number of issues that can be elaborated in the coming years in order to achieve a transparent and easy to integrate privacy protection. Especially areas that rely on the secondary use of patient data can greatly
118
F. De Meyer et al. / Privacy Protection Through Pseudonymisation in eHealth
benefit from further development of de-identification solutions and supportive functions such as re-identification risk analysis. By presenting models and policies that can be understood and agreed on by both the legal experts and the ICT experts, effective privacy protection can be further enhanced, but continuing efforts are needed to reach a common understanding of how to apply the basic principles to the various sub-domains in eHealth.
References [1] [2] [3] [4]
[5]
[6]
[7] [8]
[9] [10] [11]
[12] [13] [14]
ISO/IEC TC215/SC /WG4 ISO TS 25237 Health Informatics – Pseudonymisation DE MOOR GJE, CLAERHOUT B. Privacy Enhancing Techniques in eHealth: an Overview. Stud Health Technol Inform. 2004; vol 106;75-81. W. THOBEN, H.-J. Appelrath, Verschlusselung personenbezogener und Abgleich anonymisierter Daten durch Kontrollnummern, Verlässliche IT-Systeme, Rostock, 1995, p 193-206. KENNETH R. IVERSEN, Tor Olav Grotan, Socio-technical aspects of the use of health related personal information for management and research, Proceedings of IMIA Working Group 4 Working Conference, October 1996, Pages 83-91. DE MEYER F, CLAERHOUT B, DE MOOR G. The PRIDEH project: taking up Privacy Protection Services in e-Health. Proceedings MIC 2002 “Health Continuum and Data Echange”. IOS Press, 2002:171-177. DE MOOR GJE, CLAERHOUT B, DE MEYER F. Privacy Enhancing Techniques: the Key to Secure Communication and Management of Clinical and Genomic Data, Methods Inf Med. 2003; 42 (2):148153. DE MOOR GJE, CLAERHOUT B. Privacy Protection for Healthgrid Applications. Methods Inf Med. 2005; 44 (2):140-3. Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data. HIPAA Privacy Rule and Public Health Guidance from CDC and the U.S. Department of Health and Human Services. IAN WALDEN. Anonymising Personal Data, Int J Law Info Tech 2002 10: 224-237. EUROPEAN HEALTH MANAGEMENT ASSOCIATION. Legally eHealth. Study on Legal and Regulatory Aspects of eHealth. Deliverable 2, Processing Medical Data: Data Protection, Confidentiality and Security. 2006; European Commission Contract 30-CE-0041734/00-55. Population Health Technical Committee. HITSP/C25 Anonymize Component. 2007. Population Health Technical Committee. HITSP/T24 Pseudonymize Transaction. 2007. Population Health Technical Committee. HITSP/TP22 Patient ID Cross-Referencing Transaction Package. 2007
5. Hospital Patient Record
This page intentionally left blank
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-121
121
Eliminating the paper medical archive by bulk document scanning of historic folders and implementing revised workflows for scanning new documents Erwin BELLON a,1, Michel FERON a, Klaas PEETERS a, Matthias SWEERTVAEGHER a, Paul NEYENS a, Herman HOMBLE b, Christel ONS b, Rita LAGAE b and Bart VAN DEN BOSCH a a Department of Information Technology, University Hospitals Leuven, Belgium b Department of Medical Archiving
Abstract. We made the decision in our hospital to radically eliminate the paper archive by bulk scanning over a million medical records. This reorganization goes together with installation of new workflows for injecting information that is still captured on paper as automatically as feasible into the electronic medical record. In this article we describe our organizational and technical approach and we highlight principles which our experience suggests to be useful. Keywords. Document scanning, document imaging, electronic medical record
1. Introduction At the University Hospitals Leuven, a centrally managed 1.900 bed hospital, the inhouse developed electronic medical record (EMR) is used over all departments by anyone involved in patient care. As most of the information is available electronically, the costs to also maintain what is left of the paper archive become out of proportion. After studying several alternatives, including outsourcing the paper archive possibly combined with “on demand” document scanning if an historic paper record is needed, we concluded that one-time “bulk scanning” of the historic files was an economically more attractive alternative, and convincingly less expensive than maintaining the paper based operations. An added advantage was that all medical information would be available in electronic form. The decision was thus made to radically eliminate management and distribution of paper records in our hospital. This does not imply that no paper is used anymore. Firstly, paper keeps flowing in from outside. Secondly, making notes on paper may still be more efficient in some situations or be preferred by a (decreasing) group of users, or simply be the only practical option available, e.g. if drawings are involved. Thirdly, although also the end users are convinced nowadays that direct digital capture of structured information is
1 Corresponding Author: Erwin Bellon, University Hospitals Leuven, Herestraat 49, 3000 Leuven, Belgium; E-mail:
[email protected].
122
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
preferable, it is not possible to implement or integrate all the requested applications immediately. Scanning of new documents will only gradually become less relevant. Thus, from the input side two subprojects can be distinguished: bulk scanning of kilometers of shelves of paper records on the one hand, designing and implementing new processes to scan new paper into the EMR on the other hand. From the output side challenges are efficient retrieval of and interactive navigation over digital documents. In this paper we describe organizational and technical principles of our approach, and motivate these from their impact on hospital-wide operations.
2. Size of the Project and Technical Environment Bulk scanning affects the active and semi-active parts of the archive, representing 1.250.000 patient files or hundred million pages. These currently take 11 kilometers on shelves. About a million files that are only infrequently consulted and stored off site are not included in this project as economic arguments were less compelling for that passive archive. The daily flow of new documents corresponds to a pile of 2 meters high or about 20.000 sheets. Transparency film is not included in this project. Most of such films are stored in separate folders, which do not require a lot of manipulations anymore since PACS has become operational a few years ago. Small size transparencies that found their way into the paper folders are manually removed. Documents are scanned in color at a resolution of 200 dpi and stored in JPEG format. This part of the historic archive will take 30 terabytes after scanning (this is net space; as we keep two copies and with the overhead for other aspects of redundancy, we allocated about 100 terabytes brut on our central disk storage system to this project). The IT solutions for this project are mostly developed in house, in Java, to tightly integrate into the existing EMR, to reuse previous developments, and to have utmost freedom in implementing radically new organizations.
3. Organizational Approach and Emphasis in IT Support 3.1. Scanning and Indexing of Historic Paper Files Scanning of the historic paper files has been outsourced to Input For You (IFY, http://www.inputforyou.be, Belgium). This includes such operations as removing the documents from their jackets, removing staples and such, possibly cutting large sheets… Efficiency dictates that both sides of each document are scanned even if a side is “blank”, and scanning orientation is determined by the need to minimize paper jams on perforations more than by orientation of the actual information. In a typical project IFY provides services for post processing the scanned documents (including removal of blank pages and rotating pages) and indexing them into categories agreed with the hospital. In this project, in contrast, we rely on our own software for such operations, as described later. IFY may insert sheets with a bar code, e.g. to group the many pages of an ECG or to refer to the physical jacket that contains removed transparency films. The hospital tracks in its information system which physical folders were delivered and provides IFY with lists of patient IDs that must be attributed to the scanned documents. Details on this process and on checks for correctness are outside the scope of this paper.
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
123
Whenever a new group of users is included into the project, they perceive the historic archive as having been scanned overnight. In reality the folders for expected patients are scanned with priority (instead of being loaded on charts for distribution) while the other folders continue to be scanned in lower priority. This enables us to make the transition to “paperless” organization for old documents in one move, and to directly save on operations. As from that moment there is no physical storage anymore for new paper, the workflows for scanning new documents must be in place as well. 3.2. Workflows for Scanning and Indexing New Documents We established as a general principle that documents are scanned centrally. This makes it feasible to install heavy duty and high throughput scanners, to concentrate hardware maintenance, to increase efficiency of scanning personnel that is experienced in this particular task (while other personnel can concentrate on their tasks instead), and to ensure that scanning is according to quality and policies needed for further import. This decision to centralize scanning fits well with the fact that there generally is no need to have documents scanned immediately. In contrast, paper is generally quite handy for the tasks around the current patient contact. For example, the file with remaining paper maintained during a hospitalization is frequently consulted at that ward while there is little need to access that information from other locations. Thus, those documents are scanned after the hospitalization, at the moment they would in the traditional system be sent to the central filing room. If after emergency admission a patient goes home, the assembled documents are sent to the scanning service; but if the patient is hospitalized instead, the documents travel with the patient to get scanned at the end of the stay. If a patient contact (consultation, hospitalization, function measurement…) is available in the EMR, paper documents are linked to that context using a cover sheet as illustrated in Figure 1a. At the outpatient consultations these sheets are automatically printed as part of the patient reception process. This sheet becomes the first page in a “mini jacket” that replaces the traditional paper folder and that after the consultation will contain all documents to be scanned with that contact. For hospitalizations and some other applications such as surgery, the separator sheet is not printed up-front but at the moment the assembled papers are cleaned up and made ready for shipping to the central scanning service. The manual actions needed to generate those sheets are still minimal as the computer system presents work lists. This organization is less suited for indexing of documents that arrive in an ad hoc fashion, for example by traditional mail. In this situation, manually printing separator sheets with patient identification is cumbersome, as there are no work lists that make patient selection efficient. A dramatically more efficient workflow is to simply scan a batch of paper as it arrived at the central location (putting documents about different patients after each other) and to classify each scanned sheet on the computer using a graphical user interface. One advantage is that the computer can in many situations already give hints about e.g. patient or document date, by automatic recognition of phrases from the printed text on the document. 3.3. Management and Classification of Documents in the Computer System In our management system documents are always associated to a patient and potentially to an encounter in the EMR, as described in previous paragraphs. In
124
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
addition, documents can be labeled (tagged). This amounts to classification, though in our approach a document can have multiple tags. Detailed classification of documents into (sub) categories is likely to involve costly manual actions. The basic assumption in our project is that such classification is not per definition necessary, but that we will try to classify a subset of documents using automated methods. This automation is primarily based on optical character recognition (OCR) of printed text. OCR is performed in the back end as part of the processing of importing scanned documents into our database (other processing steps are automated recognition of blank pages, so these can be flagged in the database, and automated detection of page orientation). − If we have no control over the printed forms, as is the case for historic documents, recognition is based on a combination of words that must appear on the page. − If we do have control over the printed form, we may explicitly include a text on the document to trigger recognition. This text is printed in a font particularly suited for OCR, but it may be an advantage that the text is human readable. For example, a text “progress notes” may appear as the heading of preprinted pages (Figure 1b). We experiment with including codes in the heading of documents such as patient questionnaires, codes that in this case also contain page numbers. − Important external documents, which we have no control over but which are difficult to recognize automatically due to their variability, such as referral letters, may get a sticker with such a textual code attached (Figure 1c). − In some situations, a label may apply to a complete set of documents, for example nursing notes. Then a dedicated cover sheet may be useful. − The option remains for users to explicitly label documents using the GUI. OCR is also deployed to scrape dates from documents. Recognizing dates works fairly well; the problem rather is that many dates may appear on a document. We consider the first date encountered (after filtering out obvious dates) the most likely candidate.
Figure 1. Cover sheets relate a batch of documents to patient and context in the EMR and optionally carry labels to be attributed to those documents (a). Document types can also be inferred from text after OCR, either on the original documents or explicitly inserted in the heading (b) or even attached to the paper using a sticker such as in this example of a referral letter (c).
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
125
3.4. Interactive Viewing and Navigation Scanned documents that are linked to a patient contact can be viewed as annexes to the electronic information in that contact. However, it is not always obvious in retrospect which contact documents are linked to, for example if the patient brings documents from another hospital (which we attach to the current contact). Furthermore, documents may not be linked to a contact at all, e.g. with historic documents or documents received by mail or FAX. There always is the possibility to open a viewer that presents all scanned documents for this patient (including documents that were imported in electronic form such as PDF – for the computer these are also just a blob of data). Design priority in this document viewer was to enable efficient overview of the available information and to provide functions to find the relevant information rapidly. The fact that documents are not in all situations rigorously classified makes this even more important, though efficient navigation is probably essential in any organization. A first element in efficient overview and navigation is the pictorial overview of all documents as thumbnails, as illustrated in Figure 2a. The rightmost panel shows the document over which the mouse currently hovers in a slightly larger format. This panel also enables high-speed scrolling through the pile of documents (Figure 2b). Neither of these presentations is intended for reading the content on the document – they serve to locate the document one would like to bring on the screen in full resolution. This organization exploits the ability of humans to visually recognize information even if there is little inherent ordering. This is one reason for us to use present the documents in color, even if the resulting memory requirements are technically challenging. From technical side, fast navigation over potentially hundreds of documents is accomplished by using lower resolution preview versions, as computer memory is the bottleneck. If a document is opened in full size (Figure 2c) the usual tools are available to zoom into parts of this page or to navigate to nearby pages. The rightmost pane is now used to also present nearby pages that form the context for the current document, but can still be used to spin through the complete folder. From technical side, the full resolution version of the document is only now fetched from the database, which may take about 2 seconds. Navigation to the next page is anticipated by loading that in the background.
a
b
c
Figure 2. Basic features in the viewer to quickly find back relevant documents are pictorial overviews (a) and the possibility for fast flipping through the complete pile of paper using mouse wheel or sliders (b). When a document is called up in full resolution (c) the rightmost pane shows nearby documents and remains a tool to quickly locate other documents by browsing the stack of thumbnails (while the current document remains on screen in full resolution).
126
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
A second provision to aid in retrieving information is the use of context information as a filtering criterion in the viewer (Figure 3). This organization opposes the approach in many user interfaces in which one first has to make a selection according to one criterion and then drill down further, which may require navigating back to a previous level before going down again along some other path. From any level of filtering one can return to presentation of all documents by just one or a few mouse clicks.
Figure 3. One mouse click activates a filter to limit the number of documents presented. The filters in the upper left panel are about discipline and possibly patient contact. The date filter in the central panel and the document type filter in the lower panel may be based on information derived from OCR, which is not completely reliable, but this filtering should be regarded as a “soft” operation to assist in locating a document among many others: one can always immediately return to the overview of all documents.
3.5. High-level Integration and Software Reuse One of the reasons we developed our own document management system was that it was not designed from scratch. It is an extension of a system we deploy for managing general “multimedia” including reference images, video loops, etc [1]. This multimedia subsystem was explicitly designed to function as a technological module within the overall EMR, delegating higher-level organization and policies (such as access control) to that EMR. This separation between technology and principles related to the specific types of data on the one hand, and overall organization and workflow on the other hand, is something we also insist on whenever we buy a commercial system to be integrated into our EMR [2]. This separation has the additional advantage that the document subsystem can be plugged in into another management layer. We also use the principles and technology described here for document management in, e.g., our human resources department.
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
127
4. Experience from Clinical Operations One year after first larger pilot projects, about 90% of our medical users have been started up in this project. Scanning of historic folders is scheduled to continue for a few more months, as currently about a third of that paper has been scanned. The project was not sold to end users as a system to provide new functionality – the initial driver clearly was cost savings, with the result of having all information available in one system a very desirable side effect. Everyone agreed that manpower currently spent on filing or moving paper around, could be deployed more usefully in other tasks to support the medical process. Still, many users were concerned that this system would amount to a step back in service and efficiency. However, acceptance generally is considerably better than anticipated. Users started to explicitly mention the benefits of having the documents always available in the computer system. It already is becoming clear that cost savings are not only in the medical archiving department. For example, support staff at outpatient consultations does not have to prepare the paper folders and bring these to the consultation booths anymore.
5. Discussion and Conclusion Our approach and experience are likely to be influenced by the position of our EMR. Many projects, even as of today, consider document scanning as a “bridge” [3, 4] or a “stepping stone” [5] to arrive at an EMR, even as an “essential early step” [6] in that process. In our situation, in contrast, the EMR was introduced about 15 years ago and was intensively used before we even considered document scanning. Document scanning was instead considered a final piece, a method to complete the transition to full electronic availability of all data in one system. This can be compared to the position described in [7] (our emphasis is more pronounced but that can be expected from a more recent project). One consequence is that document scanning did not influence the design of our EMR, quite on the contrary. In particular we do not use scanned documents to drive processes or to support workflow, which are fundamental functionalities in our EMR but for which we deploy direct electronic and structured data entry. A second consequence is that in our situation historic paper documents tend to be of less importance than they are in hospitals that only now are in the transition phase to an enterprise-wide electronic system. Some of the principles and concepts we started from are not obvious. One of these is the option to go for a centralized scanning service and to adapt the workflows to that concept. Our experience so far only reinforces our decision. In contrast to a remark in [4] (stressing decentralized scanning and rapid inclusion of scanned documents in the system) we believe that, usually, if information is needed immediately it can better just be read from paper. A more relevant aspect in our situation is efficiency. We believe efficiency to be increased considerably by the clear separation between scanning on the one hand, and document indexing and (optional) classification on the other hand. Classification and indexing actions can be performed prior to scanning (by inserting cover sheets or using paper with marks on it) but also after scanning (by tagging documents using a computer GUI). What must be avoided is intertwining these actions, e.g. by having the user first set the type of document in a GUI, then manipulate the scanner for a few pages, and then fiddle with the GUI again. Our process oriented view requires more complex IT support, however.
128
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
We have grown into the conclusion that if one wants to invest in manual operations for classification of documents, it is usually better to shift these to the later stages of the process and have these operations executed in the digital world. For example, attributing a pile of scanned documents to the correct patients using a GUI is likely to take considerably less time than manually printing dedicated cover sheets to control scanning, especially as the computer may already have succeeded in doing part of the work automatically, so residual manual actions are limited or at least made easier because of the hints given by the computer. We do not perform detailed classification of all scanned documents. This is in contrasts with the emphasis in many document imaging projects (see e.g. the remarks on re-designing forms and attaching a bar code to each form in [4] and [5]). Already from the start of our project the decision was made to not invest in manual classification of the historic documents, which raised concerns with many users. However, most users so far seem satisfied with automated recognition of just a few types of documents. For those cases our approach at automation by using simple pattern matching rules using the text recognized by OCR performs better than we hoped for. This lack of insistence on detailed classification may be explained by the fact that the most important recent information was already available electronically. The efforts we spent on providing pictorial overviews and efficient navigation in the viewer are also likely to be a factor. Anyhow, in our experience the need for detailed classification is often overrated. After all, the traditional patient folders were not always indexed into detail either. In many document imaging projects folders are scanned on demand, upon first need [6]. We instead opted for a radical approach in which existing paper files are scanned in bulk in as short a transition period as feasible. It definitely helped that all our operations were already centralized, as were vision and decision power. One motivation was to quickly realize all cost savings from eliminating the traditional archive, which includes reclaiming the floor space for core tasks of the hospital. We observe that newer document scanning projects increasingly follow this approach. At the beginning of this discussion section we positioned document scanning as the final piece in our EMR. Although situating our emphasis, this is an overstatement. A more accurate wording was that this project “accelerates” arrival at the fully electronic medical record. Our physicians realize that as well: whereas we expected resistance against “elimination” of paper, we more often had to explain while we could not immediately provide additional facilities for direct electronic data entry. Although for some applications paper is likely to stay for quite some time (and be scanned), for most of these applications the bottleneck simply is the manpower needed to develop or integrate dedicated modules in the EMR. We are considering design principles that are in-between the ideal of fully structured data capture and management of unstructured data such as scanned documents. In the mean time, we are glad to at least have the kilometers and tons of paper converted into a few tens of terabytes.
References [1]
[2]
E. Bellon, M. Feron, et al. Experience on differences in requirements for managing and integrating reference images and diagnostic images. In: International Journal of Computer Assisted Radiology and Surgery, (Proceedings of CARS 2007, Berlin), Vol.2 - Supplement 1, June 2007, pp. S328-S329. E. Bellon, M. Feron, et al. Integrating multimedia workflow into the EPR. In: proceedings of the 24th International EuroPACS Conference, Trondheim, Norway, 15-17.06.2006.
E. Bellon et al. / Eliminating the Paper Medical Archive by Bulk Document Scanning
[3] [4] [5] [6] [7]
129
H. Rhodes and M. Dougherty. Document Imaging as a Bridge to the EHR (AHIMA Practice Brief). Journal of AHIMA, 74(6):56A-G, June 2003. A. Stewart. One Scan at a Time: Moving Paper to Electronic. For the Record, 19(6):12-15, March 2007. F. Baldwin. Picture Perfect: Document imaging can capture everything a patient record holds. Healthcare Informatics, 21(3):33-36, March 2004. C. Cottrell. Document management: one paving stone in the path to EHR. Healthcare Financial Management, 59(5):84-92, May 2005. J.-T. Lium, H. Lerum, at al. From the Front Line: Report from a Near Paperless Hospital: Mixed Reception Among Health Care Professionals. Journal of the AMIA, 13(6):668-675, Nov/Dec 2006.
130
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-130
The implementation of an Electronic Nursing Record in a general hospital in the Netherlands: Lessons to learn R.VERWEY RNa,1 R.A.B.CLAASSEN RNb M. J.RUTGERS RNc L.P.DE WITTE PhD,MD d a Senior lecturer, Advanced Nursing Practice, Faculty Health and Care, Centre of Research Technology in Healthcare, Zuyd University b Junior lecturer, Bachelor of Nursing, Faculty Health and Care, Centre of Research Technology in Healthcare, Zuyd University c Project manager, uitrol zorg ICT, Orbis Medical and Healthcare group, Maasland Hospital d Lector, Centre of Research Technology in Healthcare, Zuyd University
Abstract. This article describes the implementation of an Electronic Nursing Record (ENR) in Maasland Hospital (Orbis Medical and Healthcare group) in Sittard, the Netherlands. Through analysis of documents, structured interviews and participatory observation, a study was made of the plans prior to the introduction of the ENR, how the process proceeded, which enhancing and constraining factors influenced the process and how the nursing staff experienced the introduction of the ENR. The implementation of the system took place in 2006 and 2007. The selection and design of the system was carried out first, followed by a pilot phase. After thorough review and adjustment, the introduction of the ENR in the other wards of the hospital followed according to plan. The implementation process was carried out by several nurses in different roles (project management, project group members, key-users and teachers). The introduction of the system had two objectives: saving time by promoting efficiency and quality improvement by the introduction of standardization in documentation and the use of nursing care plans. The study indicates, however, that no time-efficiency was achieved by using the ENR so far. This had an adverse effect on the acceptance of the system by the nurses. The nurses were positive about the set-up of the implementation process, especially the contribution of the project group, the key-users on the ward and the resources which were made available (the staffing, external expertise and training). Keywords. Electronic Nursing Record, implementation process, process evaluation.
1. Introduction Nurses in Dutch hospitals are increasingly using electronic records. Not only are smallscale experiments being introduced, but also nurses are using electronic records on a large scale more and more [1]. Relevant to the acceptance and proper use of an electronic nursing record (ENR) is the way the system is introduced in the organization 1 Corresponding author: R.Verwey: Faculty Health and Care, Centre of Research Technology in Healthcare, Zuyd University, Postbus 550, 6400 AN Heerlen, Nederland; E-mail:
[email protected].
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
131
[2]. This article discusses the results of an evaluation study of the ENR implementation process in Maasland Hospital (Orbis Medical and Healthcare group) in Sittard, the Netherlands. Communication with the users is a major factor of success in such an implementation process. Communications between all parties involved in the introduction of the ENR (nurses on the wards, key-users, members of the project group, the project manager and the steering committee) are set down in reports and notes. This material has been used in the survey. Underestimating the time and resources necessary for the implementation of a nursing information system is a common pitfall. This fact is illustrated by an article about a similar implementation process in Oslo, Norway [3]. From this research it became clear that the main challenge for the implementation of an ENR in this hospital consisted of organizing and finding time for the introduction and training of users. Within the Netherlands, hospital-wide introductions of an ENR is known to have been carried out in Tilburg and in Sittard so far. The most recent research in the Netherlands on the use of nursing information systems in hospitals dates from 1997 [4]. Research on comparable introductions of ENR’s in hospitals abroad is written in terms of effects, for example the effects on the registration of caregivers [5], the quality of the documentation and the user acceptance of the system [6, 7]. A review study of the effects of nursing record systems on nursing practice and health care outcomes showed that the introduction of electronic records often did not produce the expected benefits [8]. The involvement of nursing staff in the development of these systems is therefore strongly recommended. One of the conclusions of another study of the definition, structure, design, use and impact of Electronic Healthcare Records was that research specifically aimed at electronic nursing documentation is strongly recommended [9]. Therefore it was decided to link an implementation study to the introduction of the ENR in Maasland Hospital 2. A post-implementation audit after the introduction of a nursing information system should consider the following elements: the implementation process, training, functioning of the system and user satisfaction [10]. This research has mainly focused on the implementation and training. Concerning the functioning of the system and user satisfaction, data are gathered during an analysis of the system and survey of the experiences of the nurses, but these components have not been systematically studied [11]. This study mainly aimed to learn from the findings and to apply new insights in subsequent projects [12]. The main research question was: How has the ENR been implemented? The research included the following sub-questions: • What were the plans at the beginning of the implementation of the ENR? • How is the actual implementation process being carried out? • What were enhancing and constraining factors in this process? • How did the nurses experience the introduction of the ENR?
2
The study was partly funded by a subsidy RAAKpubliek provided by the Stichting Innovatie Alliantie.
132
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
2. Context In the region Westelijke Mijnstreek Zuid Limburg, situated in the south of the Netherlands, a new hospital is being built and is planned to be ready in October 2008. It is a large regional general hospital with all the basic medical specialties. To prepare for the relocation, a number of innovative projects have been initiated, including the introduction of an Electronic Health Record (EHR) and an Electronic Medication System (EMS) with the ultimate objective of achieving a “paperless” organization where ICT supports care and logistical processes. An EHR in SAP (ISHmed) has been chosen, in Germany known as the Med-is Pflegedossier, PIK® [13, 14]. In this system a medical and nursing module is developed. This ENR consists of an anamnesis with questions categorised by functional health patterns according to Gordon [15]. Based on this anamnesis, a nursing care plan is formulated with appropriate nursing diagnoses, nursing outcomes, nursing interventions and schedules. Developments in nursing care are reported in a nursing report. The most important developments in the health of the patient are recorded in a special document called “vital signs”. The ENR was introduced on 15 wards. Each ward has the use of five permanent computers and two laptops connected to the intranet. In the new hospital all rooms will be equipped with bedside terminals. During the implementation process 520 nurses were trained in the use of the system.
3. Method The next paragraphs describe the methods used in the research. 3.1. Literature study A literature study was conducted of several national and international implementation processes of electronic nursing records. Recent (published after 2000) Dutch and English papers held by INVERT, PubMed, Cinahl and ScienceDirect were collected using the keywords information systems, electronic patient record, electronic healthcare record, electronic nursing record, nursing and implementation and the Dutch translations of those keywords. Because no scientific publications on Dutch ENR implementations were found, the search was extended to papers published after 1995. Subsequently sources describing more general implementation strategies were searched [2]. 3.2. Framework for the implementation Grol & Wensing developed a framework for describing a process of introducing an innovation in health care [2]. This framework was used in the labeling and analysis of the results of the study. The components of the framework are a description of the innovation, a characterization of the strategy by giving a description of the interventions (professional targeted interventions, financial and organizational interventions), a description of the participants, their professions, the target group, its
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
133
size and motivation, a description of the implementers, their professions, their authority and ability to lead and finally a description of the frequency of the activities. 3.2.1. Data collection Various methods of data collection were used, namely participatory observation, analysis of relevant documents and semi-structured interviews [16]. 3.2.2. Participating observation Two of the researchers (RV and RC) were involved in the implementation of the ENR, as teachers in the training program and through the participation in the steering committee. Their experiences are stated at the start of this paper. 3.2.3. Document analysis All conferences, meetings and training courses held during the implementation process were minuted. These internal documents were collected. Missing documents were obtained by the secretary of the project office. The relevance of the documents was determined by the extent to which the contents of the document contained information about the research question. Finally, 72 documents were analyzed. These documents were divided randomly between two researchers (RV and RC) who read the documents and collected those fragments which were directly related to the research question. These fragments were labeled. Labels were chosen to fit as closely as possible to the original text of the fragment. The fragments and the matching labels from the two different researchers were merged. Then the fragments (510) were sorted, the frequency of the labels was evaluated and some labels were combined. The core labels were combined to fit into the framework. Where the fragments contained insufficient information to complete all the aspects of the framework, the missing information was obtained during the interviews. Based on the labels and the fragments, a summary was made. 3.3. Interviews Twelve employees who were involved in the implementation of the ENR were interviewed: the management of the hospital, the project manager, a member of the project group and a sample of nine people from the nursing units. The special care wards like the children’s ward and the ICU were excluded. Three wards were randomly selected: one ward from the pilot phase and two wards which were involved in the next phase when the hospital-wide implementation took place. In every selected ward the unit leader, the involved key-user and a nurse were interviewed. Prior to these interviews a letter was sent explaining the purpose and main questions of the research. The interviews took place at the workplaces of the interviewees. Each interview lasted three quarters of an hour. The interviews were recorded on audio cassette. The main findings of the interview were summarized by the researcher who conducted the interview and this summary was approved by the people who were interviewed. The distribution of the interviews between the two researchers was based on chance; only at the interview of the Executive Board were both researchers present.
134
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
Important issues regarding every research question were written down. These issues were compared and summarized for each research question. 3.4. Data analyses The analysis of the documents was carried out first. Then the results were supplemented with the results from the interviews and finally this was compared with the reports from the participatory observations.
4. Results The results gathered are categorized according to the different sub-questions. The plans are presented, followed by the course of the process, the enhancing and constraining factors involved and a description of the experiences of the nursing staff. 4.1. Plans In April 2006 a business case was set up and a project-based organization was created with the objective of achieving a hospital-wide implementation of the ENR before January 2008 [17]. In the business case the necessary preconditions were stated, such as the allocation of sufficient resources (hardware, software, royalties, salaries and training costs), fine-tuning with other critical (ICT) projects, realistic planning and a secure and steady technical landscape (available and reliable). The project staff consisted mainly of nurses (the manager, an assistant, four expert members of the project staff and key-users). In every ward two key-users were appointed. They could spend five hours a week primarily on tasks relating to the implementation process. The expert members were made responsible for the design of the system, the support of the key-users and the agreement between the builders and users of the ENR, and they participated as teachers in the training. The expert member group also functioned as a filter for all the wishes and extensions requested by nurses in the hospital to improve the system. The introduction of the system had two goals: saving time by promoting efficiency and quality improvement through the introduction of standardization in documentation and the use of nursing care plans. It was not only the implementation of the system that was carried out but also the introduction of a new method of working and the “empowerment” of the nursing professionals. The consequences of the introduction were put into words as follows: “The project will have great impact on the working methods of all staff involved. There will be radical changes in the execution of the nurses’ professional duties. For instance the information will be gathered, changed and referred to in a totally different way using the ENR. The second outcome is a change in nursing treatment, namely from more intuitional towards more methodical and systematic”. Prior to the implementation a decision was made to set up cooperation with a college. The involvement of an external party in such a vast project was deemed useful. Teachers and students offered support in setting up the ENR, training during the implementation, coaching the key-users and developing the system further [18].
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
135
4.2. Course The initialization of the project consisted of preparatory activities such as the choice of system, establishment of a project group, exploring the possibilities of the system, further structuring and complementation of the system, preparation of the pilot phase and development of appropriate training. During the pilot phase the ENR was introduced in three departments (oncology, oncological surgery and general surgery). After a thorough review and revision of the training and composition of the project, the hospital-wide implementation started in 2007. The project was introduced on two wards each month, and subsequently introduced on specific wards (paediatric, intensive care and dialysis). Prior to the training, key-users were trained by the project group. The key-users checked whether the capabilities of the system were appropriate for the specific type of patients and situations on the ward. Then the training for all nurses started, followed by the "live stage", in which the ward actually took up use of the system. A member of the project group was present on each ward for two weeks at this stage. In addition, extra staffing was scheduled.
Education program: Methodical nursing and the ENR
Phase 3. Phase 1.
ward
Phase 2.
hospital ward
key-users in the ENR council
ward ward ward
basic education
follow-up
bedside learning
From learning by supply to learning on demand and from formal to informal learning
Figure 1. Training program
The construction of the training program is shown in Figure 1. The basic training consisted of four meetings of 2.5 hours during which aspects of the methodical work and navigation in the system were raised alternately and were applied to ward-specific cases [19]. A few months after the introduction, the “follow-up” (two meetings of four hours) for the key users took place. “Bedside learning”, a custom learning process, started in 2008 once the ENR was being used in the entire hospital (24 hours’ guidance per ward) [20]. The key-users formed an ENR council which together with the project group was responsible for the management, maintenance and updating of the system and for the quality assurance of the standards used therein [21]. During the entire process the status of the introduction was constantly evaluated by all concerned. Logs were kept, meetings were attended where staff members could give their views on the
136
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
implementation of the ENR and extra coaching was offered. The process was characterized by good listening and constant dialogue with the users. During the implementation process new functionalities and improvements were developed and implemented, such as standard nursing care plans, specific anamneses, resignation forms, increasing the ease of use and making links with other systems. 4.3. Enhancing and constraining factors The most frequently mentioned enhancing and constraining factors that played a role during the implementation are presented in Table 1.
Table 1. Enhancing and constraining factors Enhancing factors Unanimously: involvement of the Executive Board and the project group. Distinct communication, commitment and accessibility. Increased workforce and extra time for the key-users. Good staffing during "go-live stage". Competencies of younger nurses on the ward (knowledge of nursing methodology and ICT). Cooperation with Zuyd University. Expertise of the project group. Hospital-wide training (because of the alternation between methodology and "system use"). Development (specific anamneses, introducing standard nursing care plans). Constraining factors High workload, time deficit for adequate documentation (assessment of nursing anamneses and preparation of nursing care plans). Using the system is more time-consuming than paper based documentation (too many clicks, not comprehensive enough). Unclear aims in introducing the system (raising productivity and reducing staffing versus improving quality of care). Lack of knowledge and motivation of some of the nurses. Many changes in the organization in a short time. Too little guidance on the ward after the "go-live stage". Training occurred during the pilot phase because too little practice was offered. Hardware provisions (laptops and connection to the intranet) not sufficient.
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
137
4.4. Experiences The vast majority of the interviewees looked back positively on the introduction of the ENR. But there were differences in the experiences between the three departments. This can partly be explained by the fact that one division belonged to the pilot group. There was much talk about the effects of the introduction of the system (no time gains and quality improvement). Apparently the effect of using the system substantially determined the experience of the nurses. Using the system yielded no time gains because the ENR did not fit into existing workflow patterns and was not experienced as user-friendly. Despite the fact that the expectation of time gains was disproved during the training, the nurses expected this effect at the beginning of the implementation. The introduction of the standard nursing care plans led to a marked quality improvement. Concerning quality, nurses further indicated that they were made more aware of the nursing care by the use of nursing care plans.
5. Discussion, conclusions and recommendations The implementation of the ENR was a large project which was completed within the prescribed period. Looking back there was a positive opinion of the communication with the end-users, the methodology of the project, the role of key-users on the wards and the resources (staffing, external expertise and training) that were deployed. The involvement of the nursing staff in the whole process promoted the acceptance of the system. This confirms the recommendation by Currell and others to involve nurses in the development and implementation of new systems [8]. However, the introduction of this ENR did not produce the benefits expected. In particular, the lack of time gains proved to be a major barrier to the acceptance of the system. Despite the fact that this expectation was disproved during the training, efficiency was seen as an expected outcome of the introduction by the nurses on the wards. Based on these conclusions, it is suggested that the following recommendations are followed before proceeding to an implementation: • analyze the workflow and let the system fit in as far as possible, • implement only a user-friendly system, • ensure speedy access to the system (bedside terminals), and • create consensus between users on the objectives and foreseeable effects of using the system. This research has focused on how the ENR in this particular situation was implemented. It is an example of a subjective evaluation approach [12]. Further, more objective research, for instance by setting up an RCT, is needed to monitor the impact of the use of an electronic nursing record and to determine the effects on efficiency and quality of nursing care.
References [1] [2]
Hilderink H, Goossen W, Epping P. Overzorg Een nieuw fundament voor ICT in de Verpleging. Leidschendam: NICTIZ 2002. Grol RW, Wensing M. Implementatie, effectieve verbetering van de patiëntenzorg. Maarssen: Elsevier gezondheidszorg 2006.
138
[3] [4] [5]
[6] [7] [8] [9] [10] [11] [12] [13] [14]
[15] [16] [17] [18] [19] [20] [21]
R. Verwey et al. / The Implementation of an ENR in a General Hospital in the Netherlands
Wibe T, Edwin E, Husby EH, Vedal T. Implementation of nursing care plan in the Electronic Patient Record (EPR) findings and experiences. Stud Health Technol Inform. 2006;122:309–13. Eurlings F, van Asten A, Cozijn H, Klaassen K, Stokman R, van Valkenburg R, et al. Effects of a nursing information system in 5 Dutch hospitals. Stud Health Technol Inform. 1997;46:50–5. Poissant L, Pereira J, Tamblyn R, Kawasumi Y. The impact of electronic health records on time efficiency of physicians and nurses: a systematic review. J Am Med Inform Assoc. 2005 Sep– Oct;12(5):505–16. Ammenwerth E, Kutscha A, Eichstadter R, Haux R. Systematic evaluation of computer-based nursing documentation. Medinfo. 2001;10(Pt 2):1102–6. Moen A. A nursing perspective to design and implementation of electronic patient record systems. J Biomed Inform. 2003 Aug–Oct;36(4–5):375–8. Currell R, Urquhart C. Nursing record systems: effects on nursing practice and health care outcomes. Cochrane Database Syst Rev. 2003(3):CD002099. Hayrinen K, Saranto K, Nykanen P. Definition, structure, content, use and impacts of electronic health records: a review of the research literature. Int J Med Inform. 2008 May;77(5):291–304. Ball MJ, Hannah KJ, Newbold SK, Douglas. Nursing informatics: where caring and technology meet. 3nd ed. New York: Springer-Verlag 2000. Verwey R. Analyse EVD Maaslandziekenhuis. Heerlen: Hogeschool Zuyd 2007. Burkle T, Ammenwerth E, Prokosch HU, Dudeck J. Evaluation of clinical information systems. What can be evaluated and what cannot? J Eval Clin Pract. 2001 Nov;7(4):373–85. I.s.h.med verpleging. 2006. Available from: URL:http://www.sap.com/netherlands/industries/healthcare/brochures/index.epx. Ammenwerth E, Mansmann U, Iller C, Eichstadter R. Factors affecting and affected by user acceptance of computer-based nursing documentation: results of a two-year study. J Am Med Inform Assoc. 2003 Jan–Feb;10(1):69–84. Gordon M. Verpleegkundige diagnostiek: proces en toepassing. Maarssen: Elsevier gezondheidszorg 2002. Polit DF, Beck CT. Essentials of nursing research: methods, appraisal, and utilization. Philadelphia: Lippincott Williams & Wilkins 2006. Rutgers M. Projectplan uitrol van de verpleegkundige module van het EVD. Sittard: Orbis, Maaslandziekenhuis 2006. Verwey R. Projectplan de Nieuwe Manier van Werken De doorontwikkeling van het EVD, een voorwaarde voor vraaggestuurd methodisch verpleegkundig handelen. Heerlen: Hogeschool Zuyd 2006. Verwey R. Scholing Systematisch handelen / Verpleegkundige methodiek en het EVD. Heerlen: Hogeschool Zuyd 2006. Verwey R. Bedsidelearning; werkplekleren gericht op methodisch handelen en de hantering van het Elektronisch Verpleegkundig Dossier. Heerlen: Hogeschool Zuyd 2007. Rutgers M. De verpleegkundige als sterrolhouder. Sittard: Orbis, Maaslandziekenhuis 2007.
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-139
139
Open Source Electronic Health Record and Patient Data Management System for Intensive Care a,1
a
Jacques MASSAUT , Pascal REPER Intensive Care, Brugmann Hospital, Université Libre de Bruxelles, Belgium.
a
Abstract. Background and objectives: In Intensive Care Units, the amount of data to be processed for patients care, the turn over of the patients, the necessity for reliability and for review processes indicate the use of Patient Data Management Systems (PDMS) and electronic health records (EHR). To respond to the needs of an Intensive Care Unit and not to be locked with proprietary software, we developed a PDMS and EHR based on open source software and components.Methods: The software was designed as a client–server architecture running on the Linux operating system and powered by the PostgreSQL data base system. The client software was developed in C using GTK interface library. The application offers to the users the following functions: medical notes captures, observations and treatments, nursing charts with administration of medications, scoring systems for classification, and possibilities to encode medical activities for billing processes. Results: Since his deployment in February 2004, the PDMS was used to care more than three thousands patients with the expected software reliability and facilitated data management and review processes. Communications with other medical software were not developed from the start, and are realized by the use of the Mirth HL7 communication engine. Further upgrade of the system will include multi-platform support, use of typed language with static analysis, and configurable interface. Conclusion: The developed system based on open source software components was able to respond to the medical needs of the local ICU environment. The use of OSS for development allowed us to customize the software to the preexisting organization and contributed to the acceptability of the whole system. Keywords. database management system, electronic health record, software, intensive care, HL7.
1. Introduction The electronic health record (EHR) becomes increasingly important in modern health care systems. Numerous clear advantages over paper records are demonstrated. Any form of medical record needs to be accurate, consistent, legible, complete, and simply presented [1]. The use of information technology in health care records allows the user to improve the quality of information, conveys accurate information quickly, meets 1 Corresponding Author: Prof. J.Massaut, Soins Intensifs, CHU Brugmann, 4 palce Van Gehuchten, 1020 Bruxelles, Belgium ; E-mail :
[email protected].
140
J. Massaut and P. Reper / Open Source EHR and PDMS for Intensive Care
specific needs, access a patient's data whenever it is needed, and enable the rapid extraction of data to improve overall patient care[2,3]. These advantages of EHR applied also in intensive care were the amount of data to be processed, the turn over of the patients and the necessity for reliability and review processes indicate the use of Patient Data Management Systems (PDMS) [4]. Commercial PDMS exist for intensive care but they lock the users with proprietary software as opposed to Open Source Software (OSS). By publishing source code, OSS allows sharing of software resources and experience [5]. They can also be used in intensive care [6]. To respond to the needs of our intensive care unit and benefit of resources from OSS we developed an EHR system and PDMS based on open source software and components. The aim of that development was also to avoid to be locked with proprietary software and be dependent of costly licenses.
2. Materials and Methods 2.1. Software Design The software used by the system was designed as a client-server architecture running on the Linux operating system (SUSE Linux Enterprise Server 8.0) and access the PostgreSQL relational database (v 7.2). The development of the system was based on the workflow and dataflow observed in our unit and the procedures and documentations already in use. The data were mapped on the relational database. The database structure can be found at: www.openosiris.org/download/OSDMS poster.pdf. The client software was developed in C with the GTK interface library, using a bottomup approach. The software offers the following functions: (Figure 1) 1. 2. 3. 4. 5. 6.
Medical notes captures with patient’s history, observations and treatments, Nursing charts for vital signs, IN-OUT balance, ventilation parameters and settings, Functionalities for administration of medications, Scoring system possibilities for patient’s classification. (APACHE II [7], SAPS II [8]). Reporting at the end of hospitalization in Intensive Care. Encoding of medical activities for administrative and billing processes.
Interoperability between all modules of the software is realized through access to the PostgreSQL database and not the use of local memory in the interface. The software was developed to be open source in all its components and is interfaced with Open Office for reporting. To track run-time errors and achieve sufficient software reliability, we systematically tested all the software with Valgrind, a suite of debugging and profiling tools.
J. Massaut and P. Reper / Open Source EHR and PDMS for Intensive Care
141
Figure 1. Interface and Software Design
2.2. Implementation and software use All the above functionalities were implemented but only the medical part of the application was used. For every new patient, on admission, data have to be introduced in the software using classical medical observations: relevant medical history, previous treatment and chronological history of the actual problems justifying the ICU admission, as well as clinical findings and complementary examinations with specific description of the medical diagnostic. For every ICU day, clinical data on patient evolution can be described with the most important elements of the day: biological and bacteriological results, respiratory and hemodynamic status and results of the last performed complementary examinations. Daily treatment and therapeutic strategy may be prescribed and updated using an integrated care provider order entry. Description of ICU population is necessary to evaluate the patient prognosis and the severity of illness. Comparison between patients needs patient’s evaluation and stratification for study or clinical purpose. It is therefore necessary for the ICU management to score the patients with well admitted ICU scores. For that purpose, APACHE II and SAPS score could easily be determined for every patient on admission and during the ICU stay permitting to stratify ICU population and giving important informations for the patient follow-up and the ICU management. Reporting at the end of hospitalization in ICU is necessary for communication with referring hospital specialists or general practitioners. This allows transferring important follow-up information and enhancing better collaboration between the different patient care teams: in ICU, in the other hospital wards and also at home when the patient leaves the hospital. The automatic help on reporting at the end of the hospitalization enhances collaboration and information transmission of all who are involved in the care of acute patients. Encoding of medical activities for administrative and billing processes can be done with the system. Complete administrative information is important for the general
142
J. Massaut and P. Reper / Open Source EHR and PDMS for Intensive Care
management of care institutions where ICU structures are known to use a lot of personal and financial means: the software allows obtaining, after a minimal time, various information to answer to the questions of the medical authorities inside or outside the hospital. Scientific studies are also enhanced by the possibility of extracting of the database complete data about a specific population and its ICU evolution. 2.3. Hardware Minimum hardware configuration for the system consists of one x86 server with windows PC running virtual network connections (VNC) viewers, but such a configuration does not allow backup and replication. The hardware we used consists in two Intel x86 servers with uninterrupted power supply, one master and one slave to assure the integrity of the database by replication, 14 medical grade panel PCs (Advantek PPC-153m) connected via RS232 medical bus to the patient’s monitoring devices and to the servers via dedicated local Intranet network. The master server runs the postgreSQL database and the client-software that can be accessed through VNC. The slave server is used for replication of the database. The 14 medical grade panels PCs run the client software at the bedsides. 2.4. Communications with monitoring devices and other medical software We planned first to access the data from the monitoring devices of our unit through the RS232 interfaces of the Philips Intellivue monitoring devices at every bedside. That needed complex and specific communication software to be developed and implemented at every bedside. Central acquisition of data using HL7 communication standard with the Mirth HL7 communication engine installed on servers, is an easiest process and a better solution. The data can then be transferred to the postgreSQL database. The Mirth HL7 communication engine can also be used to send clinical data from the database to other medical software or export clinical summary at the end of hospitalization in intensive care. 2.5. Identification, authorization and security Identification and authorization are to be done at the database level with encrypted passwords. Several levels of authorization must include read access only, write access with privilege for prescription or not, and administration of medications. Identification must be repeated at every important access like note writing, prescriptions and administration of medications. Except for local access on private network, database access must be done through secure connections. VNC on windows does not provide such secure access and supplementary software are needed. 2.6. License The code developed for the system was published under the General Public License version 3 at https://savannah.nongnu.org/projects/freeosiris.
J. Massaut and P. Reper / Open Source EHR and PDMS for Intensive Care
143
2.7. Upgrade Before extending his use to 30 IC beds of our institution the system is being upgraded. Principal upgrades includes multi-platform support including Windows Operating System, separation of clinical data from patient identification and administrative data on two separate databases to facilitate extraction of anonymous data for clinical review, research and privacy preservation as proposed in the OpenEHR model[9] (http://www.openehr.org ). New development will use more secure languages: Ada and SparkAda in place of C.
3. Results The PDMS was used in our unit, from February 2004, for the care of more than three thousand patients. The system is accessible at desks or offices through VNC viewers on windows PCs. Its design allowed an access to the database’s functionalities with a high availability level (less than 5 hours of interruption over one year). The system is used on an every day basis for staff discussion using central display and for every patient’s notes and treatments. Indicators were also developed to follow the activity of the unit and are used at regular intervals for evaluation as well as database queries to answer specific clinical question. The use of the system at every bedside through panel PCs was less successful. The panels PCs with fans are noisy for the patients and less robust. The use of open source resources was however effective to customize the solution to ICU medical request and contributed to the acceptability of the software. The PostgreSQL database largely contributed to the overall efficacy and robustness of the system. The use of the C language permits to obtain small response times but limits the portability of the system and complicated the debugging process in this critical environment. For that reason, Valgrind software was used during development period to systematically track run-times errors. The system was well accepted locally for medical activity, but was harder to interface with the information system of the hospital and is to be completed to include all the work at the bedside.
4. Discussion We developed the present software to respond to the needs of our surgical unit, with the hope that this will enhance quality in our unit. In a review of Clinical Informatics in Critical Care, G. Martich describes several reasons to implement information system in intensive care [4]. The first one is that information systems could reduce medical errors and first of all medications errors. The second reason is that information overload is present at point of care in intensive care units. Clinical informatics at the bedside can help to better manage this load. Other reasons are described like necessity to achieve and assess compliance to guidelines and accreditation rules. To be effective to improve outcome, databases should be developed and controlled at the level were change is to occur [10]. Several studies have demonstrated the effectiveness of using relational databases to improve care of intensive care units patients and specially infected patients [11, 12].
144
J. Massaut and P. Reper / Open Source EHR and PDMS for Intensive Care
We decided to base our development work on OSS for three main reasons, first to benefit of the large OSS library and resources, second to avoid to be locked into proprietary software and third to be able to adapt the software to the manual procedures preexisting in our unit. Economical reasons were also present. These reasons are similar to that described by Douglas Carnal. That author described in 2000 that open collaboration over the Internet is changing development methods and that OSS will be a significant part of the Medical Software’s Future [5]. However, Martich’s review of Clinical Informatics in Critical Care in 2004 does not mention any OSS used in Intensive Care and we founded only one OSS specific to Intensive Care well described in the literature [13]. 292 medical projects are available for download on sourceforge.net but only one is directly related to intensive care and available only for the German language. A community of users of OSS in Intensive Care is clearly to be created. Several factors limit adoption of OSS, like limited support and some times insufficient quality [14]. For our application, we used external support for the hardware and internal support for the software. We tried to respect, during development and implementation, a level of quality corresponding to the needs of our environment. Intensive care environments require systems with high availability. The system described here was able to respond to these requirements by the use of dedicated and duplicated servers and the use of dedicated local network. Robustness however was lower at the bedsides on the Panel PCs. Software development and testing for Intensive Care need to achieve high reliability. The C language used to develop the software is unfortunately not by itself a safe language. For that reason, we systematically tested the software with Valgrind, a suite of simulation based debugging and profiling tools. The uses of static analysis of the C code with tools like Splint [15] early in the development process and before compilation, or the use of safer languages like Ada or SparkAda [16] are however better solutions and are used to develop secure systems. Ada and SparkAda, with static analysis, will be used for further developments. Finally, to better respond to the need of the work at the bedsides and better integrate nursing work, the system will be upgraded with flexible, evolving and configurable interfaces. Initially, the lack of module designed to communicate with other medical software and applications was a limitation of the system. The development of communications using the HL7 standard with the Mirth HL7 communication engine can solve this problem and facilitate the integration of the PDMS with other medical software and applications.
5. Conclusion The developed system based on open source software components was effective and able to respond to the medical needs of the local ICU environment. The use of OSS allowed us to customize the software to the preexisting medical organization of the unit at low cost and contributed to the acceptability of the whole system. The system needs however further design and development to better integrate the work at the bedside and communication with other medical software and applications.
J. Massaut and P. Reper / Open Source EHR and PDMS for Intensive Care
145
References [1] [2]
[3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]
[14] [15] [16]
Bradbury A, Computerized medical records: the need for a standard, J. Am. Rec. Assoc. 19(3) (1990), 25-37. Collins B, Wagner M, Early experiences in using computerized patient record data for monitoring charting compliance, supporting quality initiatives and assisting with accurate charging at Allina Hospitals & Clinics. Int. J. Med. Inf. 74(11-12), (2005), 917-925. Elliot B, To computerize or not to computerize the patient care record: that is the question. Del. Med. J. 74(11) (2002), 435-441. Martich G, Waldmann C, Imhoff M, Clinical Informatics in Critical Care. J. Intensive Care Med. 19 (2004), 154-63. Carnall D, Medical software’s free future. BMJ, 321(7267) (2000), 976. Massaut J, Reper A, Reper P, Open source software can also be used in intensive care. Intensive Care Medicine, A 20070 S50 0180 (2007) Knaus WA, Draper DP, Wagner DP, Zimmerman JE, APACHE II: A severity of disease classification system. Crit Care Med, 13 (1985), 818-829. Le Gall JR, Lemeshow S, Saulnier F, A new Simplified Acute Physiology Score (SAPS II) based on a European/North American multi center study. JAMA, 270 (1993), 2478-2486. Kalra D, Beale T, Heard S, The openEHR Foundation. Stud Health Technol Inform, 115 (2005), 15373. Clemmer P, Monitoring Outcomes With Relational Databases: Does It Improve Quality of Care? Journal of Critical Care, 19, No 4 (2004), 243-247. Evans R, Pestonik S, Classen D, et all, A computer assisted management program for antibiotics and other anti-infective agents. N Engl J Med, 338 (1998), 232-238. Burke J, Pestonik S, Antibiotic use and microbial resistance in intensive care units: impact of computerassisted decision support. J. Chemother, 11 (1999), 530-535. Kropyvnystskii I, Sauders F, Schierek P, Pols M, A computer system for continuous long-term recording, processing, and analysis of physiological data of brain injured patients in ICU settings. Brain Inj, 15(7) (2001), 577-83. Sfakianakis S, Chronaki C.E, Chiarugi F, Conforti F, Kateakis D.G.: Reflections on the Role of Open Source in Health Information System Interoperability. Methods Inf Med, 46 (2007) Suppl1:50-60. Evans D, Larochelle D, Improving Security Using Extensible Lightweight Static Analysis. IEEE Software. January/February (2002), 42-51. Hall A. and Chapman R, Correctness by construction: developing a commercial Secure System. IEEE Software. January/February (2002), 18-25.
This page intentionally left blank
Part Three Technical Reports Related Papers
This page intentionally left blank
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-149
149
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 a, E. DE CLERCQ b, V. VAN CASTEREN c G. THIENPONT d, M.F LAFONTAINE e, G. DE MOOR f a ProRec-BE & EuroRec b Ecole de Santé Publique, UCL, Belgium c Wetenschappelijk Instituut Volksgezondheid, Belgium d RAMIT vzw, Belgium e Wetenschappelijk Instituut Volksgezondheid, Belgium f Department of Medical Informatics and Statistics, Ghent University, Belgium
Abstract. The Belgian National Health Insurance Institute (NHII) and other Healthcare Authorities intend to improve the quality of care through promoting clinical pathway driven care and by optimising cooperation between the responsible primary care physician and the diabetologist. Patients and healthcare professionals are granted some (financial) benefits when meeting the conditions defined in a mutual agreement. This article describes the conditions and the functional requirements to be met by an EHR to enable and to maximise the benefits of a clinical pathway driven patient care to a specific group of diabetic type 2 patients, based on a mandate issued by the NHII. The generic and specific functional requirements are then translated in test criteria for certification and prioritised in an implementation plan. Keywords. Primary health care, computerised patient records, medical records, clinical pathways
1. Introduction The Belgian National Health Insurance Institute (NHII) has decided to actively promote, for chronic patients, care in accordance with national guidelines and as much as possible compliant with international guidelines. This decision was taken in consensus with the different stakeholders, more particularly with the involvement of representatives of the healthcare professionals.[1] The NHII defined financial grants for the participation of healthcare professionals and some benefits for the patients when initiating a specific clinical pathway approach for a particular group of patients, provided that some conditions were met, more especially periodic reporting and a minimal number of patient contacts with the patient’s coordination primary care physician and diabetologist.
150
J. Devlies et al. / The Use of a Compliant EHR
The periodic reporting will be used loco-regionally for peer reviewing and to enhance professional care as well as patient care support. The NHII1 mandated a group of experts with specific expertise in public health and in the use Electronic Health Record (EHR) systems to investigate and to report on the impact of such an approach on the EHR systems themselves as well as on the efficiency of a clinical pathway based provision of care [2]. The mandate focused on the General Practitioners as they are the main holders of the clinical charts and at the same time the initiators of the clinical pathway agreements. This focus on the General Practitioners fits with the system of certification of EHR systems applicable in Belgium since 2002 and compliant with initiatives at European level [3-7]. The domain of application addressed in the mandate is limited to a very specific group of patients: the diabetic type II patients with two injections of insulin a day or the patients for whom an insulin treatment has been started or ‘considered’, excluding some high risk patients as e.g. pregnant diabetics2. It is important to highlight that this advice – at least for the proposed criteria for certification of a compatible EHR system – only covers the issues required for a “NHII diabetic care pathway” meeting the expectations of that NHII (generic issues as well as the specific ones). The recommendation of the Working Group did not have the ambition nor the mandate to address the specific issues related to the complete diabetic “type 2” patient population. It is expected, however, that the recommendations are generic enough for such extension. In the near future, NHII care pathways should be extended to other chronic patients (other types of diabetic patients, patients suffering from renal failure, etc.) [1]. This paper investigates key issues of the experts’ technical report [2].
2. Methodology It appeared to be important to avoid the proliferation of incompatible clinical pathway EHR implementations. It has no sense to develop different technological IT approaches for each different clinical problem addressed. The Working Group therefore defined from scratch a theoretical and generic model to investigate the impact of a clinical pathway driven care on the EHR (or vice-versa) in accordance with the requirements to be met by such an EHR to support such a clinical pathway driven approach. The Working Group subsequently defined the more specific issues related to the target population. The Working Group chose the option of a gradual implementation of clinical pathway driven EHR systems. One of the main reasons is that actually an important lot of “certified” EHR systems are “not at all” able to implement the complete path. The option was also taken, from the start, to translate the requirements in verifiable granular “certification criteria”, in analogy to the existing Belgian and EuroRec certification criteria for EHR systems [3, 5-7].
1 2
More especially the “Quality and Research” department of the NHII, chaired by Dr. Jean Paul Dercq This limitation to a very limited Group of patients might put the initiation of care path driven care at risk.
J. Devlies et al. / The Use of a Compliant EHR
151
3. Definitions The authors identified and defined, for the purpose of these recommendations, a number of concepts or definitions, starting from a clinical care guideline, a clinical care protocol, a clinical care path over a clinical care course to a clinical care planning3. Clinical care protocol or care protocol: the transcription of a (clinical care) guideline (related to a specific problem or issue) in concrete actions or care services to be performed at defined intervals, with a goal to be reached and with a number of conditions to be met. Clinical care path or care path: clinical care path assigned to an individual patient. A care path can be an exact copy of a care protocol, made applicable to a given patient. A care protocol can be transformed in a more personal, more individual care path, including e.g. “personal” goals to be reached. NHII clinical care path or NHII care path: care path, possibly granted from the NHII with benefits for the patient as well as for the involved healthcare professionals, provided that some conditions are met. Clinical care course or care course: the collection of actions or “services” provided to a particular patient as part of an activated care path. A care path focuses on the standard set of services, provided or still to be provided to a patient and related to a given health care element.4 A care course focuses on the services effectively provided to a given patient as part of an activated care path. The authors want to highlight that both the concepts of care path and of care course fit well with the concept “care approach” or “health approach” as described and used in Belgium as structuring element for the certification of EHR systems since 2005 [4]. Clinical care plan or care plan: a patient oriented chronological list of defined actions or services according to a care path activated for that patient. More than one care path might be “in use” for the same patient. In such a case we have at patient level a care plan, being the fusion of actions or services listed in each of the care paths. The most stringent and the most ambitious goal should be applicable for such given patient.
4. Principles for clinical care path based care Hereby some considerations and principles regarding clinical care path based provision of care in general (not specifically related to the actual use case of the NHII Care Path for some diabetic patients): 1. Care protocols and care paths are in principle related to one health issue. That health issue may be one or more diagnostic statements with one or more complications. That health issue can be a pathology, a diagnosis or any other possible condition of the patient, e.g. a postoperative status. 2. Several care paths can be simultaneously active for the same patient. 3
Care guideline, care protocol, care path, care course and care planning can be used as well. Roughly said, in Belgium, a Health Care Element is a patient’s health issue for which a service is (has been / will be) performed by a health professional [4]. For reader’s sake, we will only use the term “health issue” further in the text. 4
152
J. Devlies et al. / The Use of a Compliant EHR
3.
4.
5.
6.
7.
Initiation of a care path requires a positive decision by a responsible healthcare professional and the approval by the patient. There can’t be something as an automatic or enforced enrolment in a care path driven provision of care, e.g. based on the presence in the record of a particular health issue. Initiation of a care path for a patient results in a number of actions, services, examinations or tests to be performed – conditionally – and with a predefined frequency. Monitoring the effective provision of these actions and services and alerting the responsible healthcare professional on possible deviations from the care plan resulting from care path can be done in a more efficient way by using EHR systems. Care protocols and subsequently care paths will surely evolve over time more especially regarding the kind as well as the frequency of the actions and services listed. Version management of the care protocols as well as update facilities of the care path based care plan is therefore required. The health added value of a NHII care path does not differ from that of a “free”5 care path. The EHR holder should not be allowed to abstain a patient getting care based on a care path, simply because that patient did not (want to) subscribe a NHII care path or did not meet some administrative criteria for such a care path support. The initiation of a NHII care path encompasses a number of administrative issues to be addressed by the EHR system e.g. the agreement on itself, the presence of a Global Medical Record6 for that patient and the annual export of some specific data for peer reviewing.
5. A generic digital model for clinical care pathway driven care A digital (clinical) care path encompasses a number of functions. These functions do not differ between a NHII care path and a free care path. 1. The initiation of a care path for a given patient and the registration of that care path in the EHR of the patient. The initiation of a care path requires a decision and an action by the responsible healthcare provider based on a personal evaluation of the health status of the patient, compared to the inclusion criteria of a candidate clinical care protocol, eventually suggested by an enabled EHR system or by an external functionality “detecting” its applicability for that patient. Such an initiation of care paths requires some specific functions and databases: • language independent identification of the different care protocols • registration and management of a care team of involved healthcare professionals • registration of consents and/or refusals by patients, including documenting the reasons 5 Based on a personal agreement between a professional healthcare provider and a patient, without special benefits or grants from the Insurance institutes. 6 The Global Medical Record is based on an agreement between a primary care physician and a patient, resulting in a centralisation of all / most care related information and documents.
J. Devlies et al. / The Use of a Compliant EHR
•
153
registration of the option taken by the responsible healthcare professional not to initiate a care path for patients triggered as eligible, documenting the reasons why not included.
The latter function, intelligent detection or triggering of patients candidate to a care path, developed as an internal function of the EHR system or offered as an external or plug-in functionality, checks individual patient data, either at request of the holder of the EHR or fully automatically, at the start of a patient contact. Such triggering is also possible at practice level, independently from any contact. Triggering applications should be subject to quality control and certification. Automated detection and/or monitoring of care path patients is frequently hampered by the absence, at least in a computer interpretable form, of essential data elements in a way that no conclusions can be made. Some examples of problems encountered: • The absence in the coding schemes ICPC2 or ICD10 of a specific code for a diabetes type 2 is a perfect example. The disease does simply not exist as such in these international coding schemes. • Quite some EHR systems do not have dosage schemes enabling the system to detect patients with specifically two insulin injections a day. • Most EHR systems do not offer the possibility to register the absence of signs or particular diseases or conditions. Such “negative registrations” are nevertheless important for a computer driven evaluation of patient data. These “structural” problems are aggravated by the “incompleteness” of most of the patient records. It is expected that the “care path approach” will result in updating and completing these records, in order to get the full added value offered by the application. The same effect has been experienced when offering patient summary services. A “free” care path offers the same health added value without any administrative constraint or obligation. No “request”, no formal commitment, no report nor specific data export are required. There is neither any limitation on what kind of patients can be included. A simple agreement between patient, general practitioner and specialist will do it. There are then on the other hand, no financial or other profits for the patients or the involved healthcare professionals. 2.
Follow-up and monitoring of the care path patient using a care path control file. Providing care based on a care path means: • Providing planning and reporting services to a patient, by the responsible holder of the patient record or by third parties in a multidisciplinary care team; • Achieving individually predefined goals for the patient; • Considering the inclusion and exclusion criteria, in accordance to a “standard” care protocol made applicable to the patient.
154
J. Devlies et al. / The Use of a Compliant EHR
It is theoretically possible but very unlikely to manage care in a way compliant with a care path without both a good structured patient record and an active IT support. This is even more the case with different simultaneous (and individualised) care plans. In order to realise such an efficient and effective care path support of the care we need: • A consensus based structured care path steering file, with version management and endorsed by an “authority”; • Coded identification of all the services and examinations mentioned in the care path steering files and to be used in the EHRs - agreed coding tables are not available for most of these services and examinations; • A tool to personalise care path steering files by adapting the goals to be reached and/or the frequency of the services. 3.
Building and implementing an individual care plan. The individual care plan is the result of the interaction between the content of the EHR of a patient and one or more care paths applicable to that patient. Fulfilling an in principle multidisciplinary care plan requires also a large set of data exchange files syntaxes defined. Care path based management of patient data requires also specific viewers and even specific data capture interfaces as well as the linkage of the services (provided and planned) to the health issue justifying the care path. The latter is similar to the health issue (Health Care Element) links as foreseen in the Belgian certified EHR systems for General Practitioners.
6. Requirements specific to a NHII Diabetic Care Path An NHII Diabetic Care Path enabled EHR system needs to offer a number of additional and specific functions in order to favour that care path driven provision and monitoring of the care: • Control on the insurability of the patient. It has no sense to initiate a NHII Diabetic Care Path for patients that are not insured. It is obviously always possibly to switch towards a “free” care path when a started NHII Diabetic Care Path does not meet the requirements to be granted some advantages by the NHII. • To produce, to transfer and to manage the “commitment” between the involved healthcare professionals (general practitioner holder of the GMR – Global Medical Record - and diabetologist) and the Insurance institute or sick funds. This commitment should preferably be an electronic document. The advice of the experts clearly affirms that no paper based procedure should be imposed to any healthcare professional. • To extract and report some care and patient health related data to local or regional entities for peer reviewing, quality promotion and “research” purposes, respecting legal constraints.
J. Devlies et al. / The Use of a Compliant EHR
155
An NHII Diabetic Care Path should, regarding nature and frequency of the services to the patient, not differ “clinically” from a so called “free” diabetic care path, which means without the advantages offered by the NHII. An NHII recognised and supported Diabetic Care Path can, of course, preclude that some selection criteria (inclusion as well as exclusion criteria) are met. • The inclusion criteria are, as presently defined by the NHII and hereby summarised: o Diabetes Mellitus type 2 with 2 insulin injections a day o Diabetes Mellitus type 2 with a maximal oral antidiabetic treatment and for whom starting an insulin based therapy comes under consideration or has been started recently • The actual exclusion criteria for a NHII supported care path are: o Diabetes Mellitus type 2 with 3 or more insulin injections a day o Diabetes Mellitus type 1 patients o Female diabetic patients with a pregnancy induced diabetes o Pregnant diabetic patients (patients with a known Diabetes Mellitus type 2) o Diabetic Mellitus type 2 patients with a child wish • Some of the criteria listed above are difficult to formalise or are temporarily patient conditions that aren’t always registered or coded correctly. There is no code available in the international coding schemes (e.g. child wish). Assisted or even more automated screening of patients regarding inclusion or exclusion from a NHII Diabetic Care Path are therefore difficult, at least as long as these problems of identification of patient’s conditions aren’t solved. • Screening and selection of a patient is also difficult on incomplete patient files, e.g. patient files without even a diabetic diagnostic statement recorded. Triggering requires in such a situation indirect signs to build on, e.g. lab and biometric data or even medication data, in order to identify patients candidate to an NHII Diabetic Care Path. The flow charts in figure 1 and 2 illustrate the “detection” or “identification” of patient’s candidate to an NHII Diabetic Care Path. A similar flow chart without the limitations specific to a NHII care path has been documented in the original advice, available on the web site of ProRec-BE: http://nl.prorec.be/p_images/prorec/File/ Advies%20Diabetes%20Zorgpad_WIV%20(def%20)%2020080624.pdf An important remark regarding the “mandatory” export of patient and patient care related data: this export should commit strictly and professionally to all the privacy rules, considering that it’s use for research purposes can’t be considered as part of the care as such and thus not as part of a non-explicit agreement of the patient. The simple fact that a NHII Diabetic Care Path has a kind of official endorsement does not justify deviations from the strict rules regarding sensible data security and privacy.
156
J. Devlies et al. / The Use of a Compliant EHR
Yes 1. Is there a registration of the absence of diabetes for this patient?
No
Yes
2.Is there a registration of an NHII care path with status "not applicable" , "can not be activated", "withdrawn", "terminated"?
Note: the user can always explicitly ask the system to carry out a screening
No
3. Has a NHII care path been recorded with a status "refused" by the patient, by the care supplier or by the sick fund?
Yes
General Practitioner's decision
Note: the user can always ask the system to carry out a new screening possibly followed by a new attempt to incorporate the patient in a care path
No
End search
Yes 4. Has a NHII care path been activated = selected with a status "activated"?
No
5. Has a NHII care path been selected with a status "eligible", "requested", "approved"?
Yes
Monitoring patient / care path
No Yes 6. Is one of the possible contra-indications for the NHII care path registered?
Note: exclusion criteria (pregnant woman etc.)
General Practitioner's decision
End search
For exclusion and/or inclusion criteria regarding a specific care path, e.g. diabetes - see figure 2
Figure 1. Scenario of screening NHII diabetic care path
157
J. Devlies et al. / The Use of a Compliant EHR
Yes
Yes
7. Is there an insulin therapy?
i. Is there a daily scheme ?
No Yes
No
More than two administrations per day?
Yes
8. Is there an orale antidiabetica therapy?
"No insulin daily treatment scheme"; care path probably not applicable
No
No
Yes
Code of diabetes in the record?
Yes One administration per day?
Beslissing Huisarts Beslissing Huisarts General Practitioner's decision
“Diabetic patient not qualified for a NHII care path"
Max doses?
No
einde End zoektocht search
Patient does not suffer from diabetes
No
Yes
No
General Practitioner's decision General Practitioner's decision End search
Yes
Insuline started early (age < 35)?
Probably not applicable
No
End search
Oral anti-diabetic drug (preceding insuline)?
Yes
Probably diabetic patient type 2, eligible for a NHII care path.
General Practitioner's decision
General Practitioner's decision
End search
End search
No Probably diabetes type 1
“Diabetic patient not qualified for a RIZIV care path" General Practitioner's decision End search
Diabetes Type 2 code (ICPC:T90) (ICD 9: 250.x0 /250.x2) (ICD 10: E11/12/13/14)?
Yes
No “Probably diabetes type 1”
“Diabetic patient not qualified for a NHII care path"
Probably diabetic patient type 2, eligible for a NHII Beslissing Huisarts care path.
General Practitioner's decision
General Practitioner's decision End search
End search
Figure 2. Scenario of screening NHII diabetes care path - Exclusion and/or inclusion criteria regarding a specific care path
7. Requirements translated in certification criteria to be met by NHII enabled EHR systems As indicated above, it does not seem reasonable to manage care pathway driven provision of care and to commit to the requirements of the NHII, e.g. regarding reporting, without using an enabled and preferably certified EHR system. The functional requirements for such a system have been classified in coherent functional sets, listed hereafter (and then coded and translated in criteria for certification): 1. Administrative management of the care protocols and care pathways themselves within the EHR system, more especially the list of possible care paths, the care path steering files, the initiation and personalisation of applicable care paths for a given patient, linking care services and care path to the addressed health issue, version management of the care paths, the care path status management (see table 1), care and history of the selected (active) care paths. 2. Services related to the production and management of the electronic and eventually paper based ‘agreement’, confirming the commitment of the patient, the general practitioner, the specialist and the healthcare insurance or sick fund to conform to a particular care path or care protocol. This includes checks on insurability, on the ‘therapeutic link’ between care providers and the patient, on the pre-existence of a similar care path agreement.
158
J. Devlies et al. / The Use of a Compliant EHR
3.
Generic functional services, not specific to a NHII supported care path: checking the presence of the appropriate diagnosis or health issue linked to the care path, management of the consent or refusal by the patient as well as a refusal by the healthcare professional to start a care path suggested by the triggering or selection routine. 4. Specific data gathering and registration requirements for the EHR system used, such as “child wish”. 5. Detection and triggering services related to any care path and/or more specifically to a NHII Diabetic Care Path, at patient level as well as at practice level. 6. Export and reporting services more especially the annual mandatory export of care and patient health related data, the administrative management of this reporting, the baseline export as well as the security and privacy issues related to that reporting to parties not directly involved in the care given to the reported patient. Attention is given to the content and syntax of the messages too. 7. The care path driven follow-up of the effective care with the possibilities for personalisation of the care path, the care path oriented views on the patient data, the care path oriented data gathering, production and management of the individual care plans, the data exchange services with the other involved care team members and the ongoing monitoring of the care plan based on services provided and planned again. Up to 108 functional statements or test criteria were selected (at least in the actual version of the recommendation). The recommendation is of course subject to regular update, e.g. on changes in procedure. Table 1. Care path status Nr
Status
Comments
1
Not applicable
For instance, non diabetic patient
2
Eligible
Approved by the care giver
3
Activated
Approved by the patient (and the care giver). At this stage, a team has been set up and we have started a care course (or health approach)
4
Requested
A request has been sent to the NHII
5
Approved
Approved by the NHII
6
Withdrawn
Interrupted
7
Terminated
Normal end
8
Can not be activated
For instance for patient not related to a sick fund
9
Refused by the sick fund
10
Refused by the patient
11
Refused by the care supplier
Note: status 4, 5, 8 and 9 are specific for NHII care paths
J. Devlies et al. / The Use of a Compliant EHR
159
8. Phases of Implementation The requirements and functional statements or test criteria were classified in implementation phases, not only because none of the systems are able to implement this complete functionality at once, but also because some functions require an important pre-investment in semantic and syntax related issues. The experts defined, considering the Belgian context [3,4] of implementation and European Certification initiatives [5-7], three important phases for the project, based on the following functional classes: • The management of a care path within an EHR system: all the administrative and regulatory aspects of an NHII supported care path and the required reporting. These functions can be realised quite quickly by most of the systems, provided that some initial investments are done. • The intelligent detection and triggering of the patients candidate for a diabetic care path in general and more especially for a NHII Diabetic Care Path. These functions are very demanding regarding standardisation of the EHR systems at content level as well as at structural level. They also require unambiguously and clearly defined computer interpretable inclusion and exclusion criteria. • Implementation of this part as an end stage of development care path oriented systems seems more realistic. The need for this kind of detection or triggering will increase with the number of possible free or NHII care paths available for care and patients. • The effective provision and management of care conform to a care path and based on a care path steering file interacting with patient data and guiding that provision of care, specifically applicable data entry and data display facilities. The specific data entry and more especially the data display facilities can be realised quite quickly, being similar to the planning data and health approach related data representations required since 2003 and 2005 for the certification of Belgian EHR systems for General Practitioners. • Figure 3 overview of the various functional components of a NHII care path.
Figure 3. NHII Diabetic Care Path Functional Components
160
J. Devlies et al. / The Use of a Compliant EHR
The working group finally listed the functional test criteria into three chronological phases with for each criterion a status M (mandatory), O (optional) or L (later) within that phase of implementation of the NHII Diabetic Care Path functionality in the Belgian EHR systems for General Practitioners. Phase 1 requires, as indicated before, the preliminary realisation of a very important Phase 0 of the project. Phase 0 includes not only semantic and syntactic fundamental investments but also some “generic services”: server with insurability data, care team management services, authorisation servers with existing active care path agreements, patient and healthcare professional identification services, document validation services etc… The next figure (figure 4) shows a snapshot of some criteria with their status and implementation phase defined.
Figure 4. Some functional test criteria with implementation phase and status
A concrete implementation plan, covering the whole project, has still to be discussed with most of the stakeholders on the field. It is generally expected that the implementation of the full project will take four to five years, provided that enough early attention is given to the preliminary phase 0.
9. Conclusions 1.
2.
3.
Care pathway supported care requires a very precise definition of the target patients. This means very precise and computer interpretable inclusion and exclusion criteria. It also requires the presence of the required patient data into the EHR of the patients and very clear and enforceable conventions between the involved health care professionals. There are arguments in favour of a common “external” application (plug-in) shared between the different EHR systems in order to facilitate and improve consistency and cost efficiency of the care path driven provision of care. Each EHR system can develop its own integrated care path driven support system. The maximal implementation of an automated inter-professional care path driven support of the individual care requires: • The availability of a structured care path steering file. • The use of a highly structured EHR system offering the possibility to link health services to health issues. Significant efforts have already been done in Belgium [4].
J. Devlies et al. / The Use of a Compliant EHR
161
•
4.
5.
A maximal use of semantic standards, even more when using plug-in applications. An important number of these “semantic standards” are still not available. • The availability of a fully fledged data exchange platform, not limited to the general practitioners but including all involved stakeholders (paramedics, sick funds, hospitals and the specialists within hospitals). The implementation of a care path supported provision of care will not be realised at once. The working group defined a route of stepwise implementation, obviously each time depending on the results of the investments in the preconditions and the availability of modules to the market. The implementation of a care path supported provision of care should consider that, from the start, patients may have more than one health issue to be treated. This means that several care paths could need to be merged into one patient oriented care plan.
Acknowledgments The Working Group was funded by the Belgian Health Insurance Institute (RIZIV/INAMI)
References [1]
Nationaal Akkoord Geneesheren – Ziekenfondsen van 20 december 2007, more especially point 10. http://www.riziv.fgov.be/care/nl/doctors/general-information/agreements/2008/pdf/2008acc.pdf [2] De Clercq E, Devlies J, Van Casteren V. Implementatie Digitaal Diabetes Zorgpad - Technologische aspecten: vereisten ter hoogte van het EMD, project financed by the Belgian National Health Insurance Institute, Scientific Institute of Public Health ed., Brussels, 2008, 113 pp. Technical Report D/2008 /2505/36 [3] Federal Public Service for Health, Food Chain Safety and Environment – Health informatics & Telematics Unit. Homologation de logiciels de gestion de dossiers patient. www.health.fgov.be/telematics. (accessed June.2007). [4] De Clercq E, From a conceptual Problem-Oriented Electronic Patient Record Model to Running Systems: a Nationwide Assessment. International Journal of Medical Informatics. 2008, 77(5):346-53 [5] Leavitt M., De Moor G. EHR Certification: Global Issues, World of Health IT 2007 Conference & Exhibition, Vienna, Austria, 22 to 25 October 2007 [6] De Moor G. – Improving the quality of health record systems. eStrategies, November 2007: 28-29 [7] De Moor G. – Interview with EuroRec President Georges De Moor. European Parliament Magazine, September 24, 2007: 109
162
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-162
Health Data Exchange, Health Data Sharing and Decentralised Clinical Data Collections – Recommendations from a Belgian expert group Jos DEVLIESa, Georges DE MOORb, Etienne DE CLERCQc, André VANDENBERGHEd a The EuroRec Institute, Ghent b Dept.of Medical Informatics and Statistics, Ghent University, Ghent c Health Systems Research, Université Catholique de Louvain, Brussels, Belgium d Centre Hospitalier Universitaire de Charleroi, Charleroi, Belgium
Abstract. The Belgian Federal Health Authorities are willing to redefine their eHealth vision and to reformulate their strategy in consensus with healthcare professionals and other domain experts. The National Health Insurance Institute ordered end 2007 a study to a group of experts1, representing the majority of the eHealth stakeholders. The aim of the study was to define the strategy to be followed regarding health data exchange, data sharing, decentralised clinical data collections and Electronic Health Records. The experts issued, June 2008, a description of the current standing regarding nationally available (or to be made available) services as well as a set of priorities (structural and technological ones) for the coming years. This paper presents the experts’ recommandations and some translated excerpts of their report. Keywords. Health information policy, eHealth
1. Mission statement Based on a convention between the “vzw MIM” (Belgian Medical Informatics Association) and the RIZIV (Kijksinstituut Ziekte en Invaliditeits Verzekeringen), it was the intention to formulate proposals to the National Commision of Physicians concerning projects / developments regarding the exchange of medical messages and the decentralised health record for documents and medical data.
1 Members of the MIM-experts’ Group: C. Brecht, E. De Clercq (co-president), B; Debande, K. De Bock, G. De Moor (co-president), J Devlies (redactor), D. du Boullay, T. Fiers, P. Jongen, M. Nyssen, T. Putzeys, R. Van de Velde, A. Vandenberghe (redactor) and M. Verbeke. The work was coordinated by the MIM (the Belgian Medical Informatics Association), JP Dercq and R. Goetschalkx (INAMI – RIZIV). Report excerpts were translated by G. Ruyssinck. This work has been funded by the Belgian Health Insurance Institute (INAMI / RIZIV)
J. Devlies et al. / Recommendations from a Belgian Expert Group
163
The issue results from topics 3 and 4 of an assignment by the same National Commission: • “Propose a technical solution making a generic tool available to the phycisians and a secure bidirectional communication, which takes into account the probative value of documents”. • “[Support] The development of Care-networks allowing general practitioners, specialists in or outside a hospital and other health professionals to exchange information about their patients in a bidirectional way”. During a first working group meeting (13/12/2007), the first issue of the assignment was slightly re-formulated where the second issue was more specifically defined: • “Propose a technical solution available to general practitioners and specialists for a secure communication between them.” • “[Support] The development of Care-networks allowing general practitioners, specialists in or outside a hospital and other health professionals to exchange information about their patients in a bidirectional way: o a. documents o b. structured data.” The convention specifies a number of assignments or approaches that should be respected: • An inventory of “existing” solutions and solutions “under development”; • Write out a series of functional scenarios with the possible technical options that should / could be included, whereby: o Efforts should be made to harmonise the solutions / standard solutions; o Taking into account the (existing) services needed to identify the care providers and management of access rights (BeHealth / eHealth platform); o Solutions are proposed to: Manage the (therapeutical) relationship physician – patient; Manage the approvals (informed consent) of the patients; Assure the medico-legal weight of evidence of the documents, with emphasis on the electronic signature; • All this happening in consultations with the following structures: o e-Care (INAMI – RIZIV project) o Commission for the Protection of the Private Life o BeHealth / eHealth platform The report of the introducing meeting on the RIZIV on 28 November precises the projects “medical automatisation” for which advice is asked to the group experts:
164
J. Devlies et al. / Recommendations from a Belgian Expert Group
• •
Messages with identified care providers as addressees; Non Addressed Messages / Decentralised Records.
During the consultation with the constituents it was confirmed that the assignment/the development of the record must fit in with in a context of data exchange between care providers within the care processes. Data exchange, concerning medicoadministrative data, between care providers and the insurance companies as well as between care institutions and insurance companies is not the focus of this workgroup. This does not mean that suggestions formulated by this working party do not also influence that specific message traffic. Thus must be avoided that basically several, or even contradictory options would be taken. Although the assignment precises clearly that the assignment involves also other health professions the task must be interpreted in its context of origin: the national Commission physicians - health insurance funds. Recommendations concerning those other health professions mainly involve the exchange of patient data between physicians and those other professions, and not particularly all needs specific to those health professions, among others concerning the mutual data exchange. Without compromising the importance of the personal health record and its coordination with the professional medical record, it is being assumed that this personal health record does not make part of the assignment. What will be discussed, however, is the message exchange between care providers and insurance companies preceding the process of care giving and contributing considerably to an administrative simplification of the exercise of the profession, e.g. applications for reimbursement of medical services and the management of their respective authorizations issued by the medical employees of the insurance companies. For a good understanding of this document, the acronym EHR is used for each “Electronic Health Record”, meaning both the medical record of the general practitioner or the ambulatory specialist and the medical record within a hospital. That latter can be “part” of a global health record or of a departmental health record system. In this paper we shortly introduce some Belgian contextual issues followed by the recommendations of the experts. In appendix A, we give an overview of the possible telematics services to be situated in the field of both intra-professional and interprofessional exchange of patient data. At last, we provide in appendix B a number of supporting (technical and content related) services that should be available to enable this data exchange. These services must be considered - accordingly to the nature of the data exchange - as pre-conditions which necessarily must be fulfilled to enable a professional and safe service. More detailed information is available in the experts’ report [1].
2. Current Belgian Contextual issues 2.1. Current achievements of medical telematics in Belgium Since the ninth decade of the previous century, we see the increase of projects on electronic data exchange between health professionals combined with the existing
J. Devlies et al. / Recommendations from a Belgian Expert Group
165
medical telematics. These projects sometimes aim for clinical, administrative, research or sometimes even for several targets simultaneously. As these projects appear to lack conceptual and technological coordination, we risk evolving in all kinds of directions. We note also that substantial and remarkable investments have already been done by both the public and private sector or in partnership. This includes standardization efforts for databases (medicines/terminology), existing addressed messages between different actors, labelling and availability of labeled EHR, the structuring of patient records, some tools developed by the project BeHealth / eHealth platform as described in the experts’ report, national registries, national and European projects on messaging, Kmehr syntax and the definition of an emergency record Sumehr, etc…. It is important -as far as possible and useful- to take these achievements into account. We note, however, that the continuity of some of these initiatives (usually public) has not been guarantueed and that some of these projects have suffered significant delay due to this lack of continuity. The opinion of the Working Group aims at being pragmatic in proposing actual ways of investment and development as well as guarantees for continuity in order to facilitate sufficiently sustained short-and mid-term results. These recommendations are given in by the following concerns: • When relevant, reduce costs by encouraging the reuse of tools or common procedures, resulting in a maximum compatibility between the different initiatives; • Reduce the impact of these developments to the administrative account of the healthcare professionals; • Promote the quality, effectiveness and availability of care. 2.2. History of some public initiatives In the past years, a number of government initiatives have been launched to facilitate exchanging and sharing patient data. These initiatives were alternately successful and major regional differences were found. These initiatives were not consistently and persistently held by the policy makers. To illustrate this, hereby a contribution from a member of the Advisory team with particular experience in this field. "The Ministry’s Public Health Department has launched several initiatives on sharing healthcare data since the late 1990s: from the ABC project initiated by the IRIS network, over the S3 project to finally come to the current initiatives. From an initially federal approach, one switched to a regional organisation of projects. The financing of these projects was organized by the SPF (Belgian Ministry of Public Health) by the "Projects to promote communication between the acute hospital and the general practitioners’ attraction zone" The amounts ranged from 5,000 € to 12,000 € and were allowed by the B4 part of the hospital financing. These projects allowed the development of experience and the construction of pilots such as the “Réseau Santé Wallon” or Walloon Healthcare Network (= α Flow
166
J. Devlies et al. / Recommendations from a Belgian Expert Group
project), the Brussels Abrumet Network or the Gamma Flow project in Flanders. Nevertheless, this scattered approach has some inconveniences: •
Fragmentation of the project which multiply appearing initiatives hardly compatible with each other; • Parallel development of similar features resulting in additional costs; • Troublesome administration to require the yearly signature of many parties for an after all poor allowance; • Significant delay or even lack of funding; • Sub-financing: for example, in 2007, the SPF has only been able to fund 19 hospitals out of the 31 who had submitted a project within the framework of the Walloon Healthcare Network; • Weak federative framework at national level: o Suspension of the telematics law project; o Discontinuation of the meetings of the Belgina federal commission “Telematics Standards in relation to the Health Sector”; o Lack of an official site to support the national Kmehr standard. In addition, the Government has started the development of the BeHealth platform, in collaboration with the insurance companies (MyCarenet), INAMI-RIZIV and the Cancer Register. Despite their repeated requests, care provider projects (initiated and funded by the SPF) have never been able to benefit from the services of the BeHealth project. The board of surveillance assembles on irregular base and never allows any debate. The care providers regret the lack of transparency and openness of the BeHealth project. The absence of a specific legislative framework leads to strange situations, at the least for what concerns the privacy aspect. For example, the explicit agreement of the patient is mandatory and the patient’s unambiguous identification through a national registration ID is prohibited within the framework of projects ensuring continuity of care to that patient; while it is mandatory to share the same data by making use of the national registration ID for a project with a purely epidemiological objective which does not address any patient individually (cancer register). Ultimately, we find that many projects funded by the Belgian Government within the framework of health data exchange build up outside a common organisational framework and common technology. We believe that this will lead to extra overall costs and severe damage to the actual development of the projects". 2.3. The role of the General Practitioner and the GHR (Global Health Record) A workgroup within the NRKP (Nationale Raad voor Kwaliteitspromotie or National Council for Quality Promotion) came up with a number of recommendations that are important in a general framework of making available health and care data to the different care providers.
J. Devlies et al. / Recommendations from a Belgian Expert Group
167
Among others, it includes a definition of the GHR: “it is a part of the medical file. This part is formed by a synthesis of data which are important, and interchangeable. The exchange of these data with other partners in the healthcare, both within the first and with the second line, improves the quality of the care”. Further in the document: “The GHR makes part of the actual record of the general practitioner”. The “Agreement Physicians - Health Insurance Companies 2006-2007” defines the contents of the GHR [2]: • The GHR contains the administrative data of the patient • It contains medical data such as the anamnesis, the critical issues, the current disorders, the results of additional examinations, the recommendations of specialists, the prescribed medications. The same document clearly precises that data concerning third parties and personal notes of the care provider do not make part of the GHR. From what precedes, one could decide that the GHR forms a subset, contains the essence of the complete, scattered medical record in the course of which the content of the GHR includes the patient data qualified for exchange within the framework of the care. Concerning the object of this convention, the NRKP document specifies that relevant elements of that collection form the content of a referral letter. At each referral, GHR-keeping general practitioners must mention the relevant information from the GHR. The cited document mentions that care providers should “now more than ever become aware to provide the relevant information to the GHR-keeping general practitioner” The document precises that the GHR contains the information that the patient can consult. Remarks: 1. The GHR has been rather explicitly defined in function of the individual general practitioner the patient draws an agreement with. An adaptation to the reality of group practices would be advisable. 2. A more clear definition of the boundary between the GHR and the core record/urgency record/Sumehr record seems advisable. 3. For interested parties – e.g. the care providers that are supposed to report to a GHR holder – it is not possible to retrieve the existence of a GHR in an efficient way. 2.4. Medical Care Providers: an enquiry In 2007, two inquiries were carried out by the department R&D of the RIZIV among the general practitioners [3] and the specialists (at least those specialists providing care to ambulatory patients) [4]. In total, 842 forms were filled in by general practitioners and 1405 by specialists. Analysis of the answers enabled the identification of some policy lines related to:
168
J. Devlies et al. / Recommendations from a Belgian Expert Group
•
• • •
Offering medical informatics applications, striving to produce applications o with a “common generic functionality” meeting the minimum requirements of an EHR; o enabling efficient data exchange; o with respect to the privacy of the patient and physicians; o meeting the specific requirements of each specialty; An improved knowledge of a concurrent market and its offers; A correct and optimal use of the “informatics instrument” by means of welladapted and continuous training; Facilitating the use in general of information technology in the care sector by means of: o Financial support for possession and use; o Guaranteed technical support.
3. Recommendations from the Expert Group Within the current Belgian context, some recommendations were formulated by the Belgian Health Telematics Expert Group on Health Data Exchange, Health Data Sharing and Decentralised Clinical Data Collections. 3.1. The 10 Recommendations These ten recommendations include the most important and urgent options as well as the general priorities of development as defined by the experts from the workgroup, taking into account the current context and the large number of announcing needs. However, the important and fast social and technological evolution makes regular evaluation of these recommendations necessary. Each of these priorities must be further developed to very precise and detailed proposals. This surpasses the task and the resources of this workgroup. The recommendations – being themselves already a selection of topics - have been arranged to importance as indicated by the members of the workgroup. Hereunder an English translation of these “priorities” ordered by importance and urgency by the experts. 1. Definition and follow-up of a vision and strategy regarding health data exchange and health data sharing. This requires professional and transparent “governance” supported by a recognised but independent organisation representing all stakeholders involved in health data exchange and health data sharing. The vision needs to take into account all possible relevant services and all possible service providers and this without any exclusion. The impact of such strategy will much depend on the three following pillars:
J. Devlies et al. / Recommendations from a Belgian Expert Group
2.
169
• Appropriate legal framework; • Training and education; • Financial and other incentives (incl. for the users). Development and active promotion of the real use of standards (incl. semantic and syntactic ones) hereby considering previous investments done by the local market (Kmehr2 syntax, Sumehr3) as well as existing international standards. Important investments in semantic interoperability are still required, considering the absence of national or international standards, e.g. regarding diagnostic and therapeutic procedures, medical specialties, occupational risks, allergens, care pathway identification, etc… Semantic and syntactic services should be made available to the market players, e.g. terminology servers.
3.
Availability (right to use) to any interested party involved in care of a unique primary patient identifier, independently of the data exchange platform. e.g. the national social security number.
4.
Authentic (data/information) sources, publicly funded, should be made available for free to any interested party involved in care (incl. industry). These authentic sources comprise the register of care providers and professionals, the therapeutic links between patients and care providers (‘global record holders’, care teams…), insurability as well as public medical content repositories.
5.
Quality and conformance testing of Electronic Healthcare Record systems and of systems interacting with them need to be continuously and professionally organised.
6.
Interoperability between disparate medical records, preventing the creation of parallel partial record systems, e.g. pathology oriented record systems, through:
7.
• Structured data exchange between systems; • Locator services. Definition of uniform and consistent quality assurance rules on fully secured data exchange networks for healthcare.
8.
Administrative simplification reducing repetitive and redundant data entry.
9.
Definition of rules to get legally validated electronic documents, independently of the data exchange platform.
10. Elaborate a structure for patient centred health services such as telemonitoring, homecare, personal health systems.
2 3
KMEHR stands for Kind Messages for Electronic Healthcare Records. SUMEHR: Summarized Electronic Health Record.
170
J. Devlies et al. / Recommendations from a Belgian Expert Group
3.2. Management and exploitation of services The services described in this document are best run in a professional and coordinated manner. Several models are possible, from a purely market driven model over a public exploitation of the various services to a publicly-privately cooperation. A competitive exploitation by both public and private service providers seems to be the least attractive model. Wherever possible, it is advised to define as much as possible any clear demarcation of the role of all involved parties considering the following preferences: • Private-public cooperation. • Non-exclusive or monopolistic exploitation of the services offered, based on both quality and continuity guaranteed by means of economically viable models. • Free availability of all sources and developments financed and/or maintained with resources of the government and/or the health insurance. Picking the best option for every service is and remains in an important degree a political decision. This cannot be done without considering the legitimate expectations of the users (care providers and patients), particularly concerning the right to the protection of their personal and professional confidentiality. The degree in which some of these legitimate requirements is met, will determine the acceptance of these services in an important degree. 3.3. Chronology of implementation Two approaches can be followed when determining the priorities: breadthwise or depthwise. • Depthwise, a domain application is set out, e.g. a diabetes care path, data exchange concerning medical imaging (application/results), communication with the home care or the electronic prescription. Subsequently, all problems in that field such as semantics and syntax are tackled. • Breadthwise, for instance all problems concerning semantics and syntax will be listed and tackled first, together with a number of supporting (identification) services. Both approaches result in two or three lists of priorities which –mainly – can be initiated (and finished) simultaneously. Considering the available means, it will be the task of the appropriate bodies to set these priorities.
J. Devlies et al. / Recommendations from a Belgian Expert Group
171
4. Apendix A - Description of the Telematic services Fig 1 gives an overview of the various services described in this chapter. These services are described in the chapter 7 of the experts’ report [1].
4.1. Addressed message transaction between care providers
4.3. Non-addressed messaging– Decentralised “records”
4.1.1. Notification messages
4.3.1. General characteristics
4.1.2. Requests for examination 4.1.2.1. Lab requests 4.1.2.2. Requests “Technical Interventions” - “Procedures Request” 4.1.2.3. Requests Medical imaging
4.3.2. Discussion of the various “clinical” shared care services 4.3.2.1. Patient summary 4.3.2.2. Collaboration file 4.3.2.3. Locator services – Data Reference Services 4.3.2.4. Patient consent services 4.3.2.5. Second Opinion Services
4.1.3. Reports of examinations 4.1.3.1. Lab results 4.1.3.2. Results “Technical Interventions” 4.1.3.3. Results Medical Imaging
4.3.3. Other “shared files” 4.3.3.1. Registers and thematic shared files 4.3.3.2. Temporary collections
4.1.4. Referrals and Clinical Reporting 4.1.4.1. Referral letter 4.1.4.2. Referral report 4.1.4.3. Discharge letter 4.1.4.4. Short version of the discharge letter 4.1.4.5. Overnight duty report 4.1.4.6. Overnight duty service reports 4.1.4.7. Care request 4.1.4.8. Care report 4.1.4.9. Follow-up & Outcome (Home) Monitoring 4.2. Data exchange between care providers and insurance companies 4.2.1. Requests for allowance 4.2.1.1. Requests for reimbursement / drug intervention 4.2.1.2. Other requests for reimbursements/compensations. 4.2.2. Approval & Disapproval for intervention 4.2.2.1. Approval for drug intervention 4.2.2.2. Approval for intervention of other care 4.2.2.3. Disapproval for intervention
4.4. Combined “clinical” services 4.4.1. Electronic Prescription & Delivery message 4.4.1.1. Electronically produced prescription 4.4.1.2. Electronic Medical Prescription (EMP) 4.4.1.3. Delivery message 4.4.2. Exchange of vaccination data 4.5. Medico – administrative services 4.5.1. Authorisation server services 4.5.1.1. Authorisation server insurability 4.5.1.2. Authorisation server medication 4.5.1.3. Authorisation server other therapeutical services 4.5.1.4. Patient-oriented authentic sources 4.6. Patient-driven services
4.2.3. Certificates and reports to the insurance companies 4.2.3.1. Disablement certificate – invalidity 4.2.3.2. Medical Report Insurance Company 4.2.3.3. Other reports Insurance Company
Figure 1. Telematic services
4.1. Addressed message transaction between care providers This chapter describes all messages with an identified care provider as addressee. Thereby, however, it is clearly stated that a message addressed to a group of care providers, to a practice4 or to (department of) a care institution is also considered as an addressed message. 4.1.1. Notification messages These messages have been posted by a care institution to communicate an admission, a transfer within an institution (e.g. transfer to another department), a discharge or decease, but also of a birth.
4 Every request for an examination, treatment or intervention in the care of a patient is an order. This also goes for a drug prescription, any other aid or a specific treatment or series of /series of treatments. Intrinsically, these services are that different that they are discussed separately in this document.
172
J. Devlies et al. / Recommendations from a Belgian Expert Group
The services have been described within Kmehr (except transfer and birth) and in C³ (except birth)5. These bulletins are very important for a good understanding between the hospitals and the first line and must enable the general practitioner to fulfill his (additional) advisory role towards the patient or his community. Possibly, general practitioners could be encouraged by the government. They do not represent “enormous” efforts at the level of the initiating hospital information system nor do they in the EHR systems. Some of these messages also are important in homecare. 4.1.1.1. Description of the service Addressed message sent out by a hospital to report: • admission • transfer or change of service/department during the same episode • discharge (with or without indication of destination: possibly another hospital) • decease • birth Remark: 1. The “Provisional Discharge Letter” defined by Kmehr could be an interesting extension to simple notification messages for a hospital discharge, given the increasing importance of fast acting upon for patients discharged from hospital. 2. Alternative approaches are possible, such as an automated mail service via mobile telephony. Those mail services have, however, the disadvantage that an automatic processing within the EHR is lost (as further described). Anyhow, this is an important disadvantage. 4.1.1.2. Addressee In most of cases, the addressees of the message are the referring physician and the usual general practitioner (possibly the GHR holder) of the patient. The referring physician can be hospital physician or a service in another hospital. It is possible that - on explicit indication of the patient – notification messages are sent to another care provider other than the usual general practitioner. The hospital system should be able to document this wish of the patient. It is also possible that - on explicit indication of the patient - no notification messages are sent to the usual general practitioner, being or not being holder of the GHR. The hospital system should be able to document this wish of the patient. In case of birth, it concerns the usual general practitioner of the mother. For discharge messages and notification of decease, a “reduced” version without clinical data intended for the home care could be considered. 4.1.2. Requests for examination Electronic requests for examinations (orders6) are very popular within the care institutions, initiating an entire workflow, starting with the order, the appointment, the 5
C3 stands for Comprehensive Continuous Care, an e-Ten Euroepan Research Project. Every request for research, treatment or intervention in the care of a patient is an order. This also goes for a drug prescription, any other aid or a specific treatmet or series of /series of treatments. Intrinsically, these services are that different that they are discussed separately in this document. 6
J. Devlies et al. / Recommendations from a Belgian Expert Group
173
placing on the agenda, over the implementation to the reporting and invoicing. These intramural “addressed messages” are not subject of this recommendation, even when having common characteristics and problems. Extramural, there are almost only – if not manual - electronically produced papers or document-based “electronic” requests. Electronic requests for examinations have been sent out by the EHR of the general practitioner or the information system of the extramural doctor specialist. Addressees are a laboratory (extra or intramural), a medical imaging department or an extramural service for medical imaging, or a specialised service within a hospital or a peripheral doctor specialist. The electronically structured requests for examinations are, as de facto determined within the market and confirmed in the C³ study, much less popular when it concerns an ambulatory request. General problems/considerations concerning “requests”: 1. Identification of the addressee, more specifically groups of intramural care providers or intramural departments as well as extramural practices. 2. The intake and routing of a requests message within a care institution often seems not possible in a “protected” way or not possible at all, guaranteeing that the requests are only handled by those persons addressed by the request. 3. Technologically, one could consider to drop the traditional messaging approach and to go for web services7 offered by the care provider. When going for this kind of approach however, it should be avoided that each service provider would offer his own service. This would result in the situation that the user would depend on an access and access right as user and thus become dependent on one or several service providers. A generic “order module” seems to be a possible alternative, functionally integrated in the requesting EHR systems, both for laboratory tests, diagnostic or therapeutic transactions and medical imaging. 4. An important additional consideration is that in that case, the different receiving systems must be compatible and able to process the requests. 4.1.2.1. Lab requests Lab requests still make use -almost exclusively- of paper forms to be filled in brought to the serve where the sample is taken. Some EHR systems have developed an interface for the selection of requested tests, hereby stimulating the use of a request form (analogous to the paper form the prescribers usually uses). Rather exceptional are Software developments for “structured lab requests”, except for producing a paper request form. In C³, the services are documented as well as a message format for a structured request that is offered within the Kmehr Cookbook.
7 Here, not the mail service is intended but indeed an“external” application that would be offered by the service providers in function of their “offer” to apply for some kinds of research.
174
J. Devlies et al. / Recommendations from a Belgian Expert Group
4.1.2.2. Requests “Technical Interventions” - “Procedures Request” This service concerns the diagnostic and therapeutic procedures, except for lab analyses, medical imaging, surgical procedures and consultations as well as the consultations. The first two have been documented separately in this overview, the last two are considered as “referrals”. For example, it concerns ECG, EMG, EEC, endoscopical examination, knee puncture… In this document the procedures for medical imaging are discussed separately, as most EHRs manage the results separately. The extramural requests for technical interventions still overwhelmingly go via the paper way. That also goes for the electronically produced request documents, Word documents, which are printed. The documents can be saved as a document, in some software linked to an application- or `private' encoding term. Mostly, these documents do not contain any request identification. This does not result in an obvious added-value of a link of a request to a result. Structured requests – in use on the market – are unknown. The service is documented in C³ and a messaging format is being offered in the Kmehr Cookbook. Kmehr however, does not make any difference in requests for medical imaging and requests for other examinations: an arguable option. 4.1.2.3. Requests Medical imaging This service concerns the requests for Medical Imaging. Intra-murale requests are not taken into consideration. Most of them (if not all) are created and processed locally. The extramural requests for mdical imaging still overwhelmingly go via the paper way. That also goes for the electronically produced request documents, Word documents, which are printed. The documents can be saved as a document, in some software linked to an application- or `private' encoding term. Mostly, these documents do not contain any request identification. This does not result in an obvious added-value of a link of a request to a result. Structured requests – in use on the market – are unknown. The service is documented in C³ and a messaging format is being offered in the Kmehr Cookbook. Kmehr however, does not make any difference in requests for medical imaging and requests for other examinations: an arguable option. Conclusion: The most significant problems regarding the “requests” are: 1. Structured requests still do not (yet) imply any added-value to the applicant. 2. Structured requests mostly cannot (yet) be integrated in the information systems of the service providers. 3. There is still no uniform standard for identification of the different examinations: not for lab tests, not for diagnostic and therapeutic procedures and not for medical imaging examinations. 4. There is a problem with the identification of the addressee, being not always an individual care provider but sometimes a service or a group making part of a service. 5. There is also a problem with secured routing of the request to the addressee, the system of the addressee, especially in intramural medical imaging.
J. Devlies et al. / Recommendations from a Belgian Expert Group
175
4.1.3. Reports of examinations In opposition to requests for examinations, the integration of the results of examinations and/or reports is well established since more than 15 years. Moreover, it does not concern textual documents but indeed - to a certain extent - structured messages. As discussed further, the situation becomes less satisfactory as soon as it concerns the “accompanying documentation” such as images as part of a medical imaging report. Moreover – in that particular case - the question rises whether we should seek to send that material rather than to emphasize making the data available. By means of push approach, the sender is in principle the service provider who carried out the examination, at least when it concerns traditional telematic services. For the exchange, in most cases traditional mail systems (MedServe, Mediring, Mexi,…) are used. On appropriate moments, the results are downloaded and integrated automatically in the EHR. Some practices/services offer “web-services” where the reports are “available” on their own infrastructure8. In most cases, the addressees of the reporting message are the referring physician and the usual general practitioner (possibly the GHR holder) of the patient. The referring physician is known to the system, possibly being a (group) practice: in that case it must be possible to deliver the message to the practice. The referring physician can be a hospital physician or a service in another hospital. The usual general practitioner is not always known. In case a reference database with the DMR link and/or more generally the therapeutic links between physicians and patients would be available, the efficiency of these services would increase enormously. It is possible that - on explicit indication of the patient - report messages are sent to another care provider than the usual general practitioner, being or not being holder of the GHR, and the applicant. The reporting system should be able to document that wish of the patient. Important semantic problems exist and are described for each of the described services. They all restrain the development of monitoring applications, of clinical decision support in general and an efficient management of care pathways. Existing developments are based on “local” and “system-specific” approaches. Conclusion: The most significant problems regarding the “reports” are: 1. Identification of the addressee in case it does not concern an individual care provider or the management of the therapeutic relation 2. The multiplicity of solutions for both syntax and semantics. 4.1.3.1. Lab results Most spread telematic service, in use since the end of 1980s. The service is enormously appreciated. The fact that a paper version of the laboratory protocol was no longer required proved to be a boost for the generalisation of this service. Most labs are able to send out laboratory results electronically and in a structured way, meaning these results can be integrated one by one in the receiving EHR.
8 Moreover, the question rises whether the dependency of the care provider/institute doing the examination is acceptable.
176
J. Devlies et al. / Recommendations from a Belgian Expert Group
There are however important regional differences, especially concerning both syntax and semantics (codes), implying that labs should maintain different export definitions. Laboratory results are sometimes retroactively sent “in block”, for example when creating a new link between a patient and his new (usual) physician. 4.1.3.2. Results “Technical Interventions” This service concerns the diagnostic and therapeutic procedures, except for lab tests, medical imaging, surgical procedures and consultations. It concerns for example ECG, EMG, EEC, endoscopic examination, knee puncture… This document discusses the results of medical imaging and lab results separately, as most EHRs also handle the results separately. Surgical procedures and consultations are handled as a referring document. Since the beginning of the 1990s, this service became frequently used. Lots of specialised services are able to send out reports concerning many “technical interventions” electronically and - to a limited extent – in a structured way. Thus, these results can be integrated one by one in the receiving EHR. Identification of the “interventions” is often free-text based. Some systems make use of their own encoding allowing automatical integration in the EHR, based on the own encoding system. Some EHR systems already have a (limited) own encoding system, being the same as for its users. Some important regional differences exist, especially concerning both syntax and semantics (encoding). 4.1.3.3. Results Medical Imaging There is little difference between this message and the one with the reports concerning the diagnostic and therapeutic interventions. Almost all medical imaging departments and most ambulatory services for medical imaging are able to create an electronic reporting message and to send it to the applicant of the examination and if necessary the usual general practitioner. A lot of medical imaging reports are still purely descriptive, not even making a distinction between the narrative part and the conclusion. This distinction is experienced as important to store the conclusions in the EHR and the coming from an EHR. Moreover, a lot of medical imaging reports are rather a report of a medical imaging session than a report per examination conducted, each time identified in a unique way. A report per examination conducted is essential for the sequence of examinations conducted, more specifically within the framework of prevention and care pathway management. Concerning the identification of the examinations conducted, there exists no uniform encoding resulting in a situation which resembles to those of the other technical examinations. There are however some regional differences, especially concerning both syntax and semantics (encoding). Completing a medical imaging report with documenting illustrations is less usual, at least electronically. Two tendencies are possible:
J. Devlies et al. / Recommendations from a Belgian Expert Group
• •
177
Making available all images or a composition of images at the place of origin, doing the visualisation in the medical imaging department or starting from an archive (how long will these images remain available?) Sending/supplying a composition9 of images to the prescriber in a standard format (e.g. JPEG)10.
4.1.4. Referrals and Clinical Reporting 4.1.4.1. Referral letter It concerns a report/document produced by a referring physician (general practitioner or specialist) with on the one hand an overview of the medical condition of the patient (overview resembling substantively to a core-record) and on the other hand a description of the reason (and/or objective) for the referral. There is no focus on doing a certain intervention/examination determined by the sender or on the treatment of some care problems. For that purpose, one uses the requests for examinations discussed in 4.1.2 or the non-medicinal orders as discussed in 4.1.4.7. In case of a referral, it is essential that the patient himself is referred to the care provider(s) whose advice/intervention is requested. This is in contrast with the “second opinion services” as discussed in 4.3.2.5. Generally, one understands an electronic referral letter as an electronically produced referral letter, being a text document that is on the one hand printed and on the other hand as such - as a document – saved in the EHR of the patient. Ultimately, a paper document is then used as a means of exchange of data. This service is - at least in that implementation - not comprised in this recommendation. The event itself is registered (ideally) in the EHR of origin, completed with the reason of referral. Subsequently, the document can also be sent “as document” in for example a Kmehr envelope as foreseen in the Kmehr Cookbook, with an integration as document in the record managed by the addressee. The nature of referral can be added to such a message (e.g. cardio, follow-up,…) based on a mostly application-linked or personal list. Such a message should also contain a reference ID, for future use in the message report. A more sophisticated message with a structured content (possibly identical to structured core-record of C³ or Sumehr) completed with the reason of referral, is described by both C³ and Kmehr. Very little (no?) systems can produce such a structured referral letter, mainly because almost no addressees (both individual doctor specialists and departments in a hospital) are able to accept and process such messages within their information system. There are different ways to process such structured messages, depending on the possibilities of the receiving system: by producing a document or via a structured “item by item” integration. The latter, assuming the user has an instrument to “accept” these data one by one for integration in the record of the concerned patient11. In this case, it is important to document the origin of data in the receiving system.
9
Should the delivery of all images (with a peripheral duplicate) ever be effectively considered as cost? Cfr. Annex A1: Letter to INAMI, 6 March 2008, from GBO. Essential to prevent pollution of the receiving record systems.
10 11
178
J. Devlies et al. / Recommendations from a Belgian Expert Group
4.1.4.2. Referral report This service is the logical consequence of the previous service. In principle, a referral report is only used for ambulatory care. Admissions result in a discharge letter. Kmehr is unaware of the concept of a referral report. For this purpose, a Kmehr discharge letter could be used, although a discharge does contain a number of specific elements, such as the data concerning the admission itself. Kmehr allows, however, these data to be “blank”. Making use of the syntax of a discharge letter does therefore not mean it is advisable to make a distinction between these different types of reporting. The same goes for the reports concerning non-medicinal treatments (e.g. report of a physiotherapeutic treatment). Probably, all referral reports are now at least created via text-processing. A lot of referral reports are still being printed and sent via regular mail. A referral report can be, as is a referral letter, an electronic text document (ideally with a distinction in description and conclusion) or a structured document/file. A structured report not only assumes a list of diagnoses and treatments but also a structured integration in that report of for example the examinations conducted. Not many information systems used by doctor specialists are able to create a structured report, nor are EHRs in use by for example general practitioners able to integrate these data one by one. 4.1.4.3. Discharge letter In fact, this concerns a referral letter of the end-responsible for an admission. It is not uncommon that also in case of a transfer during one and the same episode, a “discharge” letter is created. From the content point-of-view, a discharge letter is identical to a referral letter, including some additional elements concerning the intramural care period, admission data (when, how, who referred, initial diagnosis) and discharge data (state, where to, …) A referral report can be, as a referral letter, an electronic text document (with ideally a distinction in description and conclusion) or a structured document. A structured report not only assumes a list of diagnoses and treatments but also a structured integration of the examinations conducted during hospitalisation. Both C³ and Kmehr 1 describe the content of a discharge letter (rather similar). The integration of a discharge letter in the EHR of the patient generally goes via a poorly structured letter. Generally, a referral precedes the admission. It is not exceptional that the referral physician is different form the addressee. 4.1.4.4. Short version of the discharge letter The short version of the discharge letter is provided by Kmehr, not by C³. Substantively, the short version of the discharge letter is not that different form the full discharge letter. However, probably several parts of the definitive discharge letter will remain empty. For further description of this service, we refer to 4.1.4.3. There it does not differ both substantively and functionally, except (perhaps) in the aspect: integration of the
J. Devlies et al. / Recommendations from a Belgian Expert Group
179
data in the EHR. It does not seem advisable to provide more than integration12 on document-basis. 4.1.4.5. Overnight duty report Here, an overnight duty report, means the clinical report intended for the usual physician of the patient (being or not holder of the GHR) produced by a care provider who has granted care to one of his patients during overnight duty. Fundamentally, an overnight duty report does not differ from a referral report, except the fact there has been no referral. For the assessment of the data, one has to take into account the circumstances of generating these data. An overnight duty report can therefore be restricted to a text (possibly with a narrative part and a conclusion). Equally well, it can be structured, more specifically concerning medication or other factual data noted during overnight duty. For further description we refer to 4.1.4.2 In case data from a (structured) overnight duty report should (have to) be integrated in the EHR, it is essential to have a function to handle these data one by one. 4.1.4.6. Overnight duty service reports Overnight duty service reports are structured type reports concerning the functioning of the very overnight duty service, completed by a care provider doing overnight duty and forwarded to an overnight duty service responsible. They do not contain any direct identification of the patient. It concerns -what the report itself concerns- anonymous data. They do contain, however, identification data of the calls. At the level of the overnight duty service, identification data of patients could be linked to a call. In case this would actually be true, these messages should not contain medical data since the overnight duty service responsible -at least in that roledoes not make part (even temporarily) of the care team. The overnight duty service report can contain however, general indications concerning the gravity/urgency of the call, a possible aggressive attitude of the patient or (encoded) clinical data (diagnosis/treatment). 4.1.4.7. Care request It concerns a form/document produced by a qualified care provider (generally a general practitioner or specialist) requesting another care provider (nurse, physiotherapist, logopaedist, psychotherapist…) to administer (a) certain treatment(s) to a patient. It is also (mostly) defined as a prescription for physiotherapy, prescription nursing, etc… The term care request was used to be able to preserve the tem “prescription” in the medical (drug) prescription. A care request resembles to a referral letter but has another finality. It is not a request for a recommendation. For that reason, a care request summary does not contain a summary of the EHR but if required, the indication and the intended purpose. Generally, one understands an electronic care request as an electronically produced care request, a text document or form that on the one hand is printed and on the other as such -as a document- stored in the EHR of the patient. Ultimately, almost always a paper document is used as means of data-exchange. The very event is registered (ideally) in the EHR of origin, supplemented with the reason of referral.
12 Although most of the data are “confirmed”, the recording of data originating from a preliminary discharge letter supposes that the same will not occur again with data originating from the “definitive” discharge letter. Double registration should be cleared away.
180
J. Devlies et al. / Recommendations from a Belgian Expert Group
Afterwards, the document can also be sent “as document” in for example a Kmehr envelope as foreseen in the Kmehr Cookbook, with an integration as document in the record managed by the addressed care provider. For this purpose, it is required that the information system of the care provider is able to incorporate the document in the patient record of that care provider. In such a message, the nature of the necessary care is added (e.g. toilet, injections, mobilisation,…) based on a generally application-linked or personal list. Such messages should contain a reference ID, to be used afterwards in the care report. The document differs substantively according to the nature of the care that is to be administered. No sophisticated care request messages with structured content are known. 4.1.4.8. Care report This service is the logical consequence of the previous service: the care request. Kmehr does not know the specific concept care report, neither does C³. There is no fundamental difference with a referral report. For this reason Kmehr suggests to use the “contact” message13. Also in this case, it is necessary to be able to make a distinction between the different types of reporting. Probably, all referral reports are now at least created via text-processing. A lot of referral reports are still being printed and sent via regular mail. A care report can be, as is a referral letter, an electronic text document (ideally with a distinction in description and conclusion) or a structured document/file. Not many (no) information systems used by paramedical care providers are able to create a structured report, nor are EHRs in use by for example general practitioners able to integrate these data one by one. 4.1.4.9. Follow-up & Outcome (Home) Monitoring Basically, it concerns patient messages addressed to the responsible EHR manager. These patient messages are initiated by either home care professionals (mainly for chronic pathologies and palliative care) or more or less directly from “measuring” devices at the patient’s home. These messages mainly contain measurement values (coming from these measuring devices) but can also be used for textual messaging about care issues. With respect to the content, these messages will be very similar to a referring document and/or discharge letter with a descriptive and a decision area (textual) however completed with structured data, mostly measurements as weight, temperature or measurement values obtained via measuring devices. C³ provides specific messages for this follow-up and outcome monitoring services. However, it states that the market is not sufficiently mature. Possibly, this could have changed since September 2003. Concerning this issue, no specific message has been defined by Kmehr. 4.2. Data exchange between care providers and insurance companies At first sight, it may seem that these messages are not in the domain for which recommendations were requested to this workgroup. This does not seem quite 13
A care report can be related to a number of contacts
J. Devlies et al. / Recommendations from a Belgian Expert Group
181
appropriate when considering exchange of data that precedes the care. Without these data, the care itself possibly cannot be supplied. The services discussed further have a clear clinical content. It concerns data exchange between care providers on the one hand and medical services of the insurance companies on the other. Administrative data exchange concerning “granted care” with tarification and/or invoicing do not make part of this document. These services are already operational and have been define quite some time ago. Nevertheless, the form in which these data are exchanged should be revised. Other specific forms like the industrial accident form, the travel certificates etc.… are not discussed at this moment. An important part of these messages is related to the exercise of rights for patient allowance and has therefore indirectly an important impact on the care which can be granted. Electronic messaging towards insurance companies assumes however, that the “answers” of the insurance companies are electronically supplied as well and ready for integration in the EHR. The problem of addressing a certain medical service within an insurance company obviously poses problems (in some insurance companies). The outgoing messages also have some specific aspects. E.g. admissions for reimbursement are best notified to the applicant (being or not the administrator of the concerned patient file) and furthermore made available on a central point, an “authorisation server”, as discussed further. After all, the applicant is not the only “user” of an admission. E.g. one ore more pharmacists can be user of an admission for intervention in the costs of a drug. Thus another presciber also can be user of an admission granted earlier based on a request of a colleague. Refusals for intervention are best notified to the applicant and patient. Besides requests for allowance, the incidental admissions and refusals, we will discuss just number of “reports” drawn up for the medical service of insurance companies. Each of these messages deserves further consideration. 4.2.1. Requests for allowance 4.2.1.1. Requests for reimbursement / drug intervention These messages are initiated by a requesting physician. This can be both a hospital physician or a general practitioner, being or not the manager of the GHR. Most EHR software, as well as Hospital Information Systems, offer the availability of a request form, a form in full accordance with the one recorded in the law gazette (Belgisch Staatsblad / Moniteur Belge). There are two approaches to switch to the electronic request: 1. By means of the EHR of the applicant, an electronic “request form” (a standard form identical to the paper form) is produced/retrieved and filled in, resulting in an electronic document. Afterwards, the document is then, e.g. in a Kmehr 1 envelope, forwarded to the insurance company responsible for the correct routing of the message. 2. “Form approach” will no longer be done. By means of the EHR, a structured request with the hereafter listed content is produced and forwarded to the insurance company:
182
J. Devlies et al. / Recommendations from a Belgian Expert Group
• • • • •
• •
Identification of the addressee, being an insurance company or more specifically a medical service within an insurance company, as the request should be received there. Identification of the applicant Identification of the patient Identification of the drug (packing, dose) Identification of the indication, criterion and specific character of the request (first time, continuation…) for reimbursement in accordance with the legislation/regulation appropriate for that drug or packing of that drug. Quantity of the drug (number of units/packings) or duration of the treatment Possible comment of the requesting physician
No such messages are defined in C³ or Kmehr. This service is one of the top priorities for the care givers. It is a topic of the “Taskforce established within the National Commission of Physicians and charged with the offering of proposals”. 4.2.1.2. Other requests for reimbursements/compensations. Here we discuss only requests for reimbursement/ intervention of the insurance company for certain services, such as (special) glasses, a wheelchair, a special bed, transportation, prostheses etc. and not the prescription itself of these services or care. Except for purely textual requests, currently no such messages are generated. They were neither described in C³ nor in Kmehr. For some of those services some standard forms exist. The same approach could be considered as in the requests for reimbursement of certain drugs. Substantively, we then have three options: 1. Together with the EHR a textual request is filled in/created either on basis of an own practice/system own template/model or ordinary free text. 2. At the side of applicant, via the EHR, a request (standard) form is electronically produced/retrieved and filled in, as a document. Afterwards, the document is, for example in a Kmehr 1 envelope, forwarded towards the insurance company. 3. Via the EHR a structured request is produced and by means of a specific message with the hereafter listed content is forwarded to the insurance company: • Identification of the addressee, being an insurance company or more specifically a medical service within an insurance company, as the request should be received there. • Identification of the applicant • Identification of the request • Identification of the patient • Identification/description of the requested service • Indication/justification of the service (as far as necessary) • Possible comment of the requesting physician
J. Devlies et al. / Recommendations from a Belgian Expert Group
183
4.2.2. Approval & Disapproval for intervention 4.2.2.1. Approval for drug intervention This message is created by the insurance company of the patient and addressed to the requesting care provider. In a scenario with an authorisation server, as further described, there is no real need to address the approval for intervention to third parties (other care providers e.g. the holder of GHR), as this information will be available, every time a prescription is created. The message can be regarded as a notification with: • Identification of the insurance company • Identity of the patient • Identification of the applicant • Identification of the request • Identification of the approval (for further transaction of the prescription) • CNK and standard description of the product (including dose and packing)14 • Criterion and specificity of the request. There is no need to include the indication in the approval for intervention. • Allowed dose (number of packings/units) • Start and end date of the approval At present, no such message is described in C³ or Kmehr. One should check the existence of “similar” Carenet/MyCarenet messages, although then it should be considered to use the standard syntax. According to “insiders”, the current syntax of the Carenet/MyCarenet must be considered “obsolete”. 4.2.2.2. Approval for intervention of other care What applies to an approval for intervention in the costs of a drug, in principle also applies to “other care”, provided that • the content can be different in function of the nature of the care • the care should be identifiable. Here too, the addressee is the applicant, in the way that the applicant gets a notification of approval. The approval itself could be stored in an authorisation server for further availability towards the different care providers (if desirable and to be considered by nature of care). For a number of services, it will be not advisable/necessary to deliver the approval to the patient. In any case, data flows cannot create any restrictions in the free choice of the care provider for the approved care. 4.2.2.3. Disapproval for intervention Not all requests for approval are approved. Applicant and possibly the patient must be informed when a request for intervention is refused. A refused approval does not imply loading an approval on the authorisation server. The request could be returned to the applicant with: • A change of status of the message: the fact that another type of message is sent can be in fact sufficient. 14 Should better be replaced by the code given to VOS/DCI of the cluster to which the drug belongs, where a cluster indeed only can contain only one drug and one packing of that drug.
184
J. Devlies et al. / Recommendations from a Belgian Expert Group
• •
The possibility to indicate in a “structured” way why the application was refused The possibility of adding textual comment
4.2.3. Certificates and reports to the insurance companies 4.2.3.1. Disablement certificate – invalidity In principle, certificates of disablement are medico-administrative messages. In most cases the employer is the first addressee. This way, these messages do not come under the current convention, especially when the message is restricted to a specification of the disablement. Lots of employers have their own medical service. That also goes for the government. Messages addressed to those medical services can be considered however, as part of our task. 4.2.3.2. Medical Report Insurance Company A medical report for the medical service of an insurance company is produced by the responsible care provider, general practitioner or doctor specialist. Other care providers also are required to make a report for the medical service. Concerning the content, the medical report can be a discharge letter of which a copy is forwarded to the medical service. It can also be an “original” report, mostly a textual document created by the EHR, stored in the EHR and sent to the insurance companies (paper version). Currently, no structured reports are used for data exchange with the medical service of insurance companies, even if it were for the fact that those medical services cannot that incorporate that report, not as structured data and not as a document compiled by means of that report. 4.2.3.3. Other reports Insurance Company There are - more specifically for a number of paramedical professions - other “clinical” or at least partially clinical reports which are produced and forwarded, such as the activity reports of the physiotherapists. It is not yet clear to us whether the issue here is the finality rather than the invoicing. For that reason, these messages are not further discussed. 4.3. Non-addressed messaging– Decentralised “records” 4.3.1. General characteristics A decentralised record is -at least for this document- an “externally accessible collection of patient data15, separated of the original EHR, accessible for authorized third parties”. These decentralised records are related with a number of services related to dataacceptance (loading), management of data and the offering of data to the users of the services (retrieve). To offer and manage such services in an ethically justified way, a number of conditions must be fulfilled. Hereafter some general requirements, for which - to realise all this - a number of other services must be “available” (discussed in Chapter 8 of this recommendation). 15
Patient data are always nominative personal data. Here, anonymous data are not taken into consideration.
J. Devlies et al. / Recommendations from a Belgian Expert Group
185
Basically, these requirements apply to all “decentralised” records. 1. The content must be in accordance with a content agreed upon earlier: a. which data b. with which attributes: nature of the data, value of the data, confidentiality of the data c. how many data (version, in function of the nature) d. take into account the will of the patient (management of informed consent at the loading system) e. in accordance with the objective of the “decentralised” record 2. The form in which the data are offered to the service should be in accordance with the agreements concerning the syntax: a. could be in principle Kmehr 2, if we restrict ourselves to rural services b. other syntax standards should be considered (if possible within the time-frame) to enable a cross-border exchange of for example urgency data. c. migration of a syntax to another should/could be foreseen. 3. The executant (uploader) must be qualified to offer those data to the service. This assumes: a. unambiguous identification of the loader (can be a system/a practice, more specifically in case of a group practice), including electronic signature b. unambiguous determination of the usual role of the loader within the care c. unambiguous identification of the person involved, the patient about which data are uploaded d. unambiguous identification of the role of the uploader towards to the care for that patient at the moment of uploading, also called “therapeutic link”: i. the administratively confirmed role for example GHR holder, care pathway administrator,… ii. the “usual role” towards the patient, member of the care team iii. the “temporary role” towards the patient, as within the framework of an overnight duty service (<< presumably, a care provider with a “temporary role” towards the patient is not qualified to carry out data from his system to the decentralised record, however, by means of addressed message reporting can be done) 4. The upload itself must be totally protected and reliable (state-of-theart). 5. The user (uploader16) should be qualified to take note of each of those data, assuming: 16 “Upload” means both the copying patient data to its own system (as far as provided/allowed en authorised by the patient) and the taking note of the patient data.
186
J. Devlies et al. / Recommendations from a Belgian Expert Group
a. unambiguous identification of the uploader/user (can be a system/a practice, more specifically in case of a group practice but also an urgency service or pharmacy) b. unambiguous determination of the usual role of the uploader/user within the care (general practitioner, cardiologist, homecare nurse…) c. unambiguous identification of the person involved, the patient about which data are uploaded d. unambiguous identification of the role of the uploader/user towards to the care for that patient at the moment of uploading, also called “therapeutic link”: i. the administratively confirmed role for example GHR holder, care pathway administrator,… ii. the “usual role” towards the patient, e.g. member of the care team (gynecologist of the patient, psychiatrist) iii. the “temporary role” towards the patient, as within the framework of an overnight duty service 6. The system should: a. Be sufficiently protected (physically) b. Be functionally reliable and available in accordance with agreements made upon c. Have audit functions documenting the upload/download of the data i. Be it for each “migration”, e.g. urgency data (clinical data) ii. Be it on an institutional basis e.g. for a complete register 4.3.2. Discussion of the various “clinical” shared care services Here we discuss one by one the different “clinical” decentralised systems or collections of data which are made available externally from a (main) system. It concerns services where - for certain purposes - (personal) patient data are stored outside the system of origin, for use by authorised care providers. Anonymous data are not subject to this convention. Personal data stored on a decentralised system can be anonymised for further use, e.g. scientific research. Most of those services described here have a common goal: continuity of the care. 4.3.2.1. Patient summary Other names for the service are: urgency file, minimal file. The content of the Sumehr message can be seen as/has the ambition to answer the concept “urgency file”. The same applies to the C³ uploads message. Basically, only those data which are important to provide in certain circumstances the best possible urgent care to the patient are uploaded if it is not the usual care provider for those data. Both in C³ as for Sumehr, a number of data have been identified. These are listed below in a comparative table (see table 1).
J. Devlies et al. / Recommendations from a Belgian Expert Group
187
Table 1: Content of an urgency message / patient summary in C³ and Kmehr Nature of the data Identity data Adverse Drug Reactions Allergies Risk factors / Risk Social Risk factors Current problems, diagnoses, care elements, pathology, … Data on a possible pregnancy Medical history Therapeutical history (procedures)
C³ X X X
Sumehr X X X X X
X
X
X X
X
X Current medication Immunity status or vaccination history Not to be resuscitated Refusal Blood Transfusion GHR Manager Contact person
X X
As far as relevant for the care17 As far as relevant for the care18 / Sumehr does not make a distinction between medical and therapeutical history
X X X X X
Are these wills that could be centrally managed? Are these wills that could be centrally managed? Only in case GHR holder can do uploads at C³…
X
Clearly, one has chosen to define one single collection that is equal for all patients (what the urgency file concerns). That means, however, that the system must provide in protection mechanisms that must not be released to certain (groups of) uploaders/users. 4.3.2.2. Collaboration file The collaboration file aims to make patient data available to • care providers at the moment of taking over / observing the ordinary (even possibly non-urgent) care within the framework of a group practice between independent practices19. • the members of a (group) practice at times when the usual EHR is unavailable (e.g. during a house call). Members of a group practice form an enclosed community (for this service). Currently, on the Kmehr site there is no definition available of the content of a collaboration file. Once there has been an initial attempt which was however never ratified. In C³, there is a definition of such a file. It contains at least the urgency data as described earlier, with some extra data: 1. Lab results, at least the most recent results (per examination) and/or the last protocol.
17 Some EHR systems make a distinction between an antecedent (still having an impact on the current care) and an archivation item (with no other importance than its historical value). 18 This also goes for procedures: an abortion of twenty years ago is completely irrelevant for the current care. 19 E.g.: a replacement during the holiday period, a usual replacement of one afternoon per week.
188
J. Devlies et al. / Recommendations from a Belgian Expert Group
2. 3. 4. 5.
Recent medical imaging reports, technical examinations, at least the results of it. The data (also textual– narrative) of the three most recent patient contacts, the so-called “progress notes”. The planning (planned examinations or appointments) for the following period (week / month) Measured values (selection of), more specifically biometric data as BMI and blood pressure.
4.3.2.3. Locator services – Data Reference Services Locator services are services –on a central point- that offer references about which data and/or documents (nature of data, documents and identification of authorities) are where available, with the possibility to be routed from that central point to the original document and/or file containing the data. Locator services could offer an important contribution for the accomplishment of the “Federal Electronic Healthcare Record”. This is about similar services offered “internally” within e.g. a hospital information system. In that case, there is also routing with respect to the content based on a reference. The content of a “locator item” is rather limited: • Originator of the data/reporting • Origin of the document or data (e.g. hospital x, doctor practice y) • Contact information • Identity of the patiënt If necessary, to the document level: • Identifier of the item • Nature of the item • Location/reference/link to the data/document Examples are Réseau Santé Wallon, Abrumet and GZO (Gents Ziekenhuis Overleg) 4.3.2.4. Patient consent services With this service we mean centralised files where every authorised person can take note of the will of a patient concerning a certain service or care for which the patient is entitled to give his approval or disapproval. Some of these wills and consents can be managed perfectly (and sometimes better/more efficiently) in the GHR or any EHR. For example: has the patient designated a reference pharmacy within the framework of the electronic prescription? Other example: is the patient participating/including in a certain clinical trial and was the approval given (with export of personal data)? Other example: a patient refuses explicitly that data from his file -even when totally protected and anonymised- can be used outside the care itself. Other wills and consents -for example regulations which are not related specifically to certain data in the file- have a more general character have to be made available to third parties, like for example organ donation etc.… These wills and consents are indeed better managed centrally in some sort of “authentic source”.
J. Devlies et al. / Recommendations from a Belgian Expert Group
189
A variant on an approval or a will of a patient is his registration in a care trajectory/path. For this project, these registrations are regarded as medical and administrative data and therefore not discussed here in detail. A registration of a patient in (or de-registration from) a care path is ideally made available centrally and safely. Those data could thus be incorporated in the “authorisation servers” as discussed in 5.8.2. Such a registration has indeed an impact on the insurability of certain care. It would be advisable to define a standard set for “approvals” that could be managed centrally. Preliminary list (to be completed): • Organ donation • Extensive care (not to be resuscitated) • Administration of blood products • Export patient summary (to be managed centrally or in the EHR) • Export collaboration file (to be managed centrally or in the EHR) • Use of anonymised data • Electronic Medical Prescription • Medication delivery notice • Reference pharmacy • Export for second opinion services Approvals from the patient for specific services, like for example an Intego export, are best managed in the local computer system. 4.3.2.5. Second Opinion Services Second opinion services are virtual references exporting data concerning the medical condition of a patient to a “Center of Excellence” or “Center of expertise” without referring the very patient. There, the sent data are processed (partly computerised: consistency and control of the presence of certain required data or absence of exclusion criteria) and presented to an expert for recommendation purposes. The expert formulates a recommendation “on basis of what is available”. Possibly, the recommendation can be that no recommendation can be given because of the lack of certain data. The manager of the EHR, possibly being the manager of the GHR, initiates the export of previously registered data, completes the files -where necessary- (specifically for the pathology) and receives the recommendation of the service provider. It always concerns -to a certain degree different for each service- a maximally structured file that must be delivered to the service provider. Free text is almost always not useful, except for precising specific circumstances concerning that patient by the sending care provider This way a file is structurally rather resembling to the structured referral letter. From the structural point of view, such a file is rather similar to a structured referral letter.
190
J. Devlies et al. / Recommendations from a Belgian Expert Group
4.3.3. Other “shared files” In this chapter we discuss: • the specific shared files which are build up beside (basis) EHR for either scientific research or for enabling follow-up of very specific pathology or therapy • the temporary shared files, as far as these would be stored outside the practice. Most of these files are “registers” or “thematic shared files”, like for example the Cancer Register and/or the registers which are build up for the follow-up/monitoring of a therapy, as implemented currently within the framework of e-Care for certain prostheses and (expensive) medicinal treatments. Particular types of these shared files are the “temporary” collections of data build up to permit the launch of a plug-in application. Common to these shared files is: • the existing need to offer an interface for data-entry for the care provider lacking an EHR from which the data can be extracted. Generally, the application exists of a web interface using the central file 20. • the need for -even when using an EHR- adding certain specific data appropriate within the framework of the objective of the shared file to the present file data. This goes preferably by means of a (standard) web service. In both a “peripheral” file is created, outside the general care for that patient. Even when that peripheral file can be consulted from within an EHR, then still under no circumstances, this file will become an alternative for the standard file. A copy of the additionally registered data should be, either as a document or as separate data, stored in the EHR of the patient concerned. 4.3.3.1. Registers and thematic shared files As the amount of available data increases and the process of care giving becomes more and more “evidence based”, the question/pressure concerning the availability of patient-specific data increases (for reasons of follow-up and support management). With respect to the nature of the “study”, one can feel satisfied with collective (practice-specific or practice-exceeding) data without individual longitudinal follow-up of the data or it can be stated that patient-specific longitudinal data are required. In the latter case, pseudonymisation by an independent21 TTP is a must. In each of the cases a recommendation of the Sectoral Committee for the healthcare is required including a possible/mandatory opinion concerning the nature and granularity of the data that can/will be present in the shared file and concerning the need for personal data. Obviously, all of these shared files are content-specific. This does not prevent that one should seek for a (mandatory) functional and semantic harmonisation of the web interfaces and web services offered by the different “collectors”22. The current development of registers, all with their own semantics, inevitably leads to a useless 20 Especially in this case, severe security measures concerning access should be taken, particularly for the unambiguous, never failing identification of the care provider and his role in the care process. 21 This means with no link to the deliverer and the users of the data. One and the same “entitity” can therefore not be involved in TTP services and in the use/ processing of the data. 22 It is unacceptable that even the same data for two components of one and the same shared file should be executed/delivered in more than one way by an EHR.
J. Devlies et al. / Recommendations from a Belgian Expert Group
191
workload of EHRs and management systems for patient data, a decreased usability of the data and a sub-optimal use of the resources. In case of an incomplete integration, this also implies an important workload of the care provider, leading to double registration efforts on top of learning other interfaces over and over again. The workgroup believes that before starting this kind of services, it is necessary that besides a “privacy” recommendation also a “technical-functional” recommendation is given by a suitable governance structure. 4.3.3.2. Temporary collections By the term “temporary collections” we understand the whole of data concerning an individual patient that are of offered to a local or distant sub-application (plug-in) with the intention of performing a certain function (e.g. calculation of a risk or functionality). Sometimes/often those data are stored in a file used by that peripheral application, mostly to produce evolutions/trends. It also happens frequently that parameters required for that sub-application are missing in the coupled EHR, either because no data are available for that patient for that parameter or because the EHR has not (yet) foreseen that specific parameter. In those cases an interface is offered for registration/input of those data, analogous to the previously discussed “shared files”. The use of data by plug-ins and the processing of those data assume some clear agreements to prevent the creation of a parallel file: • All data elements inserted in that plug-in must be copied in the EHR • Information created in that plug-in must be incorporated in the EHR. Strict security measures are required in case the temporary “external” file is kept externally, possibly on the advice of the Sectoral Committee. The question rises how long those data can remain stored, for example when the care provider responsible for the use of that external application is no longer the file-keeping physician. 4.4. Combined “clinical” services These services make use of both addressed and non-addressed messages and/or decentralised records. This way, prescriptions (for medication) can either be put on a server without precision of the addressee23 or be made available to one distinct addressee. In this case, the service provider can inform the addressee or “push” the message to the addressee. In this chapter, we describe rather exhaustively the services concerning the electronic medical prescription and the authorisation services. It seems that several “orders” in that way could be offered, for example orders to conduct certain examinations or for administration of certain care. Those orders however concern rather exclusively addressed messages (be it that a department or a practice can be the addressee).
23
Addressee is only known when the prescription is picked up, e.g. when arriving in the pharmacy
192
J. Devlies et al. / Recommendations from a Belgian Expert Group
4.4.1. Electronic Prescription & Delivery message Concerning the electronic prescription, it essential to make a distinction between an electronically produced document that is printed and an electronic document, structured or not. Furthermore, we also distinguish an addressed and a non-addressed prescription. • A non-addressed prescription is stored temporarily at a prescription server. It is retrieved at the moment a patient gets his medication in a pharmacy. • An addressed prescription is likewise stored at a prescription server. The addressee receives notice that a prescription is available. That prescription can be consulted (and possibly prepared24) by that addressee. The regulation however, remains available for any pharmacy the patient would visit in spite of the fact it was addressed. Finally, we discuss the “delivery message” that in itself has some added-value. 4.4.1.1. Electronically produced prescription The electronically produced prescription has already a lot added-value when integrated in/coupled to an EHR and when making use of a supporting drug database. An electronically produced prescription allows a better choice of the prescribed drug, a guarding on interactions and contra-indications and also a dose control. The electronically produced prescription is in itself an answer to the most important disadvantages of a hand-written “brain made” prescription: reading and interpretation errors and poorly founded selection. 4.4.1.2. Electronic Medical Prescription (EMP) Characteristics The advantage includes at least advantages of electronically produced prescriptions with some briefly listed advantages (not exhaustive): increased efficiency for prescriber and pharmacist, availability of data for scientific research and policy (when shielding of the patient’s identity at the repository is guaranteed), less fraud. Moreover, thanks to the electronic prescription an improved partnership between physician and pharmacist becomes reality, all to the benefit of the patient. Thus the EMP can be a vehicle for sharing certain data concerning a patient such as allergies, important health risks concerning medication, medication history, compliance management and use of sometimes non-harmless OTC products. Implementation of the EMP assumes the availability of one or more servers (Prescription Pool Servers - PPS) and strict security policies of these servers and the communication of these sometimes very delicate personal data. The fact whether everything must be centralised on one server only is a purely political decision. When using several servers, coordination will be required, even when this implies a very small percentage of the prescriptions not delivered locally. Addressed electronic prescription The addressed electronic prescription is a prescription for which the patient has explicitly asked to forward it to its usual pharmacist (reference pharmacy for that
24
Based on the pharmacist’s own decision
J. Devlies et al. / Recommendations from a Belgian Expert Group
193
patient). This allows the pharmacist to improve the service towards the patient and the stock-management, without eliminating the patient’s liberty to visit another pharmacy. Non-addressed electronic prescription A non-addressed electronic prescription addressed to the PPS and stored there in a totally secured way. The prescriptions remain available on the server during a certain period (to be agreed upon) and are retrieved only when the patient visits the pharmacy with his SIS card. The prescriptions are definitively archived once all prescribed products are either delivered or “removed” from the prescription. 4.4.1.3. Delivery message After delivery of one or more prescribed drugs/products, a delivery message is sent, in case the patient agrees with this. That also happens when no product at all is delivered because the patient for example does not wish to accept. The delivery message is sent to the prescriber by the delivering pharmacy. When the prescriber is not the administrator of the GHR, it can be considered to transmit a copy of the delivery message to the administrator of the GHR25. Basically, a delivery message is identical to a prescription, with a modification of status for each prescribed product: prescribed (and not yet delivered), delivered, refused (by the patient) or cancelled (possibly after mediation with the prescriber). A prescriber could receive several delivery messages for one prescription, at least if spread deliveries are allowed. Ideally, the delivery message also contains delivered products which have not been prescribed (and which can have an influence on the prescriber’s policy at that moment or later). A particular case is a delivery message following on a VOS prescription. The delivery message can inform the prescriber on which product was actually delivered. A delivery message is integrated in the prescriber’s EHR either as a document or structured by item. Ideally, the non-prescribed delivered products are added to the medication. 4.4.2. Exchange of vaccination data Vaccinations are at the same time medical/medical-administrative data with a relatively little degree of confidentiality and data involving very different care providers and institutions: • the coordinating primary care paediatrician • the coordinating primary care general practitioner • institutions for preventive medicine such as Kind & Gezin (in the Flanders region) and the “Medisch Schooltoezicht”. For the actual administration of a vaccination, each of these levels can be responsible.
25 To be considered whether this should be linked to an attribute of the prescription: “send delivery message to …”
194
J. Devlies et al. / Recommendations from a Belgian Expert Group
4.5. Medico – administrative services These services adress an important aspect of the care provision without aiming specifically at that care provision itself. They are related to the conditions on which these services, within the framework of the health insurance, can be granted and reimbursed. These services indeed contain/manage “personal data” concerning the care and health of the patient but are also accessible to persons other than the care providers, more specifically the services are of the health insurers. Under this group we have a number of services, a number of data “made available” and a number of reports mandatorily produced within the framework of the financial settlement of granted services by care providers and institutions. All these services are related to individual patients in opposition to some other supporting services, more specifically the identification services for care providers, practices, institutions etc.…. 4.5.1. Authorisation server services An authorisation server contains -in the Belgian context- information essential to judge whether a patient is qualified to receive reimbursements by the RIZIV for certain medical services (being or not under third payer regulation). These services address an important aspect of the care provision without specifically aiming at that care attribution itself. 4.5.1.1. Authorisation server insurability This is a service run by the insurance companies that is not really subject of this recommendation. This “authentical source” of information is mentioned here because of the analogy with hereafter described services. It is essential however, that each service provider can offer the authorised care provider (authorised because of their relation with the patient) that specific information. This implies that the source must be accessible, without discrimination in the nature (private, publicly) of the service provider. 4.5.1.2. Authorisation server medication At this moment the here described service does not exist. The description must be considered as a “proposal”, a possible scenario. An admission for intervention is produced by the medical service of an insurance institution and deposited on an authorisation server. There, this admission can be consulted: to here similar to an authentic source. The requesting prescriber is warned by means of a message by the same insurance institution (theoretically, the message could be initiated by the server application). The authorisation itself (content and syntax to be defined ultimately) is exported to a central authorisation server. Each authorisation contains: • Identification of the patiënt • Identification of the prescriber • Identification of the insurance institute • Identification of the authorisation • Name of the drug and dose + CNK code and description • Start date of authorisation
J. Devlies et al. / Recommendations from a Belgian Expert Group
• •
195
End date and/or number of packings Criterion of approval
4.5.1.3. Authorisation server other therapeutical services This is analogous to the authorisation servers insurability and medication, however concerning other health services for which a preceding approval is required of the medical service of the insurance companies. The data made available on a server include an identification of the nature of the service, an identification of the approval and data concerning the duration or number of services. 4.5.1.4. Patient-oriented authentic sources This is analogous to the authorisation server described earlier. This source contains the contractual agreements between care providers and patients. On these servers, interested parties involved in the care process of a patient, can (de facto) consult certain “contractual” data. An important example which will gain importance, are the contractual commitments within the framework of the care pathways to monitor chronic disorders, such as diabetes or kidney insufficiency. Other services which can be categorized under this group are: • Repertory Therapeutic Link to check a possible existing link between a care provider and a patient. Based on that link and authority of that care provider, access rights to health data could be managed. • GHR Repertory in which the active GHR agreements can be consulted, for example within the framework of a better an automatic reporting towards the GHR holder in case of second line care granted. A broader, yet similar concept is, that of the care team, the whole of the care providers involved in the care for an individual patient. Although these services are partly administratively oriented, the data should indeed be treated as confidential personal data. 4.6. Patient-driven services The patients’ involvement in their own care can be promoted considerably by offering a number of steering medically administrative services. Hereby a first list of those services: 1. Management of the care team, possibly allowing the patient to remove members of the care team. 2. Repertory of the GHRs, variant on the previous service. 3. Management of the approvals for certain contractual services, such as the care pathways. 4. Status information concerning the insurability. 5. Authorisation server for medicinal and other treatments. The realisation of these services seems rather “simple”. These services could be offered within a practice or at least made available from within a practice. These data
196
J. Devlies et al. / Recommendations from a Belgian Expert Group
are, however, of “public interest”. Therefore, a central management of these data must be considered as discussed in this document. Certain data could even come completely under the management/responsibility of the patient, such as a server with will arrangements concerning for example organ donation, euthanasia, blood transfusions etc.… Opposed to this involvement of the patient, there are also “obligations”, more specifically to take into account these interventions of the patient when administering and/or organizing the care for that patient. Besides that, in certain degree access could/should be given to an overview of both the own records as the different shared files that could be of interest: 1. The urgency file, with some comment on the confidentiality of the data and the possibility of adding comment26. The request to “remove” a particular data-item also is one of the patient’s rights, as far as asserting that right does not make the care itself impossible to the account of the care provider. 2. Temporary shared files, such as a prescription server (Prescription Pool Server) where a patient could possibly remove a prescription (that has not yet been delivered) (benefit?) or where the patient can approve the creation and sending of a delivery message or erase/amend that approval (for example with specification of another addressee). Also, the Personal Health Record (PHR) can enable the patient to insert his own vision on his care to a (partial) copy of the EHR included in the PHR. In essence, the Personal Health Record contains two types of data: • Data originating from a professional EHR, copied to the Personal Health Record. Generally, these data will correspond in an important degree with the data presently exported to the urgency file. It is very important to avoid “chaos”. This can only be done by stipulating very exactly and strictly who or which care provider could supply data. Mind however: a lot data coming from a professional EHR are not just like that appropriate to incorporate in the Personal Health Record: o Because for the modal patient these terms are not intelligible: translation is assumed o Or on the basis of the principle “primum est non nocere” o Or at the request of the patient himself, not everyone wants to know everything o Or because the privacy of another person could be compromised (for example hetero-anamnestic data) • Data, registered by the patient himself that could taken over –if identifiable- in / synchronised with the professional EHR Strictly, these “services” are not subject to this recommendation. They possibly only exist on project-basis. Nevertheless -in the future- these services will have an increasing impact on the care and on the (professional) management of health data in general.
26
The possibilty to add comment, should also exist in the professional EHR.
J. Devlies et al. / Recommendations from a Belgian Expert Group
197
5. Appendix B - Preconditions and supporting services In this chapter (cf. chapter 8 of the experts’ report [1]), we describe the general medicolegal and infrastructural framework necessary to enable professional exchange of data and sharing of patient data as well as the operational requirements which could/should be imposed on several service providers, public as well as private. Within the infrastructural framework, attention is also paid to the coaching of the users, among which training in the use of intended systems and support for their optimum use by means of individual “incentives” as well as through support for the organisations involved in this such as professional associations, scientific institutions and also the specific user associations of certified applications. This chapter does not discuss the actual development of each of these preconditions and services. The actual development of each service or promoting measure can be the object of separate recommendations once those services are ready to be developed. The structure of this chapter is presented in figure 2
5.1. Medico-legal and organisational preconditions 5.1.1. Definition of the competences / access 5.1.2. Legal structure and organisation of the access 5.1.3. Responsibilities, increased awareness and liability 5.1.4. Availability and updating of the health data 5.1.5. Identification / Authentication 5.2. Requirements of the EHR 5.2.1. The EHR (and the GHR) as synthesis instruments 5.2.2. The EHR (and the GHR) as source for decentralised collections 5.2.3. Use of content-related standards and coding tables 5.2.4. Use of formal (syntax) standards 5.2.5. Structuring and organisation of the data 5.2.6. Tuning the ambulatory and hospital sector 5.2.7. Services with a (medical) added value 5.2.8. Actual use and training 5.3. Security requirements 5.3.1. Management of the access to health data 5.3.2. Audit Log 5.3.3. Use of health data outside the care 5.3.4. Physical security of data
5.5. Necessary supporting services 5.5.1. Identification of services 5.5.1.1. Identification / authentication of persons 5.5.1.2. Identification of the patients 5.5.1.3. Qualification of the health professionals 5.5.1.4. Identification of healthcare institutions 5.5.2. Tasks of the healthcare professionals 5.5.3. Authorisation of healthcare professionals 5.5.4. Technical supporting services 5.5.4.1. Electronic signature 5.5.4.2. Notary services 5.5.4.3. Encryption service 5.5.5. Care-related identification services 5.5.5.1. Identification of a “therapeutic link” 5.5.5.2. Care team management 5.5.5.3. Patient master index 5.5.6. De-identification services 5.6. Training and support of the users
5.4. Confidentiality requirements 5.4.1. Confidentiality as a characteristic of individual patient data 5.4.2. Confidentiality as a filter on access to patient data 5.4.3. The EHR as working tool and the privacy of the care provider
Figure 2. Structure of appendix B – Preconditions and supporting services
5.1. Medico-legal and organisational preconditions To offer a functionally optimal range of services, a number of basic conditions should be fulfilled. A number of “agreements” should be reached, preferably in an official form.
198
J. Devlies et al. / Recommendations from a Belgian Expert Group
To these appointments and legal arrangements, a range of services have been linked, delivering services under control of an “instance”, not necessarily the government. Most of these services require however a centralised approach by means of coordinating services between the service providers. 5.1.1. Definition of the competences / access It should be defined who is granted professional access to certain EHR27 and in which professional quality this happens on that specific moment and for that specific patient. Together with the patient, the GHR holding doctor defines how the confidentiality rules should be applied, among which the access rights. This applies more specifically to “decentralised” EHRs. The definition of the competences and/or access does not only apply to the care provider. Also, changing competences of “patient” or “guardian” must be defined clearly, for example in their relation with family members, partner(s) and children. The powers not only count for the access aspect to a service but are also influenced by the nature of the data as described under 5.3.1. 5.1.2. Legal structure and organisation of the access The organisation of access must take into account increasing participation, involvement and inspection in the EHR by the patient and with the monitoring possibilities as described in 4.1.4.9 and aspects of patient-driven services as mentioned in 4.2 5.1.3. Responsibilities, increased awareness and liability Agreements are necessary concerning the respective responsibilities of the different actors for what concerns the content aspects, more specifically: • Loading and updating of decentralised data (decentralised records and decentralised EHRs) in function of the relevance of the data for the intended objective. • Clearing of decentralised data in function of the relevance or the lack of relevance (meanwhile). • Updating of regularly changing accessibility. One should come to clear rules concerning everybody's liability concerning for these services: • The liability of the service provider, for example when granting access to a non-authorised user or the offering off “incorrect” data. • The liability of the provider/uploader of the decentralised records and EHRs. • The liability of the care provider using/taking into account these files in good faith.
27
As stated in the introduction of chapter 5.2.
J. Devlies et al. / Recommendations from a Belgian Expert Group
199
On the other hand, the file-keeping physician is not relieved from a number of responsibilities because certain/many data would be stored on/in decentralised records. • The file-keeping physician remains responsible for the contents of the documents, but as stated, the responsibility of user of information must be weighted up against. • The file-keeping physician remains responsible for the preservation of the (original) data during thirty years, not the manager of the decentralised record.
5.1.4. Availability and updating of the health data The service provider, at least for the decentralised records with a clinical (caresupporting) objective such as the services for the management of the urgency data, must answer for a permanent availability of the data, besides of course the legal obligation to preserve the documents possibly ever consulted by anyone. The data must be accompanied of information concerning the date/the moment of creation of “uploaded” health data. That way, a “user” can take into account this element in its assessment of an offered package with health data. A file-keeping care provider responsible when uploading decentralised records is at the same time responsible for regular updates of those decentralised data. Out-dated decentralised data can be more damaging than no data at all. 5.1.5. Identification / Authentication Identification of the parties concerned (uploaders and users of health data managed by means of decentralised records) is an essential precondition for each service towards decentralised records. It is essential however that practices can be identified as source of information, at least for what concerns general practitioner medicine. Basically, it concerns in fact the identification of the information system (of the instance of an information system). Each information system has one EHR per patient, even if several care providers (possibly even playing a different role towards each individual patient) use the same system and therefore provide care to the same patients. In an intra-professional group practice (and even more in an extra-professional) is does not suffice to use a practice- (institutions) identification, at least when more than one information system is used within that practice. 5.2. Requirements of the EHR Before going into this part, we would like to repeat that the EHR should be, within the framework of this recommendation, regarded more freely than the EHR of the general practitioner (being labeled or not) and for which the users receive a “medical informatics” compensation. For the requirements of this recommendation each collection of (personal) patient data, built up by a care provider with the aim of documenting and looking after the care, is regarded as an EHR.
200
J. Devlies et al. / Recommendations from a Belgian Expert Group
The covering (overall) EHR is actually “virtual” and exist of the collection of EHR, of systems holding data concerning the same patient. The quality of the “synthesis” is mainly determined by the way in which the different collections are “addressable” with respect to content. It is important however, that within the framework of this recommendation, the temporary collections or collections not aiming care itself are not considered as an EHR. They are called “decentralised” collections of personal data concerning health. Collections derived from EHRs but not containing personal data, in fact also do not make part of this recommendation, except for a number of aspects concerning the supply of those data originating from an EHR. It seems obvious that the EHRs of senders and receivers of shared health data must be able to supply those data both substantively and formally, the latter in accordance with at least the National agreements. This has implications for those systems, implications which will be further discussed here. Note: the description of the ideal EHR, if it still exists, is not a task of this workgroup. The important certification of the systems itself, determining whether a system actually meets the requirements, also does not make part of this recommendation. 5.2.1. The EHR (and the GHR) as synthesis instruments The EHR and even more the GHR of the file-keeping general practitioner are due to document and follow up the care given to a patient for a long period of time (for life). The care is not limited to the care granted by that file keeping care provider or the administrator of the EHR/GHR, it includes in fact all care, also granted by third parties. The EHR of the hospital physician is rather intended for the documentation of (successive yet separated) care periods. A central hospital EHR documents the care of several simultaneous care episodes (of several care providers) in successive care periods. Most of the data are of intramural origin, but are not necessarily originating from the same (information) system. That means in the first place that the EHR of the general practitioner must be “open” for integration of data coming from third parties and of other care providers, whether or not temporary involved in the care for the patients for which EHR or GHR is kept. This openness applies both to a hospital EHR as to a collection of individual collections created by several care providers. It is also increasingly assumed that the hospital EHR is capable of integrating external data, e.g. supplied by the general practitioner as well as by a care provider from another hospital. In order to have a workable tool, the EHR should enable the user to manage one or more syntheses out of the multitude of data. These syntheses can be time-oriented but also identifiable for a particular patient in function of one or a collection of problems. An important condition to enable such syntheses is a thorough structuring of the data. The EHR is not only an instrument for documentation and synthesis on patient level, it also offers opportunities for benchmarking the practice / validated practice analysis. Specifically, this means that:
J. Devlies et al. / Recommendations from a Belgian Expert Group
• • • •
•
201
The system can communicate with one or multiple networks and systems where data can be "obtained" OR through which data are "made available". The communication specialist / hospital / GHR keeping practice of a GP almost goes automatically, without all the time renewing requests or active decisions of the file-keeping care provider to receive/send messages. There is a communication between care providers in all directions. The systems understand each other, assuming -in a bilingual country- that the messages are encoded content-related (at least for the essential data) and that the messages/collections exchanged are formally (syntax) mutually interchangeable. The system allows a structured registration, an essential condition to make a synthesis.
The unicity of the EHR is another important condition to be met to regard the EHR as the source of shared files or as the source of a file synthesis. That means that all data which could possible added to an external shared file (for example a clinical research file / external plug-in application) would definitely be incorporated /duplicated in the (main) EHR. That applies also to hospital files. Evolutions requiring externally recorded additional data -for statistical or scientific research- are therefore regrettable, at least to the extent that with such data a "parallel file“ is created. 5.2.2. The EHR (and the GHR) as source for decentralised collections Fundamentally, the EHR is the source of data for all possible decentralised collections or files. That applies to both the anonymised collections originating in one or more EHRs and to collections of personal data concerning health created “peripheral” to the EHR. Examples of such collections of personal data are: • Core files or urgency files (Patient Summaries) • Collaborative files • Registers and/or Thematic files • Clinical Research / Trial Files • Prescription repositories • Research databases (as far as longitudinal) personal data are required. • Vaccination files • Export for second opinion services or external decision support. • The clinical data to be transmitted by hospitals to the government/insurance companies (Medical Registration, SMURREG, Cancer Register, …). Here, we do not discuss the purely anonymised data. Neither do we discuss pseudonymised data where data either longitudinal or coming from several sources, or a combination of both must be assembled, and where “the involvement towards the same patient” must remain traceable, this without compromising the identity of that person.
202
J. Devlies et al. / Recommendations from a Belgian Expert Group
Some important principles: 1. The EHR’s main issue Some of these files assume the presence of very specific data in the file which are possibly not present in the EHR of origin of the data. A specific interface for data import for that shared file is possible, on condition however -as discussed under the concept “unicity of the EHR”that the data then added are also integrated in that EHR. 2. The content-related proportionality For each shared collection, it should be carefully stipulated which data must be made available for a specific purpose. 3. The responsibility of the “exporting instance” Each export from an EHR (and GHR) is done under the responsibility of a care provider, who also becomes also partly responsible for the “normal” use of these data by the addressed care providers. Each exporting physician should therefore by able to “confirm”, “prevent” or “modify” the export in function of its appraisal of the status of the patient at the moment of the export and in function of the aim of the export, as judged by him/her. That implies, however, that “export” to “shared files” should be traceable and reproducible with the possible modifications done by the responsible care provider supplier to that export. 4. The availability of shared files The main issue of the EHR also implies that the existing data within that EHR can easily be used for the (automatic) generation of shared files, guaranteeing the confidentiality of the data. 5.2.3. Use of content-related standards and coding tables For analysis and structured use of the data (e.g. analysis of care pathways) and to enable integration in the EHRs of all care providers, a language-independent and encoded system is advisable. The system should use internationally accepted encoding and classification systems (ICD/ICPC/ICF/LOINC/CCHI…) This does not nearly apply only to the data for which conventional encoding tables are available, but for all option lists offered within a system. In spite of all efforts done at international level, we have almost achieved nothing. Without the ambition to be complete, hereby an overview of a number of concepts for which either no standardised table exist or for which no consensus exists concerning which tables must be used: • Title • Nature of a patient contact (apart from the RIZIV-tarification) • Nature of discharge from a health institute • Nature of admission • Nature of possible technical diagnostic examinations • Importance of a diagnosis • Certainty of a diagnosis • Severity / extent of a diagnosis / injury
J. Devlies et al. / Recommendations from a Belgian Expert Group
• • • • • • • • • • • • • • • • • • • • • • •
203
Profession and risks Nature of the objects in the EHR Nature of procedures (surgical or not) Specialty Advise / referral by specialist Civil status Urgence Biometric data (length, weight,…) Care pathway IDs Approvals and denials of the patients Nationality Language Reason for creation/closing of record Social layer Education Type of patient (observation, coincidental, GHR patient, …) Types of care episodes Topographic indications Pharmaceutical form Administration form Product unit Therapeutical interventions All kinds of measurement values, e.g. spirometry
A language-independent identification of these data and the possible values which can be registered are essential when exchanging components of a record but also for interpretation of these data within the framework of each decision supporting action. 5.2.4. Use of formal (syntax) standards Data exchange, transfer of data between systems, assumes the use of syntax, a structuring of these data. The Belgian market is characterised by a number of “de facto” standards commonly in use (in several variants) for extramural data exchanges. Besides that, messages are going round making use of a “national solution”, namely the Kmehr syntax. Apparently, the intramural data exchange tends more and more to the HL7 standard whereas the data exchange between the care providers/institutions and insurance companies can be called archaic but efficient. Most of the syntaxes simply aim at transferring factual data. When however record components -including the content-related links registered within the EHR of originmust be provided, more complex syntaxes are necessary, ever more complex than the current Kmehr models. Standards of contents and structure are brought as much as possible in line with the current international standards.
204
J. Devlies et al. / Recommendations from a Belgian Expert Group
5.2.5. Structuring and organisation of the data The need for and the nature/degree of structuring and organisation of the data in a shared file depends on the objective of these shared files. The GHR/EHR of the file keeping physician is however only capable to understand the fullness of the interaction between care provider, patient and health data when the system is able to understand the “relations” between the data. A nonexhaustive list of “structuring” that would have to become progressively available in all EHR systems: link cause/consequence on for example side effects or adverse reactions, indication/operation for treatment, concepts as problem-oriented registration, care elements, care approach, etc.… This structuring also enables the user to produce specific “syntheses”, or rather cross sections of the record. Evidently, the users must then make use of the possibilities offered by the systems. That assumes an important training effort. 5.2.6. Tuning the ambulatory and hospital sector It is important to do some efforts for better tuning between the ambulatory and hospital sector for both conceptual and data encoding. Reporting from the hospital sector cannot remain limited to a –however extendeddischarge letter. Data should be offered increasingly in a structured way, using the same encoding tables or at least making use of a validated mapping. One action point is the migration from ICD-9-CM in the hospital sector to ICD-10 that it is used in the EHRs for general practitioners. ICD-10 is based on a Thesaurus offered by the government. Possibly, it must be extended further to improve the usability within several sectors (e.g. adding toxicology list, accident descriptions and locations). This way, the complete ICD-10 would be comprised which is currently not the case yet. 5.2.7. Services with a (medical) added value The EHR/GHR evolves more and more of “store and retrieval" to actual management tools, involving not only the processes managed (as mostly in the hospital sector) but with services that increasingly and effectively support the practice / care provision: • Services which offer or might offer in most cases an administrative added value, such as services related to medication or with the initiation of a care pathway • Decision support when doing a prescription (selection of medication, possible contra-indications, etc…) • Management of care pathways • Identifying risks or indications to take preventive actions important for a certain patient • Etc... Sometimes/Often, these services are offered by interactive or integrated “modules” in the EHR systems.
J. Devlies et al. / Recommendations from a Belgian Expert Group
205
These services are however also offered by “plug-in” applications which either locally (on the system) or distantly: • Use data from/in the record • Offer recommendations, warnings or data to the EHR. Encoding and structuring are essential. The guarantees for safeguarding the personal privacy clearly also apply to external services. 5.2.8. Actual use and training The current EHR systems, at least the accredited systems for the general practitioners, offer a great deal of functionalities and –based on the labeling of the packets- a lot of possibilities for encoding, structuring and reporting of these health data. Not only are there a lot care providers using no EHR system (around 40% of the general practitioners, possibly even more for the hospital physicians). A lot of care providers only use their system for rather administrative functions such as the integration of laboratory results. On the one hand, the proportion encoded/free text data in terms of percentage differs from system to system. On the other hand, structuring of the data occurs clearly in less than 15% of the contacts. All this indicates that a very important effort must be done in training the care providers in general (usefulness and necessity of an EHR) and the users in particular (encoding, structuring, syntheses etc…). 5.3. Security requirements 5.3.1. Management of the access to health data Checking the identification and authority of an access-requesting provider should also take into consideration the setting of the care provider at that time. The agreements on the “standard” authorities of each care provider, but also on "temporary" authorities, should be established by a central coordinating body / central coordinating bodies. In emergency situations, a "necessity knows no law” procedure should be provided to grant data access. Management of the access to health data assumes several checks on the identity and the role of person concerned in relation to the patient. When granting access to certain data, one should also consider the nature of the data. Decentralised records, for example an urgency file, can on the one hand contain data of very different nature such as less “sensitive” factual data (measurement values, blood pressures etc.…) and on the other data that should not always be available to everyone (in function of the role of the “retriever”) such as psychiatric data or gynecologic/obstetric antecedents). Such a differentiated access control assumes, however, a management of confidentiality both at the data-providing EHR and at the service provider. This aspect is also discussed in chapter 5.4. 5.3.2. Audit Log Each service provider can document -during a contracted period- who has had access in which capacity to the data of a certain patient.
206
J. Devlies et al. / Recommendations from a Belgian Expert Group
Every access to the system is communicated automatically to the central administrator (role of social control on access to patient data). Alternatively, one could establish a “social control”. Also in this case, every access is communicated to the administrator of the GHR and/or the uploader of the concerned health data. 5.3.3. Use of health data outside the care Use of health data outside the care is inevitable. More and more, care suppliers administrators of well structured EHRs- will be approached for use of these data for: • Scientific research • Epidemiologic research and monitoring of the public health • Decision supporting research • Clinical trials in the development of new medicines (following certain “voluntarily associated” patients individually) or at the early detection of side effects/adverse events of drugs and treatments. Turning Belgium into an island where nothing is possible does not seem advisable. More likely, it seems to be the task of the government to provide a context to make such services possible. This assumes the definition of terms service providers must meet concerning the confidentiality of health data within all of these contexts, including the services each service provider must acknowledge. It is unthinkable (and probably not advisable) that all these data flows would only become possible using a service provider controlled by the government. 5.3.4. Physical security of data Systems should be sufficiently protected for physical failure or locking. Back-up solutions must be foreseen so the individual assistance never becomes compromised. Adequate guaranteeing must be built in to monitor the daily updating of the data. If data are not guaranteed continuously up-to-date, significant iatrogenic errors could occur. 5.4. Confidentiality requirements 5.4.1. Confidentiality as a characteristic of individual patient data In consultation between patient and file administrator, each separate component of the patient data should be lockable by means of a degree of confidentiality or a filter based on a level of confidentiality. Actively adding a “confidentiality” aspect for every registration it is not necessary. Based of a consensus, default degrees of confidentiality can be granted in function of the nature of the data (factual data versus for example simple diagnosis or psychiatric data). 5.4.2. Confidentiality as a filter on access to patient data One way to enable this confidentiality filter in a performant manner, is by coupling the patient/health data to care problems, sometimes also called care elements. This way,
J. Devlies et al. / Recommendations from a Belgian Expert Group
207
data of a specific problem area can be filtered or offered to specific care providers in function of his/her authority or role in the care for a patient. The patient should be involved when certain parts of the data are made unavailable to anyone or only to identified groups of care providers. As discussed in the preceding paragraph, it can be realised by building in an individual degree of confidentiality. Differentiated access to the patient data is in any case a prerequisite when making accessible or shielding parts of the data. It is nevertheless important to lay down the responsibilities of the various parties involved. This, in case certain health data cannot/must not be made available based on explicit demand of the patient, translated in an increased confidentiality of those data. When requiring data from a decentralised record, it seems advisable to inform the care provider that certain data are not made available. In this appropriate case, the patient himself can decide whether or not to provide those data. 5.4.3. The EHR as working tool and the privacy of the care provider The “working file” of the care provider does not belong to the data that can be incorporated in the decentralised data. Normally, only certain components or data are to nature exportable components of the EHR. For this reason, each EHR system must contain components for personal notes of the care providers. These will remain professionally shielded from third parties or the patient himself28 for export or retrieval purposes. Yet, it appears however necessary to make certain components or parts of those data available to other care providers for example within the framework of a collaboration between independent care providers and/or various practices. 5.5. Necessary supporting services Some of the “supporting” services described hereafter, have been discussed partially in the previous chapters. They must be considered as “generic” services, independent of the (clinical) field of application. 5.5.1. Identification of services 5.5.1.1. Identification / authentication of persons eHealth29 identifies persons by their national ID number, supplemented by the of social security number bis for foreigners. Authentication is done using the electronic identity card. The latter contains a password protected authentication certificate. eHealth should provide solutions with Fedict for people who do not yet have this system (foreigners, children under 12 years) or for emergency situations (loss of eID). Individual authentication is done via a HTTPS session. The user must therefore use his electronic identity card for interaction with eHealth. It would be useful to develop an authentication system between systems to ensure an institution’s connection with eHealth, on the same principle as the current Carenet system.
28
This does not mean that data can be claimed in case of legal disputes. After all, a provider should be allowed to use this information to defend a pursued policy. 29 In this text, eHealth is used as well for the project BeHealth as for the proposal for the eHealth platform, currently subject to political approval.
208
J. Devlies et al. / Recommendations from a Belgian Expert Group
5.5.1.2. Identification of the patients eHealth and eCare have obtained permission to use the national registration ID (complete with the social security number bis) to identify patients within the framework of exchanging medical and administrative data. In its recommendation for the eHealth project, the privacy commission has reconsidered its initial desire to create a specific health identification number. We believe that under these conditions, all health professionals should be able to use the national registration ID to ensure the reliability when exchanging electronically medical data of patients. When this is not available, eHealth should establish a system to manage a unique primary patient identifier via a web service. 5.5.1.3. Qualification of the health professionals A register of health professionals is made available by eHealth via web services. Currently, the register takes up: • The « qualities » of the professional according to SPF Santé Publique • The « qualities » of the professional according to l’INAMI-RIZIV (National Health Insurance Institute) 5.5.1.4. Identification of healthcare institutions A register of healthcare institutions managed by the SPF Santé Publique is made available by eHealth via web services. The offices of general medicine, for both group and solo30 practices, should be included. 5.5.2. Mandates of the healthcare professionals eHealth can define tasks for a healthcare professional within an institution. It concerns assigned profiles, collaborative relationships within an organisation. This service is called 'Public Health Mandates' = PuHMa. The task management allows entities to delegate the right to use one application to another entity. Entities are people, service providers or groups of caregivers. This data is accessible via web services. It is currently being used by MyCarenet. It should be made available to the various concerned healthcare workers. 5.5.3. Authorisation of healthcare professionals eHealth makes it possible to define a hierarchy within an organisation and to grant access rights there. This service is called `Responsability Management Public Health' = ReMaPH In any organisation a local eHealth manager is charged to define this hierarchy and to assign the rights. This data is accessible via Web services. It is currently being used by the Cancer Register and eCare-SAFE. It should be made available to the various concerned healthcare workers.
30 Solo practices not always remain solo practices (temporary collaboration of a colleague following a specific training) or change of ownership (resumption of practice retaining patient data).
J. Devlies et al. / Recommendations from a Belgian Expert Group
209
5.5.4. Technical supporting services 5.5.4.1. Electronic signature The validity of the signature based on the electronic identity card on medical documents (for example prescriptions / certificates) should be ratified as soon as possible in the law. The healthcare institutions should be discharged from using the electronic digital signature for their internal data exchange, but only when using the e-Notary service described below. 5.5.4.2. Notary services A notary service should make it possible to memorize the signatures of the transactions done in the different medical systems such as an intra-hospital computerised prescription. These signatures must be associated with an acknowledged time-reference frame. This implies the mechanism of time-stamping; pre-condition for any management system of non-repudiation. eHealth currently is developing a service of time-stamping. It would be useful to extend it to a notary service. 5.5.4.3. Encryption service eHealth should make a PKI available to both healthcare professionals and institutions. This would allow data encryption. 5.5.5. Care-related identification services 5.5.5.1. Identification of a “therapeutic link” The actual role of a care provider to an individual patient must be defined in function of its usual professional authority and his role in relation to the patient at the moment of the data access. This source of information can contain data of various natures such as: • Is the care provider holder of the GHR31 • Does the patient have a care pathway agreement (with possible explanation of the term)32 5.5.5.2. Care team management The care team is rather a "permanent" patient-oriented concept. It includes all healthcare providers participating/having participated in the patient care services or those who have the opportunity to grant services. Thus, certain care providers can be incorporated in the individual care pathway of a patient, without -at that particular moment- having granted care already. Also “non-professional” persons or services can be partner in a care team, for example persons from the volunteer aid. 31 A consideration here is whether such a service is appropriate to inform a third party on who is the holder of the GHR for a particular patient… although the need exists for medical specialists who are required to send a report to that physician. (An option would be to not inform another GP?) It must however be possible to obtain confirmation that the data-retrieving person is the holder of the GHR and thus able to do certain transactions requiring that one is the holder of the GHR. 32 Neither does it seem appropriate that via this way, the data-retrieving person would learn with whom (which phycisian and specialist) a care parthway agreement was established.
210
J. Devlies et al. / Recommendations from a Belgian Expert Group
Also for this function, it seems essential to define a group or department able to play a certain role in the care for that individual patient. The following elements can be incorporated in a care team: • Name of the care provider • Name of the service / group / practice / department (supplemental to the name of the care provider) or in place of • (Professional) role in relation to the patient • Start of the involvement in the care (optional) • End of the involvement in the care (optional) The general practitioner -holder of GHR- is by default member of the care team and co-manager of the team. The patient plays (of course) an important role when composing his care team. For this reason, the patient must have the tools to modify and validate the composition of his care team. To make this possible, a central management of the care team -with access possibilities for the patient- seems appropriate. 1. Permanent members of the care team. 2. Temporary members of the care team (replacement, overnight duty) 3. “Unexpected” members of the care team (rather a procedure) 5.5.5.3. Patient master index A patient master index is basically a file for the management of patient identities. Mostly (always?), they are translated to internal system-characteristic identifiers. In principle, each collection of patient data has a patient master index. Patient master indexes can be merged into overall indexes, such as a functional integration in locator services or data reference services. 5.5.6. De-identification services De-identification services are not required for data exchange between care providers, at least not within the framework of healthcare. After all, care assumes personal data. As far as and since the care is “shared” by several care providers, a unique patient identification is an absolute condition to make data sharing/exchange possible. Earlier in this document, this aspect has been discussed already. De-identification services become however essential as soon as patient data are used for other aims than the strict care. • Generally, anonymous data can be used fur such purposes (at least in case of a one-time data provision). • As soon as data, provided at several points in time (originating from the same source) have to be merged, at least one unique source-characteristic or consistent identification is required. • As soon as data, originating from several sources for the same patient, have to be merged without revealing the identity, special de-identification services are required. Traditionally, these services are offered by specialised service providers. They include the TTP (Trusted Third party) services with among others the creation of a pseudo-identity.
J. Devlies et al. / Recommendations from a Belgian Expert Group
211
This subject is particularly important for the decentralised records. Mainly important here is that: • clear functional and quality requirements apply to the service providers • a complete independence is guaranteed. Among others, there should be no commitment (direct/indirect) between the service providers and parties responsible for the creation of patient data (systems of origin), parties responsible for the data collection, nor with parties responsible for the use and/or (content-related) processing of the collected data. All other aspects related to this service are of a more technical nature and therefore not discussed in this recommendation. 5.6. Training and support of the users An optimal use of information technology in general and of the EHRs in particular assumes an adequate knowledge of the instrument and skillfulness in its daily use. In the field, we commonly came to the following observations: • There are still a lot of users with a poor knowledge of their own EHR system in spite of all the training opportunities offered by providers of these systems. This leads to a limited use and poor added-value. It is not at all exceptional that a user confines oneself to collecting, storing and retrieving “external data”, such as laboratory results or reports of medical imaging. • In spite of the possibilities offered by the EHRs, still a lot data are stored as free text. Encoding is not done systematically by each user, although a lot systems offer that possibility in a rather user-friendly way. • Structuring the data with among others the problem-linking/care elementlinking is done rather sporadically than systematically. For this reason, training of and support for the users are very important. It does not make much sense for producers to invest in ever more advanced functionality, only for the happy few who make use of it. • Initially, training in the use of information technology (elementary techniques) should be incorporated in the basic curriculum of each care provider. • Moreover, there should be training in the use of encoding tables and the structuring of patient data. • Finally, optimising the use of the own EHR should be encouraged as well. A research done by the RIZIV shows there is a link between the intensity/quality of use of an EHR and the membership of a user association. For this reason, user associations should actually be supported and acknowledged as one of the parties concerned, as representatives of the users.
212
J. Devlies et al. / Recommendations from a Belgian Expert Group
References [1]
[2] [3] [4]
Groep experts “MIM”, Advies aan de nationale Commissie Geneesheren – Ziekenfondsen betreffende het Medisch Berichtenverkeer en een Decentraal Dossier voor Documenten en Zorggegevens, project financed by the Belgian National Health Insurance Institute, MIM vzw ed., Brussels, 2008, 121 pp. Technical Report. http://www.inami.fgov.be/care/fr/doctors/general-information/agreements/2006-2007/index.htm http://riziv.fgov.be/care/nl/doctors/promotion-quality/study_computer/index.htm http://riziv.fgov.be/care/nl/doctors/promotion-quality/study_computer_specialist/index.htm
Collaborative Patient Centred eHealth E. De Clercq et al. (Eds.) IOS Press, 2008 © 2008 The authors and IOS Press. All rights reserved.
213
Subject Index after-hours care 92 anonymization 67 certification 82 chronic diseases 38 clinical archetypes 82 clinical pathways 149 computerized 92 computerized patient records 3, 103, 149 consumer health information 57 controlled 3 cooperation 23 data collection 103 data protection 67 database management system 139 data-exchange 38 decision support systems 11 document imaging 121 document scanning 121 early diagnostic 11 eHealth 11, 38, 47, 162 electronic health record(s) (EHR) 23, 75, 82, 139 electronic medical record 121 electronic nursing record 130 electronic patient file 32 evaluation studies 92 evidence based management 11 family 92 genetic research 67 health information policy 162 health network 23 health services 57 HL7 139 home care services 38 hospital 38 implementation process 130
information and communication technology 11 information systems 11 innovation 23 intensive care 139 knowledge 11 legal aspects 47 legal liability 57 medical informatics 11 medical records 103, 149 medical records systems 92 personal heath record 11 physicians 92 physiotherapy 75 prevention 11 primary health care 103, 149 privacy 111 privacy enhancing technology 111 process evaluation 130 professional relationships 23 pseudonymization 67, 111 public health informatics 57 quality 82 quality management 11 questionnaires 92 referring physician 32 registry 75 software 139 standards 3 telemedicine 47 treatment 11 user-computer interface 92 vocabulary 3 web access 32 workflow management 11 XML 75
This page intentionally left blank
Collaborative Patient Centred eHealth E. De Clercq et al. (Eds.) IOS Press, 2008 © 2008 The authors and IOS Press. All rights reserved.
215
Author Index Aerts, W. 32 Arning, M. 67 Artoisenet, C. 23 Bellon, E. 121 Burggraeve, P. 103 Buyl, R. 75 Buysse, H. 38 Callens, S. 47 Cierkens, K. 47 Claassen, R.A.B. 130 Claerhout, B. 67 Closon, M.-C. 23 Coorevits, P. 38 De Clercq, E. 103, 149, 162 De Deurwaerder, A. 32 De Meyer, F. 111 De Moor, G. v, 38, 67, 82, 111, 149, 162 de Witte, L.P. 130 Devlies, J. 82, 149, 162 Feron, M. 121 Forgó, N. 67 Goossen, W.T.F. 3 Homble, H. 121 Jonckheer, P. 103 Kalra, D. 82
Krügel, T. Lafontaine, M.-F. Lagae, R. Massaut, J. Neyens, P. Noppe, T. Nyssen, M. Ons, C. Peeters, K. Pierlet, N. Purcarea, O. Reed-Fourquet, L. Reper, P. Roland, M. Rutgers, M.J. Schils, E. Sweertvaegher, M. Thienpont, G. Thomeer, K. Van Bemmel, J.H. Van Casteren, V. Van den Bosch, B. Van Gyseghem, J.-M. Vanautgaerden, M. Vandenberghe, A. Verwey, R.
67 103, 149 121 139 121 32 75, 92 121 121 32 11 111 139 23 130 32 121 38, 149 92 v 103, 149 32, 121 57 32 162 130
This page intentionally left blank
This page intentionally left blank
This page intentionally left blank