Change of scope for AuditEvent

[jkiddo]

From the conversation on https://chat.fhir.org/#narrow/stream/179166-implementers/topic/AuditEvent I suggest that scope for BALP AuditEvents should have the responsibility of being a rough overview of what has happened and redactable on selected fields based on whatever security model is in place as they should be accessible for both clinicians and patients.

In general, I think the AuditEvent.entity.query lacks specificity (also raised on https://jira.hl7.org/browse/FHIR-42960) and I think one should be careful about what to put into the query field. I think the headers generally should be omitted. It should be sufficient to have a traceID in the AuditEvent. From the traceId one can go to whatever request/response log system one has and look up the traces there getting the full monty if need be.

Trying to fit everything (or almost everything in terms of logging, header etc.) into AuditEvent sounds like scope creep.
See https://www.w3.org/TR/trace-context and e.g. https://opentelemetry.io/ for more context on tracing.

[JohnMoehrke]

The trace model was not sufficiently defined. I would be happy to have a variant of AuditEvent profiles that rely on trace model, provided the trace model can be explained. Given we didn't have any feedback or experts in the trace model, we defined a model that would work.

[jkiddo]

All you need is a traceID in the auditevent. Its a bespoke tooling thing to resolve that traceID to the set of related requests. I dont see what model needs to be defined besides defining where the traceID should go into the auditevent

[JohnMoehrke]

If that is the case... (I don't know anything about traceID), then I would be fine with a set of profiles to be used when traceID is used that do not record anything else. I simply didn't have that knowledge and didn't want to guess.