T10.3: Implements IHE

Overview

UCR implements several IHE (Integrating the Healthcare Enterprise) profiles to enable standards-based healthcare interoperability. These profiles define the roles, transactions, and message formats for exchanging patient identity information and clinical documents across the federation and with external systems.

PIX (Patient Identity Cross-referencing)

PIX enables cross-referencing of patient identities across different systems:

• PIX Feed (ITI-8): Source systems submit patient identity data to the PIX Manager
• PIX Query (ITI-9): Consumer systems query for cross-referenced identities
• PIX Update Notification (ITI-10): The PIX Manager notifies subscribers of identity changes
• In UCR, the Registry acts as the PIX Manager, and Edge Gateways act as PIX Sources

PDQ (Patient Demographics Query)

PDQ enables searching for patients by demographic criteria:

• Patient Demographics Query (ITI-21): Consumer systems search for patients by name, date of birth, gender, etc.
• Patient Demographics and Visit Query (ITI-22): Extended query including visit information
• In UCR, the Registry provides PDQ Supplier capabilities

XDS.b (Cross-Enterprise Document Sharing)

XDS.b enables registration and sharing of clinical documents:

• Register Document Set (ITI-42): Document sources register metadata with the registry
• Provide and Register Document Set (ITI-41): Combined document submission and registration
• Query Documents (ITI-18): Consumer systems query for document metadata
• Retrieve Document (ITI-43): Consumer systems retrieve actual documents
• In UCR, the Registry acts as the XDS.b Registry, and Edge Gateways host XDS.b Repositories

XCA (Cross-Community Access)

XCA enables document queries across community boundaries:

• Cross Gateway Query (ITI-38): Query for documents across communities
• Cross Gateway Retrieve (ITI-39): Retrieve documents from another community
• Enables UCR federations to interoperate with external HIEs and other UCR federations

DSUB (Document Metadata Subscription)

DSUB enables subscription-based notifications:

• Document Metadata Subscribe (ITI-52): Subscribe to notifications about document availability
• Document Metadata Notify (ITI-53): Receive notifications when matching documents become available
• Document Metadata Publish (ITI-54): Publish document availability events
• Supports the Clinical Message Delivery feature in UCR

---

Overview

The Registry (Hub) production hosts the majority of IHE profile components. As the central coordinator of the federation, the Registry provides the authoritative services for patient identity management and document metadata registration.

PIX Components at the Registry

• PIX Manager: The core component that maintains the master cross-reference table linking patient identifiers from different facilities. When an Edge Gateway submits a patient identity via PIX Feed, the PIX Manager attempts to match it with existing identities and creates or updates cross-references.
• PIX Notification: When cross-references change (new links, unlinks), the PIX Notification component sends updates to registered PIX Consumers so they can update their local records.
• PIX Consumer: The Registry may also act as a PIX Consumer for internal operations that need to resolve patient identities.

PDQ Components at the Registry

• PDQ Supplier: Responds to patient demographic queries from Access Gateways, Bus, and external systems. Searches the MPI for matching patients based on submitted demographic criteria.

XDS.b Components at the Registry

• XDS.b Registry: Maintains the metadata for all clinical documents registered in the federation. When Edge Gateways submit document metadata, the XDS.b Registry stores it and makes it available for queries. The Registry stores only metadata (who, what, when, where), not the actual documents.

XCA Components at the Registry

• XCA Responding Gateway: Enables the federation to respond to cross-community queries from external systems. Routes incoming XCA queries to the appropriate internal components and returns aggregated results.

DSUB Components at the Registry

• DSUB Notification Broker: Manages subscriptions for document availability notifications. When new documents are registered, the broker evaluates subscriptions and sends notifications to matching subscribers.

---

Overview

Edge Gateway productions contain the IHE components responsible for submitting patient identities and clinical documents to the federation. As the data collection points, Edge Gateways act primarily as sources in the IHE profile model.

PIX Source

The PIX Source component on each Edge Gateway:

• Sends PIX Feed (ITI-8) transactions to the Registry PIX Manager
• Submits patient identity data when new patients are encountered or demographics change
• Includes patient identifiers from the facility's source systems
• Receives acknowledgments confirming identity registration

