Consent Tracker FHIR Resource Proposal

Consent Tracter

Owning committee name

Community-Based Collaborative Care

Committee Approval Date:

May 31, 2016

Approved during the May 31, 2016 CBCC Conference Call

Contributing or Reviewing Work Groups

• Security

FHIR Resource Development Project Insight ID

pending - reminder sent to CBCC cochairs June 1, 2016

Scope of coverage

Consent Tracker Scope of Coverage

• Important decisions that patients and their personal representative make about activities or information, which concern their health and well-being, are typically captured as contractually binding permissions, obligations, and prohibitions known as Consent Directives. Consent Directives memorialize these decisions as rules specifying rights that the patient, as grantor, conveys to a grantee, such as a provider, a health app, a health plan, HIE, or clinical trial.
• When patients and providers create and manage privacy and medical Consent Directives, including clinical trial, research, and advanced directives, three components are typically required:

(1) Paper or electronic forms in which a patient documents permissions granted or restriction limiting activities related to e.g.: patient care [aka medical consent directive], participation in clinical trials [aka research consent directive], or collection, access, use, and disclosure of information [aka privacy consent directive] (2) The legally binding recording of a Consent Directive contract for which both the patient grantor and the data controller or processor grantee are held accountable once executed. A legally binding Consent Directive may transition a series of lifecycle stages or 'status', which may indicate e.g., whether the Consent Directive form has been signed by the patient and accepted by the grantee, whether the patient has revoked or renewed it. (3) A means for managing or "tracking" Consent Directives at all stages in their lifecycle, from the patient, institutional, or jurisdictional policy, to an offered Consent Directive form, and on to the executed Consent Directive, which may be pended, disputed, revoked, terminated, or renewed.

• The FHIR Consent Tracker Resource supports the third requirement by providing a flexible means for tracking and conveying intra-and inter-enterprise the lifecycle, provenance, privacy, and security metadata used for Consent Directive management workflows, such as obtaining patient authorizations and restrictions, and Consent Directive enforcement using security labeling and privacy protective services to comply with access control decisions.
• The Consent Tracker Resource is agnostic to the media used to capture the Consent Directive. I.e., it can track the location from which an authorized user may retrieve a copy of or verification of the existence of a legally binding Consent Directive regardless of whether it is captured as a paper, scanned or otherwise unstructured representation; IHE Basic and Advanced Patient Privacy Consents; HL7 CDA Consent Directives, a FHIR Consent Directives, or the patient friendly FHIR Consent Directive form and completed instance, i.e., a FHIR Consent Directive Questionnaire and Questionnaire Response.

Evidence of utility for 80% of Systems

• The proposed Consent Tracker Resource is intended to meet a very basic yet unique healthcare domain business requirement, which is to convey the minimal set of consent directive metadata that has been used by the industry to manage consent directive in various workflows, such as orders, observations, ADT, claims, and records management and lifecycle status notifications; and access control use cases related to those workflows, including collection, access, use, and disclosure of the consent directive and information governed by the consent directive.

• The Consent Tracker Resource elements were selected based on mapping several current approaches to conveying consent directive metadata.

V2 approach to managing consent directive metadata includes sending the metadata in a CON segment and/or populating elements in other message types:

• • v2 CON Medical Records Consent Segment: This segment identifies patient consent information relating to a particular message. It can be used as part of existing messages to convey information about patient consent to procedures, admissions, information release/exchange or other events discussed by the message. It may also be used in messages focusing on recording or requesting consent and for consents related to employees or service providers. The segment will be used in conjunction with various other segments to identify the practitioner (PRA/STF) or patient (PID) the consent is for, the various individuals involved in the consent (ROL) as witnesses, consenting person (not always the patient), translators, consulting providers, etc., and the specific procedures being proposed (PR1).
  • CON Segment elements include consent type, form id and version, recorded consent

unique identifier ( whether on paper or electronic), text, patient restrictions, status, consent recorded and effective date/time, bypass and non-disclosure reason (v3 purpose of use and sensitivity code such as taboo)

