Sharing a Clinical Abstract: Privacy Considerations in Minnesota

1. Findings from AHRQ’s State Privacy & Security Projects Sharing a Clinical Abstract: Privacy Considerations in Minnesota Donald P. Connelly, MD, PhD Daniel T. Routhe, BBA University of Minnesota AHRQ 2007 Annual Meeting September 27, 2007

2. Overview • What does our project aim to do? • HIE and Minnesota’s patient privacy context • Minnesota’s HISPC work - MPSP • Changes in MN privacy laws that facilitate our work • Adopting MPSP’s privacy & security principles • Lessons learned

3. Our Response to AHRQ’s invitation • Focus: fill information gaps that occur at care transitions • Patients presenting to ED • Patients moving from one provider organization to another • Partners: Allina, HealthPartners, Fairview Health Services • How: deliver a clinical record abstract near the point of care • Leverage partners’ use of a common EHR vendor • Use a federated model of contributing clinical databases not a centralized one • Use evolving national standards

4. Information Gaps in the ED • Gaps are frequent - 32% of visits • Gaps are consequential • Very important or essential 48% • Somewhat important 32% • Prolong the ED stay • Increase costs • Redundant testing & repeated MD assessments Stiell A et al. CMAJ 2003; 169:1023-8.

5. Rationale for sharing an abstract instead of the entire record • Contents are bounded & defined • A better first step for a public wary of confidentiality breaches • Patients “get it.” They understand the value of a concise clinical abstract for themselves and their providers • Avoiding sensitive content means easier consenting & wider use • While not the entire record, clinicians endorse the abstract as having high clinical value • The abstract’s succinctness is preferred by some emergency room physicians • Interoperability across vendor platforms should be easier

6. “My Emergency Data” Abstract • Patient Information • Contact Information • Primary Care MD & Clinic • Advance Directives • Current Problem List • Current Medications • Allergies • Immunizations • Surgical History • Family Medical History • Alcohol and Tobacco use

7. MyChart HealthPartners Username 1 Password 1 Level 1 – MyChart Access Buffalo Hospital ER (Allina) (Enrolled in a HealthPartners Clinic) MyChart Fairview My Em. Data …… …… …… …… …… …… …… …… ……

8. What we’ve learned so far: Level 1 • MyChart enrollment rate is too low to yield enough heart failure patients for our analysis • An opt-in strategy greatly limits impact • An opt-in strategy tends to exclude the elderly with multiple chronic illnesses – the very group which may benefit the most • MyChart hasn’t integrated well into ED workflow • Too few hits in ED to ensure good workflow integration or reliable use • Login names and passwords are not uppermost in patients’ minds in urgent situations • ED not equipped to provide keyboard access to patients

9. Level 2 – Direct Health Information Exchange Buffalo Hospital ER Allina Epic EHR HealthPartners Pt Identifier (Enrolled in a HealthPartners Clinic) Epic EHR Allina Hosp & Clinics Standards compliant Clinical message Pt Identifier Epic EHR Fairview Review & Incorporate Standards compliant Clinical message

10. Minnesota Privacy and Security Project (MPSP) • Minnesota’s component of the Health Information Security and Privacy Collaboration (HISPC) • We participated • in the oversight committee • in the Privacy & 4A work groups • MPSP Minnesota law changes effective July 1 • We’re adopting key principles put forth in the MPSP report

11. MPSP Privacy Workgroup activities • A systematic review of the state’s privacy laws & practices to determine their impact on the electronic exchange of health data • Electronic exchange barriers identified: • Undefined and ambiguous terms in our law • Current laws are set up for paper exchange • Need to update Minnesota consent requirements to facilitate electronic exchange while retaining patient empowerment

12. 2007 Revisions to Minnesota Health Records Act • Major revisions in the Health and Human Services Omnibus bill: • Improve readability • Refine or add definitions for: • Health record • Medical emergency • Related health care entity • Identifying health data • Record locator service • Representation of consent • Liability and responsibility around disclosure clarified • Information requirements for auditing exchanges

13. Record Locator Service (RLS) • An electronic index of patient identifying information that directs providers in a health information exchange to the location of patient health records held by providers and group purchasers. • Providers may construct an RLS without patient consent • Providers must obtain patient consent to access a patient’s health record

14. RLS Privacy Protections • Allows multiple groups of providers to create a RLS • Only providers may access information in a RLS • The Minnesota Department of Health cannot access/receive information from a RLS • Providers must enable patients to completely opt-out of the RLS during the consent process • An exchange that uses a RLS must maintain audit logs tracking access to patient health records

15. Minnesota’s patient consent requirements • Patient consent is required for nearly all disclosures, including treatment • Limited exception to consent requirement • Medical emergency • Record movement within “related” health care entities • Written consent (signed & dated) is required • Consent generally expires in one year • Or … a representation from a provider that holds a signed and dated consent from the patient authorizing the release

16. Representation of consent protections • Only a provider may request a patient’s health record using a representation of consent. • The requesting provider must have, in possession, a signed and dated consent from the patient. • The releasing entity must document: • identity of the requesting provider • identity of the patient • records requested/provided • date of the request

17. Liability and responsibilities for disclosure now addressed • Prior MN law placed all liability for inappropriate disclosure on disclosing provider • Responsibilities are now defined for the patient, the requestor, and the discloser • Each party warrants no information known to the person to be false • Requestor accurately states the patient's desire to have health records disclosed or that there is specific authorization in law • Requestor & discloser do not exceed any limits imposed by the patient in the consent • Discloser has complied with the legal requirements regarding disclosure of health records

18. Applying MPSP’s security & privacy principles is ongoing • Concentrating on 4A’s principles • Data to be captured in audit logs • Limit access requests to patients being treated and information relevant to that treatment • Develop & accept • written policies and procedures for participating in the exchange • security credentialing guidelines for authorizing individuals to access health information through the exchange • minimum standards for routine auditing of individuals’ access through the exchange

19. Lessons learned • Attention to privacy concerns pays off • Law evolves too – get involved • Continuing opportunities • Conforming our exchange’s “rules of the road” to Minnesota law • Contributing to Minnesota’s universal consent form due in January 2008 • Avoiding burden to providers in neighboring states while conforming to our state’s laws

20. Acknowledgements • The many dedicated and committed participants from • Allina Hospitals and Clinics • Fairview Health Services • HealthPartners • University of Minnesota • Our project’s Board members • Jim Golden, MDH • AHRQ This project was funded in part under Grant Number UC1 HS016155 from the Agency of Healthcare Research and quality, US Department of Health and Human Services.