Data encryption for HIE sounds obvious; not so simple to implement

One of the early themes that has emerged from the initial discussions of the Office of the National Coordinator’s privacy and security tiger team is the need for stronger protection of the confidentiality and privacy of health data exchanged between entities — whether in a point-to-point exchange model such as NHIN Direct‘s or a multiparty exchange environment such as NHIN Exchange — and the call for the use of content encryption to afford that protection. This near-consensus recommendation follows from the recent work of the Health IT Policy Committee and its Privacy and Security Policy Workgroup, which resulted in recommendations for encryption of patient data whenever it is exchanged. (Side note: The tiger team was organized as a workgroup under the Policy Committee, although its membership includes people from the Health IT Standards Panel and the National Committee on Vital and Health Statistics (NCVHS); it is co-chaired by Deven McGraw and Paul Egerman, both of whom are Policy Committee members who lead standing workgroups.) The emphasis in this recommendation and something of a departure from past precedent is on encryption of the contents or payload of messages exchanged using health information exchange (HIE), alone or in addition to the transport-level encryption (such as SSL or TLS) that is already specified for secure exchange among NHIN participants. During the May 19 Policy Committee meeting, McGraw presented a set of recommendations from the Privacy and Security Workgroup that were considered from the perspective of what a reasonable patient would expect. One area of emphasis on which the Privacy and Security Policy Workgroup is continuing discussion is patient consent, but tiger team latched on to content encryption when it began discussing ways to maintain privacy when electronic health records or other protected health information is exchanged electronically.

The tiger team recognizes that even when health information exchange is limited to a transmission between two entities, there may be several ways of technically enabling the communication, many of which involve the use of intermediaries such as health information service providers (HISPs) that, depending on the nature of the exchange, may or may not have a need to examine the messages flowing through them on their way from sender to receiver. To the extent that such intermediaries may be performing functions outside the realm of what would put them under the HIPAA definition of business associate, the Health IT Policy Committee and the tiger team members are concerned that current legal requirements for the protection of health data may not apply to the intermediaries. One way to mitigate such concerns is to render the data unreadable to intermediaries, which in general means encrypting it. The discussion this month has been informed by the work on the NHIN Direct project (and participation in the tiger team meetings by some NHIN Direct team members), which has raised the issues of end-to-end content encryption and separating the potentially PHI-containing message content from the header data or other metadata needed to successfully route the message to its destination. There remains some debate as to whether such content encryption should be a mandatory requirement, or should remain “addressable” as it is under the HIPAA Security Rule.

One argument in favor of mandating the use of encryption is the technical feasibility of such an approach. By applying Web Services Security standards, particularly including SOAP Message Security, solution developers and implementers have a lot of flexibility to separate and separately protect message contents from message envelope information. The real challenge lies not in separating routing data from payload, or from enabling content (or full-message) encryption, but instead in what encryption model should be used in order to make encryption possible without imposing barriers to interoperability. Perhaps obviously, there is no value in encrypting data in transit if the recipient cannot decrypt the message, but the sort of public key infrastructure used for NHIN Exchange is not necessarily a viable approach for a solution like NHIN Direct. The use of digital certificates for encryption in health information exchange has been recommended for NHIN Direct, but because NHIN Direct will not rely on a central certificate authority, there will need to be provisions for managing and evaluating certificates from multiple issuers potentially representing different “trust domains” to which a given exchange participant might belong.

As the NHIN Direct members have discussed in the past, there are ways to do this without full-scale PKI and all of the key distribution and management overhead that comes with such an infrastructure. That potential aside, no one should underestimate the significance of the tasks of establishing, managing, and overseeing the certificates and supporting services necessary to facilitate end user encryption and decryption among health information exchange participants (to say nothing of integrating such capabilities into end user electronic health record systems, transaction gateways, web services, SMTP clients, or other messaging tools). It certainly helps that multiple technical alternatives are incorporated within available open standards and that many health IT product vendors support these standards, but there is a great deal of additional processing and management required to accommodate pervasive use of content encryption. The complexity of such a solution may explain why, to date, only the transport-level encryption is used for the NHIN, and the only encryption used within the payload is the digital signing of SAML assertions included within the SOAP messages exchanged via the NHIN. The use cases envisioned for NHIN Direct are different than those for the NHIN in general, particularly with respect to transport encryption, with is required for the NHIN but may not be in place for all possible transport mechanisms that might be supported by NHIN Direct.