Existing Wording: 1) AuditEventAction: Indicator for type of action performed during the event that generated the audit. Codes = CRUDE.

2) Event Types for Audit Events: Defined by DICOM with some FHIR specific additions.

3) Audit Event Sub-Type: More detailed code concerning the type of the audit event - defined by DICOM with some FHIR specific additions.

At bottom of subtype, there's the list of all FHIR Restful Interactions including CRUDE defined at /valueset-restful-interaction.html

4) FHIR defined Operations: Operations defined as part of this Specification - "The RESTful API defines a set of common interactions performed on a repository of typed resources (read, update, search, etc.,). These interactions follow the RESTful paradigm of managing state by Create/Read/Update/Delete actions on a set of identified resources. While this approach solves many use cases, there is some specific functionality that can be met more efficiently using an RPC-like paradigm, where named operations are performed with inputs and outputs."

5) AuditEventObjectLifecycle: Identifier for the data life-cycle stage for the object

Comment:

The disparate list of value sets required by the AuditEvent for specifying the action or "event", neither of which is cleanly delineated, need to be harmonized after analyzed for completeness and consistency, and suitability for purpose.

The AuditEvent Resource [/auditevent.html] has three REQUIRED value sets with which to value AuditEvent action related elements in addition to other IDs, and the FHIR Provenance Entity.role that conflict, overlap, are not coordinated, and are likely incomplete.

Some are very detailed, workflow, discipline, or system interaction specific and others are very high level. The value set "AuditEventAction" [/audit-event-action.html] is so coarse grained and generic that it's likely that the other value sets could be subsumed under one of its CRUDE codes.

The AuditEvent Resource has two elements in addition to the action element, the AuditEventType [Type/identifier of event - /valueset-audit-event-type.html] and the AuditEventSubType [More specific type/id for the event - /valueset-audit-event-sub-type.html] , but it's not entirely clear why one value set is considered an "action" and two other value sets are considered "types". This type and subtype combination appear to be DICOM specific system actions stated in the past tense. Some of the types clearly coordinate with related subtypes [Application Activity type could be subtyped by Application Start], but a number of them don't unless the majority of subtypes are events that raise the Security Alert Type.

Several Audit Event Types are for CRUD on granular objects, e.g., Order [Audit event: Order has been created, read, updated or deleted], Patient Record [Audit event: Patient Record has been created, read, updated, or deleted], and Procedure Record [Audit event: Patient Record has been created, read, updated, or deleted].

There's no description about how these are to be coordinated with any subtype audit events, why these are the only objects included in this list of audit events [although one could surmise that these were the focus of the DICOM community when developing the list of relevant audit events in their discipline], and how these are to be coordinated with e.g.:

• The audit event subtype restful-interaction "history-instance: Retrieve the update history for a particular resource" and "history-type: Retrieve the update history for a particular resource, type of resource, or the entire system",

• The 2.2.0.1 FHIR defined Operations "Fetch Patient Record" or "Fetch Encounter Record"

• "AuditEventAction" Update data such as Revise Patient Information.

• AuditEventObjectLifecycle Access/Use [/object-lifecycle.html].

In addition, elsewhere in the FHIR DSTU there are lists of FHIR defined Operations [/operations.html 2.2.01] RPC-like operations in addition to the Restful-Interactions listed as AuditEventSubtype values [bottom of restful-interaction /valueset-restful-interaction.html] that are arguably auditable actions/events.

This is not an exhaustive review of redundancy/overlap/gaps related to AuditEvent and Provenance Resource action related elements and value sets.

At this juncture, it's not clear how this potpourri of audit event types/actions are supposed to work together to achieve an interoperable approach to addressing 45 CFR 170 Meaningful Use Certification Criteria, 2015 § 170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged (e) Record actions related to electronic health information, audit log status, and encryption of end-user devices. (1) The audit log must record the information specified in sections 7.2 through 7.4, 7.6, and 7.7 of the standard specified at § 170.210(h) when EHR technology is in use. Nor is it clear how the plethora of audit event on the server are supposed to inform the Provenance Resource on the client as to what auditable actions of provenance relevance were performed. Despite assurances that there is coordination and some overlap between the capture of actions on Resources in the FHIR Provenance and FHIR AuditEvent, it is not clear how four Entity-Role codes on the Provenance Resource [derivation, revision, quotation, and source] map to any of the multiple codes in the AuditEvent. Recommendation is that the CBCC and Security WGs be directed to assist in a comprehensive information and behavioral modeling of this relationship, and to use those models to update the current FHIR AuditEvent and Provenance Resource structures and vocabulary.

Additional URLs: http://hl7.org/fhir/2015May/valueset-audit-event-type.html, http://hl7.org/fhir/2015May/valueset-