T9.1: Pre-Installation Decisions

Overview

HealthShare Unified Care Record (UCR) is built on a distributed architecture where each component serves a distinct purpose within the federation. Understanding how these components interact is foundational to planning a successful deployment. The architecture separates concerns between patient identity management, clinical data storage, data access, and external integration.

Registry (Hub)

The Registry is the central nervous system of a UCR federation. There is exactly one Registry per federation. It provides federation-wide services including:

• Master Patient Index (MPI): Cross-references patient identities across all connected facilities
• Consent Manager: Enforces patient consent policies across the federation
• Patient Registry: Maintains a federation-wide patient directory
• Clinician Registry: Tracks clinician identities and their facility associations
• System Registry: Catalogs all connected systems and their capabilities
• User Registry: Manages user accounts and their access privileges

The Registry never stores clinical data. Its sole purpose is to provide identity, consent, and coordination services.

Edge Gateway

Edge Gateways sit at the facility level and are responsible for collecting clinical data from source systems. Each Edge Gateway stores clinical data in its Edge Cache Repository (ECR) using the SDA (Summary Document Architecture) format. Edge Gateways communicate with the Registry to submit patient identity information and register clinical documents.

Access Gateway

The Access Gateway provides clinicians with a consolidated view of patient data drawn from across the federation. It hosts the Clinical Viewer application and stores data only transiently during active user sessions. Access Gateways query Edge Gateways and other data sources to assemble a complete patient record on demand.

Bus

The Bus is an optional component designed for integrating third-party applications with the UCR federation. It provides standardized interfaces for external systems that need to query or submit data without being a full Edge or Access Gateway.

ODS (Operational Data Store)

The ODS stores aggregated clinical data from across the federation and provides a FHIR server for standards-based data access. It enables analytics, reporting, and programmatic access to the consolidated clinical dataset.

---

Overview

Each component in the UCR architecture has a clearly defined role. Understanding these boundaries is critical for proper deployment planning and for answering exam questions about where specific functions reside.

Registry Role Details

The Registry provides coordination services for the entire federation. It is the authoritative source for:

• Patient identity resolution (which patient records from different facilities refer to the same person)
• Consent policy enforcement (what data can be shared and with whom)
• System and clinician registration (tracking all participants in the federation)

A critical exam point: the Registry never stores clinical data. If a question asks where clinical data resides, the answer is always the Edge Gateway (in the ECR) or the ODS, never the Registry.

Edge Gateway Role Details

The Edge Gateway is the primary clinical data repository. It:

• Receives data feeds from facility source systems (EHRs, lab systems, pharmacy systems)
• Transforms incoming data into SDA format for storage in the ECR
• Notifies the Registry of new patient identities and document availability
• Responds to queries from Access Gateways requesting patient data

Access Gateway Role Details

The Access Gateway is a read-only consumer of data. It:

• Hosts the Clinical Viewer web application
• Queries Edge Gateways to assemble consolidated patient records
• Stores retrieved data only transiently (not persisted long-term)
• Applies consent policies to filter data based on user permissions

Bus Role Details

The Bus serves as an integration point for external applications that need to participate in the federation without running their own Edge or Access Gateway. It provides IHE-profile-based interfaces for querying and submitting data.

ODS Role Details

The ODS aggregates clinical data from the federation and makes it available through a FHIR server. It supports analytics, population health queries, and standards-based API access for modern applications.

---

Overview

Edge Gateway planning is one of the most important pre-installation decisions because it directly affects data flow, performance, and the operational complexity of the federation. The number and placement of Edge Gateways must balance the needs of individual facilities with the cost and complexity of managing multiple gateways.

Determining the Number of Edge Gateways

The primary factors in determining how many Edge Gateways to deploy are:

• Facility count and size: Large hospitals or health systems with high data volumes typically require their own dedicated Edge Gateway
• Data volume: Facilities generating large amounts of clinical data need dedicated resources to handle the load
• Source system count: Facilities with many source systems (EHR, lab, pharmacy, radiology) benefit from a dedicated gateway to manage the integration complexity
• Network topology: Facilities in different geographic locations or network segments may need their own gateway for performance and reliability

Shared Edge Gateways

Smaller facilities such as clinics, urgent care centers, or physician practices may not generate enough data to justify a dedicated Edge Gateway. These facilities can share an Edge Gateway, reducing infrastructure and management overhead. When sharing:

• Ensure the shared gateway has sufficient capacity for all connected facilities
• Plan for growth as new facilities may be added over time
• Consider the impact of one facility's data volume on others sharing the gateway

Audit Edge Designation

Every UCR federation must designate exactly one Edge Gateway as the Audit Edge. This gateway houses the federation's audit repository and is responsible for collecting audit events from all components. The Audit Edge designation must be planned before installation because it affects the configuration of all other components. Details of the Audit Edge are covered in a later section.

---

Overview

All UCR components communicate using web services based on SOAP (Simple Object Access Protocol). This standardized approach ensures interoperability and provides robust security mechanisms. Understanding the connectivity requirements is essential for network planning and security configuration.

SOAP Messaging

UCR uses SOAP-based web services for all inter-component communication. This includes:

• Edge Gateways registering patients and documents with the Registry
• Access Gateways querying Edge Gateways for patient data
• The Registry responding to patient identity queries
• Consent policy distribution and enforcement messages

SOAP was chosen for its support of WS-Security standards and its alignment with IHE (Integrating the Healthcare Enterprise) profiles used in healthcare interoperability.

WS-Security

