RESTATEMENT I OF THEDATA USE AND RECIPROCAL SUPPORT AGREEMENT (DURSA) Nationwide Health Information Network Exchange

May 19, 2011

Data Use and Reciprocal Support Agreement

» A comprehensive, multi-party trust agreement that will be signed by all eligible entities who wish to exchange data among Participants

» Multi-party agreement that eliminates the need for “point-to-point” agreements, which Federal participants have asserted are not sustainable for information exchange

» Requires signatories to abide by common set of terms and conditions that establish Participants’ obligations, responsibilities and expectations

» The obligations, responsibilities and expectations create a framework for safe and secure health information exchange, and are designed to promote trust among Participants and protect the privacy, confidentiality and security of the health data that is shared

» Assumes that each Participant has trust relationships in place with its agents, employees and data connections (end users, systems, data suppliers, networks, etc.)

» As a living document, the agreement will be modified over time

» The DURSA does NOT preempt ONC’s governance rule-making process in any manner.

2

DURSA Milestones

» May 2008 – draft agreement developed for exchange of test data for testing and demonstration purposes (Test Data DURSA)

» September 2008 – Test Data DURSA executed by 11 private entities, 4 state entities and 6 Federal agencies

» December 2008 – draft agreement developed to support exchange of individually identifiable data in production environment

» June 2009 – Draft Limited Production DURSA submitted to Federal clearance

» July – November 2009 – Comments resolved, executable version of DURSA prepared and agreement approved by Nationwide Health Information Network Cooperative

» November 2009 – Submitted to clearance for approval and signature

» August 2010 – Draft Restatement I of the DURSA submitted to first round of Federal clearance

» May 2011

• 10 full signatories to November 2009 version (15 others signed but still in application/onboarding)

• Restatement I of the DURSA submitted to second round of Federal clearance for signature

3

DURSA Development

» Initially facilitated by ONC through Trial Implementation contracts in close coordination with HHS OGC

» Intensive effort to develop agreement using consensus process with legal, privacy, security and program representatives from diverse group (Cooperative):

• 9 Private entities

• 4 State entities

• 9 Federal entities

» Multiple rounds of Federal clearance processes (VA, SSA, HHS, DoD) and reconciled cross-agency issues

» Coordinated with and obtained input from Office for Civil Rights

» On-going maintenance of the DURSA under the direction of the Coordinating Committee in close coordination with ONC

4

Data Use and Reciprocal Support Agreement (DURSA)

KEY PROVISIONS OF THE DURSA

Unchanged Provisions

» The following slides provide a briefing on the Key Provisions of the DURSA that have remained substantively unchanged from the 11/09 DURSA to the 5/11 Restatement I of the DURSA.

5

Participants in Production (unchanged)

» The DURSA expressly assumes that each Participant is in “production” and, as a result, already has in place trust agreements with or written policies applicable to its agents, employees and data connections (end users, data suppliers, systems, and networks, etc.)

These trust agreements and policies must include terms necessary to support the trust framework memorialized in the DURSA.

*This remains unchanged in the 5/11 Restatement I of the DURSA.6

Applicable Law (unchanged)

» The DURSA reaffirms each Participant’s obligation to comply with “Applicable Law.” As defined in the DURSA, “Applicable Law” is the law of the jurisdiction in which the Participant operates.

• For non-Federal Participants, this means the law in the state(s) in which the Participant operates and any applicable Federal law.

• For Federal Participants, this means applicable Federal law.

*This remains unchanged in the 5/11 Restatement I of the DURSA.7

Privacy and Security Obligations (unchanged)

» 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 provisions as a contractual standard of performance.

*This remains unchanged in the 5/11 Restatement I of the DURSA.8

Duty to Respond (unchanged)

» Participants that allow their respective end users to request data for treatment purposes have a duty to respond to requests for data for treatment purposes.

» This duty to respond means that if actual data is not sent in response, the Participant will at a minimum send a standardized response to the requesting Participant.

» Participants are permitted, but not required, to respond to all other (non-treatment) requests.

» The DURSA does not require a Participant to disclose data when such a disclosure would conflict with Applicable Law.

*This remains unchanged in the 5/11 Restatement I of the DURSA.9

Future Use of Data (unchanged)

» Once the Participant or Participant’s end user receives data from another Participant (i.e. a copy of the other Participant’s records), the recipient may incorporate that data into its records and retain that information in accordance with the recipient’s record retention policies and procedures.

» The recipient can re-use and re-disclose that data in accordance with all applicable law and the agreements between a Participant and its end users.

*This remains unchanged in the 5/11 Restatement I of the DURSA.10

Autonomy Principle (unchanged)

» Participants apply their local policies to determine whether and how to transact data.

» This concept is called the “autonomy principle” because each Participant can apply its own local access policies before requesting data from other Participants, releasing data to other Participants, or otherwise transacting data.

*This remains unchanged in the 5/11 Restatement I of the DURSA.11

Breach Notification (unchanged)

