2.0 Transaction Definition

2.1 Context Overview

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

1. Data to be collected/audited are identified

2. Data to be reported for audit are formatted

3. Data to be reported for audit are collected

4. Reports are provided for analysis of audit data

5. Audit data are retained for analysis

6. Automated responses are provided for audit data

7. Alerts and alarms are provided for security audit

8. Identity of users is recorded whenever a protected resource is accessed

9. Time of access is recorded whenever a protected resource is accessed

10. Identity of users is recorded whenever registration data are accessed

11. Time of access is recorded whenever registration data are accessed

This HITSP Transaction references the Integrating the Healthcare Enterprise (IHE) Audit Trail and Node Authentication (IHE ATNA) Integration Profile to accomplish audit trail assurances in support of document-sharing and to support audit trails for message-based communications.

The text for the IHE ATNA profile, Section 9.2 begins here:

User Accountability is provided through Audit Trail. The Audit Trail needs to allow a security officer in an institution to audit activities, to assess compliance with a secure domains policies, to detect instances of non-compliant behavior, and to facilitate detection of improper creation, access, modification and deletion of Protected Health Information (PHI). PHI is considered to be the patient-identifiable information records (e.g., Registration, Order, Study/Procedure, Reports, Images, and Presentation States). PHI may be accessed by users or exchanged between the systems. This includes information exported to and imported from every secured node in the secure domain.

The audit trail contains information so that questions can be answered such as:

For some user: which patients PHI was accessed?

For some patient PHI: which users accessed it?

What user authentication failures were reported?

What node authentication failures were reported?

The text for the IHE ATNA profile, Section 9.2 ends here.

The format and content of audit reports are subject to local implementation policy and set by the organizations, guided by the ASTM E2147 standard. HITSP does not specify these policies or their application (see Section 2.1.5.1 Required Output).

The specific choice and operation of automated actions is subject to local implementation policy and set by the organizations, guided by the ISO 10164-7 standard. HITSP does not specify these policies or their application (see Section 2.1.5.1 Required Output).

Many events are auditable, but the choice to create and communicate the audit record or to report the data, commonly called selective auditing, and selective audit reporting, is subject to local implementation policy. HITSP does not specify these policies or their application.

2.1.1 Transaction Constraints

Table 2-1 Transaction Constraints

Constraint
The provisional format for audit records defined in IHE ATNA shall not be used
The transport protocol for audit record communication shall be BSD syslog [1] , per the IHE ATNA specification

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.20 (IHE ITI-TF-2).

Table 2-2 Interfaces

Interface	Description	Used in Component/ Composite Standard	Required = R Optional = O Conditional = C [2]
Audit Record Repository	Provides a repository for audit events	IHE ITI-TF-2	R
Audit Record Source	Creates and communicates an Audit Record to the Audit Record Repository on behalf of another interface that performs an action requiring logging	IHE ITI-TF-2	R
<any interface grouped with a Secure Node interface> (e.g., Node)	Any interface from the HITSP Interoperability Specification that is grouped with Secure Node (e.g., 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-2	R

2.1.3 Interface Interactions

Figure 2-1 Interface Interactions

An audit trigger event occurs within the Audit Record Source. This causes the Audit Record Source to format and produce an audit record, according to locally-defined policies, and send it to the Audit Record Repository. The Audit Record Repository will subsequently perform reporting, alarming, or alerting according to locally defined policies.

Locally defined policies at the Audit Record Source may specify selective suppression of auditing records for certain events that have been determined to be inconsequential.

Locally defined policies at the Audit Record Repository will specify report format, production times, and distribution. They may also specify automated alarms or alerts for certain events of high importance, suppress reporting or report certain types of events until threshold values for similar/recurring events occur and enable selective reporting to investigate user activity, etc.

2.1.4 Pre-conditions

Table 2-3 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
Identities are managed
Policy defining the protection of the log and audit exists and is being enforced

2.1.4.1 Process Triggers

Table 2-4 Process Triggers

Process Trigger
An action requiring logging occurs
Audit records are created (trigger for communicated)
Audit records are received (triggers for reports/alarms/alerts)

Various Transaction triggers are described in Table 3.20.6-1 of IHE ITI-TF-2. These are the minimum transaction triggers in order to maintain commonality with an established standard, satisfy the implied policy issues in the Use Cases that call for auditing and still allow for organizations to further define audit policies that can be supported by a log standard.

2.1.5 Post-conditions

Table 2-5 Post-conditions

Post-condition
Audit record is created, communicated, stored, and analyzed
Subsequent action initiated per policy, e.g., reports and other automated actions

2.1.5.1 Required Output

Table 2-6 Required Outputs

Required Output	Format/Usage
Audit record	Defined in Section 3.20.7.1 of IHE-ITI-TF-2
Security audit alarms	Defined in ISO 10164-7
Security report	Defined in ASTM E2147-01

2.1.6 Data Flows

All data flows associated with this Transaction are specified in Section 3.20 of IHE-ITI-TF-2.

2.2 List of HITSP Constructs

Table 2-7 List of HITSP Constructs

Construct Name	Description	Event/Action Code	Content
No applicable HITSP constructs

2.2.1 Construct Dependencies

Table 2-8 Construct Dependencies

Construct	Depends On (Name of Component that it depends on)	Dependency Type (Pre-condition, post-condition, general)	Purpose (Reason for this dependency)
No applicable dependencies

2.2.2 Additional Constraints on Required Constructs

Table 2-9 Additional Constraints on Required Constructs

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

2.3 Standards

2.3.1 Regulatory Guidance

Table 2-10 Regulatory Guidance

Standard	Description
No applicable regulatory guidance

2.3.2 Selected Standards

Table 2-11 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	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

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.3.3 Informative Reference Standards

Table 2-12 Informative Reference Standards

Standard	Description
ASTM International Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems: # E2147-01	E2147-01 is for the development and implementation of security audit/disclosure logs for health information. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of health information to external users for use in manual and computer systems. The process of information disclosure and auditing should conform, where relevant, with the Privacy Act of 1974 (1). For more information visit www.astm.org
International Organization for Standardization (ISO) Health Informatics -- Information technology -- Open Systems Interconnection -- Systems Management: Security alarm reporting function, Technical Specification #10164-- Part 7: Security Alarm Reporting Function, 1992	Establishes user requirements for the service definition needed to support the security alarm reporting function, defines the service provided by the security alarm reporting function, specifies the protocol that is necessary in order to provide the service, defines the relationship between the service and management notifications, defines relationships with other systems management functions, specifies conformance requirements. The security alarm reporting function is a systems management function which may be used by an application process in a centralized or decentralized management environment to exchange information for the purpose of systems management. For more information visit www.iso.org

	Return to detail page at www.hitsp.org	HITSP/T15
	Prev TOC Next