Stream: cds hooks/github
Topic: docs / Issue #398 Clarify expectations around handling mu...
Github Notifications (Aug 09 2018 at 17:32):
lmckenzi opened Issue #398
In some cases different services will provide cards that recommend updating the same resource instance. E.g. changing a dose, adding a coverage, adding a link to a clinical trial. The specification should make explicit that clients should detect this and manage the resulting collision - ideally by 'merging' the related updates. The client will also have to handle merging (or more likely regenerating) narrative to reflect the union of the accepted changes.
Also see: https://chat.fhir.org/#narrow/stream/17-cds-hooks/subject/Collisions.20from.20multiple.20updates
Github Notifications (Aug 13 2018 at 11:49):
robs16 commented on Issue #398
Interesting can of worms... There will be cases where service A runs before service B and they could conflict on the same field. Would it be better to provide the entire existing resource with changes applied in the update, or just the id/version and the updated fields? Does the first one win, and the second must be re-run? A similar issue may happen with concurrent EMR updates.
It seems to me this may be integration specific, but it would be good to at least discuss it in the spec and provide any best practices. I have the feeling that merging narratives are not really possible in any sane way without significant specialized integration work.
Github Notifications (Aug 13 2018 at 14:17):
lmckenzi commented on Issue #398
In theory, the confllict doesn't occur until the user applies the suggestion - and the user could do that in any order whatsoever. One possibility is that as soon as a user selects an update, you rerun all of the services, so they're starting from a new set of cards that are based on the new version.
Last updated: Apr 12 2022 at 19:14 UTC
