T1.3: Implements IHE

Overview

Integrating the Healthcare Enterprise (IHE) defines integration profiles that specify how healthcare systems should exchange information using established standards like HL7 and DICOM. HealthShare UCR implements several key IHE profiles to enable standards-based interoperability with external systems, health information exchanges (HIEs), and cross-community networks. Understanding which profiles are available and when to use each one is critical for the implementation specialist exam.

XDS.b (Cross-Enterprise Document Sharing)

XDS.b is the foundational IHE profile for document sharing:

• Purpose: Enables sharing of clinical documents across enterprise boundaries using a document registry and repository model
• Components: Document Source, Document Repository, Document Registry, Document Consumer
• UCR role: UCR can act as both a Document Source (publishing documents) and Document Consumer (retrieving documents)
• Use cases: Sharing discharge summaries, lab reports, radiology reports, and other clinical documents with external HIEs
• Standards: Uses ebXML Registry for metadata, HTTP/SOAP for transport, and CDA for document format

PIX (Patient Identifier Cross-Referencing)

PIX manages patient identifiers across systems:

• Purpose: Cross-references patient identifiers from different systems to establish a common patient identity
• Components: Patient Identity Source, Patient Identifier Cross-Reference Manager, Patient Identifier Cross-Reference Consumer
• UCR role: UCR's MPI functions as the PIX Manager, cross-referencing patient identifiers from contributing systems
• Use cases: Resolving patient identity when systems use different identifier schemes
• Standards: HL7v2 ADT messages (PIXv2) or HL7v3/SOAP (PIXv3)

PDQ (Patient Demographics Query)

PDQ enables demographic-based patient searches:

• Purpose: Allows external systems to query UCR for patient demographics
• Components: Patient Demographics Supplier, Patient Demographics Consumer
• UCR role: UCR acts as the Patient Demographics Supplier, responding to demographic queries
• Use cases: External systems searching for patients by name, date of birth, or other demographics
• Standards: HL7v2 QBP/RSP messages (PDQv2) or HL7v3/SOAP (PDQv3)

XCA (Cross-Community Access)

XCA extends document sharing across community boundaries:

• Purpose: Enables federated queries for patient documents across multiple communities (HIEs, regions)
• Components: Initiating Gateway, Responding Gateway
• UCR role: UCR can act as both Initiating Gateway (querying other communities) and Responding Gateway (responding to queries from other communities)
• Use cases: Nationwide health information exchange, cross-regional document sharing
• Standards: Extends XDS.b with gateway-to-gateway communication

ATNA (Audit Trail and Node Authentication)

ATNA provides security infrastructure:

• Purpose: Ensures secure node-to-node communication and comprehensive audit logging
• Components: Secure Node, Secure Application, Audit Record Repository
• UCR role: UCR implements ATNA for all IHE transactions, logging audit events and authenticating communication partners
• Use cases: Regulatory compliance, security monitoring, forensic investigation
• Standards: TLS for node authentication, RFC 3881/DICOM audit message format, Syslog transport

---

Overview

IHE functionality in UCR is implemented through business hosts within the HealthShare production (Ensemble/Interoperability). Each IHE profile requires specific business services, processes, and operations to be enabled and configured. The production configuration is managed through the Management Portal in the Hub (Registry) namespace.

Business Services for IHE

Business services handle incoming IHE requests:

• HS.IHE.PIXv2.Manager.Services: Receives PIXv2 patient identity feed and query messages
• HS.IHE.PIXv3.Manager.Services: Receives PIXv3 SOAP-based patient identity messages
• HS.IHE.PDQv2.Supplier.Services: Receives PDQv2 patient demographics queries
• HS.IHE.PDQv3.Supplier.Services: Receives PDQv3 SOAP-based demographics queries
• HS.IHE.XDSb.Registry.Services: Receives XDS.b document registration and query requests
• HS.IHE.XDSb.Repository.Services: Receives XDS.b document storage and retrieval requests
• HS.IHE.XCA.RespondingGateway.Services: Receives XCA cross-community query requests
• HS.IHE.ATNA.Repository.Services: Receives ATNA audit record messages

Business Operations for IHE

Business operations handle outgoing IHE requests:

• HS.IHE.PIXv2.Consumer.Operations: Sends PIXv2 queries to external PIX managers
• HS.IHE.XDSb.Consumer.Operations: Sends XDS.b document queries and retrieval requests
• HS.IHE.XCA.InitiatingGateway.Operations: Sends XCA queries to external responding gateways
• HS.IHE.ATNA.Operations: Sends ATNA audit records to external audit repositories

Enabling Components in the Management Portal

To enable IHE components:

• Navigate to HealthShare > [Hub Namespace] > Interoperability > Production Configuration
• Locate the IHE-related business hosts in the production diagram
• Enable the required business services, processes, and operations
• Configure the endpoint settings for each enabled component
• Start or restart the production to activate the changes

Endpoint URL Configuration

Each IHE business service exposes a URL endpoint:

• The endpoint URL is configured in the business service settings
• External systems use these URLs to send IHE transactions to UCR
• URL format typically follows: https://{server}:{port}/csp/healthshare/{namespace}/services/{service}
• Endpoints must be accessible to external systems through firewalls and load balancers
• TLS certificates must be configured for secure ATNA-compliant communication

---

Document Sharing Transactions (XDS.b)

XDS.b defines several key transactions:

Register Document Set (ITI-42):

• Document Sources register metadata about clinical documents with the Document Registry
• UCR receives registration requests and stores document metadata in the registry
• Configuration includes: accepted document types, metadata validation rules, affinity domain settings

Provide and Register Document Set (ITI-41):

• Combines document storage (to repository) and metadata registration (to registry) in one transaction
• UCR stores the document and registers its metadata
• Configuration includes: repository storage location, maximum document size, accepted MIME types

Registry Stored Query (ITI-18):

• Document Consumers query the registry for documents matching specified criteria
• UCR processes queries by patient ID, date range, document type, status, and other metadata
• Configuration includes: query result limits, supported query types, response format options

Retrieve Document Set (ITI-43):

• Document Consumers retrieve documents from the repository by unique ID
• UCR returns the requested documents in their original format
• Configuration includes: access controls, audit settings, supported retrieve formats

Patient Identity Transactions (PIX)

PIX defines the following transactions:

Patient Identity Feed (ITI-8/ITI-44):

• Patient Identity Sources send patient demographic and identifier information to the PIX Manager
• UCR's MPI receives the feed and cross-references identifiers
• Configuration includes: identifier domain settings, matching algorithm parameters, merge handling

PIX Query (ITI-9/ITI-45):

• PIX Consumers query for cross-referenced identifiers given a known patient identifier
• UCR returns all known identifiers for the matched patient
• Configuration includes: supported identifier domains, response format, error handling

Patient Demographics Query Transactions (PDQ)

PDQ defines the query transaction:

Patient Demographics Query (ITI-21/ITI-47):

• PDQ Consumers send demographic search criteria to the PDQ Supplier
• UCR searches the MPI and returns matching patient demographics
• Configuration includes: search parameters, result limits, matching sensitivity, continuation support

Cross-Community Transactions (XCA)

XCA extends XDS.b across communities:

Cross Gateway Query (ITI-38):

• Initiating Gateway sends document queries to Responding Gateways in other communities
• UCR can initiate queries to external communities or respond to incoming queries
• Configuration includes: community identifiers, gateway endpoints, timeout settings

Cross Gateway Retrieve (ITI-39):

• Initiating Gateway retrieves documents from Responding Gateways
• UCR can retrieve documents from external communities or serve documents to external gateways
• Configuration includes: supported document formats, size limits, audit settings

---

Overview

The IHE Test Utility is a built-in tool within HealthShare that allows administrators to test IHE connections and transactions without requiring external test harnesses. It generates test messages, sends them through the configured IHE components, and displays the results for validation.

Accessing the Test Utility

To access the IHE Test Utility:

• Navigate to HealthShare > [Hub Namespace] > HealthShare > IHE Test Utility
• The utility presents a list of available test transaction types
• Select the desired IHE profile and transaction to test
• The interface provides forms for entering test parameters

Available Test Types

The test utility supports testing for all major IHE transactions:

• PIX Tests: Send patient identity feeds, query for cross-referenced identifiers
• PDQ Tests: Send demographic queries, verify patient matches, test continuation queries
• XDS.b Tests: Register and store test documents, query by patient ID, retrieve and verify content
• XCA Tests: Send cross-gateway queries, verify responding gateway processing, test cross-community retrieval

Running Tests

To run an IHE test: 1. Select the IHE profile and transaction type 2. Fill in the required test parameters (patient identifiers, demographics, document metadata) 3. Click "Send" or "Execute" to send the test transaction 4. Review the response message displayed in the utility 5. Check the production message log for detailed processing information

Interpreting Test Results

When reviewing test results:

• Success: The response contains the expected data (matching patients, registered documents, retrieved content)
• Application error: The response contains an error code indicating a processing issue (invalid data, unknown patient)
• Communication error: The transaction failed to reach the target service (network, endpoint, TLS issues)
• Validation error: The message format was rejected (schema validation, missing required fields)

Troubleshooting with the Test Utility

Common issues: connection refused (check endpoint URL, port, firewall), TLS handshake failure (check certificates and trust stores), empty responses (verify test data exists), incorrect results (review identifier domain and query settings), and timeouts (check network latency).

---

Overview

IHE document sharing profiles (XDS.b, XCA) require clinical documents to be in standardized formats, most commonly CDA (Clinical Document Architecture). UCR stores clinical data internally in SDA (Summary Document Architecture) format. Therefore, transformations are needed to convert SDA data into CDA documents with appropriate XDS metadata for IHE-compliant document sharing.

CDA Document Structure

A CDA document consists of:

• CDA Header: Patient demographics, document metadata, author information, custodian, participants
• CDA Body: Clinical content organized into sections (structured or unstructured)
• Structured Body: Machine-readable clinical data using coded entries (preferred for interoperability)
• Unstructured Body: Human-readable narrative text (simpler but less interoperable)

