HIE and NHIN Implementation Issues: (a) Data Sharing Agreements, (b) the Master Patient Index, (c) Data Standardization, (d) Consent Requirements, and (e) Duties of Network Participants

By Robert Hudock, on March 25th, 2010

On March 19th, HHS published a notice in the Federal Register that HHS intends to complete approximately 2500 surveys to assess public perception of Health Information Exchanges.[i] Public perception of the security of HIE’s is key to understanding how ONC will eventually regulate HIEs. On a macro level the National Health Information Network (NHIN) is a network of HIEs. At this time most states have received grants to implement an HIE. Recently, however, HHS has also announced a scaled down version of the Connect software to be used for limited transaction between providers. Generally, NHIN Connect software framework is designed to enable secure and interoperable electronic health information exchanges (HIE) with NHIN compliant organizations, including federal agencies, local-level health organizations, and healthcare participants in the private sector. However, the NHIN Direct initiative announced in January, 2010 may replace some HIEs that do not bring value added services to the market place.

The typical use case of an HIE under a federated exchange model transaction involves:

Initiation of a request to the HIE service to determine if a person has relevant medical information within the HIE;
A response is returned to the requesting organization, which would request to receive the relevant data.
The HIE service would verify that the requesting organization is authorized, authenticated, and has access privileges to the information and that the person has provided consent for transmission of the given information;
The approval along with supporting metadata is transmitted to the supplying organization who has the relevant information; and
The disclosing organization would supply the information as required by the underlying data sharing or HIE participation agreements.

Both HIEs and networks of HIE (basically the NHIN) must be able establishing a baseline of trust among participants, typically, this trust includes–

Processes to ensure the integrity of patient data;
Verifiability of data after transforming, storing and/or sending (e.g. checksum, error checking, etc.);
Verification that the data source and data content are true; and
Organization the HIE or the NHIN can define standardized data values and a protocol format for sharing medical data.

Implementation usually requires:

A data sharing agreements and policies to enable information sharing and make system usable;
An enterprise master patient index (eMPI) which serves as a record locator; and
A balancing of data standardization (normalization) and physician freedom to have clinical control of the medical record while being efficient in their treatment of patients.[ii]

I have excerpted privacy and security related covenants from a document entitled Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009, which provides a summary of key features of a comprehensive agreement that governs the exchange of health data across a diverse set of public and private entities. This agreement – the Data Use and Reciprocal Support Agreement (“DURSA”) requires that:

To the extent that each Participant has existing privacy and security obligations under applicable law (e.g. HIPAA or other state or federal privacy and security statutes and regulations), the Participant is required to continue complying with these obligations. Participants, which are neither HIPAA covered entities, HIPAA business associates nor governmental agencies, are obligated to comply with specified HIPAA Privacy and Security Rules as a contractual standard of performance.
It is the responsibility of the responding Participant – the one disclosing the data – to make sure that it has met all legal requirements before disclosing the data, including, but not limited to, obtaining any consent or authorization that is required by law applicable to the responding Participant. This policy is essential for nationwide health information exchange given the number of different state laws, Federal statutes and local policies related to consent or authorization to exchange data for treatment purposes. To effectively enable the exchange of health information in a manner that protects the privacy, confidentiality and security of the data, the DURSA adopts the HIPAA Privacy and Security Rules as minimum requirements.
Participants are required to promptly notify the NHIN Coordinating Committee and other impacted Participants of breaches which involve the unauthorized disclosure of data through the NHIN, take steps to mitigate the breach and implement corrective action plans to prevent such breaches from occurring in the future. Suspected breaches must be reported within one (1) hour of discovering information that leads the Participant to believe that a breach may have occurred. As soon as reasonably practicable, but no later than twenty-four (24) hours, Participants must notify affected Participants and the NHIN Coordinating Committee This process is not intended to address any obligations for notifying consumers of breaches, but simply establishes an obligation for Participants to notify each other when breaches occur to facilitate an appropriate response.

(See Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009)

HIE services typically includes:

Patient identification and registry services within a directory structure;
Consent management and enforcement of a user’s consent when collecting, storing, accessing, processing, and disclosing personal health information; and
Information for the patient about the HIE at the point of care and a business process to obtain consent that will be used for future exchange of data until changed by the individual.

The CONNECT framework is designed to offer similar services for the NHIN. CONNECT is designed to implement privacy and security controls defined in the NHIN services, and when implemented and combined with the NHIN operating procedures and the DURSA, it allows organizations to participate in the “web of trust” that enables the secure exchange of interoperable health information among the participants of the NHIN.

Privacy and security laws do not directly cover NHIN in the sense NHIN is really a collaboration of many organizations who elect to participate in the network. Several different types of entities participate in the NHIN. There are HIPAA “covered entities”, such as providers, there are the HIPAA-defined “business associates” of those covered entities, and there are non-covered entities which are not currently required to comply with HIPAA rules.

