Stream: implementers
Topic: Handling an unused resource
Brian Reinhold (Aug 21 2018 at 19:50):
I suppose there is no good answer to this problem but I have a situation where a transaction Bundle contains several resources using conditional create transactions. These resources reference another resource using a create transaction. Now it could be that all of the conditional creates are handled using a 200 (not a 201) meaning the resource is already present and no change to that resource is made. This leaves the resource using the create transaction. Since all the other resources did not get created, I would like to avoid uploading this resource since it will serve no purpose.
One might quickly say how can the conditional creates not create new resources since the reference to this other resource has to be different? So there is no way this should arise. Well, that all depends upon the conditional create 'condition'! The reference is not part of what is being used to identify the conditional create.
For those that have to fortitude to read on, here is the actual case:
The resources being uploaded using conditional creates are Observations from a Personal Health Device (PHD). PHDs can be naughty and send old data repeatedly. The conditional create assures previously uploaded data is not made into a new resource. However, these resources also reference a special Observation called the Coincident Time Stamp Observation. PHDs can also be very bad about having good time. So the NTP synchronized gateway corrects the time stamps based upon the difference between the current time of the PHD and that of the Gateway. This coincident time stamp is referenced by the measurement Observation.
If the upload is done later and the PHD sends the same data again, the coincident time stamp resource will be different because it is taken at a different time. However, the difference will not be. So the reference to the coincident time stamp is not included in what defines the measurement. Thus the conditional create will stop the duplicate measurements, but the coincident time stamp will be new and it will be created. The downside is that it will not be referenced by anything and by itself it serves no purpose. I would like it NOT to be created (without having to look at the response).
If anyone has some ideas on how to solve this, I would be most appreciative!
Grahame Grieve (Aug 21 2018 at 20:46):
umm, isn't that Bundle.timestamp?
Brian Reinhold (Aug 21 2018 at 20:51):
umm, isn't that Bundle.timestamp?
@Grahame Grieve Not sure how the time stamp of the Bundle will help. What I would like to tell the server is that if none of the resources in the Bundle reference the 'coincident time stamp' resource, don't create it. But I am sure that is not possible. So I need to figure out another way to accomplish it.
Grahame Grieve (Aug 21 2018 at 21:09):
I don't understand. if none of the reference it, don't put it in there?
Brian Reinhold (Aug 21 2018 at 21:58):
I don't understand. if none of the reference it, don't put it in there?
@Grahame Grieve It's a conditional create for the measurement Observation resources . I do not know if the resource already exists on the server. If it does not exist, the resource will be created. Then the coincident time stamp resource WILL be useful. A possible solution that is difficult to implement on a low-end remote gateway is to get the response from the upload. If all the measurement resources return with a 200, then the coincident time stamp resource can be deleted (if one has the permission to delete the resource). A 201 on the other hand, means leave the coincident time stamp resource on the server.
Grahame Grieve (Aug 21 2018 at 22:04):
not sure I follow... if none of the resources in the Bundle reference the 'coincident time stamp' resource, don't put it in the bundle
Last updated: Apr 12 2022 at 19:14 UTC