XDS.b Document Source

The XDS.b Document Source component:

• Creates document metadata for clinical data received from facility source systems
• Submits Provide and Register Document Set (ITI-41) transactions
• Packages clinical data as CDA documents or other supported formats
• Associates documents with the correct patient identity via PIX cross-references

XDS.b Repository

Edge Gateways also act as XDS.b Repositories:

• Store the actual clinical documents (as opposed to the Registry which stores only metadata)
• Respond to Retrieve Document (ITI-43) requests from Access Gateways and other consumers
• Maintain document versions and lifecycle status
• Documents are stored in the Edge Cache Repository (ECR)

Message Traces

IHE transactions at Edge Gateways generate message traces:

• Each PIX Feed and document submission creates traceable messages
• Message traces are viewable in the Management Portal under the production's message viewer
• Traces include the full SOAP envelope, headers, and body
• Essential for troubleshooting data submission issues

Transactional Flow

The typical Edge Gateway IHE transaction flow: 1. Facility source system sends clinical data to the Edge Gateway 2. Edge Gateway transforms data into SDA format and stores in ECR 3. PIX Source sends patient identity to Registry 4. XDS.b Document Source registers document metadata with Registry 5. Document is stored locally in the XDS.b Repository for retrieval

---

Overview

Access Gateway productions contain the IHE components responsible for querying and retrieving clinical documents on behalf of clinicians using the Clinical Viewer. As the primary consumer of clinical data, Access Gateways act as consumers and initiating gateways in the IHE profile model.

XDS.b Consumer Components

The XDS.b Consumer on each Access Gateway:

• Sends Query Documents (ITI-18) requests to the Registry XDS.b Registry
• Queries for document metadata matching patient identities and search criteria
• Receives lists of available documents with their repository locations
• Sends Retrieve Document (ITI-43) requests to Edge Gateway XDS.b Repositories
• Assembles retrieved documents for display in the Clinical Viewer

XCA Initiating Gateway

The XCA Initiating Gateway enables cross-community queries:

• Sends Cross Gateway Query (ITI-38) to external communities
• Sends Cross Gateway Retrieve (ITI-39) to retrieve documents from external sources
• Aggregates results from internal and external sources
• Provides a unified view of data from multiple communities

On-Demand Document Generation

Access Gateways support on-demand documents:

• Generated dynamically at query time from data stored in Edge Gateway ECRs
• Assembled from current SDA data into CDA documents
• Always reflect the latest available data
• Require real-time connectivity to Edge Gateways

Stable Document Retrieval

Access Gateways also retrieve stable documents:

• Pre-generated documents stored in Edge Gateway repositories
• Represent a point-in-time snapshot of clinical data
• Available even if the originating source system is temporarily unavailable
• Include documents submitted from external sources (e.g., scanned documents, lab reports)

Clinical Viewer Integration

The IHE components feed data to the Clinical Viewer:

• Patient search uses PDQ to find patients
• Document list uses XDS.b queries to find available documents
• Document display uses XDS.b retrieval to fetch document content
• Cross-community data uses XCA to access external sources

---

Overview

The Bus production contains IHE components that enable external third-party applications to interact with the UCR federation using standard IHE transactions. The Bus acts as a gateway between the internal federation and external consumers.

PIX Consumer at the Bus

The PIX Consumer component:

• Enables external systems to query the Registry's PIX Manager for cross-referenced patient identities
• External systems submit patient identifiers from their own domain
• The PIX Consumer returns matching identifiers from other domains in the federation
• Provides the standard PIX Query (ITI-9) interface

XCA/XCPD Components

Cross-community components at the Bus:

• XCA Initiating Gateway: Allows external systems to query for documents across the federation and connected communities
• XCPD (Cross-Community Patient Discovery): Enables external systems to discover patients across communities using demographic criteria
• These components aggregate results from internal sources and route to the appropriate community

XDS.b Repository at the Bus

The Bus can host XDS.b Repository components:

• Provides document retrieval services for external consumers
• May cache or proxy documents from Edge Gateway repositories
• Enables external systems to retrieve clinical documents without direct access to Edge Gateways

External-Facing Security

