T12.2: Manages Registries

Overview

The Gateway Registry at the Hub maintains the authoritative list of all Edge Gateways and Access Gateways participating in the UCR federation. Every gateway must be registered with the Hub before it can participate in data exchange, patient lookup, or clinical data retrieval. The registration process establishes the communication channel between the gateway and the Hub, including endpoint URLs, security certificates, and configuration parameters.

Proper gateway registration is foundational to the UCR federation, as unregistered gateways cannot communicate with the Hub or other federation components.

Edge Gateway Registration

1. Access the Gateway Registry through the Hub Management Portal 2. Create a new Edge Gateway entry 3. Provide the gateway's endpoint URL and web server details 4. Configure SSL/TLS certificate information for secure communication 5. Set the gateway's name, description, and associated facility 6. Configure communication parameters (timeout, retry settings) 7. Activate the gateway registration 8. Test connectivity between the Hub and the newly registered Edge Gateway

Access Gateway Registration

1. Create a new Access Gateway entry in the Gateway Registry 2. Provide the Access Gateway's endpoint URL 3. Configure SSL/TLS settings 4. Associate the Access Gateway with the facilities it serves 5. Set Clinical Viewer access parameters 6. Activate and test the registration

Gateway Registration Properties

• Name: Unique identifier for the gateway within the federation
• Endpoint URL: The web service endpoint for Hub-to-gateway communication
• Type: Edge Gateway or Access Gateway
• Facility Association: Which facility or facilities the gateway serves
• Status: Active, inactive, or suspended
• Certificates: SSL/TLS certificates for secure communication
• Communication Settings: Timeout, retry, and connection pool parameters

---

Overview

The Facility Registry maintains information about all healthcare facilities participating in the UCR federation. Facilities represent the organizations that contribute clinical data (hospitals, clinics, laboratories, etc.). Each facility is associated with one or more Edge Gateways that handle its data ingestion, and with assigning authorities that define its patient identifier domains.

The Facility Registry provides the organizational context for data in the federation, allowing the system to track which facility originated specific data and enabling facility-based filtering and access control.

Managing Facilities

1. Access the Facility Registry through the Hub Management Portal 2. Create a new facility entry or modify an existing one 3. Provide facility details: name, identifiers, address, type 4. Set the facility's organizational hierarchy (parent organization, department) 5. Associate the facility with its Edge Gateway(s) 6. Link the facility to its assigning authorities

Facility-Gateway Relationships

• Each facility must be associated with at least one Edge Gateway
• A facility can be associated with multiple Edge Gateways (e.g., separate feeds for different departments)
• A single Edge Gateway can serve multiple facilities (common in smaller organizations)
• The facility-gateway association determines where data from that facility is processed and stored
• Changes to gateway associations affect data routing and storage

Facility Properties

• Name: Official facility name
• Identifiers: Facility codes, NPI numbers, OIDs
• Address: Physical location details
• Type: Hospital, clinic, laboratory, pharmacy, imaging center, etc.
• Parent Organization: Organizational hierarchy for multi-facility systems
• Status: Active or inactive
• Contact Information: Administrative contacts for the facility

---

Overview

The Assigning Authority Registry manages the organizations and systems responsible for assigning patient identifiers within the federation. Each facility typically has one or more assigning authorities that issue patient identifiers (medical record numbers, account numbers, etc.). The assigning authority defines a unique identifier domain, ensuring that identifiers from different facilities are properly distinguished and matched across the federation.

Proper assigning authority configuration is critical for accurate patient identification and MPI matching.

Managing Assigning Authorities

1. Access the Assigning Authority Registry through the Hub Management Portal 2. Create a new assigning authority or modify an existing one 3. Define the authority name, OID, and identifier type 4. Link the assigning authority to the facility or facilities that use it 5. Configure MPI matching rules for identifiers from this authority

Linking Assigning Authorities to Facilities

• Each facility has at least one assigning authority for its primary patient identifiers
• Large health systems may share an assigning authority across multiple facilities (enterprise MRN)
• Some facilities may have multiple assigning authorities (different systems assigning different ID types)
• The linkage determines how incoming patient identifiers are interpreted during data ingestion
• Changes to linkages affect patient matching and identification

Assigning Authority Properties

