Stream: implementers
Topic: version specific references in transactions
Ben Spencer (Oct 31 2017 at 05:47):
Can a transaction create two resources with one having a version-specific reference to the other (eg Provenance)?
Ben Spencer (Oct 31 2017 at 07:21):
Actually I don't really understand how version-specific references work for PUTs in transactions either, do you need to assign a local version ID to the resource being referenced?
Lloyd McKenzie (Oct 31 2017 at 14:56):
Yes, you'd assign a local version id and make the reference version-specific. When processing the transaction, your version would be replaced with the server's version.
Elliot Silver (Nov 07 2017 at 01:19):
@Lloyd McKenzie , can you clarify what that would look like? If I have a bundle with a two new resources: a Patient, and an Observation. I want Observation.subject to point to the Patient version submitted (I know, not likely in the real world). Would Observation.subject be <guid>/xyz? And the Patient (with that guid) in the Bundle would be defined as having version xyz? Do we expect both the guid and the version are replaced in the reference when the resources are created? (We can't keep the version since we don't know how the server assigns version numbers.)
Lloyd McKenzie (Nov 07 2017 at 03:50):
It would be <guid>/_version/xyz, but otherwise yes.
Elliot Silver (Nov 07 2017 at 05:06):
Can you point me to where we say version numbers can be replaced on a PUT? I can't seem to find it.
Ben Spencer (Nov 07 2017 at 07:04):
Not very explicit but mentioned in the paragraph about updating references here: https://www.hl7.org/fhir/http.html#2.21.0.17.2
Ben Spencer (Nov 07 2017 at 07:05):
Resolving versioned references is also covered here: https://www.hl7.org/fhir/bundle.html#references
Elliot Silver (Nov 07 2017 at 23:07):
So, Resolving references in Bundles says:
If the reference is version specific (either relative or absolute), then remove the version from the URL before matching fullUrl, and then match the version based on Resource.meta.versionId.
And Transaction Processing Rules says:
If the server assigns a new id to any resource in the bundle as part of the processing rules above, it SHALL also update any references to that resource in the same bundle as they are processed. References to resources that are not part of the bundle are left untouched. Version-specific references should remain as version-specific references after the references have been updated.
Is a "versionId" an "id"? I don't think either make clear that the version number can be updated (and will be kept in sync across resources in the bundle.
Elliot Silver (Nov 07 2017 at 23:14):
Brian Postlethwaite (Nov 10 2017 at 09:44):
I'm not sure I like bundle processing choosing to replace the versioned references included.
How could I upload a resource that was referring to an older version of a resource in the history?
Lloyd McKenzie (Nov 10 2017 at 12:15):
It'd be hard unless you had a corresponding version in your local store and maintained a map of version ids
Elliot Silver (Nov 10 2017 at 17:27):
Wouldn't updating history only apply when both the referring resource, and the referred resource are new and in the same bundle?
...Actually no, we would need to cover new/updated resource makes reference to new/updated resource. That complicates it a little -- I was thinking that if a resource has a uuid id we could treat the version as replaceable, but if the resource already exists, we can't do that. So, the issue comes down to how to make a reference to a specific-version of a resource, when we don't know the version yet. Can we define a special version, e.g. "0" or "*", that indicates the server should replace?
Last updated: Apr 12 2022 at 19:14 UTC
