Healthcare Messages Over the Internet: The Direct Project

This article originally appeared in The Health Care Blog and O'Reilly Radar on Monday November 29th. Related stories include John Halamka's post on the Direct Project and the HIT Standards Committee hearing on transport standards.

by Brian Ahier, Rich Elmore and David C. Kibbe

The Direct Project announced today the completion of its open-source connectivity-enabling  software and the start of a series of pilots that will be demonstrating directed secure messaging for healthcare stakeholders over the internet.  The Direct Project specifies a simple, secure, scalable, standards-based way for participants to send authenticated, encrypted health information directly to known, trusted recipients over the Internet.

Also announced:  

• A new name - the Direct Project was previously known as NHIN Direct
• An NHIN University course, The Direct Project - Where We Are Today, to be presented by Arien Malec, November 29 at 1 PM ET, sponsored by the National eHealth Collaborative
• An extensive list of HIT vendors (20+) that have announced plans to leverage the Direct Project for message transport in connection with their solutions and services
• Presentations at the HIT Standards Committee on Tuesday November 30 where three or more vendors will be announcing their support for the Direct Project.
• A thorough documentation library including a Direct Project Overview
• Best practice guidance for directed messaging based on the policy work of the Privacy and Security Tiger team
• A new web site at DirectProject.org
• A new hashtag #directproject for following the Direct Project on twitter.

The Direct Project is the collaborative and voluntary work of a group of healthcare stakeholders representing more than 50 provider, state, HIE and HIT vendor organizations.  Over 200 participants have contributed to the project.  It’s rapid progress, transparency, and community consensus approach have established it as a model of how to drive innovation at a national level.

What is The Direct Project?

Today, communication of health information among providers and patients is most often achieved by sending paper through the mail or via fax. The Direct Project seeks to benefit patients and providers by improving the transport of health information, making it faster, more secure, and less expensive. The Direct Project will facilitate “direct” communication patterns with an eye toward approaching more advanced levels of interoperability than simple paper can provide.

The Direct Project provides for universal boundaryless addressing to other Direct Project participants using a health internet “email-like” address.  

The Direct Project focuses on the technical standards and services necessary to securely transport content from point A to point B and does not specify the actual content exchanged. When The Direct Project is used by providers to transport and share qualifying clinical content, the combination of content and The Direct Project-specified transport standards may satisfy some Stage 1 Meaningful Use requirements. For example, a primary care physician who is referring a patient to a specialist can use The Direct Project to send a clinical summary of that patient to the specialist and to receive a summary of the consultation.

How might the Direct Project be Used?

2009-10 Congress and agencies of the federal government have created regulations that require physicians and hospitals participating in the ARRA/HITECH incentives awarded for meaningful use of EHR technology to:

• send messages and data to each other for referral and care coordination purposes;
• send alerts and reminders for preventive care to their patients;
• send patients clinical summaries of their visit and of their health information
• receive lab results from labs
• send immunization and syndromic surveillance data to public health agencies
• integrate with HIT vendor systems

Each capability can be enabled with point-to-point secure e-mail or in a more integrated manner as HIT vendors and public health agencies enable communication with the Direct Project.

How will the Direct Project affect states and Health Information Exchanges?

States that are receiving federal funding to enable message exchange are being asked by the ONC to facilitate Stage 1 Meaningful Use information exchange.  The Direct Project may serve as a key enabler of directed messaging for all states and Health Information Exchanges.  Even states that have some level of health information exchange capability need to address areas that are currently uncovered by a regional or local Health Information Organization (HIO).

As state plans seek to address a means to fill the gaps in exchange capability coverage, the Direct Project may provide a bridge to enabling the basic exchange requirements for Stage 1 Meaningful Use. The Direct Project does not obviate the need for state planning for HIE, neither does it undercut the business case for HIOs. More robust services can be layered over simple directed messaging that will provide value to exchange participants.

There are already organizations that have announced the establishment of national clinical exchange networks, including integration with the Direct Project. States and HIO’s will need to decide how best to provide Direct Project services to their constituents, whether by partnering with existing exchange networks or incorporating direct messaging into the services they provide.

The Direct Project Implementation

The Direct Project is organizing real-world pilots to demonstrate health information exchange using The Direct Project standards and services.  Six pilots are ramping up including:  

