Are the HL7-FHIR, HL7 CDA, CIMI, openEHR and ISO13606 approaches aiming to solve the same health data exchange problems?
-
1Actually not homework, I already have a degree (so feel free to retract that downvote if that was your reason), but I edited/shortened the question to make it cleaner since it looked to much of an essay task :-) so thanks for pointing that out. Many people confuse the listed approaches and their purposes. I think a place like stackoverflow is neutral enough ground to get proponents of different approaches to describe the differences properly in a balanced manner. Not too far from the spirit of the post https://blog.stackexchange.com/2011/07/its-ok-to-ask-and-answer-your-own-questions/ – Erik Sundvall Aug 14 '15 at 12:59
5 Answers
FHIR, CDA, 13606, CIMI, and openEHR all offer partial and overlapping approaches to 'solving health data exchange problems'. They each have strengths and weaknesses, and can work together as well as overlapping each other.
FHIR is an API exchange spec that's easy to adopt CDA is a document format that's widely supported CIMI is a community defining formal semantic models for content openEHR does agreed semantic models and an application infrastructure 13606 is for EHR extract exchange

- 3,538
- 3
- 15
- 17
CIMI is clearly an initiative to think about the content of archetypes and recurring patterns
FHIR is a specification for API's including a limited set of content models
openEHR is a community and an open-source specification with standardised Reference Model, and Archetype Object Model, Data types and Termlist
CEN/ISO 13606 is a community using its formal, public(?), and CEN and ISO standardised Reference Model, and Archetype Object Model, Data types and Termlist
Scopes of all overlap. The most overlap is between openEHR and 13606. And to a lesser extend with CIMI.
Two level Modeling Paradigm. CIMI, openEHR and 13606 have a lot of interactions and adhere to the Two level Modeling Paradigm.
Archetypes can be used by FHIR. CIMI is creating archetypes as are the openEHR and 13606 communities.

- 1
- 1

- 31
- 1
-
1Thanks for the reply! I do not understand why you call the openEHR specification proprietary (it is CC-BY-ND licenced and freely available online) and you call the ISO 13606 more open (it is copyrighted and behind a paywall). – Erik Sundvall Aug 28 '15 at 10:07
-
1The previous notion of "proprietary" regarding openEHR above now seems to have been corrected through edits. OpenEHR and HL7 FHIR both use various open source and open content licenses. – Erik Sundvall Sep 03 '15 at 10:56
I see a future for 13606 in context of cloud EHR, were the exact location of data is not always known, but what matters is how to get access to them.
13606 can provide a standard for interfacing to the cloud, and provide features as queries and requests for detailed information, instead of precooked general purpose message-formats, like patient summaries, etc.

- 1,057
- 3
- 14
- 25
Erik, you write: "I do not understand why you call the openEHR specification proprietary (it is CC-BY-ND licenced and freely available online) and you call the ISO 13606 more open (it is copyrighted and behind a paywall)"
The point is is that in case of an ISO standard third parties should not claim IP. You must pay for the information, and you may not distribute the copyrighted text, but you may use the information without risk of being confronted with excessive claims afterwards.
There is a policy on ISO deliverables regarding to patents, which gives insurance for not having to deal with excessive patent-claims afterwards. See for more information: http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2
Resume: There can be IP claims on ISO deliverables, except from the copyrighted text, but those claims must be handled in a non-discriminatory and reasonable way. So, no excessive claims are possible.
In a patent-related legal case, the judge will find it important that the deliverable was published at ISO. Two equitable defenses to patent infringement that may arise from a patent owner's delay in taking action are laches and equitable estoppel. Delays give rise to a presumption that a delay is unreasonable, inexcusable, and prejudicial. This is certainly true when it concerns an ISO deliverable.
This policy does not exist in the case CC-BY-ND licenced work. This work gives no guarantee at all. The user of CC-BY-ND licenced work is not safe for claims.
Therefore it is important that AOM2.0 will be submitted to ISO. It can only be submitted to ISO in context of the 13606 Renewal. That is why the OpenEHR community, for its own sake, must work on a Reference Model agnostic standard in all parts, to help and convince the ISO13606 renewal committee to implement it.
AOM1.4 has been an ISO standard for years, so we can be pretty sure that there is no hidden IP on that.

- 1,057
- 3
- 14
- 25
-
I must add, that if the patent-owner inevitable knows about a patent-infringement, the lache-defense can become effective directly. That is a work around. Tell the one you suspect of future claims publicly about your work, and they are forced to respond immediately or lose their right to claim. – Bert Verhees Sep 01 '15 at 13:18
-
3Whether your arguments are correct or not, it is simply not correct to state that openEHR is proprietary. I have submitted an edit to Gerard's post to correct this inaccuracy and deeply regret that a thread that could have been used constructively has been hijacked. – Ian McNicoll Sep 01 '15 at 15:41
-
1I agree Ian, I see no reason to think that OpenEHR is proprietary. I am only offering a solution to fight these rumours. Maybe Gerard can explain what he meant by his statement. – Bert Verhees Sep 01 '15 at 15:52
-
2Thanks Bert, those are helpful remarks. Just for clarity , AOM2/ADL2 is completely RM-agnostic, and is being used against 13606, openEHR and CIMI RM's in the ADL workbench. – Ian McNicoll Sep 01 '15 at 17:38
-
RM-agnostic, I think so too, Ian, at least, I trust, that is the intention. I have not studied it carefully, because I am very busy, but I surely will, short time from now. I hope there is the ambition to be used in ISO13606. I am afraid it will be the end of ISO13606 if it does not find a way to modernize. And if that happens, an ISO-vehicle to emphasize the power of two level modelling will be gone. – Bert Verhees Sep 01 '15 at 18:54
-
The computable resources from openEHR are Apache 2 licensed and that licence (http://www.apache.org/licenses/LICENSE-2.0) has an anti-patent clause (#3). The ADL (Archetype definition language) grammar and the UML sourcecode are such resources. Yes, the written documentation is currently CC-BY-ND but the archetype formalism (AOM/ADL) and the Reference Model (RM) have been scientifically published years ago and are thus impossible to claim any patents on. It might still be a good idea (for PR reasons not patent reasons) to let ISO to make a version of AOM/ADL2.0 into a formal standard. – Erik Sundvall Sep 03 '15 at 08:07
-
I need to clarify a bit more, the Apache-Licence speaks only for the publisher (not filing patent-claims against the user of the published work). But in this special case, where the suspicion has risen that the publisher would have secret patents, this should be sufficient. So I agree with you, also on your other arguments. – Bert Verhees Sep 03 '15 at 09:48
I would say the only standard which aim is NOT to solve data exchange problems is openEHR.
openEHR defines a complete EHR platform architecture to manage clinical data structure definitions (archetypes, templates), including constraints and terminology/translations, manage clinical information (canonical information model), access clinical information (standard query language AQL), define rules for clinical decision support (standard rule language GDL), and defines a service model (REST API is close to be approved).
So looking at openEHR, it tries to solve the all the interoperability problems that come before any data exchange but are needed to make data exchanged interpreted and used correctly, in short openEHR allows interoperability but doesn't define how data is technically exchanged.

- 3,080
- 29
- 42