T10.1: Implements Consent Policies

Overview

UCR implements a hierarchical consent management framework with three levels of policy granularity. This hierarchy allows organizations to establish broad default policies while enabling exceptions at the facility and individual patient levels. Understanding how these levels interact and override each other is essential for exam preparation.

System-Wide Level

System-wide policies are the broadest and serve as the default for the entire federation:

• Apply to every facility and every patient unless overridden
• Establish the baseline consent posture (opt-in or opt-out)
• Created and managed at the Registry (Hub)
• Should reflect the organization's overall consent philosophy and regulatory requirements

Facility-Level

Facility-level policies apply to specific facilities within the federation:

• Override system-wide policies for the designated facility
• Allow individual facilities to have stricter or more permissive consent rules
• Useful when different facilities operate under different regulatory requirements
• Managed at the Registry but scoped to specific facility identifiers

Patient-Level

Patient-level policies are the most specific and take highest precedence:

• Apply to an individual patient's data
• Can be general (applying across all facilities) or facility-specific
• Override both system-wide and facility-level policies
• Represent the patient's explicit consent choices
• Managed through the consent management interface at the Registry

Precedence Rules

When multiple policies apply, the most specific policy wins: 1. Patient-level facility-specific consent (most specific) 2. Patient-level general consent 3. Facility-level consent 4. System-wide consent (least specific, default)

---

Overview

UCR separates consent into two distinct tracks: MPI consent and clinical consent. These tracks operate independently, and understanding the difference is critical for implementing consent policies correctly and for exam questions about consent behavior.

MPI Consent

MPI consent controls the visibility of a patient's identity in the Master Patient Index:

• Allow: The patient's identity is included in MPI search results. Clinicians searching for the patient will find them.
• Deny: The patient's identity is excluded from MPI search results. The patient effectively becomes invisible to searchers. No clinical data can be accessed because the patient cannot be found.

MPI consent is a binary decision: the patient either appears in searches or does not. There is no partial MPI consent.

Clinical Consent

Clinical consent controls what clinical data is visible once a patient has been found:

• Allow: Clinical data from the specified scope (all facilities, specific facility, etc.) is visible to authorized clinicians.
• Deny: Clinical data from the specified scope is hidden from clinicians, even if they can find the patient via MPI search.

Clinical consent can be granular, controlling visibility of specific types of clinical information through Clinical Information Types (CITs).

Interaction Between MPI and Clinical Consent

The two tracks interact as follows:

• If MPI consent is denied, the patient is completely hidden regardless of clinical consent settings
• If MPI consent is allowed but clinical consent is denied, the patient appears in searches but no clinical data is displayed
• If both are allowed, the patient is visible and their clinical data is accessible (subject to CIT-level restrictions)

This dual-track model provides organizations with flexible options for protecting patient privacy at different levels.

---

Overview

The system-wide MPI consent policy establishes the default behavior for patient visibility across the entire federation. This is the most fundamental consent decision and affects every patient who does not have a more specific consent policy.

Creating the System-Wide MPI Consent Policy

Configuration steps include:

• Navigate to the consent management section in the Registry Management Portal
• Create or modify the system-wide MPI consent policy
• Select the consent model (opt-in or opt-out)
• Define the default behavior for patient identity visibility

Opt-In vs Opt-Out for MPI

• Opt-in: Patients are hidden from MPI searches by default. Each patient must explicitly consent to be visible. This model provides maximum privacy protection but requires more administrative effort to collect consent.
• Opt-out: Patients are visible in MPI searches by default. Patients must explicitly request to be hidden. This model enables broader data sharing by default but requires mechanisms for patients to opt out.

Considerations for System-Wide MPI Policy

• Regulatory requirements may dictate the consent model (some jurisdictions require opt-in)
• The chosen model affects clinical workflow (opt-in requires consent collection before data sharing)
• Emergency override mechanisms should be available regardless of the consent model
• The system-wide policy applies only when no facility-level or patient-level MPI consent exists

---

Overview

