ATNA Audit Format Problems

From IHE Wiki
Jump to navigation Jump to search

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 Both the RFC-3881 and DICOM schemas show the ParticipantObjectIdentification element as having a required attribute, ParticipantObjectID. However, many IHE Transactions which specificy audit messages utilize the ParticipantObjectIdentification element without specifying a value for ParticipantObjectID, and in contexts where no useful value is available to populate the field, for example, in this query element taken from a PIX Consumer Audit message (ITI TF V2a 3.9.5.5.1) 
<ParticipantObjectIdentification 
	ParticipantObjectTypeCode="2" ParticipantObjectTypeCodeRole="24">
	<ParticipantObjectIDTypeCode csd-code="ITI-9" originalText="PIX Query" 
           codeSystemName="IHE Transactions"/>
	<ParticipantObjectQuery>VXRpbC5qYXhiTWFyc2hhbFRvU3RyaW5nKGJvZHkp
	</ParticipantObjectQuery>
	<ParticipantObjectDetail type="2220c1c4-87ef-11dc-b865-3603d6866807" 
           value="TWpJeU1HTXhZelF0T0RkbFppMHhNV1JqTFdJNE5qVXRNell3TTJRMk9EWTJPREEzDQo="/>
</ParticipantObjectIdentification>

Moreover, historically, ATNA syslog implementations have not included this attribute in cases where the transaction audit record specifications did not require it.

RFC-3881 6.1. DICOM PS 3.15, 2011 A.5.1. A CP to DICOM changing ParticipantObjectID to optional. It may be required by specific message requirements.
Email Ralph Moulton moultonr@mir.wustl.edu The RFC-3881 schema defines the UserIsRequestor attribute of the ActiveParticipant element as: 
<xs:attribute name="UserIsRequestor" type="xs:boolean" use="optional" default="true"/>

although many IHE Audit record specifications show it as mandatory, although often not specialized. The DICOM RNC schema defines it as: 

attribute UserIsRequestor {xsd:boolean},

that is, as required and having no default value. Developers have complained that they are not always in a position to know a correct value for the UserIsRequestor attribute.

RFC-3881 6.1. DICOM PS 3.15, 2011 A.5.1. A CP to DICOM changing the UserIsRequestor attribute to optional. It may be required by specific message requirements.
Email Ralph Moulton moultonr@mir.wustl.edu The PurposeOfUse element is not present in the DICOM schema. ITI TF-2a 3.20.7.8. ITI Supplement XUA++ Revision 1.3 section 3.20.7.8 CP to DICOM schema adding: 
  <xs:element name="PurposeOfUse" minOccurs="0" maxOccurs="unbounded">
     <xs:complexType>
	<xs:attributeGroup ref="CodedValueType" />
     </xs:complexType>
  </xs:element>

to the EventIdentification element definition.

Email Ralph Moulton moultonr@mir.wustl.edu Do ATNA syslog message xml parts have to validate to the DICOM schema or not? Would like specific guidance on this issue. Recommend: Yes. This would provide Senders with an automated method to help validate their messages, and would permit Collectors to rely on the message contents meeting a standard.
Email Ralph Moulton moultonr@mir.wustl.edu Documentation says that users may extend the schema, but does not say how. Need specific guidance.
xxx
xxx
xxx
Retrieved from "http://wiki.ihe.net/index.php?title=ATNA_Audit_Format_Problems&oldid=75599"