T3.3: Manages and Uses Registries

Overview

HealthShare Unified Care Record relies on a set of registries to manage the metadata and configuration that drive federation operations. These registries define the participants in the federation (facilities, gateways), the rules for patient identification (assigning authorities), the grouping of patients for access and reporting (cohorts), the available interoperability endpoints (services), and system-wide behavioral settings (configuration). Without properly configured registries, the UCR federation cannot ingest data, match patients, or deliver clinical information to end users.

Purpose of Registries in UCR Operations

Registries serve as the single source of truth for federation metadata. When an Edge Gateway receives an HL7 message, the system consults the Facility Registry and Assigning Authority Registry to determine where the data came from and how to interpret patient identifiers. When the Clinical Viewer requests patient data, the Service Registry and Configuration Registry determine how the request is routed and what behavior the system exhibits. Cohort Registry entries control which patients are included in subscriptions and access-control policies.

Management Portal Access

All registries are accessed through the HealthShare Management Portal on the Hub namespace:

• Navigate to HealthShare > Registry Management in the Management Portal
• Each registry has its own management page with search, browse, add, and edit capabilities
• Administrative privileges are required to modify registry entries
• Changes to registries take effect immediately or upon the next synchronization cycle, depending on the registry type

---

Purpose and Role

The Facility Registry maintains a record of every healthcare facility participating in the UCR federation. Each facility entry defines the organization that contributes clinical data, such as a hospital, clinic, laboratory, or pharmacy. The registry maps each facility to its Edge Gateway, establishing the data routing path for clinical information flowing from that facility into the federation.

Viewing Facility Entries

1. Open the Management Portal and navigate to HealthShare > Registry Management > Facilities 2. Use the search bar to find facilities by name, code, or OID 3. Browse the list of registered facilities with their key properties displayed in a table 4. Click on a facility entry to view its full details, including gateway associations and identifiers

Adding New Facilities

1. Click Add New Facility in the Facility Registry page 2. Enter the facility name (the human-readable name used throughout the system) 3. Assign a unique facility code (used in data feeds and routing logic) 4. Provide the facility OID (Object Identifier for IHE interoperability) 5. Select the facility type (hospital, clinic, laboratory, pharmacy, imaging center) 6. Associate the facility with its Edge Gateway (select from registered gateways) 7. Add optional description and contact information 8. Save the entry

Facility Properties

• Name: Official facility name displayed in the Clinical Viewer and administrative interfaces
• Code: Unique alphanumeric code used in HL7 messages and routing rules
• OID: Globally unique Object Identifier for IHE profile transactions
• Gateway Association: The Edge Gateway that processes data from this facility
• Type: Classification of the facility (hospital, clinic, laboratory, etc.)
• Status: Active or inactive; inactive facilities do not participate in data exchange
• Description: Optional text describing the facility and its role in the federation

Best Practices

• Always assign an OID before integrating a facility with IHE profiles
• Verify the gateway association is correct before starting data feeds
• Use consistent naming conventions across all facility entries
• Deactivate rather than delete facilities that are no longer contributing data, to preserve historical references

---

Purpose and Role

The Assigning Authority Registry manages the organizations and systems that assign patient identifiers within the federation. In a multi-facility environment, multiple facilities may assign their own Medical Record Numbers (MRNs) to patients. The Assigning Authority Registry ensures that the MPI (Master Patient Index) can distinguish between an MRN from Hospital A and an MRN from Hospital B by associating each identifier with its assigning authority.

Without properly configured assigning authorities, the MPI cannot correctly match patients across facilities, leading to duplicate records or incorrect merges.

Viewing Assigning Authority Entries

1. Navigate to HealthShare > Registry Management > Assigning Authorities in the Management Portal 2. The list displays all registered assigning authorities with their name, OID, and identifier type 3. Use the search function to locate specific entries by name or OID 4. Click on an entry to view full details and associated facilities

Adding New Assigning Authority Entries

1. Click Add New Assigning Authority on the registry page 2. Enter the authority name (descriptive name identifying the source system or organization) 3. Assign the OID (required for IHE interoperability) 4. Specify the identifier type (MRN, account number, SSN, insurance ID, enterprise ID) 5. Set the universal ID and universal ID type if applicable 6. Associate the authority with the facility or facilities that use it 7. Save the entry and verify it appears in the registry list

Assigning Authority Properties

• Name: Descriptive name for the assigning authority (e.g., "Memorial Hospital MRN System")
• OID: Unique Object Identifier that distinguishes this authority in IHE transactions
• Identifier Type: The category of identifier issued (MRN, account number, SSN, insurance ID)
• Universal ID: An additional unique identifier for cross-system reference
• Universal ID Type: The type of the universal ID (ISO, DNS, UUID)
• Facility Association: Which facilities use this assigning authority to issue identifiers
• Status: Active or inactive

Relationship to MPI Matching

• The MPI uses the assigning authority and identifier value together as a compound key
• When matching patients, the MPI checks for identical identifiers within the same assigning authority domain
• Cross-referencing occurs when the MPI links identifiers from different assigning authorities to the same patient
• Incorrect assigning authority configuration is a common cause of patient matching failures

---

Purpose and Role

The Cohort Registry manages named groups of patients (and in some cases clinicians) that are used for subscriptions, clinical message delivery, access control, and reporting. Cohorts allow administrators to define meaningful populations, such as "Diabetes Patients at Memorial Hospital" or "Cardiology Department Clinicians," and then apply operations to the entire group. For example, a cohort can be used to send notifications when new lab results arrive for any patient in the group, or to restrict Clinical Viewer access to only patients in a specific cohort.

Creating Cohorts

