This wiki page attempts to be a common place where we discuss the question : What Standards will we adopt for exchanging health information ?
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.