Stream: Security and Privacy
Topic: Provenance question
David Hay (Jul 09 2019 at 21:04):
Actually a couple of questions.
- agent.who is a reference to a FHIR resource. What is the process if the updater was identified in some other way? For example, there's an external API manager that authenticates the user with a username - and that username is all there is (eg no corresponding Practitioner / Patient whatever) - maybe passed in the JWT access token...
- when updating a resource, you want to create a provenance resource, so you put them both in a transaction. The Provenance.target is a reference to the resource being updated (and you have its id), but it's a version independent one (as it should be pointing to the version that the server will create out of the transaction rather than the version that was changed). Is there a way to 'force' the server to make the Provenance.target a version specific one? (I'm using hapi for testing)
John Moehrke (Jul 10 2019 at 11:52):
put the username in agent.who.identifier
John Moehrke (Jul 10 2019 at 11:54):
I don't know on the second question. Need this asked of FHIR-I.... However might this be automatic if you use the X header rather than a transaction? http://build.fhir.org/provenance.html#header
David Hay (Jul 11 2019 at 00:03):
Thanks - I wondered about that... (the reference.identifier is quite useful when it should be a reference, but the target is not yet fhir enabled). I'll try out the XHeader - it doesn't seem to work in a transaction...
John Moehrke (Jul 11 2019 at 16:16):
I look forward to you pushing for a general solution for within Bundle version specific references... I am sure Provenance is not the only use-case needing this
Mohammad Jafari (Jul 15 2019 at 01:40):
RE the first question: if there is more information about the user (other than a single user name), it may make sense to create a contained resource to capture that information and set the agent property to the reference to the contained resource.
Contained resource can also be a potential solution to the second question although I imagine if you would like to be able to search over the provenance resources separately, searching over contained resources may be difficult to implement and less likely to be supported by most implementations.
Generally, I think using a contained resource in cases where the contained resource will have a life of its own independent of the containing resource, is not a great design choice.
John Moehrke (Jul 15 2019 at 13:19):
@Mohammad Jafari would be interested in determining a common set of attributes to reflect in AuditEvent from the security token introspection. However, I would tend to NOT put anything but identifier.. I do think identifying the app and user are useful AuditEvent.agent entries. Queries into AuditEvent often demand that the appropriate use must have access to many identity registries. In this way the log is minimally exposing, but has all the pointers necessary for full use as appropriate.
John Moehrke (Jul 15 2019 at 13:21):
In IHE the IUA profile (the one for REST and OAuth) it does define how one takes the JWT aud, sub, and iss parameter to make the user name for the audit log. Likely that needs to be ehnanced too
Mohammad Jafari (Jul 15 2019 at 16:42):
To add to your point, there is also a need to provide a mapping (as well as profiling some extensions) for extracting AuditEvent information from an OAuth token introspection response. The Client may provide several assertions about itself and the transactions at the time of requesting a token from the OAuth server and these assertions are often consequential in making the decision to issue the token and grant scopes. However, very little of that information is made available to the Resource Server (i.e. FHIR in this case) in the introspection response.
John Moehrke (Jul 15 2019 at 18:46):
I would expect that any application that is doing security or privacy analysis using the AuditEvent log also has intimate access to the OAuth authorization logs. Thus we only need to provide a linkage between the token in the AuditEvent, so that one can look up the details of what that token meant at the time in the OAuth authorization service log and directory.
David Hay (Jul 15 2019 at 19:03):
The Provenance resource refers to a specific target resource version, so to determine what changes were made you need to retrieve the previous version and do a diff. (I believe). If you are already using AuditEvent resources to record access, would it be reasonable to record the changes that were in that resource (eg address updated, name changed) to support a simple 'who updated this resource' view? Or would you add that data to Provenance and have 2 resources - AuditEvent and Provenance ?
John Moehrke (Jul 15 2019 at 19:12):
Neither AuditEvent or Provenance contain THE changes. As you indicate, actual changes are represented in the diff between versions. Thus, if one really needs to know the diff, then one MUST have a system that supports version based FHIR.
Mohammad Jafari (Jul 15 2019 at 19:18):
I would expect that any application that is doing security or privacy analysis using the AuditEvent log also has intimate access to the OAuth authorization logs. Thus we only need to provide a linkage between the token in the AuditEvent, so that one can look up the details of what that token meant at the time in the OAuth authorization service log and directory.
@John Moehrke this would be fair (at least for some use-cases) if OAuth 2.0 had a standard endpoint/data structure for access to its logs which right now is :shrug:
Consider the case where an app wants to show a patient a record of access to that patient's information at a FHIR server (i.e. which organizations, apps, etc. and at what times). The simplest way is for this app to be granted suitable scope to fetchAuditEvent resources corresponding to the patient in question and render them in some UI. For that the AudutEvent needs to have sufficient information.
What you suggest would require to either of the following:
- The app be granted the scopes to fetch the logs from the OAuth server directly, or
- The FHIR server to query the OAuth server, somehow compile the logs in the form of FHIR AuditEvent resources on-the-fly and sends them to the app.
Both of these require an API for access to logs/audit from the OAuth server.
John Moehrke (Jul 15 2019 at 19:19):
In a comprehensive world there is duplication of every update in both a Provenance record, and one(or more) AuditEvent records. The difference between Provenance and AuditEvent is the audience that will use the data.
Realistically Provenance is only a subset of updates, those that are clinically (or medical records) relevant. And these Provenance records live as long as they data they are describing.... Provenance is there to support clinical workflows and medical records regulations...
Where as AuditEvents are all accesses and update; but also include many events that have nothing to do with data (physical actions, system actions, user actions, etc). The AuditEvents are analyzed in context of security and privacy and efficiency kinds of use-cases. The AuditEvents are more likely to be filtered and expunged after analysis. Meaning that AuditEvent will likely only be n years deep (e.g. 7 years deep, or 20 years deep).
John Moehrke (Jul 15 2019 at 19:22):
@Mohammad Jafari I am happy for either of those solutions.. FHIR is an API, not a systems-design. I think you are looking for a systems-design. That all said, the use-case you describe is why the recommendations I pointed at do try to encode a UserName that is useful without being exhaustive, and why I asked about potential improvement based on your experience. I just don't think it is correct to encode EVERYTHING in the AuditEvent.
David Hay (Jul 15 2019 at 19:29):
So the requirement we're working with (its a registry project) is to be able to display a report of changes as well as accesses to a resource (user X changed the address on this date, user Y changed it on that date, user Z just looked at it). The back end is not a FHIR server, but can record the changes. Just wondering what the API would be to expose that list
John Moehrke (Jul 15 2019 at 19:41):
So the requirement we're working with (its a registry project) is to be able to display a report of changes as well as accesses to a resource (user X changed the address on this date, user Y changed it on that date, user Z just looked at it). The back end is not a FHIR server, but can record the changes. Just wondering what the API would be to expose that list
In your case you could use a combination of Provenance and AuditEvent, or you could just use AuditEvent. Given your use-case is beyond that which is intended for Provenance (because you want read events tooo), this is why I think AuditEvent is more complete. You should make sure that there are system-design requirements that assure all these events are available as AuditEvent, and that the AuditEvent record does include AuditEvent.entity references that are version specific as appropriate. (Note seems your use-cases are similar to what IHE has for ATNA)
John Moehrke (Jul 15 2019 at 19:46):
I will note that the current distinction for Provenance and AuditEvent are based on existing systems in healthcare. This being one of the principles behind FHIR. We chose to limit Provenance to Create, Update, Delete; because that was the concepts typically expected of Provenance in healthcare systems. That experience based on Medical Records Retention practices and regulations. That limit is NOT the limit that W3C has for Provenance, where they also include Read operations. We could learn from our FHIR experience that this separation was a bad idea.
David Hay (Jul 15 2019 at 20:00):
Yeah - AuditEvent seemed the most appropriate - given that we want all accesses. Perhaps using AuditEvent.subType to record the 'nature' of any change (rather than the details). - eg change address etc. ...
David Hay (Jul 15 2019 at 23:54):
Actually - I see that subType would be something like 'update' to indicate that the entity.what was updated. The nature of the update could be in outcomeDesc if we were happy with just text - otherwise I guess an extension...
Last updated: Apr 12 2022 at 19:14 UTC