Bus IHE components have additional security considerations:

• External-facing endpoints require robust SSL/TLS configuration
• Authentication mechanisms must verify external system identities
• Authorization controls limit what external systems can access
• Audit logging tracks all external access through the Bus
• Rate limiting may be needed to prevent abuse

---

Overview

XCA (Cross-Community Access) configuration enables a UCR federation to exchange clinical documents with external communities, such as other UCR federations, regional Health Information Exchanges (HIEs), or national health information networks. XCA configuration involves setting up both initiating and responding gateway capabilities.

XCA Initiating Gateway Setup

Configuration for outbound cross-community queries:

• Enable the XCA Initiating Gateway component in the appropriate production (Access Gateway or Bus)
• Configure the endpoints of external communities that can be queried
• Set up SSL/TLS configurations for each external community connection
• Configure query parameters and timeout settings
• Test connectivity with each external community

XCA Responding Gateway Setup

Configuration for inbound cross-community queries:

• Enable the XCA Responding Gateway component in the Registry production
• Configure authentication and authorization for external initiating gateways
• Set up the routing logic to direct queries to appropriate internal Edge Gateways
• Configure response aggregation and formatting
• Establish rate limiting and access controls for external queries

Community Mapping

UCR must be configured with knowledge of external communities:

• Community identifiers (Home Community IDs)
• Community endpoint URLs for query and retrieve operations
• Community SSL/TLS certificates and trust configuration
• Community-specific query parameter mappings
• Community availability and failover settings

XCA Edge Gateway Configuration

Edge Gateways can be configured for XCA participation:

• An Edge Gateway can act as an XCA Edge Gateway for direct cross-community data sharing
• This is useful when specific facility data needs to be directly accessible by external communities
• Configuration includes XCA endpoints, authentication, and access controls

Testing XCA Configuration

After configuration:

• Use the IHE Test Utility to validate XCA transactions
• Test cross-gateway queries with known patient data
• Verify document retrieval across community boundaries
• Confirm audit events are generated for cross-community access
• Test error handling and timeout behavior

---

Overview

XDS.b Repositories store clinical documents in the UCR federation. UCR supports different repository types with different behavior for document storage and retrieval. Understanding the differences and knowing when to use each type is important for deployment and exam preparation.

Standard XDS.b Repository

A standard repository:

• Stores documents that are submitted through the normal Edge Gateway data flow
• Documents are registered with the Registry's XDS.b Registry via Provide and Register
• Documents persist locally and are available for retrieval via ITI-43
• Appropriate for facilities that continuously push data to the Edge Gateway

Notify and Query Repository

A Notify and Query repository operates differently:

• Receives a notification that a document is available at an external source
• Retrieves the document on-demand when a consumer requests it
• May cache the document locally after retrieval
• Appropriate for facilities where data is pulled from the source system rather than pushed

Choosing Repository Type

The choice between standard and Notify and Query depends on:

• How the facility's source systems deliver data (push vs pull)
• Network connectivity and reliability between the Edge Gateway and source systems
• Storage capacity on the Edge Gateway
• Freshness requirements (Notify and Query always retrieves current data)

Converting Between Repository Types

UCR supports converting repositories between types:

• A standard repository can be converted to Notify and Query (and vice versa)
• Conversion involves reconfiguring the repository type in the Edge Gateway production
• Existing documents may need to be re-registered after conversion
• Test thoroughly after conversion to verify correct behavior

Repository Configuration

Configuration includes:

• Repository unique ID (OID) for IHE transactions
• Storage location and capacity settings
• Document retention policies
• SSL/TLS configuration for incoming retrieval requests
• Access control settings for who can retrieve documents

---

Overview

The service registry maintains a directory of all IHE service endpoints within the UCR federation. Each IHE component that provides services must have its endpoints registered so that other components can discover and connect to them.

PIX Service Registry Entries

PIX-related entries include:

• PIX Manager endpoint: The Registry's PIX Manager service URL for receiving PIX Feed transactions
• PIX Notification endpoint: The URL for PIX Update Notification delivery
• PIX Consumer endpoints: URLs for systems that accept PIX notifications

PDQ Service Registry Entries

PDQ-related entries include:

• PDQ Supplier endpoint: The Registry's PDQ Supplier service URL for patient demographic queries
• The PDQ endpoint is used by Access Gateways and Bus for patient search operations

XDS.b Service Registry Entries

XDS.b-related entries include:

• XDS.b Registry endpoint: The Registry's document registration service URL
• XDS.b Repository endpoints: Each Edge Gateway's document retrieval service URL
• Document query endpoint: The Registry's document metadata query service URL

XCA Service Registry Entries

XCA-related entries include:

• XCA Responding Gateway endpoint: The Registry's endpoint for receiving cross-community queries
• XCA Initiating Gateway endpoints: Endpoints for outbound cross-community queries
• External community endpoints: Endpoints for each connected external community

Managing Service Registry Entries

Best practices for service registry management:

• Keep entries up to date when endpoints change (server moves, URL changes)
• Remove entries for decommissioned components
• Verify all entries after upgrades or migrations
• Use consistent naming conventions for entries
• Document the purpose and owner of each entry

---

Overview

Object Identifiers (OIDs) are hierarchical identifiers used in IHE transactions to uniquely identify facilities, repositories, communities, and other entities. Proper OID management is essential for correct IHE operation and data routing.

OID Structure

OIDs follow a hierarchical numeric format (e.g., 1.2.3.4.5.6):

• Organizations obtain a root OID from a registration authority
• Sub-OIDs are created under the root for specific purposes
• Each OID must be globally unique within the IHE ecosystem
• OIDs are assigned during deployment planning and registered in UCR

Facility OIDs

Each facility in the federation needs OIDs for:

• Patient identity domain: Identifies the facility's patient identifier namespace (used in PIX transactions)
• Assigning authority: Identifies the facility as the authority that assigned patient identifiers
• These OIDs allow the PIX Manager to distinguish patient identifiers from different facilities

Repository OIDs

Each XDS.b repository needs a unique OID:

• Repository unique ID: Identifies the repository in document registration and retrieval
• Used in XDS.b Provide and Register transactions to identify where documents are stored
• Used in Retrieve Document transactions to locate the correct repository

Community OIDs

For XCA operations:

• Home Community ID: Uniquely identifies the UCR federation as a community
• External community IDs: Identify connected external communities
• Community OIDs are used in Cross Gateway Query and Retrieve transactions to route requests

OID Registry Configuration

UCR maintains an OID registry that:

• Maps OIDs to their associated entities (facilities, repositories, communities)
• Provides lookup services for IHE transaction routing
• Must be kept synchronized across all federation components
• Should be documented and version-controlled

---

Overview

CDA (Clinical Document Architecture) is the HL7 standard for exchanging clinical documents. UCR uses CDA transforms to convert internal SDA data into CDA format for document sharing via IHE profiles. Understanding CDA transforms is important for both IHE implementation and for customizing document output.

On-Demand Document Transforms

On-demand transforms generate CDA documents at query time:

• When a clinician requests a patient's clinical summary through the Clinical Viewer, the system generates a CDA document from current SDA data
• The transform assembles data from the Edge Cache Repository into a structured CDA document
• On-demand documents always reflect the latest available data
• Commonly used for Continuity of Care Documents (CCD) and clinical summaries

Stable Document Transforms

Stable document transforms create persistent CDA documents:

• Generated at the time data is received or at scheduled intervals
• Stored in XDS.b repositories as registered documents
• Represent a point-in-time snapshot of clinical data
• Commonly used for discharge summaries, operative notes, and lab reports

XSLT Stylesheets

CDA transforms use XSLT (eXtensible Stylesheet Language Transformations):

• SDA-to-CDA transforms: Convert internal SDA format to CDA XML
• CDA rendering transforms: Convert CDA XML to HTML for display in the Clinical Viewer
• UCR includes default XSLT stylesheets for standard document types
• Custom stylesheets can be created for organization-specific requirements

Transform Customization

Organizations may need to customize CDA transforms for:

• Including organization-specific headers and metadata
• Adjusting document section ordering and content
• Adding custom sections or data elements
• Modifying rendering for the Clinical Viewer display
• Complying with jurisdiction-specific CDA implementation guides

