Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Coverage Areas:

A Singular Opportunity for Health Interoperability

by Wes Rishel  |  November 2, 2009  |  7 Comments

Sean Nolan of Microsoft just published a finding from the HIT Standards Committee testimony on implementation last Thursday. See his blog item  Hey — was that just an HIT Standards breakthrough? I summarized and perhaps oversimplified an analogy that had built up during multiple conversations by saying healthcare SDOs should “get out of the HTTP business.” The analogy developed from a conversation on the benefits of the Internet suite of protocols by having cleanly separated layers and, in particular, separating specifications on data (such as HTML) from specifications on the communication protocol (such as HTTP, HTTPS, etc.)

A number of healthcare standards and standards-profiling groups have published not only format standards, but also communications standards. Some do not. One of the reasons that HIPAA transactions were largely a failure is that the regulations included no approved method for communicating X12 transactions. Providers must conform to many dozens of different various specifications for the physical transport of data in order to get their bills paid. Alternatively they can pay a substantial click fee to clearinghouses to cater to the communications-spec whims of the payers.

I did not at all mean to suggest that the ONC in its role guiding the implementation of the ARRA should allow the same thing to happen again.

The HTTP Side

To a certain extent the specifications that are most disputed now relate not directly to HL7 standards but to specifications created by Integrating the Healthcare Enterprise (IHE) and adopted by the Health IT Standards Panel. Those poor fellas at IHE started working on an approach to cross-enterprise data sharing in about 2004 and believed IBM and Microsoft that Web Services would be the way to achieve secure, reliable, technology-neutral inter-enterprise interoperability. At the same time they adopted ebXML as a then-proven approach for store-end-forward messaging.  IHE members dumped a ton of sweat into puzzling through the specs, developing selective profiles of them that might actually interoperate, conducting repeated multi-may inter-vendor testing sessions and honing their specifications. Now that they made this investment they are naturally reluctant to give it up. There are actually live implementations now using these protocols, we learned last week.

Oh how times change! During the five years that have passed new entrants such as Google and Amazon have joined the ranks of market-dominating vendors, serious concerns have developed about the complexity of Web services and everybody’s favorite new approach is RESTful Web services‎. This approach is, indeed, simple and layers well. There is a lot of real-world use of RESTful Web services. Security is very simply provided by using the security associated with HTTPS.  Other requirements important to healthcare, such as non-refutability transmission and receipt, can be handled equally well. Probably many of the big firms already are.

In fact, I would venture that each of Amazon, Google, Microsoft and other dominant players each have one or more specs built around the concept of RESTful Web services each of which is simple, particularly because it was catered to the needs of their specific applications. Like providers sending in HIPAA bills, software developers have to develop interfaces that are generally the same but differ in enough specifics that they either align with one vendor or re-develop their interfaces for each.

Is that the best we can do for healthcare interoperability? Somehow I had hoped for more. I don’t really care about RESTful Web services or the other kind. I do care that N x M interoperability work for medium sizes of N and M. For example, if a vendor or care delivery organization (CDO) is developing a clinical solution that needs to interoperate with some other HCOs, labs, multiple PHRs, public health and quality measurement agencies, I would like to believe that they could do so, without getting into a “my business is bigger than yours ” contest. It is clearly not the case that every CDO needs to talk to every other CDO. More and more they will outsource the communications to their vendors, a trend that is underway. So, would each vendor have to be a clearinghouse? Would a new vendor coming into the market face a daunting challenge because it needs to develop a body of intellectual property to communicate with all the labs, PHRs, payers, health agencies and quality measurement organizations, each of which uses a different approach to RESTful Web Services?

Let’s suppose that all the various supporting specs needed for healthcare interoperation already exist in one or the other of the big vendors’ use of RESTful Web services. Is there really a standard for all that that is standard as, say HTTPS or HTML? If so, great let’s go full time ahead. If there is no standard but a lot of good experience, can we somehow put together a tiger team that looks at what’s in use and agrees on a common approach? Such a team would have to follow much of the advice we heard at the HIT SC testimony last week including:

  • focus solely on the most immediate needs for fulfilling meaningful use requirements
  • focus on reusing what is widely being done across many industries
  • spec a little, implement a little, test a little, spec some more until you reach a stopping point
  • create open source specs and code that has been tested for interoperability.

The “HTML Side”

There is also work that needs to be done on the side that is the equivalent of HTML in our metaphor. This side includes the specs that represent the payloads communicated through HTTPS for healthcare interoperability. Perhaps the most critical thing is to revisit the specifications to see whether they intermix information needed for the communications with information needed for business processing of the payload. 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. Perhaps it is already done. But if not, could a “tiger team” on the payload side work closely with the communication side to sort out these issues and provide an urgent interface back to the standards bodies if any changes are needed?

Can We Create the Trust to Get This Done?

Like Sean, I see this as an opportunity to get the U.S. healthcare industry to make a leap forward on interoperability that could meet the challenge of the ARRA meaningful use criteria.

For something to come of this, various parties will have to trust a small team to do the work without the formal governance of an SDO. Developers will have to be prepared to accept solutions that require changes to their software. SDOs will have to accept the challenge to change their standards to catch up with the work of the tiger team.

The biggest problem will be antibodies created by the bile and spittle of numerous commenters in this area. Every time an advocate for a more RESTful approach refers to Electronic Health Record Association and IHE as being a cartel working to restrain trade it becomes that much harder to bring the mainstream EHR vendorsto the table. On the other side, HITSP, IHE and others need to do a better job of understanding the advantages of totally separating the two layers and be willing to give some in order to bring in the Health 2.0 crowd.

If this is going to work, all parties are going to have to accept that we need some change and we have a singular opportunity to accomplish it. They are going to have to accept that the parties they disagree with won’t go away. They must refute even their supporters who continue to play the name-calling game.

In the words of comedian Judy Tenuta, “Hey! It could happen!”

This posting was revised on 1 November based on thoughtful feedback from several people.

7 Comments »

Category: Healthcare Providers Interoperability Uncategorized Vertical Industries     Tags: , , , , ,

7 responses so far ↓

  • 1 Joe Bormel   November 3, 2009 at 9:50 am

    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?

  • 2 Wes Rishel   November 3, 2009 at 10:00 am

    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.

  • 3 Joe Bormel   November 3, 2009 at 10:19 am

    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?

  • 4 The Recovery Room - 11/3/09 — HITECH Answers   November 4, 2009 at 1:03 am

    [...] 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 [...]

  • 5 Tweets that mention A Singular Opportunity for Health Interoperability -- Topsy.com   November 4, 2009 at 12:25 pm

    [...] 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? [...]

  • 6 Keith W. Boone   November 5, 2009 at 5:15 am

    Could be, see Synthesis for a response.

  • 7 Charles Parisot   November 5, 2009 at 1:23 pm

    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.