I need to store details about CRUD operations with resources, ex:
- User ID (note that it is an external application user, not Practioner or Patient) who did changes.
- Information about submitter and processing details.
- My custom data, not related to FHIR.
So what is the best option:
- Store it in the resource itself, in meta, extension, or somewhere.
- Use AuditEvent
- Use Provenance
By description, AuditEvent or Provenance may suit, but I am confused by required fields like Provenance.agent.who (a reference to Practioner, Patient, etc.). In my case, not Practioner (or any other FHIR entity) made changes, so I am not sure that it is the appropriate resource for my need.
Typically you’d always have AuditEvent for internal use, though you might not store it using a FHIR resource representation unless there’s a need to share. Provenance would be the mechanism this information would generally be exposed to a user. Any change is obviously made by someone/something (provider, organization, software, patient, etc.) All of these are representable as FHIR resources (Practitioner, Organization, Device, Patient). If you don’t have a FHIR representation of the information to point to, you could capture the information as contained resource within the Provenance or even using Reference.display.
Thanks for the answer.
“Any change is obviously made by someone/something (provider, organization, software, patient, etc.)”
It is not always possible to determine who did changes. Ex in my case I am receiving a message and trying to save it as Rest resources and have no information who in hospital originally did that changes. So I can’t use AuditEvent without workarounds because it is not possible to explicitly fill required fields like agent.who
If you’re receiving a message, then you’d be auditing that - and the ‘who’ would be the system that’s sending it to you (which hopefully you do know).
Hm. So I should create Organization/Device representing the sender. In my case, it was outside the FHIR server itself but that makes sense. Thanks.
You can also choose to just use Reference.display and/or Reference.identifier instead of Reference.reference if you don’t want to have an Organization instance for the sender.