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.
ARRA and HITECH
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.
- Use Computer Provider Order Entry (CPOE).
- Implement drug-drug, drug-allergy, and drug-formulary checks.
- Record demographics.
- Implement one clinical decision support rule.
- Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM or SNOMED CT.
- Maintain active medication list.
- Maintain active medication allergy list.
- Record and chart changes in vital signs.
- Record smoking status for patients 13 years or older.
- Report hospital clinical quality measures to CMS or States. [NHIN]
- Provide patients with an electronic copy of their health information, upon request. [Maybe NHIN]
- Provide patients with an electronic copy of their discharge instructions at time of discharge, upon request. [Maybe NHIN]
- Capability to exchange key clinical information among providers of care and patient-authorized entities electronically [NHIN]
- 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).
- Drug-formulary checks
- Record advanced directives for patients 65 years or older.
- Incorporate clinical lab test results as structured data.
- Generate lists of patients by specific conditions. [NHIN can help]
- Use certified EHR technology to identify patient-specific education resources and provide to patient, if appropriate. [NHIN can help]
- Medication reconciliation [Maybe NHIN]
- Summary of care record for each transition of care/referrals [NHIN can help]
- Capability to submit electronic data to immunization registries/systems [NHIN]
- Capability to provide electronic submission of reportable lab results to public health agencies [NHIN]
- 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
- 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.
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.
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 NHIN Direct Design Principles
- The NHIN Direct User Stories
- The NHIN Direct Abstract Model and the examples
- The NHIN Direct Addressing Specification
- The NHIN Direct Concrete Implementation Workgroup
- The NHIN Direct RESTful API
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 Address||Health Endpoint Name + "@" + Health Domain Nameemail@example.com|
|REST URI||See REST Implementation (see Resources)||https://nhin.sunnyfamilypractice.example.org/ nhin/v1/nhin.sunnyfamilypractice.example.org/drsmith/||This 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 reference||See IHE Implementation (see Resources)||https://nhin.sunnyfamilypractice.example.org/ nhin/1_0/wsdls/messages||Returns the WSDL pointing to the SOAP web services. 1_0 refers to the SOAP API version.|
|XCN||HL7 documentation||urn:nhin:nhin.sunnyfamilypractice.example.org: drsmith^Smith^John^J^III^DR^PHD^^&NHIN OID&OID||The 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)|
|XON||HL7 Documentation||Sunny Family^^^^^&NHIN OID&OID^^^^urn:nhin:nhin. sunnyfamilypractice.example.org:sunnyfamily||The 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.
- Health IT home page: Health information technology allows comprehensive management of medical information and its secure exchange between healthcare consumers and providers.
- NHIN overview page: The Nationwide Health Information Network (NHIN) is a set of standards, services, and policies that enable secure health information exchange over the Internet.
- NHIN Direct home page: NHIN Direct is a project to expand the standards and service definitions that, with a policy framework, constitute the NHIN.
- The NHIN Direct Design Principles: See guidelines for designing and implementing NHIN Direct solutions.
- The NHIN Direct User Stories: Dig in to over 20 use cases of NHIN Direct for health information exchange.
- The NHIN Direct Abstract Model and the examples: Read here to understand the actors and transactions behind the NHIN Direct use cases.
- The NHIN Direct Addressing Specification: Read the 1.0 specification.
- The NHIN Direct Concrete Implementation Workgroup: Start here for a high-level set of concrete implementations for NHIN Direct.
- The NHIN Direct RESTful API: The collaboration area for the RESTful implementation of NHIN Direct.
- REST Implementation Development Team: Join the volunteer team to advance the REST Implementation proposal of NHIN Direct to a concrete implementation.
- SMTP Implementation Development Team: If you have SMTP expertise, join the team to advance the SMTP Implementation proposal to a concrete implementation for NHIN Direct.
- IHE Implementation Development Team: Volunteer to advance the Integrating the Healthcare Enterprise (IHE) NHIN Direct Specification.
- XMPP Implementation Development Team: Start here to volunteer the advancement of the XMPP implementation for NHIN Direct.
- Open Health Tools' website: Open Health Tools is an open source community with a vision of enabling a ubiquitous ecosystem where members of the Health and IT professions can collaborate to build interoperable systems that enable patients and their care providers to have access to vital and reliable medical information at the time and place it is needed.
- iheprofiles Project home page: Integrating the Healthcare Enterprise (IHE) is an initiative by healthcare professionals and the healthcare industry to improve the way computer systems in healthcare share information.
- OpenExchange Project home page: The OpenExchange platform provides standards-based core infrastructure to exchange patient health information in a secure and timely manner, to advance the quality, safety, and efficiency of healthcare delivery.
- Visit the IBM developerWorks Industry zone for all the latest industry-specific technical resources for developers.
- To listen to interesting interviews and discussions for software developers, check out developerWorks podcasts.
- developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
Get products and technologies
- IBM WebSphere Application Server: Build, deploy, and manage robust, agile, and reusable SOA business applications and services of all types while reducing application infrastructure costs with IBM WebSphere Application Server.
- IBM WebSphere Message Broker and IBM WebSphere Enterprise Service Bus help enable fast and flexible application integration with reduced cost.
- Innovate your next open source development project with IBM trial software, available for download or on DVD.
- Create your My developerWorks profile today and set up a watchlist on data integration. Get connected and stay connected with My developerWorks.
- Find other developerWorks members interested in Web development.
- Web developers, share your experience and knowledge in the Web development group.
- Share what you know: Join one of our developerWorks groups focused on Web topics.
- Roland Barcia talks about Web 2.0 and middleware in his blog.
- Follow developerWorks' members' shared bookmarks on Web topics.
- Get answers quickly: Visit the Web 2.0 Apps forum.