Difference between revisions of "ITI Tech Audit Msg Specification New Approach"

From IHE Wiki
Jump to: navigation, search
(The problem)
Line 8: Line 8:
  
 
* The current practice in the ITI TF is to specify audit message requirements in the Security Considerations section at the end of every transaction in Volume 2a, 2b, 2c.  The tables are based on the General Message Format in [http://dicom.nema.org/medical/dicom/current/output/pdf/part15.pdf DICOM PS3.15] Section A.5.2.
 
* The current practice in the ITI TF is to specify audit message requirements in the Security Considerations section at the end of every transaction in Volume 2a, 2b, 2c.  The tables are based on the General Message Format in [http://dicom.nema.org/medical/dicom/current/output/pdf/part15.pdf DICOM PS3.15] Section A.5.2.
 +
* For new transactions, ITI does not have documented guidance for profile authors on how to fill out each field in an audit message/
 
* The ITI TF does not have a template for the IHE conventions for specifying audit messages (use of fonts, etc)
 
* The ITI TF does not have a template for the IHE conventions for specifying audit messages (use of fonts, etc)
* For a new transaction, a common practice is for the author to copy an audit message specification for an existing transaction and then make edits.  Editors have varying expertise in this area, and the original table may have had errors.  This results in many errors that cascade into many, many CPs to fix audit message specifications.
+
* Thus, for a new transaction, a common practice is for the author to copy an audit message specification for an existing transaction and then make edits.  Authors have varying expertise in this area, and the original table may have had errors.  This results in many errors that cascade into many, many CPs to fix audit message specifications.
 
* Errors in the TF are then encoded into the Gazelle Security Suite and Gazelle EVS Client test tools that do audit message checks based on the TF requirements.
 
* Errors in the TF are then encoded into the Gazelle Security Suite and Gazelle EVS Client test tools that do audit message checks based on the TF requirements.
  

Revision as of 17:39, 13 February 2017

ITI Technical Committee - Exploring a new approach to Audit Message Specification in the TF

During the Feb 2017 F2F Meeting in Naples, Italy, the ITI Technical Committee began exploring alternatives to specifying audit message requirements. This wiki page is a working document in order to make progress toward an improved specification

This page is not owned/maintained by one person. Feel free to make edits and share your ideas.

The problem

  • The current practice in the ITI TF is to specify audit message requirements in the Security Considerations section at the end of every transaction in Volume 2a, 2b, 2c. The tables are based on the General Message Format in DICOM PS3.15 Section A.5.2.
  • For new transactions, ITI does not have documented guidance for profile authors on how to fill out each field in an audit message/
  • The ITI TF does not have a template for the IHE conventions for specifying audit messages (use of fonts, etc)
  • Thus, for a new transaction, a common practice is for the author to copy an audit message specification for an existing transaction and then make edits. Authors have varying expertise in this area, and the original table may have had errors. This results in many errors that cascade into many, many CPs to fix audit message specifications.
  • Errors in the TF are then encoded into the Gazelle Security Suite and Gazelle EVS Client test tools that do audit message checks based on the TF requirements.

Opportunities

IHE Tools for audit message documentation & validation