# Presentation: 833737

## Connecting for Health Common Framework:Resources for Implementing Secure Health Information ExchangeAHRQ Resource Center for Health Information TechnologyNational Teleconference, July 25th 2006

## Overview of the Common Framework

- AHRQ National Resource Center HIT Webconference
- July 25, 2006

**Lygeia Ricciardi**
**Director, Health**
**Markle Foundation**

## What is Connecting for Health?

- A public-private collaborative of 100+ organizations representing all the points of view in healthcare.
- A neutral forum.
- Founded & supported by the Markle Foundation
- Additional support from the Robert Wood Johnson Foundation

## What is the Purpose of Connecting for Health?

*	**To catalyze changes on a national basis to create an interconnected, electronic health information infrastructure to support better health and healthcare*

## Healthcare is Unique

- The healthcare system is very diverse
- Health information is especially sensitive—and privacy spills can’t be “fixed”
- Patients/consumers are traditionally less involved than in some other areas

## Some Barriers to Electronic Information Sharing in Health

- Technical (e.g. lack of standards)
- Policy (e.g. lack or incompatibility of rules about who is allowed to see information and why)
- Financial (e.g. misalignment of incentives for IT adoption)
- Educational (e.g. lack of understanding of the benefits and risks of IT)
- ... and the technology is the *easy* part!

## Sharing Health Information = Linking Existing Sources 

- Health information can *stay where it is—*with the doctors and others who created it
- Specific information is shared *only* when and where it is needed.
- Sharing *does not* require an all new “network” or infrastructure
- Sharing *does not* require a central database or a national ID
- Sharing *does* require a Common Framework

## A Common Framework Is Needed  

- The Common Framework is the minimum necessary set of rules or protocols for *everyone* who shares health information to follow.
- Helps organizations overcome the barriers without “reinventing the wheel”
- Enables nationwide interoperability...avoiding isolated islands of information
- Builds *trust*

## The Common Framework

- 	Is like a nationwide set of traffic rules that enable specific pieces of health information to travel when and where they are needed...

## The Common Framework

-    ...and that put patients and the doctors they trust in the drivers’ seat.

## GET

**GET**

**SEND**

- Source: © 2004 The Markle Foundation   Graphic adapted from Tom Benthin original.

**De-Identified****Data**

**Reporting**
**Router**

**Message**
**Transfer**

**FIND**

**Patient Index**

**Provider asks if there are records for his/her patient**

**Index sends****location of****any records**

**Source****sends index****information**

**LOCATOR**

**Provider asks****for and receives records**

**Records****are sent to Provider**

**TING**

**Source may push data for reporting**

**REPOR**

**Data**
**Sources**

**Patients**

**Providers**

**Hospitals**

**Diagnostic**
**Services**

**Payors**

**Public Health****Providers**

**DATA**

**Individual**
**Care**
**Providers**

**Patients**

**Providers**

**Hospitals**

**Diagnostic**
**Services**

**Payors**

**Public Health****Providers**

**Public**
**Health**

## What Do the Common Framework Resources Consist of? 

- Technical rules and standards—that allow systems to “talk to” each other
- Policies on how to handle information– that build *trust*
- Model contractual language—that holds it all together

## Technology and Policy are Intertwined

- Choices about one necessarily shape the other.
- To build trust, you have to put policy decisions first.

## Slide 14

## Sample Policy Documents

- Sample Policy Documents

*From P8 – Breaches, p. 4*

*Sample policy language*

*CFH Recommended policy*

*From M2 – Model Contract, p. 10*

## Sample Technical Documents (T2)

## The Common Framework is Not a “RHIO in a box”

- It provides different models to consider—not one “right answer.”
- It is intended as a partial solution. It does not address finance, governance, etc.
- There are topics (like how to aggregate data for research and public health) that Connecting for Health is still working on...

## How Was the Common Framework Developed?

- Connecting for Health...
- Started with Design Principles
- Wrote a Roadmap
- Built a Prototype
- Developed the Common Framework through field experience and the collaboration of experts

## Technical Principles

- Make it “Thin”
- Avoid “Rip and Replace”
- Separate Applications from the Network
- Decentralization
- Federation
- Flexibility
- Privacy and Security
- Accuracy