The NHIN is more like the Internet than a traditional health information system found within a hospital. NHIN while not a covered entity, NHIN has a similar threat profile. Similar to an HIE, the Data Use and Reciprocal Support Agreements (DURSA) permit network participants to contract the specific terms under which they will exchange information, including addressing privacy and security needs of each NHIE amongst themselves. The responsibility for security, including compliance with state and federal laws, including HIPAA, rests with the member organizations or the network nodes a hospital, physician’s office, etc. Examples of common DURSA contracts/agreements are listed in the table below.

The typical Connect implementation involves the use of a server based PKI and the NHIN NHIE service registry which define and secure the NHIN core backbone. Connect services include-

The messaging platform and authorization framework to implement security and privacy controls to address the known threats for Web services implementations of service-oriented-architectures;
The audit log query service is designed to meet the requirements for HIPAA disclosure accounting;
The consumer preferences profile allowomg consumers to express their preferences for whether or not to share their information on the NHIN and for more granular control over access to their private information. The CONNECT policy engine enforces those preferences in the runtime environment to insure that the access policies of the organization and the preferences of the consumer are honored in the decision to release health information in response to a request from the NHIN

In a separate draft publication ONC has detailed use cases on how to obtain, modify, and detail a patient’s consent to access his/her medical record.

If this all seems to daunting, a less ambitious project was recently announced by ONC called NHIN Direct. The NHIN Direct project is focused on smaller providers who are unable to implement the Connect solution, and/or put in place an appropriate DURSA. According to ONC- “NHIN Direct is intended to solve simple direct secure electronic transport supporting health information exchange currently being handled via paper or portal communication following existing trust models.”

Transactions that would fall within the scope of NHIN Direct would be those transactions involving the communication of pre-existing information typically transferred via fax, courier, mail or clipboard, or in some cases, via a patient/physician portal. The transactions must be “push transactions” where patient identity is known and consent and legal authorization exists for the information transfer. (See http://nhindirect.org/User+Stories).[iii]

Additional Information – Data Sharing Agreements

Sample DURSA Business Associate Addendum

Sample Health Information Exchange Agreement

AMENDED AND RESTATED CLINICAL OUTCOMES ASSESSMENT PROGRAM HEALTH CARE PROVIDER INFORMATION SHARING AGREEMENT

ONC NHIN Draft Policies

2010 NHIN Final Production Specifications
The following specifications have been provisionally approved by the NHIN Technical Committee. This approval is subject to the validation of the NHIN reference implementation.

Additional Information Available at the Following Sites:

American Health Information Community (AHIC) http://www.hhs.gov/healthit/ahic.html
American Health Information Management Association (AHIMA) http://www.ahima.org/
Certification Commission for Healthcare Information Technology (CCHIT) http://www.cchit.org
Commission on Systemic Interoperability http://endingthedocumentgame.gov
Healthcare Information and Management Systems Society (HIMSS) http://himss.org/ASP/index.asp
HL7 United States http://www.hl7.org/
International Health Terminology Standards Development Organization (IHTSDO) and SNOMED International http://www.ihtsdo.org/
Office of the National Coordinator of Health Information Technology (ONCHIT) http://www.hhs.gov/healthit/

[i] See http://edocket.access.gpo.gov/2010/2010-6020.htm

[ii] CONNECT has three primary components:

The Core Services Gateway implements the core NHIN services enabling such functions as locating patients at other health organizations within the NHIN, requesting and receiving documents associated with the patient, and recording these transactions for subsequent auditing by patients and others. Other features include authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information.
The Enterprise Service Component (ESC) provides default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log.
The Universal Client Framework contains a set of applications that can be adapted to create an edge system, and be used as a reference system, and/or can be used as a test and demonstration system for the gateway solution.

[iii] The project has highlighted the following use cases for the NHIN project:
1. Primary care provider refers patient to specialist including summary care record
2. Primary care provider refers patient to hospital including summary care record
3. Specialist sends summary care information back to referring provider
4. Hospital sends discharge information to referring provider
5. Laboratory sends lab results to ordering provider
6. Providers without a fully certified EHR send and receive data
7. Primary care provider sends patient immunization data to public health
8. Pharmacist sends medication therapy management consult to primary care provider
9. Provider sends patient health information to the patient
10. Provider sends a clinical summary of an office visit to the patient
11. Hospital sends a clinical summary at discharge to the patient
12. Provider or hospital reports quality measures to CMS
13. Provider or hospital reports quality measures to State
14. Laboratory reports test results for some specific conditions to public health
15. State public health agency reports public health data to Centers for Disease Control
16. Provider reports to the State
17. Hospitals reporting to the State