Difference between revisions of "Audit Trail and Node Authentication"

From IHE Wiki
Jump to navigation Jump to search
Line 1: Line 1:
−
Audit Trail and Node Authentication [ATNA] describes certificate-based node authentication and transmitting PHI-related audit events to a repository. This helps sites implement confidentiality policies.
 
−
 
−
 
 
__TOC__
 
__TOC__
  
Line 7: Line 4:
 
==Summary==
 
==Summary==
  
−
The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security measures which, together with the Security Policy and Procedures of the enterprise, provide patient information confidentiality, data integrity and user accountability.  
+
The '''Audit Trail and Node Authentication (ATNA)''' Integration Profile establishes security measures which, together with the Security Policy and Procedures, provide patient information confidentiality, data integrity and user accountability.
  
−
ATNA requires the use of bi-directional certificate-based node authentication for connections to and from each node, and requires that events concerning PHI use are recorded and transmitted to a repository where they can be monitored to detect indications of inappropriate activity.
+
==Benefits==
−
 
 
−
''<Insert a simple graphic that, at a glance, visually summarizes what the profile is about.  Do not use an actor/transaction diagram here.  Show your graphic to someone for 5 seconds (literally) and ask them what it's about.  If what they say hits the main points in your summary paragraph, you have succeeded.  E.g. a graphic of a hospital, a clinic, and a lab with patient records moving between them.  .>''
 
−
 
 
−
''<See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on inserting an image/graphic.>''
 
  
−
==Benefits==
+
'''Assistance to sites in implementing security and confidentiality policies'''
−
''<List the key benefits the profile provides (e.g. error reduction, increased throughput) and how they come about (e.g. SWF reduces patient errors due to mistyped demographics at the modality by transfering demographics electronically from the Order Filler). Consider using a bullet list for readability>''
+
* This model is partially driven by the underlying assumption that there will be situations where documents are being exchanged between machines and stored on the recipient. This is partly driven by the need for healthcare systems to operate in disasters and overload situations, where the network operation is limited or destroyed. It is not safe to assume that clients are display only. So there will be semi-permanent copies of most information kept. Even in normal operation, healthcare providers may have only 15 minutes per patient. Good healthcare system design recognizes the need to not waste any of those seconds searching and transferring documents over a network. The documents are transferred in advance, and are kept locally until it is determined that they are no longer needed. There are thin client display only applications in healthcare, but they are limited to uses that can fail without introducing risks to safety or patient health, but a complete security/privacy design requires handling situations where data is stored after retrieval.
  
 
==Details==
 
==Details==
  
−
ATNA ''uses XYZ to carry audit messages formated as XML from the originating system to the audit repository etc etc.''
+
The '''Audit Trail and Node Authentication (ATNA) Integration Profile''':
 +
contributes to access control by limiting network access between nodes and limiting access to each node to authorized users. Network communications between secure nodes in a secure domain are restricted to only other secure nodes in that domain. Secure nodes limit access to authorized users as specified by the local authentication and access control policy.
 +
* User Authentication
 +
The Audit Trail and Node Authentication Integration Profile requires only local user authentication. The profile allows each secure node to use the access control technology of its choice to authenticate users. The use of Enterprise User Authentication is one such choice, but it is not necessary to use this profile.
 +
* Connection Authentication
 +
The Audit Trail and Node Authentication Integration Profile requires the use of bi-directional certificate-based node authentication for connections to and from each node. The DICOM, HL7, and HTML protocols all have certificate-based authentication mechanisms defined. These authenticate the nodes, rather than the user. Connections to these machines that are not bi-directionally node-authenticated shall either be prohibited, or be designed and verified to prevent access to PHI.
 +
* Audit Trails
 +
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 domain’s policies, to detect instances of non-compliant behavior, and to facilitate detection of improper creation, access, modification and deletion of Protected Health Information (PHI).
  
−
''Something about what Node authentication means and a couple details about what kind of certificates??''
 
  
−
Other Domains extend the ATNA Profile by defining specific audit events and details relevant to their specific domain.
+
==Systems Affected==
  
−
''(From an email by Rob Horn)''
+
Systems involved in this profile are:
  