Rhode Island Quality Institute, Redwood MedNet and MedAllies will be sending Continuity of Care Documents to other providers for referrals and transitions of care.  Visionshare will be linking to immunization registries. Carespark (Tennesee) will be linking the VA with private clinics providing health services to veterans.  And Connecticut’s Medical Professional Services, an IPA,  will be linking Middlesex Hospital with primary care providers.

The Reference Implementation

To help the Direct Project implementers, an open source reference implementation of the Direct Project standards and services has been developed under the guidance of the Direct Project. To ensure the broadest possible participation, the reference implementation has been implemented in two flavors:  Java and .Net.  

The HISP

Connectivity among providers is facilitated by Health Information Service Providers (HISP).  HISP describes both a function (the management of security and transport for directed exchange) and an organizational model (an organization that performs HISP functions on behalf of the sending or receiving organization or individual).

Best Practices

The Direct Project is bound by a set of policies that have been recommended to the HIT Policy Committee (HITPC) or are being examined by the HITPC’s Privacy and Security Tiger Team for directed messaging. Within this context, the Direct Project has developed best practice guidance for secure communication of health data among health care participants who already know and trust each other. The Direct Project assumes that the Sender is responsible for several minimum requirements before sending data, including the collection of patient consent. These requirements may or may not be handled in an electronic health record, but they are handled nonetheless, even when sharing information today via paper or fax. For example, a sender may call to ask whether a fax was sent to the correct fax number and was received by the intended provider.

The following best practices provide context for the Direct Project standards and services:

• The Sender has obtained the patient’s consent to send the information to the Receiver.
• The Sender and Receiver ensure that the patient’s privacy preferences are being honored.
• The Sender of a Direct Project transmission has determined that it is clinically and legally appropriate to send the information to the Receiver.
• The Sender has determined that the Receiver’s address is correct.
• The Sender has communicated to the receiver, perhaps out-of-band, the purpose for exchanging the information.
• The Sender and Receiver do not require common or pre-negotiated patient identifiers. Similar to the exchange of fax or paper documents, 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, as described in the detailed The Direct Project technical specifications.
• When the HISP is a separate entity from the sending or receiving organization, best practice guidance for the HISP has been developed for privacy, security and transparency.

What it isn’t

The Direct Project is not targeted at complex scenarios, such as an unconscious patient who is 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 and therefore requires a more robust set of health information exchange tools and services that The Direct Project does not provide.

The Direct Project in Context of the Nationwide Health Information Network

The Direct Project is an integral component in a broader national strategy to have an interconnected health system through a Nationwide Health Information Network (NHIN). 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.”

The authors:

Brian Ahier is chairman of the State of Oregon’s Health Information Technology Oversight Council Technology Workgroup.  Rich Elmore is Vice President, Strategic Initiatives at Allscripts.  David C. Kibbe is a family physician, senior advisor to American Academy of Family Physicians and co-founder of the Clinical Groupware Collaborative.

NHIN Direct - What it might look like

NHIN Direct is an ONC led initiative to enable boundaryless secure point-to-point provider messaging to other healthcare stakeholders. NHIN Direct would provide a standards-based replacement to paper, fax and email-in-the-clear and a transport layer for system-to-system point-to-point messaging.

The NHIN Direct Implementation Group is drawing close to its decision on the implementation approach.  A convergence proposal has been submitted by NHIN Direct workgroup leaders David McCallie  and this writer.  The proposal centers on an SMTP backbone, with edge protocols that enable secure email, EHR workflow integration (using IHE standards) and system-to-system integration (using REST).
_______________________________________________________________________________


NHIN Direct Convergence Proposal
This post is from Rich Elmore (Allscripts) and David McCallie (Cerner), with thanks and gratitude to many contributors and reviewers. A special thanks to the Concrete Implementation teams and the HIT Standards Committee review team that paved the way for this proposal.

---

Following the NHIN Direct Implementation Group June face-to-face meetings, the following proposal emerged as having a reasonable potential for consensus. The core of the idea is to take the best aspects of each proposal and blend them together to create something that doesn’t have to compromise on any dimension.
The proposed approach is designed to address the following CTQ’s:

• The backbone shall be:
  • A pervasive widely-available, universally-addressable, secure and reliable network
  • Already proven and in widespread use for this specific purpose (1a)
  • “Instantly on” – meaning that the global network can be built out in months, without central planning, using proven infrastructure and deep existing knowledge for this specific application (1a). Wes Rishel has described this as a “socially scalable” deployment architecture.
