FHIR Chat · docs / PR #58 Constrain prefetch semantics and functional...

Stream: cds hooks/committers

Topic: docs / PR #58 Constrain prefetch semantics and functional...

Github Notifications (Jul 26 2017 at 05:49):

kpshek edited PR #58
from iss47-constrain-prefetch to master

Adds restrictions to the allowed prefetch queries to reduce EHR implementer burden and align with the DataRequirement of FHIR Clinical Reasoning.

This pull request addresses issue #47.

Github Notifications (Jul 27 2017 at 01:56):

kpshek commented on PR #58

@brynrhodes - Can you clarify the restrictions further? For example:

What does "instance level read interactions" mean? I'm guessing this read in FHIR? If my understand of that is correct, what does the further qualification of "for the Patient resource only" mean?

Does "type level search interactions" only mean search and not create or history? Why is GET called out? The EHR can satisfy the prefetch data however it sees fit and I'm not sure what GET vs POST would mean

Are these similar restrictions defined similar to how you have documented then here somewhere in Clinical Reasoning? If so, where?

My questions here are just an attempt to ensure that I and everyone else understands very clearly what we're proposing is & isn't allowed in prefetch queries.

Github Notifications (Jul 27 2017 at 02:08):

grahamegrieve commented on PR #58

I don't think these restrictions should be global. There might not even be a patient in context. More generally, what is most effective varies widely by context. There might not be the possibility for the cds-hooks server to pull further information from the EHR at all, for instance.

I'm not opposed to being able to make - or even recommend - these restrictions (though they need more clarity as Kevin says) but they can't be applied always

Github Notifications (Jul 27 2017 at 16:13):

brynrhodes synchronized PR #58

Github Notifications (Jul 27 2017 at 16:19):

brynrhodes commented on PR #58

@kpshek, yes, I'm thinking of the "read" and "search" interactions. I was trying to describe them in terms of the HTTP level FHIR API only, so that was the reason for the reference to GET, but after reading your updates to the prefetch on the other pull, I agree, and I've removed the references to HTTP verbs.

I've also expanded the Patient request to include resource for which an id is known (so it could include Practitioner or Encounter, for example).

As far as documentation about how these restrictions are used within Clinical Reasoning, there is documentation on the DataRequirement, are you thinking a link there would be helpful?

@grahamegrieve, agreed, I've relaxed the language to make them 'recommended', rather than 'required'.