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

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 2

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 3

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 4

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 5

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

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

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

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

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

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

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

Relevant DURSA Provisions (1 of 3) The Data Use and Reciprocal Support Agreement (DURSA) is the trust agreement that all participants in the eHealth Exchange (formerly the NwHIN exchange) execute. It establishes obligations of the participants to each other and grants authority to a Coordinating Committee for oversight. (Healtheway is 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. 13

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

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

Confidentiality Codes: CCDA CodePrint NameDefinition Nnormal Definition: Privacy metadata indicating that the information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without authorization. Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI) given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health information disclosed in an application for health, workers compensation, disability, or life insurance. Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable jurisdictional privacy law or disclosure authorization. Rrestricted Definition: Privacy metadata indicating highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. May be preempted by jurisdictional law, e.g., for public health reporting or emergency treatment. Examples: Includes information related to mental health, HIV, substance abuse, domestic violence, child abuse, genetic disease, and reproductive health. May be used to indicate proprietary or classified information that is not related to an individual, e.g., secret ingredients in a therapeutic substance; or the name of a manufacturer. Usage Note: This metadata indicates that the receiver may be obligated to comply with the information subject’s consent directive or jurisdictional or organizational policies that are more stringent than prevailing or default jurisdictional privacy laws. Vvery restricted Definition: Privacy metadata indicating extremely sensitive, likely stigmatizing information, which presents a very high risk if disclosed without authorization. This information must be kept in the highest confidence. Examples: Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient. May also include information held under “legal lock” or attorney-client privilege. Usage Note: This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject. 16

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 17

CCDA Envelope Metadata, User Assertions, and Confidentiality Codes One or more CCDAs are sent in a Document Entry Envelope 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) 18

BACKUP SLIDES Backup Slides 19

Lvl- Typ Code Print NameDefinition, Properties, Relationships 0-SConfidentiality Definition: Privacy metadata indicating the sender's sensitivity classification, which is based on an analysis of applicable privacy policies and the risk of harm that could result from unauthorized disclosure. Usage Note: Confidentiality codes are used as metadata indicating the receiver responsibilities to ensure that the information is not made available or redisclosed to unauthorized individuals, entities, or processes (security principals) per applicable policies. Map: Definition aligns with ISO : Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. Concept Relationships: Generalizes (derived): L M N R U V 1-LLlowDefinition: Privacy metadata indicating that the information has been de-identified, and there are mitigating circumstances that prevent re-identification, which minimize risk of harm from unauthorized disclosure. The information requires protection to maintain low sensitivity. Examples: Includes anonymized, pseudonymized, or non-personally identifiable information such as HIPAA limited data sets. Usage Note: This metadata indicates the receiver may have an obligation to comply with a data use agreement. Map: Partial map to ISO Sensitivity Level (1) Care Management: RECORD_COMPONENTs that might need to be accessed by a wide range of administrative staff to manage the subject of care's access to health services. 1-LMmoderateDefinition: Privacy metadata indicating moderately sensitive information, which presents moderate risk of harm if disclosed without authorization. Examples: Includes allergies of non-sensitive nature used inform food service; health information a patient authorizes to be used for marketing, released to a bank for a health credit card or savings account; or information in personal health record systems that are not governed under health privacy laws. Usage Note: This metadata indicates that the receiver may be obligated to comply with the receiver's terms of use or privacy policies. Map: Partial Map to ISO Sensitivity Level (2) Clinical Management: Less sensitive RECORD_COMPONENTs that might need to be accessed by a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology staff). 1-LNnormalDefinition: Privacy metadata indicating that the information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without authorization. Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI) given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health information disclosed in an application for health, workers compensation, disability, or life insurance. Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable jurisdictional privacy law or disclosure authorization. Map: Partial Map to ISO Sensitivity Level (3) Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations. HL7 Confidentiality Code System 20

Lvl- Typ Code Print NameDefinition, Properties, Relationships 1-LRrestrictedDefinition: Privacy metadata indicating highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. May be preempted by jurisdictional law, e.g., for public health reporting or emergency treatment. Examples: Includes information related to mental health, HIV, substance abuse, domestic violence, child abuse, genetic disease, and reproductive health. May be used to indicate proprietary or classified information that is not related to an individual, e.g., secret ingredients in a therapeutic substance; or the name of a manufacturer. Usage Note: This metadata indicates that the receiver may be obligated to comply with the information subject’s consent directive or jurisdictional or organizational policies that are more stringent than prevailing or default jurisdictional privacy laws. Partial Map to ISO Sensitivity Level (4) Privileged Care: Access restricted to a small group of people caring intimately for the patient, perhaps an immediate care team or senior clinical party (the privileged clinical setting needs to be specified e.g. mental health). 1-LUunrestrictedDefinition: Privacy metadata indicating that the information is not classified as sensitive. Examples: Includes publicly available information, e.g., business name, phone, or physical address. Usage Note: This metadata indicates that the receiver has no obligation to consider additional policies when making access control decisions. Note that in some jurisdictions, personally identifiable information must be protected as confidential, so it would not be appropriate to assign a confidentiality code of "unrestricted" to that information even if it is publicly available. 1-LVvery restricted Definition: Privacy metadata indicating extremely sensitive, likely stigmatizing information, which presents a very high risk if disclosed without authorization. This information must be kept in the highest confidence. Examples: Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient. May also include information held under “legal lock” or attorney-client privilege. Usage Note: This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject. Partial Map to ISO Sensitivity Level (5) Personal Care: To be shared by the subject of care perhaps with only one or two other people whom they trust most, or only accessible to the subject of care (and to others by one-off authorizations). HL7 Confidentiality Code System 21