Comments on: A Singular Opportunity for Health Interoperability

By: Charles Parisot

Charles Parisot — Thu, 05 Nov 2009 18:23:37 +0000

You are providing a great analysis in distinguishing two layers, the transport, or \HTTP side\ and the payload or \HTML side\. This transport vs payload discussion is only partialy the problem.

There is an elephant in the room, the glue layer, where the real challenges lies, that you mention several times but never really address. This middle layer sometimes called the envelope layer, needs to be discussed and is the root of the proliferation of incompatible transports. You put your finger on it quite well when you say: \This is a tricky business, because there is overlap. I don’t really know how much IHE and HITSP have already done to create the correct separation.\ Much work has been done to create this separation, by having a glue layer above the strict tranport (does not matter whether it is REST or SOAP), what matters is that this glue layer is simple but effective to manage in a consitent way and architecturally flexible way the communication of payload (in a payload agnostic way):
— On portable media
— In simple point-to-point
— In environments where sharing is supported by the infrastructure (rather than by a closed application).
— In federations of networks
The business problems addressed by this enveloping layer are key to trusted and reliable health information exchange:
— Replacing, Deprecating previosuly communicated payload
— Conveying means to identification the person associated to this payload
— Conveying sets of objects that form an atomic set (healthcare calls this a stapple !)
— Conveying the identification of the source institution, so that it can be called on the phone, in case the payload cannot be processed
– Conveying some meta-data so that the payload be routed beyond point to point connections.
– Conveying the necessary information to enable workflow eventing

It seems important to avoid poluting the \payload\ or the generic transport and to look carefully into the work performed in this area, but not assume that this middle layer does not exist.

By: Keith W. Boone

Keith W. Boone — Thu, 05 Nov 2009 10:15:14 +0000

Could be, see Synthesis for a response.

By: Tweets that mention A Singular Opportunity for Health Interoperability -- Topsy.com

Wed, 04 Nov 2009 17:25:09 +0000

[...] This post was mentioned on Twitter by Gartner, John N. Huff. John N. Huff said: RT @Gartner_inc: A Singular Opportunity for Health Interoperability: Wes Rishel, Gartner, on his blog http://bit.ly/P3u3R What do u think? [...]

By: The Recovery Room - 11/3/09 — HITECH Answers

The Recovery Room - 11/3/09 — HITECH Answers — Wed, 04 Nov 2009 06:03:55 +0000

[...] in their own right. My apologies! I also found these panelists blogs, Adam Bosworth, Sean Nolan, Wes Rishel, and Dr John Halamka on their thoughts after the [...]

By: Joe Bormel

Joe Bormel — Tue, 03 Nov 2009 15:19:28 +0000

Wes,
Implied in your response is that a term mapping layer (relatively straightforward) will be inadequate to achieve “rich” semantic interoperability. In your opinion, is there a legitimate lowest common denominator for comparatively “poor” semantic interoperability that wont suffer from the absence of a strong information model?

By: Wes Rishel

Wes Rishel — Tue, 03 Nov 2009 15:00:36 +0000

Joe, so far V3 messages are not on the table for the US. However the CDA definitely is, particularly in specific constrained applications such as HITSP C32. This is a difficult issue. Because the element names are generic ( or ) and made specific through codes in coding systems identified by OIDs, the XML wire format is hard to understand. It is arguably the case that this is a strong inhibitor to adoption in the free-wheeling world of the Internet. It is also notably more difficult to work using productivity tools that are applicable to most XML data representations.

This is an issue that needs to be addressed on the “html” side of the “http/html split.

By: Joe Bormel

Joe Bormel — Tue, 03 Nov 2009 14:50:37 +0000

One of your prior observations was that only a few hundred people in the world understand v3, and, notably those who dont design and build what we get [I know I'm paraphrasing].

It seems to me that an underlying concept in your post is that few people responsible for executive decisions appreciate the importance and nuances of layering. Does taking a RESTful approach address this recurring source of execution failure? – OR – does RESTfulness still require an architectural mindset, including separating out functional layers, with the same kinds of discipline that were at play in the creation of v3 and HL7 itself?