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/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 SOAP 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!