NHIN Direct Overview
Abstract: NHIN Direct supports point-to-point messaging by healthcare stakeholders. Common tasks
such as a referring provider sending health information at a transition of care are supported by NHIN
Direct. NHIN Direct uses secure internet-based standards such as secure email and others. Stakeholders
communicate with each other using their health internet address which is similar to an internet email
address. This document provides a general overview of NHIN Direct.
Table of Contents
1.
What is NHIN Direct? ............................................................................................................................. 4
1.1
Introduction ..................................................................................................................................... 4
1.2
Assumptions .................................................................................................................................... 5
1.3
Limitations in Scope of NHIN Direct ................................................................................................ 6
2.
How was NHIN Direct Started?.............................................................................................................. 6
3.
Who will use NHIN Direct? .................................................................................................................... 7
3.1
Who Needs to Communicate Health Information Directly? ........................................................... 7
3.2
How does NHIN Direct Support the User Stories? .......................................................................... 9
4.
NHIN Direct in the Context of the Nationwide Health Information Network ..................................... 13
5.
Implementers (Enablers) of NHIN Direct ............................................................................................. 14
6.
NHIN Direct Project Organization and Participation ........................................................................... 15
7.
Standards and Glossary ....................................................................................................................... 15
7.1.
Standards ...................................................................................................................................... 15
7.2.
Glossary ........................................................................................................................................ 16
Page 2 of 19
Change History
Change Summary
Author
Organization
Date
Initial Draft
Nagesh Bashyam
Harris Corporation
7/21/2010
Edits
David Tao & others
Siemens
7/22/2010
Edits
Will Ross
Redwood MedNet
7/23/2010
Edits
Rich Elmore
Allscripts
7/24/2010
Edits & formatting
Will Ross
Redwood MedNet
7/25/2010
Minor edits
David Tao
Siemens
7/26/2010
Baseline Version A for Document Work Group Review
Nagesh Bashyam
Harris Corporation
7/27/2010
Substantial new material and edits added to Baseline
A, following Doc WG meeting. Reordered sections to
move higher level material up front and “project” or
“technical” info toward the back.
Formatting
David Tao
Siemens
7/29/2010
Rich Elmore
Allscripts
7/30/2010
Formatting and minor edits, create baseline ver B for
review
Nagesh Bashyam
Harris Corporation
8/4/2010
Edits, comments
Janet Campbell
Epic
8/4/2010
Further edits
Noam Arzt
Further edits, added more in section on ND in the
context of NHIN. Reversed the order of sections 4 and
5. Addressed some of Janet’s and Noam’s comments
Formatting and content editing. Converted “Technical
Discussion” and “Acronym Index” into a single
Glossary populated with terms & concepts found in
the Overview narrative.
Accepted prior changes. Added brief abstract
(above). Addressed comments (and removed them).
David Tao
Siemens
8/5/2010
Will Ross
Redwood MedNet
8/5/2010
Rich Elmore
Allscripts
8/7/2010
Clarified assumptions, examples, and glossary, and
removed some redundant statements
David Tao
Siemens
8/10/2010
8/5/2010
Page 3 of 19
1. What is NHIN Direct?
1.1
Introduction
Today, communication of health information among providers and patients is most frequently achieved by
sending paper through the mail or via fax. These methods can be slow, unreliable, and duplicative. NHIN 1
Direct seeks to benefit patients and providers by improving the communication of health information,
making it faster, more secure, less expensive, and more environmentally-sensitive (greener). For
example, NHIN Direct will enable a primary care physician who is referring a patient to a specialist to
send the clinical information electronically to the specialist, and to receive back a summary of the
consultation. It will enable a hospital to send a discharge summary electronically to a patient who
requests it. NHIN Direct will enable these and similar “direct” communication patterns with minimal cost to
set up and use the tools in a fully secure manner.
The NHIN Direct project seeks to create simple data tools implemented within a strong policy framework
to enable secure delivery of point-to-point electronic messages between health care participants. The
project was initiated and sponsored by the United States Department of Health and Human Services
Office of the National Coordinator for Healthcare Information Technology (ONC). NHIN Direct is a
component in the Nationwide Health Information Network (NHIN).
The Crux of NHIN Direct: NHIN Direct specifies a simple, secure, scalable, standards-based way
for participants (care providers, EHRs, etc.) to send encrypted health information directly to
known, trusted recipients (including patients) over the Internet. NHIN Direct participants will be
able to communicate securely via e-mail and via more comprehensive NHIN-related tools.
NHIN Direct enables standards-based point-to-point messaging in support of Stage 1 Meaningful Use.2
Examples include communication of summary care records such as the HL7 Continuity of Care Document
(CCD) or ASTM Continuity of Care Record (CCR), discharge summaries, simple text notes, scanned
documents, and other content3 in support of coordination of care and patient engagement. NHIN Direct
focuses on the technical standards and services necessary to securely transport content from point A to
point B. This is the meaning of the term “Direct” in the project name. NHIN Direct, by itself, does not
satisfy any Meaningful Use objectives. When NHIN Direct is used by providers to transport and share
qualifying EHR content, the combination of clinical content plus NHIN Direct transport may satisfy
“meaningful use” requirements.
1
NHIN = “Nationwide Health Information Network” of which NHIN Direct is one component.
2
Meaningful Use as defined in the Final Rule from CMS published in July, 2010, in support of the Health Information
Technology (HITECH) sections of the American Recovery and Reinvestment Act (ARRA) economic stimulus
legislation passed in 2009
“Content” (sometimes called “payload”) means the health information being communicated, which is independent of
the technical mechanism used to move it. For example, when a person composes a simple e-mail message, the
“content” is information that is typed or attached. The authoring of e-mail content is independent of how the e-mail
moves across networks. Similar to the transport of common e-mail, NHIN Direct is a set of standards and service
specifications that describe the secure transport of health messages, but it does not limit the message content. NHIN
Direct defines the process for sending any content similar to e-mail.
3
Page 4 of 19
Additional information on NHIN Direct, such as workgroups, models, standards, services, reference
implementation and documentation, can be found at http://www.nhindirect.org.
1.2
Assumptions
NHIN Direct is bound by a set of simplifying assumptions. It allows secure communication of health data
among a known set of health care participants who already know and trust each other. NHIN Direct relies
on the patient consent that was obtained by the participants prior to the transfer of information. NHIN
Direct assumes that the Sender is responsible for several minimum requirements before sending data.
These requirements may or may not be handled “electronically” in an EHR, but they are handled
nonetheless when sharing information today via paper or fax, for example a sender may call to ask
whether a FAX was sent to the correct phone number and was received by the intended provider,
especially when sending for the first time.4
The following assumptions provide context for the NHIN Direct standards and services:
4

