Basic AuditEvent for a successful Operation

A basic AuditEvent profile for when a RESTful Operation action happens successfully.

• Given a RESTful Operation is requested
• And the request is authorized

- Authorization failures should follow FHIR core Access Denied

• When successful

- Note a failure AuditEvent may follow this pattern, but would not be a successful outcome and should have an OperationOutcome - Note success may result in zero or more results. The number of results and the content of the results are not recorded.

• Then the AuditEvent recorded will conform

- The raw operation parameters is placed in the .contained element. The contained parameters enables preserving exactly what was requested, including possibly malicious patterns. This enables detection of malicious or malformed requests.

Note: the pattern defined in DICOM and IHE have the client is identified as the Source Role ID, and the server is identified as the Destination Role ID. This represents the query parameters are flowing from the client to the server. This may not be so obvious, as the data actually flows the opposite direction. This pattern is established and thus followed here.