What is NHIN Direct? (alpha)

Recently a member of the FOSS Health community wrote to me:

So I’m confused by NHIN Direct. Why not simply use S/MIME or PGP email? Why five different ways of addressing people, when really only the email-address format makes sense to the average internet user?

I have been pretty confused by the NHIN Direct for quite some time. But I have finally invested enough time that I can discuss the aim of the project somewhat succinctly. Note that this is essentially my re-phrasing of the NHIN Direct FAQ item “What is NHIN Direct“. To implement code, we need to have very exact definitions of what we will or will not do, and often that careful phrasing, while making it easier to code, makes things harder to understand. So the site above, in its current definition reads like this:

NHIN Direct is the set of standards, policies and services that enable simple, secure transport of health information between authorized care providers. NHIN Direct enables standards-based health information exchange in support of core Stage 1 Meaningful Use measures, including communication of summary care records, referrals, discharge summaries and other clinical documents in support of continuity of care and medication reconciliation, and communication of laboratory results to providers.

Lets re-write that in English.

NHIN Direct is like “email for doctors”. NHIN Direct is way for doctors, patients and other healthcare providers to send each other messages, which will feel like email messages, but are different in two important ways. First, the messages can have smart “attachments” that are essentially patient records in standardized formats (CCR/CCD/etc) and second, unlike email, the messages will be sent over a secure network in a HIPPA compliant way. Generally NHIN Direct should replace the current use of fax and email for the transfer of medical records in the US, and provide a stepping stone to greater interoperability with the NHIN Exchange (which is much smarter than just email)

The problem is, at this stage, that you cannot really go much deeper than this high-level thinking, because the NHIN Direct project has not yet settled on which protocol it will be using to enable the messaging. The current candidates are SMTP with S/MIME for handling encryption, XMPP also with S/MIME, REST and the IHE direct messaging profile. I am going to follow this post with a more detailed discussion of that particular decision and its implications, but until that decision is made, it is not really possible to further discuss the NHIN Direct model. In that later model I will discuss more clearly the first part of my friends question.

The second part of the question: “Why the different ways of addressing people?” can be answered now. The NHIN Direct group had a “how do we address” discussion, before we settled on an implementation protocol. That meant that the addressing specification had to implementable using several different protocol stacks. However, the decision was made that all of the addressing mechanisms must be “transferable” into something that looks just like email. Lets imagine that I was going to host my own NHIN Direct node. My address might look like fredtrotter@nhin.fredtrotter.com. When my doctor wanted to send me a message, then that is what he would type into his messaging system. If NHIN Direct decided to go with SMTP, then my address, as it is routed across the NHIN Direct network would look just the way my doctor typed it. But if NHIN Direct uses REST, then it might get transformed into a URI, like this: https://nhin.fredtrotter.com/nhin/v1/nhin.fredtrotter.com/fredtrotter/ . That might look scary, but everyone using NHIN Direct can think in terms of email addresses, because the REST implementation would convert fredtrotter@nhin.fredtrotter.com automatically, we would never even know it was happening.

Eventually, I will extend this article into a better natural language description of the NHIN Direct project, which means later versions will not discuss “if we choose X protocol” but instead focus on the protocol that is actually chosen.

-FT