Difference between revisions of "Audit Trail and Node Authentication - Radiology Option"

Revision as of 15:20, 25 May 2018

The Radiology Option for Audit Trail and Node Authentication (ATNA) specifies basic security measures for protecting patient confidentiality and assuring traceability in the imaging environment.

Summary

The IT infrastructure domain (ITI) has already established ATNA as a profile for the information exchange (see ITI Technical Framework, Volume 1 - Section 9 documents the ATNA profile :http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf). This is the Radiology option.

ATNA provides institutions with a mechanism to consolidate audit trail events on user activity across several imaging and information systems throughout the enterprise systems interconnected in a secure manner. The Radiology option defines further requirements for the ATNA profile, which are specific for this domain.

The Radiology Audit Trail Option defines the specific requirements of the IHE Radiology transactions for supporting the IHE ITI Audit Trail and Node Authentication profile. This option deals largely with the details of the Record Audit Event transaction in the IHE ITI Technical Framework. The option details the required audit events for each of the IHE Radiology transactions, based on the different trigger events.

Benefits

Having an ATNA implementation allows healthcare professionals and patients have a greater confidence in the system and prevents improper access or tampering with the medical information.

For example:

User identification: the users will have to be identified in order to gain access to the system.

Authentication/Access control: network access is limited between information systems (the access is restricted to secure systems only) and between each sytem to authorized users (depending on local authentication and access control policy).

Audit trail: allows detection of abnormal behavior, such as improper creation, access, modification and deletion of Protected Health Information (PHI).

The audit records are centralized, allowing an easier implementation of security requirements.

Details

Securing the exchange of patient healthcare information, and logging key events during the processing of healthcare data increases the reliability of the underlying information systems and provides accountability for users of these systems. This is achieved by combining the ATNA requirements with the relevant IHE profiles, using industry standards like TLS and Syslog.

Node authentication gives a means to control network access by:

Using, from and to each node, a mandatory bi-directional certificate-based node authentication,

Allowing, for each node, the use of the user’s authentication and access control policy of its choice.

Audit Trails are based on the production of audit records, that provide a record of actions such as queries, views, additions, deletions and changes that are processed within the Security Domain covered by ATNA.

Records are triggered by trigger events described in this profile.

Some of the trigger events described in ATNA are not relevant in the ATNA Radiology option. These trigger events are:

Health-service-event

Medication

Patient-care-assignment

Patient-care-episode

Patient-care-protocol

More details concerning the ATNA profile can be found on the: Audit Trail and Node Authentication. For an in-depth explanation the reader is directed to the ITI technical framework (ITI Technical Framework, Volume 1 - Section 9 documents the ATNA profile

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf).

Systems Affected

All systems which participate in Radiology Framework transactions with corresponding audit events are affected. See Table 5.1-2, page 161-163 listed in volume 3 of the IHE Radiology technical framework(http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf).

Some examples are: ADT systems, HIS, RIS, PACS, imaging modalities

ADT systems - recording patient demographics and events
Modalities - storing instances (exams and their associated information)
Image manager/Image archive - handling images
Reporting workstations - retrieving, processing and including details from exams in reports.

Actors & Transactions:

ATNA is security domain that involves all kind of Information Systems that could be used within a department up to a XDS-I Affinity Domain.

Specification

Profile Status: Final Text

Documents:

ITI Technical Framework:

Vol. 1 - Section 9 (ATNA profile)
Vol. 1 - Section 10 (Cross-Enterprise Document Sharing profile - XDS)
Vol. 2a - Section 3.20 (Record Audit Event)

IHE Radiology Technical Framework:

