1. IRIS for Health Base Installation
Key Points
- Foundation platform: UCR is built on InterSystems IRIS for Health
- Installation prerequisite: IRIS for Health must be installed before UCR configuration
- Supported platforms: Windows, Linux, and other supported operating systems
- Installation methods: GUI installer, command-line installation, or container deployment
- System requirements: Verify hardware, OS, and network prerequisites before installation
Detailed Notes
Overview
HealthShare Unified Care Record (UCR) runs on the InterSystems IRIS for Health platform. Before any UCR-specific configuration can begin, the base IRIS for Health instance must be installed on each server that will host a UCR component. This is the first step in any UCR deployment.
Installation Process
The IRIS for Health installation follows the standard InterSystems installation process:
- Run the InterSystems installer appropriate for the target operating system
- Accept the license agreement and specify the installation directory
- Select the installation type (server installation for production components)
- Configure the initial security settings (LockedDown recommended for production)
- Set passwords for predefined accounts (_SYSTEM, Admin, SuperUser, CSPSystem)
- Complete the installation and verify the instance starts successfully
System Prerequisites
Before installing IRIS for Health, verify:
- Sufficient disk space for the installation and data storage
- Adequate memory for the component type (Registry, Edge, Access, Bus, ODS have different memory profiles)
- Network connectivity to other servers in the federation
- Required ports are available and not blocked by firewalls
- Operating system is on the supported platforms list
- Any required system-level packages or libraries are installed
Post-Base-Installation
After the base IRIS for Health installation completes, the instance is a generic IRIS for Health server. UCR-specific functionality is added through the Installer Wizard, which creates the appropriate namespaces, productions, and configurations for the chosen component type.
---
Documentation References
2. License Key Application
Key Points
- Timing: Apply license key during or immediately after IRIS for Health installation
- Management Portal: License key can be applied via System Administration > Licensing
- Key file: License key is a file provided by InterSystems
- Activation: Instance may require restart after license key application
- Validation: Verify the license key enables the required features for the component type
Detailed Notes
Overview
Each IRIS for Health instance in a UCR deployment must have a valid license key applied. The license key determines the capabilities and capacity of the instance and must be appropriate for the UCR component type it will host.
Applying the License Key
The license key can be applied through several methods:
- During the IRIS for Health installation process when prompted
- After installation via the Management Portal under System Administration > Licensing > License Key
- By placing the license key file in the instance's manager directory (mgr/)
License Key Validation
After applying the license key, verify:
- The key is recognized and activated by the instance
- The license type matches the intended component role
- The concurrent user and connection limits are appropriate
- The key has not expired and has sufficient remaining validity
- All required features are enabled by the license
Troubleshooting
Common license key issues include:
- Key not matching the server hardware or virtual machine
- Expired license key
- Insufficient capacity for the planned workload
- Missing features required by the UCR component type
- File permission issues preventing the instance from reading the key file
---
Documentation References
3. Registry (Hub) Configuration
Key Points
- Installer Wizard: Primary tool for creating the Registry namespace and production
- Single instance: Only one Registry per federation
- Feature selection: Choose features during wizard configuration (MPI, consent, registries)
- Namespace creation: Wizard creates the Hub namespace with all required databases
- Production creation: Wizard configures the production with appropriate business operations and services
Detailed Notes
Overview
The Registry (Hub) is configured using the Installer Wizard, which is accessible through the Management Portal. The wizard guides administrators through the creation of the Hub namespace, its associated databases, and the production that runs the Registry services. Since there is exactly one Registry per federation, this configuration is performed once.
Installer Wizard Process for Registry
The Installer Wizard for the Registry performs the following steps:
- Creates the Hub namespace with required databases
- Configures the production with Registry-specific business services and operations
- Sets up the MPI engine configuration
- Configures the consent management framework
- Creates the patient, clinician, system, and user registries
- Establishes the system index for federation health monitoring
Feature Configuration Options
During Registry configuration, the wizard presents options for enabling various features:
- MPI Configuration: Algorithm selection, matching thresholds, and search parameters
- Consent Management: Default consent policies and enforcement mode
- IHE Profiles: PIX Manager, PDQ Supplier, XDS.b Registry components
- Notifications: Clinical message delivery configuration
- Analytics: Enabling analytics and reporting features
Post-Wizard Configuration
After the Installer Wizard completes, additional configuration steps are typically required:
- SSL/TLS configuration for secure communication
- Endpoint configuration for Edge and Access Gateway connections
- MPI algorithm tuning based on the patient population
- Consent policy definition at the system level
- User and clinician registry population
---
Documentation References
4. Edge Gateway Configuration
Key Points
- Installer Wizard: Creates Edge Gateway namespace and production
- Cache type: Standard cache or expire-and-query cache configuration
- Facility association: Each Edge Gateway is associated with one or more facilities
- ECR setup: Edge Cache Repository configured for SDA data storage
- Feature selection: Choose IHE profiles and data handling features
Detailed Notes
Overview
Each Edge Gateway in the federation is configured using the Installer Wizard. The wizard creates the Edge Gateway namespace, its associated databases, and the production that manages data collection and storage. Edge Gateway configuration includes important decisions about caching behavior and facility association.
Cache Type Configuration
A key decision during Edge Gateway configuration is the cache type:
- Standard Cache: Clinical data is stored persistently in the Edge Cache Repository (ECR). Data remains available locally for queries even if the source system is unavailable. This is the most common configuration.
- Expire-and-Query Cache: Clinical data is cached temporarily and expires after a configurable period. When data is needed and has expired, the system queries the source system for fresh data. This approach reduces local storage requirements but depends on source system availability.
The choice of cache type affects storage requirements, query performance, and source system load.
Installer Wizard Process for Edge Gateway
The wizard performs these steps:
- Creates the Edge Gateway namespace with required databases
- Configures the production with Edge-specific business services and operations
- Sets up the Edge Cache Repository (ECR) for SDA data storage
- Configures IHE components (PIX Source, XDS.b Document Source)
- Establishes data transformation and routing rules
- Configures notification capabilities
Feature Configuration Options
During Edge Gateway configuration, administrators select:
- Cache type (standard or expire-and-query)
- IHE profile support (PIX, XDS.b)
- Clinical message delivery support
- Data validation and transformation options
- Audit event forwarding to the Audit Edge
Facility Association
Each Edge Gateway must be associated with one or more healthcare facilities. This association determines:
- Which source systems feed data to the gateway
- How patients are identified within the facility context
- Consent policy application at the facility level
---
Documentation References
5. Access Gateway Configuration
Key Points
- Installer Wizard: Creates Access Gateway namespace and production
- Clinical Viewer: Web application for clinician access to patient data
- Transient data: Access Gateway does not persist clinical data long-term
- Query routing: Configured to query appropriate Edge Gateways for patient data
- User authentication: Integration with authentication mechanisms for clinician login
Detailed Notes
Overview
The Access Gateway provides clinicians with a consolidated view of patient data through the Clinical Viewer web application. Configuration using the Installer Wizard sets up the namespace, production, and Clinical Viewer components needed to serve clinical users.
Installer Wizard Process for Access Gateway
The wizard performs these steps:
- Creates the Access Gateway namespace with required databases
- Configures the production with Access-specific business services and operations
- Sets up the Clinical Viewer web application
- Configures query routing to Edge Gateways and other data sources
- Establishes patient search capabilities via the Registry MPI
- Configures consent policy enforcement for data display
Clinical Viewer Setup
The Clinical Viewer is a web-based application that provides:
- Patient search using MPI-based identity resolution
- Consolidated clinical record view aggregating data from multiple Edge Gateways
- Document viewing for clinical documents (CDA, PDF, etc.)
- Clinical timeline and chart views
- Consent-aware data filtering
Configuration includes:
- Web server and application settings
- User interface customization options
- Session timeout and security parameters
- Document rendering configuration
Feature Configuration Options
During Access Gateway configuration, administrators select:
- Clinical Viewer features and display options
- IHE profile support for document retrieval (XCA, XDS.b)
- CDA transform configuration for document rendering
- Authentication and authorization integration
- Audit event configuration
---
Documentation References
6. Bus Configuration
Key Points
- Optional component: Bus is not required for basic UCR operation
- Installer Wizard: Creates Bus namespace and production
- External integration: Provides IHE-based interfaces for third-party applications
- PIX Consumer: Enables external systems to query the MPI
- XCA/XDS.b: Provides document query and retrieval services for external consumers
Detailed Notes
Overview
The Bus is an optional UCR component that provides standardized interfaces for third-party applications to interact with the UCR federation. It is configured using the Installer Wizard when external system integration is required beyond what Edge and Access Gateways provide.
Installer Wizard Process for Bus
The wizard performs these steps:
- Creates the Bus namespace with required databases
- Configures the production with Bus-specific business services and operations
- Sets up IHE profile components for external communication
- Configures PIX Consumer capabilities for patient identity queries
- Establishes XCA and XDS.b components for document sharing
When to Deploy a Bus
Consider deploying a Bus when:
- Third-party applications need to query patient identities via PIX
- External systems need to retrieve clinical documents via XDS.b or XCA
- Applications outside the UCR federation need standardized access to federation data
- Regional Health Information Exchanges (HIEs) need to connect to the federation
Feature Configuration Options
During Bus configuration, administrators select:
- IHE profile support (PIX Consumer, XCA Initiating Gateway, XDS.b Consumer)
- External system registration and access control
- SSL/TLS and authentication requirements for external connections
- Message routing and transformation rules
---
Documentation References
7. ODS Configuration
Key Points
- Aggregated data: ODS stores consolidated clinical data from the federation
- FHIR server: Provides FHIR-based API access to clinical data
- Installer Wizard: Creates ODS namespace and production
- Analytics support: Enables analytics, reporting, and population health queries
- Data synchronization: Configured to receive data updates from Edge Gateways
Detailed Notes
Overview
The Operational Data Store (ODS) is a UCR component that provides aggregated storage of clinical data and a FHIR server for standards-based data access. Unlike the Access Gateway which retrieves data transiently, the ODS persists a consolidated copy of clinical data for analytics and API access.
Installer Wizard Process for ODS
The wizard performs these steps:
- Creates the ODS namespace with required databases
- Configures the production with ODS-specific business services and operations
- Sets up the FHIR server endpoint and resource configuration
- Configures data synchronization from Edge Gateways
- Establishes indexing and search capabilities
FHIR Server Setup
The ODS FHIR server provides:
- RESTful API access to clinical data using FHIR resources
- FHIR resource search and retrieval capabilities
- Support for standard FHIR operations
- Authentication and authorization for FHIR API clients
- Conformance statement and capability documentation
Data Synchronization
The ODS receives clinical data through:
- Subscription-based notifications from Edge Gateways
- Periodic synchronization of new and updated records
- Transformation of SDA data into FHIR resources
Analytics and Reporting
The ODS supports:
- Business Intelligence (BI) cube building for analytics
- Population health queries across the aggregated dataset
- Custom reporting on clinical data
- Data extraction for research and quality improvement
---
Documentation References
8. Installer Wizard Feature Options
Key Points
- Component-specific: Each component type has its own set of feature options
- IHE profiles: Enable or disable specific IHE profile support per component
- Clinical features: Message delivery, analytics, consent enforcement options
- Data handling: Cache types, transformation, validation options
- Post-wizard changes: Some features can be enabled or disabled after initial configuration
Detailed Notes
Overview
The Installer Wizard presents different feature options depending on the component type being configured. Understanding which features are available for each component type and what they enable is important for both deployment planning and exam preparation.
Registry Feature Options
- MPI engine configuration and matching algorithm selection
- Consent management framework enablement
- IHE profile support (PIX Manager, PDQ Supplier, XDS.b Registry)
- Clinical message delivery (notification engine)
- DSUB (Document Metadata Subscription) support
- Analytics and reporting features
- System index and federation health monitoring
Edge Gateway Feature Options
- Cache type selection (standard or expire-and-query)
- IHE profile support (PIX Source, XDS.b Document Source, XDS.b Repository)
- Clinical message delivery support
- Data validation and quality checking
- SDA transformation configuration
- Audit event forwarding configuration
- Notification capabilities
Access Gateway Feature Options
- Clinical Viewer configuration and customization
- IHE profile support (XCA, XDS.b Consumer)
- CDA transform and document rendering
- Authentication integration options
- Session management and timeout configuration
- Consent enforcement display options
Bus Feature Options
- IHE profile support (PIX Consumer, XCA Initiating Gateway, XDS.b Consumer, XCPD)
- External system connectivity options
- Message routing and transformation
- Security and access control for external connections
ODS Feature Options
- FHIR server endpoint configuration
- Data synchronization mode and schedule
- Analytics and BI cube configuration
- Index building and search configuration
- FHIR resource type support selection
Modifying Features After Installation
Some features can be enabled or disabled after the initial Installer Wizard configuration through the Management Portal. However, fundamental choices like cache type for Edge Gateways or the namespace structure cannot easily be changed after creation.
---
Documentation References
Exam Preparation Summary
Critical Concepts to Master:
- IRIS for Health Base: UCR requires IRIS for Health as the underlying platform
- Installer Wizard: Primary tool for creating UCR namespaces and productions for all component types
- Registry Configuration: Single instance per federation, MPI and consent services, no clinical data
- Edge Gateway Cache Types: Standard cache (persistent) vs expire-and-query cache (temporary)
- Access Gateway: Hosts Clinical Viewer, transient data only
- Bus: Optional component for third-party IHE-based integration
- ODS: Aggregated data store with FHIR server capabilities
- Feature Options: Component-specific options selected during Installer Wizard configuration
Common Exam Scenarios:
- Choosing the correct cache type for an Edge Gateway based on facility requirements
- Identifying which Installer Wizard options are available for each component type
- Determining the correct order of installation (base IRIS first, then Installer Wizard)
- Selecting features to enable for a given use case
- Understanding the relationship between namespace creation and component configuration
- Troubleshooting license key issues during installation
Hands-On Practice Recommendations:
- Walk through the Installer Wizard for each component type and observe available options
- Practice installing IRIS for Health and applying license keys
- Configure a Registry and observe the created namespace, databases, and production
- Set up Edge Gateways with both cache types and compare behavior
- Deploy an Access Gateway and explore Clinical Viewer configuration
- Create an ODS and examine the FHIR server endpoint configuration