Stream: implementers
Topic: Adding _include, _revinclude to history operation
Lloyd McKenzie (Sep 25 2021 at 02:59):
FHIR#32367 proposes adding support for _revinclude and _include to allow retrieving Provenance and possibly Provenance-associated entities (e.g. Practitioner) back with the history items so the recipient wouldn't need to invoke separate queries for each to see who had made the change, why, etc. Feedback from the community is welcome.
Brendan Keeler (Oct 13 2021 at 16:52):
This sounds cool
Brendan Keeler (Oct 13 2021 at 16:53):
and useful
Lloyd McKenzie (Dec 06 2021 at 21:29):
Didn't get a whole lot of response (thanks @Brendan Keeler for at least providing one :>). Pinging to see if we can get some more feedback before FHIR-I makes a decision on whether this would be a good thing to add.
Grahame Grieve (Dec 06 2021 at 23:04):
@James Agnew @Alexander Zautke @Paul Church @nicola (RIO/SS) @Lee Surprenant @Peter Jordan @Michael Lawley @Brian Postlethwaite - please respond to this one too
Brian Postlethwaite (Dec 07 2021 at 00:06):
I'm not against it, but don't see it as being used that often.
I'd normally expect that you'd already have the initial content and then going back to review history, at which point you'd likely only be wanting to grab the stuff you don't already have.
And these would be usually current versions of the referenced resources, not the version at the time that instance was grabbed - so may not be what you were after either.
Would want to think more about the use cases and if this is really the data that you would want to be getting back.
nicola (RIO/SS) (Dec 07 2021 at 00:42):
We should think twice before "searchable history". This feature looks so attractive, but i fill it's a trap ;) Looks like Provenance is from "meta" world, i.e. not an ordinary resource. I'm definitely against including other resources than Provenance. For me specialized parameter aka _with_provenance would be more appropriate.
Brian Postlethwaite (Dec 07 2021 at 01:59):
I don't think it's implying additional search on history, I think it's just grab other stuff along with the history content (not changing the core of the request at all)
Brian Postlethwaite (Dec 07 2021 at 01:59):
(and I too would be against further extending the "searchable" part of history)
Grahame Grieve (Dec 07 2021 at 02:12):
it has a subtle difficulty that is pretty important - search doesn't work on history; you'd get back the current resources for the agents. That could be problematic
Grahame Grieve (Dec 07 2021 at 02:12):
or not
Lloyd McKenzie (Dec 07 2021 at 03:21):
I'd be fine with limiting it to Provenance - though the Practitioners, Devices, Organizations, etc. that the Provenance points to could also be useful.
nicola (RIO/SS) (Dec 07 2021 at 04:39):
What is the use case for _history with provenance - Audit?
Lloyd McKenzie (Dec 07 2021 at 04:41):
When a user wants to look at "what happened in the past", they typically want to see "what changed" as well as "who did it and why?". History only answers the former question. You need Provenance for the latter part.
nicola (RIO/SS) (Dec 07 2021 at 04:45):
Don't you think, that good place for this info is resource.meta? :)
Lloyd McKenzie (Dec 07 2021 at 04:49):
Resource.meta isn't the place we store that information. Provenance is.
Michael Lawley (Dec 07 2021 at 06:42):
Which version of the referenced resource would you get back? The latest / current, or the one that was current at the time the history entry was created?
Lee Surprenant (Dec 07 2021 at 12:54):
To me, this doesn't seem so compelling to warrant the additional complexity.
If it was added, would we also add a field for it in CapabilityStatement so that clients can determine if its supported?
Lloyd McKenzie (Dec 07 2021 at 14:22):
History returns all versions. Provenance links to a specific version, so you'd get back the Provenance entry for each version. We could certainly define an extension to flag it in CapabilityStatement. (Don't know it would be common enough to justify a core element.)
Paul Church (Dec 07 2021 at 17:47):
I lean against adding this capability. I do see the use for it - primarily for Provenance, but maybe other cases like AuditEvent? Or some cases where _include is a useful convenience.
But this is only a convenience. The client could already call _history, get back the names version1, version2, version3, and then search Provenance?target=version1,version2,version3 as a separate call. Adding include/revinclude further complicates the history API and will open up a hundred little decisions about the details for something that is almost like search but not quite - can you :iterate? where is support for this declared in the capability statement? what happens in various error cases?
On balance I don't see this as a compelling enough feature to justify tackling all of this complexity.
Josh Mandel (Dec 07 2021 at 23:30):
Agree with Paul. Batch read requests are another way to let clients control inclusion.
Last updated: Apr 12 2022 at 19:14 UTC
