ATNA Audit Format Problems

When the ITI Technical Committee reviewed the Ballot 20 results on Feb 20, one of the approved-for-final-text CPs is CP-ITI-731.

This CP updates the requirement for ATNA audit message format to that specified in DICOM 2011 Final Text. (CP-ITI-622, in 2013 Ballot 18 and integrated into ITI TF version 10, had previously replaced the "Supplement 95" references with "DICOM 2011" references, implicitly changing the schema, but CP-ITI-731 is more explicit.) CP-ITI-731 acknowledges that DICOM Supplement 95 extended the schema defined in RFC-3881, and that DICOM Final Text 2011 defined a different, but similar, schema.

CP-ITI-731 also documents several differences between RFC-3881 and the DICOM schemas, but acknowledges that the list of differences is not all-inclusive.

Please read the details in the CPs themselves.

For 2014 connectathons, support for either schema is accepted. The Syslog Collector tool has attempted to accommodate differences in the schema, and we expect to see a mix of support among the Secure Node/Applications & Audit Record Repositories.

For 2015 connectathons, we hope to move implementers toward support for the DICOM FT schema.

In various email chains & connectathon-related conversations, implementers have referred to problems with the DICOM schema, or problems with the audit specification in the ITI Tech Framework resulting from this change. The ITI Technical Committee would like to address this and is asking the developer community to document specific problems so that the ITI Tech Cmte can address these via Change Proposal before the next version of the Technical Framework is published in the fall.

We are using this wiki page to gather input. Please provide feedback by April 4.

Please contribute by adding a row to this table to document a problem you have found. If you don't have a login on this wiki, you can request one.

Name / email	Problem Desc	Reference (ie in TF, DICOM)	Proposed solution
Massimiliano Masi massimiliano.masi@tiani-spirit.com	Possible interoperability problem with XSPA and the new DICOM audit schema. Details in this post: https://groups.google.com/forum/#!topic/ititech/4eMj_wV4jlM
Email Ralph Moulton moultonr@mir.wustl.edu	CP states that, in the RFC-3881 schema, displayName is a required attribute of CodedValueType. It is actually optional, although many ATNA message specifications require it.	CP-ITI-731-01, new section 3.20.7.1.1, first bullet. RFC-3881 6.1	Since we are moving away from the RFC-3881 schema, perhaps we can just ignore this, although it has some potential to be confusing and, ATNA message specifications could not require it. (I don't know of any.)
Email Ralph Moulton moultonr@mir.wustl.edu	The RFC-3881 schema for a CodedValueType contains an attribute group “CodeSystem”, containing the optional attributes “codeSystem” (an OID) and “codeSystemName” (a string). Both may be present, both are optional. The DICOM schema contains only the attribute “codeSystemName” (a token), which is required. It states in a comment that the value can be an OID or a string, but no such requirement actually exists in the schema. Thus, in the RFC-3881 schema you can have neither, either, or both, while in DICOM you must have either one or the other.	RFC-3881 6.1. DICOM PS 3.15, 2011 A.5.1.	ATNA has generally been using strings to specify code sets, but might desire OID's in the future. I would also seem reasonable to permit users to have both.
Email Ralph Moulton moultonr@mir.wustl.edu	The AuditSourceTypeCode has not been removed in the DICOM schema, as stated in the CP. It has been changed from a coded value type to a token type.	RFC-3881 6.1, DICOM PS 3.15, 2011 A.5.1.CP-ITI-731-01, new section 3.20.7.1.1, second bullet.	A CP to the CP?
Email Ralph Moulton moultonr@mir.wustl.edu	In the RFC-3881 schema the AuditSourceTypeCode element could appear any number of times. The new “code” attribute is required, 1 time.	RFC-3881 6.1, DICOM PS 3.15, 2011 A.5.1.CP-ITI-731-01, new section 3.20.7.1.1, second bullet.	Are there cases where more than one AuditSourceCode might be appropriate?
Email Ralph Moulton moultonr@mir.wustl.edu	The hard-coded values (1-9) for the AuditSource “code” attribute in the DICOM schema did not exist in the RFC-3881 schema, which required the entry to be a coded value type.	RFC-3881 6.1, DICOM PS 3.15, 2011 A.5.1.CP-ITI-731-01, new section 3.20.7.1.1, second bullet.	Some guidance should be provided to developers on this issue. If we are going to require ATNA messages to validate against the schema, we should understand that this combination of hard-coded and coded value types can not be represented in RNC or XSD.
Email Ralph Moulton moultonr@mir.wustl.edu	The DICOM schema defines a new group, DICOMObjectDescriptionContents, which is required in the ParticipantObjectIdentification element. Along with a comment that states it is, “ for use in describing DICOM objects”.	RFC-3881 6.1. DICOM PS 3.15, 2011 A.5.1.	At minimum, a CP to DICOM changing the schema so that the ParticipantObjectName and ParticipantObjectQuery choice is optional or has a cardinality which includes 0. Perhaps also allowing a maximum cardinality greater than 1?
Email Ralph Moulton moultonr@mir.wustl.edu	The RFC-3881 schema defines the ParticipantObjectName and ParticipantObjectQuery as: <xs:choice minOccurs="0"> <xs:element name="ParticipantObjectName" type="xs:string" minOccurs="0"/> <xs:element name="ParticipantObjectQuery" type="xs:base64Binary" minOccurs="0"/> </xs:choice> while the DICOM schema defines them as: (element ParticipantObjectName {token} | # either a name or element ParticipantObjectQuery {xsd:base64Binary}), # a query ID field, which means that for DICOM schema compatibility, at least one of the elements must appear in every ParticipantObjectIdentification element. However, it does not appear that DICOM actually follows this requirement. In many of their Audit specifications, ParticipantObjectIdentification elements appear in which neither element is specified.	RFC-3881 6.1. DICOM PS 3.15, 2011 A.5.1.	At minimum, a CP to DICOM changing the schema so that the ParticipantObjectName and ParticipantObjectQuery choice is optional or has a cardinality which includes 0. Perhaps also allowing a maximum cardinality greater than 1?
Email Ralph Moulton moultonr@mir.wustl.edu
Email Ralph Moulton moultonr@mir.wustl.edu
Email Ralph Moulton moultonr@mir.wustl.edu
Email Ralph Moulton moultonr@mir.wustl.edu