Audit Trail and Node Authentication - Radiology Option

From IHE Wiki
Jump to navigation Jump to search
{{subst::Profile Template| 
 One line description | 
 One Paragraph Description | 
 Your Profile Name | 
 Domain Committee }}


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.

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.


Figure 12 SEC.jpg


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


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.

Diagramradio1.JPG

Specification

Profile Status: Final Text

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.>

ITI Technical Framework:

  • Vol. 1 - Section 9 (ATNA profile)
  • Vol. 2 - Section 3.20 (document record audit transactions)

IHE Radiology Technical Framework:

  • Vol. 1 - Section 5 (SWF Profile)
  • Vol. 2 - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23
  • Vol. 3 - Appendix E

ITI Technical Framework, Volume 1 - Section 9 documents the ATNA profile

ITI Technical Framework, Volume 2 - Section 3.20 documents Record Audit Event transaction and with special attention on the trigger events, on which the radiology option is largely based.

Radiology Technical Framework, Volume 1 - Appendix H (informative) gives consideration on the security environment within the XDS-I profile

Radiology Technical Framework] - Section 5 documents the Audit trail radiology option.


Underlying Standards:

<list all the standards on which the profile is based; if possible with links to sources>

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

<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.>


Consumer Information

The 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>

The 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 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>

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. >


This page is based on the Profile Template


<Delete this Category Templates line since your Profile page is no longer a template.>