• Name: Descriptive name for the assigning authority
• OID: Unique Object Identifier for IHE interoperability
• Identifier Type: Type of identifier issued (MRN, account number, SSN, insurance ID)
• Facility Association: Which facilities use this assigning authority
• Status: Active or inactive
• Universal ID: Additional identifier for cross-system reference

---

Overview

The Cohort Registry manages named groups of patients (cohorts) that can be used for access control, reporting, research, and care program management. Cohorts can be static (manually managed membership) or dynamic (membership determined by rules that automatically evaluate patient characteristics). The Cohort Registry provides tools for creating, editing, and monitoring cohort definitions and membership.

Creating and Editing Cohorts

1. Access the Cohort Registry through the Hub Management Portal 2. Create a new cohort with a descriptive name and purpose 3. Choose the cohort type: static or dynamic 4. For static cohorts: manually add and remove patient members 5. For dynamic cohorts: define the criteria/rules that determine membership 6. Save the cohort definition 7. Verify membership is correct

Managing Patient Membership

• Static Cohorts: Add patients individually or in bulk. Remove patients as needed. Membership is explicit and does not change automatically.
• Dynamic Cohorts: Define criteria such as diagnosis codes, age ranges, facility associations, or other patient characteristics. The system evaluates criteria to determine current membership. Membership changes automatically as patient data changes.

Dynamic Cohort Configuration

• Define membership criteria using available patient data properties
• Criteria can include: demographic attributes, diagnosis codes, facility of care, identifier types, care programs
• Multiple criteria can be combined with AND/OR logic
• Set the evaluation frequency (how often membership is recalculated)
• Dynamic cohorts may have a delay between data changes and membership updates

Troubleshooting Dynamic Cohorts

• Patient Not in Expected Cohort: Verify the patient's data meets all cohort criteria; check for data quality issues
• Membership Not Updating: Verify the evaluation schedule is running; check for errors in criteria evaluation
• Incorrect Criteria Logic: Review AND/OR combinations; test with known patients who should/should not be members
• Performance Issues: Overly complex criteria may slow evaluation; simplify criteria or adjust evaluation frequency
• Data Latency: New data may not yet be available for cohort evaluation; check data ingestion timing

---

Overview

The Service Registry manages entries for IHE (Integrating the Healthcare Enterprise) interoperability services used by the UCR federation. IHE profiles define standardized ways for healthcare systems to exchange information, and the Service Registry tracks the endpoints and configuration for each service. Key IHE profiles used in UCR include PIX, PDQ, XDS.b, and XCA.

IHE Profile Services

• PIX (Patient Identity Cross-Reference): Cross-references patient identifiers across different identifier domains. Enables looking up a patient's MRN at Hospital A given their MRN at Hospital B.
• PDQ (Patient Demographics Query): Queries patient demographics from the MPI. Used for patient search and verification.
• XDS.b (Cross-Enterprise Document Sharing): Shares clinical documents across the federation. Manages document registration, storage, and retrieval.
• XCA (Cross-Community Access): Enables document sharing across community boundaries. Used when UCR federations need to exchange data with external communities.

Managing Service Entries

1. Access the Service Registry through the Hub Management Portal 2. Create or edit service entries for each IHE profile 3. Configure endpoint URLs for each service 4. Set communication parameters (SOAP version, security, timeout) 5. Associate entries with the appropriate production type (Hub, Edge, Access) 6. Activate the service entry

Service Entry Properties

• Service Name: Identifier for the service
• IHE Profile: The IHE profile implemented (PIX, PDQ, XDS.b, XCA)
• Endpoint URL: The web service endpoint
• Production Type: Which production type hosts this service
• SOAP Action: The SOAP action URIs for the service operations
• Security Settings: Authentication, SSL/TLS, and WS-Security configuration
• Status: Active or inactive

Entries for Different Production Types

• Hub Production: Hosts central services (PIX Manager, PDQ Supplier, XDS Registry)
• Edge Gateway Production: Hosts data contribution services (XDS Document Source, PIX Consumer)
• Access Gateway Production: Hosts data retrieval services (XDS Document Consumer, XCA Initiating Gateway)

---

Overview

