IHE General Introduction
  • IHE General Introduction and Shared Appendices
    Revision 2.0 June 4, 2021

6 External Relationships

6.1 Relationship of IHE to Standards

IHE promotes the use of established standards. Conformance claims for products must still be made in direct reference to specific standards. IHE Technical Frameworks specify the use of standards maintained by Standards Development Organizations (SDOs) such as ISO, IEEE, IHTSDO, Regenstrief, NEMA, HL7, IETF, OASIS and W3C. As the scope of IHE expands, specifications based on other standards may be included as well.

The Technical Frameworks constrain these standards, but do not contradict conformance. If IHE identifies any errors in or extensions needed to existing standards, its policy is to report them to the appropriate standards bodies for resolution.

Appendix E describes documentation conventions used by IHE when profiling these standards.

6.2 Relationship of IHE to Real-world Products and Architectures

A key goal that underlies the structure of the IHE Technical Frameworks is to define and constrain details necessary for integration and interoperability, while permitting as much flexibility as possible for all other details. Most products will have many other features, behaviors and design details that are outside the scope of IHE. Product designers are encouraged to consider IHE requirements as a baseline and to build user-beneficial features that make creative use of the information provided through IHE integration. There is ample opportunity for creativity, ingenuity and differentiation.

IHE assigns transactions to actors, which are abstractions of components found in the real-world healthcare information system environment. While some transactions are traditionally performed by a certain category of product (e.g., a HIS, a PACS, a Clinical Data Repository, or a Cardiology Information System), IHE intentionally avoids assigning actors to a specific product category. IHE profiles depend on the defined actors being present, not on how the actors are allocated to products (one large system or multiple specialized systems, a single vendor or multiple vendors). This preserves freedom for users and vendors in how HIT components are implemented, purchased and deployed. IHE demonstrations emphasize the integration of multiple vendors’ systems based on the IHE Technical Frameworks.

Products may implement a wide variety of IHE actor combinations. A single physical product might implement only a single actor in a single profile. It is also common for a product to implement multiple actors in multiple profiles. When those actors communicate internally, IHE permits them to use proprietary methods that are equivalent to the IHE transactions; however, IHE requires the actors to be capable of communicating with actors on other systems using the defined IHE interfaces. This maintains reliable interoperability, while staying out of internal product design and allowing performance optimizations.

6.3 Relationship of IHE Actors to Product Implementations

Developers implementing IHE profiles must:

  • Select which profiles the product will support
  • For each profile, select which actors and/or content modules to implement
  • For each actor, select which defined options to implement

To comply with an actor in an IHE profile, a system must perform all the transactions and/or content modules required for that actor in that profile. A given product may implement more than one actor and more than one integration profile. When more than one actor is implemented in a single product, IHE refers to the actors as being “grouped”. Certain actor groupings are mandated by IHE, sometimes as a way of bringing necessary information or features together in a single system, sometimes as a way of binding content with transport or workflow.

A product implementation that incorporates a combination of IHE actors may combine those actors so that the internal communication is achieved by means other than transactions defined by IHE. For example, in the Radiology Scheduled Workflow Profile, a single system could be implemented as a RIS-PACS, encompassing the Department System Scheduler/Order Filler and the Image Manager Actors. The internal communications of this product have no bearing on the compliance of that system with the Scheduled Workflow profile. However, all required transactions of each actor must also be externally exposed for the system to claim IHE conformance for those actors.

At a Connectathon testing event, all the IHE transactions, options, or content modules for each actor are tested, even when the actors are combined in a single product. All required groupings are also tested.