Been doing some literature review stuff and hit a few papers from 10 years ago (link below) that are focussing on OWL transforms etc. There’s a thread from the below paper that positions 13606 and openEHR differences as;
• openEHR was designed to support construction of EHR systems,
• ISO 13606 was designed for exchanging EHR extracts,
Would it be safe to suggest that the historical difference between 13606 and openEHR (message vs persistence) is manifest in the HL7 opposition that we see now? It appears that 13606 was a direct HL7 competitor (in theory)? But as I am far too young to have battle scars of that time, was there any argybargy with V3/RIM and 13606? I’m sure there’s some literature on it but wondered your thoughts first?
Generally, the need for semantic models as a route to a unified ontology does seem overly academic when the business of just getting systems to understand each other is hard enough. Interesting nevertheless…
Ref:
Martínez-Costa, C., Menárguez-Tortosa, M., & Fernández-Breis, J. T. (2010). An approach for the semantic interoperability of ISO EN 13606 and OpenEHR archetypes. Journal of Biomedical Informatics, 43(5), 736–746. Redirecting
IMHO to have a vs. there should be an overlap in scope, for me the overlap between messaging standards and ISO/EN 13606 is clear, but the overlap between FHIR and openEHR is yet to be found.
All I can see today, because it’s part of my daily work, is implementing both FHIR and openEHR in the same platform to support different areas of requirements. Right now I’m working for HiGHmed and we defined a FHIR broker on top of the openEHR backend CDR. I think it’s clear that FHIR is not for storing clinical information, besides that FHIR CDR people want to push that, is not for that. Either way we are using some parts of the FHIR storage to store information about audit logs, which I think suits perfectly if an ESB is not in place (since ESBs have their own logging system). So the data comes in FHIR, it is translated to openEHR and stored in the openEHR backend for usage. That usage happens at the openEHR API level getting compositions or using AQL. I think this architectural approach is the best of the two worlds: information interchange + information management and usage.
Totally agree and acknowledge but this nevertheless still exists form those that “don’t know any better”. So the question for me is history repeating itself?
This is from a 2006 HL7 slide deck:
ENV 13606
– European Prestandard for EHR Communication
– Basis of earlier UK work in XMLEPR Project
• ENV13606 and HL7 RIM are both:
– Fairly abstract UML views of healthcare information
• ENV13606
– High-level architecture of patient record information
• HL7 Version 3 RIM
– The larger picture more general in scope of coverage
– Used to derive messages by formal development method
• Convergence
– GP2GP team developed HL7 v3 messages
• Taking account of ENV13606 EHR Architecture
• Using the HL7 RIM and development method
The German project is proof of history not being repeated, an in fact showing the right path.
The rest is business and education. I mean, we have those people that don’t want to understand because they want to impose a view because that’s good for business. Good the ones that take don’t know, we need to educate, and the German project IMO will be a great case of study.
A reaction form a person active in the early days when history was written.
In the beginning there was the ORCA European project (I have many of its deliverables in my archive) that was about the EHR. It provided the beginnings of the Two-Level modelling method: basic Reference Model and Archetypes. The Reference Model was extremely generic. It resulted in the first Standard for the EUropean EHR.
Because of co-operation in the project with persons from Australia (Thomas Beale, and more) the next development took place in Australia. They produced the first version of a more detailed Reference Model.
In Europe CEN started to work on the second version of its EHR standard EN 13606 payed for by the EU. David Markwell became the projectleader to create this second version. I (Gerard Freriks) was an extended member of this group. The EN13606 v2 was clearly a messaging standard, Around 1995 these developments took place.
At the same time HL7 v2 in the USA proved to be successful in the market but its Reference Model became so complex that only sheet of paper roughly two meters wide allowed the model to be represented in a readable way. It was much too complex. Around 1996 a German anaesthesiologist (Günther Schadow) proposed the HL7 v3 method. It allowed to created standardised sentences, aka messages.
Around 2000 I became the chairman of CEN/tc251 Wg1 and started the proces to produce EN13606 v3. That was to be based on important work done by the Australians on the OpenEHR Reference Model and Archetype model. The CEN Archetype model was and is an exact copy of an OpenEHR version. For political reasons it was positioned as EHR messaging solution, but hidden in the Scope statement there was an idea to extend it to EHR-systems, as was the clear scope of OpenEHR.
As chairman I initiated a co-operation between CEN and HL7. Soon it became clear that the Europeans were supposed to assimilate with HL7. Many Europeans became active within HL7 to influence them from within. e.g. David Markwell that left CEN for HL7. In the end Europeans and Australians wrote a manifesto explaining why HL7v3 was failing. It had to many design errors in models and methods.
Around 2010 I started the renewal process of the CEN ISO EN13606 v4. This time with a scope that included the use of the standard to define EHR-systems. Also two other standards were harmonised with: System of Concepts for Continuity of Care (CEN ISO 19340 ) and Health Information Services Architecture (CEN ISO 12967) Observe that by then these EHR related and harmonised standards were developed jointly by CEN and ISO.
Because of the implementation problems with HL7v3 the HL7 organisation started what became FHIR as implementable alternative for HL7 v3. Technical implementation engineers designed a method to (explicitly) allowed fast development of messages; allowing that 80% of the data in existing systems could be exchanged using FHIR (Fast Healthcare Interoperable Resource)
The HIT sector has still not caught up with modern methods, which is not to impose content in messages (called ‘resources’ in FHIR), but to generate storage, message and any other structures from single-source content definitions. While that is the case, content definitions imposed in messages/resources will always be competing with the content definitions of systems, and will require constant data transformation work. Apparently, the HIT sector is happy with this situation.