• The edge protocols shall support:
  • Instantly-on integration with EHR’s using the existing IHE XDR standard
  • Immediately available infrastructure ready for system-to-system innovations using a RESTful reference implementation
  • Bootstrapping for non-EMR users by providing basic access using standard email clients (POP/IMAP)
• A payload neutral content model shall meet entry-level providers where they are, but can scale up to the levels of metadata that are currently required by integrated health care settings and will be required by all providers to drive efficient and high quality workflows.

---

In more detail, we are proposing that:

• The backbone protocol for NHIN Direct would be SMTP carrying S/MIME signed and encrypted messages. This approach will allow us to leverage existing software, infrastructure and business models to ensure that NHIN Direct service is immediately available to both large and small providers regardless of practice size and IT budget.
  • In order to minimize the need to have end-users managing PKI certificates, we have designed and coded a transparent way for an organization and/or its users to delegate certificate management to a trusted HISP. The HISP will then transparently use DNS to locate and apply the user’s certificate (or the organization’s certificate) to convert the unencrypted message into a standard S/MIME message and verify an S/MIME signature. If an organization prefers not to sign a BAA with their HISP and prefers to manage certificates themselves, security can be performed within the organization. If the sender is unwilling to outsource encryption to the HISP, then the sender will have to perform any necessary XDM packaging (and encryption) before uploading the message to the HISP. NHIN Direct supplied libraries could be invoked locally to perform the XDM wrapping.
  • The use of organization or user level certificates also allows our approach to manage “multiple circles of trust,” as required by the Privacy & Security principlesbecause each organization may independently chose which certificate authorities to accept, and which to reject.
  • HISP-HISP conversations will be additionally encrypted using standard TLS using server certificates only (no client certificates) issued by an accepted Internet CA. This willguarantee a secure channel to protect the routing metadata while messages are being sent between trusted entities.
  • Error and status messages will be returned as messages using the MDN content type.
• An integrated XDR interface/gateway will be developed that can translate messages to and from XDR for out-of-the-box integration with existing XDR implementations. The system will adopt XDM as the recognized mechanism to encode content metadata for transmission across the backbone (as an attachment with the application/xdm+zip content type) and will use XDR as the protocol to interface with existing XD* applications. See the figure below for a schematic. (Note: we use the term “metadata” here to refer to content-associated metadata, not the routing information used to send the message.)
  • We recommend that clients create metadata attachments whenever possible. As a general rule of thumb, the sender is recommended to create as “rich” a metadata package as possible. The receiver should use as much received metadata as possible, and will be expected to send a “bounce” message back to the sender if the message cannot be processed, or the metadata does not meet the receiver’s standards.
  • A key goal here is to provide a “bootstrapping” pathway that lets clients move from “no metadata” to full metadata without having to change messaging platforms. A provider should be able to start out with a simple an email client, and then move to an EHR module, and then to a full EHR without changing HISP or secure NHIN-Direct addresses.
  • Our approach follows the same content standards as are used by XDR with the design criteria to avoid changes to the EHRs. It would also follow and leverage the “step up” and “step down” gateway code created by the SOAP team. It would follow any new profiling standards from IHE that would guide the proper use of “minimal” content metadata for those clients who cannot generate full metadata.
  • The REST reference implementation will be specifically tuned to ease creation of the metadata package transparently.
• A reference implementation of a simple REST interface will be exposed to the edge to support a more familiar integration approach for developers comfortable in that environment. This interface will also enable rapid innovation through the addition of new methods as needed.
  • The REST interface can readily be used to integrate the HISP with existing EHR software (where there is an already-established workflow engine and/or “inbox”)
  • The REST interface can be used to create novel integration points, such as web-based portals, for secure message-handling. We propose to create a reference implementation of a simple web-based portal, as part of the pilot deliverables.
