FHIR Chat · docs / Issue #157 HTTP Response status in the prefetch do... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #157 HTTP Response status in the prefetch do...

---

Github Notifications (Jan 28 2018 at 18:29):

mattvarghese opened Issue #157

Specifically this property on prefetch properties

      "response": {
        "status": "200 OK"
      },

Based on this sentence, the value of this property can only ever be 200 OK

Additionally, if the EHR encounters an error while prefetching any data, the prefetch template key SHOULD NOT be sent to the CDS Service.

At the same time, there may not even be an HTTP request and therefore any HTTP status associated with a prefetch based on this sentence

The EHR may satisfy some of the desired prefetched templates via some internal service or even its own FHIR server

So, should this be retained in the spec, or should it be removed? If it is retained, we need to reconcile the other sentences cited to not make a contradiction.

Github Notifications (Jan 28 2018 at 20:58):

kpshek milestoned Issue #157

Github Notifications (Jan 31 2018 at 17:35):

euvitudo commented on Issue #157

Agree with @mattvarghese. My thought is that it would be useful to retain the status (and augment the possible values, or simply rely on the standard set of HTTP statuses. At some point the service will need to determine whether to call out to the FHIR server for required(?) resource (provided fhirAuthorization is included) or to return an error (or otherwise?) indicating that it cannot proceed without the resource; or attempt to proceed without the resource.

Github Notifications (Jan 31 2018 at 17:44):

kpshek commented on Issue #157

I think this is a reasonable change too. I would be curious to hear an differing opinions here, but I think the fact that prefetch data can be satisfied by a means other than FHIR makes having the response structure odd.

@jmandel - any objections?

Github Notifications (Jan 31 2018 at 17:48):

jmandel commented on Issue #157

The reasons this was originally here was to enable easy slotting of Bundle.entry values into prefetch responses. If we do eliminate this, would we want to kill the whole "response" field and then collapse "resource" up a node in the tree? In other words:

### Move from

   "prefetch" : {
      "patientToGreet" : {
         "response" : {
            "status" : "200 OK"
         },
         "resource" : {
            "resourceType" : "Patient",
            "gender" : "male",
            "birthDate" : "1925-12-23",
            "id" : "1288992",
            "active" : true
         }
      }
   }

### To

   "prefetch" : {
      "patientToGreet" : {
            "resourceType" : "Patient",
            "gender" : "male",
            "birthDate" : "1925-12-23",
            "id" : "1288992",
            "active" : true
      }
   }

Github Notifications (Jan 31 2018 at 17:51):

brynrhodes commented on Issue #157

Agree that would be simpler, but I think we might be losing the ability to say "This prefetch key has no data", which I think is a useful thing to say.

Github Notifications (Jan 31 2018 at 17:54):

kpshek commented on Issue #157

Agree that would be simpler, but I think we might be losing the ability to say "This prefetch key has no data", which I think is a useful thing to say.

If the EHR attempted the prefetch but there was no data, then the prefetch key can be present in the request with a value of an empty object. Eg:

"prefetch" : {
  "current-medications": {}
}

Github Notifications (Jan 31 2018 at 17:55):

euvitudo commented on Issue #157

@kpshek - regarding

...but I think the fact that prefetch data can be satisfied by a means other than FHIR...

from an implementer's point of view, I would rather support a single standard versus opening it up to anything under the sun. If the former, it tightens up the spec and makes it a more reasonable implementation. If the latter, then you should include a discussion regarding what a service should expect in prefetch data and how to convey that in the cds-services metadata.

Github Notifications (Jan 31 2018 at 17:55):

jmandel commented on Issue #157

So, in this example, presumably current-medications is an empty bundle...

Github Notifications (Jan 31 2018 at 17:57):

kpshek commented on Issue #157

@euvitudo - I left out a critical word. I meant to say:

...but I think the fact that prefetch data can be satisfied by a means other than FHIR server

For instance, the EHR may have the requested prefetch data locally in memory (FHIR format). In this case, there is no RESTful service being invoked to prefetch the requested data. This is why the response structure doesn't make as much sense.

Github Notifications (Jan 31 2018 at 17:59):

euvitudo commented on Issue #157

Regarding the current-medications field, why not more simply use a null? An empty object is not very useful, but a null (as ugly as they may be).

Regarding @brynrhodes' comment, it _would_ be useful to know when a prefetch value has no data (in one case the service doesn't need to attempt a retrieval from the FHIR server; or the fact that there are not data is meaningful to the service).

Github Notifications (Jan 31 2018 at 18:01):

kpshek commented on Issue #157

Regarding the current-medications field, why not more simply use a null?

I agree @euvitudo, that's a better choice than an empty object (it is far more simply for a CDS Service to reason about a null value than my proposal).

Github Notifications (Jan 31 2018 at 18:02):

jmandel commented on Issue #157

Whatever we do, I think we want it clear how to tell the difference among:

