I know boring V2 can easily carry documents back and forth. Personally, I favor avoiding XDS as being “necessary”. Neither of use cases of “New Data Flowing
in from Edge Node” and “Data Dump from SHR” require XDS, and both can be done naturally by a V2 message.
I don’t know who (what users/what use cases) actually want XDS. It would be a Good Thing to plop XDS into our architecture, and explain how OpenMRS would
interact with it. Presumably, the XDS query would be satisfied by an OpenMRS query against documents or lab panels. OpenMRS could synthesize a document out of the discreet observational data of a lab panel.
Thanks for getting thing going again. From my perspective there are really 2 basic types of messages that we need to represent:
Structured observational data
Un-structures data (eg. documents)
For 1, I see the options that we could use as HL7v2 (OBX segments), FHIR Observations or an IHE standards that stores observational data.
HL7v2 - We will have to profile this our selves. Do we want to do this?
FHIR - This is a very new and un-balloted standard.
IHE - The IHE profiles all seems very use case specific, we want to support a generic message format for observational data so that multiple different implementation needs can be met. How can be do this with IHE profiles? Perhaps, I don’t have a good enough
knowledge of IHE profiles that are available.
For 2, I see the options that we could use as HL7v2 (embedded CDA?), FHIR Documents or the IHE XDS.b profile.
HL7v2 - We will again have to profile this ourselves.
FHIR - This is a very new and un-balloted standard.
IHE XDS.b - this works well and is well understood. Does it fit in with a SHR architecture?
Hopefully others that have more experience with these standard will be able to let us know what specifically we should look at.
Looking forward to talking about this on the call tomorrow!
On Mon, Jul 29, 2013 at 3:35 PM, Tucker, Mark firstname.lastname@example.org wrote:
We need to push forward to a more clear understanding of how we will represent clinical data.
I wanted to summarize the issue, but Derek already has. (Email attached)
In another email, which I can’t put my hands on, Derek said he personally was leaning towards IHE.
Derek, (or anyone else!), can you please make one round of elaboration on what exactly we would be buying into:
“We need to choose the IHE protocol stack for OpenHIE. Specifically, we will start with the
We will not adopt
as we don’t need that style of interaction.”
Derek Ritz email@example.com
Date: Wed, Jun 26, 2013 at 7:06 PM
Subject: Re: “stacks” of standards : V2+CDA+Profile
I think I should probably be clearer about what I mean when I refer to a “stack of standards”. A stack, for me, is a collection of specifications that ** hang together** . This may be contrasted to a set of specifications, even if they are all balloted
standards from recognized Standards Development Organizations (SDOs, such as HL7, ISO, WHO or IHTSDO), that
DON’T hang together . Sadly, many internationally balloted standards are inconsistent with each other and not inherently interoperable. Anyone who chooses a smorgasbord approach to selecting standards is signing up for a mountain of profiling;
there is no other way to achieve interoperability.
We can narrow our scope of eHealth specifications down to the stacks of standards that have been internationally balloted. Given my definition (above), this gets us down to 3 candidates:
- OpenEHR / ISO 13606
Because it is isn’t inherently interoperable, HL7v2 isn’t in this list EXCEPT for when it is leveraged within IHE profiles (which it
The 3rd of these options is very different from options 1 & 2. Both HL7v3 and OpenEHR / ISO 13606 are based on underlying reference information models. Because of this – both provide inherent interoperability. Any HL7v3 message can be understood by a recipient,
regardless of profiling, because it is (by definition) a constrained instance of the underlying RIM. This is true for OpenEHR / ISO 13606, too. The underlying information model makes each of them internally consistent and interoperable.
IHE is not based on an underlying information model. Quite the contrary; it is very much the smorgasbord approach. Different underlying standards (sometimes ISO, sometimes HL7v3, often HL7v2) are profiled so that they will be interoperable. These profiles,
themselves, are collected into infrastructure frameworks that broadly re-use existing profiles across multiple differing use cases. IHE only works because it is profiled; that is how it achieves interoperability.
Here’s the thing; if we (as engineers of an HIE) were looking for something that is well-designed to be inherently interoperable – we definitely should favour either HL7v3 or OpenEHR / ISO 13606. Here’s the other thing; neither HL7v3 (with the exception of
CDAs) nor OpenEHR / ISO 13606 have yet been broadly adopted within the eHealth marketplace. In fact – to find out what HAS been broadly adopted in the marketplace, look at the IHE profiles. Significant market acceptance is a prime consideration when IHE is
selecting which standards it will profile.
So… here is the impact of thing 1 and thing 2 (is anyone else thinking of a “Cat in the Hat” rhyme right now?). If we want to be elegant in our datacentre – we should choose HL7v3 or OpenEHR / ISO 13606. These are, by any engineering measure, better options.
Our trade-off is that we will have a very inelegant time “out in the world” since so few point of service eHealth applications “speak” HL7v3 or OpenEHR. In contrast, if we choose IHE, we will have inelegance inside our datacentre as we support bits of ISO,
bits of HL7v2, bits of HL7v3, bits of this and bits of that – whatever has been specified in the profile. What we get for our troubles, however, is elegance “out in the world”. These profiles are strongly aligned with what is already out there in the eHealth
landscape; in many cases, existing products will work out-of-the-box (because they already have, for instance, an HL7v2 interface).
I strongly advocate for us choosing one of the 3 internationally balloted STACKS of standards. If we decide to do this, we then have to decide which approach will serve us better: superior engineering which is elegant in our datacentre or an inferior (but pragmatic)
approach which is elegant “in the world”.
Food for thought…
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton