An overview of NHIN and NHIN Direct for software developers

If you're doing any work in the healthcare IT industry, you need to be familiar with the National Health Information Network (NHIN). This article provides a technical overview of NHIN and related sub projects called NHIN CONNECT and NHIN Direct. You can use CONNECT right now to create your own health information exchange (HIE) or connect to an existing HIE. NHIN Direct is new and doesn't have immediately usable code, but when it's ready you can use it to push or pull data from your medical systems to other healthcare systems directly (without necessarily going through an HIE).


Shahid N Shah (, CEO and Chief Architect, Netspective Communications, LLC

Shahid Shah photoShahid N. Shah is an internationally recognized and influential healthcare IT thought leader who is known as "The Healthcare IT Guy" across the Internet. He is a consultant to various federal agencies on IT matters and winner of Federal Computer Week's coveted "Fed 100" award given to IT experts that have made a big impact in the government. Shahid has architected and built multiple clinical solutions over his almost 20-year career. He helped design and deploy the American Red Cross's electronic health record solution across thousands of sites; he's built two web-based EMRs now in use by hundreds of physicians; he's designed large groupware and collaboration sites in use by thousands; and, as an ex-CTO for a billion-dollar division of CardinalHealth, he helped design advanced clinical interfaces for medical devices and hospitals. Shahid also serves as a senior technology strategy advisor to NIH's SBIR/STTR program helping small businesses commercialize their healthcare applications.

27 July 2010

Also available in Japanese

Introduction to NHIN

The NHIN is our National Health Information Network. It's the 2006 successor to the 2002 National Health Information Infrastructure (NHII) project. NHIN has gone through additional changes to help support the requirements of the healthcare-specific provisions known as HITECH (The Health Information Technology for Economic and Clinical Health Act) in the 2009 American Recovery and Reinvestment Act (ARRA). One thing to remember about NHIN, though, is that it's not a new or closed network but simply a framework that allows the Internet to be used for healthcare data exchange.

NHIN is far from settled and is not a forgone conclusion for data exchange, so you shouldn't rest your complete integration strategy on it. In fact, make sure you have other options available to you. You shouldn't read this as a negative comment on NHIN, but as a practical observation on how complex healthcare data exchange is: There's nothing easy about it, but you do need to solve problems today. Many important questions like how patient data can be legally accessed, where patient data lives (physically and logically), whether it will be free, whether only the big players can participate, and who's really going to be responsible for validity and privacy models still need to be addressed.

If this all sounds familiar it's because NHIN is the logical successor and is similar to the old regional health information organizations (RHIOs) model which was run by large health systems that would decide who could and couldn't participate. RHIOs were the first step in launching the national "network of networks" that would eventually tie everyone to everyone else. The little guys, like patients, smaller physician practices, and community hospitals would run under the auspices of the RHIOs and depend on their goodwill. Of course, RHIOs didn't succeed, and although NHIN is starting with the same premises, the implementation strategy will be different. Whether this strategy will be successful remains to be seen, since it might be years before it's ready for prime time.

Before we get into the details of NHIN and NHIN Direct, let's review the ARRA and HITECH Act so you can understand the whole context.


In February 2009 the U.S. Congress passed ARRA, also known as the "stimulus bill" or "Recovery Act". The stimulus bill provides for about $787 billion USD across numerous industries; the healthcare-specific provisions of the bill are known as HITECH and are worth about $19 billion USD.

With that $19 billion, HITECH offers as little as tens of thousands of dollars for private physician practices to as much as tens of millions of dollars for hospitals and multihospital systems that accept Medicare and Medicaid to install and use electronic medical records (EMR) systems. The money being provided by the bill is not a direct payment to practices and hospitals. Instead, the payments will be made as increases in Medicare and Medicaid reimbursements to those care providers that meet the rules and regulations defined within HITECH.

An overview of meaningful use

HITECH coined the term meaningful use (MU), and it was a game-changer in the healthcare IT industry. In a series of regulations, the Recovery Act specifically required the following:

  • Use of certified electronic healthcare records (EHRs) in a "meaningful" manner (not directly related to NHIN)
  • Use of certified EHRs for electronic exchange of health information (important for NHIN)
  • Use of certified EHRs to submit clinical quality and other measures to the government (also done through NHIN)

MU is a great concept, and the approach is designed to lead the industry from just installing information systems to actually using them to improve patient lives. MU wants to go from data capture and sharing (NHIN comes in when data is shared outside of the enterprise) to advanced electronic clinical processes (with more improvement through NHIN) and, finally, to improved outcomes (which can be reported to the government through NHIN).

The folks defining MU understand that we will not be able to get to improved health outcomes without a basic amount of information sharing and important improvements in electronic clinical workflows. How much MU will ultimately affect outcomes is not known, but it's a good start.

MU is defined in three stages through rule-making: Stage 1 in 2011, Stage 2 in 2013, and Stage 3 in 2015. In Stage 1 the National Quality Forum (NQF) wants to focus on the following health outcome priorities:

  • Improve quality, safety, and efficiency as well as reduce health disparities.
  • Engage patients and families in their healthcare.
  • Improve care coordination. Improve population and public health.
  • Ensure adequate privacy and security protections for health information.

MU objectives and NHIN

The final MU rule was published by HHS on July 13, 2010. It defines 24 objectives and measures that a hospital must meet to become a meaningful user and qualify for incentive funding. There is a "core set" that must be met by all institutions and a "menu set" from which organizations must implement at least five objectives. I have listed below the MU measures that enterprises need to be aware of, and I've added [NHIN] to those that are either directly or marginally related to NHIN.

Core set objectives

This is the core set of objectives that all institutions must meet.

  1. Use Computer Provider Order Entry (CPOE).
  2. Implement drug-drug, drug-allergy, and drug-formulary checks.
  3. Record demographics.
  4. Implement one clinical decision support rule.
  5. Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM or SNOMED CT.
  6. Maintain active medication list.
  7. Maintain active medication allergy list.
  8. Record and chart changes in vital signs.
  9. Record smoking status for patients 13 years or older.
  10. Report hospital clinical quality measures to CMS or States. [NHIN]
  11. Provide patients with an electronic copy of their health information, upon request. [Maybe NHIN]
  12. Provide patients with an electronic copy of their discharge instructions at time of discharge, upon request. [Maybe NHIN]
  13. Capability to exchange key clinical information among providers of care and patient-authorized entities electronically [NHIN]
  14. Protect electronic health information.

Menu set objectives

This is the menu set of ten objectives from which organizations must implement at least five. At least one public health objective must be chosen (number 8, 9, or 10).

  1. Drug-formulary checks
  2. Record advanced directives for patients 65 years or older.
  3. Incorporate clinical lab test results as structured data.
  4. Generate lists of patients by specific conditions. [NHIN can help]
  5. Use certified EHR technology to identify patient-specific education resources and provide to patient, if appropriate. [NHIN can help]
  6. Medication reconciliation [Maybe NHIN]
  7. Summary of care record for each transition of care/referrals [NHIN can help]
  8. Capability to submit electronic data to immunization registries/systems [NHIN]
  9. Capability to provide electronic submission of reportable lab results to public health agencies [NHIN]
  10. Capability to provide electronic syndromic surveillance data to public health agencies [NHIN]

Government agencies and participants involved in NHIN

As you can see in Figure 1, the Office of the National Coordinator for Healthcare IT (ONCHIT) is a component of the Department of Health and Human Services (HHS). ONCHIT, usually abbreviated just ONC, is the principal policy group of the Federal Government that defines and manages NHIN.

Figure 1. Department of Health and Human Services and related organizations
A diagram showing the HHS and its components, including NIST, CMS, and ONCHIT, and underneath the ONCHIT, HIEs, HIT Policy Committee, and HIT Standards Committee
  • ONC is responsible for coordinating with the Department of Commerce's National Institute of Standards and Technology (NIST) on the specifications for the NHIN standards.
  • The HIT Policy and HIT Standards Committees are the working groups that advise ONC on what to put in the standards.
  • NIST is responsible for coming up with the test materials (assertions, procedures, methods, tools, data, and so on) that will be used to certify working systems.

NHIN basics

Based on the government's own definition (see Resources), the NHIN is:

  • A set of policies, standards, and services that enable the Internet to be used for secure and meaningful exchange of health information
  • A set of harmonized standards-based specifications for communicating between participants on the NHIN (referred to as NHIN health information exchanges or NHIEs)
  • A trust fabric that allows for secure exchange of health information that respects individual choice. This includes:
    • An Internet-based private network that ensures secure transport
    • Membership services to ensure that only valid, trusted entities may participate
    • Certification to ensure interoperability between entities
    • Legal agreements to protect privacy and security of information exchanges
    • A curated set of indexes that enables network participants to access resources on the network
  • A governance model that structures and defines activities, roles, and responsibilities of all participants and enforces accountability
  • The confederation of entities, called NHIEs, bound by the NHIN mission and governance structure

If you're still confused, you're not alone. NHIN is quite big, and in my opinion it is attempting to accomplish too much. Instead of doing the minimal necessary from the bottom up, the government is working from the top down and specifying what it thinks should be there years down the road. The initial participants of NHIN are all massive entities (like Social Security, CDC, FDA, and Medicare), which do have complex problems to solve, so thinking big for them makes sense. The vision is grand and achievable over the long term, but how long this will take is difficult to calculate because NHIN is not concrete.

Ultimately, NHIN is about exchanging patient and care data. For NHIN to be successful, it will need to have defined vocabularies, documents, and messaging standards for how to exchange patient data among government agencies, hospitals, insurance companies, and dozens of other types of participants. It will have to answer the question of how and where patient information will be delivered—meaning, will it go to some large central database in the sky, or will it be routed to local exchanges that then route them to national exchanges? The legal and data ownership rules need to be defined. Some part of NHIN will need to be able to sign and authenticate data to validate that the data is coming from a reliable source and is being sent to a reliable destination, along with some service guarantees to make sure the patient data arrives unaltered.

In technical terms, the foundational NHIN components include authentication and certificates, delivery protocols, trust framework, vocabularies, message specifications, directories, and security. As you have probably deduced, all of these same foundational components are present within the Internet in some way. If the parties exchanging data on both ends know each other, then the routing and trust is fairly straightforward. What is needed immediately for quick deployment is a lightweight "on ramp" and an easy way to get started for small, medium, and large enterprises to start exchanging data now instead of waiting for the government to specify everything.

IBM has many products that can help with health data integration today, most of which will work with NHIN as it evolves. The DB2® 9 database and its native XML functionality is a good choice for storage because it's the only data storage engine that can store all the various NHIN XML specifications directly without translation (all other databases need to do transforms to save XML). The new Cognos® business intelligence suite can be put to immediate use for HL7 ETL, patient matching, master patient index searching and lookups, and patient population analysis. Instead of using a small tool provider's basic analytics engine, Cognos gives you fast deployments with the Express product and then allows you to move up to a full engine later as your needs grow.


The first initiative that was released as an NHIN open source project is NHIN CONNECT. Unlike NHIN writ large, which is a set of standards, specifications, and a reference architecture, CONNECT is software you can download and use to create a health information exchange (HIE) within your own organization. You can attach an existing HIE into a regional network of health information exchanges, or tie an HIE into the national network of exchanges. Note that CONNECT is really focused on HIEs and not on point-to-point solutions with direct connectivity between systems (see NHIN Direct, below, for that).

Since NHIN CONNECT is about tying it into the HIE, what if you're just interested in connecting your EMR to an HIE? While it seems like it should, unfortunately, CONNECT does not help you there, and you might be interested in Open Health Tools (OHT), iheprofiles (led by IBM), and the OpenExchange. See the Resources section at the end of this article for links.

You use the CONNECT Core Services Gateway to write code that can locate patient records, retrieve patient documents, and update patient records in either your own HIE or a connected one with which you have a trust relationship. Basic requirements such as authentication, authorization, and privacy rules are handled by the Core Services.

You use the CONNECT Enterprise Service Components to deploy default implementations of a Master Patient Index (MPI), XDS.b Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log, and other related tasks. These are only default implementations of interfaces defined in the Core Services Gateway and may be used as is or replaced with custom implementations as necessary.

As you use the Core Services and Enterprise Service Components, you'll want to look to the IBM WebSphere® Application Server and WebSphere Message Broker MQ and other process server tools that may be more robust implementations than the default components provided in the open source suite. They can cut development time and give you better integrated development environments. See Resources for more information.

I'm sure by now you're thinking, "Enough words already! Show me the code!" However, given the complexity of NHIN and the fact that it's more specification than code, I do not have a "Hello World" program to show you. NHIN CONNECT does have a good deal of code, but again, given the complexity of a health information exchange, it's hard to demonstrate a short "Hello World" program for CONNECT that shows anything meaningful.

NHIN Direct

Once you realize that a top-down government undertaking that connects all players to all other players will take time, but that many immediate problems can be solved with existing Internet and enterprise protocols already available today, you arrive at what is called NHIN Direct (see Resources). The NHIN program is all about health information exchange, from the simple to the complex, but the NHIN Direct Project wants to ensure that simple health data exchanges, arguably the most common, are easily achieved. Instead of focusing on large players like the government, NHIN Direct extends support to a broader set of participants and providers (like your local hospitals and physician offices) who already know and can push data to each other. That's the key—if you are communicating with participants that you already know and are willing to use models with data push like email (meaning, "when my data changes I'll let you know and you can record it") or data pull like Web browsers, then NHIN Direct is a faster on ramp to NHIN. And, instead of trying to define everything at once, NHIN Direct is focused on standards-based, widely deployed, and well-supported Internet-friendly methods to support core Meaningful Use use cases like:

  • Primary care provider refers patient to specialist including summary of care record
  • Primary care provider refers patient to hospital including summary care record
  • Specialist sends summary care information back to referring provider
  • Hospital sends discharge or continuity of care information to referring provider
  • Laboratory sends lab results to ordering provider

ONC is reiterating that NHIN and NHIN Direct are not different—NHIN Direct is simply a small part of NHIN. It's a project within NHIN to allow people to start using the NHIN gateway specifications for immediately useful and easier implementations. What I really like about NHIN Direct is that it's more "down to Earth" and focused on real-world, immediate needs. It uses an open, transparent, and collaborative process, using wikis, blogs, and open source and open content. It's the kind of project that practitioners, and not policy wonks, would start.

One thing to remember about NHIN and NHIN Direct is that they are not creating a new network.

Getting started with NHIN Direct

NHIN Direct is a relatively new government-led (but not necessarily government-run) project, which means it has more documentation on its website about what it is versus what it does and what code is available (very little at this time). To get started with some real target deliverables, take a look at the following pages (also see Resources):

The most important non-policy and non-governance design principles (the technical ones) include the following:

  • The NHIN Direct project will create a transport-level set of specifications and services that can handle multiple types of content, from unstructured (text, PDF, and so on) to semi-structured (various CDA templates, HL7 MDM, and so on) to fully structured (CCR, CCD).
  • Questions of content (for example, CCD versus CCR) will be handled through profiles on top of the resulting specifications and service descriptions.
  • The design will incorporate connectivity to eligible providers and will accommodate a variety of technology types (including installed EHR, modular EHR, enterprise EHR, SaaS EHR, and so on).
  • The design will incorporate at least one connectivity model wherein an installed EHR makes only outbound transactions through a firewall (that is, where the provider need not open a TCP/IP port to the open Internet).
  • The design will accommodate the typical IT environment for a small practice (such as installed EHR, dynamic IP address, no or limited IT support).
  • The design will accommodate an EHR connectivity model that can be natively implemented by a small development team working in a language with modern library support.

On the same page as the design principles you will find the "Rules" section, which is worth reading.

The Abstract Model

Once you've looked at the design principles and user stories, you should look at the Abstract Model and the associated examples. NHIN Direct contemplates various ways servers can talk to each other: source (end point) to service provider, service provider to service provider, source to destination, and service provider to destination (end point). In this regard the NHIN Direct abstract model is more familiar to us than the CONNECT model, which is almost like a hub and spoke pattern. The following table provides an overview of the different types of models that are being contemplated for NHIN Direct.


As soon as you're familiar with the different models, you'll want to see how addressing works (see Table 1). Here are some non-normative examples of how Health Internet Addresses may be formatted (directly from the website):

Table 1. NHIN Direct Addressing examples
Email AddressHealth Endpoint Name + "@" + Health Domain
REST URISee REST Implementation (see Resources) nhin/v1/ example refers to the home message inbox for Dr. Smith. The same relative URL can and will be served out of the sender's domain. 1_0 refers to the REST API version.
WSDL referenceSee IHE Implementation (see Resources) nhin/1_0/wsdls/messagesReturns the WSDL pointing to the SOAP web services. 1_0 refers to the SOAP API version.
XCNHL7 drsmith^Smith^John^J^III^DR^PHD^^&NHIN OID&OIDThe XCN representation could be used in multiple contexts, including the intendedRecipient in an XDS/XDR web service call or in an HL7 2.x message to refer to the sender or receiver of a message (for example, in a PV1 segment)
XONHL7 DocumentationSunny Family^^^^^&NHIN OID&OID^^^^urn:nhin:nhin. XON representation could be used in multiple contexts, including the intendedRecipient in an XDS/XDR web service call or in an HL7 2.x message to refer to the sender or receiver of a message (for example, in an ORC segment)

NHIN Direct code examples

Unlike NHIN CONNECT, which has code but is too complex to present in a short article like this, NHIN Direct is too new to have much useful code at this time. We can't really demonstrate working examples because the project only recently started, and a number of people are working very hard to get code created and available for use.

As you're beginning your journey to learning about NHIN Direct, be sure to look at the IBM Enterprise Service Bus (ESB) offering (see Resources). All of the different concrete implementations (REST, SMTP, and so on) are fully supported by the ESB, and it can shortcut many months of developing, deploying, and maintaining services envisioned by NHIN Direct. In addition to the ESB, you likely want to integrate the IBM WebSphere Process Server for human-centric BPM around the NHIN specifications. The ESB tied with the Process Server is a powerful combination that can enable NHIN Direct as it matures.


You should now have a clear understanding of what NHIN is and why it is important to the transformation of the healthcare industry. The specifics on the current state of both NHIN CONNECT and NHIN Direct, and more importantly where they are headed, have been carefully described for you. If you want to join in and get involved in this crucial space, see Resources for more information.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Web development on developerWorks

Zone=Web development, Industries
ArticleTitle=An overview of NHIN and NHIN Direct for software developers