## Privacy Principles

- Openness and Transparency
- Purpose Specification and Minimization
- Collection Limitation
- Use Limitation
- Individual Participation and Control
- Data Integrity and Quality
- Security Safeguards and Controls
- Accountability and Oversight
- Remedies

## The Roadmap Report

- Laid out the vision in 2004
- More than 60K copies in circulation

## The Prototype

- Three sites
- Boston
- Indianapolis
- Mendocino County, CA
- Diverse architectures
- Diverse structures
*If these 3 can all use the Common Framework...anyone can!*

## Who Developed the Prototype and the Common Framework?

- Connecting for Health Steering Group
- Policy Subcommittee: Co-Chairs Bill Braithwaite and Mark Frisse
- Technical Subcommittee:  Chair: Clay Shirky
- Three communities and teams:
**Boston**: MA-SHARE and technical partner CSC
**Indianapolis**: Regenstrief Institute and Indianapolis Health Information Exchange (IHIE)
**Mendocino**:  Mendocino HRE and technical partner Browsersoft, Inc.

## What is Available?

**Technical Documentation: 3 Categories**
- _Background Documents_
- T6: Record Locator Service Design
- T5: Data “Cleanliness” and Quality
- _Specific Technical Documents_
- T1: Technical Overview and Implementation Requirements
- T2: NHIN Message Implementation Guide (Record Locator Service/Inter-SNO Bridge)
- T3-T4: Standards Guides
- Medication History: Adapted NCPDP SCRIPT
- Laboratory Results: ELINCS 2.0, with modifications
- _Technical Code and Interfaces_
- Test Interfaces: CA, IN, MA
- Code base: CA, IN, MA

## What is Available?

**Policy Documents: 3 Categories**
- _Background Document _
- P1:  Privacy Architecture for a Networked Health Care Environment
- _Specific Policy Documents_
- P2-P8: Model privacy policies, notification and consent, correctly matching, authentication, patient access, audits, and breaches
- _Sample Contract Language_
- M1: Contact Topic List
- M2: Model Contract

## The Common Framework is Still Evolving

- Improving the resources to better meet the needs of communities
- Exploring how patients/consumers can access their own information
- Exploring how researchers and public health can benefit from health data
- Connecting for Health needs the input of organizations nationwide....

## Common Framework Resources

