180 likes | 192 Views
Explore the structure of DICOM audit messages, real-world events, and IETF Common Audit Messages. Understand event descriptions, active participant roles, participant objects, and more.
E N D
Functional Structure • Three components: • Event Description (DICOM) • Audit Policy (Local) • Message Definition (DICOM) Real World Event Policy Audit Message(s)
Supplement Structure • Alternative A • List and describe all the real world events, then • List and describe the associated audit messages • Alternative B • List all events with a section for each • Real world event, and its • Associated audit messages • IHE tried both methods and found alternative B slightly superior, but it does have problems.
Sample Real World Event • A DICOM source sends a collection of instances to a DICOM destination. • All of the instances are members of the same study for the same patient.
IETF Common Audit Message • Major Sections • Event Description • Active Participants • Network Access Point • Audit Source ID • Participant Objects
Event Description • Event ID (M/M) • (M/M) means IETF mandatory, DICOM mandatory • Need to establish a DICOM DCID for terminology • IETF CAM uses HL7 OID references for coded terminology. Register this DCID. • Event ID = 99supxx,instances-transferred
Event Description • Event Action Code (U/M) • R (read/view/print/query) • Other candidate could be C (create) • What are the rules for picking R versus C?
Event Description • Outcome Indicator (M/M) • DICOM rule that if a transfer is partially successful, then there will be two audit messages. One will describe the successfully transferred objects. The other will describe the failed objects.
Active Participants • IETF specifies that there shall be at least one active participant. • For this event, DICOM specifies that there shall be at least three active participants. • One shall be a node and have the role of “source” • One shall be a node and have the role of “destination” • One shall be a person or automatic process and may have the role “source” or “destination” depending on its location. • There may be other active participants.
Active Participant • User ID (M/M) • Nodes shall be identified by means of node name and AE-Title. (How to do both? Need a naming nomenclature specification in the supplement. AE-title@DNS-name?) • Persons shall be identified by means of: • Local username, user@domain-name • Enterprise User Identification (e.g. Kerberos principal)
Active Participant • Role ID Code M/M • All Active Participants in this event shall be identified as either “source” or “destination” • Role ID is multivalued. DICOM does not restrict other role IDs that may be present, nor does it define other role IDs.
Active Participant • User Is Requestor (U/M) • Every active participant shall state whether it is the requestor. • IETF issue. The default is “true”. There is no way to indicate “unknown” because this is a boolean field.
Network Access Point • Use IP address. • Issue: How do we describe the multi-homed host? E.g. Modality to multi-homed archive. How do I describe that IP-x was the modality, and IP-y, IP-z was the archive.
Audit Source ID • These are enterprise specific ID fields except for audit source type code. • For audit source type code, define coded value that means: • DICOM Audit Message • Issue with how and where to encode the actual schema used, assuming that the syslog negotiation specifies the IETF CAM schema.
Participant Object Code • Type Code (U/M) • Shall be 2, (System Object) • Type Code Role (U/M) • Decision needed. Either: • Shall be 3 (report) or • Shall be XX (DICOM Instances) and need to extend IETF CAM, e.g. with coded value. • Or leave this out?
Participant Object • Life Cycle (U/M) • Shall be either • 1 (for new object origination/creation, e.g. modality) • 10 (Export/copy to target, e.g. archive to workstation) • Missing a good code for moving object from location A to B.
Participant Object • ID Type Code (M/M) • Define a new code XX – DICOM Study Instance UID • Object ID (M/M) • Study Instance UID
Participant Object • Object Detail - IETF CAM area for extensions • Multivalued list of • “ContainsSOPClass=sop-class-uid” • List shall contain the list of all SOP Classes found in this collection of instances. • Number of instances (optional) • “NumberOfInstances=xxx”