ONC focus on NHIN governance presents opportunity to establish acceptable security and privacy standards

According to an article yesterday from Government Health IT, the Office of the National Coordinator is getting ready to address a more complete set of rules of behavior and other requirements for participation in the Nationwide Health Information Network (NHIN), and to establish the governance processes and capabilities to manage, monitor, and enforce them. While current participation in the NHIN Exchange is limited to federal agencies and federal contractors or grant recipients, the long-term vision for participation includes a wide range of state, regional, and federal government entities, commercial health care enterprises, and potentially researchers and other relevant organizations. For NHIN Exchange, there is a NHIN Coordinating Committee serving in an oversight capacity, with representation from ONC as well as each active participant, but as the number of participants grows from its current single-digit level of active NHIN-participating entities and the focus shifts from building the NHIN to managing an operational infrastructure, a different sort of model is likely to be needed. Formal governance procedures, not to mention a governing body (ONC personnel and documentation typically use the term “NHIN governing authority”) with fully specified roles and responsibilities, are needed initially facilitate the participation of entities that aren’t necessarily bound by the legal requirements that apply to current participants, to evaluate whether applicants to participate should be able to do so, and to oversee the monitoring of the NHIN that is implied in the Data Use and Reciprocal Support Agreement (DURSA) and other participant agreements. A key topic area that governance rules must address is the set of security and privacy provisions NHIN participants are able to support, including obvious security needs like secure communication, entity authentication and authorization, and audits, but also likely including practices like consent management.

The text of the DURSA provides several examples of expectations or obligations of its signatories that could be translated into an evaluation framework or standard set of criteria by which the security and privacy capabilities of prospective participant could be assessed. Under the DURSA, entities participating in the NHIN are responsible for maintaining the security of their own environments and to apply appropriate safeguards that protect the information the entity sends or receives using the NHIN. The point of reference for “appropriate safeguards” is the HIPAA Security Rule (45 CFR §160 and §164), which seems a sensible source for requirements, at least for participants who are HIPAA-covered entities or business associates. The challenge may be in making a default or standard or minimally acceptable specification of just what safeguards are appropriate, and in trying to apply such a standard uniformly to all organizations. The only category of security controls called out explicitly in the DURSA is protection against malware, a requirement which, much like the general security provisions, is focused on protecting the message contents that will be transmitted using the NHIN and on protecting entities against the possible introduction of security threats into their environments via the ostensibly trusted channel that the NHIN provides. A thornier problem may be the NHIN’s approach (viewed through the DURSA) of handling access controls for end users — NHIN Exchange uses digital certificates for entity authentication and authorization (and other purposes), but the certificates are bound to the organizational identity, not to any individual users that might access NHIN-connected systems and initiate queries, requests, or data exchanges. Specifically, section 7 of the DURSA on System Access Policies (in its entirety) stipulates that:

Each Participant shall have policies and procedures in place that govern its Participant Users’ ability to access information on or through the Participant’s System and through the NHIN (“Participant Access Policies”). Each Participant acknowledges that Participant Access Policies will differ among them as a result of differing applicable law and business practices. Each Participant shall be responsible for determining whether and how to respond to a Message based on the application of its Participant Access Policies to the information contained in the assertions that accompany the Message as required by the NHIN Performance and Service Specifications. The Participants agree that each Participant shall comply with the applicable law, this agreement, and the NHIN Performance and Service Specifications in responding to messages.

One way to interpret this language would be that participating entities are required to have access control policies and controls for its own systems, but that a given entity shouldn’t expect the policies and controls of another participant to be comparable to its own. Nevertheless, when receiving a message via the NHIN, participants are expect to use their own access control policies to determine whether and how to respond — this despite the fact that it seems highly unlikely that any identifying information about a requester (other than his or her entity affiliation) can be much use in making authorization decisions, since there is no reason to expect users of other participants’ systems to be known to the entity that receives the request or other message. The assumption seems to be that authorization of participating entity users is implied by their employment or other relationship to the entity whose certificate validates the assertions in the messages sent via the NHIN. However, for a given participant to have the confidence it needs to accept the validity of the individual initiating a request, it would seem enormously helpful to have some idea either of what access control policies are applied and enforced by the requesting entity, and also how those controls and other security and privacy measures were evaluated by someone in authority with the NHIN in order to decide that the controls were adequate for the intended uses of the NHIN to be supported.

ONC will engage the public and all interested stakeholders in the process of developing NHIN governance rules and capabilities, beginning with a request for information to be issued later this summer, and then through a comment period on a draft rule to be published early next year. From a practical standpoint, some of the areas that will need to be addressed in any governance framework will be functions and processes already in place for NHIN Exchange, but for which formal criteria or standards have not yet been developed. For example, part of the “on-boarding” process for a new applicant is to apply for a digital certificate (this actually occurs twice, as a temporary cert is issued to be used for validation and testing, and then a production version), something that is not supposed to happen until the prospective participant’s application has been received and the participant has been approved for membership in NHIN Exchange. The decision to approve a prospective NHIN participant is a core governance function, but to date this process has been handled on a case-by-case basis, so to scale to a production-capable process, formal governance rules and standards are certainly needed, not to mention decision criteria. There are a number of functional areas ONC is working to support, but most of these also presume the existence of some sort of governing authority. ONC went so far as to issue a request for proposals in late January to award a contract for NHIN Operational and Infrastructure Support, with a variety of tasking that either presume or directly depend on the existence of a NHIN governing authority. These tasks included administering and operating technical infrastructure supporting the NHIN (”infrastructure” in this context means the certificate authority, directories, and network infrastructure), implementing a support center to provide assistance to participating entities throughout the process of joining the NHIN and of participating once they are on board, and creating and maintaining the on-boarding process itself.

To move forward with a larger-scale NHIN that still leverages some of the core features of NHIN Exchange, it is essential for the governance processes and criteria associated with the NHIN (and with ONC, if ONC will own the governance function in the future) to be robust and transparent enough to give entities the confidence they need to participate. With the central governance model and single multi-party legal agreement used to date with the NHIN, participants theoretically have no need to trust each other, as long as they have confidence in the central authority that approves applicants for participation, and in the criteria used to make those approval decisions. This means that the key relationship for each NHIN participant is with the NHIN governing authority, since the NHIN asks participants to set aside their own judgment about other participants, and substitute the NHIN’s judgment instead. Even with a robust governance function in place, this task is likely to prove very challenging, but without effective governance in place, it’s not even feasible.