A basic AuditEvent profile for when a RESTful Query / Search action happens successfully.

• Given a RESTful Query is requested
• And the request does not have a Patient subject indicated
  • The requestor logging the event would potentially not know they have requested Patient specific data
  • The data objects may not be patient specific kind of objects
  • when the request is Patient specific then PatientQuery is used
• 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.
• And the results are not Patient specific
  • when the results are Patient specific then PatientQuery are used
• Then the AuditEvent recorded will conform
  • The raw search request is base64 encoded and placed in the .entity[query].query element. The base64 encoding of the raw search request enables preserving exactly what was requested, including possibly malicious patterns. This enables detection of malicious or malformed requests.
  • The cleaned search may be recorded (not base64) in the .entity[query].description. The cleaned search request would have removed parameters that were not understood/supported. The cleaned search request in the .description element enables more efficient processing.

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.