Stream: cds hooks/github
Topic: docs / Issue #99 Remove Decisions for the 1.0 release
Github Notifications (Sep 19 2017 at 18:49):
kpshek milestoned Issue #99
Github Notifications (Sep 19 2017 at 18:49):
kpshek assigned Issue #99
Github Notifications (Sep 19 2017 at 18:49):
kpshek opened Issue #99(assigned to kpshek)
Based upon a lack of broad implementer feedback and due to the number of outstanding issues around Decisions, a consensus was reached last week in San Diego that Decisions will not be included in the 1.0 release.
Decisions are an important feature of CDS Hooks that we will want maintain. To include this in CDS Hooks, it is imperative that we receive broad implementer feedback on this feature and thus far, we have not seen this. Additionally, we need to address many, if not all of the outstanding issues that have been logged against Decisions.
Our plan is to circle back on Decisions after 1.0 and include it in a subsequent release of CDS Hooks.
Github Notifications (Oct 12 2017 at 13:59):
tirithen commented on Issue #99
I have worked on a project where we tried this a bit. Worth noting is that while we use CDS Hooks API structure we do not structure our clinical data with FHIR but as a JSON representation of openEHR archetypes. The spontaneous feeling us as a CDS vendor was that we would have preferred that all data persistence was done in the EHR (I would assume FHIR server in your case?).
If the CDS apps could send decisions with HTTPS to the EHR system the CDS systems could be kept stateless. They would then be re-initiated with the same hookInstance as previous session and continue from there.
To me, since the decisions originates from the app, and the CDS service only returns an app link card, the CDS service does not need to know about any decisions that would be made in the app (for us they runs as separate docker containers anyway). Also you could have two CDS services that both returns a link to the same app, that to me makes it even more clear that the decision would belong to the app and that it would be useful if the app could send the decision to the EHR. Else possibly store them in one single decision storage service that would take store all decisions until someone fetches them but that adds complexity about for how long they should be stored before they are cleaned out to prevent clinical data from just building up inside systems that is external from the EHR.
Github Notifications (Nov 19 2017 at 19:25):
Thanks for the feedback @tirithen!
I think decisions are an important feature and it is encouraging to hear that you have been exploring them in your environment. Thanks for your thoughts on decisions and when we swing back on this topic in a subsequent release, it would be great to get your feedback then too.
Github Notifications (Nov 21 2017 at 12:14):
kpshek closed Issue #99
Last updated: Apr 12 2022 at 19:14 UTC