» “Breach” is defined in the DURSA as the “unauthorized acquisition, access, disclosure, or use of Message Content while Transacting such Message Content pursuant to this Agreement.”

» Participants are required to notify the Coordinating Committee and other impacted Participants of suspected Breaches within 1 hour.

» Within 24 hours of confirming a Breach, Participants must provide a Notification to the Coordinating Committee, take steps to mitigate the Breach and implement corrective action plans to prevent such Breaches from occurring in the future.

» 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 and the Coordinating Committee when Breaches occur to facilitate an appropriate response.

*This remains unchanged in the 5/11 Restatement I of the DURSA.12

Mandatory Non-Binding Dispute Resolution (unchanged)

» Because the disputes that may arise between Participants will be relatively complex and unique, the Participants are required to participate in the dispute resolution process but are still free to pursue legal remedies if they are not satisfied with the outcome of the dispute resolution process. 

» Multi-step process

• Informal Conference between the Participants involved in the dispute

• If not resolved through the Informal Conference, the Dispute Resolution Subcommittee hears the dispute and is encouraged to develop an appropriate and equitable resolution

• Coordinating Committee can review the Subcommittee’s recommendation, if requested by any Participant involved in the dispute, and issue its own resolution

*This remains unchanged in the 5/11 Restatement I of the DURSA.13

Allocation of Liability Risk (unchanged)

» The DURSA contains a number of representations, warranties and disclaimers that have not changes.

» With respect to liability, the DURSA articulates the Participants’ understanding that each Participant is responsible for its own acts or omissions and not for the acts or omissions of any other Participant.

» If a Participant allows a User to improperly access Message Content and another Participant is harmed as a result then the Participant who allows that access may be liable. However, the DURSA explicitly recognizes that a Participant cannot bring a cause of action against another Participant where the cause of action is prohibited by Applicable Law.

» This section is not intended as a hold harmless or indemnification provision.

*This remains unchanged in the 5/11 Restatement I of the DURSA.14

Data Use and Reciprocal Support Agreement (DURSA)

KEY PROVISIONS OF THE DURSA

Amended Provisions

» The following slides provide a briefing on the Key Provisions of the DURSA that have changed from the 11/09 DURSA to the 5/11 Restatement I of the DURSA.

15

DURSA Amendments

» The following slides provide a briefing on the Key Provisions of the DURSA that have been approved by the CC as amendments to the DURSA and will be re-submitted to federal clearance in the 5/11 Restatement I of the DURSA

» Each slides provides:• The original 11/09 DURSA provision• An explanation of the issue with the 11/09 DURSA provision• The resolution of the issue in the 5/11 Restatement I of the DURSA

16

Use of the Term “NHIN” (amended)

11/09 DURSATerm “NHIN” is used to refer to the activity in which the Participants are engaged

IssueONC has defined the “Nationwide Health Information Network” more broadly and is phasing out its use altogether

ResolutionAll references to “NHIN” were either removed, or replaced with “Network” or some variation of “transacting Message Content,” depending on which resolution is appropriate

17

Coordinating Committee and Technical Committee Roles (amended)

11/09 DURSAThe Coordinating Committee is responsible for breach notification; dispute resolution; Participant membership, suspension and termination; and adopting Operating Policies and Procedures.

The Technical Committee is responsible for determining priorities for the NHIN; and creating and adopting specifications and test approaches.

IssueThe description of the Technical Committee’s responsibilities is no longer accurate and the division of responsibilities between the Technical Committee and Coordinating Committee is not efficient or scalable.

Resolution» Technical Committee functions will be consolidated under the Coordinating Committee. » The Coordinating Committee will be responsible for most of its original duties plus the following:

• Evaluating, prioritizing and adopting new and revised Performance and Service Specifications and Validation Plans for the Participants;

• Maintaining a process for managing versions of the Performance and Service Specifications for the Participants, including migration planning;

• Evaluating requests for the introduction of Emergent Specifications into the production environment used by the Participants; and

• Coordinating with ONC to help ensure the interoperability of the Performance and Service Specification with other health information exchange initiatives.

18

Coordinating Committee Composition (amended)

11/09 DURSA» The Coordinating Committee is composed of

• a representative of each Participant,

• a representative of each organization with an approved Definitive Plan,

• 2 representatives appointed by the Cooperative, and

• 1 ONC representative.

IssueThe current composition is not scalable given the rapid growth in the number and type of Participants.

Resolution» The Coordinating Committee will be composed of

• 1 representative from each of the 10 Charter Participants,

• 1 representative selected by each Affiliation Group, and

• 1 representative from ONC.19

Coordinating Committee Composition (amended)

» Affiliation Groups• All those Non-Federal Participants who are eligible to Transact

Message Content in connection with a contract, grant or cooperative agreement issued by the same Federal agency– Beacon Communities and State HIEs would be one “Affiliation

Group” because of their contracts and agreements with ONC• A Federal Participant and those Non-Federal Participants who are

Transacting Message Content with it– SSA and all of its awardees– VA, DoD and the non-Federal Participants participating in

VLER• A Non-Federal Participant may be in more than one Affiliation