1. Navigate to HealthShare > Registry Management > Cohorts in the Management Portal 2. Click Create New Cohort 3. Enter the cohort name and description 4. Select the cohort type: Static or Dynamic 5. For static cohorts: proceed to add members manually after creation 6. For dynamic cohorts: define the membership criteria (demographic attributes, diagnosis codes, facility, care program) 7. Save the cohort definition

Adding Members to Cohorts

• Static Cohorts: Add patients individually by searching for them, or perform bulk additions from a file or query result. Remove members as needed. Membership does not change automatically.
• Dynamic Cohorts: Members are determined by the criteria defined in the cohort. The system periodically evaluates patient data against the criteria and updates membership automatically. Administrators cannot manually add or remove members from dynamic cohorts.

Cohort-Based Operations

• Subscriptions: Subscribe a cohort to receive notifications when specific clinical events occur (new results, new documents, admissions)
• Clinical Message Delivery: Route clinical messages to clinicians based on patient cohort membership
• Access Control: Restrict Clinical Viewer access so that users can only see patients belonging to specific cohorts
• Reporting: Generate reports for cohort populations (aggregate statistics, quality measures)
• Research: Define study populations for clinical research data extraction

Troubleshooting Cohort Membership

• Verify that the patient's data meets all dynamic cohort criteria
• Check the evaluation schedule to confirm it is running on time
• Review the Event Log for errors in criteria evaluation
• Test criteria with known patients who should and should not be members
• For static cohorts, confirm the patient was explicitly added and not subsequently removed

---

Purpose and Role

The Service Registry is a central catalog of all interoperability services available in the UCR federation. It records the endpoint URLs, service types, communication parameters, and security credentials for each service. When federation components need to communicate (for example, when an Edge Gateway sends a patient identity notification to the Hub, or when the Clinical Viewer requests documents), they consult the Service Registry to locate the correct endpoint and determine how to connect to it.

Viewing Service Entries

1. Navigate to HealthShare > Registry Management > Services in the Management Portal 2. Browse the list of registered services, which shows service name, type, endpoint URL, and status 3. Filter services by type or production association 4. Click on an entry to view full details including credentials and SOAP configuration

Adding New Service Entries

1. Click Add New Service on the Service Registry page 2. Enter the service name (descriptive identifier) 3. Specify the service type (PIX Manager, PDQ Supplier, XDS Registry, XCA Gateway, etc.) 4. Provide the endpoint URL for the service 5. Configure security credentials (username/password, SSL certificate, or WS-Security settings) 6. Set SOAP action URIs if applicable 7. Associate the service with the appropriate production type (Hub, Edge, Access) 8. Set the service status to active 9. Save and test connectivity to the endpoint

Service Properties

• Name: Descriptive name identifying the service
• Type: The interoperability profile or protocol (PIX, PDQ, XDS.b, XCA, XCPD, custom)
• Endpoint URL: The web service URL where the service is accessible
• Credentials: Authentication information for connecting to the service
• SOAP Actions: SOAP action URIs for supported operations
• Production Type: Which production hosts the service (Hub, Edge Gateway, Access Gateway)
• Status: Active or inactive
• Timeout: Connection and response timeout settings

Common Service Types

• PIX Manager: Receives patient identity feed notifications and provides cross-reference queries
• PDQ Supplier: Responds to patient demographics queries from the MPI
• XDS Document Registry: Manages document metadata registration and queries
• XDS Document Repository: Stores and retrieves clinical documents
• XCA Initiating/Responding Gateway: Handles cross-community document queries and retrieval

---

Purpose and Role

The Configuration Registry provides a centralized store for system-wide configuration settings that control the behavior of the UCR federation. Rather than configuring each component individually, administrators define settings in the Configuration Registry at the Hub, and federation components read these settings at startup or on demand. This ensures consistent behavior across the federation while allowing gateway-level overrides for site-specific requirements.

Viewing Configuration Entries

1. Navigate to HealthShare > Registry Management > Configuration in the Management Portal 2. Browse settings organized by category (System, Security, Communication, Display, Integration) 3. Use the search function to locate specific settings by key name 4. Click on an entry to view its current value, description, and default value

Adding and Modifying Configuration Entries

1. Click Add New Setting or select an existing entry to edit 2. Enter or modify the key name (a descriptive, dot-separated identifier such as "system.timeout.default") 3. Set the value (string, numeric, or boolean depending on the setting) 4. Provide a description explaining the setting's purpose and valid values 5. Specify whether the setting can be overridden at the gateway level 6. Save the entry

Common Configuration Settings

• Timeout Values: Default connection and response timeouts for intercomponent communication
• Purge Settings: Message retention periods and purge schedule parameters
• Feature Toggles: Enable or disable optional features across the federation
• Display Defaults: Default Clinical Viewer settings (date format, language, page size)
• Security Parameters: Session timeout, password policies, audit logging levels
• Batch Processing: Batch sizes, processing intervals, and queue management parameters
• Notification Settings: Alert thresholds, notification delivery channels, escalation rules

How Components Read Configuration

• Components query the Configuration Registry at startup to load their settings
• Some components poll the registry periodically for updated settings
• Settings can also be pushed to components when changes are made at the Hub
• Gateway-level overrides take precedence over Hub-level defaults
• If a setting is not found in the registry, the component uses its built-in default value
• The order of precedence is: gateway override > Hub registry value > built-in default

Best Practices

• Document all custom configuration settings and their intended behavior
• Use consistent naming conventions for setting keys (e.g., category.subcategory.setting)
• Review gateway-level overrides periodically to ensure they are still necessary
• Test configuration changes in a non-production environment before applying to production
• Maintain a change log for configuration modifications to support troubleshooting

---