Stream: implementers
Topic: conditional updates and temporary ids
Brian Reinhold (Jul 09 2018 at 23:44):
Masters of the FHIR spec,
Is it okay to use temporary logical ids in a conditional update transaction in a transaction bundle? Its been a while since I looked at this and I think at the time I first looked at conditional updates temporary ids were not in plain sight yet.
The reason is that we have a concern that some servers might not like the client to specify the logical ids. But I suppose if the allow conditional updates they must also support updates?
On a related note, if I do a conditional create in a transaction bundle (where I have to use a temporary id since I have references to the resource in the transaction bundle, will I be able to send a second transaction bundle with a conditional create for the same resource and have the logical ids consistent. That is confusing.
Example
I create a Patient resource using a conditional create. It has a temporary id. All the Observation resources in the Bundle reference that Patient resource using the temporary id. At some later time, I send a similar bundle with a conditional create on the SAME Patient resource and once again use a temporary id. Now all the new Observation resources in the Bundle reference that temporary id. When the second Bundle gets uploaded to the Server, will all the Observation resources point to the same Patient resource as the first set?
Why this pain? Consider a FHIR generator which knows nothing about the server and has no contact with the server. All it does is map some data to FHIR (perhaps measurement data from a Personal Health Device) and send it off to some other module that actually uploads it.
Thanks for any input on this!
Grahame Grieve (Jul 10 2018 at 22:12):
I think that conditional creates have to work like this. I don't have time to check test.fhir.org to see that is does, but isn't the documentation clear about this?
Grahame Grieve (Jul 10 2018 at 22:12):
well, I think it is, but only by implication. you could create a task to make it more explicit
Christiaan Knaap (Jul 12 2018 at 08:18):
I have assembled an example of this in the attached file.
The requests in the file can be executed with VSCode and the REST Client extension. conditionalCreateTransactions.html
Angus Millar (Jul 13 2018 at 07:04):
I struggle to see how this example is ever a good idea. I feel the reference from the Observation to the Patient in the transaction bundle should be done with the FullUrl's urn:uuid and not as a search reference. The reason is, as a server, I must process the ifNoneExist of the Patient resource against my database. If that is False (it exists) then the Observation's search reference will also be true and all if fine. Yet if it is True (it does not exist) I am to assign my own Resource ID for the Patient and POST it I now have to somehow search the transaction bundle to work out what the Observation reference points to. There might be many Patient resources in the bundle and any number of search parameters on the Observation reference. I do not have the raw transaction bundle indexed and therefore the search within it is difficult. @Christiaan Knaap , how do you handle that first transaction when the Patient resource is not in the database as yet, ifNoneExist = True, how do you work out what the Observation reference points to in the bundle. Have you implemented search for non-database indexed resources? Not impossible but just more work. I feel it is pointless as the client could just use the FullUrl's urn:uuid to reference between the bundle's resources. The FullUrl's urn:uuid don't need to match across bundles they are only relevant within the bundle instance. I have no problem with Search references but not when they are mixed with, or point to, Resources that are not indexed in the database. I can see i'm going to have to build a whole new search indexer in memory to search on bundles.
Christiaan Knaap (Jul 16 2018 at 07:12):
I did not intend to say that this was the best way of solving it, but it is valid.
Referencing the fullUrl is indeed easier to process by the server.
That being said|: If you are running on a true transactional database, you should be able to index & search entries from the transaction that you processed already in the database as normal, since they should be in the same transaction.
Vonk is indeed also capable of mixing in-memory indexing / searching with database indexing / searching, but that is only really needed if you try to create / update data within a (SMART) Patient scope.
Angus Millar (Jul 17 2018 at 00:40):
Thanks, Christiaan, you are correct in regard to the transactional database comment, my mistake. My apologies I did not mean to accuse in regard to the example, it was my frustration with the problem coming through. Thank you for your reply it has set me straight.
Last updated: Apr 12 2022 at 19:14 UTC