The OID (Object Identifier) Registry manages the assignment and tracking of Object Identifiers used throughout the UCR federation for IHE interoperability. OIDs are globally unique identifiers in a hierarchical dot-notation format that uniquely identify organizations, systems, coding systems, document types, and other entities. IHE profiles require OIDs to ensure unambiguous identification of entities across organizational boundaries.

OID Management

1. Access the OID Registry through the Hub Management Portal 2. View existing OID assignments 3. Create new OID assignments for new entities 4. Associate OIDs with the appropriate entities (organizations, systems, coding systems) 5. Maintain a consistent OID hierarchy

OID Assignment Categories

• Organization OIDs: Identify healthcare organizations and facilities
• System OIDs: Identify information systems and applications
• Coding System OIDs: Identify coding systems and vocabularies (LOINC, SNOMED, etc.)
• Document Type OIDs: Identify types of clinical documents
• Assigning Authority OIDs: Identify patient identifier assigning authorities
• Repository OIDs: Identify document repositories

OID Hierarchy

• OIDs follow a hierarchical structure under a root OID
• Organizations typically have a registered root OID from a standards body
• Sub-branches are created for different entity types
• Example hierarchy:
• Root: 2.16.840.1.113883.x (organization root)
• Systems: 2.16.840.1.113883.x.1 (systems branch)
• Coding Systems: 2.16.840.1.113883.x.2 (coding systems branch)
• Authorities: 2.16.840.1.113883.x.3 (assigning authorities branch)

---

Overview

The Configuration Registry provides centralized management of system-wide configuration settings for the UCR federation. These settings control various aspects of system behavior, from security policies to communication parameters to display defaults. Managing the Configuration Registry at the Hub ensures consistent configuration across all federation components, while allowing certain settings to be overridden at the gateway level for site-specific requirements.

Managing Configuration Settings

1. Access the Configuration Registry through the Hub Management Portal 2. Browse settings by category 3. View current values and descriptions for each setting 4. Modify settings as needed 5. Save changes and distribute to federation components

Setting Categories

• System Behavior: Core system parameters (timeout values, batch sizes, processing modes)
• Security: Authentication settings, session management, password policies
• Communication: Endpoint configuration, retry settings, connection parameters
• Display: Default display settings for the Clinical Viewer
• Integration: External system integration parameters
• Logging: Logging levels and audit configuration

Configuration Distribution

• Settings defined at the Hub are distributed to Edge Gateways and Access Gateways
• Distribution can be automatic (pushed) or manual (pulled during synchronization)
• Gateway-level overrides take precedence over Hub-level defaults for specific settings
• Track which settings have been overridden at each gateway
• Review and reconcile override settings periodically

---

Overview

The Coded Entry Registry (also known as the Code Registry) is the centralized repository for managing coded terminology entries used throughout the UCR federation. This registry stores the individual code values, descriptions, and metadata for all coding systems in the federation. It supports the terminology normalization process by providing the reference data used in translation maps and code validation.

The Coded Entry Registry is closely related to the terminology customization covered in T11.3 but is managed as a registry at the Hub level alongside other federation registries.

Adding Coded Entries

1. Access the Coded Entry Registry through the Hub Management Portal 2. Select the target coding system 3. Create a new entry with code value, description, and metadata 4. Set the entry status (active, inactive, deprecated) 5. Save the entry

Modifying Coded Entries

• Update the description or metadata of existing entries
• Change the status (e.g., deprecate an obsolete code)
• Modify associations with translation maps
• Record the reason for modification in audit metadata
• Changes are distributed to federation components

Deleting Coded Entries

• Exercise caution when deleting entries (historical data may reference them)
• Consider deprecating instead of deleting for entries no longer in active use
• Deletion removes the entry from the registry but not from existing data
• Verify no active translation maps reference the entry before deletion
• Audit the deletion for compliance tracking

Search and Browse

• Search by code value (exact or partial match)
• Search by description text (keyword search)
• Browse entries by coding system
• Filter by status (active, inactive, deprecated)
• Export search results for review or documentation

---

Overview

The User/Clinician Registry manages identity information for both system users (who log in and use UCR components) and clinicians (who are referenced in clinical data as treating providers, ordering physicians, etc.). User records control authentication and authorization, while clinician records provide the clinical context needed for data attribution, order verification, and provider-based filtering.

