Stream: cds hooks/github
Topic: docs / Issue #102 Feedback on Decisions
Github Notifications (Oct 05 2017 at 22:49):
stefan-evinance opened Issue #102
There are two parts to the question of sending CDS decisions to an EHR: communicating to web-based EHR that decisions are available & sending the actual FHIR resources.
1. notifying EHR that interaction is complete
- redirect: this is the current implementation. Pro: it's very simple to implement. Against: doesn't cover use cases which require the CDS Service page to remain open while decision is communicated.
- JavaScript Window.postMessage(): this was a proposal circulating in the CDSHooks group before (not sure if it's still considered). Pro: CDS Service page can remain open. Against: CDS Service needs to know about parent web page origin, thus hard to integrate. I don't support this approach.
- HTTP POST to EHR endpoint provided in initiating CDSHooks call: this will be the best approach from our point of view, resources are not send with this notification (may not be available). Pro: fully transparent to the user, generic & easy to implement. Against: request must be send by CDS Service backend, if attempting to send request from JavaScript will result CORS issues and CORS configuration can be very tricky for EHR working with multiple CDS Services.2. sending FHIR resources back to EHR
- Second POST to CDSHooks Service: this is the current implementation, we do not agree with this approach.
- POST to FHIR server: this is what we do with some EHRs. Pro: infrastructure exists; Against: can't notify EHR that resources were posted, EHR may not want the resources to be automatically stored in FHIR server without user interaction.
- POST to another EHR endpoint defined in CDSHooks call: Pro: gives EHR control on handling CDS Service resources. Against: Opens Pandora's box on authentication with EHR.If you are considering a single EHR endpoint to replace both the current redirect & the current second POST, I don't think it is a good idea for 3 reasons:
1) Sending resources to EHR requires authentication. We already have FHIR authentication, may be we can just POST to the FHIR server (as we currently do with some EHRs).
2) Resources may not be immediately available upon completing the CDS Service interaction. That's why we need two communication mechanisms (previously: redirect+POST, now: POST+POST).
3) Some open CORS may be acceptable (for example: simple notification POST from JavaScript to EHR with no data) but if we are dealing with resources then configuring CORS correctly is much more important (and difficult).
Github Notifications (Oct 06 2017 at 17:33):
isaacvetter commented on Issue #102
Hey stefan-evinance,
Another advantage to web messaging is that it significantly simplifies the need to open firewalls. It's not always clear that a cds service will be able to access a FHIR server, let alone the non-FHIR CDS Hooks endpoints that you're creating, above. For example, see #82.
Further, the "in-memory" content that a cds service is interested in providing guidance on in the user's workflow typically aren't yet committed to the database from which FHIR resources are served.
Can you provide additional, compelling points to back up your stated preferences?
Against: CDS Service needs to know about parent web page origin, thus hard to integrate. I don't support this approach.
Second POST to CDSHooks Service: this is the current implementation, we do not agree with this approach.
Isaac
Github Notifications (Nov 19 2017 at 19:52):
kpshek labeled Issue #102
Github Notifications (Nov 19 2017 at 19:53):
kpshek commented on Issue #102
Thanks for the well thought out and detailed feedback @stefan-evinance!
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:53):
kpshek closed Issue #102
Last updated: Apr 12 2022 at 19:14 UTC
