Existing Wording: 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.

A 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.

Proposed Wording: A Provenance Resource is a record-keeping assertion applicable to a specific Resource, which conveys contextual information about the Resource to which the Provenance Resource applies. This contextual information is bound to the Resource so that downstream users can ascertain the authenticity, reliability, and trustworthiness of the Resource. Senders and receivers should establish policies about their expectations with regard to ensuring the continuity of provenance information is available as applicable to their use cases in accordance with FHIR specifications. Workgroups with scope encompassing various FHIR Resources are responsible for ensuring that the FHIR Provenance Resource is appropriately bound to their Resources given the requirements of their disciplines and domains, and to provide sufficient guidance to implementers to enable deployment without deep subject matter expertise on this topic.

When an application initiates interactions on a server that manages the state or operations on Resources, the application assigns a Provenance Resource to the target Resource and any previously bound Provenance Resources, which the server persists to enable end users to evaluate the authenticity, reliability, and trustworthiness of that Resource. The application's actions are tracked by the application's AuditEvent component, which must record the application's behavior that enabled the application user to initiate the actions recorded in the Resource's Provenance. Once the interaction is completed, the server's AuditEvent component must record the server's behavior, which enabled the persistence of any Provenance Resources assigned to the interaction's target Resource.

Comment:

The current Scope and Usage description does not sufficiently specify how to implement the FHIR Provenance Resource in order for it to actually indicate the "clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle." Not only does it not specify the requirements for or the means by which persistence of the provenance but leaves it up to the sender as to whether to send a Provenance Resource along with a transmitted Resource to which it merely points. This lack of binding leaves the persistence of the provenance entirely up to the receiver. If the receiver does not retain the provenance, then the FHIR Provenance Resource is not available to end users. This is concerning given that the FHIR APIs do not prevent updates being made by systems and users who did not author the target Resource.

In addition, the characterization of the relationship/overlap/dependencies between the AuditEvent and the Provenance Resources are also concerning. Comments below indicate the lack of a cohesive framework within the AuditEvent and between it and the Provenance Resource for conveying, in a harmonized, comprehensive, and complete manner, the system and user actions that are (1) recorded by Provenance Resource as the sender generates the Resource to which it applies, (2) the AuditEvents that should be recorded in the sender's system about what the sender is generating (which is not mentioned in the description of either Resource), (3) the AuditEvents that should be recorded by the receiver's server pertaining to the requested and actualized behaviors sought by the requester, and (4) the server's responsibilities with respect to persisting Provenance Resources assigned to the target Resource.

While acknowledging the pioneering work that the FHIR Provenance and AuditEvent Resources authors undertook and the foundational importance of that contribution, discussions within the CBCC and Security WGs indicates that the authors and work group participants are aware of the need to refine and further articulate the critical infrastructure specifications of these Resources in FHIR so that this standard can enable the PCAST and JASON reports vision of atomic clinical relevant information structures that are persistently associated with both privacy [and its enforcing security] and provenance metadata. This comment is intended to provide more detail on the direction in which that detailed enhancement should be headed.