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

7 Technical Framework Document Conventions

The IHE Technical Frameworks have adopted the following conventions for representing the framework concepts and specifying how the standards upon which they are based should be applied.

7.1 Diagrams and Tables of IHE Actors and Transactions

Each integration profile models a real-world capability in terms of actors that interact through transactions.

The Actors and Transactions table in each profile in Volume 1 specifies which transactions each actor is required to support in that profile.

The Required Actor Groupings table in each profile in Volume 1 specifies actors the implementer is required to implement together. Such requirements combine capabilities necessary for the system to function properly and achieve the profile integration goals. For example, the Client Authentication Agent of the ITI Enterprise User Authentication (EUA) Profile is required to be grouped with the Time Client of the ITI Consistent Time (CT) Profile.

Note: In previous versions of technical framework documents, additional Grouping requirements were specified in a "Profile Dependencies" section that required actors in one profile to also implement the same actor in another profile on which the first depended. These are now folded into the Required Actor Groupings table.

The Actors and Options table in each profile in Volume 1 specifies Named Options for each actor. Implementers that choose to claim support for a named option are required to implement the specification sections referenced in the table.

The Actor Diagram in each profile in Volume 1 provides an overview of the actors in the profile and the transactions between them. Grouped actors will be shown as boxes that share a side. Rarely, actors from other profiles may be shown for context as dashed line boxes.

7.2 Process Flow Diagrams

Integration profiles often include process flow diagrams that illustrate how the profile functions as a sequence of transactions between relevant actors.

These diagrams are intended to provide an overview so the transactions can be seen in the context of an institution’s workflow. Certain transactions and activities not defined in detail by IHE are shown in these diagrams in italics to provide additional context on where the relevant IHE transactions fit into the broader scheme of healthcare information systems.

These diagrams are not intended to present the only possible scenario. Often, other actor groupings are possible and transactions from other profiles may be interspersed.

In some cases, the sequence of transactions may be flexible. Where this is the case there will generally be a note pointing out the possibility of variations. Transactions are shown as arrows oriented according to the flow of the primary information handled by the transaction and not necessarily away from the initiator.

7.3 Security Implications

IHE transactions often contain information that must be protected in conformance with privacy laws, regulations and best practices. This protection is documented in a Security Considerations section of each profile, which communicates security and privacy concerns that the implementers need to be aware of, assumptions made about security and privacy pre-conditions and, where appropriate, key elements of a risk mitigation strategy to be applied.

IHE includes several security and privacy-focused profiles. Other IHE profiles generally do not have specific privacy protections, but rather require a grouping of actors in one or more of the security profiles. It should be understood that institutions must implement policy and workflow steps to satisfy enterprise needs and to comply with regulatory requirements.

7.4 Content Modules

There is often a very clear distinction between the transactions in a messaging framework used to package and transmit information and the information content actually transmitted in those messages. In these cases, the same transactions may be used to support a wide variety of use cases in healthcare, such that the content needs to be profiled separately from the transaction itself. To this end, IHE has developed the concept of a Content Module.

Content Modules may be defined in a number of different standards, the two most prevalent being HL7 Clinical Document Architecture (CDA®) and DICOM Information Object Definitions (IODs).

Content profiles are typically defined with two actors, a Content Creator and a Content Consumer, which exchange the well-defined content module information.

For Content Creators and Content Consumers to function in the real world; however, those actors must be grouped with actors from a workflow or transport profile. For example, the Cardiology Imaging Report Content (CIRC) Profile defines the discrete content of a cardiology report. Typically, some of the data for the report is created and accessible from another machine such as a modality or other electronic health record. In this case, the Content Creator would be grouped with the Image Enabled Office (IEO) Report Creator. Once an instance of a content module is created, it is typically intended to be sent to another location or person. In this case, a Content Consumer could be grouped with an ITI Cross Enterprise Document Sharing (XDS.b) Document Consumer or a Cardiology Displayable Reports (DRPT) Report Manager. These potential actor groupings are defined in Volume 1 of a content module profile.

In addition to groupings, Content Consumers also have the following common set of options defined by the Patient Care Coordination (PCC) domain: 

  • View Option
  • Document Import Option
  • Section Import Option
  • Discrete Data Import Option

These options are defined in PCC TF-2: 3 and should be reviewed in detail.

Finally, when an actor that supports a content module is grouped with an actor that supports a transaction, some of the data from the content module must be carefully mapped into the metadata of the transaction used by the transport actor. This data mapping of a content module to a transaction is called “data binding”. For example, the XDS Document attribute “authorPerson” is explicitly defined to be the concatenation of several CDA attributes beginning with “ClinicalDocument/author/assignedPerson/name/family”, etc. The data bindings of CDA content modules to Cross Enterprise Document Sharing (XDS.b) Profiles is defined in the PCC domain. PCC TF-2: 4 should be reviewed in detail.

Appendix E of the General Introduction (this document) defines important content module conventions such as cardinality constraints and optionality constraints for DICOM, HL7 v2 messages, and HL7 CDA documents.

7.5 Technical Framework Cross-references

When references are made to another section within a Technical Framework volume, a section number is used by itself. When references are made to other volumes or to a Technical Framework in another domain, the following format is used:

  • <domain acronym> TF-<volume number>: <section number>, where
  • <domain acronym> is the short designator for the IHE domain (e.g., ITI = IT Infrastructure, RAD = Radiology)
  • <volume number> is the applicable volume within the given Technical Framework (e.g., 1, 2, 3), and
  • <section number> is the applicable section number.

For example:

  • PCC TF-1: 3.1 refers to Section 3.1 in Volume 1 of the IHE Patient Care Coordination Technical Framework.
  • RAD TF-3: 4.33 refers to Section 4.33 in Volume 3 of the IHE Radiology Technical Framework.
  • ITI TF-2: Appendix B refers to Appendix B in Volume 2 of the IHE IT Infrastructure Technical Framework.

When references are made to transaction numbers in the Technical Framework, the following format is used:

  • [<domain designator>-<transaction number>], where
  • <transaction number> is the transaction number within the specified domain.

For example:

  • [ITI-1] refers to Transaction 1 from the IHE IT Infrastructure Technical Framework.