Difference between revisions of "Audit Trail and Node Authentication - Radiology Option"
| Line 49: | Line 49: | ||
:*Allowing, for each node, the use of the user’s authentication and access control policy of its choice. | :*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. | 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. | ||
| Line 70: | Line 71: | ||
More details concerning the ATNA profile can be seen on the: [[Audit Trail and Node Authentication]] | More details concerning the ATNA profile can be seen on the: [[Audit Trail and Node Authentication]] | ||
| − | |||
==Systems Affected== | ==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). | 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). | ||
Revision as of 06:49, 31 March 2008
{{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.
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 seen on the: Audit Trail and Node Authentication
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 <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.>
IHE Radiology Technical Framework:
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.>
- 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 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.>