Consent Directive Use Cases

Actors

These actors are used in all privacy use cases, with a common meaning and definition. Also see Glossary for defintion of acronyms and terms.

Consent Directive Management System (CDMS) 

Repository and associated services for creating, maintaining, and evaluating consent directive rules.

Patient 

Person who is subject of PHI.

PHI Repository 

General actor that includes EHR Systems, EMR Systems, PHR Systems, and other health platform repositories and portals.

Substitute Decision Maker(SDM) 

A person who is authorized under legislation to consent on behalf of the patient/person.

Role-Based Access Control (RBAC)

The following use cases are based on the RBAC specification.

Each type of user in a healthcare organization has a specified "role" which consists of "permissions" to perform certain functions and access specific data. While the set of permissions assigned to each role is based on local policy (enterprise-wide, jurisdiction-wide, etc.), the operation and the functions/information to which they apply, are standardized by HL7 as a normative specification. The functional roles for healthcare users are specified as an informative specification.

• Sample permissions:
  • "read, M.A.R. (medication administration record)" allows the user the see the medication administered to a patient.
  • "create, Registration" allows a clerk to register a patient by creating a registration/encounter record

Benefits RBAC for Patient Privacy

• Even though it does not take into account specific patient preferences, RBAC ensures that only specific user roles have access to patient information and clinical functionality (e.g. admission clerks cannot view pharmacy prescriptions).

Mask Functionality

Based on the functional role of the user logged in, the healthcare information system will limit access only to those operations (e.g. append, create, read, update, delete, execute) and functions (identified using an object id) that are allowed for that role.

Basic scenario

A user logs in, the application identifies the functional group or role for the user. Based on the user's role, the application interrogates the security systems for the functions allowed for the role. The security system stores the permissions associated with the role and it can specify whether the user can access specific functionality. Based on the results provided by the security system, the application displays to the users only those are of functionality that their functional role in the allows them to have. This use case would apply to a situation where both the application and the security systems are in the same organization or in different organizations.

Actors

• User
• Healthcare Application
• Security System

Mask Information

Based on their functional role, users can view(read),create, update, delete, or act (execute) on information contained in a patient's record. While the role of the user may limit their access to specific patient record information - limiting it to the information required to perform the job as specified by the role -

Basic Scenario

The user inquires the Personal Health Record system, based on the role the system provides the information specified by the permissions assigned to the user's role.

Actors

• User
• EHR System (EHRS)
• Security System

Consumer Preferences

The following use cases provide a consumer-centric rather than user-centric view to consent. These use cases reuse the functional role, operation, and object id concepts introduced by RBAC but it adds the consumer license, purpose, relationship to consumer (e.g.

Grant for Personal Health Information to Consumer

Pre-condition

The right/license to control one's medical information is assigned by jurisdiction to the patient/consumer.

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 that acts on behalf of the Consumer.

Actors

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

Consumer Manages Consent Directives

This use case assumes that the consumer has access to a Personal Health Record system through some type of portal (e.g. web) and manages a single data consent intended to be shared with a variety of providers, payers, etc.

Basic Scenario

Consumer uses the portal provided by the PHR to set the privacy consent directives for their medical record information. By default, the PHR will include the protection specified by CFR 42, Part 2.

Actors

• Consumer
• Substitute Decision Maker
• Personal Health Record System/Portal

Provider Requests Consent Directives for a Patient

Pre-condition

The patient has completed the consent directive and persisted in in the Personal Health Record and it is made available through a Consent Manager system.

Basic Scenario

• The patient (or SMD) provides the Registration Clerk with a reference to the consent directives already specified by the patient and maintained along the patient's PHR.
  • Implementation Note: The reference may be a URL that references a set of user-readable rules and computer-readable consent directive rules.
• The Registration Clerk retrieves the consent directives and compares them with the privacy consent directives currently supported in the organization.
• If the local consent directive rules contradict the local rules, the patient (or SMD) has the option to decline the medical services. Otherwise, the patient (or SMD) agrees with the local consent directive rules.

Post-condition

The Provider's Information System stores a copy of the Consumer's Consent Directives.

Actors

• Consumer/Substitute Decision Maker(SDM)
• Provider's Registration Clerk
• Provider's Information System
• Consent Manager (associated with a Personal Health Record)

Provider Looks up the Personal Health Record Information

Pre-condition

• The patient has completed the consent directive and persisted in in the Personal Health Record.
• The patient needs healthcare services a healthcare organization that has never treated the patient in the past or has treated the patient prior to introduction of consent directives and PHRs.

Basic Scenario

• The patient provides the Provider with a references to the PHR ...
• The provider looks up the consent and medical record.

Post-condition

The Provider's Information System stores a copy of the agree consumer preferences.

Actors

• Provider's Clerk
• Provider's Information System
• Consent Manager (associated with a Personal Health Record)

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, or "masking", 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).

Pre-condition

• The patient has completed entry of consent directive rules.

Basic Scenario

Depending on whether the information is structured or unstructured, masking may be applied at the record or document level, or on subsections. Structured information, which is encoded data, can be masked 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 masked at the document or document section level.

Actors

• Consent Manager
• EHR System (EHRS)

Flag Filtered Health Record Information

If Patient decides to mask certain information, he may have the option of deciding whether to permit EHR System to send a flag to an authorized party alerting the requester that masked information is available upon Patient's consent 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.

Pre-condition

• The patient has completed entry of consent directive rules.

Basic Scenario

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

Actors

• Patient
• Consent Manager
• EHR System (EHRS)

Flow diagram to help with construction of use cases

SAMHSA-RBAC flow contributed by FDin

---

Back to CBCC Main Page