Hey -- was that just an HIT Standards breakthrough?
I spent Thursday last week at the HIT Standards Committee's inaugural "Implementation Workgroup" meeting in Washington DC. The purpose of the meeting was for the committee to hear perspectives from folks who are "on the ground" and could offer real-world perspectives on the pros and cons of what HITSP has done to date --- to help guide its work going forward. I participated on a panel of five vendors that included HSG (me), Surescripts, RelayHelath, eClinicalWorks and Orion Health.
To set the stage clearly --- I have not been a huge fan of the HIT work coming out of the government and its advisory bodies. This is not because I don't think standards are a good idea, or because I think the committee members aren't smart and dedicated folks trying to do good work --- they clearly are both of those things. I just feel strongly that standards emerge when they are needed and desired - and that without those two ingredients they are at best irrelevant, and at worst become inadvertent obstacles to the kind of innovation they were intended to accelerate.
The reason we don't have greater adoption of healthcare standards is simple: the use cases they enable aren't sufficiently compelling to the parties expected to use them. ARRA dollars will have some impact on the motivation problem for sure, but that gravy train can't last forever - so we'd better be thinking beyond it if we want changes that stick.
Frankly, I felt like my testimony was only so-so. I feel pretty good about my written comments, but in the compressed timeframe of the meeting itself I didn't articulate my points as well as I expect of myself --- kind of a bummer. What I tried to say was: HITSP has at least one great success, namely the CCD. It works because it is a relatively simple, inclusive document that people understand and have real uses for. Let's focus on the lessons we can take from this example, and trim away all of the other noise.
Kind of the same arguments we've been having for a long time. Lots of exhortations to keep things small and simple, but without the specifics needed to make that advice actionable. Despite many examples of good insight throughout the day, as things wound down I was not feeling optimistic about any real change coming out of the discussion.
However, right at the end of the meeting, I heard something that got me really excited - it made my trip worthwhile and I am hoping that it just might be the start of a real shift. The specific comment came from Wes Rishel, but it was the culmination of a thread that started early in the day with Adam Bosworth, and popped up throughout the proceedings in comments from David McCallie and others.
Wes' statement was this (not an exact quote but very close): "We need to get SDOs out of the business of creating HTTP." The reference to HTTP started in the context of discussion the success of the web, when Adam made the observation that a key to this success was a clear separation of content (HTML) from envelope (HTTP) - meaning that each of them could evolve and innovate separately from the other - and that the utility of each was maximized. For example, we have been able to add security models on top of HTTP with no dependencies on HTML. And HTML has seen great use beyond the world of HTTP, for example in many TV set-top boxes that communicate over proprietary cable networks.
Even beyond the separation, the observation was made that transport simply is not a healthcare problem. Back when HIT standards bodies got their start, transport had to be built in from the ground up. This is no longer the case, but too much of the standards discussion is still based on whether we should use SOAP or REST or EDI or who knows what to move the data around - all the layers get conflated and create unwieldy and overly-restrictive end products.
This kind of thing has been said many times before --- it was in fact the real nut of I was trying to say in my own testimony. But I had never seen it articulated so clearly by members of the committee, and honestly I had never seen it that clearly myself. When I dig into the HITSP standards, the parts that drive me crazy are all about transport, needlessly-restrictive limitations on technology choice and other conflations obscuring the specific purpose of the standard.
So what does this mean? Well, maybe nothing --- but I am an optimistic guy and would love to see positive outcomes from the investments we are making as a nation in HIT and HIT standards. If just that one observation from yesterday sticks - we get out of the business of creating "HTTP" - we may really get somewhere.
