Dennis Patterson

Noting that this came up on Zulip - https://chat.fhir.org/#narrow/stream/179159-cds-hooks/topic/Client.20side.20pre-conditions

Zulip conversation - https://chat.fhir.org/#narrow/stream/179159-cds-hooks/topic/Specifying.20the.20FHIR.20version

A year later, this discussion came up again at the May 2021 Virtual Connectathon. :) Services are handling this by setting up separate base urls devoted to a specific version...

This came up again on Zulip for Precondition Failed - https://chat.fhir.org/#narrow/stream/179159-cds-hooks/topic/Precondition.20Failed

In that example of multiple adjustments to a single rx, I'd agree that those are distinct order-select hook events each deserving their own hookInstance. Since the question here is around...

Note that this is referring to scenarios where the suggested update is to a persisted resource, not a scratch pad or otherwise in-memory resource that is not yet persisted.

Note that the example was added, but does not follow the above format and rather only lists the FHIR reference - https://github.com/cds-hooks/docs/commit/052825b5f8b63385300eb8f2a9cc4792ad7082bc . From reading the spec history, I think...

To elaborate on my thoughts above, one non-breaking way to approach this is to change Action into more of a parent object, with sub objects defining their own schema. **suggestion.actions**...

implementers already do this kind of flexing today with FHIR's resourceType. You look at the resourceType to know which model to parse. Here you look at the action type

At least for this case, the flexibility is already built-in, but definitely confusing as-is. If we want to make a breaking change to have deletes be an object, we'll need...