• • CON segment may be used in MDM/ACK - Document Status Change Notification (Event T03), Document Status Change Notification and Content (Event T04), Document Addendum Notification (Event T05), Document Addendum Notification and Content (Event T06), Document Edit Notification (Event T07), Document Edit Notification and Content (Event T08), Document Replacement Notification (Event T09), Document Replacement Notification and Content (Event T10), Document Cancel Notification (Event T11)
  • v2 MDM/ACK - Document Status Change Notification (Event T03): This is a notification of a change in a status of a document without the accompanying content. Scenario: A document is authenticated. Notification is sent to the chart tracking system and is used to update the document status from pre-authenticated to authenticated or legally authenticated. A change in any of the following independent status characteristics would cause a message to be sent:

Completion Status and Confidentiality Status.

• • ADT ARV-3 Access Restriction Value: The ARV segment is used to communicate the requested/required type of access restrictions from system to system, at both the person/patient and the encounter/visit level.
  • Examples: A person/patient may have the right to object to any or all of his/her information to be disclosed. In addition, the patient may request that protected information not be disclosed to family members or friends who may be involved in their care or for notification purposes.
  • A realm or organization may have certain privacy policies. A patient may have the right to opt out of being included on facility directories. In an international context, a physician may be culturally obligated to protect the patient's privacy. Any "opt-in" or "opt-out" restrictions.
  • The individual system security may want to utilize the Access Restriction Value along with the Access Restriction Reason (and/or with the Confidentiality Code from another segment, e.g., OM1-30 or other data) in order to implement the appropriate type of protection for the person, patient, visit and/or visit data. Each system has the flexibility to incorporate/map the access values into their security system appropriately; the actual implementation for access to protected data is determined by the individual system. The Access Restriction Values supported by an enterprise/system would be defined and determined by that organization.

It is expected that these access restriction values would be utilized in combination with other system security information (e.g., patient locations, user department, caregiver-patient relationships, other access restriction parameters) to determine user access. System implementers should carefully control access to the restriction codes and values, as they themselves hold sensitive information.

• • OM 1-30 Master Files General Observations Confidentiality Code: : This field contains the degree to which special confidentiality protection should be applied to the observation.
  • ORC-28 Common Order Segment Confidentiality Code: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.).
  • Financial Management DG1-18 Confidential Indicator and DRG-10 Confidential Indicator: Fields indicating whether the diagnosis is confidential or the DRG contains a confidential diagnosis.
  • eClaims EHC^E12 – Request Additional Information (event E12): Interpretative Rule: Patient Consent. If Patient Consent in the RFI segment is marked "Y" (Yes) the Payer is signifying possession of proof of patient consent for release of confidential information.

EHC^E13 – Additional Information Response (event E13): Informative Rule: Document Confidentiality Status on TXA. When this optional field is completed it indicates that the Payer is to restrict access to the attached document according to the Payer's established policies and/or in accordance with prior business agreements between the Provider and Payer. PSL-21 Restricted Disclosure Indicator (ID) 01975 Definition: Set to "Yes" if information on this invoice should be treated with increased confidentiality/security.

Consent Tracker Breath of Scope

Consent Tracker scope, as listed below, is constrained during implementation to applicable policies. I.e., in some jurisdictions, there may be no opportunity for a patient to consent or dissent to uses of information or activities performed, either because there is no express consent or consent is implied/assumed.

For example, many jurisdictions collect, access, use, and disclose health care information without consent or implied consent for certain public health, safety, and legal purposes.

Consent Tracker Subjects

Persons who are the subject of information or activity governed by a consent directive.

Consent Tracker Disciplines

• Any type of patient or subject specific health care provision, including physical, preventive, palliative, hospice, community-based, reproductive, maternity, neonatal, pediatric, geriatric, mental, behavioral, substance use, clinical trials, and public health
• Any type of patient or subject specific administrative or financial activities permitted or required for purposes care delivery management, operations, or payment
• Any secondary use of patient or subject specific health and administrative/financial information, including research, public health surveillance, immunization and cancer registries, quality measures, payment incentive programs.
• Any patient or subject specific provision of services, such as health device platforms, or health and fitness APPs.

Care Delivery Environment

Any care delivery environment, including Community, Geriatric, Hospice, Home care, Emergency, Inpatient, Intensive, Neonatal, Pediatric, or Primary Care

Locale

Any jurisdiction in which consent directives are permitted or required by policy.

When Resource Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org