NHIN Direct Update

Last week, I wrote about the way I select my outdoor gear. First, I define requirements such as:

What will the gear be used for?

How durable does it need to be?

How light is it?

I then search for a product that meets the requirements.

Sometimes products are available off the shelf.

Sometimes I have to modify commercially available products.

Sometimes products have to be made from scratch by specialists.

In my opinion, last week's NHIN Direct face to face meeting demonstrated that we do not have an off the shelf solution for simple point to point communication that meets all the requirements outlined by the NHIN Direct participants. Wes Rishel's blog further outlines the issues.

To review, requirements include:

*The NHIN Direct protocol relies on agreement that possession of the private key of an x.509 certificate with a particular subject assures compliance of the bearer with a set of arbitrary policies as defined by the issuing authority of the certificate. For example, Verisign assures that bearers of their "extended validation" certificates have been validated according to their official "Certification Practice Statement." Certificates can be used in many ways, but NHIN Direct relies on the embedded subject and issuing chain as indicated in the following points. Specific implementations may choose to go beyond these basic requirements.

*Implementations must allow configuration of one or more public certificates representing "anchors" that implement agreed-to message handing policies. Implementations should allow anchors for sending messages to be distinct from those for receiving messages.

*Implementations should allow these configurations to be unique per-address in addition to per-health-domain. This will ease integration for participants with an existing PKI infrastructure, and provides a path to more fine-grained assurance for future use cases. Implementations must be able to accept messages identified per-address or per-health-domain per the Sender Identification requirement below.

*When possible, implementations must frequently check the validity of configured or cached certificates through standard means. The definition of "frequently" should be defined by external policy.

*NHIN Direct messages must be reliably linked to the public certificates possessed by the sender, through standard digital signatures or other means that match the certificate subject to the sender's address or health domain. Implementations must reject messages that are not linked to valid, non-expired, non-revoked public certificates inheriting up to a configured Anchor certificate per the Certificate Anchor Configuration requirement above.

*NHIN Direct messages sent over unsecured channels must be protected by standard encryption techniques using key material from the recipient's valid, non-expired, non-revoked public certificate inheriting up to a configured Anchor certificate per the Certificate Anchor Configuration requirement above. Normally this will mean symmetric encryption with key exchange encrypted with PKI. Implementations must also be able to ensure that source and destination endpoint addresses used for routing purposes are not disclosed in transit.

*Implementations should attempt to ease the complexity of certificate management for end users and organizations. While this is not a hard protocol requirement, it is important to be aware that many systems leveraging certificate technology have failed to achieve adoption due to complexity of PKI management, so efforts here will be a key driver of success or failure for NHIN Direct. If possible implementations should enable NHIN Direct users to think in terms of "who do I trust" rather than "what certificates do I import". Implementations should also ensure that users can leverage existing credential management programs; for example, ICAM in the federal space.

*NHIN Direct messages must be protected using standard hashing techniques acceptable in current regulation.

Based on these security requirements, a workgroup of the HIT Standards Committee evaluated the 4 NHIN Direct reference implementations, REST, SOAP/IHE, SMTP and XMPP, to assess their compliance with these requirements and to propose the simplest, compliant solution for an initial NHIN Direct pilot.

We evaluated the reference implementations based on the current state of the standards, as they are today.

Our sense was that REST adhered to all the security requirements, decoupled transport from content, and kept the content secure without the need to inspect it during transport. Metadata was not disclosing since it was limited to just a from/to address for transport. We made our recommendations to the NHIN Direct team.

At the NHIN Direct meeting, there was wide acceptance of REST as an option, but stronger support for SOAP/IHE. This was based on technical considerations for some of the participants, but just as strongly was based on the current support nearly all of the EHR and HIE vendors have for the XDS profile. There was broad acceptance that the SOAP/IHE option should be changed as follows:

1. Separation of routing metadata from content data

2. Separation of content standards from routing standards

3. End to end content encryption

4. Ability to route any package - patient specific or not

5. Ease of implementation with simple documentation, fewer requirements, and rapid deployability for all stakeholders

There was also enthusiasm for using SMTP at the edges - enabling a small practice to send healthcare data content to a Health Information Service Provider via secure email.

So, where do we go from here?

Based on the requirements and the current state of standards, there is not an off the shelf solution that works for everyone.

Harmony seems to be broadly achievable by allowing SMTP at the edges to support the little guy and using SOAP/IHE as the backbone but only if it is changed in the 5 ways listed above. REST could bring everyone along, but it would also require new software development for all the participants.

Consensus is always hard to achieve among a large group debating complex issues. At the NHIN Direct meeting, a few vocal detractors refused to accept SOAP/IHE regardless of the modifications to it.

This week there will be a followup call with the group to try to reach consensus. With SMTP for the little guy at the edge and SOAP/IHE (modified to meet NHIN Direct requirements) as the backbone, hopefully the group can get to yes.