Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/TR 28380-2 — Health Informatics: IHE — Part 2: Integration Aspects
Technical Framework for Cross-Domain Healthcare Integration and Workflow Orchestration
Integration Aspects in Healthcare: ISO/TR 28380-2 Overview
ISO/TR 28380-2 addresses the integration aspects of healthcare information systems, focusing on how IHE profiles work together across clinical domains to support end-to-end healthcare workflows. While Part 1 introduces individual integration profiles, Part 2 examines the interactions between profiles, the dependencies that exist between them, and the architectural patterns needed to create coherent cross-domain integration solutions. This technical report is essential reading for architects and integrators responsible for designing enterprise-wide health information exchange infrastructures.
The report recognizes that real-world healthcare delivery involves complex workflows that span multiple clinical domains, departments, and organizations. A typical patient journey may involve interactions with radiology, laboratory, pharmacy, primary care, and specialist services, each supported by different information systems that must communicate seamlessly. ISO/TR 28380-2 provides guidance on composing IHE profiles to support these multi-domain clinical workflows while maintaining data consistency, patient safety, and clinical governance.
When designing cross-domain healthcare integrations, start by mapping the complete clinical workflow from end to end, then identify the IHE profiles that support each segment. Pay special attention to handoff points between domains, where data loss or miscommunication is most likely to occur.
Cross-Domain Workflow Patterns
ISO/TR 28380-2 describes several recurring cross-domain workflow patterns that appear across healthcare integration scenarios. The patient-centric workflow pattern organizes integration around the patient journey, ensuring that all relevant clinical data follows the patient across care settings. This pattern relies heavily on the XDS and PIX profiles to maintain document availability and patient identity correlation across organizational boundaries. The order-to-result workflow pattern, common in laboratory and radiology, involves order placement, specimen tracking, result generation, and result delivery across multiple systems.
| Workflow Pattern | Description | Key Profiles |
|---|---|---|
| Patient-Centric | Data follows the patient across care settings and enterprises | XDS, PIX, PDQ, XCPD |
| Order-to-Result | Order placement, fulfillment, results delivery | RAD, LAB, SWF, ORM |
| Referral-to-Consultation | Referral request, clinical review, consultation report | XDS, XCA, XCPD |
| Medication Management | Prescribing, dispensing, administration, reconciliation | CM, DIS, PRE, PML |
| Public Health Reporting | Case reporting, notifiable conditions, population surveillance | XDS, QED, PIX |
The report also addresses the challenge of workflow orchestration across heterogeneous systems with different capabilities and availability characteristics. It discusses synchronous versus asynchronous communication patterns, event-driven integration, and the role of clinical document exchange as a fundamental integration mechanism. The technical report emphasizes that successful cross-domain integration requires not only technical interoperability but also semantic interoperability, ensuring that the meaning of exchanged clinical information is preserved across system boundaries.
Cross-domain workflows introduce latency and reliability challenges that are not present in single-system scenarios. Design your integration architecture to handle asynchronous responses gracefully, implement timeout handling with clinical fallback procedures, and monitor transaction completion to detect hung or failed exchanges.
Transaction Models and Communication Patterns
ISO/TR 28380-2 defines several transaction models used within IHE profiles and provides guidance on selecting appropriate patterns for different integration scenarios. The request-response model is used for synchronous interactions where immediate feedback is required, such as patient identity queries. The publish-subscribe model supports event-driven integration where systems need to be notified of relevant events without continuous polling. The document submission model, central to XDS, supports reliable asynchronous document exchange with registry-based discovery.
| Transaction Model | Communication Style | Typical Use Cases |
|---|---|---|
| Request-Response | Synchronous | Patient identity query, demographics lookup, document retrieval |
| Publish-Subscribe | Asynchronous event-driven | Result availability notification, patient update alerts |
| Document Submission | Asynchronous reliable | Clinical document sharing, diagnostic report submission |
| Query-Retrieve | Synchronous with discovery | Document registry query, subsequent document retrieval |
| Alert-Notification | Asynchronous urgent | Critical result alert, public health notification |
The report provides detailed guidance on transaction reliability, addressing message acknowledgment, error handling, retry strategies, and idempotency requirements. It emphasizes that healthcare transactions often require audit logging for regulatory compliance and clinical safety, and that transaction tracking mechanisms should be built into integration infrastructure from the outset rather than retrofitted. The ATNA profile provides a standardized approach to audit logging that should be implemented across all integration transactions.
Implementing consistent transaction tracking and audit logging across all integrated systems provides multiple benefits beyond regulatory compliance: it enables root cause analysis of integration failures, supports clinical governance, and provides the data needed to monitor and optimize integration performance over time.
Integration Architecture and Governance
ISO/TR 28380-2 addresses the architectural considerations for enterprise healthcare integration, including integration engine deployment patterns, interface specification management, and integration testing strategies. The report describes a layered integration architecture with presentation-level integration (portal-based), application-level integration (API-based), and data-level integration (document exchange). Each layer has different characteristics in terms of coupling, flexibility, performance, and governance requirements.
The technical report also covers integration governance, emphasizing the need for formal integration agreements between participating organizations. These agreements should specify the IHE profiles to be implemented, the required transaction options, the security and privacy policies to be applied, the service level expectations for integration availability and performance, and the procedures for change management and version migration. The report recommends establishing an integration governance board with representation from all participating organizations to oversee the integration lifecycle.
Integration governance is often overlooked in healthcare interoperability projects, leading to unsustainable point-to-point interfaces and technical debt. Establish a formal integration governance structure before implementing technical solutions, and ensure that all interface changes follow a documented change management process with impact assessment and regression testing.
Frequently Asked Questions
Q1: How does ISO/TR 28380-2 differ from ISO/TR 28380-1?
Part 1 introduces IHE concepts and individual integration profiles, while Part 2 focuses on the integration aspects of combining profiles across clinical domains. Part 2 addresses cross-domain workflow patterns, transaction models, architectural considerations, and integration governance, making it more relevant for enterprise architects and integration specialists.
Part 1 introduces IHE concepts and individual integration profiles, while Part 2 focuses on the integration aspects of combining profiles across clinical domains. Part 2 addresses cross-domain workflow patterns, transaction models, architectural considerations, and integration governance, making it more relevant for enterprise architects and integration specialists.
Q2: What is the most challenging aspect of cross-domain healthcare integration?
Patient identity correlation across organizational boundaries remains the most persistent challenge. Different organizations use different patient identifiers, and achieving reliable identity matching without creating safety risks requires careful implementation of PIX profiles complemented by robust patient matching algorithms and manual review processes.
Patient identity correlation across organizational boundaries remains the most persistent challenge. Different organizations use different patient identifiers, and achieving reliable identity matching without creating safety risks requires careful implementation of PIX profiles complemented by robust patient matching algorithms and manual review processes.
Q3: Can IHE profiles be implemented incrementally?
Yes, the report recommends an incremental implementation approach, starting with foundational profiles such as ATNA (security) and CT (time synchronization), then adding XDS for document sharing, followed by domain-specific profiles. This approach builds a solid infrastructure foundation while managing implementation risk.
Yes, the report recommends an incremental implementation approach, starting with foundational profiles such as ATNA (security) and CT (time synchronization), then adding XDS for document sharing, followed by domain-specific profiles. This approach builds a solid infrastructure foundation while managing implementation risk.
Q4: How should integration performance be monitored?
The report recommends implementing transaction-level monitoring with metrics including transaction volume, response time, error rate, and mean time to recovery. Integration monitoring should be integrated with existing enterprise monitoring tools and should include automated alerting for transaction failures and performance degradation.
The report recommends implementing transaction-level monitoring with metrics including transaction volume, response time, error rate, and mean time to recovery. Integration monitoring should be integrated with existing enterprise monitoring tools and should include automated alerting for transaction failures and performance degradation.
📥 Standard Documents Download
No download files available yet