Vol. 1 - Appendix H (Security considerations for XDS-I (informative)
Vol. 1 - Section 7 (Access to Radiology Information (ARI)
Vol. 1 - Section 18 (Cross-enterprise Document Sharing for Imaging (XDS-I)
Vol. 3 - Section 5 (Transaction Options on other Domain Profiles)

Underlying Standards:

http://www.ietf.org/rfc/rfc4346.txt - TLS
http://www.ietf.org/rfc/rfc3881.txt - Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications
http://medical.nema.org/Dicom/2011/11_15pu.pdf - DICOM PS 3.15: Audit Trail Message Format Profile

@@ Line 1: / Line 1: @@
-<pre>
+The Radiology Option for '''Audit Trail and Node Authentication (ATNA)''' specifies basic security measures for protecting patient confidentiality and assuring traceability in the imaging environment.
-{{subst::Profile Template|
- One line description |
- One Paragraph Description |
- Your Profile Name |
- Domain Committee }}
-</pre>
-The Audit Trail and Node Authentication (ATNA) profile for Radiology option specifies basic security measures for protecting patient confidentiality and assuring traceability in the imaging environment.
 __TOC__
 ==Summary==
-{{{2|The IT infrastructure domain (ITI) has already established ATNA as a profile for the information exchange (see ITI Technical Framework, Volume 1 - Section 9 documents the ATNA profile :*http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf).  This is the Radiology option.
+{{{2|The IT infrastructure domain (ITI) has already established ATNA as a profile for the information exchange (see ITI Technical Framework, Volume 1 - Section 9 documents the ATNA profile :http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf).  This is the Radiology option.
@@ Line 28: / Line 19: @@
 ==Benefits==
-''<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>''
+Having an ATNA implementation allows healthcare professionals and patients have a greater confidence in the system and prevents improper access or tampering with the medical information.
+For example:
+:* User identification:  the users will have to be identified in order to gain access to the system.
+:*Authentication/Access control: network access is limited between information systems (the access is restricted to secure systems only) and  between each sytem to authorized users (depending on local authentication and access control policy).
+:*Audit trail: allows detection of abnormal behavior, such as improper creation, access, modification and deletion of Protected Health Information (PHI).
+:*The audit records are centralized, allowing an easier implementation of security requirements.
 ==Details==
-''<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>''
+Securing the exchange of patient healthcare information, and logging key events during the processing of healthcare data increases the reliability of the underlying information systems and provides accountability for users of these systems. This is achieved by combining the ATNA requirements with the relevant IHE profiles, using industry standards like TLS and Syslog.
+Node authentication gives a means to control network access by:
+:*Using, from and to each node, a mandatory bi-directional certificate-based node authentication,
+:*Allowing, for each node, the use of the user’s authentication and access control policy of its choice.
+Audit Trails are based on the production of audit records, that provide a record of actions such as queries, views, additions, deletions and changes that are processed within the Security Domain covered by ATNA.
+Records are triggered by trigger events described in this profile.
+Some of the trigger events described in ATNA are not relevant in the ATNA Radiology option. These trigger events are:
+:*Health-service-event
+:*Medication
+:*Patient-care-assignment
+:*Patient-care-episode
+:*Patient-care-protocol
+More details concerning the ATNA profile can be found on the: [[Audit Trail and Node Authentication]].  For an in-depth explanation the reader is directed to the ITI technical framework (ITI Technical Framework, Volume 1 - Section 9 documents the ATNA profile
+:*http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf).
-''<If the user might be familiar with the mechanisms used by the profile, you can mention them here.  E.g. Evidence Documents is based on DICOM Structured Report (SR) Templates.>''
-''<If the user might have an appreciation for the problems addressed in the profile, you can mention them here, but keep it short.  E.g. Mapping HL7 Order fields to DICOM Modality Worklist attributes can be inconsistent in the marketplace, so Scheduled Workflow provides vendors with more detailed instructions.>''
 ==Systems Affected==
-''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>''
+All systems which participate in Radiology Framework transactions with corresponding audit events are affected. See Table 5.1-2, page 161-163 listed in volume 3 of the IHE Radiology technical framework(http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf).
-* ''PACS systems may store, manage, and/or display Evidence Documents.''
+Some examples are:  ADT systems, HIS, RIS, PACS, imaging modalities
-* ''Display systems may query, retrieve and display Evidence Documents.''
+* ADT systems - recording patient demographics and events
-* ''Reporting workstations may retrieve, process and include details from Evidence Documents in reports
+* Modalities - storing instances (exams and their associated information)
+* Image manager/Image archive - handling images
+* Reporting workstations - retrieving, processing and including details from exams in reports.
 '''Actors & Transactions:'''
-''<Insert an actor-transaction diagram, and or list of Content Definitions>''
+ATNA is security domain that involves all kind of Information Systems that could be used within a department up to a XDS-I Affinity Domain.
+[[Image:Diagramradio1.JPG]]
 ==Specification==
 '''Profile Status:''' [[Comments| Final Text]]
-''<Replace "Final Text" with "Trial Implementation" or "Public Comment" as appropriate.>''
 '''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 ITI Technical Framework:]
+:* [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol1.pdf Vol. 1] - Section 9 (ATNA profile)
+:* [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol1.pdf Vol. 1] - Section 10 (Cross-Enterprise Document Sharing profile - XDS)
+:* [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol2a-2.pdf Vol. 2a] - Section 3.20 (Record Audit Event)
 [http://www.ihe.net/Technical_Framework/index.cfm#radiology IHE Radiology Technical Framework:]
-:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf Vol. 1] - Section 5 (SWF Profile)
+:* [http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol1.pdf Vol. 1] - Appendix H (Security considerations for XDS-I (informative)
-:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-2.pdf Vol. 2] - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23
+:* [http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol1.pdf Vol. 1] - Section 7 (Access to Radiology Information (ARI)
-:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf Vol. 3] - Appendix E
+:* [http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol1.pdf Vol. 1] - Section 18 (Cross-enterprise Document Sharing for Imaging (XDS-I)
+:* [http://www.ihe.net/Technical_Framework/upload/IHE_RAD_TF_Vol3.pdf Vol. 3] - Section 5 (Transaction Options on other Domain Profiles)
 '''Underlying Standards:'''
-''<list all the standards on which the profile is based; if possible with links to sources>''
+:* http://www.ietf.org/rfc/rfc4346.txt - TLS
-:* [http://dicom.nema.org DICOM]
+:* http://www.ietf.org/rfc/rfc3881.txt - Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications
-:* [http://www.hl7.org HL7]
+:* http://medical.nema.org/Dicom/2011/11_15pu.pdf - DICOM PS 3.15: Audit Trail Message Format Profile
-:* ...
 ==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'''
+* Most part of the radiology integration profiles are affected by the ATNA profile, since it pertains to privacy and security of the personal healthcare information.
-''<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.>''
-* ''[[Reporting Workflow]] [RWF] may use Evidence Documents as inputs to the reporting process.''
-* ''[[Simple Image & Numeric Reports]] [SINR] may include data copied from Evidence Documents.''
-* ''[[Cross-enterprise Document Sharing for Imaging]] [XDS-I] can be used to share Evidence Documents between sites over a network.''
-* ''[[Portable Data for Imaging]] [PDI] can store Evidence Documents on media such as CDs.''
-* ''[[Import Reconciliation Workflow]] [IRWF] can fix patient ids, etc. of Evidence Documents when importing.''
 '''Consumer Information'''
+* The [[ATNA Profile FAQ]] answers typical questions about what the profile does.
-The [[{{{3|Profile FAQ Template}}}]] answers typical questions about what the Profile does.  ''<Replace the link with a link to the actual FAQ page for the Profile>''
+*[[Audit Trail and Node Authentication Purchasing]] describes considerations when purchasing equipment to deploy this Profile. For the moment there is no page describing the Trail and Node Authentication Purchasing.
-The [[{{{3|Profile Purchasing Template}}}]] describes considerations when purchasing equipment to deploy this Profile.  ''<Replace the link with a link to the actual Purchasing page for the Profile>''
 '''Implementer Information'''
-The [[{{{3|Profile Implementation Template}}}]] provides additional information about implementing this Profile in software.  ''<Replace the link with a link to the actual Implementation page for the Profile>''
+*[[Audit Trail and Node Authentication Implementation]] provides additional information about implementing this Profile in software.]
 '''Reference Articles'''
-''<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis).  Go ahead, Google: IHE <Profile Name> abstract   or something.  You might be surprised. >''
+*Creating an IHE ATNA-Based Audit Repository, Gregg, B. et al, Journal of Digital Imaging, Vol. 19, Number 4, 2006, pp. 307-315 - http://www.springerlink.com/content/a587222402764162/
-This page is based on the [[Profile Template]]
 [[Category:Profiles]]
+[[Category:RAD Profile]]
+[[Category:Security]]
-<noinclude>''<'''Delete this Category Templates line''' since your Profile page is no longer a template.>'' </noinclude>
-[[Category:{{{4|Templates}}}]]

Difference between revisions of "Audit Trail and Node Authentication - Radiology Option"

Revision as of 15:20, 25 May 2018

Contents

Summary

Benefits

Details

Systems Affected

Specification

See Also

Navigation menu

Search