T1.1: Implements Consent Policy Decisions

Overview

HealthShare Unified Care Record uses a three-tier consent policy hierarchy to control access to patient data across the federation. This hierarchy ensures that organizations can define broad default policies while accommodating exceptions at the facility and individual patient levels. The hierarchy cascades downward, meaning that higher-level policies serve as defaults that can be overridden by more specific lower-level policies.

How Cascading Works

When a clinician attempts to access patient data, UCR evaluates consent policies starting from the most specific level: 1. If a patient-level consent policy exists, it is used regardless of facility or system settings 2. If no patient-level policy exists, the system checks for a facility-level policy 3. If no facility-level policy exists, the system-wide default applies 4. At each level, both MPI consent and clinical consent are evaluated independently

Practical Implications

• A system-wide opt-out policy means all patients are visible by default across the federation
• A facility override to opt-in for a behavioral health clinic restricts visibility for patients at that facility
• A patient who explicitly consents to sharing overrides the facility-level restriction
• Administrators must understand the effective consent at each level to troubleshoot access issues

Configuration Location

All consent policies are configured through the HealthShare Management Portal on the Registry (Hub) namespace. The consent management pages provide interfaces for creating and editing policies at each level of the hierarchy.

---

Overview

System-level consent is the broadest setting in the consent hierarchy and defines the default consent posture for the entire federation. This is the first consent decision an organization must make during UCR deployment, as it affects every patient and every facility unless overridden.

Opt-In vs Opt-Out

The fundamental system-level decision is the consent model:

• Opt-in model: All patient data is restricted by default. No data is shared across the federation until explicit consent is obtained from the patient. This provides maximum privacy protection but requires robust consent collection workflows.
• Opt-out model: All patient data is shared across the federation by default. Patients must actively request restrictions on their data. This enables immediate data sharing and supports care coordination but requires clear patient notification.

Configuring System-Level Consent

Configuration is performed through the Registry Management Portal:

• Navigate to HealthShare > Registry Management > Consent Management
• Configure MPI consent: choose the default MPI consent mode (opt-in or opt-out) to control whether patients appear in cross-facility searches by default
• Configure clinical consent: choose the default clinical consent mode and optionally define default CIT restrictions
• The system-level setting applies to all facilities and patients unless overridden

Regulatory Considerations

• Some jurisdictions mandate opt-in for health information exchanges
• HIPAA permits both models with appropriate safeguards
• 42 CFR Part 2 requires explicit patient consent for substance abuse treatment records regardless of the system model

---

Facility-Specific Consent

Facility-level consent overrides allow organizations to accommodate facilities with different privacy requirements:

• A behavioral health facility may require opt-in consent even when the system default is opt-out
• A facility in a state with stricter privacy laws can enforce tighter consent rules
• Each facility override is linked to the facility's identifier in the system registry
• Facility overrides can be set for MPI consent, clinical consent, or both independently

Creating Facility Consent Policies

To create a facility-level consent policy:

• Navigate to Consent Management in the Registry Management Portal
• Select the target facility from the facility registry
• Define the MPI consent override (if different from system default)
• Define the clinical consent override (if different from system default)
• Specify any CIT-level restrictions specific to this facility

Patient-Level Consent Records

Patient-level consent provides the most granular control:

• General patient consent: Applies to the patient across all facilities in the federation
• Facility-specific patient consent: Applies only to the patient's data at a designated facility
• Patient consent takes the highest precedence in the hierarchy
• Can be recorded through the Management Portal, consent collection workflows, or XACML import

---

Overview

Consent groups are a mechanism for organizing clinicians into logical groupings that share common consent access permissions. Instead of defining consent rules for individual clinicians, administrators create groups and assign clinicians to them. Consent policies then reference these groups to determine who can access what data.

Creating Consent Groups

To create a consent group:

• Navigate to HealthShare > Registry Management > Consent Management > Consent Groups
• Click "Create New Group"
• Provide a group name and description
• Define the group's scope and purpose (e.g., "Emergency Department Staff", "Primary Care Physicians")
• Optionally assign the group as a child of an existing parent group

Assigning Users to Consent Groups

Clinicians are assigned to consent groups through:

• The Consent Group management interface in the Management Portal
• Selecting individual clinicians from the clinician registry and adding them to groups
• Bulk assignment using task-based workflows (see Section 8)
• Integration with external identity management systems

How Consent Groups Affect Access

When a consent policy references a consent group:

• Members of the group receive the access permissions defined in the policy
• Non-members are not affected by the group-specific policy
• A clinician can belong to multiple groups; all applicable group policies are evaluated
• Group membership is checked at query time, so changes take effect immediately

Group Hierarchy

Consent groups support hierarchical organization:

• A parent group can contain child groups
• Child group members inherit the consent access of the parent group
• Child groups can have additional or more restrictive consent rules
• The hierarchy allows broad groups (e.g., "All Clinicians") with specialized subgroups (e.g., "Behavioral Health Clinicians")

---

Clinical Information Qualifiers

Qualifiers refine consent decisions beyond simple allow/deny:

• Role-based qualifiers: Consent varies based on the clinician's role (physician, nurse, admin)
• Purpose-based qualifiers: Consent varies based on access purpose (treatment, payment, research)
• Time-based qualifiers: Consent has effective date ranges and can expire automatically
• Facility-based qualifiers: Consent further refined by the facility context of the request

Configuring Qualifiers

To configure clinical information qualifiers:

• Navigate to Consent Management > Clinical Information Qualifiers
• Create qualifier definitions specifying the qualifier type and valid values
• Associate qualifiers with consent policies to add contextual conditions
• Qualifiers are evaluated against the requesting clinician's attributes at query time

