EHR systems - Future developments

Transcription

1 EHR systems - Future developments Gerard Freriks EN13606 Association, Electronic Record Services B.V. gerard.freriks@en13606.org Position Paper It s the economy, stupid said Bill Clinton 1. It s the semantics, stupid is the topic for this position paper. For a long period of time of more than 35 years Electronic Health Record (EHR) systems 2 are developed and used. There is no dispute whether patient data that is kept in an EHR-system has many advantages such as: a safe and full documentation of the healthcare provided, exchange between co-operating healthcare providers, generation of invoices or reports, education, clinical decision support, support of clinical pathways, clinical and other re-use for research, etc. Many of the potential benefits have not been realised. There has to be a missing piece of the puzzle. This position paper will answer the question why and will point out the solution: at least a European or preferably a worldwide supporting INFOstructure as a publicly financed organisation that produces, maintains and publishes semantic interoperability artefacts. 1. Introduction Many European and other (national) projects and huge investments in standardisation efforts over more than 35 years of time have not brought about all the benefits of an Electronic Health Record. Huge amounts of resources and many highly motivated politicians, IT-specialists, project managers, healthcare providers and their organisations have failed. All the projected benefits have not come to fruition. It is difficult to argue that all those projects were underfunded or mismanaged and that big projects always must fail. When we humans can wage wars on a world scale, when we can send people to the moon and back, when we can have a CERN physics research facility, it proves that we can be successful in big projects. Could it be that until now we overlooked one essential missing piece of the puzzle? And that when addressed properly we can reap the benefits of the EHR? This paper will not address all the ethical, legal, and usability issues but will focus on what is needed for the safe exchange of data and information over time and over distance, across disciplines, across languages and across cultures Gio Wiederhold. (1979). Stanford Computer Science Department. Report No.STAN-CS March

2 This position paper will point at the essential line of reasoning, the co-operation, types of investment and political support we dearly need as an important piece of the puzzle. 2. EHR-system expectations What we expect from health IT and what is suggested by the vendors is that the present IT-solutions provide an EHR. And yes, the IT-systems can store data and information and have a lot of functionalities and, most importantly, have screens that suggest that these systems are fit for purpose. There is nothing the IT-vendors could not provide, is the sales mantra. What do we really expect and are implicitly/explicitly lead to believe that the IT-systems will provide? We expect, that each health IT-system is capable to store, archive, retrieve and exchange all its data seamlessly with systems of other vendors. In the extreme we expect that data and information, stored now, can be retrieved, read, and automatically processed by systems that have yet to be designed and used by healthcare providers, that have yet to be born in other countries, using other languages and cultures. And that clinical decision support systems can safely process all the archived data in the future. We expect full semantic interoperability. 3. Present day most common interoperability solution The hard reality is that, although systems are very functional, they are very static and monolithic. At best they provide a kind of interoperability within an organisation. But there are examples where even that proved to be impossible. There are hospital/ehr systems 3 that when installed, are deployed per department facilitating their own work processes and there own information needs. Because of the design and specific deployment, these departmental systems proved to be incapable to interact fully and safely with other departmental systems, in spite of the fact that all were using the same vendor system. Semantic interoperability between the departments was not part of the explicit requirements, apparently! In case semantic interoperability between departmental systems had been a requirement, vendors could have achieved this within one organisation. But then we would have had the same problem at the next level: exchange between the hospital and other healthcare providers outside the hospital. Almost always the semantic interoperability between EHR-systems from different vendors is not existing, apart from limited exchanges using messaging standards. An advocated solution for intra- and inter-organisational (some times regional or national or cross border) is the Message Paradigm with messages based on Edifact or HL7 or DICOM. This technical solution is capable to transport fixed data sets between databases of different vendors. But at a hefty price. It takes a lot of resources to produce these message standards, implement this technical solution in EHR-systems and test it. 3 Personal communication by Jan Talmon. Chair WG Technology Assessment and Quality Improvement at IMIA 2-11

