Dear Colleagues, I am often asked about the relationship between ISO EN 13606 and openEHR, and I note this topic has recently been raised on our lists.
To say straight off, some people imagine there are tensions between these, but most of the people active in taking forward 13606 are also active in openEHR, and see value in both. I certainly do. Inevitably those close up to this subject tend to focus on fine differences, while those further away cannot understand what the differences are or why they might be important. If one looks at the modest quality and poor consistency of clinical data and the limited interoperability of EHR systems today, the differences between openEHR and 13606 are really rather slight. 13606 was developed drawing on a long thread of R&D on EHR representations, starting from the early 1990's and embodied in two past generations of European Standard as well as openEHR's specifications. All of this background work was inter-linked through time and people, many of whom contributed to the development of the standard, directly or indirectly. The priority during the development of the standard - expressed especially by the vendors and the health ministry representatives - was to find the simplest possible model for communication between heterogeneous EHR systems, whilst meeting published requirements including medico-legal requirements e.g. ISO 18308. The goal was to keep the complexity of the interoperability models low, and not to require a large number of information properties that many legacy systems might not be capable of providing for export or of safety storing on import. As the work migrated from its origins in CEN to ISO, this philosophy was endorsed by the broader international community: for example the ISO version of Part 1 (2008) is identical to the CEN version (2007). Archetypes were very much liked, and there was a wish to support the sound use of archetypes as promoted by openEHR, but optionally - recognising that archetypes will take some years for marketplace penetration, and that EHR interoperability has to work in a non-archetyped, a fully archetyped and in a transitional mixed economy. We have tried to support these options in 13606. When developing ISO 13606 Part 2 we recognised that the then current version of ADL would evolve, and also that other representations of archetypes might gain favour over time e.g. XML, OWL. That part-standard is therefore deliberately called an "Archetype Interchange Specification" - i.e. it is for sharing archetypes, not for operationalising them within particular systems. The normative parts are the requirements and the UML logical representation, and the conformance requirements are to be able to map any physical representation of archetypes to this local expression. ADL 1.4 was included as it was then stable and implemented within tools (i.e. the paint on it was dry), but with optional conformance. (Readers of the standard are invited to go to the openEHR Web site for more on archetypes.) It is therefore permitted by the standard to use, for example, ADL 1.5. Other part of 13606 deal with confidentiality policy interoperability and with interface specifications, and some internal vocabularies. (There is a data type "inter-regnum" that should be addressed in the near future.) Some vendors and countries have found 13606 attractive because of its stability: since the time line from design to return on investment for EHR system products can be many years, an evolving specification is considered by some to be a disadvantage. 13606 is considered to be easy on the learning curve and potentially well suited to feed a national EHR network that has to federate multiple (legacy) systems from multiple vendors. openEHR, of course, offers a more detailed and comprehensive EHR reference model and other specifications targeted primarily as an EHR system architecture. This suits other use cases and budgets. I won't elaborate on openEHR here as you all know it well. Since both support archetypes, investments in clinical modelling activities by health professional bodies or eHealth programmes can be exploited by both kinds of specification. This is important since a significant investment is now needed, globally, in scaling up archetype development and validation. When 13606 is revisited over the next few years we will see what experiences have been gained across all dimensions of health record interoperability globally, in order to identify deficiencies and new priorities for it to meet. Since openEHR is also learning hugely as its implementation base grows, I would expect the shared learning to result in better alignment between the two specifications next time. However, as I have often made clear, I am strongly resistant to modelling by "religion" so I do not like to be drawn yet on how close that alignment might be, nor on how close we can align with HL7 CDA - desirable as those alignments might be. To me requirements and experience are everything! I would like to see all of our representations for EHRs (including those developed by HL7) more transparently and robustly mapped to evidenced requirements. If we do all work to the same requirements, our differences will surely evaporate. Thanks to all of you on the lists for enriching our understanding of what is needed of the EHR and for sharing your experiences along our common journey of learning. With best wishes, Dipak ________________________________________________________ Dipak Kalra Clinical Professor of Health Informatics Director, Centre for Health Informatics and Multiprofessional Education University College London Holborn Union Building, Highgate Hill, London N19 5LW Honorary Consultant, The Whittington Hospital NHS Trust, London Phone: +44-20-7288-5966