−
We have done this only for profiles that were most critical (e.g. XDS, RFD, EUA, XUA). There is some interested in RID and PIX, we need help to create prioritized CP requests for clarity on profiles that the IHE community needs assistance with.
+
* Any local or enterprise-wide healthcare information systems that manage or process Protected Health Information
  
−
There is also some historical funny business.  Originally HL7 was going to
 
−
issue an HL7 side equivalent to DICOM's Supplement 95, but that lost
 
−
sponsorship and got abandoned.  So DICOM threw together some partial stuff
 
−
to cover the immediate needs of the imaging community.  It deals with only
 
−
those HL7ish things that happen to DICOM equipment (like receiving
 
−
orders).  DICOM didn't attempt to handle the rest of the HL7 world.  So
 
−
the various IHE domains get creative in a variety of ways.
 
−
 
−
==Systems Affected==
 
−
''<List (in user terms) systems that would be likely candidates for implementing this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. >''
 
  
 
'''Actors & Transactions:'''
 
'''Actors & Transactions:'''
  
−
''<Insert an actor-transaction diagram, and or list of Content Definitions>''
+
[[Image:ATNA-Actor-Transaction.jpg]]
  
 
==Specification==
 
==Specification==
  
 
'''Profile Status:''' [[Comments| Final Text]]   
 
'''Profile Status:''' [[Comments| Final Text]]   
−
''<Replace "Final Text" with "Trial Implementation" or "Public Comment" as appropriate.>''
 
  
 
'''Documents:'''  
 
'''Documents:'''  
−
 
−
''<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile.  This is a simple inventory of official normative and informative text.  If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below.  If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>''
 