3 It is estimated and shown in several projects 4, that it takes 2-3 years to produce the message standard and at least 1.5 years to implement and test an IHE profile 5 in IHE Connectathons. At present there is a huge industry worldwide making money out of this technical message solution: HL7, DICOM, IHE, and many consultants and systems integrators. EHR vendors are commercially rewarded for what they do not provide: semantic interoperability. Because these solutions are complex and take a lot of time to define and test and implement these solutions have as side effect that they are brittle and once implemented can not easily be changed; they are inflexible. They do not support health innovation. One of the particular factors in healthcare is that each healthcare provider is unique, each department is unique, each organisation is unique, each speciality is unique, each country is unique and each patient is unique and each patient treatment process is unique. In spite of all this, healthcare providers have a lot in common. They work roughly the same but all use different EHR-systems, use different words and different codes.the most striking thing they have in common is the fact that healthcare providers are very efficient in exception handling. Alas. EHR_systems do not support this well. On top of all this, healthcare is in a constant state of flux. It is for ALL these reasons that healthcare providers need very adaptive EHR-systems that can deal with ever changing contexts, circumstances, new knowledge because of advances in health sciences, and clinical and organisational workflows. The Message paradigm will not support the needed flexibility. When stored, all data and information will eventually re-used for research and reporting. These static Message standard solutions can not create solutions that are flexible enough to deal with the ever changing needs in health research, because only fixed sets of data as defined by the message standard can be re-used. Message standards that needed a lot of resources and testing to implement. An other part of the problem is the fact that several competing coding systems are in use with considerable overlap. This is an additional factor why generic, ubiquitous, safe semantic interoperability is non-existent. 4. What is an EHR? There are several interpretations in use. Some National projects define one Patient Summary Message and ask/force/seduce the vendors to implement this message. Healthcare providers can exchange data between their data bases. Only data as defined in the message can be exchanged and adaptation to local needs is impossible. It creates an environment that is static and not facilitating innovation. 4 EU-epSOS project started 3 years ago, Recently the first messages were installed and deployed. 5 IHE needs 1.5 years minimal to produce a profile and test it in connectathons ftp://ftp.ihe.net/it_infrastructure/iti_educationalmaterials/currentpublished/ihe-introduction_ ppt, Slide

4 Figure 1: EHR using a central switch and standardised messages There are several examples of National projects 6 where the Patient Summary is automatically assembled via a national/regional switch point (the Act Registry 7 ) that knows the location where data about a particular patient is available. Such a set-up creates, because of the message standards used, inflexibilities that prevent innovation in healthcare. An additional problem is that, since each author is fully responsible for his texts, no one is the responsible author of the automatically assembled Patient Summary. In this way it is difficult to hold any one solely accountable. Any EHR architecture must be a system that is able to document all healthcare that is provided in such a way that all data and information can fully be attributed to its responsible author and can be safely exchanged and transported over time and space without any loss of meaning. 6 England, Austria, Netherlands

5 Figure 2: The generic EHR In the generic EHR each author uses his own documentation system (EMR for healthcare providers and PHR for the patient and its surroundings). Data and information is documented by an author (healthcare provider or patient) to his EMR or PHR. All data and information is placed by the author in the (restricted) public domain because of a conscious decision. One person is accountable. The data and information can be in this (restricted) public domain under control of the author AND the data subject (patent) for a split second or forever or anything in between as regulated by a policy defined in a Patient Mandate. The CEN/ISO EHR-communication standard has defined (in part 4) the Patient Mandate. In this mandate the access policies can be defined and attached to data in the EHR. Plus it can be exchanged. Under exceptional circumstances it must be possible to overrule the Patient Mandate and its Access Control policy; the author and data subject must be alerted automatically. Who has access to the patient data and what is he allowed to do is expressed in an Access Control List, names the Patient Mandate. The patient mandate is a set of policies attached to data and information in the record or the EHR-Extract when communicated. When the data is exchanged the Patient Mandate is exchanged together with the data. The Patient Mandate acts as an access control list (ACL) that specifies who and what roles have or do not have what rights for reading, changing, deleting, etc. Most systems regulate access to data per patient record. The Patient Mandate must be firmly attached to the data and information. This calls for it to be defined in a semantically interoperable way. Existing messaging standards do not have facili- 5-11

6 ties to attach security policies at the data level. Only the CEN/ISO EHR-communication standard 8 has these Patient Mandate facilities. When data and information is stored in the Electronic Medical Record (EMR) and/or the Personal Health Record (PHR) and made available via services in the (restricted) public domain all this (EMR, PHR and the public part) are called an EHR-system. The data can be published freely in this public domain or be restricted because of the Patient Mandate policies. All data and information in the EHR-system, as described, had better be fully normalised and fully semantically interoperable. Since many existing EHR-systems store data and information in databases in a proprietary and suboptimal way in local EMR-systems at least the data in the (restricted) public domain must be available there in a normalised way. 5. What needs to be semantically interoperable? All patient and health related data needs to be interoperable. Many think that limited data sets in message standards are enough. But this is not enough. More needs to be made interoperable: 1. Clinical work processes, 2. The Patient Mandate Two additional foundation standards are presented in this section that help make more types of data interoperable. Clinical workflow: Since healthcare providers as users of databases (EHR s) co-operate with others, EHR-systems must support this co-operation,.and let work processes and clinical processes become interoperable. It is for this reason that CEN and ISO worked on the standard for System of Concepts for Continuity of Care (ContSys) 9. For complete semantic interoperability of data and information documented in EHR-systems it is necessary that the co-operating health care providers can share their local words related to clinical workflow with others. A CEN/ISO standard (System of Concepts for Continuity of Care 10 ) is in place and in the process of renewal and extension. Privacy/Access control: Patient Mandate The privacy of patients is an big issue 11 that creates many political, legal and implementation issues. The moment data is exchanged between systems, the moment data is archived and re- 8 and 9 CEN/ISO ContSys standard 10 ContSys is not to be confused with CCR/CCD as message specifications for continued care, ContSys is a terminological standard that defines terms used in the context of continuity of care. 11 Ross Anderson. An Update on the BMA Security Policy

7 used later, it is essential that together with the data the Patient Mandate is stored as is explained in section 4. At present there is are two related standards that allow the preservation of the Patient Mandate (CEN/ISO part 4 and ISO standard for Privilege Management and Access Control 12 ). In this way a policy, as desired by the patient, can indicate who has access and who is allowed to process the data. On top of this Patient Mandate European legislation and implementation issues need to be formalised. 6. EHR-systems need an supporting INFOstructure Even when these CEN/ISO foundation standards are in place; we need much more to achieve semantic interoperability. Only when semantic interoperability is in place and EHR-systems start to exchange, only then we will be exposed to the next level of challenges, but these are not the topic of this paper: security and privacy with exchange at a large scale and across several jurisdictional boundaries; usability and user interfaces; data and information quality; quality assurance. EHR-systems need to be able to safely and completely store, archive, retrieve and exchange anything in such a way that all semantics are expressed. Local healthcare providers must be able to decide what will support the documentation of health data and information in their own local work processes. And be able to change their minds and co-operation agreements to exchange data or co-operate at any moment. And when archived, systems and users of the future must be able to understand data, use it for research, as allowed by the Patent mandate, and have computer systems provide the service of clinical decision support. All this means that data and information must be available and exchanged in a highly standardised format. A format that can be used by all and in many cultures, languages where several coding systems are in use. When we want to be able to do this across many jurisdictions, legals systems, specialties and languages, we need a semantic infrastructure that provides these services. What is needed is described in the Semantic Stack. The Semantic Stack is depicted in figure 3. It defines 5 layers that are needed to create an IN- FOstructure. The content of this stack and how all the semantic interoperability artefacts are produced, governed, published and financed, is called the INFOstructure. 12 ISO PMAC standard csnumber= EU Privacy policies 14 ARTICLE 29 Data Protection Working Party 29/index_en.htm 7-11

