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 Individually Identifiable Health Information(IIHI) to Consumer

This use cases is the basis of the entire Consent Directive specification. If the consumers do not own/control their IIHI, 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 IIHI 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

The Consenter, a patient or substitute decision maker uses a CDMS (via Web) to manage consent directive rules that are shared with healthcare providers, payers, and others that may access IIHI. The CDMS may embedded in a PHR System or some other publicly accessible healthcare platform.

Pre-condition

• The Consenter will have an access to a set of default enumerated of consent directive options that are appropriate for that jurisdiction.
• An authenticated Consenter and Consumer identity have been established.
• The Consenter may be SDM acting on behalf of a Consumer.

Basic Scenario

• Consenter may add, modify, or revoke consent directive regarding the disclosure of his/her Personal Health Record (PHR).
• Verify that added or modified consent directive rules do not conflict with existing federal or local rules.
• 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 IIHI 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 reconcile all relevant privacy policies.

Pre-Conditions

• An authenticated Consumer identity has been established.
• The Consenter may be SDM acting on behalf of a Consumer.

Basic Scenario

• The Consent Requester uses the consumer's identity to query the CDMS Registry and discover location of CDMS that stores the consumer's consent directives.
• Query the CDMS and retrieve the patient's consent directives.
• Reconcile 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 consumer, or no registered CDMS.
• Apply only the organizational and jurisdictional consent rules.

Post-condition

• A set of consumer's consent directive rules, or empty set if no rules are registered or no CDMS is found.
• Flags for conflicts in merged rules.
• If the consumer's consent directives and the organizational directives cannot be reconciled, the consumer may sign a waiver or refuse medical services.

Actors

See also: Actor definitions

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

Provider Requests Access to Personal Health Record (PHR)

When a healthcare provider requires access to the patient's medical history, medication list, problems, allergy, etc. the patient may allow access to the PHR to be used for the purposes of treatment, payment, etc. Before the PHR may be viewed, used, and updated by a provider, 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 IIHI Repository to retrieve patient's health record (PHR) including Individually Identifiable Health Information (IIHI)
• Invoke use case: Consent Directives Filter Health Record Information
  • Use the consent directive rules to filter IIHI, 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 IIHI repository with the new data that was created by the provider. The Provider must flag the PHR and the Individually Identifiable Health Information (IIHI) contained in it according to the patient's consent directives.

Actors

See also: Actor definitions

• Provider's EHR System (EHRS)
• PHR 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 the PHR 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 IIHI 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)
• IIHI Repository

Provider Maintains IIHI based on Consumer's Directive

If the consumer requested it, the provider will update the IIHI stored at a location specified by the patient at the end of a visit, encounter, procedure, etc.

Pre-condition

The provider is given access to the IIHI and the consent directive,

Post-condition

• The provider produce additional information as a result treating the patient.
• The consumer's IIHI is updated in the IIHI Repository.
• It must be possible to interpret the information added to the IIHI such as a system can correctly differentiate information that my be sensitive under jurisdictional, organizational, or consent directive.

Actors

See also: Actor definitions

• Consenter
• IIHI Producer