Managing Custom Transforms

When customizing transforms:

• Maintain custom transforms in version control
• Document all customizations for upgrade planning (custom transforms must be migrated during upgrades)
• Test custom transforms with representative clinical data
• Validate generated CDA documents against CDA schemas
• Keep track of which default transforms have been customized

---

Overview

The IHE Test Utility is a built-in UCR tool for validating IHE configurations. It enables administrators to test individual IHE transactions without requiring actual clinical data or external system participation. This tool is essential during initial deployment, after configuration changes, and after upgrades.

Test Capabilities

The IHE Test Utility can test:

PIX Transactions:

• PIX Feed (ITI-8): Submit a test patient identity and verify it is registered
• PIX Query (ITI-9): Query for cross-referenced identities and verify results
• PIX Update Notification (ITI-10): Verify notification delivery

PDQ Transactions:

• Patient Demographics Query (ITI-21): Submit demographic search criteria and verify results

XDS.b Transactions:

• Provide and Register Document Set (ITI-41): Submit a test document and verify registration
• Query Documents (ITI-18): Query for document metadata and verify results
• Retrieve Document (ITI-43): Retrieve a test document and verify content

XCA Transactions:

• Cross Gateway Query (ITI-38): Test cross-community queries
• Cross Gateway Retrieve (ITI-39): Test cross-community document retrieval

DSUB Transactions:

• Document Metadata Subscribe (ITI-52): Create a test subscription
• Document Metadata Notify (ITI-53): Verify notification delivery

Using the Test Utility

Steps for testing IHE configurations: 1. Access the IHE Test Utility from the Management Portal 2. Select the IHE transaction to test 3. Configure test parameters (patient identifiers, document metadata, etc.) 4. Execute the test transaction 5. Review the results including response messages, error codes, and timing 6. Investigate any failures using the detailed transaction log

Troubleshooting with the Test Utility

The test utility helps diagnose:

• Endpoint connectivity issues (can the source reach the target?)
• Authentication and authorization failures
• Message format issues (invalid SOAP messages, missing required fields)
• Certificate and SSL/TLS configuration problems
• Routing issues (messages reaching the wrong component)

---

Overview

Securing IHE endpoints is critical because IHE transactions carry sensitive patient identity and clinical data. UCR requires SSL/TLS encryption for all IHE SOAP endpoints, and best practice includes mutual TLS authentication (mTLS) where both the client and server verify each other's identity.

SSL/TLS for IHE Endpoints

Each IHE endpoint requires SSL/TLS configuration:

• Server certificates: Every component that hosts IHE services needs a server certificate
• Client certificates: Every component that initiates IHE transactions needs a client certificate
• CA certificates: All components must trust the certificate authorities that issued certificates to other components
• TLS version: Use TLS 1.2 or TLS 1.3 (older versions should be disabled)

Mutual TLS Authentication (mTLS)

For maximum security, configure mutual TLS:

• The server verifies the client's certificate (confirms the client's identity)
• The client verifies the server's certificate (confirms the server's identity)
• Both parties must present valid certificates from trusted CAs
• Prevents unauthorized systems from submitting or querying data

WS-Security for IHE Messages

In addition to transport-level security, IHE messages use WS-Security:

• SAML tokens: Authentication tokens embedded in SOAP headers
• Message signing: Digital signatures on SOAP messages to ensure integrity
• Timestamp verification: Prevents replay attacks by checking message timestamps
• WS-Security configuration is managed alongside SSL/TLS in the production settings

Certificate Management Best Practices

• Use a consistent certificate authority (internal or commercial) for all federation certificates
• Establish a certificate naming convention that identifies the component and purpose
• Track certificate expiration dates and renew well before expiration
• Test certificate rotation procedures before certificates actually expire
• Store certificate private keys securely with appropriate access controls
• Include certificate renewal in the upgrade and maintenance procedures

External IHE Endpoint Security

When exposing IHE endpoints to external systems (via the Bus or XCA):

• Apply the strongest available security measures
• Consider IP-based access restrictions in addition to certificate authentication
• Implement rate limiting to prevent abuse
• Enable detailed audit logging for all external access
• Review and update security configurations regularly

---