Consent Directive Use Cases

Back to: CBCC Main Page > CBCC Use Cases

See also: Glossary of Consent Terms for definition of acronyms and terms.

---

Introduction

The following use cases describe requirements for the creation and use of privacy consent directives to express consumer preference in regards personal health record and personally/individually identifiable information. These use cases are based on the recommendation issued by [www.samhsa.gov/ SAMHSA] in May 2008 to the American Health Information Community (AHIC) Consumer Empowerment Workgroup:

Recommendation 1: Personal Health Records should possess the functional and technical capability to enable healthcare consumer control of the collection, access, use, and disclosure of their individually identifiable health information (IIHI) according to the type of information, type of provider, and purposes/circumstance of the collection, access, use, or disclosure. The consumer control capability must remain associated with the IIHI as it travels through the electronic health information exchange such that consumer control is supported when IIHI is further disclosed. Thus, the consumer control of IIHI capability must span EHRs and PHRs. Sarah Wattenberg, May 15th, 2008

Use Cases

Grant Control of Protected Health Information(PHI) to Consumer

This use cases is the basis of the entire Consent Directive specification. If the consumers do not own/control their PHI, then they cannot specify consent directives.

Basic Scenario

Based on the current regulation, the Jurisdictional Authority assigns the right to control personal health information to the Consumer who is its subject or to their designated Substitute Decision Maker (SDM) that acts on behalf of the Patient.

Post-Condition

The Consumer may consent to assign access to parts of the PHI to specific providers for treatment or other organization for research, etc.

Actors

See also: Actor definitions

• Jurisdictional Authority
• Patient
• Substitute Decision Maker(SDM)

Consenter Manages Consent Directives

A patient or substitute decision maker, the "Consenter", uses a CDMS to manage consent directive rules that are shared with healthcare providers, payers, and others that may access PHI. The CDMS is usually embedded in a PHR System or some other publicly accessible healthcare platform and does not require separate privileges for user access.

I would reverse "A patient or substitute decision maker, the "Consenter"" to "The Consenter, a patient or substitute decision maker,". The new order seems more consistent with the effort for consistency in vocabulary.

I suggest that "...does not require separate privileges for user access" is unneccesarily restrictive at this level. I think a case could be made that a second sign in, much like how ebay will periodically ask for a user ID and password, is an additional safety feature.

Pre-condition

The consumer will have an enumerated of consent directive options.

Basic Scenario

• Consenter may add, modify, or revoke consent directive regarding the disclosure of his/her PHI.
• Verify that added or modified consent directive rules do not conflict with existing rules.

Whose "existing rules", the jurisdiction?

• The CDMS will include default jurisdictional policy rules that are applicable across all requesting organizations. Other organizational or local jurisdiction policies must be applied by each consent requester. The user must not be able to disable the directives derived from these default jurisdictional policies.
  • For example, universal consent policies are required for Alcohol and Substance Abuse information, as specified by CFR 42, Part 2.

Actors

See also: Actor definitions

• Consenter
• Consent Directives Management Service (CDMS)

Request Consent Directives for a Consumer

Consent for access to PHI is determined by both a consumer's consent directives and the policies of the requester's organization and/or governing jurisdiction. The request for a patient's consent must discover and merge all relevant privacy policies.

Pre-Conditions

• An authenticated patient identity has been established.

Basic Scenario

• The Consent Requester uses the patient's identity to query the CDMS Registry and discover location of the patient's CDMS.
• Query the CDMS and retrieve the patient's consent directives.
• Merge patient's directives with requester's organizational and jurisdictional consent policy rules.
  • If the patient's consent directive rules contradict the organizational or jurisdictional policies, then flag conflict in result set.

Alternate Flow

• There are no consent directives for the patient, or no registered CDMS.
• Apply only the organizational and jurisdictional consent rules.

Post-condition

• A set of patient's consent directive rules, or empty set if no rules are registered or no CDMS is found.
• Flags for conflicts in merged rules.

Actors

See also: Actor definitions

• Consent Requester
• Consent Directives Management Service (CDMS)
• CDMS Registry

Provider Requests Protected Health Information (PHI)

When a healthcare provider looks up a patient's PHI, that patient's consent directives must be retrieved and used to filter the data before returning or displaying results to the provider.

Basic Scenario

• Invoke use case: Request Consent Directives for a Patient.
• Query the PHI Repository to retrieve patient's medical record.
• Invoke use case: Consent Directives Filter Health Record Information
  • Use the consent directive rules to filter PHI, allowing only content appropriate for clinician involved in care, administration, and payment.

Post-condition

• The Provider's EHRS stores a copy of the patient's health record that was created in by that provider. This information must be retained for legal reasons.
• The Provider's EHRS must update the patient's health record in the PHI repository with the new data that was created by the provider. The Provider must flag the Protected Health Information (PHI) according to the patient's consent directives.

Actors

See also: Actor definitions

• Provider's EHR System (EHRS)
• PHI Repository

Consent Directives Filter Health Record Information

Filtering mechanisms and algorithms are required that apply consent directive rules to an individual's health record content. Consent directives may include restricted access filters that are applied to a category of health information (e.g., all HIV related information) or to a particular data element (e.g., filter all instances of a provider's name). A consent directive may also require that personally identified health information is "masked" to hide the patient's identity.

Pre-conditions

• Instead of having generic functional role, provider's role is based on their relationship to the patient. For example, a member of the immediate care team (e.g. attending physician, nurses providing direct care, etc.) may be allowed to see and update Protected Health Information (PHI) while other clinicians (e.g. laboratory medical technicians, consulting physicians, etc.) will be allowed access only to the information intended for their use (e.g. laboratory order or consult request).
• A provider requests a patient's health record in order to provide care to the patient. The information is provided in the form of structured or unstructured clinical documents.

Basic Scenario

Depending on whether the information is structured or unstructured, filtering may be applied at the record or document level, or on subsections. Structured information, which is encoded data, can be filtered at the data element level. Unstructured information, which is unencoded data that may be transmitted, e.g., as an image or bit map, can only be filtered at the document or document section level.

Actors

See also: Actor definitions

• Consent Directives Management Service (CDMS)
• Consent Requester

Flag Filtered Health Record Information

If Consenter decides to restrict certain information, he may have the option of deciding whether to permit PHI Repository to send a flag to an authorized party alerting the Consent Requester that restricted information is available upon Consenter's approval or by "breaking the glass" in an emergency. "Breaking the glass" occurs when a provider who is authorized by organizational policy or jurisdictional law overrides a consent directive.

Basic Scenario

Authorize a specified type of provider to access all restricted health information, and to receive a flag that restricted information may be accessed, following Consenter's approval. A provider's use of restricted information is limited to read-only for a specified time period, after which the consent approval will expire.

Actors

See also: Actor definitions

• Consenter
• Consent Requester
• Consent Directives Management Service (CDMS)
• PHI Repository