Existing Wording: 6.6.2 Audit Events are created as events occur, to track and audit the events. Audit Event resources are often (though not exclusively) created by the application responding to the create/read/query/update/delete/execute etc. event. A Provenance resource contains overlapping information, but is a record-keeping assertion that gathers information about the context in which the information in a resource was obtained. Provenance resources are prepared by the application that initiates the create/update etc. of the resource.

6.5.1 Provenance resources are a record-keeping assertion that gathers information about the context in which the information in a resource was obtained. Provenance resources are prepared by the application that initiates the create/update etc. of the resource. An Audit Event resource contains overlapping information, but is created as events occur, to track and audit the events. Audit Event resources are often (though not exclusively) created by the application responding to the read/query/create/update etc. event.

AuditEvent.object.lifecycle

Definition

Binding AuditEventObjectLifecycle: Required: http://hl7.org/fhir/object-lifecycle (Identifier for the data life-cycle stage for the object)

Type code

Requirements

Institutional policies for privacy and security may optionally fall under different accountability rules based on data life cycle. This provides a differentiating value for those cases.

Comments - This can be used to provide an audit trail for data, over time, as it passes through the system

Provenance Extension Most recent change - Definition

Provides the provenance record associated with the most recent update of the resource.

Comment:

[I may have totally misunderstood how the following FHIR capabilities are meant to work together, but this is the only sense I can make of the write up - so either I need more education on this and there needs to be better documentation or there's something fundamentally broken in the design, which wouldn't be that hard to fix.] AuditEvents are about actions performed on the server, which were initiated by an application, which may send Provenance about the context on the application side of a Resource that the application has uploaded, updated, executed, or deleted on the server. The FHIR Provenance Resource at this juncture has no element to convey the Resource's life span on the application or the specific lifecycle event that triggered the application to upload, update, execute or delete it on the server. According to the AuditEvent, all the details about what happened to the Resource are about actions on the server side, not on the application side, so that audit log isn't informative about what happened to the Resource on the application side. Perhaps the application that prepares the Provenance Resource to send along with the target Resource could also send along a snippet of the target Resource's audit log in order to inform downstream users about the actions performed on the Resource on the application side. But that means that the application has to be smart enough to determine what part of the audit log is relevant to the Provenance Resource being prepared to accompany the target Resource. Taking this approach means that the sender has to send along two optional Resources along with the target Resource, and there's no guarantee that the receiving server is going to persist them together.

Recommended fixes - Add an action element with binding to the ProvenanceEventCurrentState vocabulary [which is awaiting updating by the Security and EHR workgroup for appropriate workflow trigger events], add a pointer to the Provenance Resources to all entities involved in the generation of the target Resource, and add Lifecycle event to the Provenance Resource. Remove any dependencies with the application or the server side AuditEvent Resources.