Question 7. What privacy and security considerations, including compliance with relevant rules of HIPAA, are implicated by the NHIN, and how could they be addressed?

• All of the capabilities of the Health Information Environment including the delivery of care, the conduct of research, and public health reporting, must be conducted in an environment of trust, consistent with appropriate requirements for patient privacy, security, confidentiality, integrity, audit and informed consent.
• Participation in the Health Information Environment by providers, patients, or others must be voluntary; no one must be required to share information.
• The Health Information Environment is premised on a model of patient authorization and control. Patients must be able to: choose whether or not to participate in sharing personally identifiable information; exercise their rights under HIPAA; control who has access to their records (whether in whole or in part); see who has accessed their information; review, contribute to and amend their records (without unreasonable fees); receive paper or electronic copies of their information; and reliably and securely share all or portions of their records among institutions. Once patient consent has been granted for a certain type of information access, however, information should be able to be accessed freely in a trusted environment.
• Clinical data will be managed by those who have a direct relationship with the patient (patients may also keep their own records of their own information).
• No mandated national unique health ID is required, but standardized methodologies to identify patients are required.
• No single repository is intended to hold all of a patient's clinical data (although this does not preclude patients from aggregating their data, either on their own or through the services of a trusted third party such as a personal health record or PHR provider).
• Authorization and authentication of users takes place at the regional, sub-network or local institution level.
• Sub-networks will be required to participate in some form of validation process.
• The Health Information Environment is a network of networks, linked only by registries through which authorized information about how to find the locations of records can be found, not any of the actual content of the health records. Thereby, the registry system knows only where records are, not what is in them.
• To achieve these capabilities, the Health Information Environment requires the addition of one new piece of infrastructure at the sub-network level based on an architecture that separates the function of locating authorized records from the function of transferring them to authorized users. This piece of infrastructure is the Record Locator Service (RLS) and is operated by a multi-stakeholder collaborative at the regional or non-geographic sub-network level and built on the current enterprise use of Master Patient Indices. The RLS itself is subject to privacy and security requirements, and is based on open standards set by the SPE.
• The system supports
  1. Linking of records via a registry of names and record location information, and sharing among users participating in the system, but it also allows
  2. Linking without sharing, or sharing pursuant only to higher authorization, as well as
  3. The ability to choose not to link information in certain sensitive treatment situations determined by users.

By leaving these decisions at the edges (e.g., with patients and the professionals that support them), the architecture supports a range of approaches. It also allows higher levels of approval to be set locally for sharing some records. This obviates the need to have "one size fits all" policies as would be necessary for centrally controlled approaches. The Record Locator Service needs to enable a care professional looking for a specific piece of information (PCP visit or ER record) to find it rapidly. An open design question is how and where in the model this capability can best be accomplished.

• The Privacy and Security Principles (as outlined by Connecting for Health's Linking Workgroup) for the sub-networks and the broader Health Information Environment must address:
  1. Confidentiality: Material existing within the system will only be disclosed to those authorized to have it.
  2. Authentication: The system will require identification for use by all authorized individuals, thus both deflecting unauthorized use and enabling auditing for monitoring of compliance with policy guidelines.
  3. Integrity: Material in the system will be defended against unauthorized alteration, and all alterations will be logged.
  4. Non-repudiation: Transactions undertaken in the system will be acknowledged by both parties, and cannot be unilaterally revoked or altered.
• The Security Standards (as outlined by Connecting for Health's Working Group on Accurately Linking Information for Health Care Quality and Safety in its report: Linking Healthcare Information: Proposed Methods for Improving Care and Protecting Privacy) must address:
  1. Wire Security: Securing material "on the wire" means making sure that in its transit from point A to point B it is defended from eavesdropping, copying, or other interception. In practice, this can mean encrypting all the material passing over that connection, and ensuring that it is effectively delivered to the desired recipient.
  2. Perimeter Security: Perimeter security involves requiring some form of authorization credentials for anyone using the system for any reason, as well as an auditing program that allows use of the system to be evaluated later.
  3. Content Security: Sometimes a user is both authorized to use the system and a malefactor, as with the hypothetical examples of a file clerk searching for his girlfriend's records, or the intern looking at the records of a famous patient. This type of attack can be limited by restricting what can be done with the data, even by authorized personnel, and by making sure that physical access to the equipment does not translate directly to access to its contents.