A way forward for NHIN Direct

There are two communities of interest that NHIN addresses, those already engaged in the NHIN Exchange who want to be able to capitalize on their existing technology investment, and those providers who do not have access to technology that is capable of integrating with the current NHIN Exchange specifications and policies.  NHIN Direct is focused on meeting the needs of that latter group, but we need to remember that group will need to communicate with the group already invested in NHIN Exchange.

This is, I believe, the real impasse in the current NHIN Direct work.

What we need to remember is that there is one National Health Information Network, and that the purpose of NHIN Direct is to enable providers who cannot communicate via NHIN Exchange to participate in NHIN.

The current NHIN Exchange also includes several other components that may also be problematic for these providers, because the current set of policies (including the DURSA) may also be too complex.  I won't bother to address issues of policy other than to point out that there is an HIT Policy committee that will be advising on those.

Let us just take it as a given that NHIN needs to support both communities:

We have two "backbone" proposals (SOAP with IHE XDR or SMTP) that are more or less desirable between one community or the other.  Movement of one community or another towards the "backbone" that meets the needs of the other has implementation costs that neither community really wants to be responsible for.

Whether we call SMTP the backbone or SOAP+XDR the backbone really doesn't matter (at least to me).  We will want to bridge between these two communities of interest.

Let us name three protocols:
Protocol A uses IHE XDR with SOAP
Protocol B uses SMTP and includes an XDM content package in the content.
Protocol C just uses SMTP and any sort of attachment desired.

So, we have providers with the following sets of cababilities:

1. XDR and/or XDS.b capabities through NHIN Exchange.  These are users of protocol A.
2. SMTP + some level of services to produce an XDM package. These are users of protocol B.
3. SMTP.  These are users of protocol C.

We need to enable exchanges between all three sets of providers as much as possible.  In order to do that, each NHIN Exchange participant will need to have an NHIN Direct address that they can use to communicate with parties that are not in the NHIN Exchange.  That same address can also be used to when routing communications between NHIN Exchange participants.

If a party in group 1 wants to communicate to another party in group 1, here is the overall process:

1. The Source System communicates to the Source HISP via XDR.
2. The Source HISP forwards that communication to the Destination HISP
3. The Destination HISP delivers the pushed content to the Destination System using XDR

If a party in group 1 wants to communicate to a party in group 2 or 3, here is the overall process that could take place:

1. The Source System communicates to the Source HISP via XDR.
2. The Source HITSP S/MIME encrypts the content
3. The Source HISP converts the XDR metadata and content to an XDM Zip file an attaches it to the communication.
4. The Source HISP locates the destination HISP via the destination address in the XDR informationRecipient metadata.
5. The Source HISP sends it via SMTP+TLS to the destination HISP.
6. The Destination HISP stores the encrypted content until requested by the Destination System.
7. The Destination System requests the content.
8. The Destination HISP descrypts the S/MIME encrypted content and sends it to Destination System (via POP or IMAP).

If a party in group 2 or 3 wants to communciate to a party in group 2 or 3, here is the overall process that could take place:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP stores the encrypted content until requested by the Destinatio Edge System
6. The Destination System requests the content.
7. The Destination HISP descrypts the S/MIME encrypted content
8. The Destination HISP sends it to Destination System (via POP or IMAP).

Now, a distinction appears in the protocol when we want to go from B to A or C to A.  Let's look at B to A first:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP decrypts the S/MIME encrypted content.
6. The Destination HISP sends the XDM content via XDR through a simple transform that requires no manipulation of PHI, and only deals with protocol bridging.

Now let's look at C to A:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP decrypts the S/MIME encrypted content.
6. * The Destination HISP fails to locate an XDM package and sends a message back to the source HISP indicating that the content could not be transmitted.

Step 6 is a problem, but not an insurmountable one, and we've already covered almost all cases.  There are a couple of ways that a software component could eliminate the rejection in step 6, depending on the content and communication intent:

1. The message is simply a "text e-mail" with no attachments directed to the destination address.  For example: "I'm sending John Doe to you to have an EKG because he has a history of hypertension.  Could you send the results back to me when you are done.  Thank you.  Dr. Smith"
2. The message includes an attachment in a non-healthcare format (e.g., PDF) or a proprietary format (e.g., RTF).
3. The message also includes an attachment in a healthcare standard format (e.g., CCD or CCR) and that attachment is from the medical record of the patient who the communication is about. (Add "P.S., I've added John's CCD to this e-mail" to the previous case).
4. The message includes an attachment in a healthcare standard format, and that attachment is not from the medical record of the patient who the communication is about.  "I'm sending you the information about the delivery of Jane Doe's baby John as she tells me that you will be John's pediatrician.  Attached please find her delivery summary.  Thank you.  Dr. Smith."
5. The message includes multiple attachments for different patients.  "Here are my records for the paitents I immunized today.", and/or "Here is Jane's delivery summary and Baby Doe's discharge summary".
6. The message includes an attachment that is not specific to any single patient.  "Here is my quality report."

Cases 1, 2, 3 and 4 can be made to fit an XDR model by generating a unique random identifier to identify the patient and including minimal metadata in the XDR communication.  What will be lost is any way to have the patient be matched in the NHIN Exchange side.  As we've seen in the media, ensuring that patients are correctly identified during information exchange is important for patient safety.  Users on the NHIN Exchange side will need to deal with cases where patient information comes in where they have to ensure that the patient is correctly identified.  We've also seen examples where content in case 3 can be bridged using a "better" set of metadata, but it is difficult to distinguish those in case 3 from those in case 4.  That could be addressed by including an additional header in the communication that indicated that the Attachments in the communication are related to the patient that the communication is about.

That leaves the last two cases.  Batching and quality reporting is NOT a requirement for phase 1 of NHIN direct, although they could be requirements of future phases.  The two documents from different medical records pertinent to one patient is arguably a rare case that we can better work the details out for later.

Frankly, I could spend another page proposing solutions to these two cases, and knowing that I could do that is enough to stop here.

I believe there is a way forward.  I believe that way forward will need to include some sort of bridging technology, and I'm very much in favor of recommending XDM content in whatever is selected to support that bridge.  Whether the backbone of NHIN Direct is SMTP or XDR, what we need to realize is that the backbone of NHIN needs to support both.

All of the examples I gave assumed that the Source and Destination HISP's were trusted with the responsibility to encrypt/decrypt the S/MIME package. This is to address certificate deployment issues.

In the examples I gave above, I showed that it was the Destination HISP that was responsible for bridging the content.  Arguably, that bridging step could also be done by the Source HISP, and I see no reason to prevent or discourage that.  Bridging is in fact an additional service that should be offered to enable the existing NHIN Exchange infrastructure to support NHIN Direct.  The examples I just described could actually treat the "bridging component" as the Source or Destination System, which would be a purer way to describe it.  From my perspective, I just see that additional component as fitting best with a software application that performs the HISP role.

P.S.  Actually, group 1 to group 1 is already addressed by current NHIN protocols using a query model and an XDR push model, this exchange group really doesn't need to be addressed by NHIN Direct.