"stacks" of standards

dritz · June 25, 2013, 1:14pm

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.

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.

Tucker_Mark · June 25, 2013, 1:17pm

Derek,

Do you means stacks like: "HL7 V3", or "HL7 V2"
Would you have a heart attack if that stack was HL7V2 with CDA ?

Mark

P.S. I'm back from vacation, and may have missed a lot of the conversation ......

···

-----Original Message-----
From: openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com] On Behalf Of Derek Ritz (ecGroup)
Sent: Tuesday, June 25, 2013 9:15 AM
To: openhie-interoperability-layer@googlegroups.com
Subject: "stacks" of standards

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.

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.

ryan · June 25, 2013, 1:30pm

Hi Derek,

Thanks for these points. I too agree that these are vital. These point will likely be the topic of subsequent calls as we get into designing the Interoperability layer and SHR solution. For this call we will likely stick to the evaluation that we have done so far. So, hopefully you will be able to be on the next calls where we can begin these discussions. I suspect these “standard stack” discussions will go on for some time.

Cheers,

Ryan

···

On Tue, Jun 25, 2013 at 3:17 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Derek,

Do you means stacks like: “HL7 V3”, or “HL7 V2”

Would you have a heart attack if that stack was HL7V2 with CDA ?

Mark

P.S. I’m back from vacation, and may have missed a lot of the conversation …

-----Original Message-----

From: openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com] On Behalf Of Derek Ritz (ecGroup)

Sent: Tuesday, June 25, 2013 9:15 AM

To: openhie-interoperability-layer@googlegroups.com

Subject: “stacks” of standards

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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

derek.ritz · June 25, 2013, 2:24pm

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.