CDA documents conform to templates that define required and optional sections:

• CCD (Continuity of Care Document): Comprehensive patient summary with standard sections
• Discharge Summary: Patient information at time of hospital discharge
• Referral Note: Clinical information for referral to another provider
• C-CDA templates: Consolidated CDA templates standardized by HL7 and ONC

SDA to CDA Transformation

The transformation process converts SDA data to CDA format:

1. SDA extraction: Retrieve relevant SDA streamlets from the patient's data container 2. Section mapping: Map SDA streamlet types to CDA document sections

• SDA Medications -> CDA Medications section
• SDA Diagnoses -> CDA Problems section
• SDA Lab Results -> CDA Results section
• SDA Allergies -> CDA Allergies section
• SDA Procedures -> CDA Procedures section

3. Code translation: Convert internal codes to standard terminology (SNOMED, LOINC, ICD, RxNorm) 4. Narrative generation: Generate human-readable narrative text for each CDA section 5. Header assembly: Populate the CDA header with patient demographics, author, and custodian information 6. Document packaging: Assemble the complete CDA XML document

Transformation Classes

UCR provides built-in transformation classes:

• HS.SDA3.Streamlet.ToSDA: Converts individual SDA streamlets to SDA XML
• HS.IHE.XDSb.Transformer.SDAToXDSb: Transforms SDA data into XDS.b-compliant CDA documents
• HS.Gateway.SDA3.SDA3ToCDA: Core SDA-to-CDA transformation logic
• Custom transformation classes can extend these base classes for organization-specific requirements

XDS Metadata Generation

When sharing CDA documents through XDS.b, metadata must be generated including: document unique ID, patient ID in the affinity domain, class code, type code, format code, healthcare facility type, practice setting, creation time, service start/stop time, confidentiality code, and author information. This metadata is registered in the XDS.b Document Registry and enables consumers to discover and retrieve documents.

Customizing Transformations

Organizations can extend the base transformation class to modify section content, add custom CDA sections, adjust code translation mappings, and customize narrative generation for organization-specific requirements.

---

Overview

The HealthShare Bus production is the runtime engine that executes all IHE transactions in UCR. The Bus provides the infrastructure for receiving, processing, routing, and sending IHE messages. Understanding how the Bus performs IHE functions is essential for configuring, monitoring, and troubleshooting IHE integrations.

Bus Architecture for IHE

The Bus production follows the standard Ensemble/Interoperability pattern:

• Business Services: Receive inbound IHE messages from external systems (HTTP listeners, TCP listeners)
• Business Processes: Orchestrate the processing of IHE transactions (validation, routing, response generation)
• Business Operations: Send outbound IHE messages to external systems (HTTP/SOAP clients, TCP clients)
• Message Classes: Define the structure of IHE messages as they flow through the Bus
• Routing Rules: Determine how messages are routed between components

How the Bus Performs IHE Functions

Inbound IHE Processing (UCR as IHE Server): 1. An external system sends an IHE transaction to a UCR business service endpoint 2. The business service parses the incoming message into an internal message object 3. The business service forwards the message to the appropriate business process 4. The business process validates the message, performs the requested operation (registry query, document retrieval, PIX lookup), and generates a response 5. The response is returned to the business service, which sends it back to the external system

Outbound IHE Processing (UCR as IHE Client): 1. An internal process or user action triggers an outbound IHE transaction 2. A business process creates the appropriate IHE request message 3. The business process sends the request to a business operation 4. The business operation transmits the message to the external IHE endpoint 5. The external system processes the request and returns a response 6. The business operation receives the response and forwards it to the business process for handling

External System Integration via the Bus

The Bus connects UCR to external IHE-compliant systems:

• HIE connections: Connect to regional or national health information exchanges through XDS.b and XCA
• EHR integration: Exchange patient identifiers and documents with external EHR systems through PIX and XDS.b
• Community networks: Participate in cross-community document sharing through XCA gateways
• Audit repositories: Send ATNA audit records to centralized audit log repositories

Production Monitoring for IHE

Monitor IHE transaction flow through the Management Portal:

• Message Viewer: View individual IHE messages as they flow through the Bus, including request/response pairs
• Visual Trace: Follow a single IHE transaction through all Bus components from receipt to response
• Event Log: Review errors, warnings, and informational messages from IHE components
• Queue Monitor: Check business host queue depths to identify processing bottlenecks
• Dashboard: Overview of production health including IHE component status

Troubleshooting and Best Practices

Common troubleshooting steps:

• Verify IHE business hosts are enabled; check queue depths for processing delays
• Review connection settings (endpoint URL, port, credentials) for failed operations
• Examine the message viewer and event log for rejected messages and transformation errors
• Adjust timeout settings for slow external systems

Best practices include enabling only required IHE profiles, configuring appropriate timeouts, setting up error alerting, using separate business hosts per external system to isolate failures, and ensuring TLS certificates are properly configured for ATNA compliance.

---