Clinical Information Types (CITs)

CITs categorize clinical data for granular consent control:

• Each CIT represents a category of clinical information (e.g., Medications, Lab Results, Mental Health)
• CITs are mapped to SDA streamlet types so the system knows which data belongs to which category
• Consent policies can reference CITs to allow or deny specific categories independently
• Common sensitive CITs include: Behavioral Health, Substance Abuse, HIV/AIDS, Reproductive Health

The Consent Rules Engine

The rules engine evaluates consent decisions dynamically: 1. Identify the clinical data being requested and its CIT classification 2. Retrieve applicable consent policies for the patient, facility, and system levels 3. Evaluate qualifiers against the requesting clinician's context 4. Apply rules in priority order; the first matching rule determines visibility 5. If no rule matches, the default consent behavior applies

Creating Consent Rules

To create a consent rule:

• Navigate to Consent Management > Clinical Information Rules
• Define the target CIT, conditions, action (show/hide), and priority
• Associate the rule with the appropriate consent level
• Test the rule with representative scenarios to verify expected behavior

---

Overview

Consent options define the set of choices available when recording a patient's consent preferences. They provide a structured way to capture patient consent decisions and map those decisions to the underlying consent policy framework.

Consent Option Types

UCR supports configurable consent option types:

• Share All: Patient consents to sharing all clinical data across the federation
• Share Partial: Patient consents to sharing some data categories but restricts others
• Deny All: Patient denies sharing of all clinical data
• Facility-Specific Share: Patient consents to sharing data from specific facilities only
• Category-Specific: Patient consents or denies based on clinical information categories (CITs)

Configuring Consent Options

To configure consent options:

• Navigate to HealthShare > Registry Management > Consent Management > Consent Options
• Define the available consent option types for the organization
• Configure which CITs each option type affects
• Set the mapping between consent options and the underlying consent policy actions
• Define the presentation order for consent collection forms

Default Consent Options

Default options determine what happens when no explicit patient consent has been recorded:

• The default option aligns with the system-level consent model (opt-in or opt-out)
• In opt-out mode, the default option is typically "Share All"
• In opt-in mode, the default option is typically "Deny All"
• Default options can be overridden at the facility level

Integration with Consent Collection

Consent options integrate with consent collection workflows:

• Consent coordinators see the configured options when recording patient preferences
• Patient portals can present consent options for self-service consent management
• Imported consent documents are mapped to the configured consent option types
• Audit trails record which consent option was selected and when

---

Overview

Break the Glass (BTG) is an emergency override mechanism that allows authorized clinicians to access patient data that is normally restricted by consent policies. BTG is essential for patient safety in emergency situations where consent cannot be obtained in time, but it must be carefully controlled and audited to prevent misuse.

When BTG Is Triggered

BTG is triggered when:

• A clinician searches for a patient whose MPI consent denies visibility
• A clinician attempts to view clinical data restricted by clinical consent or CIT rules
• The system presents a BTG prompt instead of silently denying access
• The clinician chooses to override the restriction by declaring an emergency

Configuring BTG Settings

BTG configuration includes:

• Enabled/disabled: BTG can be enabled or disabled at the system level
• Authorized roles: Define which clinician roles are permitted to invoke BTG
• Required fields: Configure what information the clinician must provide (reason, patient relationship, emergency type)
• Data scope: Define what data becomes accessible during a BTG event (all data, specific CITs, time-limited access)
• Duration: Configure how long the BTG override remains active before the clinician must re-authenticate

Configuring BTG in the Management Portal

To configure BTG:

• Navigate to HealthShare > Registry Management > Consent Management > Break the Glass
• Enable or disable BTG for the federation
• Define the authorized roles that can invoke BTG
• Configure the required reason codes and free-text fields
• Set the BTG duration and data scope parameters
• Configure audit notification settings

Auditing BTG Events

BTG events generate enhanced audit records:

• The clinician's identity, role, and location are recorded
• The reason provided for the override is stored
• The patient whose data was accessed is identified
• The specific data viewed during the BTG session is logged
• Audit records are flagged for review by compliance officers
• Automated notifications can be sent to privacy officers when BTG is invoked

Best Practices

• Regularly review BTG audit logs for potential misuse
• Limit BTG to roles that genuinely need emergency access (e.g., emergency physicians)
• Require meaningful reason codes rather than generic "emergency" selections
• Implement post-hoc review processes with accountability for inappropriate BTG use
• Test BTG scenarios during implementation to verify correct behavior

---

Overview

Managing consent groups individually through the Management Portal is practical for small numbers of clinicians, but organizations with large numbers of users need efficient bulk management capabilities. UCR provides task-based workflows that enable administrators to perform consent group operations at scale.

Task-Based Consent Group Operations

Available task operations include:

• Bulk add to group: Add multiple clinicians to a consent group from a list or file
• Bulk remove from group: Remove multiple clinicians from a consent group
• Group transfer: Move clinicians from one group to another
• Group synchronization: Synchronize group membership with an external directory or identity system
• Group cleanup: Remove inactive or deactivated clinicians from groups

Creating and Running Tasks

To create a consent group management task:

• Navigate to HealthShare > Registry Management > Tasks
• Select the consent group task type
• Configure the task parameters (target group, operation type, clinician list or source)
• Optionally schedule the task for automatic execution
• Run the task manually or wait for the scheduled execution

Bulk Operations and Scheduling

Tasks support file-based bulk operations and automation:

• Upload CSV files containing clinician identifiers for bulk add/remove operations
• Schedule recurring tasks to synchronize group membership with external systems
• Automate group updates when new clinicians are registered or deactivated
• All task-based changes are audited with the task identifier, administrator, and timestamp

---