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.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.