Stream: cds hooks/github
Topic: docs / Issue #80 State keeping
Github Notifications (Sep 08 2017 at 16:18):
bvdh edited Issue #80
In the section "CDS Decisions" it is stated that "To return a decision after a user interaction, the CDS service must maintain state associated with the request’s hookInstance; when the EHR invokes the hook for a second time with the same hookInstance, the service can respond with decisions on as well as cards".
To my knowledge this is not the typical behavior when calling webservices.
Preferably one would have the CDS services stateless and store the state in the EHR application. When it invokes the service, it will pass the state. This prevents a lot of (difficult) bookkeeping in the services (such as determining when how long a state should be maintained).Suggested change:
Preferably one would have the CDS services stateless and store the state in the EHR application. Can’t we have the CDS Service pass a optional “opaque” state object when it redirects back to the EHR. The EHR then appends this object to the CDS Service request. Thereby passing the state.
Github Notifications (Sep 08 2017 at 17:59):
grahamegrieve commented on Issue #80
For me personally, this would equate to the server making up the identifier for the state, not the client.
Github Notifications (Sep 09 2017 at 14:37):
This state could be very large depending on the needs of the service. The issue of how long it must be maintained is still a problem, just shifted to the EMR. The state definition could also change over time, making updates of the service much more difficult.
Github Notifications (Sep 12 2017 at 15:25):
From my point of view, the EHR maintains the current session. So it also knows when state is no longer relevant.
Github Notifications (Sep 12 2017 at 16:36):
I see your point for a simple service. As long as statefull is also supported, it works for me. The service provider would have to figure out which model works best for their need.
You would also have to pass the state in both directions for analytic endpoints.
Github Notifications (Sep 12 2017 at 18:02):
brynrhodes labeled Issue #80
Github Notifications (Sep 12 2017 at 19:05):
Per discussion at the Sept WGM (Tue Q2), we will defer this issue given that Decisions are not making the pending 1.0 release (TODO: Kevin to add more details on this as an update to the comment)
Github Notifications (Nov 26 2017 at 15:06):
Thanks for the feedback on decisions, @bvdh.
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 26 2017 at 15:06):
kpshek closed Issue #80
Github Notifications (Nov 26 2017 at 15:07):
kpshek labeled Issue #80
Last updated: Apr 12 2022 at 19:14 UTC
