This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Consent Tracker FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
Line 59: Line 59:
 
==='''Consent Tracker Scope of''' Coverage===
 
==='''Consent Tracker Scope of''' Coverage===
  
*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 workflow and access control.
+
*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 including:
+
*The Consent Tracker Resource elements were selected based on mapping several current approaches to conveying consent directive metadata.
**v2 CON Medical Records Consent Segment;
+
 
**v2 MDM/ACK - Document Status Change Notification (Event T03)  
+
V2 approach to managing consent directive metadata includes sending the metadata in a CON segment and/or populating elements in other message types:
**ADT ARV-3 Access Restriction Value;  
+
 
**OM 1-30 Master Files General Observations Confidentiality Code;
+
**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).
**ORC-28 Common Order Segment Confidentiality Code;
+
**CON Segment elements include consent type, form id and version, recorded consent
**Financial Management DG1-18 Confidential Indicator and DRG-10 Confidential Indicator; **eClaims EHC^E12 Request Additional Information (event E12) and EHC^E13 Additional Information Response (event E13)
+
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 Breath of Scope===

Revision as of 22:48, 1 June 2016



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

FHIR Resource Development Project Insight ID

pending - reminder sent to CBCC cochairs June 1, 2016

Scope of coverage

Consent Tracker Scope of Coverage

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

RIM scope

Resource appropriateness

Expected implementations

Content sources

Example Scenarios

Resource Relationships

Timelines

gForge Users

When Resource Proposal Is Complete

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