Group

20

Permitted Purposes (amended)

11/09 DURSAParticipant’s end users may only request data through the NHIN for “Permitted Purposes” which include treatment, payment, limited health care operations with respect to the patient that is the subject of the data request, specific public health activities, quality reporting for “meaningful use” and disclosures based on an authorization from the individual.

IssueCurrent definition is focused on query/retrieve model of data exchange, but the Participants may engage in other data exchange models (e.g. “push,” publish/subscribe, routing).

ResolutionRevise the Permitted Purposes to support varied types of transactions and not preclude legitimate reasons to transact Message Content including treatment, payment, limited healthcare operations with respect to the patient that is the subject of the data being exchanged, public health activities, meaningful use and disclosures based on an authorization from the individual

21

Identity Proofing and Truthful Assertions (amended)

11/09 DURSADoes not specifically require Participants to “identity proof” their Users or explicitly require a Participant to submit truthful information in the assertions and statements that accompany a Message (e.g. SAML assertion). At the time, it was assumed that these issues would be addressed in the Specifications.

IssueBest practices for security and trust require identity proofing. These are not addressed in the specifications.

ResolutionEach Participant is required to (i) validate information about its Users prior to issuing the User credentials; (ii) use the credentials to verify the identity of its Users before enabling the User to transact Message Content; and (iii) provide truthful assertions.

22

Duties of Submitters (amended)

11/09 DURSAIncludes specific provisions related to the duties of a “requestor” and a “responder”

Issue» Focused on query/retrieve model of data exchange with responsibilities of the

“requestor” and “responder”» Participants may engage in other data exchange models that do not involve “requestors”

and “responders” (e.g. “push,” publish/subscribe, routing).

Resolution» Combine duties of a responder and requestor into duties of a Submitter (any Participant

or Participant User that submits a Message to another Participant)• Messages must comply with Applicable Law, the DURSA, OP&P, applicable

Performance and Service Specifications• Submitter must represent that all assertions or statements related to the submitted

Message are true and accurate• It is the responsibility of the Submitter – 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.

• When a request is based on a purpose for which authorization is required under HIPAA (e.g. for SSA benefits determination), the requesting Participant must send a copy of the authorization with the request for data. Requesting Participants are not obligated to send a copy of an authorization or consent when requesting data for treatment purposes.

23

Compliance with Technical Specifications (amended)

11/09 DURSARequires all Participants to comply with all Specifications

IssueLimited flexibility with respect to a Participant’s ability to choose which Transaction Pattern(s) it will implement and maintain

Resolution» Allow each Participant to identify the Transaction Pattern(s) that it will

support but require each Participant to support at least one Transaction Pattern.

» For each Transaction Pattern it supports, the Participant will choose whether it will be a Submitter, a Recipient or both.

» Require the Participant to only comply with the Specifications associated with the supported Transaction Pattern(s).

» Require all Participants to comply with the mandatory set of Specifications.

24

Voluntary Suspension by a Participant (amended)

11/09 DURSA» Participant can voluntarily suspend participation by giving the Coordinating Committee at least 24

hours notice » Coordinating Committee suspends the Participant’s digital credentials» Voluntary suspension cannot last longer than 5 business days without approval from the

Coordinating Committee

IssueProcess is unintentionally onerous based on actual experience and does not reflect best practices

Resolution» Removed the 24 hour notice from the DURSA and put the notice process in an OP&P so the

Coordinating Committee can change it as conditions change to maintain the scalability of the process

» Participant agrees not to transact data during the period of its suspension but its digital credentials are not suspended

» Increased from 5 to 10 days the amount of time that a Participant can voluntarily suspend without requiring approval from the Coordinating Committee

25

Operating Policies and Procedures (amended)

11/09 DURSARequires 2/3 of non-governmental and 2/3 of governmental Participants to approve all changes to the OP&Ps

IssueProcess has proven itself inefficient and has impeded the Coordinating Committee’s ability to revise the Operating Policies and Procedures

Resolution» Prior to approving new OP&Ps, Coordinating Committee will solicit comments

from the Participants» 30 day objection period once the Coordinating Committee approves new or

amended OP&Ps» New or amended OP&Ps go into effect unless 1/3 of the Participants object» If 1/3 object, then 2/3 of non-governmental and 2/3 of governmental Participants

must approve before the new or amended OP&Ps become effective

26

Performance and Service Specifications (amended)

11/09 DURSAApproval of new or amended Performance and Service Specifications requires the Coordinating Committee to make a determination of “materiality,” which then dictates the Technical Committee’s process of approving the Spec change.

IssueProcess has proven itself inefficient and has impeded the ability to amend the Performance and Service Specifications and adopt new Performance and Service Specifications

Resolution» Since the Coordinating Committee will now adopt new and amended

Performance and Service Specifications, the “materiality” determination is no longer necessary

» Approve new and amended Performance and Service Specifications in the same way that new and amended OP&Ps are approved (see slide 29)

27

For More Information

For more information see:

www.nationalehealth.org/exchange

28