Stream: implementers
Topic: R4 AuditEvent.agent
Michele Mottini (Jun 14 2019 at 14:49):
Our audit log contains the id of the user that performed the logged action (pretty standard I guess). Mapping it to AuditEvent in DSTU2 / STU3 we used AuditEvent.agent.userId. In R4 that's gone - the best match is AuditEvent.agent.who, but our users are not necessarily Practitioner or Patient - we actually map them to FHIR Person - and that's not an allowed target type for who - so not sure what to do
John Moehrke (Jun 14 2019 at 14:50):
use AuditEvent.agent.who.identifier - just record the user id as the identifier.
Michele Mottini (Jun 14 2019 at 14:53):
I see - and add the id a an identifier to our Person resource I guess?
John Moehrke (Jun 14 2019 at 14:59):
The is no need to add the id to the Person resource, but you might want to do that for other reasons. Cross-referencing business identifiers into the various agent Resources is always useful for Provisioning and Identity proofing.
John Moehrke (Jun 14 2019 at 15:00):
There is no expectation that using a Reference.Identifier will result in a positive lookup; only that it is technically possible for that business identifier could be found as one of the Reference types.
Michele Mottini (Jun 14 2019 at 15:06):
(scratch that - adding the identifier to Person would not give us anything: the client would not know which resource to look for, and in any case won't look at Person because it is not one of the possible references there)
Michele Mottini (Jun 14 2019 at 15:32):
Oh - and the user search parameter is gone
John Moehrke (Jun 14 2019 at 15:47):
yup, just ?agent now
John Moehrke (Jun 14 2019 at 15:48):
These changes are all driven by the FHIR methodology move to Reference inclusive of Reference.identifier.
Michele Mottini (Jun 14 2019 at 15:49):
yes - but that's a reference search parameter and what we have is an id, so it will take some hacks to make it work
John Moehrke (Jun 14 2019 at 15:51):
nope, very easy -- http://build.fhir.org/search.html#reference
Michele Mottini (Jun 14 2019 at 15:52):
The specs might be easy, the implementation is not: all our reference search parameters expect actual references to existing resources, and this will break that pattern and so require special code
Grahame Grieve (Jun 14 2019 at 21:36):
pattern might happen elsewhere too
John Moehrke (Jun 14 2019 at 22:31):
yup, the main reason to use Reference.identifier is because the entity has not yet or may never be persisted as a formal FHIR Resource. If it has been, then Reference.reference is the better solution (aka the only one that should be used).
John Moehrke (Jun 14 2019 at 22:33):
Main reason to populate Reference.identifier when there is an actual persisted formal FHIR Resource, is when you know the recipient of your data understands the business identifier and has no access rights to the FHIR Resource. This is possible, but unlikely, and especially unlikely that the sender knows that this is the case on the recipient.
Last updated: Apr 12 2022 at 19:14 UTC
