Clearer definitions and roles for intermediaries would facilitate policy decisions on directed exchange of health data

During the latest meeting of the Health IT Privacy and Security tiger team today, the bulk of the discussion centered around draft recommendations for message handling in what the group calls “directed exchange” in which health care providers send data on patients to other providers in a point-to-point communication. This type of exchange comes into play in many of the use cases intended to be satisfied by the NHIN Direct pilot project, so part of the discussion focused on the appropriate policy declarations that should be made about directed exchanges of health data, including among NHIN Direct participants. One of the primary concerns of the group is establishing the right policy and technical mechanisms to minimize the exposure of protected health information (PHI) send as part of these directed exchanges.

To guide this discussion, the draft recommendations identify four categories of exchange, differentiated by presence or absence of an “intermediary” handlers of the messages in the exchange and the role of such intermediaries where they are involved, with particular scrutiny on how much access the intermediaries would have to PHI within the message contents. The four categories the tiger team is using are:

1. No intermediary involved (exchange is direct from point A to point B).
2. Intermediary only performs routing and has no access to unencrypted personal health information (PHI) (message body is not unencrypted and routing information does not identify patient).
3. Intermediary has access to unencrypted PHI (i.e., patient is identified) but does not change the message body, either the format or the data.
4. Intermediary opens message and changes the message body (format and/or data).

Not far into this point on the agenda, the discussion devolved a bit into a debate on just what an “intermediary” is, and whether it would be good policy to state that no intermediary should have access to PHI at all under directed exchanges of health information. Clearly no consensus exists among the group on the definition of intermediary, but from the perspective of looking at solution elements proposed for NHIN Direct, a key question (not yet definitively answered) is whether a service used by a doctor, such as a hosted EHR or message packaging (including encryption) and delivery by a health information service provider (HISP) introduces an intermediary into the equation. It might simplify the discussion on both the technology, policy, and legal compliance fronts to just assume that all exchanges involve intermediaries, and focus on whether existing legal requirements such as those in the HIPAA Security and Privacy Rules would apply to those intermediaries, and therefore mitigate at least some of the concerns about the ability to see or process PHI.

For the sake of argument, it might make sense to say that when your data passes from one organizational entity to another, the involvement of any entity other than the sender and receiver means there is an intermediary. With respect to the basic categories of message handling for directed exchange, it seems to make little sense to include the first category (“no intermediary”) at all if we are talking about data exchange over the Internet or other public or common carrier-furnished communications infrastructure. Perhaps the no-intermediary case would apply with a secure domain (in the IHE sense of the term) such as an organizational LAN or WAN or company-owned private network. We would argue that neither server-to-server nor desktop-to-desktop secure communication channels (such as TLS) really remove intermediaries (ISPs, backbone infrastructure providers) from the communication, but with such a secure channel in use there should be no concerns about the intermediaries getting any access to the data — including PHI — that flows across the connection. If we can agree that for all intents and purposes, there is always some sort of intermediary involved, then we can shift the discussion where it ought to be — to the extent to which intermediaries can access data in the messages, especially if they contain PHI.

The “B” option in the list above is a pretty standard use case for mutually-authenticated point-to-point communication channels such as TLS, but could also apply to unsecured channels where message (payload) encryption was involved. This distinction is important insofar as directed exchange using SMTP is intended to be an option. The “C” option is similar to the second one, but instead of encrypting or otherwise packaging the message at the point of origin, here the intermediary (such as a HISP) performs encryption and decryption processing on behalf of the parties to the exchange. This option is favored by some working on NHIN Direct to save providers from having to install and use encryption technology locally, and also to help simplify digital certificate management by using the HISPs as the boundary for public key infrastructure established to enable secure, authenticated exchange. In this third category it seems logical that the intermediary would fit the definition of a business associate under HIPAA, as the intermediary would be an”entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.” To be fair, nothing in the legal definition under HIPAA explicitly includes functions like encryption or message routing, but does include functions such as “data analysis, processing, or administration” and other generic services such as data aggregation, management, administrative, and accreditation services (45 CFR §160.103). Covered entities were already responsible for the compliance of their business associated with HIPAA safeguards, and under HITECH the HIPAA security and privacy rules apply directly to business associates, so even the temporary exposure of such intermediaries to the contents of messages (before the contents are encrypted for transmission) should not raise any special privacy concerns unless the parties believe that constraints applicable to business associates are insufficiently robust.

A similar logic applies to the “D” option, although in this case because the intermediary is explicitly processing the contents of the message, the intermediary would be considered a health care clearinghouse and therefore a HIPAA-covered entity (potentially in addition to being a business associate of the parties to the exchange). This means it would be in the intermediary’s own interest to guard against unauthorized disclosure, as the full set of HIPAA requirements apply when it accesses, changes, or otherwise discloses PHI. In recent weeks, the Health IT Policy Committee’s Privacy and Security Policy Workgroup has recommended policies in other contexts (notably including consent) that would result in the need for no additional protective measures beyond what is required by current law. If the definition and role of “intermediary” in the various directed exchange patterns was more clearly specified, it would be easier to identify areas of security or privacy concern that are already addressed by current legal requirements, and also to highlight any gaps that exist that might demand new policy statements.