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.
Amen. I completely agree and am excited to see there are others with the same opinion. These standards, although agreeably well intentioned, are generally of little value, difficult to implement, and rarely fully understood even after implemented. Forever and ever these standards were only challenged by a few brave souls typically slammed by responses from ISVs and auditors like 'FDA or HIPAA required' and this is necessary to support health care when neither or true. It is nice to see more and more people challenging them who can influence change... Nice. Best wishes.
Could be, see <a href='http://motorcycleguy.blogspot.com/2009/11/synthesis.html'>Synthesis</a> for a response.
Thanks for the personal perspective/view from the HIT Policy Committee meeting.
Now two questions for you, one easy, the other less so:
1) What does the acronym SDO stand for?
2) Within the context of the NHIN/Health Internet that we discussed previously, how does this separation of "church" and "state" occur? Might the Health Internet define the health specific HTTP, or do we already have a secure enough transport mechanism in https and what the Health Internet can address is more along the lines of policy, or should it also extend to content?
Hey John, hope all is well and that you're dealing with the Yankee win better than I am.
1. "SDO" = "Standards Defining Organizations" ... I definitely need to curb my acronym usage.
2. This is a great question, and not one I have a complete answer for --- I remain optimistic that as we build out the Health Internet (on real servers, not just in the abstract) we will get better clarity on this kind of thing. For example, with just https we're missing some stuff that may be really important, like digital signatures to prove document integrity and source. I expect to post some more complete thoughts on this within the next few days and would very much appreciate your reactions to them.
Not really concrete answers --- will try to do better soon!
I agree that separation of content and transport is good, and SDOs have by and large stayed out of that. However, Profilers, who create implementation guidance for specific use cases, e.g., HITSP and IHE, seemed to be forced to combine in one implementation guide both transport standards and content standards to provide full clarity on how to implement the multiple standards required to support a particular use case. Clearly there can be improvement in how HITSP or IHE document, while considering their challenge to cover multiple standards, but let's not confuse Profilers and SDOs. Now, if the concern is that implementation guidance should not address transport and leave that up to whatever makes sense, i.e., remove that from the implementation guides, then let's have the discussion on that topic. But if there is value in providing guidance on transport mechanisms, then somewhere an implementation guide will have to reference both content and transport. Therefore, are you saying that there should be NO specifications re transport ("use anything you want"), or are you just saying that there should be many transport options that are independent of the content? For example, should a lab result from a lab to an EHR be able to be e-mailed, sent on media, use a VPN, use https, etc.?