Hi all.
The standards “ecosystem” includes more than just the governing standards (or profiling) body – it includes the health informatics communities, IT communities, vendor communities (both tools and products), etc. The choice of an eHealth standard has implications for all of these ecosystem stakeholders in a country (and vice versa!). Paul has pointed out a crucial distinction – there is a big difference between profiling existing standards for deployment in a context and writing new base standards. Our “low-resource” use cases and requirements require us to do much more of the former than the latter.
Can we accomplish what we need to accomplish using XDS/MHD, HPD, PIX/PDQ and other IHE profiles? Yes… almost entirely. But addressing the “almost” is important to us. And as Paul has also pointed out – so far, our experience with them (the IHE technical committees and leadership) has been a success, but it certainly has had its bumps, especially early on. Would we need to profile CDAs for some use cases that have not been on their committee radar so far? Absolutely. In fact, we should expect that this would likely be a national-level configuration for each country. But these CDAs are built from a collection of templates and we should make sure all the templates we need are there (and they aren’t, yet). We’ll need to know that we can get IHE’s attention and that they will support that kind of effort. These conversations are ones we’ve not yet had with them, but I hope we will soon.
Do we need to use the same standards for internal messaging as for external messaging? Architecture is the answer to that. If we expose our “above the HIM” assets, then yes. If we abstract them, then no. But that doesn’t mean we aren’t standards-based within our own datacentre, it just means we can relax some of the burdensome elements that are part of message exchange in the wild (such as authentication, authorization, firewall-routable enveloping, etc.). At Mohawk, for example, their Canadian-conformant system speaks HL7v3 to the wild, but internally in the ESB it speaks a boiled down message spec they call RIMMISH that does not include the overhead that would otherwise slow it down. We could employ a similar pattern and would do it (if we do it) for the same reason – speed.
The inaugural architecture call is one I’m looking forward to, too. In this, our year of engineering, I think we are to the point where these issues have to be answered – for us all as a community of communities. The evaluations so far have been diligent. We understand these issues well. I also know we can “win” with any one of the credible candidates we’re looking at, so it is now just a matter of picking one.
Derek.
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.
From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Paul Biondich
Sent: August 8, 2013 8:38 AM
To: ohie-architecture@googlegroups.com; openhie-shr@googlegroups.com
Subject: Re: Abridged summary of ohie-architecture@googlegroups.com - 3 Messages in 1 Topic
Hi Ryan,
No, I don’t think I’m saying that.
Again, standards development organizations come with all different sorts of approaches to this.
We are leaning pretty heavily towards IHE now, because they allow for various base standards to be “composed together”, and there seems to be a pretty healthy level of interest amongst their leadership to allow us to evolve existing standards to meet our demonstrated real world needs. Of course, that needs to be tested and we all need to be comfortable with that.
Remember, the HL7 organization produces base standards, that can be wholly used and specified within IHE profiles. Profiles simply further how base standards are used for a specific use case (like sending a antenatal visit, etc).
I think we need to have our inaugural “architecture committee” phone call here soon, as there seems to be some misunderstandings amongst folks about how some of these organizations work. This could be the first topic.
-Paul
On Thu, Aug 8, 2013 at 3:50 AM, Ryan Crichton ryan@jembi.org wrote:
Good discussion. So, from what has been said do we actually want to support multiple standards in the long run? This would allow an implementing country to make the decision on what they would like to implement and we don’t ‘push’ particular standards onto them.
Obviously, we would have to choose something to start with and then build additional support as need be. From what it sounds like here we should probably start with standards in an ecosystem where we are welcome to participate. I know IHE does allow us to easily participate, I’m not so sure about the HL7 process though.
Another problem I see when thinking of choosing between the IHE ecosystem and the HL7 ecosystem is their fundamentally different approach. IHE produces profile for specific use cases and for sharing specific data. HL7 on the other hand produces more general standards that allow you to represent the data that the user needs to for a particular use case. From what I’ve seen of IHE CDA profiles they collect very specific data that often didn’t map to data that we were collecting (for example in Rwanda). I’m not sure what the solution to this would be. Would we have to profile our own CDA in this case? For HL7 they provide the generic structures to transmit the data that a user needs, but the user has to define what that data would be. Are these concerns true or are their other ways around this? I’d like to hear from those that have a more in depth understanding of these standards.
Cheers,
Ryan
On Wed, Aug 7, 2013 at 8:02 PM, Paul Biondich pbiondic@regenstrief.org wrote:
Man, Bob… very, very, very well said.
I think you have nailed the very dynamic that keeps me up at night when thinking about hitching to a specific gravitational force. 
I am completely uncomfortable in my leadership role to submit us and the countries we serve to a ecosystem process that doesn’t sufficiently enfrachise us to adapt the standards created within those ecosystems in a way that’s driven by real world needs and experience.
This is what we’re looking critically at amongst the various ecosystems, and I’m trying to have deliberate conversations with their leadership as I get the chance. Perhaps you and I can tackle these dialogs together?
-Paul
On Wed, Aug 7, 2013 at 1:53 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Paul, I am impressed with your command of the marxist dialectic between form and function
I think your metaphor of gravitational force is powerful and apt. In my experience of working with standards and standards organisations from a South African perspective and alongside colleagues and fellow activists in Latin America, it is these centres of power which are most problematic. We are often faced with two equally troubled choices:
(i) we take on “stacks” of standards from global organisations in which we have very little real power and influence, whose standards were/are developed for very different economic, social and political contexts, but which nevertheless represent the combined wisdom (that is the tricky bit SDOs do) of a great many smart people; or
(ii) we try to address problems in the context in which we find them, using the best of what is appropriate from elsewhere, and in the process capture and share the wisdom we accumulate. With the clear danger of meandering off in amateurish diversions and reinventing wheels.
I think there is indeed a synthesis between these contradictory approaches. And it requires changing the balance of power within SDOs, even by little bits, to continually raise the validity of the healthcare contexts of what are effectively the majority of people in the world as real and concrete sites where functions are performed. So we can get out of them (and put in) forms which work. That is an ongoing challenge.
Bob
On 7 August 2013 18:19, Paul Biondich pbiondic@regenstrief.org wrote:
Totally agreed here, Jack… it’s been my instincts and experience as well.
I want to take a crack at re-casting the conversation point here, to see if we talk less at cross purposes.
On one dimension, the operationally-focused folks on this thread are suggesting that you can’t just select a “bucket of standards”, because of the multidimensional complexities of making this blanket call. Form needs to follow function in other words.
Derek and others on the other hand are suggesting that we need to hitch our wagon to a consistent approach towards documenting and more explicitly specifying how and what standards are being used for various use cases. There are ecosystems which revolve around the gravitational force of a few organizations (like HL7, like IHE). Some of these ecosystems implicitly accept that form needs to follow function, and they develop “profiles” around specific use cases using the various base standards Jack alludes to below.
These are two separate points that are not at inherent odds with one another. They are both valid, and possible to run in tandem with one another.
Does everyone that’s pitched into this thread agree with that?
-Paul
On Wed, Aug 7, 2013 at 8:48 AM, Jack Bowie jack.bowie@gmail.com wrote:
Another spin on the “dimensions” of this discussion is the distinction between data, message and interface standards. LOINC and SNOMED CT are “low-level” data standards. CDA and HL7V3 (mostly) are messaging standards and CTS2 is an interface standard. [Your definitions may vary 
]. Simplistically, message standards describe buckets (or structures of buckets) and data standards describe what goes into the buckets. Interface standards describe how the messages can be exchanged between actors, but this distinction often gets fuzzy.
The point is that just saying you want a stack of standards is not sufficient. Especially looking at a national program, the whys of standards are just as important as the whats. Governments that try to go too far, I’ll suggest the UK’s NPfIT as a poster child, have not been successful. As one example, it’s relatively easy to test conformance to data and message standards, harder with interface standards.
Jack
On Tue, Aug 6, 2013 at 8:39 PM, ohie-architecture@googlegroups.com wrote:
Today’s Topic Summary
Group: http://groups.google.com/group/ohie-architecture/topics
§ Standard for the SHR [3 Updates]
Standard for the SHR
Ryan Crichton ryan@jembi.org Aug 06 10:46AM +0200
Hi Derek,
Do you think it needs to be as black and white as that? That we can only
use a single standards stack? I understand that for particular domains
within the exchange it makes sense to use …more
Back to top.
"Derek Ritz (ecGroup)" derek.ritz@ecgroupinc.com Aug 06 06:58AM -0400
Hi Ryan (and all).
I think it is a matter of perspective. I’m looking at this issue from a
national MOH standpoint. That is why I referred to this as an “ecosystem”
choice.
…more
Back to top.
Paul Biondich pbiondic@regenstrief.org Aug 06 07:50AM -0400
Different people refer to “standards” with differing meanings and levels of
granularity in their minds, so I think it might be useful to clarify things
a bit in this conversation.
…more
Back to top.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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 “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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 “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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 “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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 “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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 “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
]. Simplistically,