I’m brining a conversation around Standards and profile selection into this newly created list (ohie-architecture@googlegroups.com) where I think we are going to get the cross cutting reviews this list was created for.
Derek thanks for the review and laying out our scenarios below. It drives an interesting set of options i) pretty inside, difficult on the connectivity and data exchange; ii) ‘easier’ of connectivity and data exchanges and ‘not so pretty inside’.
Stepping back to OHIE in general and that we are in a “startup” and adoption phase of the communities and we are focusing our tools on a Low Resource Setting primarily (I think that is something that we all keep in the front of our minds when looking at functionality and feature sets) the biggest impact we can have is in strengthening Health Information Systems in Low resource settings. And getting existing tools to begin to communicate and contribute into any OHIE implementation. I would suggest we look at placing the burden on “us” (as OHIE) and focus on getting people onboard before trying to change their data formats.
Down the way we can start to look at moving towards the “pretty on the inside” approach.
My 2c for the morning and (I think) christening the architecture list.
···
---------- Forwarded message ----------
From: Derek Ritz derek.ritz@gmail.com
Date: Wed, Jun 26, 2013 at 7:06 PM
Subject: Re: “stacks” of standards : V2+CDA+Profile
To: openhie-interoperability-layer@googlegroups.com
Cc: mtucker2@regenstrief.org
Hi all.
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:
- HL7v3
- OpenEHR / ISO 13606
- IHE
Because it is isn’t inherently interoperable, HL7v2 isn’t in this list EXCEPT for when it is leveraged within IHE profiles (which it often is).
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…
Derek.
On Tuesday, June 25, 2013 11:29:34 AM UTC-4, Tucker, Mark wrote:
Hoi.
I heartily agree that the issue with V2 is PROFILES PROFILES PROFILES. That is true of V3, and CDA, too!
But, if we agree with V2+CDA, then the task is, precisely, what profiles to apply?
And on that count, we start with HIE, and ask : Are they specific enough! ?
If we want real plug and play (in the scenario wherein the MoH stipulates codes/etc), what do we add to IHE standards to make our system work.
So, I still feel that we want to think “V2+CDA”, realizing that the onus is now on Profiles.
Mark
P.S
Just for the record, I would never say that “V2 + CDA” is the end point; that such a statement is “implementable”. It is the starting point for further design.
From: openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com]
On Behalf Of Derek Ritz
Sent: Tuesday, June 25, 2013 10:24 AM
To: openhie-interoperability-layer@googlegroups.com
Cc: derek...@ecgroupinc.com
Subject: Re: “stacks” of standards
Hi Mark.
Would I have a heart attack with v2 plus CDA? Not by myself I wouldn’t… but I think we all would have one together! 
If we’re going with HL7v2 and CDA, then I think we’re going with IHE. The problems with HL7v2 (optionality, US-centricity, Z segments, etc.) would require us to do a mountain of profiling. We would be far better off to just adopt the mountain of profiling that
HAS been done by an internationally recognized group. Although HL7v2 has been broadly adopted in the eHealth marketplace (which is GOOD), in the absence of profiles, there is NOT strong interoperability – only lots and lots of of one-off point to point connections.
With HL7v2, we’ll need to leverage profiles in order to go to scale.
I look forward to more discussion on this topic when the time comes.
DJ
On Tuesday, June 25, 2013 9:14:39 AM UTC-4, Derek Ritz (ecGroup) wrote:
Hi all.
Sadly, I have a conflict today and will miss our interoperability-layer
call. An issue which I hope will come up, though, is the choice of which
“stack of standards” our HIM will employ. I’ve exchanged comments/emails on
this topic because, depending on what we choose as our product, the
standards “stack” is often baked in. Mohawk’s Everest framework, for
example, supports HL7v3. In contrast, the CONNECT framework is entirely
based on IHE.
I would like to advocate for the selecting of a eHealth single standards
stack – even where we may be favouring the OpenHIM product and believe we
could support “anything”. However pragmatic this “anything” approach might
appear, it actually will be (I believe) a mistake to NOT choose a single
stack of standards, however imperfect, and go with it. My reasoning is this:
-
the HIM plays a crucial, central role as the “plug and play” bus
-
if the HIM’s interfaces are idiosyncratic, or a mish-mash of
specifications, then this idiosyncracity will be “inherited” by the entire
OpenHIE, and that will impede our ability to go to scale
-
we should expect that the HIM will be a key infrastructure for a
country’s entire healthcare system, including existing private sector care
delivery networks. This means it should stick to families of interfaces that
the existing eHealth “market” favours… otherwise the ability to connect in
existing products will be very problematic, if not impossible. In short:
support legacy/commercial systems; don’t expect everything is going to be
written from scratch.
-
we don’t have the bandwidth, ourselves, to take on the job of having to
write new standards… or even to have to profile existing ones – at every
turn. No single stack of standards is perfect, but they don’t need to be for
us to be successful. Good enough is… well… good enough.
I will be sorry to miss this discussion, if it makes its way onto today’s
agenda. But I hope this short email frames the nature of my concerns on the
topic.
Warmest regards,
Derek.
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com
This communication is intended only for the party to whom it is addressed,
and may contain information which is privileged or confidential. Any other
delivery, distribution, copying or disclosure is strictly prohibited and is
not a waiver of privilege or confidentiality. If you have received this
telecommunication in error, please notify the sender immediately by return
electronic mail and destroy the message and any attachments.
Le présent courriel et les documents qui y sont joints sont confidentiels et
protégés et s’adressent exclusivement au destinataire mentionné ci-dessus.
L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à
leur caractère confidentiel. Toute prise de connaissance, diffusion,
utilisation ou reproduction de ce message ou des documents qui y sont
joints, ainsi que des renseignements que chacun contient, par une personne
autre que le destinataire prévu est interdite. Si vous recevez ce courriel
par erreur, veuillez le détruire immédiatement et m’en informer.
–
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
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
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 openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl@jembi.org