FHIR Chat · docs / PR #62 Clarify prefetch expectations and documenta... · cds hooks/committers

Stream: cds hooks/committers

Topic: docs / PR #62 Clarify prefetch expectations and documenta...


view this post on Zulip Github Notifications (Jul 26 2017 at 05:52):

kpshek edited PR #62(assigned to mattberther)
from issue5-Prefetch-is-optional to master

pre-fetch is a request, not a requirement and can be partially fulfilled.

Requested prefetch information may not always be supplied to the service
and may be partially supplied -- in which case, the CDS service should
query the EHR's FHIR service for the missing data.

The EHR will not expose internal errors to the FHIR server.

Fixes #5

view this post on Zulip Github Notifications (Jul 26 2017 at 23:45):

kpshek synchronized PR #62

view this post on Zulip Github Notifications (Jul 27 2017 at 00:21):

kpshek synchronized PR #62

view this post on Zulip Github Notifications (Jul 27 2017 at 00:21):

kpshek review_requested PR #62

view this post on Zulip Github Notifications (Jul 27 2017 at 00:22):

kpshek review_requested PR #62

view this post on Zulip Github Notifications (Jul 27 2017 at 00:25):

kpshek commented on PR #62

@Isaac Vetter, @mattberther, and @brynrhodes --

I wanted to add even further clarifications and details to our prefetch documentation to make it even more explicit. Rather than asking for @Isaac Vetter to make further changes, I thought it'd be easier to propose some additions myself. I've updated this PR with those changes in d2157a5. Please re-review these changes.

Isaac - since you're the author on this PR I could not add you as a reviewer so please just comment here if you approve these additional changes.

view this post on Zulip Github Notifications (Jul 27 2017 at 00:26):

kpshek review_requested PR #62

view this post on Zulip Github Notifications (Jul 27 2017 at 02:00):

grahamegrieve commented on PR #62

There are plenty of situations where there won't be any possibility for the cds-hooks server to make further requests of the EHR server. the documentation/introspection for a service or maybe the hook defnition should be able to make it clear somewhere that failing to provide the pre-fetch will result in no service being provided

view this post on Zulip Github Notifications (Jul 27 2017 at 02:32):

isaacvetter commented on PR #62

Hey @grahamegrieve - what are the situations where it isn't possible for the CDS Hooks service to make follow-up requests to the FHIR server?
1. Will the "EHR server" know ahead of time that it won't be capable of responding to these requests?
1. I think that the CDS Hooks scope of synchronous, real-time queries will discourage complex network architectures, such as proxies.

view this post on Zulip Github Notifications (Jul 27 2017 at 02:40):

isaacvetter commented on PR #62

@kpshek - with the exception of Grahame's above feedback, I think that your modifications are overall an improvement. Looks good.

view this post on Zulip Github Notifications (Jul 27 2017 at 02:42):

grahamegrieve commented on PR #62

well, in the case we are working up in Australia, the EHR asks a diagnostic service to comment to the user on the proposed diagnostic service tests. There will be no business arrangement for the diagnostic service to have access back to the EHR (it's technically possible to set it up, but not feasible in practice). So I guess the EHR knows that this is the case ahead of time - by onfiguration, presumably. And i think that the things that cds-hooks can do will make it really compelling to use in spite of complex network topographies, and circumstances where lack of trust is a real impediment to work

view this post on Zulip Github Notifications (Aug 09 2017 at 18:31):

kpshek commented on PR #62

@grahamegrieve - Let us know if you'd like any other clarifications or want to discuss your use case further. If so, let's open a new issue for that.

view this post on Zulip Github Notifications (Aug 09 2017 at 18:31):

kpshek closed PR #62


Last updated: Apr 12 2022 at 19:14 UTC