Here are the use-cases
- In a service oriented transaction there is a 'transaction identifier' that is specific to that transaction. When all audit events are recorded with their transaction identifier, then one can see all the audit events caused by one transaction. This transaction identifier might be in SOAP header, or might be in an HTTP header, or might be elsewhere. For the purpose of this article it doesn't matter were it comes from, but rather that many different audit logging events can record the transaction identifier so that later the many different audit log entries can be correlated.
- In a layered software environment there are various software 'applications' (aka services) that might be involved in an 'event'. It would be good to record all of these applications so that an analysis of the audit log can show the involvement. For example: During the audit logging, it is possible to walk the call-stack to see all the layers involved.
IHE defined Audit Message is minimally transaction focused
- Event Description: Defining this kind of an event
- ActiveParticipant: the Initiating Gateway would be described by IP address, possibly the ReplyTo value if async web services are being used.
- ActiveParticipant: the Responding Gateway by IP Address, and SOAP endpoint URI. The Process ID can be recorded to tie to local system logs.
- AuditSource: identity of the system recording the audit event
- ParticipantObject: The patient identity(ies) if known
- ParticipantObject: The query parameters