Stream: cds hooks/github
Topic: docs / Issue #57 Clarity on nested decision structure
Github Notifications (Jul 13 2017 at 19:57):
bkaney opened Issue #57
The documentation on the decision structure is somewhat lacking. And I think needs to be advanced a bit, as we are attempting to implement this right now.
## Delete Case
In the case the decision indicates an item to be deleted, it makes sense to have the value be a string identifier.## Create Case
In the create case, the resource doesn't yet exist. Using an identifier could be confusing and also implies that the CDS service would have to host this resource. It is more convenient if the resource to be created is inlined within the decision payload (similar to how this happens with the context).## Proposal
Don't changedelete
, continue to specify an array of strings. These identifiers are existing FHIR resources on the specified fhir-server (from the initial service call).Change
create
to be an array of (inlined) objects (e.g. FHIR resources).
Github Notifications (Jul 13 2017 at 19:57):
bkaney edited Issue #57
The documentation on the decision structure is somewhat lacking. And I think needs to be advanced a bit, as we are attempting to implement this right now.
## Delete Case
In the case the decision indicates an item to be deleted, it makes sense to have the value be a string identifier.## Create Case
In the create case, the resource doesn't yet exist. Using an identifier could be confusing and also implies that the CDS service would have to host this resource. It is more convenient if the resource to be created is inlined within the decision payload (similar to how this happens with the context).## Proposal
Don't changedelete
, continue to specify an array of strings. These identifiers are existing FHIR resources on the specified fhir-server (from the initial service call).Change
create
to be an array of (inlined) objects (e.g. FHIR resources) instead of strings.
Github Notifications (Nov 19 2017 at 19:46):
kpshek labeled Issue #57
Github Notifications (Nov 19 2017 at 19:50):
Thanks for the well thought out feedback @bkaney.
At the Sept 2017 San Diego Connectathon, the community reached consensus to remove decisions for the 1.0 release (#99) until we obtain more implementer feedback. I think the questions you pose here are further indication that the decisions feature needs quite a bit of further thought, implementation feedback, and documentation.
We will swing back on the decisions feature on a subsequent release. As such, I'm closing this issue with a _deferred_ label.
Github Notifications (Nov 19 2017 at 19:50):
kpshek closed Issue #57
Last updated: Apr 12 2022 at 19:14 UTC