Stream: implementers
Topic: revinclude:iterate and versioned references
Paul Church (Apr 26 2021 at 21:18):
The search spec says that _include SHOULD follow versioned references and provide the specified version. So the searchset may contain entries that are not the current version of the resource.
It's pretty clear what _include:iterate would do from that point - follow outgoing references from that version. But what does _revinclude:iterate do?
If the _include'd result is Patient/123/_history/456, it seems clear we want incoming versioned references to Patient/123/_history/456, if there are any. Should we also find incoming references to Patient/123? They might not be relevant to a past state of the resource.
Josh Mandel (Apr 26 2021 at 21:19):
Good question! Any existing behavior from servers we can review as a starting point?
Paul Church (Apr 26 2021 at 21:22):
Currently the Google implementation doesn't do either. I'm fixing revinclude to at least find the version-specific incoming references so it can catch Provenance.target.
Not aware of any other examples at the moment.
Paul Church (Apr 26 2021 at 21:25):
I think I lean toward not finding incoming non-versioned references. It's hard to come up with a use case where that's definitely desirable.
Paul Church (Apr 26 2021 at 21:25):
The problem is that the version might be current, in which case we should.
Grahame Grieve (Apr 27 2021 at 01:48):
very tricky questions; I've ignored them in my implementation, and I don't even know what would happen
John Moehrke (Apr 27 2021 at 11:10):
seems this should be directable, rather than a default unchangeable behavior. Provenance use likely does want version specific followed, as that is an important part of the mechanism that is provenance. Where else is version specific references used, are they intended to be soft (FYI, this was the version), or hard (this is the instance).
Lloyd McKenzie (Apr 27 2021 at 13:58):
The issue is that 'search' doesn't allow for multiple versions of a resource in the Bundle, so Provenance with includes is tricky.
Paul Church (Apr 27 2021 at 14:00):
Doesn't it? What if I have two results for my primary search, each of which has a versioned reference to different versions of the same resource, and I have an _include that follows that reference?
Lloyd McKenzie (Apr 27 2021 at 14:03):
Only 'history' Bundles are currently allowed to have multiple versions of the same resource.
Paul Church (Apr 27 2021 at 14:29):
That's an interesting conflict. I think there will be legitimate use cases for _include on versioned references that will collide with that constraint.
John Moehrke (Apr 27 2021 at 15:06):
Isn't the idea that Lloyd describing that generally a reference that is versioned is most of the time treated as the resource id (current)? Thus outside of a history bundle, you would always get the current?
John Moehrke (Apr 27 2021 at 15:07):
This is why a _revinclude on Provenance will find all historic Provenance based on the current Observation. And doesn't conflict because each of the Provenance are instances, not revisions.
John Moehrke (Apr 27 2021 at 15:08):
What is a use-case, @Paul Church , that you are thinking of where _include really wants version specific targets?
Paul Church (Apr 27 2021 at 15:19):
This came up in CARIN BB where they want an ExplanationOfBenefit and related resources to be a "point in time" record that aligns with what the patient would have seen on a paper claim. For example, a Practitioner should be represented with the affiliation and address that they had at the time of the claim to avoid confusion, e.g. "wait a minute, I didn't see a doctor at hospital X" if the practitioner has since moved.
One way of accomplishing this is through versioned references (rather than creating a bunch of Practitioner resources for the same individual), so the IG called for that. It was already allowed by the spec as a "should" so it didn't seem like a big deal.
John Moehrke (Apr 27 2021 at 15:21):
that is versioned references... but what about multiple historic versions of the same resource?
John Moehrke (Apr 27 2021 at 15:21):
your use-case sounds like a Composition. Often Compositions are a document of an instance in time.
Paul Church (Apr 27 2021 at 15:22):
If the patient searched for their ExplanationOfBenefit resources with an _include on Practitioner, you can imagine that two claims over time might have references to different versions of the same Practitioner, and those might occur in the same search.
John Moehrke (Apr 27 2021 at 15:24):
I think in that case you get the current Practitioner, not the historic (version). Thus you get one Practitioner for each individual practitioner involved. It might be referenced multiple times in the search set.
Paul Church (Apr 27 2021 at 16:25):
But in this case, it makes sense for the application to show multiple versions of the same Practitioner when displaying the various claims. It would be confusing if sometimes you saw the referenced version and sometimes saw the current version depending on what search results were present.
Josh Mandel (Apr 27 2021 at 17:12):
Agreed, Paul's use case is pretty clear; I don't know why we'd intentionally rule this out.
Lloyd McKenzie (Apr 27 2021 at 17:47):
I don't know either.
Last updated: Apr 12 2022 at 19:14 UTC
