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

From IHE Wiki
Jump to navigation Jump to search
Line 1: Line 1:
The ATNA Radiology profile specifies basic security measures that can help protect the confidentiality of patient information as part of an institution's overall security policies and procedures. 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.
 
  
 +
<pre>
 +
{{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 specifies basic security measures for protecting patient confidentiality and assuring traceability in the imaging environment.
 +
 +
}}}
 
__TOC__
 
__TOC__
  
 
==Summary==
 
==Summary==
{{{2|The Radiology Audit Trail Option defines the specific requirements of the IHE
+
{{{2|''<Describe the profile in about a paragraph using user-oriented language. Focus on what it accomplishes for a user (i.e. the Use Cases).  Don't get into how it works, leave that to the Details section.>''}}}
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.
 
}}}
 
  
 +
''<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.>''
  
[[Image:Figure 12 SEC.jpg]]
 
 
==Benefits==
 
==Benefits==
  
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.
+
''<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>''
 
 
Some of the benefits are:
 
 
 
:*Authentication/Access control: network access are limited between nodes (access restriction to secure nodes only) and  between each nodes to authorized users (depending on local authentication and access control policy)
 
 
 
:*Audit trail: allows detection of non-compliant behaviour instances, or improper creation, access, modification and deletion of Protected Health Information (PHI)
 
 
 
:*Centralized audit record repository, making easier the implementation of security requirements
 
 
 
  
 
==Details==
 
==Details==
  
Node authentication gives a means to control network access by :
+
''<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>''
  
:*Using, from and to each node, a mandatory bi-directional certificate-based node authentication,
+
''<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.>''
 
 
:*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 concering the ATNA profile can be seen on the: [[Audit Trail and Node Authentication]]
 
  
 +
''<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==
 
==Systems Affected==
All systems which participate in Radiology Framework transactions with corresponding audit events are affected. See Table 5.12 IHE Radiology transactions and resulting ATNA trigger events in volume 3 of the IHE Radiology technical framework.
+
''<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.>''
  
 +
* ''PACS systems may store, manage, and/or display Evidence Documents.''
 +
* ''Display systems may query, retrieve and display Evidence Documents.''
 +
* ''Reporting workstations may retrieve, process and include details from Evidence Documents in reports
  
 
'''Actors & Transactions:'''
 
'''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.
 
  
[[Image:Diagram3.JPG]]
+
''<Insert an actor-transaction diagram, and or list of Content Definitions>''
  
 
==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:'''  
  
ITI Technical Framework, Volume 1 - Section 9 documents the ATNA profile
+
''<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 textIf 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/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf
 
   
 
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.
 
:*http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4.0_Vol2_FT_2007-08-22.pdf
 
  
Radiology Technical Framework, Volume 1 - Appendix H (informative) gives consideration on the security environment within the XDS-I profile
+
[http://www.ihe.net/Technical_Framework/index.cfm#radiology IHE Radiology Technical Framework:]
:*http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf
+
:* [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_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_tf_rev8-3.pdf Vol. 3] - Appendix E
  
Radiology Technical Framework] - Section 5 documents the Audit trail radiology option.
+
'''Underlying Standards:'''
:*http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf
 
  
'''Underlying Standards:'''
+
''<list all the standards on which the profile is based; if possible with links to sources>''
 +
:* [http://dicom.nema.org DICOM]
 +
:* [http://www.hl7.org HL7]
 +
:* ...
  
:* http://www.ietf.org/rfc/rfc4346.txt - TLS
+
==See Also==
:* http://www.ietf.org/rfc/rfc3881.txt - Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications
 
:* ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf - DICOM Supplement 95: Audit Trail Messages
 
  
 +
''<The following sections can be left out if there is nothing to point to.  This is just to show where such information can go.>''
  
==See Also==
 
  
 
'''Related Profiles'''
 
'''Related Profiles'''
  
* [[Audit Trail and Node Authentication]] (ATNA) is the profile this option augments.
+
''<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'''
 
'''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.  
+
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'''
 
'''Implementer Information'''
  
*[[Audit Trail and Node Authentication Implementation]] provides additional information about implementing this Profile in software.
+
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>''
  
 
'''Reference Articles'''
 
'''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 - http://www.springerlink.com/content/a587222402764162/
+
''<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]]
 +
 
 +
[[Category:Profiles]]
 +
 
 +
 
 +
<noinclude>''<'''Delete this Category Templates line''' since your Profile page is no longer a template.>'' </noinclude>
 +
[[Category:{{{4|Templates}}}]]

Revision as of 04:51, 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 specifies basic security measures for protecting patient confidentiality and assuring traceability in the imaging environment.

}}}

Summary

<Describe the profile in about a paragraph using user-oriented language. Focus on what it accomplishes for a user (i.e. the Use Cases). Don't get into how it works, leave that to the Details section.>

<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 - Tips and Tricks for details on inserting an image/graphic.>

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>

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

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

  • PACS systems may store, manage, and/or display Evidence Documents.
  • Display systems may query, retrieve and display Evidence Documents.
  • Reporting workstations may retrieve, process and include details from Evidence Documents in reports

Actors & Transactions:

<Insert an actor-transaction diagram, and or list of Content Definitions>

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:

  • 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

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