Privacy and Security Tiger Team

1. Privacy and Security Tiger Team Today’s Discussion: Query/Response Models for Health Information Exchange January 24, 2013

2. Agenda • Review & discuss progress to date, including key assumptions and preliminary consensus recommendations • Discuss outstanding topics • Additional background in backup slides: • DURSA evolution and requirements, • HIE practices, and • Results of PCAST WG discussions on similar issues. • Expectation is to wrap up the discussion during Q1 of CY13; this provides 6 meetings (including today) to discuss these topics

3. Issues • Previous Tiger Team recommendations assume a decision-maker at the receiving end of the query—and that the decisionmaker has discretion as to whether to provide the requested records or not. • The wording of the certification recommendation in the RFC also assumes a decisionmaker at the other end • Not clear that all query models leave room for this discretion. • A query model puts entities into a position of collecting information—HIPAA does not establish rules around collection (instead focuses on permitted uses and disclosures once the information has been collected)

4. Questions for Tiger Team • Are any revisions needed to previous Tiger Team recommendations on consent? • Does the Tiger Team want/need to make any comment around the intersection of the IEWG recommendations and the previous recommendations on consent?

5. Key Assumptions for Query Discussion (1 of 2) • The focus of this initial set of recommendations is on the most common use case involving adult patients and exchanges for treatmentin a query/response model. • This use case does not include queries for: • records on minors, personal representatives, and proxies, which will be handled in a separate discussion • highly sensitive health information, such as genetic, HIV, reproductive health, mental health, etc. Note: Indirect treatment relationships, in which the provider does not interact directly with the patient and only reviews records, should be considered in finalizing these recommendations.

6. Key Assumptions for Query Discussion (2 of 2) • Queries will take place in a trusted environment in which there is some mechanism in place to vet providers. Ways of establishing that this trust exists include: • Use of the DIRECT protocol to transmit information (participants have been identity proofed and issued a certificate) • Membership in a trusted network (participants have been identity proofed and authentication measures are in place), • Others?

7. Preliminary Consensus • Providers making a query for patient information for treatment purposes, must provide at least one of the following: • An attestation that the requesting provider has established (or is in the process of establishing) a treatment relationship with the subject patient or • An authorization from the patient. • Record holders should be provided a “safe harbor,” insulating them from legal liability from wrongful disclosure if the above conditions are met. • Providers are responsible for knowing and complying with the legal requirements governing these exchanges in their own jurisdictions

8. Additional Topics • Responsibilities of the data holder, including: • Responsibility to respond to queries • Content of response • Timeliness of response • Form of consent required, including the potential need for standard consent • Interstate queries and navigating varying legal requirements • Transparency/education • Responsibilities of provider making the request • Accounting for disclosures (audit trails)* *Coordinate with the Office of Civil Rights (OCR)

9. Back up slides

10. Background on DURSA Query Approach • The Data Use and Reciprocal Support Agreement (DURSA) is the trust agreement that all participants in the eHealth Exchange (formerly the NwHIN exchange) execute. • Key provisions (relate to query for treatment): • Participants must represent, among other things, that the request is for a permitted purpose and supported by legal authority. • Data requesters must submit copies of authorizations, as required. • Data holders are required to respond with either the record(s) or with a standard response that the information is not available or cannot be released; data holders have discretion over the release of information. (Nothing in this provision would require a disclosure contrary to any legal requirement.)

11. DURSA – Rationale for Provisions • Context for DURSA negotiations: • HIEs were in early stages of maturity • Agreement had to work across diverse entities; not an effort to create national policy • Providers (not payers) may query • Permitted uses focused on specific use cases (7 use cases identified by AHIC) • Treatment for subject individual, • Payment activities of the provider for the subject individual • Certain health care operations

12. DURSA – Rationale for Provisions • Permitted uses (continued) • Public health activities as permitted by law • Demonstration of meaningful use • Pursuant to an authorization provided by the individual or their personal representative • Responsibilities of participants • Established an expectation of reciprocity in exchange • Addressed concerns about queries being one-sided—providers querying but not responding to queries

13. HIE Practices (1 of 4) • Overall • HIEs generally use a record locator service (RLS) or similar • HIE user entities must sign and are bound by participation agreements that establish “rules” for query, and must vet their users • Who is permitted to query and for what purpose: • Considerable heterogeneity in approaches. • NE providers can query for treatment; payers can query for certain purposes such as prior authorization and claims processing. • ME providers can query for treatment only (an exception exists for certain limited types of healthcare operations transactions)

14. HIE Practices (2 of 4) How Patient Consent/Authorization is Handled: *Does not include 42 CFR Part 2 information.

