(Preface)
This wiki page attempts to be a common place to press forward where we discuss the question : What Standards will we adopt for exchanging health information ?
Attached is one email message that has plenty of fodder for discussion.
...
Here is an email discussion that highlights the key points:
Date: Thursday, June 27, 2013 4:56 AM
Subject: The "stacks" of standards : V2+CDA+Profile
Hi All,
I'm bringing 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'.
My first instinct in this situation is I want best of both (pretty in and pretty out -- mainly
because....well just that would be the best) but realistically we can't do that right now, and I feel
we need to start to make a decision down a road. Secondly my thoughts are running around well
can we move from one to the other over time and under the thinking of yes I am faced with the
thoughts of which of the 2 options we lead with.
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 thinking is also running around, do we want a system that is very pretty inside but no-one
is adding to it or do we want a system with multiple existing tools contributing to it that is
focused at addressing the complexity of data management.
My 2c for the morning and (I think) christening the architecture list.
Cheers,
Carl
---------- 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:
1. HL7v3
2. OpenEHR / ISO 13606
3. 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:
1. the HIM plays a crucial, central role as the "plug and play" bus
2. 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
3. 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.
4. 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.