FHIR Chat · docs / Issue #119 Move CDS Service request parameters pat... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #119 Move CDS Service request parameters pat...

---

Github Notifications (Nov 21 2017 at 23:16):

kpshek milestoned Issue #119

Github Notifications (Nov 21 2017 at 23:16):

kpshek opened Issue #119

Today, the patient and encounter parameters are defined in the request to the CDS Service. However, what if we have hooks that:

• Do not have a patient in context. For instance, consider a hook ehr-launch that is invoked as soon as the user launches the EHR application.

• Have more than one patient in context. For instance, consider a hook patientlist-view that is invoked when the user is viewing their patient list.

In both of these scenarios, that current location of our patient and encounter parameters is not optimal. Either the parameters are null (or not set) or they are not set and instead superseded by a more appropriate parameter in the context in the CDS Service request.

The proposal to address this would be to remove patient and encounter from the CDS Service request and instead place these as parameters in the context object when appropriate for a given hook. For the three hooks we've defined and implemented today (patient-view, medication-prescribe, order-review), they would all include patient and encounter.

In offline discussion with @brynrhodes and @isaacvetter, we all agreed this would be a good change to make for 1.0. While this is technically a breaking change, it will serve us better down the road as we start implementing and supporting new hooks in which there is no patient or no single patient in context. Additionally, this is a minor change as we're simply just moving where in the JSON structure these parameters are read.

Given that it is a breaking change, we would appreciate thoughts from the rest of the community.

Github Notifications (Nov 22 2017 at 00:27):

kensaku-kawamoto commented on Issue #119

I think it's a reasonable change and a good idea.

Github Notifications (Nov 22 2017 at 00:37):

grahamegrieve commented on Issue #119

so to be clear, this is a significant change because you are replacing the ids of the these things with the whole resource. That's.... potentially significant. I'm making sure that this is clear

I'm in favor of this change. It works for my existing use cases, that include some where patient and encounter are not in context, and some where they are

Github Notifications (Nov 22 2017 at 00:44):

kpshek commented on Issue #119

so to be clear, this is a significant change because you are replacing the ids of the these things with the whole resource. That's.... potentially significant. I'm making sure that this is clear

That is not what I'm proposing. Both the patient and encounter parameters would continue to just be the ids still.

Github Notifications (Nov 22 2017 at 01:06):

brynrhodes commented on Issue #119

so to be clear, this is a significant change because you are replacing the ids of the these things with the whole resource. That's.... potentially significant. I'm making sure that this is clear

It would depend on the hook though, right? A hook could define the patient parameter as the resource, or it could define it as a patientId parameter. I see that as another advantage of this approach, it would be up to the hook to specify what it would actually provide.

Github Notifications (Nov 22 2017 at 01:08):

kpshek commented on Issue #119

Correct, each hook defines the context object as it sees fit. However, we're not proposing we start sending the full Patient and Encounter resource in place of the ids we're sending today. For the 3 hooks we've defined today, it would continue to be ids.

Github Notifications (Nov 22 2017 at 01:47):

grahamegrieve commented on Issue #119

That is not what I'm proposing

but context is an array of resources....

Github Notifications (Nov 22 2017 at 02:33):

jmandel commented on Issue #119

Not if we land#39 appropriately -- which I think is increasingly critical if we make sense the change proposed here. Doing this change without #39 would be very messy.

Github Notifications (Nov 22 2017 at 03:08):

grahamegrieve commented on Issue #119

really? that's not evident to me from the description of #39

Github Notifications (Nov 22 2017 at 08:04):

kpshek commented on Issue #119

but context is an array of resources....

Today, we document it as "Hook-specific contextual data that the CDS service will need". #39 is going to clearly define how a new hook is defined. Related to this, context is an object with keys/values specific to each individual hook. From an earlier comment from me on #39:

From some Zulip discussion on this issue, we're proposing that context is always a JSON object. Furthermore, context is defined per hook which each hook defining the individual keys and values (both the JSON value type and the content) within the context JSON object.

Github Notifications (Nov 23 2017 at 15:43):

WWie commented on Issue #119

I am in favor of that change. The patient and encounter Ids are indeed context but not always part of the active context. Putting them in the context object as optional makes sense. And putting more work into defining what context objects are and where they are well-defined vs. customizable will go a long way making this framework more robust.

We are looking into various scenarios where we would want to invoke a hook where the context would be a "class of patients", e.g. "Any patient with diagnosis X , Y or Z and age between 50 and 75". Having to still put a value into a high-level attribute like patient or encounter would make it a bit awkward to use. So would having to ignore a high-level parameter in the hook call.

Github Notifications (Jan 22 2018 at 16:05):

robs16 commented on Issue #119

How does this interact with the prefetch requirements for a Patient.id replacement? I mean if you are going down the road of these items being part of the context (and I think that might be reasonable), it seems that the prefetch replacements need to be defined somewhat dynamically.

Github Notifications (Jan 29 2018 at 15:46):

kpshek assigned Issue #119

Github Notifications (Jan 29 2018 at 15:47):

kpshek commented on Issue #119

This issue has been addressed by PR #109 and #153

Github Notifications (Jan 29 2018 at 15:47):

kpshek closed Issue #119

---

Last updated: Apr 12 2022 at 19:14 UTC