Stream: implementers
Topic: resource metadata
Brian Postlethwaite (Jun 23 2016 at 03:17):
The Meta component has a curret property lastModified which indicates when the record was last updated/created.
I'm interested to know if anyone has considered exposing the user details that made the change also? (I know it should be in the AuditEvent, but you're not always getting that)
Stephen Royce (Jun 23 2016 at 04:42):
Yep. I'm also interested in retaining created date.
Brian Postlethwaite (Jun 23 2016 at 04:49):
Unfortunately, that's back in the history of the resource.
Brian Postlethwaite (Jun 23 2016 at 04:51):
(in the oldest version of the resource)
[base]/Patient/34/_history?_count=1&_elements=meta.lastModified (then use the last link in the bundle returned)
Not sure how many of the reference servers would do this _elements filtering into the history.
Stephen Royce (Jun 23 2016 at 04:53):
Yeah; so that's all well and good, but it's a ginormous pain when you could just copy it forward in the metadata each time.
Brian Postlethwaite (Jun 23 2016 at 05:28):
(I know, might also want the createdbyuser too)
Stephen Royce (Jun 23 2016 at 05:29):
Yep; original author is very useful to know, especially when they're authoring StructureDefinitions. 
James Butler (Jun 23 2016 at 05:33):
We (Orion Health) are using an extension to express author/custodian on all our CDA- and v2-derived resources - it is indeed useful.
Brian Postlethwaite (Jun 23 2016 at 06:04):
Can you share the details of these extensions?
(where you put them and what is in them)
James Butler (Jun 23 2016 at 21:27):
We put the extension on every top-level resource we serve (or do you mean where is the definition registered? We haven't got that far yet). The structure is inspired by Provenance.agent - a role code (I stole the valueset from https://www.hl7.org/fhir/valueset-provenance-agent-role.html) plus an identifier and a reference to a Practitioner or Organization. The idea is to populate the identifier and optionally a (contained) resource depending on the richness of the source data.
The intended use is for writing privacy/access rules in a multi-participant HIE-style system. Ideally this or something like it would be standard metadata or at least a standard extension, I guess that depends on how widespread the use case is.
David Hay (Jun 24 2016 at 01:47):
This post - https://fhirblog.com/2016/02/18/where-did-that-data-come-from/ describes the process we went through at the time...
John Moehrke (Jun 24 2016 at 14:36):
It sure seems like you are reinventing Provenance... why can't Provenance be used? More importantly, can you help us improve Provenance so that it can be used? Having two different ways of doing Provenance, with one being extensions, seems like a bad design for us this early in FHIR lifecycle.
Brian Postlethwaite (Jun 26 2016 at 05:24):
Its that you don't want the rest of it, and always have to ask for it. All other data would be expected in either provenance or AuditEvent
James Butler (Jun 26 2016 at 23:20):
As David mentioned in his linked blog, and as Brian points out, Provenance is a heavy beast when all you want to know is a single identifier; and the direction of the Provenance references makes it difficult to serve up at the point we need it. Also we're not building a FHIR server de novo - we're adding FHIR read APIs to an existing solution where constructing a useful Provenance endpoint would be difficult and of (so far) limited value. Maybe we'll get there one day though.
Chris Grenz (Jun 27 2016 at 14:42):
We've contemplated operations to provide summary Audit and Provenance information for each resource that would take into account the existence of those resources...anyone else?
John Moehrke (Jun 27 2016 at 15:13):
Chris, how is this not simply a query on the Provenance resource? or query on AuditEvent resource? If you have Resource X, and you want to know all Provenance resources about it, you just query for Provenance resources with target of X. Similarly with AuitEvent.
Chris Grenz (Jun 27 2016 at 15:16):
Return parameters would be what the above have requested - create by/time, update by/time, optionally some information gleaned from provenance records. Nothing that you couldn't get by querying and summarizing client-side AuditEvent and Provenance resources, but in a more usable form.
Chris Grenz (Jun 27 2016 at 15:17):
And, potentially at scale (a record for each of a large set of resources) that wouldn't be as practical when executed a record at a time.
Chris Grenz (Jun 27 2016 at 15:20):
Not sure this needs to be a standardized operation or not...again, more spit-balling here than proposing...
John Moehrke (Jun 27 2016 at 15:23):
Okay... since you are just spit-balling.... I will ask for your perspective on what makes the existing Provenance and AuditEvent such that you need something 'more usable'? How are they not useable? I presume you have looked and found them problematic, if so, now is the time to fix them. Or you have some use-case scenario that has different needs?
Chris Grenz (Jun 27 2016 at 15:28):
Not sure I have an issue with them as-is...the issue for me is probably just a lack of good client-side tooling to access them. Digging through an auditevent log with postman is painful, and generally I'm just after a list of creates/edits (who and when). A nice summary operation would cover many of my "what's going on here?" kinds of questions...
John Moehrke (Jun 27 2016 at 15:47):
We did try to make the _summary query useful... Your argument might be indicating a few more elements could be eliminated from a _summary request? This would be a nice CP I would like the committee to consider; could you write up that CP?
Chris Grenz (Jun 27 2016 at 15:51):
Will give it some thought....
Grahame Grieve (Jun 27 2016 at 20:50):
there's other resources where server side summarization is a very useful thing too. Observation is one where we have a draft for server summarization. I can see a provenance summary being useful too.
Grahame Grieve (Jun 27 2016 at 20:51):
of course these are things that could be implemented by making the client fetch the data and do the analysis itself, but there's several advantages in getting the server to do the analysis
Grahame Grieve (Jun 27 2016 at 20:51):
and none of this indicates that the resources themselves are at all deficient
Brian Postlethwaite (Jun 28 2016 at 00:46):
Looking at the Provenance structure, in order to display on in a search result set the createby/date, updateby/date I would need to:
1. perform queries to retrieve the provenance for the record in the result,
2. grab the history of the resource to locate retreive the link to the first version of the resource
3. retrieve the provenance for that first version of the resource.
Then my issue is that the userId is there, but the username isn't. The security system is likely not FHIR resources, and hence i'd need to just read the display from the Reference on the actor
Note: For our system we wouldn't record anything else from this resource, except where the content was introduced by external systems (such as via an integration engine/messaging).
AuditEvent however, we do use basically as is, and the only oddity I've had with that is the lack of the simple requestURI that was used.
Brian Postlethwaite (Jun 28 2016 at 00:46):
I think that captures my thoughts, if I'm misusing things, I'd like to know about it.
Thomas Johansen (May 14 2018 at 13:50):
Hi!
I'm wondering if there are any appropriate fields to put "custom" metadata? Use case: I have a codesystem that has a product brand and a URL to some medication site online. Only 0..* I see is Coding, but I guess this is not correct use. Any input on this?
// Thomas
Michel Rutten (May 14 2018 at 13:54):
Hi @Thomas Johansen, you could define some custom extensions. This would allow you to exchange and process the custom metadata.
Thomas Johansen (May 15 2018 at 04:36):
@Michel Rutten Hi Michel! I see, I was hoping this was a common use case and therefore within the spec without turning to extensions. But I guess this kind of data is of non importance and ok to put in extension. Thanks so much for your time :)
Michel Rutten (May 15 2018 at 07:16):
Hi @Thomas Johansen, I wouldn't say the data is of non-importance - it is just not covered by the core FHIR resource definitions.
Last updated: Apr 12 2022 at 19:14 UTC
