4.0 document updates

The following sections provide the history of all changes made to this document since the last publication.

4.1 October 5, 2007

The changes in this cycle address the following comments received during the Public Comment and Inspection Testing period (July 23, 2006 - August 17, 2007):

1205, 1239, 1240, 1261

The full text of the comments along with the Technical Committees disposition can be reviewed on the HITSP Public Web Site.

4.2 October 15, 2007

Upon approval by the HITSP Panel on October 15, 2007, this document has been moved to Version 1.1. This document is now Released for Implementation.

4.3 July 11 , 2008

Updated to place standards into 3 categories: Regulatory, Selected, and Informative References. Also provided clarifications for VPN use.

4.4 August 20, 2008

This document has been modified to reflect the updated HITSP approach to categorizing standards as Regulatory Guidance, Selected Standards, and Informative References.

The following standard was added as selected, as a more specific standard reference to ATNA Profile:

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

4.5 August 27, 2008

Upon approval by the HITSP Panel on August 27, 2008, this document is now Released for Implementation.

4.6 December 10, 2008

This document has been edited to incorporate the updated version of the IHE ATNA standard to IHE ITI-TF Revision 5.0.

Minor editorial changes were made to this document.

4.7 December 18, 2008

Upon approval by the HITSP Panel on December 18, 2008, this document is now Released for Implementation.

4.8 June 30, 2009

Minor editorial changes were made to this document. Boilerplate text was removed for simplification. The term actor was replaced with interface.

4.9 July 8, 2009

Upon approval by the HITSP Panel on July 8, 2009, this document is now Released for Implementation.



[1] When there is a known security mechanism connecting two secured networks (e.g., physical isolation or VPN), this construct may be determined by the local security administrators to be unnecessary. The Node shall be configurable to disable the use of this construct.