8 In Europe we have many (26) languages and many borders, different cultures and legal systems. When we want semantic interoperability in Europe we have to co-operate. In other countries such as the USA, Canada, Australia the problems are as big as in Europe but have the benefit of much less diversity. The particular situation that Europe and its Member States are in is the reason why in Europe developments around semantic interoperability are more advanced. Producing, maintaining and quality assuring components of the Semantic Stack in the INFOStructure is a very human intensive resource needing the skills of many highly trained collaborators. Even for big countries 15 this is a task that is too large. Because of its importance, size and the substantial resources needed the INFOstructure needs to be maintained and financed by (at least) all European countries. And preferably at a larger world wide scale. 7. INFOstructure needs a Semantic Stack The needed Semantic Stack will consist of several autonomous and orthogonal layers. Each of these layers must be based on a standard and will produce semantic interoperability artefacts that need to be shared by all. In order to understand the function of each layer the metaphor is given. e.g. Encyclopaedia, Dictionary, etc.) 1. Ontology (like an encyclopedia) 2. Codes from a Reference Terminology (like a dictionary) 3. Clinical Information Models (CIM s) or Detailed Clinical Models (standard phrases that make sense in health) 4. Archetype Object Model (the syntax to technically produce archetypes that make sense or non-sense) 5. Reference Model (archiving and documentation standard) For each of these layers there are open international standards available (E.g. IHTSDO: SNOMED-CT 16, WHO: ICD, ICPC, CEN/ISO: 13606, 13940). Ontology Ontologies define concepts in a computer processable way. The ontological methods as defined by W3C for the Semantic Web allows fine grained handling and reasoning of data and information. Only using ontological methods complex translations to and from various languages, specialities and jurisdictions become possible. In addition, computer reasoning about 15 Personal communication (1999) by Ann Harding director of the NHS and responsible for the transition of the UK Read-codes to SNOMED-RT. The next release SNOMED-CT is owned by IHTSDO and is the result of co-operation between the NHS in England and the College of Pathologists in the USA because of a lack of resources (finances and expertise)

9 the data becomes possible. Building, maintaining and publishing ontologies is resource intensive. Figure 3: The Semantic Stack Reference Coding System Like words in a dictionary these concepts need to be translated into the various languages. SNOMED-CT is a good example of a Reference Coding system. Building, maintaining and publishing coding systems is resource intensive. Clinical Information Models in Libraries Clinical Information Models (CIM s) are expressed as archetypes and specify what and how in healthcare the provision of healthcare is documented, archived, retrieved, and exchanged. These are models that make sense in the context of health. All kinds of codes from coding systems and links to ontologies can be bound to elements in these CIM s. Templates are produced using these these models as building blocks and represent the content of a screen, letter, report, etc. For semantic interoperability to work we need standardised CIM s translated in various languages. Building, maintaining and publishing archetypes is resource intensive. Archetype Object Model and Reference Model The CEN/ISO EHR communication standard is a standard that defines two models that complete the semantic stack. One is the Archetype Object Model with which is is possible to technically create archetypes as constraints of the Reference Model. With these archetypes one can create things that make sense and non-sense. The second is the Reference Model that specifies all that is needed to archive and exchange: attest/digitally sign, version, and archive data or information and produce archetypes. 9-11