NHIN Direct will conform to applicable federal and state laws, including but not limited to those
related to security and privacy of protected health information. 5

Policy guidance for NHIN Direct will be provided by the NHIN Workgroup of the HIT Policy
Committee6 and will not be decided within the NHIN Direct project itself.

The Sender of an NHIN Direct transmission has determined that it is clinically and legally
appropriate to send the information to the Receiver.

As required by law or policy, the Sender has obtained the patient’s consent to send the
information to the Receiver. Therefore, the Sender and Receiver know that the patient’s privacy
preferences are being honored.

The Sender has determined that the Receiver address is correct.

The Sender has communicated to the receiver (perhaps out-of-band) the purpose for which the
information is being exchanged (e.g., to assist in the consultation).

The Sender and Receiver do not require that common or pre-negotiated patient identifiers
are determined, exchanged or included in messages or their content. Similar to the sharing of
fax/paper documents, this means there is no expectation that a received message will be
automatically matched to a patient or automatically filed in an EHR.

The communication will be performed in a secure, encrypted, and reliable way. The technology
to do this is covered in the detailed NHIN Direct technical specifications.
This is sometimes referred to as “out of band” verification
5
Since Federal laws do not currently mandate any particular transport standards, NHIN Direct cannot be
inherently noncompliant in regards to transport.
6
http://healthit.hhs.gov/portal/server.pt?open=512&objID=1269&parentname=CommunityPage&parentid=5&mode=2
Page 5 of 19

