ITI Tech Audit Msg Specification New Approach

From IHE Wiki
Revision as of 08:14, 5 October 2017 by Felhofer (Talk | contribs) (Enhancements needed to the tools)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

IHE Tools for audit message documentation & validation

Opportunities

  • Explore the possibility of documenting the audit message requirements for each transaction once in the tool. The specification and the tool would reside together. The published IHE TF would reference into the tool for the audit msg portion of the specification for each transaction.
  • more...

Enhancements needed to the tools

  • We need to figure out versioning of the definitions
  • Lower priority items:
    • With the exception of some codes, the audit message documentation in GSS currently does not contain the contents of the "Value Constraints" column in the audit message tables in the TF. This needs to be considered/added.
    • Examine capabilities to Import and Export the definitions.
    • Ideally, add an example for each audit message. (It is currently possible to look through the database of verified audit messages for examples.)
    • more...

Administrative and governance issues to address

  • Figure out how the CP process (to fix TF documentation) and the Jira process (to fix the tools) work together
    • How would proposed changes to existing audit message, or new audit msg content, be review/approved prior to tool updates? (ELS: also balloted and commented on.)
    • Determine how implementers know that a message definition has been fixed in the tool
  • Confirm that there are no intellectual property issues associated w/ using the tools?
  • If/when the audit message definitions reside in the GSS, what happens if the tool goes offline?
  • How will the published TF reference the audit message definitions in the tool?
  • more...

Next steps and To Dos

What Who When Notes
Engage with Eric Poiseau's team to get feedback on this idea Lynn asap after Feb F2F; Feb-17 - initial outreach email sent Feb

Mar 3 - rec'd positive response; likely no forward movement until after EU Connectathon (ie May/June)

If Gazelle dev team is on board with this, create Jira issues and start the ball rolling on updates to the tools Lynn tbd