Stream: implementers
Topic: Can we save entry item with version of Resource Object.
Karimulla (Sep 29 2017 at 10:28):
Hi,
I want to save few FHIR resource objects reference in Composition Section entries.
I want to save entry with version also?
Is there any way to that?
Lloyd McKenzie (Sep 29 2017 at 15:10):
I'm not totally clear on your question. Can you give an example of what you're trying to do?
Karimulla (Oct 03 2017 at 11:41):
@Lloyd McKenzie Sorry For Late reply.
I need to Composition Resource object need to save entries with Observations.
Basically Entry supports reference id of Resource object. But I need to keep version of Resource object.
Example:
Entry [Observation/1234,Observation/1235,Observation/1236]
I want to keep version of Observation resource objectEntry [Observation/1234/_history/1,Observation/1235_history/3,Observation/1236/_history/6]
Grahame Grieve (Oct 03 2017 at 11:49):
that would be in resource.meta.version, no?
Karimulla (Oct 04 2017 at 10:30):
Can we store version info in Reference?
Lloyd McKenzie (Oct 04 2017 at 13:48):
The URL of your reference can be version-specific.
Elliot Silver (Oct 04 2017 at 19:47):
@Lloyd McKenzie , since version numbering is server implementation specific, is there a way you can post a transaction bundle with several new resources that reference each other in a version specific manner?
Lloyd McKenzie (Oct 04 2017 at 19:53):
Within the Bundle, you indicate the versions in the URL and in resource.meta. Doing this only really makes sense in a query response though. It wouldn't accomplish much in a batch or transaction Bundle.
Elliot Silver (Oct 04 2017 at 20:36):
Well, lets say I'm creating two resources in one post transaction. I want one to point to the specific, just created, version of the other. I don't care what the ids of the newly created resources are. New resource would get an UUID url in the bundle, but I can't use {UUID}/1 to refer to the just created version. (Can't use because (1) I don't think that's valid syntax, and (2) we don't know that the server is going to use 1 for the first version.)
Grahame Grieve (Oct 04 2017 at 20:43):
you just refer to the resources by their local id in the bundle - that is version specific. It doesn't matter what the server will assign to them
Elliot Silver (Oct 04 2017 at 20:48):
I'm missing something. What does a version specific reference to a new resource look like in a bundle? How does it differ from a version independent reference?
Lloyd McKenzie (Oct 04 2017 at 21:09):
[baseurl]/Condition/[id]/_version/[version] as opposed to [baseurl]/Condition/[id]
John Moehrke (Oct 04 2017 at 21:10):
so in MHD we use a CREATE Transaction of a Bundle (DocumentManifest that points at one or more DocumentReference which point at zero or more List, and where DocumentReference(s) point at equal Binary). Where all are to be created new. And All references would be to the non-version specific identity... Is this working as explained? Or are these version-specific? Is there a way to have a transaction that does do this version specific or not-version specific?
Grahame Grieve (Oct 04 2017 at 21:23):
I think that's the bit that's missing; all references within a transaction bundle are version specific, but there's no language to tell a server whether to make them version specific when processing the transaction or not
Grahame Grieve (Oct 04 2017 at 21:24):
partly that is because servers get to decide for themselves whether things are or aren't version specific - consistent with that, then, I would expect this to be resolved out of band - e.g. in an IHE profile
John Moehrke (Oct 04 2017 at 21:30):
Right. so this should be made more clear... And thus if someone wants the non-supported behavior they need to go to multiple transactions.. right? Or do you see a way to have bundle specific behavior, or even reference specific?
Grahame Grieve (Oct 04 2017 at 21:35):
well, there's always extensions.
Grahame Grieve (Oct 04 2017 at 21:36):
but IHE should be ok with just fixing it in the profile?
John Moehrke (Oct 04 2017 at 21:38):
so, within IHE we are okay defining that it is to be not version specific. I think that is what we want in MHD... should be fun discusion
Grahame Grieve (Oct 04 2017 at 21:48):
binary references can always be non-version specific. When would you want version specific references?
Grahame Grieve (Oct 04 2017 at 21:48):
but this does make me realise that I should disable updates for binary resources... maybe
Elliot Silver (Oct 04 2017 at 22:15):
all references within a transaction bundle are version specific
Where is that documented?
I found (http://build.fhir.org/http.html#transaction)
Version-specific references should remain as version-specific references after the references have been updated.
But I'm not sure what a version specific-reference to a new resource would look like before the update.
Grahame Grieve (Oct 04 2017 at 22:25):
I don't know
Elliot Silver (Oct 04 2017 at 22:29):
This is actually wider than I thought -- it doesn't just apply to references to new resource, it could also apply to a bundle containing a resource with reference to another resource being updated in the transaction.
Grahame Grieve (Oct 04 2017 at 22:33):
that's where we know the answer about the difference in the references
Elliot Silver (Oct 04 2017 at 23:04):
John Moehrke (Oct 04 2017 at 23:06):
This seems only needing clarity when the reference is to another resource being created in the same bundle. right?
Elliot Silver (Oct 04 2017 at 23:07):
Is there another case? I think the issue is when we don't know the id and/or version id of the object being created/updated. If it wasn't in the same bundle, we'd know it.
Last updated: Apr 12 2022 at 19:14 UTC