15. HIE Practices (3 of 4) • Handling of highly sensitive information: • HealthInfoNet (ME) is working toward integrating sensitive information; it will be sequestered in a separate system. (State law created an opt-in for exchange of mental health and HIV information.) Will allow sharing among behavioral health and general medical providers. • NeHII (NE) contains no highly sensitive information; a separate exchange—electronic Behavioral Health Information Network (BHIN)—serves behavioral health facilities in parts of the state.

16. HIE Practices (4 of 4) • Audit trails • All indicated they had audit trails and actively review them • Some HIEs share audit trails with patients upon request (ME) • MN Department of Health has been mandated by their legislature to study the feasibility of providing audit logs from EHRs to patients; study due in February

17. Issues Raised by PCAST Work Group Similar issues discussed in the context of the proposed PCAST architecture: • Controls should be applied at the level of data categories, rather than at the data element (atomic) level • Concerns about over-exposure of patient data when querying a record locator service [data element access service (DEAS) in PCAST terms]

18. Issues Raised by PCAST Work Group • Data holder responsibilities, autonomy, and liability • Level of autonomy data holders maintain over how they share patient data under their control? • Liabilities data holders may incur from sharing through DEAS? • Responsibilities that data holders have for ensuring that data is shared with legitimate users for legitimate purposes? • Responsibilities of EHR holders to maintain a high level of accessibility to their data? • Education Programs and Transparency • Needed for patients and providers • Who is responsible for education?

19. IEWG Recommendations re: Query (1 of 3) Certification criteria: The EHR must be able to query another entity for outside records and respond to such queries. The outside entity may be another EHR system, a health information exchange, or an entity on the NwHIN Exchange, for example. This query may consist of three transactions: • Patient query based on demographics and other available identifiers, as well as the requestor and purpose of request. • Query for a document list based for an identified patient • Request a specific set of documents from the returned document list

20. IEWG Recommendations re: Query (2 of 3) When receiving inbound patient query, the EHR must be able to: • Tell the querying system whether patient authorization is required to retrieve the patient’s records and where to obtain the authorization language*. (E.g. if authorization is already on file at the record-holding institution it may not be required). • At the direction of the record-holding institution, respond with a list of the patient’s releasable documents based on patient’s authorization • At the direction of the record-holding institution, release specific documents with patient’s authorization

21. IEWG Recommendations re: Query (3 of 3) The EHR initiating the query must be able to query an outside entity* for the authorization language to be presented to and signed by the patient or her proxy in order to retrieve the patient’s records. Upon the patient signing the form, the EHR must be able to send, based on the preference of the record-holding institution, either: • a copy of the signed form to the entity requesting it • an electronic notification attesting to the collection of the patient’s signature *Note: The authorization text may come from the record-holding EHR system, or, at the direction of the patient or the record-holding EHR, could be located in a directory separate from the record-holding EHR system, and so a query for authorization language would need to be directable to the correct endpoint.

22. Previous Recommendations: Consent (1 of 4) • Recommendations apply to exchange of identifiable health information to meet Stage 1 requirements – exchange of information for treatment and public health purposes (pages 1, 11). • Additional work would be needed to apply these recommendations to other exchange circumstances. • The trust framework for exchange among providers for treatment requires some assurance that providers on both ends of the transaction have a treatment relationship with the subject of the information (page 7) • A provider requesting information should, at a minimum provide attestation of his or her treatment relationship with the individual who is the subject of the info sought. (page 8)

23. Previous Recommendations: Consent (2 of 4) • Directed Exchange among a patient’s treating providers – the sending of identifiable health information from provider A to provider B – is generally consistent with patient expectations and does not require patient consent beyond what is required in current law or what has been customary practice.(p.5) • When the decision to disclose or exchange the patient’s identifiable health information from the provider’s record is not in the control of the provider or that provider’s organized health care arrangement (“OHCA”), patients should be able to exercise meaningful consent to their participation.(p.10)

24. Previous Recommendations (3 of 4) • Examples of this include: • A health information organization operates as a centralized model, which retains identifiable patient data and makes that information available to other parties. • A health information organization operates as a federated model and exercises control over the ability to access individual patient data. • Information is aggregated outside the auspices of the provider or OHCA and comingled with information about the patient from other sources. (page 10)

25. Previous Recommendations (4 of 4) • Recommendations were based on the following core values: • The relationship between the patient and his or her health care provider is the foundation for trust in health information exchange. • We must consider patient needs and expectations. Patients should not be surprised about or harmed by collections, uses, or disclosures of their information. (p.4)