10 8. The European Managed INFOstructure Producing, maintaining, publishing and quality assuring all elements of the Semantic stack and translating all into all the languages of the European Community is a task that is too big for the healthcare sector, European countries, regions. The cost for the INFOstructure for each language are the same. Small countries most certainly can not afford it, even the big ones can not. An additional argument why we need a (at least) European managed INFOstructure is that the number of semantic interoperability experts is so limited that we need to bundle all resources available. In the light of the present European development, in creating one economic space with cross border health for european citizens, it is logical that the European INFOstructure will be created. This Health INFOstructure must be a project of all European countries, analogous to the EU-epSOS 17 project and the ehealth Goverenance Initiative 18. It can be argued, even, that we need to solve the INFOstructure at the world level. 9. Ongoing developments At present there is a European project where almost all experts in Europe are working towards the ideas of the European INFO-structure. The SemanticHealthNet 19 project is a Network of Excellence with limited funds to discuss and experiment with some aspects of the INFOstructure and the future business model and organisational structure for it. The project will end in After which the next political and organizational steps can be set. At the world level there is the Clinical Information Modeling Initiative (CIMI 20 ) a USA lead organisation of volunteers consisting of (among others): Veterans Health Administration, InterMountain Healthcare, Mayo Clinic, Stanford University, GE Healthcare, OMG, IHTSDO, WHO, NHS-England, National projects of Canada, Australia, Singapore, Sweden, the EN13606 Association and several more. Many of these actors are funded by their own large organisations. Most meetings are held in the USA. European volunteers (several are SME s) do not have and are unable to participate in meetings because of a lack of funding. Because of cultural differences between the USA and the rest of the world CIMI has a tendency to focus on pragmatic quick fixes for the Anglo-Saxon world and not on a sound well founded infrastructure for Europe with its rich cultural and language diversity. One thing is clear at this moment. All actors agree that we need to produce the artefacts thata are defined via standards for each layer in the Semantic Stack, but that structural funding is missing. 10. Rounding off 17 epsos ehealth Governance Initiative. htm 19 SemanticHealthNet CIMI

11 IT alone will not bring about the EHR we all expect to have. The IT-industry and National EHR-projects have proven to be unable to provide safe and full semantic interoperability. In effect, the EHR is not a technical ICT-problem that vendors will solve; it is a problem that semantic interoperability experts will solve, where ICT is just an enabling technology. Most of this enabling technology is in the hands of innovative Small and Medium Enterprises (SME s). E.g. Electronic Record Services, academic departments and Associations of users or vendors. Semantic Interoperability until now is primarily focussed on Coding Systems with health related concepts. Several other very essential topics need to be made interoperable, also: the terms related to co-operation and clinical workflow plus the Patient Mandate that defines who gets access to the data and information. These other topics will have to be integrated with the semantic Stack. In order to get full and safe semantic interoperability we need an international / European INFOstructure, organised in such a way that all actors operate in their own natural role plus sufficiently trained health informaticians that make use of the INFOstructure. The EU project SemanticHealthNet 21 and the CIMI 22 project will help to shape the semantic INFOStructure in Europe. Active financial and in addition political support in the very short term by the European Commission is essential for Europe. Only in this way Europe is able to continue to lead in semantic interoperability in the European Member States with their culturally rich and complex, diverse societies speaking all their different languages. At first sight this diversity can be seen as a handicap but can be converted to a competitive advantage with better usable EHR systems worldwide from EU vendors, as compared to existing EHR-systems from the USA vendors. 11. Post script The basis for this position and the reasons stem from: - A personal involvement of the author during more than 35 years in the provision of healthcare as General Practitioner, developer of software, participant in standardisation in HL7, CEN and ISO in the fields of healthcare related semantic interoperability, information security, quality assurance of data and health IT-systems. - Several EU-projects and International initiatives in which we participate (SALUS, SemanticHealthNet, CIMI) all devoted to semantic interoperability in health care and developments of an international INFOstructure that will support semantic interoperability. Major actors and participants in these activities are: National projects of England, Canada, Australia, Singapore, Sweden, or USA Veterans Health Agency, DoD, Kaiser Permanente, Mayo clinics, Stanford, Intermountain, General Electric, Agfa, IHTSDO (SNOMED), WHO, HL7, CEN/tc251, etc. - Activities in international organisations such as: The European Institute for EHR s (EuroRec), the EN13606 Association