I think you'll find this link helpful http://www.oceaninformatics.com/Media/docs/Relationship-between-CEN-13606-HL7-CDA--openEHR-2ba3675f-2136-4069-ac5c-152139c70bd0.pdf

You might like watching a video intro to HL7 at

http://blog.interfaceware.com/hl7/how-does-hl7-work/

I suggest You ask Miroslav Koncar from HL7 Chroatia. We are studying thos problem in Poland. I will inform You about our coclusions.

Grzegorz, I am interesting in your conclusions about standards (HL7 or EN13606) in Poland.

We would need to have more details here. (Sorry to be late, this pops up in my messages only this week).

In particular because HL7 has a couple of dozen standards, of which many are also balloted under ISO regime, where ISO EN 13606 series of five is currently undergoing systematic review. In other words, comparing HL7 with 13606 is like comparing the 30+ HL7 member countries with Eastern Island.

OpenEHR is not a standard. There has been research published though, but that has been done with HL7 particulars as well.

What would you like to do?

Do you want to learn from disasters with such standards misunderstood?

I could give you more details, if you give more goals or research questions.

I work in the HL7 community on the Care Record v3 message. That is suitable for flexible number of data to be exchanged between two systems. Either system should read and write HL7 v3, or a parser can do the transforms. http://www.windesheim.nl/~/media/Files/Windesheim/Research%20Publications/UitwisselenverpleegkundigegegevensoncologiemetbehulpvaneenClinicalDataWareHouse.pdf (In Dutch, but HL7 v3 part submitted in English).

I work in the OpenEHR community and create archetypes for clinical content.

I work in the ISO community as expert in the 13606 revision.

And I am a voting member of the Clinical Information Modeling Initiative.

My experience is that once you have the data elements and their definitions and unique code bindings right, it makes no difference which of the technologies you use. In fact, with modern cloud and soap stuff, each of their paradigms is very 20th century.

Last week in Karuizawa Japan, at the ISO meeting several 13606 related projects were presented. Also several HL7 r standards were moved to the next stage in ISO space.

What might be of interest for this question on how to compare 13606 versus HL7 is that for instance there is enormous progress in the demographic archetypes. Although this is just a fraction of what the standards have, the step made is that the 13606 demographic will be on a higher abstraction level than in the past. The specification of details goes in a table like structure. This opens the possibility to use HL7 v3 Common Message Element Types for patient, person, including the telecom set and including the address set for the specification in 13606.

In the past I did a detailed analysis for clinical data, representing the data elements, the code binding, the data type and their relationships (see http://www.ncbi.nlm.nih.gov/pubmed/20841821). 13606 and HL7 have similar expressiveness, except that 13606 is very hard to use for the code binding to e.g. Snomed CT. However, the work of the clinical information modeling initiative (www.opencimi.org) has improved the archetype definition language such that a node to code binding is simple and possible to include in a similar way as HL7.

I am just throwing in some comments about comparing these two, but it really depends on what your goal is. At this stage both are mature enough to apply in practice, but if there is no focus it makes no sense to go deeper.

That was http://www.opencimi.org

EN13606 provides a comprehensive means of defining Shared EHR

content.

What are you trying to achieve? You need to answer that, since the or in your question can lead to confusion. In my experience, a proper EHR uses hundreds of standards, and 13606 and HL7 are not mutually exclusive standards, but complementary.

ISO EN 13606 tries to give a structure for EHR content in part 1. It defines how to create archetypes in ADL, requiring EHR systems to use a specific formalism. Part 3 gives core example archetypes, part 4 arranges the security and part 5 gives some implementation specifics. The ISO EN 13606 is currently undergoing a revision.

Although it is labeled as record communication, it is not a specification for it, but is focusing on internal structures of EHRs, that all communicating systems should adhere to. Part 5 uses HL7 v3 for the actual semantic interoperability specification.

HL7 has currently 6 types of standards: HL7 v2 is traditional standard for internal use in hospitals. The follow up was the HL7 CDA, a document exchange standard, for exchange between hospitals, HL7 v3 is the version for exchanges for continuity of mcare between multiple care providers and organizations. Electronic services are more web services / soap based approaches, and the new kid on the block is FHIR, which can be seen as a technical implementation specification. #6 is the Electronic Health Record System Functional Model and the mirror Personal Health Record System Functional Model., that are parallel balloted at ISO level.

If you want your EHR right, focus on the following:

1. ISO  Contsys 13940 (final stage), which has a conceptual model of health care and processes.

2. HISA series (or TOGAF) for an architecture. Why? See papers by prof. Bernd Blobel.

3. ISO 18308 describing the logical model and requirement of lifetime / cross institutions electronic health records.

4. The HL7 EHR-S FM / FP and PHR-S FM/FP for the system requirements (>3000 items).

5. The ISO EN 13606 series for the EHR content

6. ISO TS 13972 detailed clinical models to specify the clinical content in a non implementation specific way, and supports the transformation to many technical formats (such as archetypes for 13606, HL7 v3 XML HL7 FHIR and more)

7. Various terminologies, such as SNomed CT, LOINC, ICD-10, ICNP, ICF, RxNorm, ATC, Omaha, and many many more.

8. Security standards, e.g. ISO 27000 series.

But again, I can list even more of this, but you would need to be more specific as to your goals.

The biggest blunder I see people make is that they choose for one standard, and then get so involved in that single approach that they loose the rational decision making on what is most useful standard for which kind of problem in EHRs.

William