- All available free at _[www.connectingforhealth.org](http://www.connectingforhealth.org/)_
- Policy and technical guides, model contractual language
- Registration for AHRQ/NORC Common Framework discussion forum
- Software code from regional prototype sites:  Regenstrief, MAShare, OpenHRE
- Email to _[info@markle.org](mailto:info@markle.org)__ _

## Technical Overview of the Common Framework

- National Resource Center
- Agency for Healthcare Research and Quality

- J. Marc Overhage, MD, PhD
- Regenstrief Institute
- Indiana University School of Medicine
- Indiana  Health Information Exchange

## Architecture is Federated and Decentralized: Once records are located, the health information flows peer-to-peer – with patient’s authorization

## The architecture supports point of care information sharing and population-based reporting

## The Connecting for Health Model for Health Information Sharing

- Sharing occurs via a network of networks (National Health Information Network) — not a completely new architecture
- The nationwide “network” is made up of smaller community networks or SNOs (Sub Network Organizations)
- Each SNO has an RLS (Record Locator Service) to locate patient records
- SNOs are interconnected through ISBs (Inter-SNO Bridges)

## NHIN: Network of Networks

- National Health Information *Network*, not National Health Information *Database*
- Bad Tradeoff: 1000x Searches for 0.1 to 0.01 increase
- No “Top Level” Query
- Privacy
- Security
- Patient Trust
- Source of Truth
- Data Cleanliness
- Queries Must Be Targeted/No Fishing
- Built On Lines of Actual Human Trust

## What is a SNO?

- A group of entities (regional or non-regional) that agree to share information with each other
- Implements the Common Framework
- Provides an ISB for all external traffic
- Runs an RLS internally

**Notes:**
Some more detailed definitions FYI:

Entity: An entity refers to functionally independent participants within the health care system, from single doctor practices up to hospital chains and national organizations, whether public or private. An entity is any organization, institution, or practice; the only parts of the health care system that are not entities are the patients themselves. 

SNO: A SNO is any group of entities (regionally or non-regionally defined) that agree to communicate clinical data with one another using a single Record Locator Service (RLS), using shared policies and technological standards, and operating together under a single SNO-wide set of policies and contractual agreements.  A SNO has two sets of interfaces, one internal, which binds its member entities together, and one external, which is where traffic to and from other SNOs and outside entities come from. Examples of non-regionally-organized SNOs include the VA and RxHub.

## What is a Record Locator Service (RLS)?

- Like a phone book listing locations of information
- Contains no clinical information
- Only authorized participants can access it
- Obtaining the actual clinical record is a separate transaction not involving RLS

## What is a Inter-SNO Bridge (ISB)?

- Software that provides the interfaces that define a SNO
- Provides essential services

## How Multiple SNOs Connect to Form NHIN

- A SNO queries other SNOs when it knows:
- An institution where the patient received care
- A region where the patient received care
- Same query formatted for all remote SNOs
- Only need location of
-    ISBs

## Underlying Technologies

- TCP/IP
- SOAP
- Web Services
- HL7/NCPDP messaging standards
- LOINC codes
- NDC codes

## Security / Confidentiality

- Server-to-server (ISB-to-ISB) authentication via X.509 certificates
- Communication protected by SSL/TLS
- Federated identity based on single token authentication in edge systems
- Role based/level based access control

## Prototype SNOs reflect the realities of existing market and health IT variation

|  | IHIE | MA-SHARE | Mendocino HRE |
| --- | --- | --- | --- |
| Market | Mixed urban and rural; dominant academic anchor (IU) | Urban mix of academic, community and commercial influences | Rural and underserved community medicine and health centers |
| RHIO-related history | 35+ years | 25+ years | 7 years |
| Technology partner | Regenstrief (academic not-for-profit) | CSC (large commercial) | Browsersoft (small commercial) |
| Development preference | J2EE | Microsoft .NET | Mixed Open Source |
| Overall architecture | Central data repository with standardized data | Federated, with shared Record Locator Service | Brokered through mirrored data at central HRE |
| Standards | Significant investment in HL7 2.x | Implementing HL7 3.0; investigating XDS | “Bi-lingual”
(HL7 2.x and 3.0) |

## Prototype Approaches

**Community-level registries**

**HL7 Update Services**

**MPI / RLS Service**

**Clinical Data**

**Auth / Access Control Service (AACS)**

**Record Exchange Service (RES)**

**Registries, Audit, etc.**

**Mirrored Clinical Data**

- _Mendocino_
- Developed RLS and ISB
- Source systems send data to HRE for hostingin native form with on demand transformation

**= New “NHIN” functionality**

**IHIE / INPC (at Regenstrief)**

**Supported by  Browsersoft, Inc. (OpenHRE)**

**RLS**

**InterSNO Bridge**

**Hosted by  CSC**

**CDX Gateway (serving as InterSNO Bridge)**

**RLS**

**INPC Disburser / Aggregator (serving as InterSNO Bridge)**

**IN Cancer Registry**

**St. Francis**

**St. Vincent**

**Wishard**

**IU Medical Group**

**Community Hospitals**

**Clarian**

**Indiana Medicaid**

**Indiana ****DPH**

**Beth Israel Deaconess**

**Boston Medical Ctr.**

**AEGIS**** (public health)**

- _Massachusetts_
- Adapted its CDX Gateway as front-end to the RLS and ISB
- Distributed CDX Gateways fetch source data on demand from participant sites

**UVPMCG**

**Ukiah Valley Medical Ctr.**

**Consolidated Tribal Health**

- _Indiana _
- Developed Disburser / Aggregator for ISB
- Adapted existing MPI for RLS
- Source systems send data to hosted HL7 Update Services for transformation and hosting in standard form

## Policies for Information Sharing

- AHRQ National Resource Center HIT Webconference
- July 25, 2006

**Melissa M. Goldstein**
**Director, Health**
**Markle Foundation**

## About 40 experts in
Law
Health privacy and ethics
Health care delivery
Administration
Technology
Local network development (RHIOs)

- Law
- Health privacy and ethics
- Health care delivery
- Administration
- Technology
- Local network development (RHIOs)

- Connecting for Health Policy Subcommittee

## Looked at HIE in the context of HIPAA and existing state laws
Developed a list of significant topics from
Members’ experience with early information exchange networks 
Members’ own expertise

- Developed a list of significant topics from
- Members’ experience with early information exchange networks
- Members’ own expertise

- Connecting for Health Policy Subcommittee

## Who has access to what, under what circumstances, and with what protections?
Who shares what and who bears the liability?
How can you control access to your information? 

- Who shares what and who bears the liability?
- How can you control access to your information?

- Challenges

## Develop a policy framework
Identify what needs to be common for interoperability and what does not
Design and develop a working guide

- Identify _what needs to be_ common for interoperability and what does not
- Design and develop a working guide

- Connecting for Health Goals

## What is the Common Framework?

- A set of critical tools, including technical standards and policies for how information is handled, whose general adoption will enable secure nationwide health information sharing
- Contractual arrangements among members of communities (or SNOs) are a key to implementation

## Overview of Connecting for Health Architecture

- A sub-network organization (SNO) brings together a number of providers and other health information sources
- They are linked together by contract
- Agree to follow common policies and procedures
- Agree to create and use a shared index to where patient records are located (RLS)
- Agree to create and use a common gateway to share information with other networks (ISB)

## An index containing patient demographic information and the location of a patient’s medical records
Contains no clinical information – obtaining the clinical record is a separate transaction NOT involving the RLS
Participating entities decide whether or not to put record locations into the RLS
Designed to take a query in the form of demographic details and return only the location of matching records

- Contains _no_ clinical information – obtaining the clinical record is a separate transaction NOT involving the RLS
- Participating entities decide whether or not to put record locations into the RLS
- Designed to take a query in the form of demographic details and return only the _location_ of matching records

- What is a Record Locator Service (RLS)?

## Slide 49

## Connecting for Health: Privacy Principles

- Openness and Transparency
- Purpose Specification and Minimization
- Collection Limitation
- Use Limitation
- Individual Participation and Control
- Data Integrity and Quality
- Security Safeguards and Controls
- Accountability and Oversight
- Remedies

## The Privacy Principles are Interdependent 

- Openness

- Purpose Specification

- Collection Limitation

- Use Limitation

- Individual Participation and Control

- Remedies

- Accountability

- Security

- Data Integrity

- The Privacy Principles are Interdependent

## To be used in conjunction with the Model Contract for Health Information Exchange
Establish baseline privacy protections – participants can follow more protective practices
Based on HIPAA, although some policies offer greater privacy protections
Rooted in nine privacy principles
Should be customized to reflect participants’ circumstances and state laws

- Establish baseline privacy protections – participants can follow more protective practices
- Based on HIPAA, although some policies offer greater privacy protections
- Rooted in nine privacy principles
- Should be customized to reflect participants’ circumstances and state laws

- Model Privacy Policies and Procedures

## Model Contract for Health Information Exchange  

- Purpose of Model SNO Terms and Conditions
- To assist SNOs prepare their own Terms and Conditions
- 60-40 solution
- Identify issues and alternatives
- Raise questions

## Model Contract: Essential Components 

- Incorporates applicable terms of Common Framework Policies and Procedures
- Provides specific terms that the individual SNO may determine are appropriate for its unique needs
- Includes mechanism for making and implementing changes

## Common Framework Policy Topics Addressed

- Notification and consent
- Patient access to their own information
- Breaches of confidential information

## Sample Policy Documents

- Sample Policy Documents

*From P8 – Breaches, p. 4*

*Sample policy language*

*CFH Recommended policy*

*From M2 – Model Contract, p. 10*

## Notification and Consent

- Inclusion of a person’s demographic information and the location of her medical records in the RLS raises privacy issues and issues regarding personal choice
- What should an institution participating in the RLS be required to do to inform patients and give them the ability to decide not to be listed in the RLS index?

## Involves issues of openness and transparency, and individuals’ participation and control over their own health information
Easy to fall into trap of opt-in/opt-out debate, but question is really about enabling individual choice 

- Easy to fall into trap of opt-in/opt-out debate, but question is really about enabling individual choice

- Notification and Consent

## Subcommittee recommendations are more protective of privacy than HIPAA – HIPAA is a floor but not always sufficient in this environment
Patient must be given notice that institution participates in RLS and provided opportunity to remove information from index
Revision of HIPAA Notice of Privacy Practices should reflect participation in RLS

- Patient must be given notice that institution participates in RLS and provided opportunity to remove information from index
- Revision of HIPAA Notice of Privacy Practices should reflect participation in RLS

- Notification and Consent: recommendations

## Notification and Consent

- Recommendations strike balance between burden on SNO participants, individual patient choice and control, and maximizing the benefits of a networked health information environment
- Encourages participation in system by engendering patient trust
- Separation of clinical record from locations included in the RLS add layer of privacy protection

## Patient Access

- Patients have a vital interest in accessing sensitive information about their own health care
- Enables informed choices about who should get such information, under what circumstances
- Facilitates awareness of errors that the records my contain
- Ability to effectively access personal health information could be significantly enhanced with the use of new technologies

## Patient Access

- How can we facilitate patients’ access to their own health information in health information exchange networks?
- Involves issues of openness and transparency and individual control of health information

## Patient Access

- HIPAA – the baseline
- Right to See, Copy, and Amend own health information
- Accounting for Disclosures
- Covered entities required to follow both Privacy Rule and related state laws
- Allows stronger privacy safeguards at state level

## Patient Access

- As a matter of principle, patients should be able to access the RLS.
- Access will empower patients to be more informed and active in their care
- However, significant privacy and security concerns exist regarding giving patients direct access at this stage

## Patient access to the information in the RLS
Each SNO should have a formal process through which information in the RLS can be requested by a patient or on a patient’s behalf
Participants and SNOs shall consider and work towards providing patients direct, secure access to the information about them in the RLS

- Each SNO should have a formal process through which information in the RLS can be requested by a patient or on a patient’s behalf
- Participants and SNOs shall consider and work towards providing patients direct, secure access to the information about them in the RLS

- Patient Access: recommendations

## Patient Access	

- Recommendations strike balance between current security and authentication challenges and principle that patients should have same access to their own information as health care providers do
- RLS could ultimately empower patients to access a reliable list of where their personal health information is stored

## Breaches of Confidential Health Information

- Networked health information environments include higher volumes of easily collected and shared health data – thereby increasing privacy risks
- Security experts assure us that breaches will occur in even the most secure environments

## What policies should a SNO have regarding breaches of confidentiality of patient data?
Involves issues of purpose specification, collection, and use of health information, accountability, and remedies
Who should be notified of breaches, and when?
Is breach a reason for a participant to withdraw from the SNO?  Should special rules for indemnification apply in the case of a breach?

- Involves issues of purpose specification, collection, and use of health information, accountability, and remedies
- Who should be notified of breaches, and when?
- Is breach a reason for a participant to withdraw from the SNO?  Should special rules for indemnification apply in the case of a breach?

- Breaches of Confidential Health Information

## Breaches of Confidential Health Information: recommendations

- SNO should comply with HIPAA Security Rule.  SNO Participants should comply with applicable federal, state, and local laws
- Responsibility of Participants to train personnel and enforce institutional confidentiality policies and disciplinary procedures

## SNO must report any breaches and/or security incidents.  SNO Participants must inform SNO of serious breaches of confidentiality
Participants and SNOs should work towards system that ensures affected patients are notified in the event of a breach

- Participants and SNOs should work towards system that ensures affected patients are notified in the event of a breach

- Breaches of Confidential Health Information: recommendations

## Breaches of Confidential Health Information: recommendations

- SNO contract could include provision allowing participant withdrawal from SNO in case of serious breach of patient data
- SNO contract could include indemnification provisions pertaining to breach of confidentiality of protected health information

## Breaches of Confidential Health Information

- Recommendations strike balance between levels of institutional and SNO responsibility for breaches and goal of notifying patients in the event of a breach
- Model language for SNO policies regarding breach is provided

## Common Framework Resources

- All available free at _[www.connectingforhealth.org](http://www.connectingforhealth.org/)_
- Policy and technical guides, model contractual language
- Registration for AHRQ/NORC Common Framework discussion forum
- Software code from regional prototype sites:  Regenstrief, MAShare, OpenHRE
- Email to _[info@markle.org](mailto:info@markle.org)__ _

## SW Tennessee’s experience in Using the Connecting for Health Framework Model Contract 

- AHRQ National Resource Center HIT Webconference
- July 25, 2006

**Vicki Estrin**
**Program Manager**
**Vanderbilt University**

## Where are we talking about? 

*All parties recognize that health care is regional and that a significant number of individuals seeking care in Tennessee are residents of one of the 8 bordering states*
*Note – There are other regional initiatives and state-wide HIT initiatives funded by HHS, AHRQ and  HRSA in the state*

## Project Summary

**Funding Sources**
- September 21, 2004, Tennessee received a 5 year contract/grant from Agency for Healthcare Research and Quality (AHRQ) - total award is $4.8 million
- State of Tennessee provided additional funds in the amount of $7.2 million for the same 5 year period
- MidSouth eHealth Alliance will receive additional funding from the state to fund operations (e.g. Executive Director and local support staff)

**Initial Participating Organizations**
- Baptist Memorial Health Care Corporation – 4 facilities
- Christ Community Health – (3 primary care clinics)
- Methodist Healthcare – 7 facilities including Le Bonheur Children’s Hospital
- The Regional Medical Center (The MED)
- Saint Francis Hospital & St. Francis Bartlett
- St. Jude Children’s Research Hospital
- Shelby County/Health Loop Clinics (11 primary care clinics)
- UT Medical Group (200+ clinicians)
- Memphis Managed Care-TLC (MCO)

**Vanderbilt’s Role**
- “Donated” the use of its technology for the project
- Serves the functions of Project Management Office and Health Information Service Provider
- Responsible for compliance with the AHRQ contract
- Also supports as requested other HIT activities across the state at a planning level

## Project Summary

- Planning August 2004 – January 2005
- Governor initiated planning effort in August 2004 to explore the effect of HIT on healthcare in Tennessee
- September 2004 awarded AHRQ Contract to be a State Regional Demonstration (SRD) project
- Planning effort re-focused primarily in the demonstration area of Shelby, Fayette and Tipton counties
- Detail Design and Implementation February 2005 – present
- Memorandum of Understanding and Business Associate Agreements
- Data feeds through secure VPN connection
- Test data started June 2005. Switch to production data August 2005
- October 1, 2005 demonstrated the ability to exchange 25% of core data elements.  System was not in use.
- Limited initial use in 1 emergency department (The MED) during weekday day shifts on May 23rd.  Shifted to 24/7 use on June 21st.
- Next site for initial use is targeted for August 22nd

## Organization and Governance	

- The MidSouth eHealth Alliance (MSeHA) – Organization responsible for the operations of a RHIO in the three counties
- Board was formed in February 2005
- Incorporated in August 2005- not-for-profit status in March 2006
- Plan to hire an executive director
- Board makes all final decisions on policy
- Current Structure: Work groups make recommendations to the board
- Privacy and Security
- Technical
- Clinical
- Financial
- Future Structure:  Operations Committee (a.k.a. Management Committee in Connecting for Health Framework) will be formed in August 2006 – initial membership will be the Privacy and Security Work Group.
- Function will be to review, educate, and advise the board on Policy and Procedure
- Board will continue to make all final decisions on policy

## Privacy and Security  Where the conflict began

- Technology was hard work but early on, one of the project principles was that policy would drive technology whenever possible
- In the planning effort we generated more questions than answers
- HIPAA was the easy part
- Never considered the legal fees in our budget
- Did not understand the magnitude of what we were attempting
- Privacy and Security Work group charted in June 2005 to support implementation efforts
- Members were told it was a 6 – 8 month commitment – *Now we see no end in sight*
- Group has grown to approximately 25 members and meets monthly for half a day with work done via conference call and e-mail in between
- First meeting, listed all the issues to tackle among them was the creation of a regional data exchange agreement AND everyone wanted to start there but...

## Our Approach to a Regional Data Exchange Agreement

- Mark Frisse was the co-chair of the Connecting for Health Policy for Information Sharing Sub-committee. He promised me that a model contract was in the works for a regional data sharing agreement
- We all agreed it made sense to wait for the model
- The Privacy and Security workgroup tackled a number of issues while we waited...turns out these needed to be tackled sooner than later anyway
- Who would have access to the MidSouth eHealth Alliance data?
- Would we allow a patient to “opt out” of the RHIO (or “RHIO Out” as we now call it)?
- Would we notify the patient in some way that their data was being shared?
- What would we audit and track?
- What policies do we need to have in place?
- Who will write policies?
- Etc.
- The dialogue and debate around these issues laid the foundation for an environment of trust where all views are considered viable and discussed openly

## Our Approach to a Regional Data Exchange Agreement

***Note:  June through August the workgroup focused on key policy issues.  This laid a foundation for trust and open dialogue.  When we began working on the Regional Data Exchange agreement, our overall approach was to do as much work as we possibly could without incurring legal fees***

## Once the Regional Data Exchange Agreement Draft was completed we thought we could relax ...

- WRONG!
- _All_ of the attorneys requested at a minimum a draft of the policies and procedures
- Not an unreasonable request given that the agreement makes a number of references to policies
- We immediately turned to the recently released Markle Framework...
- We created a minimum list of policies that the agreement required
- Used the Framework as a reference guide
- While the agreement was being reviewed, the work group spent two full days together working through policies.  In addition each organization had at least one person and usually two people working for several hours a week on the policies prior to the day long working meetings.

## Did the Connecting for Health Framework Help – You Bet It Did!

- Model Contract gave us framework to start work from
- It identified areas we needed to address in our agreement
- The language didn’t always flow for the members but it gave them an idea of what was intended
- It took several readings to digest the format, terms, etc.
- Initially, wrestled with the terms and definitions
- Model forced MSeHA board and work group to discuss all parties’ assumptions
- We kept most of the construct from the model although made a few deliberate changes
- Example: We have reference the license agreement but the MSeHA will sign a separate license agreement with Vanderbilt for software access
- The model did about 50 – 60 percent of the work for us by giving us the framework and example language in many cases from which to work
- It supported our goal/approach of engaging counsel later in the process
- The Model Policies gave us a benchmark to start with and sample language to start from

## Our Challenges

- Achieving agreement between all parties
- The model raises questions that only the community working through the agreement will be able to answer – *it doesn’t have all the answers – it has most of the questions *
- It is an educational process that requires deep understanding of the issues and the positions of all involved
- Getting 9+ attorneys to agree on one single document is never easy
- The framework once understood actually facilitated the agreement much quicker than anyone dared to believe was possible
- Time
- The agreement and policies were our last milestones to bringing the system up in a live environment
- All of the organizations donated a significant amount of resource time to work on the agreement and policies/procedures that support the agreement
- Money
- Never predicted the amount of legal fees we would incur
- Consciously brought the lawyers in only after we had discussed the areas of conflict and come to a common conclusion/decision

## Next Steps

- Document what we actually did using the Markle Model Contract and Framework as a benchmark
- Policies were written for initial use in the Emergency Department to keep focus and get the policies done; however, they need to be reviewed in a more methodical manner with a larger scope of use in mind.
- Have identified a set of Participant policies that need to be reviewed by each Participant before bringing the system live in the next organization
- Identify and bring up the next emergency department in August.  (The goal is to have five emergency departments using the system by first quarter of 2007.)

## Questions & Answers	

- For additional Common Framework resources, visit:
- 	_[www.connectingforhealth.org](http://www.connectingforhealth.org/)__ _
- For more information, visit AHRQ’s National Resource Center, which boasts links to more than 6,000 health IT tools, best practices, and published evidence online at _[http:healthit.ahrq.gov](http://www.healthit.ahrq.gov/)__. _