1 / 21

Privacy and Security Tiger Team

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

Download Presentation

Privacy and Security Tiger Team

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Objectives of Today’s Discussion • Continue discussion of query, with a focus on the policy implications, if any, of the Information Exchange Work Group (IEWG) recommendations on EHR certification criteria for query included in the RFC • Position Tiger Team to respond to comments, if any, on these issues as a result of the RFC—comments due January 14

  3. Topics to be Covered • Review: • Specifics of IEWG recommendations • Previous Tiger Team recommendations on consent • Tee up Tiger Team Discussion Questions • Provide relevant context to inform discussion: • CCDA confidentiality codes • Applicable provisions of the DURSA

  4. 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

  5. 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

  6. 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.

  7. 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)

  8. 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)

  9. 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)

  10. 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)

  11. Issues • Previous Tiger Team recommendations assume a decision-maker at the receiving end of the query—and that this 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)

  12. 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?

  13. Relevant DURSA Provisions (1 of 3) • The Data Use and Reciprocal Support Agreement (DURSA) is the trust agreement that all participants in the eHealthExchange (formerly the NwHIN exchange) execute. It establishes obligations of the participants to each other and grants authority to a Coordinating Committee for oversight.(Healthewayis the non-profit organization that supports the eHealth Exchange.) • Submitter—defined as any participant that submits a message to another participant—is responsible, among other things, for representing that the message is for a permitted purpose and supported by legal authority, including any consent/authorization required.

  14. Relevant DURSA Provisions (2 of 3) • Participants who request information for treatment purposes, must respond to requests for information for treatment by providing the information or providing a standard response that the information is unavailable or cannot be exchanged. This means that participants still retain the right to determine when to release information per applicable law and local policy. • Participants may, but are not required, to provide information for permitted purposes other than treatment.

  15. Relevant DURSA Provisions (3 of 3) • 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.

  16. Confidentiality Codes: CCDA

  17. CCDA Confidentiality Code “Value Set” • CCDA constrains the HL7 Confidentiality Code System (see: Backup Slides) from 6 to 3 codes • Confidentiality codes are used in the CCDA: • Header • Section • CCDA confidentiality codes are determined by the Sensitivity of the Entries • May be conveyed by External Reference • Future: By Security Labels on the Entries • CCDA Header confidentiality code must be the “High Water Mark” or the most restrictive of the Section confidentiality codes

  18. CCDA Envelope Metadata, User Assertions, and Confidentiality Codes • One or more CCDAs are sent in a Document EntryEnvelope • Document Entry Envelope includes Privacy Metadata • High Water Mark Confidentiality Code – the most restrictive of the CCDA Headers (Required) • Handling Instructions (DS4P Extensions): • Purpose of Use (e.g., Treatment, Payment, Operations) • Obligations (e.g., Encrypt, Minimum Necessary) • Refrain Policies (e.g., Do not redisclose without Consent) • Federated User Assertions (SAML/XUA+) are included as metadata • Assertion of proposed purpose of use (e.g., Treatment, Payment, Operations) • Identity Assertion (individual user or organization)

  19. Backup Slides Backup Slides

  20. HL7 Confidentiality Code System

  21. HL7 Confidentiality Code System

More Related