Stream: ibm
Topic: bundle
Yogesha K (Mar 03 2021 at 05:25):
Is there a specific order for resources while posting bundles? I encountered a specific case, lets say I have a patient resource and practitioner resource where Patient resource occurs first in bundle and Practitioner occurs next , and Practitioner is referenced by Patient with BOTH RESOURCES HAVING CONDITIONAL CREATE then the reference from Patient resource to Practitioner resource is not built by the server.
IS THIS THE EXPECTED BEHAVIOUR?
If it is and one should arrange resource bundle how should resources be posted with conditional create eg: Encounter and Condition(which reference each other)
The reference is being built by server if conditional create was disabled
Mike Schroeder (Mar 03 2021 at 13:44):
If you are talking about the processing of local references within bundles, then the order of the entries within the bundle generally does not matter (see https://ibm.github.io/FHIR/guides/FHIRServerUsersGuide#48-using-local-references-within-request-bundles for details). However, if using conditional create, that entry must appear in the bundle before an entry with a reference to that entry. So in your example, the Practitioner entry must come first if the Patient entry is referencing the Practitioner.
Mike Schroeder (Mar 03 2021 at 14:03):
In the case where two conditional create entries reference each other, only one reference will be resolved correctly. In your example, if the Encounter entry were first in the bundle and the Condition entry were second, then only the Condition's reference to the Encounter would be resolved correctly. This is because for conditional creates, we don't know the logical ID to use (could be the ID of the a newly created resource or the ID of an existing resource) until the conditional create is completed. So when the Encounter resource is processed, we don't know what the logical ID of the Condition resource will be, so we cannot resolve the Encounter's reference to the Condition resource.
Last updated: Apr 12 2022 at 19:14 UTC