Sean Nolan’s blog highlights that NHIN Direct has stumbled on a “tough” decision. We didn’t come to agreement on the backbone protocol despite an absolutely outstanding process for increasing understanding as opposed to so many meetings where the opposite of speaking usually is not “listening” but “waiting to speak.” Sean characterized the split in the group as being between “big vendors” and “small vendors.” (Ironically, Microsoft is aligned with the “small vendor” axis because its interest is in enabling the hyper-evolution of new approaches that has been characteristic of the Internet in other industries – my words, not Sean’s.)
Writing separately, Arien Malec (the NHIN coordinator) has characterized the split as between EHR vendors and others, rather than Sean’s big vs. small categorization. It is hard to tell the difference because only large EHR vendors have the resources to put into big group processes like NHIN Direct has become.
Sean and Arien are lumpers and I’m a splitter. If you look at the assumptions that are driving the participation I saw nine different points of view:
- A better way to make standards. The lesson taken from testimony at the HIT Standards Committee was that assembling a small group of players with a common vision, strong leadership and a plan for early implementation works better than the more ponderous “design by ballot box” approaches of large standards efforts. “Rough consensus and move to code; intermingle completing the consensus with writing code.” A consequence of this approach is that the work product will be judged later by whatever consensus process is necessary to adopt it as a standard; the work product is not preordained to get that far.
- Discard and start again: the EHR market is basically broken and needs to be replaced by products that great innovators could produce if they weren’t constrained by a regulatory process and standards process that is way too willing to embrace complexity. NHIN Direct must lay the groundwork for this.
- The Long View: the primary goal of NHIN Direct is to start a long term process of incremental architecture towards enabling the business innovation. Increment number one should be “messaging” across EHRs and non-EHR users, but that is only a start. The approach must enable future growth of the security infrastructure and the behaviors that can be enabled among participants that go way beyond simple delivery of messages.
- The RESTful Long View: everything that that long-view guy said plus a commitment to the ultimate architecture being RESTful.
- Top-downism the path for health information exchange has been set down by the grant program. Without such an organized approach attempts to interoperate are doomed to failure. NHIN Direct should be limited to those areas that can help the master plan succeed, but it should not create an alternative path to interoperability.
- Minimal Value: EHRs are at least adequate to meet the needs of improving healthcare. The basic problems of interoperability have been solved by IHE, the HIE grants and prior NHIN work. The only reason for NHIN Direct is to get hospitals connected to EHRs owned by community physicians faster than can be accomplished by standing up HIEs.
- Deadline Fatalism(1): the rules of the game are set by the ARRA; this effort is only useful if it allows are clients to more quickly achieve EHR-to-EHR communication in order to qualify for incentives earlier.
- Deadline Fatalism (2): like #1 but it also includes supporting hospitals in communicating with physicians who do not have EHRs that qualify for incentives. This will be important for transitions of care and potentially for meaningful use requirements in Stage 2 or Stage 3.
- There’s gotta be something better, sooner. The vision of nearly universal EHRs communicating through a ubiquitous set of HIEs that are interconnected via the NHIN too far in the future. These folks want to see something a little better than the fax machine as soon as possible. They will be happy if it helps compliance with meaningful use, but the requirement is much more basic and the impact more profound than simply helping to earn incentive money.
The size and diversity of the NHIN Direct is making it more difficult to hold to the “better way to make standards” view. We have become a group of strange bedfellows where the strangeness is stronger than the fellowship.
The size of the group is partly a result of the attention it has received from ONC. Otherwise, we wouldn’t see the “top downists” and the “limited value” folks who basically believe that the main challenge is to execute on an established direction. Many believe that the outcome of the NHIN Direct group is automatically destined to be a standard recognized in federal regulations. ONC has said the opposite but they haven’t been heard or understood.
If those that don’t believe NHIN Direct is mission critical fall way, would any of the established EHR vendors continue to participate? If so, it would be because they fall into the “Deadline Fatalism (2)” or “There’s gotta be something better, sooner” categories.
To their credit the HIT vendors have come a long way in offering to adapt the IHE standards that are used in NHIN Exchange. They have offered a “pure push” approach. They have offered to remove any protected health information from the unencrypted portions of the messages available to HISPs. The main sticking point seems to be whether the secure backbone protocol is SOAP, WS-* security, supported by the interface discovery capability in UDDI.
Unfortunately, the RESTful Web services movement was founded as a reaction against some of the assumptions inherent in the SOAP/WS-*/UDDI approach. RESTful Web services is a different approach for dealing with complexity. There is substantial justification for this but, but the basic notions of how to design RESTful Web services is still evolving. The team working on NHIN Direct didn’t get beyond some very simple test code and didn’t demonstrate the deeper values of the RESTful approach. I personally think those values can be achieved but this will take much longer than the REST advocates believe.
(This debate about RESTful vs traditional Web services sounds a bit like the Astronomy society deciding whether Pluto is a planet. But it is more like cosmologists arguing a theorem. The outcome can profoundly shape future directions.)
Frankly, there is not enough evidence in the world to put to bed the argument about whether the WS-* approach is good enough or better, or whether RESTful Web services is the way to go. Absent evidence people will back their instincts and their instincts will be guided by their experience (they work they have already done), the amount that they will have to work to adopt a new approach and which of the nine points of view (above) they have.
If it goes to an approach of achieving decisions that are not consenuses (e.g., simply voting) then the process becomes one of which side can muster the most votes. One of the factors that shaped this effort was complaints about the HITSP experience wherein a number of participants felt steam-rollered by a few that they perceived to be an organized bloc with a particular agenda. I am not endorsing this view, just pointing out that thoughts like this are the inevitable outcome of a decision process that is not a true consensus process .
A Path Forward
I have rewritten this blog several times now. The trend has been from trying to find a path to reconciliation towards trying to have purposeful “disreconcilation.” Instead of having the group make a decision the decision is going to make the group.
The group must be reduced to a working size of folks can roll forward enthusiastically instead of feeling put upon because this is a diversion from their important work. So I would urge those who really think that NHIN Direct is unnecessary or unimportant to drop out. We can arrange for better communication beyond the group on what is going on than we have achieved so far, so those folks shouldn’t feel that they lose their insight into what is going on by dropping out. If you like what you see or find more industry acceptance than you imagine, we are doing everything we can to make it easy to get back in again later.
Among the members who do feel that the NHIN Direct idea is needed, we need to split into two or three groups. There still may be a substantial group that supports SOAP+UDDI for the backbone. If so, they should be a group with whatever governance they favor and their own process for getting to a working body of open source code and unfettered, comprehensible specifications. Perhaps IHE would like to host this effort since it so strongly builds on existing IHE work products.
Those that support “RESTful but maybe SMTP” or “SMTP but maybe RESTful” may become one or two groups according to whether they have enough appreciation of the combination of short-term and long-term views to have enthusiastic agreement. If this is one group it should favor an initial implementation using SMTP with a security infrastructure that will also support REST. It should look for another opportunity to use REST for a behavior that is different than pushing packaged messages around.
The deciding rule for forming groups should be to establish the minimum number of groups where the members of the group can work enthusiastically rather than feeling dragged along against their better judgment or when other work is more important.
With one or two smaller groups we can get back to proof by code rather than design by the ballot box.
This not ideal. Maybe all the groups will fail. Maybe they each will continue to split until there is no critical mass. Maybe they’ll all succeed and we’ll have “many standards to choose from.” Those would all be bad outcomes. But the current path is not tenable and the most likely path is that one of the two or three groups will be better able to prove their approach in the next few months and will end up with a strong enough case that others join in.
Isn’t that how the Internet was built?
(Last revision 13 June 2010 10:25 pm EDT)
Category: Healthcare Providers Interoperability Vertical Industries Tags: ARRA, EHR, Health Information Exchange, Health IT, Healthcare Interoperability, HIE, Meaningful Use, NHIN, NHIN Direct, RESTful Web Services, simple interop, UDDI