1.3
NHIN Direct will coexist gracefully with health information exchange services based on the
existing NHIN Gateway and related standards and services.
Limitations in Scope of NHIN Direct
In contrast to other standards and services, such as NHIN Exchange, NHIN Direct is not targeted at
complex scenarios, such as an unconscious patient brought by ambulance to an Emergency Department.
In the unconscious patient scenario, a provider in the ED must “search and discover” whether this patient
has records available from any accessible clinical source. This type of broad query is not a simple and
direct communication pattern and therefore it requires a robust set of health information exchange tools
and services. Unlike the complex communication pattern of a blind query and response, NHIN Direct is
limited to simple, point-to-point communication patterns. Because of the simplifying assumptions, NHIN
Direct does not require a master patient index to match patients, unique identifiers, or other infrastructure
associated with comprehensive health information exchanges. However, if such capabilities exist, they
can be used along with NHIN Direct to improve the business processes and workflows. NHIN Direct is
intended to interoperate with NHIN Exchange. NHIN Direct makes available a simple set of
communication tools that are useful in a broad range of NHIN settings.
For more details on how NHIN Direct fits with other NHIN initiatives, see Section 4: NHIN Direct in the
Context of the Nationwide Health Information Network.
2. How was NHIN Direct Started?
The NHIN Work Group, part of the federal Health IT Policy Committee (HITPC), has been developing
recommendations to extend secure health information exchange using NHIN standards to the broadest
possible audience. Potential NHIN adopters include organizations and individuals with varying levels of
health information exchange requirements as shown in Figure 1.
Page 6 of 19
Figure 1: Spectrum of health information exchange to be supported by the NHIN
Standards and services used by NHIN Exchange were developed under recent federal contracts were
designed for a robust type of health information exchange. Analysis of these standards by Wes Rishel
and David McCallie in 2009 highlighted the need for “simple interoperability” among healthcare providers
to enable simpler point-to-point communication. In response to the robust discussion that ensued, the
NHIN Work Group recommended the creation of additional NHIN specifications to include simple, direct,
secure standards for point-to-point messages. The Implementation and Adoption Workgroup of the Health
IT Standards Committee (HITSC) endorsed the idea of “simple interoperability” by noting that “one size
does not necessarily fit all.” Complex cases require a robust set of standards to handle the complexity,
but simple use cases should be handled with appropriately simple solutions. NHIN Exchange has similar
simple push patterns that support less complex information exchange, but the Workgroup was concerned
that these standards were still too complex and difficult to adopt rapidly by all health care providers. For
this reason, NHIN Direct was launched to complement and extend NHIN Exchange with additional simple
electronic communication options.
Meaningful Use includes financial incentives for eligible providers (including but not limited to physicians,
dentists, chiropractors) and hospitals to adopt Electronic Health Records (EHRs). NHIN Direct recognizes
that the majority of providers and hospitals have not yet implemented EHRs, and that it is important to
“meet them where they are” to help providers exchange information, even as they gradually “ramp up” to
adopt EHRs. NHIN Direct aims to reduce the barriers to information exchange for all stakeholders,
including providers who have complete or modular EHRs, providers who do not have EHRs, vendors,
service providers, and patients. NHIN Direct focuses primarily, but not exclusively, on the left side of the
“Spectrum of Exchange” (Figure 1) while also recognizing that exchanges are not limited to “simple to
simple.” For instance, a small physician practice may currently have little or no EHR technology and may
need to communicate with an integrated delivery network that has robust EHR technology. NHIN Direct
aims to facilitate communication across the entire spectrum, in either direction, between less complex and
more robust health care settings.
3. Who will use NHIN Direct?
3.1
Who Needs to Communicate Health Information Directly?
The NHIN Direct standards and services can be adopted by any organization or person (such as a
physician or a patient) seeking to implement simple direct point-to-point electronic communications. For
some providers, these communications are part of satisfying Stage 1 Meaningful Use objectives. NHIN
Direct can also help improve business processes for a practice, or empower patients and families by
supporting efficient exchange of health information. The NHIN Direct project enables the achievement of
these goals by use of standards and services that can be implemented with widely available technology.
The senders and receivers of NHIN Direct messages can be humans or technology systems. Technology
can range from certified comprehensive EHRs or individual EHR modules (as defined by the CMS final
rule on meaningful use), to Personal Health Records, or to other technology that is not part of an EHR –
such as a simple e-mail client or web browser – that can communicate health information securely. Direct
human intervention may be involved on both ends of the communication, such as a physician composing
an e-mail to another physician and attaching a clinical document. In other cases human intervention may
be involved on only one end of the communication, such as an EHR automatically generating an e-mail
message to a patient. Some scenarios might involve no human intervention at all, such as one EHR
automatically communicate with an HIE or another EHR, automatically routing and/or storing the
Page 7 of 19
message. It is important to note, however, that the “entirely automated” scenario requires more than the
minimum required data to be sent for effective processing within the business workflow.
A sample set of user stories that can be enabled using the NHIN Direct standards and services are listed
below. The NHIN Direct project created this set of user stories to facilitate the development of the NHIN
Direct standards and services. These stories are prioritized as follows
1. Priority 1: Supportive of Stage 1 meaningful use. Targeted for implementation in the first version
of NHIN Direct.
2. Priority 2: Priority for early implementation but with potentially complex dependencies on
additional policy considerations
3. Priority 3: Other high priority use cases.
User story #1, a referral from one provider to another, addresses the need for simple, direct, secure
communication. In this user story, the referring provider has determined that it is clinically and legally
appropriate to send a referral and summary of care to a specialist. The referring provider searches for a
patient in the practice EHR and initiates a referral message. The referral reason is described in the body
of the message. In some cases the referral is directed to a specific specialist, and in other cases, to a
specialist practice. The referring provider attaches clinical documents as needed for reference and then
sends the referral. The specialist sees the new referral in her local practice EHR. If this is a new patient
for the practice, a new patient is created in the EHR. The core referral and the various documents are
imported into the new patient's chart if supported by the EHR.
The list of all the user stories along with their priorities is listed below:
Story
Priority
1
Primary care provider refers patient to specialist including summary care record
1
2
Primary care provider refers patient to hospital including summary care record
1
3
Specialist sends summary care information back to referring provider
1
4
Hospital sends discharge information to referring provider
1
5
Laboratory sends lab results to ordering provider
1
6
Transaction sender receives delivery receipt
1
7
Provider sends patient health information to the patient
1
8
Hospital sends patient health information to the patient
1
9
Provider sends a clinical summary of an office visit to the patient
1
10
Hospital sends a clinical summary at discharge to the patient
1
11
Provider sends reminder for preventive or follow-up care to the patient
1
Page 8 of 19
Story
Priority
12
Primary care provider sends patient immunization data to public health
1
13
Provider or hospital reports quality measures to CMS
2
14
Provider or hospital reports quality measures to State
2
15
Laboratory reports test results for some specific conditions to public health
2
16
Hospital or provider send chief complaint data to public health
2
17
Provider or hospital sends update to regional or national quality registry
2
18
2
19
Pharmacist sends medication therapy management consult to primary care
provider
A patient-designated caregiver monitors and coordinates care among 3 domains
20
A Provider EHR orders a test
2
21
A patient sends a message to the provider
2
22
Transaction sender receives read receipt
3
23
State public health agency reports public health data to Centers for Disease
Control
3
2
The analysis of user stories leads to common patterns that would be required to satisfy them. Some of
these patterns include:

A need to uniquely identify the Sender of the health information

A need to uniquely identify the Receiver of the health information

A need to deliver health information from the Sender

A way to separate the routing of the health information from the clinical content, which includes
formal as well as informal types of content (for example, simple text narrative, or formal
structured documents such as a CCD or CCR or a lab test result).

Security that establishes and verifies trust between the participants and protects the content
being transferred from inappropriate disclosure or tampering.
3.2
How does NHIN Direct Support the User Stories?
The NHIN Direct Abstract Model in Figure 2 was created from analysis of the user stories to identify NHIN
Direct participants and messages7 that are exchanged between participants. The Abstract Model forms
Note that “message” in this document is used generically to refer to any communication in NHIN Direct, independent
of the content, similar to e-mail messages which can contain a wide variety of information both within the “body” as
well as attachments. We do not use “message” to refer to any specific format or standard such as HL7 version 2.x or
3.x messages.
7
Page 9 of 19
the basis of the NHIN Direct technical specifications, and provides a common framework for stakeholders
to investigate NHIN Direct standards and services. The concepts and acronyms on this diagram are then
defined and explained through the examples below.
Figure 2: NHIN Direct Abstract Model
The model is deliberately “abstract” to avoid declaring that there is only one way to implement each arrow
or to embody each concept. In reality there are many ways. The following examples make the abstract
model easier to understand. Refer to the Glossary for light definitions of the concepts involved in the
abstract model.
EXAMPLE 1: Primary care provider sends some supplemental background information to specialist
(subset of User Story #1)
Starting on the left of the diagram,
1. SEND
Primary care physician Dr. B. Wells is the Sender who initiates a secure email message. In this
example she has referred one of her patients to a gastroenterology specialist, Dr. G. Aye, and
would like Dr. Aye to clarify something in the health record. She types her message using her
secure email client and sends it to Dr. Aye using a Health Internet address that Dr. Aye provided
her. Dr. Aye’s address is her secure email client’s local address book. Her email client
authenticates (1.1) to establish its identity8 to a NHIN Direct Health Internet Service Provider
(HISP), then it encrypts and sends the text message and the service provider acknowledges
8
Analogous to a user logging on to a system, but in this case it is one system authenticating to another
Page 10 of 19
successful receipt of the message (1.3). HISPs serve a similar purpose as a typical Internet
Service Providers that handles e-mail messages today – the Sender has a HISP and the
Receiver has a HISP that may be the same or is most likely different.
2. ROUTE
Dr. Wells’ HISP must communicate with the receiver’s HISP through similar steps of
authentication, message transmission, and receipt acknowledgement (2.1, 2.2, 2.3) after finding
the address of the destination HISP. Once the message has arrived at the receiver’s HISP it
needs to be delivered to the intended recipient.
3. DELIVER
AND
RECEIVE
9
Dr. Aye plans to install an EHR in the future, but he already uses e-mail software that is capable
of handling secure (encrypted) messages. Dr. Aye uses his e-mail software, which authenticates
to the HISP (3.1) and then displays an inbox of messages (3.2). Dr. Aye has chosen to have
multiple e-mail accounts to separate his NHIN Direct messages from his normal e-mail, so his
inbox contains only clinical messages sent via NHIN Direct. 10 He sees the message from Dr.
Wells, with a subject line “Re the patient I told you about” but no patient-specific information is
visible. Dr. Wells uses the procedure that his e-mail software requires to open encrypted e-mails
(3.3, 3.4), in order to open the attached clinical summary. He sees Dr. Wells’ description of the
patient’s problems, medications, allergies, and recent diagnostic tests, and he is now well briefed
for the patient’s visit later today.
EXAMPLE 2: Primary care provider refers patient to specialist including summary care record
(User Story #1)
Starting on the left of the diagram,
1. SEND
Primary care physician Dr. B. Wells is the Sender who initiates a message using technology,
such as an EHR. In this example she has referred one of her patients to a gastroenterology
specialist, Dr. G. Aye, and would like Dr. Aye to have some background information about the
patient. She uses her system to generate a clinical summary and sends it to Dr. Aye using a
Health Internet address that Dr. Aye gave her. Dr. Aye’s address is now in her EHR system’s
local address book. Her EHR system authenticates (1.1) to establish its identity11 to a NHIN
Direct Health Internet Service Provider (HISP), then it encrypts and sends the message
including the clinical summary (1.2 NHIN Direct Message Push) and the service provider
acknowledges successful receipt of the message (1.3). HISPs serve a similar purpose as a
9
such as Outlook, Thunderbird, etc.
This is just one example, and does not imply that “separate e-mail account using the same e-mail client software”
is the preferred or only way to set up a user’s e-mail client. Risks vs. benefits of each alternative solution should be
assessed. The NHIN Direct project will provide documentation of some alternatives and tradeoffs, as well as open
source reference implementations that can assist in the solution (such as the NHIN Direct Security Agent).
10
11
Analogous to a user logging on to a system, but in this case it is one system authenticating to another
Page 11 of 19
typical Internet Service Providers that handles e-mail messages today – the Sender has a
HISP and the Receiver has a HISP that may be the same or is most likely different.
2. ROUTE
Dr. Wells’ HISP must communicate with the receiver’s HISP through similar steps of
authentication, message transmission, and receipt acknowledgement (2.1, 2.2, 2.3) after
finding the address of the destination HISP. Once the message has arrived at the receiver’s
HISP it needs to be delivered to the intended recipient.
3. DELIVER
AND
RECEIVE
Dr. Aye plans to install an EHR in the future, but he already uses e-mail software12 that is
capable of handling secure (encrypted) messages. Dr. Aye uses his e-mail software, which
authenticates to the HISP (3.1) and then displays an inbox of messages (3.2). Dr. Aye has
chosen to have multiple e-mail accounts to separate his NHIN Direct messages from his
normal e-mail, so his inbox contains only clinical messages sent via NHIN Direct. He sees the
message from Dr. Wells, with a subject line “Re the patient I told you about” but no patientspecific information is visible. Dr. Wells uses the procedure that his e-mail software requires
to open encrypted e-mails (3.3, 3.4),in order to open the attached clinical summary. He sees
Dr. Wells’ description of the patient’s problems, medications, allergies, and recent diagnostic
tests, and he is now well briefed for the patient’s visit later today.
EXAMPLE 3: Hospital Sends Health Information to the Patient (User Story #8)
Some details that are the same as Example 1 are not repeated here.
1. SEND
Patient M. Powered has recently completed a hospitalization stay at Premiere Memorial Hospital,
and he’d like to get a copy of his clinical information and discharge summary. He requests that
Premiere send his information to his personal health record, and he provides his health Internet
address: m.powered@SuperPHR.com.. A Health Information Management professional at
Premiere, Meg Wreckerds, uses the hospital EHR’s Patient Document Management function to
select documents to send to a patient. She selects both a Continuity of Care Document and a
dictated Discharge Summary document, enters the patient’s health Internet address address, and
clicks Send.
2. ROUTE
The Hospital’s EHR in this case is hosted by the EHR vendor’s data center, which has HISP
capabilities built in. The HISP looks up the SuperPHR address and sends the message with two
attached documents to the PHR’s HISP, which has established a mutual trust relationship with
the sending HISP.
3. DELIVER AND RECEIVE
In this example, there is no human intervention on the receiving end. Rather, the PHR, which is
also hosted in a data center, is “listening” for e-mails and directing them to the appropriate
patient’s record. Upon receiving the documents, the PHR software detaches them from the
message, decrypts them, and stores them in its “incoming documents” folder. Later, when M.
12
such as Outlook, Thunderbird, etc.
Page 12 of 19
Powered logs into SuperPHR, he reviews the documents and has the option to select data from
the Continuity of Care Document and add it to the appropriate section of his PHR.
4. NHIN Direct in the Context of the Nationwide Health Information
Network
NHIN Direct is an integral component in a broader national strategy to have an interconnected health
system through a Nationwide Health Information Network (NHIN).13 The NHIN is “a set of standards,
services and policies that enable secure health information exchange over the Internet. The NHIN will
provide a foundation for the exchange of health IT across diverse entities, within communities and across
the country, helping to achieve the goals of the HITECH Act.” Four Components of the NHIN initiative are
shown in Figure 3.
Figure 3: NHIN and its initiatives

NHIN Gateway is a set of specifications, in support of “universal patient discovery” and health
information access within and across health information organizations (HIOs). In other words, it
enables users to query the NHIN to and find patient records, within a health information exchange
organization, or even across organizations. NHIN Gateway specifications include selected IHE
Information Technology Infrastructure integration profiles and transactions, such as CrossGateway Patient Discovery, Registry Stored Query, and Retrieve Documents. So in a fully
implemented NHIN, an authorized user could query the a regional HIO in (for example)
Wisconsin, as well as a state-level Wisconsin HIO, and even other state-level HIOs where the
patient may have lived or visited, to locate the patient’s records in accordance with policies (local,
state, national) and the patient’s consent directives. The concept of universal patient discovery
goes beyond the “simple, direct, among known participants” scope of NHIN Direct. The NHIN
Gateway exchanges are not only “direct” and are not limited to “known participants.” For example,
the emergency department that treats a patient who was vacationing did not have a prior
relationship with the patient’s previous providers, and none of the previous providers directed a
message to the ED.

NHIN CONNECT is software that embodies the standards and services to support NHIN Gateway
specifications. The software is open-source and is available as a reference implementation to
13
See
http://healthit.hhs.gov/portal/server.pt?open=512&objID=1142&parentname=CommunityPage&parentid=4&mode=2
for more on the NHIN
Page 13 of 19
help organizations who wish to use or build upon it, but organizations can also choose to develop
their own software to implement NHIN Gateway specifications.


NHIN Exchange is a “Limited Production Exchange” among a group of organizations that have
come together under a standard policy framework (expressed in the DURSA 14) to exchange data
using the NHIN Gateway specifications. Some NHIN Exchange implementations have used NHIN
CONNECT, and others have developed their own software. Note also that many organizations
may use some or all NHIN Gateway standards without formally being part of the NHIN Exchange.
In order to participate and adopt NHIN Exchange services, an organization needs to complete an
“on-boarding” process that consists of:

Application for participation with a sponsoring Federal Agency

Execution of a DURSA

Completion of required testing and validation of the NHIN Exchange services.

Acceptance by the NHIN Cooperative, which operates the NHIN Exchange
NHIN Direct complements NHIN Gateway, NHIN CONNECT, and NHIN Exchange. It is a
project, with a beginning and an end, to draft the specifications and services that address simple,
direct communication through known participants. The NHIN Direct standards and services can
be implemented by any two participants, organizations or a community using the standards and
services defined without a central governance structure
The NHIN is expected to ultimately include the standards and services developed by both NHIN Direct
and NHIN Gateway. Any HIO can choose to support both NHIN Direct and NHIN Gateway, and many
HIOs participating in the NHIN Direct project plan do just that, to connect as many participants as
possible.
The NHIN provides a foundation, but it does not encompass everything that an HIO might do. It does not
limit the ability of HIOs who implement NHIN Direct and/or NHIN Gateway specifications to innovate or
offer additional value-added services. For example, some HIOs may offer common provider index
(directories) for participants to look up NHIN Direct addresses; may offer translation between different
protocols, formats, and vocabularies; may aggregate data for quality or public health reporting; or offer
other complementary services that are beyond NHIN Direct’s scope.
5. NHIN Direct Implementation
Organizations which create initial implementations of the NHIN Direct standards and services via the
project’s conformance testing process are the enablers of NHIN Direct. Examples of such organizations
include EHR/PHR vendors, Health Internet Service Providers (HISPs), Health Information Exchange
organizations, and Integrated Delivery Networks.
In addition to these organizations, the NHIN Direct Implementation Geography Work Group is organizing
real-world pilots to demonstrate health information exchange using NHIN Direct standards and services.
14
DURSA = Data Use and Reciprocal Support Agreement, a trust agreement that must be executed
Page 14 of 19
To help the NHIN Direct implementers, an open source reference implementation of the NHIN Direct
standards and services is being implemented under the guidance of the NHIN Direct project.
6. NHIN Direct Project Organization and Participation
NHIN Direct is an open government initiative 15 started by the ONC. The project’s initial coordinator is
Arien Malec with the guidance of the HHS Office of the National Coordinator for Health Information
Technology. The policy direction for NHIN Direct is provided by the NHIN Work Group of the HIT Policy
Committee, and oversight related to technology standards is provided by the HIT Standards Committee.
2010
2011
Figure 4: Integration of NHIN Direct in the HITSC and HITPC project calendars
The NHIN Direct project provides multiple avenues for organizations to contribute to the development of
standards and services. To facilitate effective coordination and expedited development of standards and
services, the NHIN Direct project is organized into multiple work groups, each of which has a dedicated
set of goals and timeline.
The work group collaboration is facilitated by use of a wiki16 (http://www.nhindirect.org), by weekly and
monthly meetings, and by blogs and discussion lists. Currently the NHIN Direct project has more than 200
participants from over 60 different organizations. These participants include EHR/PHR vendors, medical
organizations, systems integrators, integrated delivery networks, federal organizations, state and regional
health information organizations, organizations who provide health information exchange capabilities, and
health information technology consultants. Many NHIN Direct participants are also active in standards
organizations such as HL7, IHE, ASTM, etc. The participants provide varying levels of support to the
NHIN Direct project.
7. Standards and Glossary
7.1.
Standards
The section contains a list of all the standards that are applicable to the various NHIN Direct concepts,
standards and services.
NHIN Direct Concept
Standards Applicable
Requirements definition
RFC 2119
Health Domain Name Format
RFC 1034
See http://www.whitehouse.gov/open for more information about the Obama administratation’s intent to promote
transparency, participation, and collaboration in government.
15
16
A wiki is a website with user maintained content, such as Wikipedia. The NHIN Direct wiki contains the latest
information and much more detail about the project than can be included in an Overview.
Page 15 of 19
Health Endpoint Name Format
RFC 5322
Health Content Container
RFC 2045, RFC 2046, RFC 2387 (MIME)
Securing the Content in NHIN Direct Messages
RFC 1847, (S/MIME)
Secure Point-to-point communication transport
SMTP
SOAP transport governed by IHE XDR and XDD
profiles
7.2.
Glossary
Abstract Model -- forms the basis of the NHIN Direct technical specifications, and provides a
common framework for stakeholders to investigate NHIN Direct standards and services
ARRA -- American Recovery and Reinvestment Act of 2009, a.k.a the “economic stimulus package”
that includes a HITECH section providing incentives to adopt Health Information Technology.
ASTM -- international standards organization that develops and publishes voluntary consensus
technical standards, including the Continuity of Care Record (CCR)
Authenticate -- verify an identity prior to granting access or asserting trust
Backbone Protocol -- the transport mechanism used to transfer information between two HISPs
CCD -- Continuity of Care Document
CCR -- Continuity of Care Record
Certificate Authority -- Issues digital certificates in a public key infrastructure environment
Certificate Revocation -- Lists certificates in a public key infrastructure environment that are no
longer valid
CMS -- Centers for Medicaid and Medicare Services
Content -- the health information being communicated, which is independent of the technical
mechanism used to move it
Deliver -Destination -- Source and destination correlate to the sender and the receiver of information in
an NHIN Direct health information exchange.
Destination Protocol -- the transport mechanism used to transfer information between the HISP
and the Destination belonging to that HISP
DURSA -- Data Use and Reciprocal Support Agreement – a comprehensive agreement that
governs the exchange of health data through the NHIN
Page 16 of 19
ED -- Emergency Department
Edge Protocol -- see Destination Edge Protocol or Source Edge Protocol
EHR -- Electronic Health Record
Gateway -Health Content Container -Health Domain Name -- the delivery location for messages to an individual NHIN HISP; the
HISP portion of an NHIN Direct Address
Health End Point -- the delivery location for messages to an individual NHIN Direct user; the
user portion of an NHIN Direct Address
HIE -- Health Information Exchange
HIO -- Health Information Organization
HISP -- Health Internet Service Provider. The NHIN Direct HISP represents the entity that is
responsible for delivering health information as messages between senders and receivers over the
Internet. On the Internat, an ISP (Internet Service Provider) provides users with access to the
Internet. Similarly, on the NHIN a HISP provides qualified users with access to NHIN Direct
services.
HIT -- Healthcare IT
HITECH -- Health Information Technology for Economic and Clinical Health Act (HITECH) – a part
of ARRA
HITPC -- Healthcare IT Policy Committee
HITSC -- Healthcare IT Standards Committee
HL7 -- Health Level 7, international standards organization that develops and publishes voluntary
consensus technical standards, including the Clinical Document Architecture (CDA)
IDN -- Integrated Delivery Network
IHE -- Integrating the Healthcare Enterprise
Implementation Geography -Initiate -- See “Send”
J-agent -- NHIN D Security Agent for Java
Meaningful Use -- as defined in the Final Rule from CMS published in July, 2010
Message Push -- see “Push”
MIME -- Multipurpose Internet Mail Extensions
Page 17 of 19
MU -- Meaningful Use, as defined in the CMS regulations for meaningful use under the ARRA
HITECH provisions.
Multipart MIME Message -NHIN -- a set of standards, services and policies that enable secure health information exchange
over the Internet
NHIN CONNECT -- software that embodies the standards and services to support NHIN
Gateway specifications.
NHIN D Security Agent -- a security service applicable only to the SMTP backbone
NHIN Direct Address -- An NHIN Direct Address is composed of two parts, a Health End
Point Name and a Health Domain Name. Example: drbob@samplehispname.org.
NHIN Direct Backbone -- NHIN Direct transport specifications for the backbone protocol have
two parts: specifications based on the Simple Mail Transport Protocol (SMTP); and
specifications based on Integrating the Healthcare Enterprise's (IHE) Cross Enterprise Document
Reliable Interchange (XDR) integration profile
NHIN Direct Edge Protocol -- see Edge Protocol
NHIN Direct HISP Address Directory -- an authoritative source to identify the address and
domain name of a HISP. This is similar to the concept of a business directory which contains the
contact information for the type of business listed in the directory
NHIN Direct Message -- The NHIN Direct Message refers to the content of the information
being transferred from the source to the destination. The NHIN Direct Message is similar to a
package that is sent from one person to another via the postal service, such as the content within
an envelope or a box
NHIN Direct Protocols -- see Edge Protocol, Backbone Protocol
NHIN Exchange -- Nationwide Health Information Network operates as NHIN Exchange - a
diverse set of federal agencies and non-federal organizations that have come together to securely
exchange electronic health information.
NHIN Gateway -- an open source implementation of the core NHIN services enabling such
functions as locating patients at other health organizations within the NHIN.
NHIN Workgroup -- part of the federal Health IT Policy Committee
ONC -- Office of the National Coordinator for Health Information Technology in the Department of
Health and Human Services
Patient Discovery -- Search for patient data in the absence of a universal identifier
Payload -- see Content
Page 18 of 19
PHR -- Personal Health Record
PKI -- Public Key Infrastructure
Push -- to send a message directly to a receiver, such that the receiver receives the message
without having to “go look for it.” However, it should be noted that even “push” messages are
not guaranteed to be viewed (e.g., receiver may not log into e-mail or might have turned off the
device on which messages are displayed)
Receiver -- Actor in the NHIN Direct workflow who receives the message content
Reference Implementation -Route -- to transport a NHIN direct message from sender to the receiver(s) identified by the
NHIN Direct address(es).
Sender -- Actor in the NHIN Direct workflow who originates (or SENDS) the message content
Sender Verification -SMTP -- Simple Mail Transport Protocol, and industry standard for transporting e-mail
Source -- Source and destination correlate to the sender and the receiver of information in an
NHIN Direct health information exchange.
Source Edge Protocol -- the transport mechanism used to transfer information between the
Source and the Source’s HISP
X.509 -- standard for public key infrastructure for single sign-on and privilege management
XDM -- Cross-Enterprise Document Media Interchange (XDM)
XDR -- the IHE Cross Enterprise Document Reliable Interchange (XDR) integration profile
Page 19 of 19