• A basic client interface will be provided by exposure of standard POP/IMAP email services.
  • To ensure edge on-the-wire privacy, all clients will be required to use TLS with a server certificate only to connect to the HISP. Authentication could be username/password and/or client certificates.
  • To minimize the risk of mistaking a non-secure email account with the secure email account, we recommend (but don't require) that clients use a separate email instance to connect to their HISP, where this is technically supported by the client, rather than managing two accounts from one email client. This would be similar to using one client for personal email and a different client for corporate email.
  • Our reference implementation will include instructions to pre-configure email clients to ensure secure communication with a HISP.

---

Together, a reference implementation built to support this proposal is able to expose all three of XDR, REST and SMTP/POP3/IMAP as peer interfaces to edge clients. It will provide immediate utility for providers with limited IT capability, maximize the acquisition and exchange of content metadata, and provide a surface for rapid innovation.

---

Appendix - Sending / Receiving

NHIN Direct: Getting to the Health Internet, Finally!

By guest author David C. Kibbe.

I've been spending a lot of time involved in several Work Groups of the NHIN Direct Project, being run by ONC/HHS. The Project is aimed at developing secure, affordable, health data exchange over the Internet so more physicians can participate in Meaningful Use. This project has major significance to physicians in primary care, to all doctors in small and medium size medical practices, and for many small hospitals, as it is a potential "game changer" with implications for both the EHR technology industry and quality improvement movement. Here's some background and explanation about why and how.

Background on health data exchange -- why paper and fax no longer suffice
As a means of getting information from point A to point B, the fax machine works pretty well. But there are three big problems with faxing health data and information. One, it's expensive, mostly due to the staff time spent running the machine, changing paper and ink cartridges, and handling paper jams, busy signals, and wrong numbers. Two, faxes contain unstructured text that at best is stored as a document electronically, but usually turns out as paper. Paper is expensive to store compared with digital documents, but the real problem here is that fax data are "non-computable." Data in a fax is almost always unstructured and therefore unavailable for storage as discrete data elements, e.g. name, address, HbA1c level, etc, in a database. In a database, discrete data can be acted upon by software, but in paper format the data just sits there. And third, faxes are not really secure, as anyone walking by an unattended fax during receive mode can attest.
Not a huge issue, perhaps, until we consider that in 2009-10 Congress and agencies of the federal government have created regulations that require physicians and hospitals participating in the ARRA/HITECH incentives awarded for "meaningful use" of EHR technology to:

• send data to each other for referral and care coordination purposes;
• send their patients alerts and reminders for preventive care;
• offer patients views of their clinical data, such as laboratory results;
• make clinical summaries available to patients after each visit, and: send quality measurement data to CMS.

Given this new situation, which will dramatically increase the flow of data out of medical practices and hospitals, the really pertinent question is this: "If we can't use fax machines to deliver these messages, what can we use?"

As it turns out, transporting health data electronically isn't so easy. Even for doctors/hospitals who use comprehensive EHRs in their practices. The major problem is meeting basic HIPAA security and the maintenance of patient privacy requirements. E-mail with attachments is a hands-down, no-brainer win over faxes in terms of moving data electronically from Doctor-or-Hospital A to Doctor-Hospital-or-Patient B, especially if those attachments are structured data, like the CCR standard xml files. But the way our email clients (Outlook,Entourage, Apple Mail) and online mail accounts with Google or Yahoo are configured, they're not secure enough for health data transport.

(Why not? Well, for one thing Internet Service Providers (ISPs) and normal email clients don't authenticate, that is, assure the identity of, the sender or receiver. So identity can be spoofed. "On the Internet, no one can tell you're a dog," as the quite famous cartoon has put it. For another thing, most email data attachments aren't encrypted during transport. Email protocols, of course, can perform enable email clients to perform these functions, and we'll return to this potential later in this piece.)

The first iteration of the National Health Information Network, or NHIN, was top down, proprietary, and complex -

Roughly six years ago, the Office of the National Coordinator for HIT, ONC, under David Brailer, came up with the idea of the "National Health Information Network" or NHIN to solve the privacy and secure transport problem. As a solution to moving health data from point-to-point, the NHIN was exactly what you might expect would be proposed by the large enterprises, hospital systems, and their legacy vendors who were called upon by ONC for suggestions. Accordingly, the NHIN was to be a network composed of connected Regional Health Information Networks, RHIOs, now called Health Information Exchanges, or HIEs. These large HIEs would create "bridge technology" so that they could communicate with each other. Two of the biggest health systems in the country, who for years had fought interoperability and data exchange, but by 2005 were committed to the NHIN, are the VA Health System and the Department of Defense. Accordingly, in 2005, ONC/HHS let out grants for 18.5 million dollars for the design of the NHIN, to the likes of Accenture and Northrup Grumman, the latter a big defense contractor.

Now, if you were a doctor in 2005 practicing in a four doctor group in suburban Toledo, Ohio -- or one of her patients -- word of this design for the NHIN and the multi-million dollar contracts never reached you. And if it had, you'd probably wonder about its relevance to you or your colleagues. In part, that was because the feds weren't thinking about you at all. To the NHIN planners of 2005-08, your practice was on the very dark "edge" of the network they were designing, while hospitals and integrated health systems, were at its "core." Connecting the "cores" with each other was at the heart of the NHIN design and the work which continues under its newer name, NHIN Connect.

NHIN and NHIN Connect is a vision for a multi-stage, evolutionary approach to health data connectivity, tightly controlled by large enterprises and HIEs. First come the HIEs, then the HIEs connect to one another, and finally connectivity trickles down to the "edge" providers and practices who have EHRs, as these are required or incentivized to join the nearest HIE. I want to emphasize that there is nothing inherently wrong with this construct. But it does centralize decision-making and power in the hands of an elite few.
Think of the way the Cable TV industry developed in this country, and you're getting close to the old NHIN and NHIN Connect. Most Cable TV operators were given exclusive, monopoly contracts to do business in a community or region, based upon the claimed large start-up costs for laying copper and fiber cable. Which meant that customers who wanted cable TV had to sign up with a monopoly, or go without. Similarly, for the original NHIN, the RHIOs and HIEs are being given monopoly rights to establish private health data exchange networks, one per region, and doctors, hospitals, labs, pharmacies, and others will have to sign up with them in order to be able to send and receive data for various purposes, including those requirements to become a Meaningful User of certified EHR technology under the ARRA/HITECH incentive program -- for making electronic referrals, sending alerts and reminders, and clinical summaries to patients.

Another useful analogy with which to compare the NHIN-as-connected-large-enterprises-and-HIEs is the situation that existed just before the Internet, when private networks like AOL and Prodigy were able to charge customers a monthly fee for basic services such as sending emails and viewing the Web through their own browser. The NHIN as originally planned is essentially a framework for the establishment of multiple, Prodigy-like private Internets, which would use the open source but still very complex NHIN Connect Gateway software to move health data between private networks, in many cases for a fee.

Now, you don't need to be the least bit technically savvy to raise some good, solid questions about this arrangement. For example:

Why would we go through the expense and hassle to build and then limit our NHIN experience to monopolistic, Prodigy-like, private health data networks around the country for simple data transport, when the Internet itself is available? Banks, airlines, and e-commerce of all kinds run on secure Internet systems, so why can't health care? HIEs and RHIOs may offer some of their clients much value beyond simple, secure, health data transport, which is fine. But not all of us will need Mac trucks to drive to work. Or:

Isn't this version of the NHIN going to be really, really slow to develop? Physicians and medical practices need to connect their health data by 2011 in order to qualify for Meaningful Use, but the original NHIN design sounds as though it might well take another decade to pull off. Or:

What about the doctors, practices, and patients who don't have an HIE in their vicinity? How will they get connected? HIEs are primarily urban and suburban, and formed around large hospitals or consortia of hospital systems. What are the docs going to do in rural and underserved areas? Or, what about this:
How can health IT innovation occur rapidly when health data and their transport are controlled by a relatively few private networks, and a few very large IT vendors?

NHIN Direct explained and illustrated

It is in large part as a way of answering these questions that the NHIN Direct Project has been initiated by ONC and HHS. The aims of the NHIN Direct Project are "to expand the standards and service definitions that, within a policy framework, constitute the NHIN. Those standards and services will allow organizations to deliver simple, direct, secure and scalable transport of health information over the Internet between known participants in support of Stage 1 meaningful use." Implicit in this objective is the inclusion of small and rural medical practices located at the "edge" for full participation in health data exchange within the scope of the expanded NHIN.

Stated even more simply, NHIN Direct is a specification for the use of a set of existing Internet standards and protocols to allow any individual, organization, or organizational health IT system with an NHIN Direct Address to send health data to any other individual, organization, or organizational health IT system with an NHIN Direct Address, and to do so without having to be part of an HIE or other private network. In practice it is likely that most HIEs and private networks will adopt the NHIN Direct protocols, and thus enable their member individuals and organizations to have NHIN Direct Addresses, and therefore be capable of participation in the direct routing of health data. An NHIN Direct Address is very much like an email address or a web address, the difference being that NHIN Direct Addresses are verifiable, "unspoofable," and stored in a directory for updating.

It is important to recognize that NHIN Direct is NOT a means of sending health data "out into the Internet" to unknown individuals, or to anyone with an email address. To avoid "spoofing," NHIN Direct will require that the sender of health data "knows" the identity of the receiver, and that the exchange between Dr. Kibbe and Dr. Smith using NHIN Direct methods will occur ONLY when there is a trusted method of assuring the identity of each.

How is this trust established? NHIN Direct envisions a new kind of Internet Service Provider, or ISP, to be called a Health Internet Service Provider, or HISP. To be connected to the Internet as a citizen or individual requires the use of an ISP, which may be Time Warner Cable, the local telephone company, or one's place of business or employer. In each case, one's ISP is the "first connection" that allows all of the other Internet and Web features to be available, e.g. email, web browsers, e-commerce, online video, etc.

The duties of a HISP are like those of an ISP, but include specific additional services that will permit providers to simply and securely exchange data using NHIN Direct channels. These include:
Assignment and listing of organizational and individual NHIN Direct Addresses. HISPs will not need to create completely new email or URI addresses for individuals or organizations. Dr. Kibbe can still maintain his email address as Kibbe@FamilyMedicineUSA.org. What the HISP must do is verify that Dr. Kibbe is in fact a physician licensed in the state of North Carolina, and that this address is accurate and correct. The HISP would be responsible for publishing this address to other qualified HISPs looking to pass along health data addressed to Dr. Kibbe, and to maintain and update this address periodically.

Authentication of senders and receivers at the time of transport. There are a number of ways that client applications such as email or a web browser can create a trust relationship with a server to which data is being sent on the Internet, and similarly, several ways in which HISP servers passing on the data to one another can verify and trust one another. Often, digital signatures or certificates are exchanged at the same time that data are encrypted, and these methods both establish trust and disable "sniffing" of the data in transit by nefarious or criminal parties. Within the NHIN Direct specifications, it will be up to each HISP to set a minimal authentication protocol for client applications using the HISP, and each HISP will need to decide whether or not to trust other HISPs, based on their choices of minimal identity management protocols, which each HISP will be required to publish.

Content packaging of sender's message to assure that receiver can consume and interpret it. For handoffs of health data to be efficient, simple packaging standards need to be employed that both senders and receivers, or their EHR technologies, can understand. The messages that can be sent over NHIN Direct will be limited to a very familiar Internet messaging standard known as multipart-MIME, in which various kinds of attached data formats will be permitted, including the CCR standard, CDA CCD, HL7 flat file, and PDF for unstructured data.

In the drawing below, the physician on the left is identified as the "Source to HISP." He or she is sending a message to the physician at the bottom on the right, identified as "HISP to Destination." The individuals or organizations who are senders and receivers may use a number of "edge protocols," e.g. email clients, to send their messages to the HISP with whom they are associated. The HISPs then use a "backbone protocol" to communicate with each other, until the Destination physician or organization is located, at which point the HISP associated with the receiving physician or organization uses another (may be one of several) "edge protocols" to deliver the message.

This model is essentially the same model, and employs many of the same protocols for message transport, as the Internet itself. Only in the case of NHIN Direct there are additional layers of both technology and policy to establish and enforce a framework of trust and security, to assure privacy and confidentiality.

Final comments on the importance of NHIN Direct
The advantages to small and medium size medical practices of a national system that looks like NHIN Direct are substantial. Medical practices will be able to participate in health data exchange without the requirement to join a formal HIE or RHIO, although they will have the option to do so whenever one is established in their areas and if they provide additional value beyond simple, secure transport. Meaningful Use criteria for data exchange to support care coordination, patient engagement, and submission of quality data will be easier to meet, and at lower cost. In fact, the costs to be part of the NHIN Direct will be initially very minimal, and scale upward only as services beyond simple transport are added and subscribed to.

Beyond these tactical and practical issues, there is an essential tension between the older version of the NHIN and the NHIN Direct. If you believe that health care is fundamentally the business of large provider organizations and their large IT corporate vendors, then you're probably comfortable with the NHIN Connect's system of RHIOs and HIEs controlling health data and its flows. Large enterprises like the VA Health System may find they need the added complexity. But if you believe that medicine and most of health care is still primarily a set of service professions, where relationships between providers and patients count, and that individuals should be given the right to control most, if not all, of their health data, the NHIN Direct will seem preferable, or at least worth a try. A similar "decision" was made for the Internet and World Wide Web at large back in the 1990s, when private networks like AOL and Prodigy fell to the wayside in favor of the more open, simpler to use, and more democratic protocols which have created "net neutrality."

Over the next weeks and months we'll see the extent to which these two visions of health data for a National Health Information Network are successful. With any luck, they'll peacefully co-exist side by side.

NHIN Direct Addressing Specification

Guest author and member of the NHIN Direct Implementation Group John Halamka provides an update on:

The NHIN Direct Addressing Specification

Every Tuesday, the NHIN Direct Implementation Group holds a teleconference to update the entire team on the progress of the technical workgroups. This week, we discussed the completed addressing specification.

As I've said many times in my blog, the most important standards implementation problem to solve right now is transport, not only the basics of transmitting data securely but also transaction orchestration and the constellation of supporting functions such as addressing the messages.

In previous blogs, I've described one way to solve the addressing problem - give every patient a voluntary opt in "Health URL" that they could use to receive all healthcare data from hospitals, offices, labs, and pharmacies.

For use cases such as sending data from provider to provider, hospital to provider or provider to public health we need some similar approach to ensure data is delivered to the right place.

The NHIN Direct Addressing specification proposes five ways to do this - secure email addressing (SMTP plus TLS), REST, SOAP, and the HL7 routing schemes XCN and XON.

First, two definitions. A "Healthcare Internet Address" is made up of a Health Domain name and a Health Endpoint Name

Health Domain Name

A Health Domain Name is a string conforming to the requirements of RFC 1034.

A Health Domain Name identifies the organizations that assign the Health Endpoint Names and assures that they correspond to the real-world person, organization, machine or other endpoint that they purport to be. For example, my organizations (BIDMC and Harvard Medical School) could control nhin.bidmc.org or nhin.hms.harvard.edu

A Health Domain Name MUST be a fully qualified domain name, and SHOULD be dedicated solely to the purposes of health information exchange.

Organizations that manage Health Domain Names MUST maintain NHIN Direct Health Information Service Provider (HISP) Address Directory entries for the Health Domain Name, as specified by the Abstract Model, and corresponding to rules established for concrete implementations of the Abstract Model. Organizations that manage Health Domain Names MUST ensure that transactions are available for Health Endpoint Names, either through proprietary means or following the Destination role transactions of the Abstract Model. Organizations may take on the HISP role or assign this function to another organization playing the HISP role (such as GoDaddy does for hosting regular email on behalf of other organizations).

Health Endpoint Name

A Health Endpoint Name is a string conforming to the local-part requirements of RFC 5322

Health Endpoint Names express real-world origination points and endpoints of health information exchange, as vouched for by the organization managing the Health Domain Name. For me, that could be a person such as Dr. John Halamka, an organization such as BIDMC Emergency Department or an aggregation point such as BIDPO Quality Data Center. Here are examples of each address type

Email

Jhalamka@nhin.bidmc.org for health information exchange (not regular email) directed to me at BIDMC

REST (example of a possible format)

https://nhin.bidmc.org/nhin/1_0/urn:nhin:nhin.bidmc.org:jhalamka/

1_0 refers to the REST API version.

SOAP (example of a possible format)

https://nhin.bidmc.org/nhin/1_0/wsdls/messages

the person or organizational endpoint would be specified in the message itself.

1_0 refers to the SOAP API version.

HL7 XCN (extended composite ID number and name for persons)

urn:nhin:nhin.bidmc.org:jhalamka^Halamka^John^D^DR^MD^^&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 (e.g., in a PV1 segment)

HL7 XON (extended composite name and identification number for organizations)

Beth Israel Deaconess Medical Center^^^^^&NHIN OID&OID^^^^urn:nhin:nhin.bidmc.org:emergency_department

Note that XCN and XON are included for compatibility with the IHE XDR spec, NHIN Document Submission, and HITSP T31.

Imagine if every EHR could send data to every other EHR using a simple addressing mechanism like Email, a consistent REST implementation or a well described SOAP WSDL. Interoperability would follow rapidly because novel packages of data will be sent to support real business needs without any barriers of how to get the data from endpoint to endpoint.

The NHIN Direct process is working well and builds upon the work of the past. It does not compete with, diminish, or in any way represent a replacement of the hard work done by so many people over the past years in HITSP, IHE, and the SDOs.

I'll continue to provide NHIN Direct updates as reference implementations with running code are deployed. Massachusetts, through NEHEN and the Massachusetts eHealth Collaborative has volunteered to test these techniques with other surrounding states. Let the testing begin this Summer!