1. EHR did not run a prefetch on this parameter
2. EHR ran a prefetch and found a result
3. EHR ran a prefetch and found no match (note this shouldn't apply to search operations, which should successfully return empty bundles that would be conveyed as the response)
4. EHR rand a prefetch and encountered an error (e.g. if the service is asking to prefetch data it's not allowed to see; this is important to distinguish because it tells an app that shouldn't try to run this query on its own, after being invoked)

Is that correct? If so, @kpshek can you list how you're proposing each of these cases gets conveyed?

Github Notifications (Jan 31 2018 at 18:09):

euvitudo commented on Issue #157

On a more meta-note, I've always thought it strange that prefetch value type is Bundle.entry (not a Resource). It would be much more flexible to specify a prefetch value as an object that contains a prefetch status (as defined by the CDS Hooks spec) and, if applicable, a FHIR Resource.

Github Notifications (Jan 31 2018 at 18:10):

kpshek commented on Issue #157

1. EHR did not run a prefetch on this parameter

prefetch key is omitted from the request. We address this today in the spec with: "The CDS Service MUST NOT receive any prefetch template key that the EHR chooses not to satisfy."

2. EHR ran a prefetch and found a result

prefetch key exists with a valued object. We need to be clear on the data type (@euvitudo's comments agree)

3. EHR ran a prefetch and found no match (note this shouldn't apply to search operations, which should successfully return empty bundles that would be conveyed as the response)

prefetch key exists with a null object (@euvitudo's suggestion which I agree with).

4. EHR ran a prefetch and encountered an error (e.g. if the service is asking to prefetch data it's not allowed to see; this is important to distinguish because it tells an app that shouldn't try to run this query on its own, after being invoked)

prefetch key is omitted from the request. We address this in the current spec with "Additionally, if the EHR encounters an error while prefetching any data, the prefetch template key SHOULD NOT be sent to the CDS Service. It is the CDS Service's responsibility to check prefetched data against its template to determine what requests were satisfied (if any) and to manually retrieve any additional necessary data."

I don't see value in communicating any errors that occurred when attempting to prefetch the data. The error could be transient, could only apply to the EHR, or something else that doesn't matter to the CDS Service. At the end of the day, prefetch is optional and the CDS Service has to determine how it handles missing prefetch data by either:

• Returning a 412 ("If the CDS Service is unable to obtain required data because it cannot access the FHIR server and the request did not contain the necessary prefetch keys, the service SHALL respond with an HTTP 412 Precondition Failed status code.")
• Trying to fetch the data itself. Sure, it may fail again but the CDS Service has to try (if it really needs the data).

Github Notifications (Jan 31 2018 at 18:14):

jmandel commented on Issue #157

That's fine @kpshek; you're saying you don't need item 4 from my list. Your proposal above clearly distinguishes among 1/2/3. I'm happy with that, and if we go with this plan... I think we can collapse the resource node per my previous note:

   "prefetch" : {
      "patientToGreet" : {
            "resourceType" : "Patient",
            "gender" : "male",
      }
   }

@euvitudo are you okay with this? It doesn't quite satisfy your perspective that

It would be much more flexible to specify a prefetch value as an object that contains a prefetch status (as defined by the CDS Hooks spec) and, if applicable, a FHIR Resource.

Github Notifications (Jan 31 2018 at 18:21):

euvitudo commented on Issue #157

@jmandel - Agreed it doesn't satisfy the perspective regarding status, however I think I might be OK with it insofar as the specification indicates what each of the three conditions means.

The reason for that is that including the status is a bit of an optimization allowing the service to decide what do to per a given status, leaving the exclusion of such in the spec open to interpretation by each service.

At this point I'm not completely sure whether that helps or whether it complicates the implementation, but it does allow implementers to decide the approach per the given prefetch value (for better or for worse).

Github Notifications (Feb 02 2018 at 19:32):

mattvarghese edited Issue #157

Specifically this property on prefetch properties

      "response": {
        "status": "200 OK"
      },

Based on this sentence, the value of this property can only ever be 200 OK

Additionally, if the EHR encounters an error while prefetching any data, the prefetch template key SHOULD NOT be sent to the CDS Service.

At the same time, there may not even be an HTTP request and therefore any HTTP status associated with a prefetch based on this sentence

The EHR may satisfy some of the desired prefetched templates via some internal service or even its own FHIR server

So, should this be retained in the spec, or should it be removed? If it is retained, we need to reconcile the other sentences cited to not make a contradiction.

Github Notifications (Feb 21 2018 at 16:41):

isaacvetter assigned Issue #157

Github Notifications (Mar 15 2018 at 14:55):

isaacvetter commented on Issue #157

Hey Everybody,

Just created PR #176 to satisfy this issue. I think that it's pretty clearcut, based upon the above.

The only thing that I didn't do was provide a concrete example of a bull FHIR read. Given that (currently) our only two defined "prefetch variables" are {{User.Id}} and {{Patient.Id}} and that a null prefetch template only makes sense to be passed to the CDS service as part of a FHIR read, I'm at a loss to identify a realistic scenario when an EHR doesn't have a patient or practitioner resource for the current user or patient ... Any suggestions?

If not, I'll close this issue when the PR's merged.

Isaac

Github Notifications (Mar 15 2018 at 16:03):

kpshek closed Issue #157

Github Notifications (Mar 15 2018 at 18:47):

grahamegrieve commented on Issue #157

if you start thinking about using cds-hooks in the configuration part of an EHR, or outside an EHR altogether, then you can quickly come up with scenarios where the host doesn't have a patient or practitioner resource

---

Last updated: Apr 12 2022 at 19:14 UTC