−
 
 
[http://www.ihe.net/Technical_Framework/index.cfm#IT IHE IT Infrastructure Technical Framework:]
 
[http://www.ihe.net/Technical_Framework/index.cfm#IT IHE IT Infrastructure Technical Framework:]
−
:* [http://www.ihe.net/Technical_Framework/upload/???.pdf Vol. 1] - Section 9 (ATNA Profile)
+
:*[http://www.ihe.net/Technical_Framework/upload/ihe_ITI_TF_4_0_VOl1_FT_2007_08_22.pdf Vol. 1] - Section 9  
−
:* [http://www.ihe.net/Technical_Framework/upload/???.pdf Vol. 2] - Sections 3.16 and 3.17
+
:*[http://www.ihe.net/Technical_Framework/upload/ihe_ITI_TF_4.0_VOl2_FT_2007_08_22.pdf Vol. 2] - Sections 3.19, 3.2, 3.7
−
 
 
−
[http://www.ihe.net/Technical_Framework/index.cfm#radiology IHE Radiology Technical Framework:]
 
−
:* ''repeat listing of Rad sections here or just point to Rad Option?''
 
−
:* [ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf DICOM Supplement 95 - Frozen]
 
  
 
'''Underlying Standards:'''
 
'''Underlying Standards:'''
−
 
+
:* DICOM 2003 PS 3.15: Security Profiles. Annex B1: The Basic TLS Secure Transport Connection profile.
−
''<list all the standards on which the profile is based; if possible with links to sources>''
+
:* IETF: Transport Layer Security (TLS) 1.0 (RFC 2246)
−
:* [http://www.hl7.org HL7?]
+
:* ITU-T: Recommendation X.509 (03/00). “Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks"
−
:* Syslog?
+
:* IETF: The BSD Syslog Protocol. (RFC 3164); 3830 Reliable Delivery for Syslog (RFC 3195); Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC 3881).
−
:* XML?
+
:* DICOM: Supplement 95
−
:* ... The underlying RFC can be found at a variety of RFC repositories
+
:* ASTM: E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems.
 +
:* W3C: Recommendation: Extensible Markup Language (XML) 1.0
  
 
==See Also==
 
==See Also==
−
 
−
''<The following sections can be left out if there is nothing to point to.  This is just to show where such information can go.>''
 
−
 
  
 
'''Related Profiles'''
 
'''Related Profiles'''
−
 
−
''<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one.  Start with the name of the other profile as a link and then explain the relationship.>''
 
−
 
−
* [[Audit Trail and Node Authentication - Radiology Option]] defines Radiology-specific audit trail messages and security measures to ATNA.
 
−
* [[Cross-enterprise Document Sharing]] [XDS] depends on ATNA for ...
 
−
* ...
 
−
 
−
'''Consumer Information'''
 
−
 
−
The [[ATNA Profile FAQ Template]] answers typical questions about what the Profile does. 
 
−
 
−
The [[Profile Purchasing Template]] describes considerations when purchasing equipment to deploy this Profile.
 
−
 
−
'''Implementer Information'''
 
−
 
−
[[Audit Trail and Node Authentication Implementation]] provides additional information about implementing this Profile in software.  Specific questions about how to implement this profile can be found in the [[ATNA FAQ]].
 
−
 
−
White Paper [[IHE Security and Privacy for HIE]] puts ATNA in context.
 
−
 
−
'''Reference Articles'''
 
−
 
−
Creating an IHE ATNA-Based Audit Repository, Gregg, B. et al, Journal of Digital Imaging, Vol. 19, Number 4, 2006, pp. 307-315
 
−
 
−
 
  
 
This page is based on the [[Profile Template]]
 
This page is based on the [[Profile Template]]
−
 
  
 
[[Category:Profiles]]
 
[[Category:Profiles]]
 
[[Category:ITI Profile]]
 
[[Category:ITI Profile]]
 +
 +
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].

Revision as of 11:38, 2 April 2008


Summary

The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security measures which, together with the Security Policy and Procedures, provide patient information confidentiality, data integrity and user accountability.

Benefits

Assistance to sites in implementing security and confidentiality policies

  • This model is partially driven by the underlying assumption that there will be situations where documents are being exchanged between machines and stored on the recipient. This is partly driven by the need for healthcare systems to operate in disasters and overload situations, where the network operation is limited or destroyed. It is not safe to assume that clients are display only. So there will be semi-permanent copies of most information kept. Even in normal operation, healthcare providers may have only 15 minutes per patient. Good healthcare system design recognizes the need to not waste any of those seconds searching and transferring documents over a network. The documents are transferred in advance, and are kept locally until it is determined that they are no longer needed. There are thin client display only applications in healthcare, but they are limited to uses that can fail without introducing risks to safety or patient health, but a complete security/privacy design requires handling situations where data is stored after retrieval.

Details

The Audit Trail and Node Authentication (ATNA) Integration Profile: contributes to access control by limiting network access between nodes and limiting access to each node to authorized users. Network communications between secure nodes in a secure domain are restricted to only other secure nodes in that domain. Secure nodes limit access to authorized users as specified by the local authentication and access control policy.

  • User Authentication

The Audit Trail and Node Authentication Integration Profile requires only local user authentication. The profile allows each secure node to use the access control technology of its choice to authenticate users. The use of Enterprise User Authentication is one such choice, but it is not necessary to use this profile.

  • Connection Authentication

The Audit Trail and Node Authentication Integration Profile requires the use of bi-directional certificate-based node authentication for connections to and from each node. The DICOM, HL7, and HTML protocols all have certificate-based authentication mechanisms defined. These authenticate the nodes, rather than the user. Connections to these machines that are not bi-directionally node-authenticated shall either be prohibited, or be designed and verified to prevent access to PHI.

  • Audit Trails

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 domain’s policies, to detect instances of non-compliant behavior, and to facilitate detection of improper creation, access, modification and deletion of Protected Health Information (PHI).


Systems Affected

Systems involved in this profile are:

  • Any local or enterprise-wide healthcare information systems that manage or process Protected Health Information


Actors & Transactions:

ATNA-Actor-Transaction.jpg

Specification

Profile Status: Final Text

Documents: IHE IT Infrastructure Technical Framework:

Underlying Standards:

  • DICOM 2003 PS 3.15: Security Profiles. Annex B1: The Basic TLS Secure Transport Connection profile.
  • IETF: Transport Layer Security (TLS) 1.0 (RFC 2246)
  • ITU-T: Recommendation X.509 (03/00). “Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks"
  • IETF: The BSD Syslog Protocol. (RFC 3164); 3830 Reliable Delivery for Syslog (RFC 3195); Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC 3881).
  • DICOM: Supplement 95
  • ASTM: E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems.
  • W3C: Recommendation: Extensible Markup Language (XML) 1.0

See Also

Related Profiles

This page is based on the Profile Template

Current: IT Infrastructure Technical Framework.

Retrieved from "http://wiki.ihe.net/index.php?title=Audit_Trail_and_Node_Authentication&oldid=15552"