The Case for IHE

From Direct Project
Jump to: navigation, search
Concrete Implementation Workgroup > IHE Implementation Development Team > The Case for IHE
  • The goal of the NHIN Direct Project is "to expand the standards and service definitions that, with a policy framework, constitute the NHIN ... At the conclusion of the project, there will be one nationwide exchange, consisting of the organizations that have come together in a common policy framework to implement the standards and services."

As the NHIN Direct implementation group considers the feasibility of each proposed implementation, we are well advised to keep the goal of the NHIN Direct project in mind. For each implementation, we must ask ourselves:

  • Is it simple?
  • Is it scalable?
  • Is it sustainable?

The IHE implementation is the simplest, most scalable, and most easily sustained implementation to move the healthcare industry along the path to NHIN Direct's goal of one nationwide exchange.

What's the IHE Implementation?

The IHE Concrete Implementation Group proposes an NHIN Direct backbone protocol defined by a healthcare initiative called Integrating the Healthcare Enterprise. Specifically, our HISP to HISP backbone uses the XDR standard, a lightweight point-to-point protocol designed specifically to push documents from a source to a destination. Rather than dictate XDR from end-to-end, our implementation demonstrates variable endpoints, such as REST and SMTP, thereby pairing a defined, standardized, and industry-tested protocol for backbone communication with flexible edge communications. More technical details can be found in our Implementation Capability Worksheet.

Is it simple?

At first glance, an IHE implementation might not seem as simple as, for example, sending an e-mail, messaging with IM, or filling out a form on a web page. But we must ask ourselves what "simple" means in this context. For a healthcare provider who uses an electronic health record system (a scenario that will only become more common because of Meaningful Use incentives), communicating with other healthcare providers in the context of his workflow, through the same EMR that he uses daily in his care of his patients, is simple. Switching to an e-mail client in the middle of his workflow or reauthenticating himself to a web form is an extra step which is less simple. Over 60 EHR vendors are already supporting either the exact protocols used in this implementation or protocols that can be transitioned to this implementation with a relatively small amount of development and virtually no infrastructure investment. And every major development platform (e.g., .NET, Java) supplies built-in tools and abstractions that allow for rapid and robust development of the necessary transactions for XDR-based exchange.

NHIN Exchange has already laid the groundwork necessary for enabling a nationwide network of healthcare communication. An IHE implementation, simply, puts NHIN Direct on the most straightforward path to integration with NHIN Exchange. Users shouldn't need to consider which workflow they'll use to access information via NHIN Exchange versus information provided through NHIN Direct, and EHR vendors and HIE Hubs shouldn't need to support parallel communication methods. The simple solution is one that eliminates variability, makes the most efficient use of scarce development resources, and focuses on core protocols, infrastructure, and use cases.

But we recognize that not every provider will use an EMR, and not every vendor will support the backbone protocols we advocate. The IHE Concrete Implementation workgroup is demonstrating that multiple edge protocols can be “stepped up” to our proposed XDR-based backbone, which can then be “stepped down” to multiple edge protocols. We needn’t have an end-to-end solution based on what is best for the lowest technology threshold. Instead, we can accommodate those with minimal technology as well as those with EHR systems or modules that speak IHE natively. Our solution allows for both the inherent variability of edge systems and the uniformity of the services strengthening the backbone.

Is it scalable?

A nationwide communications network, in order to be valuable, must be not only ubiquitous but also widely used. After all, no communications technology, from phones to faxes to Facebook, has any practical use without a critical mass of users. Regardless of the implementation the NHIN Direct group settles upon, providers who wish to participate will need to undertake some procedural steps to establish their identity, receive an address, and establish secure networks. This cost, while not substantial, is still significant, and so NHIN Direct must provide an incentive for participation. The best incentive we can offer is the potential that, when providers are ready to communicate, they will have someone who's ready to communicate back.

Contrary to popular belief, most commercial EHR systems support protocols in the IHE family today, as do many HIE hub solutions. Not only does the healthcare IT industry as a whole have this technical experience, but state-based healthcare exchanges are being initiated at notable speeds, fueled by government funding and a federal commitment to supporting standards-based exchange. A scalable implementation is one that can leverage this fiscal commitment to provide potential users with a ready-made community.

A scalable implementation must bridge the gap between isolated islands of exchange and a network that crosses the nation. An implementation cannot be judged merely by the development cost of creating islands - we must examine the work needed to reach the ideal state. In terms of the total effort required to attain this goal, the IHE implementation is a clear choice; every development step taken to support an XDR-based backbone leads us further along the path to the nationwide grid. No development is extraneous.

Is it sustainable?

Perhaps the most compelling argument for a backbone of IHE-defined protocols is not technical but procedural. IHE's stakeholder participants include medical professional societies, government agencies, provider organizations, trade associations, and software vendors. A sustainable implementation is one that not only works out the technical details but also accounts for the necessary foundation of the principles, politics, and procedures of exchange. By choosing IHE protocols as our backbone, we can focus on the technical intricacies with the firm assurance that the bedrock is solid.

A sustainable implementation must prove itself, through testing, documentation, and a common language to define expected scenarios and outcomes. IHE, besides providing standardized and documented profiles, frameworks, and implementation guides, also hosts an annual Connectathon solely devoted to proving interoperabilty. Any implementation must create this support structure in order to maintain viability beyond the NHIN Direct pilot; IHE has created it for us.


The IHE Concrete Implementation workgroup has proposed an implementation that is simple, both for its users and the systems that will support them. This implementation is scalable, using variable edge protocols to connect to a nationwide communications network. And it is sustainable, through the substantial work of those upon whose shoulders we stand. When we ask ourselves these questions, the answer is clear.