Some individuals may have both a user record (for system access) and a clinician record (for clinical attribution). These records can be linked to provide a complete identity profile.

Managing User Records

1. Access the User/Clinician Registry through the Hub Management Portal 2. Create new user records with username, credentials, and role assignments 3. Configure user properties (name, email, facility associations, roles) 4. Modify existing user records as needed 5. Deactivate or delete user records for departed personnel

Managing Clinician Records

• Create clinician records with provider identifiers (NPI, DEA, state license)
• Configure clinician properties (name, specialty, facility affiliations)
• Link clinician records to user records where applicable
• Maintain clinician status (active, inactive, retired)

Reindexing the User/Clinician Registry

• Reindexing rebuilds the search index for the registry
• Necessary after bulk imports, data migrations, or index corruption
• Access the reindex function through the Hub Management Portal
• Reindexing may take time for large registries; schedule during low-usage periods
• Verify search functionality after reindexing completes

Lifecycle Management

• Creation: Add new records when users join or new clinicians are added
• Modification: Update records as roles, affiliations, or credentials change
• Deactivation: Disable records for temporary absence (retain for reactivation)
• Deletion: Remove records permanently (only when appropriate and compliant with retention policies)
• Audit: Track all changes to user and clinician records

---

Overview

Identity types define the categories of patient identifiers recognized by the UCR federation. Each identifier associated with a patient has an identity type that classifies it (medical record number, social security number, insurance ID, etc.). Managing identity types involves adding new types when the federation needs to recognize new categories of identifiers and removing types that are no longer in use.

Identity types are integral to the MPI matching process, as the MPI uses identifier types and values to match patients across facilities.

Managing Identity Types

1. Access the Identity Types configuration through the Hub Management Portal 2. View the currently defined identity types 3. Add new identity types as needed 4. Configure type properties (name, description, format rules) 5. Delete obsolete identity types (with caution)

Adding Identity Types

• Define a unique name and description for the new type
• Specify format validation rules if applicable (e.g., SSN format: ###-##-####)
• Set the type's priority for MPI matching (some identifiers are more reliable for matching than others)
• Associate the type with assigning authorities that issue this type of identifier
• Test that the new type is recognized during data ingestion

Deleting Identity Types

• Verify no active data feeds use the identity type before deletion
• Check for existing patient identifiers of this type in the MPI
• Consider deprecating rather than deleting if historical data references the type
• Deletion may affect MPI matching if patients have identifiers of the deleted type
• Document the deletion and notify affected teams

---

Overview

Cross-Enterprise User Assertion (XUA) is an IHE profile that provides a standardized way to convey user identity information in cross-enterprise transactions. When UCR components exchange data using IHE profiles (XDS.b, XCA), XUA assertions identify the requesting user, enabling the responding system to make access control decisions. XUA configuration involves setting up the assertion format, signing certificates, and identity provider integration.

Creating XUA Configurations

1. Access the XUA Configuration through the Hub Management Portal 2. Create a new XUA configuration 3. Define the assertion format and content requirements 4. Configure signing certificate settings 5. Set identity provider parameters 6. Associate the configuration with the appropriate IHE services 7. Test XUA assertions in cross-enterprise transactions

XUA Configuration Settings

• Assertion Issuer: The entity issuing the SAML assertion (typically the UCR Hub or authentication service)
• Signing Certificate: X.509 certificate used to sign assertions for integrity verification
• Assertion Lifetime: How long an assertion is valid (minutes)
• Identity Attributes: Which user attributes are included in the assertion (name, role, organization, purpose of use)
• Audience Restriction: Which services can accept the assertion
• Name ID Format: How the user identity is represented in the assertion

XUA in IHE Transactions

• XUA assertions are conveyed in the SOAP header of IHE transactions
• The requesting system includes the assertion when making cross-enterprise requests
• The responding system validates the assertion and checks the user's authorization
• Assertion validation includes: signature verification, expiration check, audience verification
• Failed validation results in denied access to the requested data

Editing XUA Configurations

• Modify existing configurations to update certificates (certificate rotation)
• Adjust assertion lifetime based on security requirements
• Update identity attributes as organizational roles change
• Add or remove audience restrictions
• Test changes before deploying to production

---