cds-hooks
Clarify expectations around handling multiple updates
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
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.
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.