Stream: implementers
Topic: reference.identifier in bundles
Josh Mandel (Oct 16 2020 at 18:38):
The spec says:
Note, in addition, that a reference may be by identifier, and if it is, and there is no URL, it may be resolved by scanning the ids in the bundle
What does "scanning the ids" mean here? Does it mean looking through each entry.resource.identifier[] , or is really about ids?
Michele Mottini (Oct 16 2020 at 18:39):
It says ids, why would it be about identifier ?
Josh Mandel (Oct 16 2020 at 18:40):
I honestly don't know what it's supposed to mean. How do you compare an identifier with an ID?
Lloyd McKenzie (Oct 16 2020 at 18:41):
It should have said identifiers. If you have a Reference.identifier, it could only be matched against Resource.identifier.
Josh Mandel (Oct 16 2020 at 18:41):
I'll add this to my write-up in Jira, thanks.
Lloyd McKenzie (Oct 16 2020 at 18:41):
Though resolving references that way would be plain weird
Josh Mandel (Oct 16 2020 at 18:41):
I agree!
Paul Church (Oct 16 2020 at 18:42):
It's not even clear to me that this is necessarily talking about reference.identifier. It could almost be talking about urn:uuid values in the ID field.
Paul Church (Oct 16 2020 at 18:44):
Resolving reference.identifier by looking at Identifiers in the bundle or on the server is its own can of worms.
Paul Church (Oct 16 2020 at 18:48):
The wording in this section does not address other transaction semantics, so calling out conditional references in the next sentence seems out of place. One of the most interesting aspects of resolving resource identity within a bundle is that a conditional create or update entry could resolve to either a new identity or the identity of an existing resource on the server.
Josh Mandel (Oct 16 2020 at 19:02):
Agreed. I've done my best to update the rules for clarity at FHIR#29271 -- but of course in the process of spelling out details, I'm sure to have raised some issues. Would love comments/notes on this Jira issue, so we can do a round of revisions before taking this up in a #fhir/infrastructure-wg call.
Vassil Peytchev (Oct 16 2020 at 19:58):
Resolving logical references (via reference.identifier) is not avoidable. Nothing has prohibited their use in Bundles, and it is too late to start now. I think it would be reasonable that such references are only resolved within the bundle, and only when reference.reference.value is not populated.
John Moehrke (Oct 17 2020 at 14:15):
I have asked a few months back about similar and got no useful answer. Add into this mix the fact that a Reference is no longer just a Reference. It is now a complex datatype holding a Reference.reference that you are all talking about, but it also has Reference.identifier which you are all saying is in conflict. This is all very confusing...
Chidamber Kumar (Oct 19 2021 at 13:08):
Hello
A question on modifier: identifier.
Does the below search matches the search value to 'Patient.managingOrganization.identifier.value' or ' Organization.identifier[].value' ?
http://test.fhir.org/r4/Patient?organization:identifier=Hostpital10
Would it result the Patient if 'Patient.managingOrganization.identifier.value' is null but Organization has a identifier ?
Lloyd McKenzie (Oct 19 2021 at 13:26):
The identifier modifier searches Reference.identifier, not Reference.resolve().identifier.
Chidamber Kumar (Oct 19 2021 at 13:34):
Thanks @Lloyd McKenzie for clarifying that.
Last updated: Apr 12 2022 at 19:14 UTC
