1 Introduction
This document, Volume 1 of the IHE IT Infrastructure (ITI) Technical Framework, describes the clinical use cases, actors, content module, and transaction requirements for the ITI profiles.
1.1 Introduction to IHE
Integrating the Healthcare Enterprise (IHE) is an international initiative to promote the use of standards to achieve interoperability among health information technology (HIT) systems and effective use of electronic health records (EHRs). IHE provides a forum for care providers, HIT experts and other stakeholders in several clinical and operational domains to reach consensus on standards-based solutions to critical interoperability issues.
The primary output of IHE is system implementation guides, called IHE profiles. IHE publishes each profile through a well-defined process of public review and Trial Implementation and gathers profiles that have reached Final Text status into an IHE Technical Framework, of which this volume is a part.
For general information regarding IHE, refer to www.ihe.net. It is strongly recommended that, prior to reading this volume, the reader familiarizes themselves with the concepts defined in the IHE Technical Frameworks General Introduction.
1.2 Introduction to IHE IT Infrastructure (ITI) Technical Framework
This document, the IHE IT Infrastructure Technical Framework (ITI TF), defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. It is expanded annually, after a period of public review, and maintained regularly through the identification and correction of errata. The latest version of the document is always available at http://profiles.ihe.net/ITI/TF/index.html.
The IHE IT Infrastructure Technical Framework identifies a subset of the functional components of the healthcare enterprise, called IHE actors, and specifies their interactions in terms of a set of coordinated, standards-based transactions. It describes this body of transactions in progressively greater depth. The present volume (ITI TF-1) provides a high-level view of IHE functionality, showing the transactions organized into functional units called integration profiles that highlight their capacity to address specific IT Infrastructure requirements.
1.3 Intended Audience
The intended audience of IHE Technical Frameworks Volume 1 (Profiles) is:
- Those interested in integrating healthcare information systems and workflows
- IT departments of healthcare institutions
- Technical staff of vendors participating in the IHE initiative
1.4 Prerequisites and Reference Material
For more general information regarding IHE, refer to www.ihe.net. It is strongly recommended that, prior to reading this volume, the reader familiarizes themselves with the concepts defined in the IHE Technical Frameworks General Introduction.
Additional reference material available includes:
1.4.1 Actor Descriptions
Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise.
A list of actors defined for all domains and their brief descriptions can be found as Appendix A to the IHE Technical Frameworks General Introduction.
1.4.2 Transaction Descriptions
Transactions are interactions between actors that transfer the required information through standards-based messages.
A list of transactions defined for all domains, their transactions numbers, and a brief description can be found as Appendix B to the IHE Technical Frameworks General Introduction.
1.4.3 IHE Integration Statements
IHE Integration Statements provide a consistent way to document high level IHE implementation status in products between vendors and users.
The instructions and template for IHE Integration Statements can be found as Appendix F to the IHE Technical Frameworks General Introduction.
IHE also provides the IHE Product Registry (http://www.ihe.net/IHE_Product_Registry as a resource for vendors and purchasers of HIT systems to communicate about the IHE compliance of such systems. Vendors can use the Product Registry to generate and register Integration Statements.
1.5 Overview of Technical Framework Volume 1
Volume 1 is comprised of several distinct sections:
- Section 1 provides background and reference material.
- Section 2 presents the conventions used in this volume to define the profiles.
- Sections 3 and beyond define ITI profiles, actors, and requirements in detail.
The appendices in Volume 1 provide clarification of uses cases or other details. A glossary of terms and acronyms used in the IHE Technical Framework is provided in Appendix D to the IHE Technical Frameworks General Introduction.
1.6 Comment Process
IHE International welcomes comments on this document and the IHE initiative. Comments on the IHE initiative can be submitted by sending an email to the co-chairs and secretary of the IT Infrastructure domain committees at iti@ihe.net. Comments on this document can be submitted at http://ihe.net/ITI_Public_Comments.
1.7 Copyright Licenses
IHE technical documents refer to, and make use of, a number of standards developed and published by several standards organizations. Please refer to the IHE Technical Frameworks General Introduction, Chapter 9 - Copyright Licenses for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there.
1.8 Trademark
IHE® and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. They may only be used with the written consent of the IHE International Board Operations Committee, which may be given to a Member Organization in broad terms for any use that is consistent with the IHE mission and operating principles.
1.9 Disclaimer Regarding Patent Rights
Attention is called to the possibility that implementation of the specifications in this document may require use of subject matter covered by patent rights. By publication of this document, no position is taken with respect to the existence or validity of any patent rights in connection therewith. IHE International is not responsible for identifying Necessary Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of the specifications in this document are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information about the IHE International patent disclosure process including links to forms for making disclosures is available at http://www.ihe.net/Patent_Disclosure_Process. Please address questions about the patent disclosure process to the secretary of the IHE International Board: secretary@ihe.net.
1.10 History of Document Changes
This section provides a brief summary of changes and additions to this document.
| Date | Document Revision | Change Summary |
| 2015 - 2020 | Various |
Refer to the ITI Technical Framework – Log of Integrated Change Proposals (CPs) for details on annual updates made via Change Proposals to the ITI Technical Framework Volumes and Trial Implementation Supplements. |
| July 2018 | ITI TF Rev. 15.0 | Integrated the “Delayed Document Assembly” Trial Implementation Supplement. |
| July 2019 | ITI TF Rev. 16.0 | No Trial Implementation Supplements were integrated in this revision. |
| July 2020 | ITI TF Rev. 17.0 | Added the XAD-PID Change Management (XPID) Profile that describes how changes to the links between local patient identifiers and the identifier used by the XDS Affinity Domain can be communicated and managed. |
| July 2021 | ITI TF Rev. 18.0 | Integration of approved CPs. |
| June 2022 | ITI TF Rev. 19.0 | Integration of approved CPs. |
| August 2023 | ITI TF Rev. 20.0 | Integration of approved CPs. |
1.11 Security Implications
IHE transactions often contain information that must be protected in conformance with privacy laws and regulations, such as HIPAA, GDPR, or similar requirements in other regions. IHE includes a few security and privacy-focused profiles listed below. Other IHE Profiles generally do not have specific privacy protections, but rather expect a proper grouping with one or more of the security profiles:
- The Audit Trail and Node Authentication (ATNA) Profile specifies a means to ensure that nodes in a network are authenticated.
- The ATNA Profile specifies an audit message for reporting security- and privacy-relevant events.
- The Enterprise User Authentication (EUA) Profile specifies a means to authenticate system users and to share knowledge of the authenticated users among applications.
- The Cross-Enterprise User Assertion(XUA) Profile provides a means to carry federated user assertions for authentication and authorization.
- The Internet User Authorization (IUA) Profile provides a means to use OAuth security authorization tokens with http RESTful services (e.g. FHIR).
- The Basic Patient Privacy Consents (BPPC) Profile provides a means for Patient Privacy Policy Domain (e.g., an XDS Affinity Domain) to have a number of Patient Privacy Policies that can be acknowledged (aka consent) by a Patient.
- The Advanced Patient Privacy Consents (APPC) Profile enables the capturing of consent(s) that cannot be adequately expressed using the Basic Patient Privacy Consents (BPPC) Profile.
- The Document Digital Signature (DSG) Profile defines general purpose methods of digitally signing of documents for communication and persistence.
- The Document Encryption (DEN) Profile defines general purpose methods of digitally encrypting a document for communication and persistence.
- The Secure Retrieve (SeR) Profile defines access control decision and enforcement mechanism for use with XDS.
Implementers may follow these IHE profiles to fulfill some of their security needs. It is understood that institutions must implement policy and workflow steps to satisfy enterprise needs and to comply with regulatory requirements.