The system-wide clinical consent policy determines the default visibility of clinical data across the federation. While the MPI consent controls whether a patient can be found, the clinical consent controls what data is shown once the patient is found.

Creating the System-Wide Clinical Consent Policy

Configuration steps include:

• Navigate to the consent management section in the Registry Management Portal
• Create or modify the system-wide clinical consent policy
• Define the default behavior for clinical data visibility
• Optionally configure default Clinical Information Type (CIT) restrictions

Policy Options

The system-wide clinical consent policy can specify:

• Whether clinical data is visible or hidden by default
• Which categories of clinical information are included or excluded
• Whether the policy applies equally to all clinical data types or differentiates by category
• Time-based restrictions (if supported by the version)

Interaction with MPI Consent

The system-wide clinical consent works in conjunction with the system-wide MPI consent:

• Both must allow access for a patient's data to be fully visible
• MPI consent being denied overrides clinical consent (patient cannot be found)
• Clinical consent being denied while MPI consent is allowed results in the patient being findable but with no visible clinical data

Regulatory Considerations

System-wide clinical consent policies should account for:

• HIPAA minimum necessary standards
• State-specific consent requirements
• Sensitive data categories (mental health, substance abuse, HIV, reproductive health)
• Break-the-glass emergency access requirements

---

Overview

Facility-level consent policies allow individual facilities within the federation to have consent rules that differ from the system-wide defaults. This is necessary when facilities operate under different regulatory requirements, serve different patient populations, or have different organizational consent philosophies.

Creating Facility-Level MPI Consent

To create a facility-level MPI consent policy:

• Navigate to consent management at the Registry
• Select the target facility from the system registry
• Create an MPI consent policy that overrides the system-wide MPI default for this facility
• This policy affects only patients whose data originates from this facility

Creating Facility-Level Clinical Consent

To create a facility-level clinical consent policy:

• Navigate to consent management at the Registry
• Select the target facility
• Create a clinical consent policy specifying how clinical data from this facility is handled
• Can include CIT-level restrictions specific to the facility

Use Cases for Facility-Level Policies

Common scenarios include:

• A behavioral health facility requiring stricter consent (opt-in) for clinical data sharing while the system-wide default is opt-out
• A facility in a state with specific consent laws that differ from the federation's default
• A research facility that needs separate consent tracking for research data
• A facility that has agreements with patients about how their data will be shared

Policy Scope

Facility-level policies affect:

• Data originating from the specified facility
• Patient visibility when searching from the context of that facility
• Clinical data display when data was collected at that facility

---

Overview

Patient-level consent policies provide the most granular consent control, allowing individual patients to have consent settings that override both system-wide and facility-level defaults. These policies are the highest precedence in the consent hierarchy.

General Patient Consent

A general patient consent policy applies to the patient across all facilities:

• Overrides system-wide and facility-level defaults for this patient
• Can set MPI consent (visible or hidden in all searches)
• Can set clinical consent (data visible or hidden from all facilities)
• Useful when a patient has a blanket preference that should apply everywhere

Facility-Specific Patient Consent

A facility-specific patient consent applies to the patient only at a particular facility:

• Overrides all other consent levels for this patient at this facility
• Allows a patient to consent to sharing data from one facility but not another
• Enables nuanced consent decisions based on the patient's relationship with each facility
• Most granular level of consent control in the hierarchy

Managing Patient-Level Consent

Patient-level consent policies are managed through:

• The consent management interface at the Registry
• Administrative tools for consent coordinators
• Potentially through patient-facing consent collection workflows
• Import of XACML consent documents from external systems

Exam-Relevant Scenarios

Typical exam scenarios involving patient-level consent:

• A patient opts out of sharing data from a behavioral health facility but consents to sharing data from their primary care facility
• A patient requests complete removal from MPI searches (MPI deny at patient level)
• A patient consents to sharing all data except substance abuse records (requires CIT-level control)

---

Overview

The choice between opt-in and opt-out consent models is one of the most significant decisions in UCR deployment. This choice affects clinical workflows, patient privacy, and data availability across the federation.

Opt-In Model

In an opt-in model:

• Patient data is hidden by default (not shared across the federation)
• Each patient must provide explicit consent before their data becomes visible
• Until consent is obtained, clinical data stays isolated at the originating facility
• Provides the strongest default privacy protection
• Requires robust consent collection workflows to be effective

Advantages:

• Maximum privacy protection by default
• Aligns with strict privacy regulations
• Patients maintain control over their data from the start

Challenges:

• Requires significant administrative effort to collect consent
• Delays data sharing until consent is obtained
• May impede care coordination if consent is not collected in a timely manner
• Emergency access mechanisms become critical

Opt-Out Model

In an opt-out model:

• Patient data is shared by default across the federation
• Patients must actively request that their data be restricted
• Enables immediate data sharing when new facilities join the federation
• Provides the broadest data availability for clinical care

Advantages:

• Maximum data availability for care coordination
• Minimal administrative burden for consent collection
• Aligns with implied consent principles in many jurisdictions
• Better supports care continuity across facilities

Challenges:

• Some patients may not be aware their data is being shared
• May not comply with strict opt-in regulatory requirements
• Requires clear notification to patients about data sharing
• Opt-out mechanisms must be easily accessible to patients

Hybrid Approaches

UCR's hierarchical consent system allows hybrid approaches:

• System-wide opt-out with facility-level opt-in for sensitive facilities
• Opt-out for MPI visibility with opt-in for specific clinical data categories
• Different models at different levels of the hierarchy

---

Overview

Consent groups provide an organizational mechanism for managing consent policies at scale. When a federation has many facilities and complex consent requirements, groups allow administrators to organize policies logically and establish inheritance relationships between groups.

Creating Consent Groups

Consent groups are created at the Registry and can represent:

• Organizational units (e.g., "Hospital System A", "Clinic Network B")
• Geographic regions (e.g., "Eastern Region", "Western Region")
• Regulatory zones (e.g., "State X Compliance", "State Y Compliance")
• Care categories (e.g., "Behavioral Health", "Primary Care")

Group Hierarchy

Groups can be organized in a tree structure:

• Parent groups establish baseline consent policies
• Child groups inherit policies from their parent
• Child groups can override parent policies for their specific scope
• The most specific (deepest) group in the hierarchy takes precedence

Precedence Within the Group Hierarchy

When evaluating effective consent for a patient: 1. Check for patient-level consent (highest precedence, outside group hierarchy) 2. Check for the most specific group that applies 3. Walk up the group hierarchy if no specific group policy exists 4. Fall back to the system-wide default if no group policies apply

Best Practices for Group Organization

• Align groups with the organizational structure of the federation
• Avoid overly deep hierarchies that are difficult to understand and troubleshoot
• Document the group structure and its intended consent behavior
• Regularly review group assignments as facilities join or leave the federation
• Test consent behavior at each level of the hierarchy

---

Overview

Consent qualifiers add dimensions of control beyond the basic allow/deny decision. They enable policies that account for who is accessing data, why they are accessing it, and when the access is permitted. Qualifiers make the consent framework flexible enough to handle complex real-world consent scenarios.

Types of Consent Qualifiers

Common qualifier types include:

Role-Based Qualifiers:

• Consent can differ based on the clinician's role (physician, nurse, administrator, researcher)
• A patient might consent to physicians viewing their data but deny access to administrative staff
• Role qualifiers reference role definitions in the clinician registry

Purpose-Based Qualifiers:

• Consent can vary by purpose of access: treatment, payment, healthcare operations, research, public health
• A patient might consent to data sharing for treatment but deny access for research purposes
• Purpose qualifiers align with HIPAA's defined purposes of use

Time-Based Qualifiers:

• Consent policies can have effective start and end dates
• A patient might grant temporary access for a specific treatment period
• Expired consent policies automatically cease to apply

Facility-Based Qualifiers:

• Further refine facility-level consent with additional conditions
• A patient might consent to data sharing from a specific facility only for emergency purposes

Qualifier Evaluation

When evaluating consent with qualifiers:

• All applicable qualifiers must be satisfied for access to be granted
• If any qualifier denies access, the overall consent is denied
• Qualifiers are evaluated in the context of the accessing user's attributes (role, purpose, etc.)

---

Overview

Clinical Information Types (CITs) provide the mechanism for controlling consent at the clinical data category level rather than the all-or-nothing level. By defining CITs, administrators can create consent policies that allow sharing of some types of clinical data while restricting others.

Creating CITs

CITs are created by mapping clinical information categories to consent-controlled types:

• Define a CIT for each category of clinical data that needs independent consent control
• Common CITs include: Diagnoses, Medications, Lab Results, Procedures, Mental Health, Substance Abuse, HIV/AIDS, Reproductive Health, Genetic Information
• Associate each CIT with the clinical data elements it encompasses

CIT Examples

Typical CIT definitions:

• General Medical: Routine clinical data (vital signs, immunizations, allergies)
• Behavioral Health: Mental health diagnoses, treatment plans, therapy notes
• Substance Abuse: Substance use disorder diagnoses and treatment records (often subject to 42 CFR Part 2)
• HIV/AIDS: HIV test results and treatment information
• Reproductive Health: Pregnancy, fertility treatment, contraception records
• Genetic Information: Genetic test results and counseling notes

CIT-Based Consent Policies

Once CITs are defined, consent policies can reference them:

• A system-wide policy might share all CITs except Behavioral Health
• A patient-level policy might deny the Substance Abuse CIT while allowing all others
• Facility-level policies might restrict specific CITs based on regulatory requirements

CIT Mapping to Data

CITs must be mapped to actual clinical data categories in the SDA:

• Map SDA streamlet types to CITs
• Ensure all clinical data is covered by at least one CIT
• Data not mapped to any CIT follows the default consent behavior

---

Overview

Clinical Information Rules define the logic for how Clinical Information Types (CITs) translate into actual data visibility decisions. While CITs categorize data, rules determine the conditions under which each category is shown, hidden, or partially revealed.

Rule Components

Each clinical information rule specifies:

• Target CIT: Which Clinical Information Type the rule applies to
• Condition: The circumstances under which the rule fires (consent state, qualifiers, etc.)
• Action: What happens when the rule fires (show, hide, redact, flag)
• Priority: The order in which rules are evaluated when multiple rules apply

Rule Evaluation

When a clinician requests patient data: 1. The system identifies all applicable CITs for the requested data 2. For each CIT, the system evaluates applicable rules 3. Rules are evaluated in priority order 4. The first matching rule determines the visibility of the data 5. If no rule matches, the default consent behavior applies

Creating Rules

Steps to create clinical information rules:

• Navigate to the consent configuration in the Registry Management Portal
• Define the rule with its target CIT, condition, action, and priority
• Associate the rule with the appropriate consent policy level (system, facility, or patient)
• Test the rule with sample data to verify expected behavior

Common Rule Patterns

• Default deny with explicit allow: Hide all data for a CIT unless a specific consent allows it
• Default allow with explicit deny: Show all data for a CIT unless a specific restriction exists
• Role-based visibility: Show data for a CIT only when the requesting clinician has a specific role
• Emergency override: Allow access to restricted CITs when an emergency break-the-glass event is declared

---

Overview

XACML (eXtensible Access Control Markup Language) is a standard format for expressing access control policies, including patient consent. UCR supports importing XACML consent documents, which enables integration with external consent management systems and standard-based consent exchange.

XACML Structure

An XACML consent document typically contains:

• Policy Set: The top-level container for consent policies
• Policy: Individual consent rules within the set
• Target: Conditions that determine when the policy applies
• Rule: The specific allow/deny decision with conditions
• Obligation: Additional actions to perform when the rule applies

UCR XACML Interpretation

When UCR imports an XACML document:

• Policy sets are mapped to UCR consent groups
• Individual policies are translated to UCR consent policies at the appropriate level
• Targets are interpreted to determine the scope (system, facility, or patient level)
• Rules are translated to allow/deny decisions with applicable qualifiers
• Obligations may trigger additional UCR consent behaviors

Group Mappings

XACML policy elements map to UCR consent groups:

• XACML policy set identifiers can correspond to UCR group identifiers
• Hierarchical XACML policy sets map to the UCR group hierarchy
• Group mappings must be configured before XACML import for correct interpretation

SNOMED Role Codes

XACML consent documents use SNOMED CT codes to express clinician roles:

• Role codes specify which types of clinicians are affected by the consent policy
• UCR maps SNOMED role codes to its internal clinician role definitions
• Common role codes include those for physicians, nurses, pharmacists, and other healthcare professionals
• The mapping between SNOMED codes and UCR roles must be configured for correct XACML interpretation

Practical Considerations

• Validate XACML documents before import to ensure correct format
• Test imported policies to verify they produce the expected consent behavior
• Maintain the XACML-to-UCR mapping configuration as roles and groups evolve
• Consider using XACML export to share consent policies with external systems

---

Overview

UCR provides utilities for importing and exporting consent policies. These utilities support backup and restore, migration between environments, and integration with external consent management systems.

Import Utility

The consent import utility allows:

• Loading consent policies from XACML documents
• Importing UCR-native consent policy exports
• Bulk import of multiple patient consent records
• Importing facility and system-level consent policies
• Validation of imported policies before applying them

Export Utility

The consent export utility provides:

• Export of all consent policies or filtered subsets
• Export in XACML format for sharing with external systems
• Export in UCR-native format for backup and migration
• Patient-specific consent export for patient data portability
• Facility-level and system-level policy export

Migration Scenarios

Common use cases for import/export:

• Environment migration: Moving consent policies from development to test to production
• Disaster recovery: Restoring consent policies from backup after a system failure
• Federation expansion: Sharing consent policy templates with new facilities joining the federation
• Regulatory compliance: Exporting consent records for audit or legal review
• System integration: Exchanging consent policies with external consent management systems

Best Practices

• Regularly export consent policies as part of the backup strategy
• Validate imported policies in a test environment before applying to production
• Document the format and version of exported policies for compatibility
• Include consent policy export in the pre-upgrade checklist
• Audit import operations to track when and by whom policies were changed

---

Overview

When a clinician searches for a patient or views clinical data, UCR must evaluate potentially multiple consent policies at different levels to determine the effective consent. Understanding the precedence rules is critical for predicting system behavior and for exam questions.

Evaluation Process

UCR evaluates consent in the following order:

Step 1: MPI Consent Evaluation 1. Check for patient-level MPI consent (facility-specific, then general) 2. If no patient-level MPI consent, check facility-level MPI consent 3. If no facility-level MPI consent, use system-wide MPI consent 4. If MPI consent is denied at any applicable level, the patient is hidden from searches. No further evaluation is needed.

Step 2: Clinical Consent Evaluation (only if MPI consent allows) 1. Check for patient-level clinical consent (facility-specific, then general) 2. If no patient-level clinical consent, check facility-level clinical consent 3. If no facility-level clinical consent, use system-wide clinical consent 4. Within clinical consent, evaluate CIT-level rules for each data category 5. Apply qualifier-based refinements (role, purpose, time)

Effective Consent Determination

The effective consent for any given access request is the result of:

• The applicable MPI consent (determines visibility)
• The applicable clinical consent (determines data access)
• CIT-level rules (determine category-level access)
• Qualifier evaluation (determine context-specific access)
• Override status (break-the-glass emergency access)

Break-the-Glass

UCR supports emergency override (break-the-glass) mechanisms:

• Allows clinicians to access data that would otherwise be restricted by consent
• Generates enhanced audit events documenting the override
• Requires the clinician to provide a reason for the override
• Subject to post-hoc review and accountability

Common Precedence Scenarios for Exam Preparation

• System-wide allows sharing, facility denies, patient allows: Patient-level wins (data shared)
• System-wide denies sharing, facility allows, no patient consent: Facility-level wins (data shared)
• MPI denied at patient level, clinical allowed at all levels: Patient hidden (MPI denial overrides)
• Clinical denied at system level, allowed at patient level for one CIT: Patient data restricted except for the specifically allowed CIT

---