←
EHR systems - Future developments
Gerard Freriks
EN13606 Association,
Electronic Record Services B.V.
[email protected] Position Paper
‘It’s the economy, stupid’ said Bill Clinton1.
‘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) systems2 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, ex-change between co-operating healthcare providers, generation of invoices or reports, educa-tion, clinical decision support, support of clinical pathways, clinical and other use for re-search, 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 Eu -ropean or preferably a worldwide supporting INFOstructure as a publicly financed organisa-tion 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 under -funded 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 ad-dressed properly we can reap the benefits of the EHR? This paper will not address all the ethi-cal, 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.
1 http://en.wikipedia.org/wiki/It's_the_economy,_stupid
2 Gio Wiederhold. (1979). Stanford Computer Science Department. Report No.STAN-CS-80-790. March 1980.
This position paper will point at the essential line of reasoning, the co-operation, types of in-vestment 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-so-lutions 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 infor-mation, 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 coun-tries, 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 mono -lithic. At best they provide a kind of interoperability within an organisation. But there are ex-amples where even that proved to be impossible. There are hospital/EHR systems3 that when
installed, are deployed per department facilitating their own work processes and there own in-formation 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 de-partments was not part of the explicit requirements, apparently!
In case semantic interoperability between departmental systems had been a requirement, ven-dors 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 out-side the hospital. Almost always the semantic interoperability between EHR-systems from dif-ferent 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 Improve-ment at IMIA
It is estimated and shown in several projects4, that it takes 2-3 years to produce the message
standard and at least 1.5 years to implement and test an IHE profile5 in IHE Connectathons. At
present there is a huge industry worldwide making money out of this technical message solu-tion: 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 de-partment 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 be-cause 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 inter-operability 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 ven-dors 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_2011-05-18.ppt, Slide 14
Figure 1: EHR using a central switch and standardised messages
There are several examples of National projects6 where the Patient Summary is automatically
assembled via a national/regional switch point (the Act Registry7) that knows the location
where data about a particular patient is available. Such a set-up creates, because of the mes-sage standards used, inflexibilities that prevent innovation in healthcare. An additional prob-lem 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
http://www.ehealth-strategies.eu/report/eHealth_Strategies_Final_Report_Web.pdf 7 http://www.ringholm.com/docs/00950_en.htm
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 un-der control of the author AND the data subject (patent) for a split second or forever or any-thing in between as regulated by a policy defined in a Patient Mandate. The CEN/ISO 13606 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-ties to attach security policies at the data level. Only the CEN/ISO 13606 EHR-communica-tion standard8 has these Patient Mandate facilities.
When data and information is stored in the Electronic Medical Record (EMR) and/or the Per-sonal 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 se-mantically 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 interop-erable. 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
informa-tion 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 Care10) is in place and in the process of renewal and
ex-tension.
Privacy/Access control: Patient Mandate
The privacy of patients is an big issue11 that creates many political, legal and implementation
issues. The moment data is exchanged between systems, the moment data is archived and
re-8 http://www.iso.org and http://www.cen.eu
9 CEN/ISO 13940 ContSys standard
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=58102
10 ContSys is not to be confused with CCR/CCD as message specifications for continued care, Con-tSys 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
used later, it is essential that together with the data the Patient Mandate is stored as is ex-plained in section 4.
At present there is are two related standards that allow the preservation of the Patient Mandate (CEN/ISO 13606 part 4 and ISO 26000 standard for Privilege Management and Access
Con-trol12). 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 legislation13 14 and
im-plementation 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 bound-aries;
• 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 fu-ture 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 stan-dardised format. A format that can be used by all and in many cultures, languages where sev-eral 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 26000 PMAC standard http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm? csnumber=36337
13EU Privacy policies http://ec.europa.eu/justice/data-protection/index_en.htm
14 ARTICLE 29 Data Protection Working Party http://ec.europa.eu/justice/data-protection/article-29/index_en.htm
In Europe we have many (26) languages and many borders, different cultures and legal sys-tems. When we want semantic interoperability in Europe we have to co-operate. In other coun-tries 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 ad-vanced.
Producing, maintaining and quality assuring components of the Semantic Stack in the INFOS-tructure is a very human intensive resource needing the skills of many highly trained collabo-rators. Even for big countries15 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-CT16, WHO: ICD, ICPC, CEN/ISO: 13606, 13940).
Ontology
Ontologies define concepts in a computer processable way. The ontological methods as de-fined 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 lan-guages, 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 transi-tion 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).
the data becomes possible. Building, maintaining and publishing ontologies is resource inten-sive.
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 sys-tems 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, re-port, etc.
For semantic interoperability to work we need standardised CIM’s translated in various lan-guages. Building, maintaining and publishing archetypes is resource intensive.
Archetype Object Model and Reference Model
The CEN/ISO 13606 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.
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 de-velopment, 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-epSOS17 project and the eHealth
Gov-erenance Initiative18.
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 SemanticHealthNet19 project is a Network of
Excellence with limited funds to discuss and experiment with some aspects of the INFOstruc-ture and the fuINFOstruc-ture business model and organisational strucINFOstruc-ture for it. The project will end in 2014. After which the next political and organizational steps can be set.
At the world level there is the Clinical Information Modeling Initiative (CIMI20) a USA lead
organisation of volunteers consisting of (among others): Veterans Health Administration, In-terMountain 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 infra-structure for Europe with its rich cultural and language diversity. One thing is clear at this mo-ment. 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. http://www.epsos.eu 18 eHealth Governance Initiative.
http://ec.europa.eu/information_society/activities/health/policy/ehealth_governance_initiative/index_en. htm
19 SemanticHealthNet. http://www.semantichealthnet.eu
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 se-mantic 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 re-lated 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 INFO-structure. The EU project SemanticHealthNet21 and the CIMI22 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 Com-mission 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 health-care as General Practitioner, developer of software, participant in standardisation in HL7, CEN and ISO in the fields of healthcare related semantic interoperability, information secu-rity, quality assurance of data and health IT-systems.
-Several EU-projects and International initiatives in which we participate (SALUS, Seman-ticHealthNet, 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, Sin-gapore, 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 (Eu-roRec), the EN13606 Association.
21 http://www.semantichealthnet.eu/
