Halamka on Enabling Nationwide Interoperability

John D. HalamkaIt’s been over 10 years since ONC head David Brailer and HHS Secretary Tommy Thompson published the “The Decade of Health Information Technology”, one of the goals of which was to create a “a new network to link health records nationwide.”  Since the beginning, government planners have advanced the notion of a national-level network, at first suggesting a single “national health information network” architecture, which was later modified to be a “nationwide health information network” built on a foundation of federally-subsidized regional health information organizations (RHIOs) working together across the country.  

More recently, the ONC Interoperability Roadmap, recognizing that the building blocks of universal interoperability could not be so neatly erected, leans on the idea of “coordinated governance” of networks.

While these frameworks have paid homage to the concept of nationwide network as a “network of networks”, we have yet to crisply define the stitching needed to form this nationwide network quilt. This issue hasn’t been so pressing up until now because there were relatively few networks – the “last mile” problem was the bigger concern. Network formation is evolving rapidly, however, which has made more pressing the question of what it means to connect networks in a uniform way.

We believe that there are five key interoperability transactions that need to be operationalized across networks in order to achieve the goal of nationwide interoperability. Those are:

1. Patient matching/identification.
2. Provider directory supported by a FHIR query/response transaction.
3. Constrained CCDA payload with little to no optionality.
4. Data-level FHIR API for MU common data elements and a document-level FHIR API for a CCDA supported by a standard schema and controlled vocabularies.
5. OAuth/OpenID Trust fabric supported by appropriate HIPAA/state/local policies for consent.

There are obviously many other interoperability functions that have value in the market, but we believe that those are best left to individual networks to provide within their networks as their customers and stakeholders see fit and are willing to pay for and enable. This is exactly how other network-based industries have developed. Wireless connections work seamlessly across networks even though within their networks they don’t all use the same standards or offer the same functions (e.g., Verizon users can do more with each other than they can with AT&T users, for example, which is also true for iphone users).

We obviously made some decisions about what to relegate to within network. For example, what about a record locator service? We do appreciate the value that record location can provide, but given the variation in network architectures that exists today and the policy complexity involved, we see this as a capability that is best left for the future.  We also caution against letting the perfect be the enemy of the good. It’s important that we begin with achievable, practical steps and grow from there.

How would this be accomplished? Network development is now at the point where the private sector – a small group of existing networks such as CommonWell, Epic CareEverywhere, Surescripts, DirectTrust, the eHealth Exchange – should assemble to roll up their sleeves and agree on practical, federated solutions to these five issues.  And if the experiences of other network industries is any guide, once a critical mass of networks launches such functions according to open industry standards, the rest of the market will soon follow.

In our various speaking events at HIMSS this year, you’ll hear a call to action from Micky and me to move this agenda forward.