Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
PD ISO TR 28380 — Health Informatics IHE Global Standards Adoption Technical Reports
Health Informatics — IHE Global Standards Adoption (ISO/TR 28380-1/2/3, BSI UK implementation)
🏥 PD ISO TR 28380 is the UK implementation, published by BSI, of the ISO/TR 28380 series of technical reports, prepared by UK Technical Committee IST/35 (Health informatics) and focused on IHE (Integrating the Healthcare Enterprise) global standards adoption in health informatics. The three parts in this batch are: Part 1, the process; Part 2, integration and content profiles; and Part 3, IHE characteristics and their expression. Together they form the framework for producing IHE interoperability specifications and are important guidance for interoperability construction and procurement acceptance of healthcare information systems.
💡 Interoperability among healthcare information systems (HIS, RIS, PACS, LIS) is a core challenge in health informatisation. By defining “Integration Profiles” and “Content Profiles”, IHE organises dispersed standards (e.g., HL7, DICOM) into testable implementation specifications, ensuring smooth information exchange between systems.
1. Series Overview 📌
IHE (Integrating the Healthcare Enterprise) is a healthcare-led interoperability framework that, by defining integration profiles, organises standards such as HL7, DICOM, and IHE into concrete “use-case” and “actor-transaction” models, verified through activities such as Connectathon. The ISO/TR 28380 series documents and standardises IHE’s global standards adoption process, enabling countries to consistently adopt and implement IHE profiles. BSI adopts them as “PD ISO/TR 28380-xxx”.
In this batch, Part 1 explains the IHE adoption process (how profiles are published, updated, and maintained), Part 2 specifies the structure and content requirements of integration and content profiles, and Part 3 explains how to express IHE characteristics in interoperability specifications and requirement documents.
2. Series Structure and Part Highlights 📋
| Part | Document Title | ISO Edition | Core Content |
|---|---|---|---|
| Part 1 | Process | ISO/TR 28380-1:2014 (Ed. 1.0) | IHE global standards adoption process: publication, updating, review, and maintenance of profiles |
| Part 2 | Integration and content profiles | ISO/TR 28380-2:2014 (Ed. 1.0) | Structure, content, and documentation requirements of integration and content profiles |
| Part 3 | IHE characteristics and their expression | ISO/TR 28380-3:2014 (Ed. 1.0) | Expression and documentation of IHE characteristics in interoperability specifications and requirement documents |
All three parts are classified under ICS 35.240.80 (IT applications in health care technology) and handled by the same UK technical committee IST/35, forming a complete system from “process” to “profiles” to “characteristic expression”, including the analysis framework of Interoperability Use Cases.
⚠️ This series comprises technical reports (TR) providing the framework for producing and adopting IHE profiles; they are not mandatory certification standards. Actual interoperability verification of healthcare IT systems typically relies on IHE Connectathon testing activities and procurement acceptance requirements.
3. Key Technical Requirements 🔧
1. IHE Global Standards Adoption Process (Part 1)
Part 1 specifies the IHE global standards adoption process, mainly including:
- Process: the life cycle of an IHE profile from conception, review, publication, to maintenance;
- Publication and update: version management and update mechanisms for profiles;
- Review and consistency: ensuring consistency and coordination with the referenced standards (HL7, DICOM, etc.).
2. Integration and Content Profiles (Part 2)
Part 2 specifies the requirements for IHE Integration Profiles and Content Profiles, mainly including:
- Profile structure: the document structure of a profile (actors, transactions, use cases, etc.);
- Content requirements: requirements for writing profile content (actors, transactions, data-content constraints);
- Documentation: guidance on writing testable, unambiguous profile documents.
3. IHE Characteristics and Their Expression (Part 3)
Part 3 explains how to express IHE characteristics (i.e., the interoperability capabilities provided by profiles) in various documents, mainly including:
- Interoperability use cases: the concept of an Interoperability Use Case and its decomposition into Technical Use Cases;
- Project Interoperability Specification: content and preparation method of a Project Interoperability Specification;
- Expression of characteristics: accurately expressing IHE characteristics in tender, procurement, and acceptance requirements to avoid ambiguity.
🚨 If healthcare IT interoperability rests only on “claims to support a standard” without testable IHE profiles and acceptance criteria, data-exchange failures often surface only at system integration. Procurement and acceptance should explicitly reference IHE profiles and interoperability use cases to form verifiable specifications.
4. Engineering Practice Applications 🛠️
- 📋 Procurement specifications: in hospital informatisation procurement, use IHE integration/content profiles and Project Interoperability Specifications as technical specifications, requiring suppliers to explicitly declare the specific profiles and actors they support.
- 🧪 Integration verification: referring to IHE Connectathon test methods, verify interoperability of data exchange among HIS/RIS/PACS/LIS before system go-live.
- 📝 Profile development: when participating in health information standardisation work, prepare or review IHE profile drafts according to the process and structure requirements of this series.
- 🤝 Cross-institution coordination: in regional healthcare, medical alliances, and mutual-recognition systems, use this series to guide unified data-exchange and interoperability specifications, promoting cross-institution information sharing.
5. Frequently Asked Questions ❓
❓ Q: What is an IHE Integration Profile?
A: An Integration Profile is a set of actors and transactions defined by IHE that describes how systems exchange information in a specific clinical scenario (e.g., the examination flow between PACS and RIS). It organises standards such as HL7 and DICOM into testable specifications.
A: An Integration Profile is a set of actors and transactions defined by IHE that describes how systems exchange information in a specific clinical scenario (e.g., the examination flow between PACS and RIS). It organises standards such as HL7 and DICOM into testable specifications.
❓ Q: What is the difference between Parts 2 and 3?
A: Part 2 specifies the structure and content of the integration/content profiles themselves; Part 3 explains how to express IHE characteristics (interoperability capabilities) in tender, procurement, and acceptance documents, and introduces the interoperability use-case framework.
A: Part 2 specifies the structure and content of the integration/content profiles themselves; Part 3 explains how to express IHE characteristics (interoperability capabilities) in tender, procurement, and acceptance documents, and introduces the interoperability use-case framework.
❓ Q: What is the relationship between IHE and HL7/DICOM?
A: HL7 and DICOM are foundational standards for healthcare information exchange; IHE does not replace them, but defines how to use them to realise specific clinical workflows, forming testable, procurable integration profiles.
A: HL7 and DICOM are foundational standards for healthcare information exchange; IHE does not replace them, but defines how to use them to realise specific clinical workflows, forming testable, procurable integration profiles.
🔍 Q: Is this series mandatory?
A: No. It is a technical report (TR) providing the framework for producing and adopting IHE profiles. Actual verification typically runs through IHE Connectathon and procurement acceptance requirements.
A: No. It is a technical report (TR) providing the framework for producing and adopting IHE profiles. Actual verification typically runs through IHE Connectathon and procurement acceptance requirements.