WS-Security provides message-level security for SOAP communications. This includes:

• Message integrity verification (ensuring messages are not tampered with in transit)
• Authentication of the sending component
• SAML (Security Assertion Markup Language) token support for identity federation

SSL/TLS

All communication between UCR components must be encrypted using SSL/TLS. This requires:

• Creating SSL/TLS configurations on each UCR instance
• Installing and managing certificates for each component
• Configuring trust relationships between components
• Regular certificate renewal before expiration

Network Planning Considerations

• All UCR components must be able to communicate over the network
• Firewall rules must allow SOAP/HTTPS traffic between components
• Network latency affects query response times, particularly for Access Gateway queries
• Consider redundant network paths for high-availability deployments

---

Overview

The Audit Edge is a specially designated Edge Gateway that serves as the centralized audit repository for the entire UCR federation. Every UCR deployment must have exactly one Audit Edge, and this designation must be made during the pre-installation planning phase.

Purpose of the Audit Edge

The Audit Edge collects and stores audit events from all components in the federation. These audit events record:

• User access to patient records
• Data queries and retrievals
• Administrative actions
• Consent policy changes
• System configuration modifications

This centralized audit trail is essential for regulatory compliance (HIPAA, etc.), security monitoring, and forensic investigation.

Planning Considerations

When selecting which Edge Gateway to designate as the Audit Edge:

• Choose a gateway with sufficient storage capacity for audit data from the entire federation
• Consider network connectivity, as all components must be able to reach the Audit Edge
• Plan for the additional processing load of receiving audit events from all components
• The Audit Edge also functions as a regular Edge Gateway for its associated facility
• Changing the Audit Edge designation after deployment is a complex operation and should be avoided

Configuration Impact

The Audit Edge designation affects the configuration of every other component in the federation, as each component must be configured to send audit events to the designated Audit Edge endpoint.

---

Overview

UCR topology planning involves deciding how to distribute components across InterSystems IRIS for Health instances. The topology differs significantly between production and development environments, and making the right choice is critical for performance, maintainability, and scalability.

Production Topology

In a production environment, best practice dictates that each UCR component runs on its own dedicated InterSystems IRIS for Health instance. This means:

• A dedicated instance for the Registry (Hub)
• A dedicated instance for each Edge Gateway
• A dedicated instance for each Access Gateway
• A dedicated instance for the Bus (if used)
• A dedicated instance for the ODS (if used)

This separation provides:

• Independent scaling of components based on their specific workloads
• Isolation of failures (one component's issues do not affect others)
• Independent maintenance windows for upgrades and patching
• Clear resource allocation and capacity planning

Development and Demo Topology

For development, testing, or demonstration purposes, multiple UCR components can run as separate namespaces on a single IRIS for Health instance. This reduces infrastructure requirements but is not suitable for production because:

• Components compete for shared resources (CPU, memory, disk)
• A failure in one component can affect all others on the same instance
• Performance testing results do not reflect production behavior

Namespace Organization

Regardless of topology, each UCR component operates within its own namespace. The Installer Wizard creates the appropriate namespace and production for each component type. Namespace naming should follow a consistent convention that identifies the component type and associated facility.

---

Overview

The deployment model for UCR differs significantly between production and development environments. Understanding these differences is important for exam preparation and for real-world deployment planning.

Production Deployment Characteristics

• Each UCR component runs on its own dedicated IRIS for Health instance, typically on separate servers or virtual machines
• SSL/TLS is mandatory for all inter-component communication
• High availability configurations (mirroring, failover) are implemented
• Dedicated network infrastructure with appropriate firewall rules
• Formal change management processes for configuration changes
• Monitoring and alerting for all components
• Backup and disaster recovery procedures in place
• Full security hardening following InterSystems best practices

Development Deployment Characteristics

• Multiple UCR components can share a single IRIS for Health instance
• Components run as separate namespaces on the shared instance
• SSL/TLS may be simplified or use self-signed certificates
• High availability is typically not configured
• Simplified network configuration
• Rapid deployment and teardown for testing cycles
• May use reduced data volumes and simplified consent policies

Key Differences for Exam Preparation

The exam may present scenarios asking whether a particular topology is appropriate. Key rules to remember:

• Single-instance deployments are only for development, testing, and demonstration
• Production deployments must use separate instances
• The Registry is always a single instance (one per federation) regardless of environment
• Edge Gateways in production should be dedicated to their facility or facility group

---

Overview

Every InterSystems IRIS for Health instance in a UCR deployment requires an appropriate license key. License planning is a pre-installation decision because installations cannot proceed without valid license keys, and the type of key determines what features are available on each instance.

License Key Basics

• Each IRIS for Health instance requires its own license key file
• License keys are tied to specific server hardware or virtual machine characteristics
• Keys specify the number of concurrent users, connections, and enabled features
• Different component types (Registry, Edge, Access, Bus, ODS) may require different license configurations

Obtaining License Keys

License keys must be obtained from InterSystems before installation begins. The process involves:

• Identifying all instances that will be deployed
• Specifying the component type for each instance
• Providing server identification information
• Requesting appropriate capacity for each component

License Key Application

License keys are typically applied during the IRIS for Health installation process or immediately after installation via the Management Portal. An instance without a valid license key will operate in a restricted mode with limited functionality.

Renewal and Management

License keys have expiration dates. Administrators must:

• Track license key expiration dates for all instances
• Initiate renewal well before expiration
• Plan for key replacement during maintenance windows
• Keep backup copies of license key files in secure storage

---