HITSP Secured Communication Channel Transaction

The following are the requirements derived from the initial Use Cases for this Transaction:

1. Session used to transmit data has mutual authentication of the nodes involved

This construct utilizes the Authenticate Node Transaction from the Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Audit Trail and Node Authentication (ATNA) Integration Profile (IHE-ITI-TF ATNA), Section 9.1.

2.1.1 Transaction Constraints

Constraint
Only communications requiring the attributes of transmission authenticity, transmission confidentiality, and transmission integrity need to utilize this construct for session oriented, synchronous, and point-to-point communication channels

Consistent with this constraint, those communications that require the attributes of transmission authenticity, confidentiality, and integrity shall either be prohibited, or designed and verified to prevent access to Protected Health Information (PHI) if they are not communicated through connections that provide session oriented, synchronous, and point-to-point communication channels [1] .

2.1.2 Interfaces

All Interfaces for this Transaction are described further in the Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework, Volume 2, Section 3.19 (IHE ITI-TF-2).

Interface	Description	Used in Component/ Composite Standard	Required = R Optional = O Conditional = C
Node	The originating or terminating point of information or signal flow in a telecommunications network. This interface is equivalent to the Secure Node in the IHE-ITI-TF ATNA Transaction	IHE-ITI-TF ATNA	R

2.1.3 Interface Interactions

Figure 2-1 illustrates the mutual authentication of nodes producing a secured communication channel. The detailed interface interactions for authentication are deliberately omitted from the diagram and are incorporated by reference through IHE-ITI-TF2, Section 3.19.

The act of node authentication precedes all Transactions for HITSP interoperability constructs that require a secured communication channel. Once the secured communication channel is established, the HITSP Transactions continue inside the channel according to the Interoperability Specification.

2.1.4 Pre-conditions

Pre-condition
A policy defining what is to be audited exists
Audit record repository is active and designated as the destination for recorded audit events
Audit record source is initialized to the audit policy
Consistent Time construct is a pre-requisite for this Transaction
Existence of active and network accessible nodes
Identities are managed
Policy defining the protection of the log and audit exists and is being enforced
There is a mutually agreed upon set of policies and procedures for establishment of mutually acceptable identity credentials

2.1.4.1 Process Triggers

Process Trigger
The Secured Communication Channel Transaction is triggered when a secured information exchange between two nodes is requested. The node interface represented in this Transaction is equivalent to the secure node interface in the IHE-ITI-TF ATNA Transaction. All triggers associated with this Transaction are specified in the IHE-ITI-TF ATNA Transaction

2.1.5 Post-conditions

Post-condition
A secured communication channel providing transmission confidentiality, transmission integrity, and session authenticity is established between the two nodes. This secured communication channel will be used for all future secure transmissions between the two nodes

2.1.5.1 Required Outputs

Required Output	Format/Usage
Enable node to record an audit event to indicate successful connection from nodes that are mutually authenticated	See HITSP/T15 - Collect and Communicate Security Audit Trail
Require node to record an audit event to indicate attempted connections from nodes that are not mutually authenticated	See HITSP/T15 - Collect and Communicate Security Audit Trail

2.1.6 Data Flows

2.2 List of HITSP Constructs

Construct Name	Description	Event/Action Code	Content
HITSP/T15 - Collect and Communicate Security Audit Trail	Provides a means to ensure that security policies are being enforced and that risks are being mitigated	Various (HITSP Use Case dependent)	Identification and management of audit trigger events and audit event outputs

2.2.1 Construct Dependencies

Construct	Depends On (Name of Component that it depends on)	Dependency Type (Pre-condition, post-condition, general)	Purpose (Reason for this dependency)
HITSP/T17 - Secured Communication Channel	HITSP/T15 - Collect and Communicate Security Audit Trail	General	Identification and management of audit trigger events and audit event outputs

2.2.2 Additional Constraints on Required Constructs

Data Element	Construct	Constraint	Constraint Type (Pre-condition, post-condition, general)	Purpose (Reason for this constraint)
No applicable constraints

2.3 Standards

2.3.1 Regulatory Guidance

Standard	Description
No applicable regulatory guidance

2.3.2 Selected Standards

Standard	Description
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 or later, Audit Trail and Node Authentication (ATNA) Integration Profile, Section 9.1 Authentication	Audit Trail and Node Authentication (ATNA) establishes the characteristics of a Basic Secure Node. It describes the security environment (user identification, authentication, authorization, access control, etc.) assumed for the node so that security reviewers may decide whether this matches their environments. It defines basic auditing requirements for the node. It defines basic security requirements for the communications of the node using TLS or equivalent functionality. It establishes the characteristics of the communication of audit messages between the Basic Secure Nodes and Audit Repository nodes that collect audit information. This integration profile has been designed so that specific domain frameworks may extend it through an option defined in the domain specific technical framework. Extensions are used to define additional audit event reporting requirements, especially interface specific requirements. The latest version of the IHE Technical Framework is available at www.ihe.net

Standard

Description

Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 or later, Audit Trail and Node Authentication (ATNA) Integration Profile, Section 9.1 Authentication

Audit Trail and Node Authentication (ATNA) establishes the characteristics of a Basic Secure Node. It describes the security environment (user identification, authentication, authorization, access control, etc.) assumed for the node so that security reviewers may decide whether this matches their environments. It defines basic auditing requirements for the node. It defines basic security requirements for the communications of the node using TLS or equivalent functionality. It establishes the characteristics of the communication of audit messages between the Basic Secure Nodes and Audit Repository nodes that collect audit information. This integration profile has been designed so that specific domain frameworks may extend it through an option defined in the domain specific technical framework. Extensions are used to define additional audit event reporting requirements, especially interface specific requirements. The latest version of the IHE Technical Framework is available at www.ihe.net

2.0 Transaction Definition

2.1 Context Overview