FHIR Chat · docs / Issue #75 Context should be an Array or an Object · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #75 Context should be an Array or an Object

---

Github Notifications (Aug 11 2017 at 01:49):

grahamegrieve opened Issue #75

Some hooks require a set of resources be passed to the decision support service, so that it can evaluate a set of actions that are inter-related. For instance, order-review - many of the uses of this hook will relate to a set of orders e.g. the set of diagnostic requests proposed. The same applies to medications particularly, where clinicians - rightly - think of a single prescription that contains multiple medications, but FHIR (also rightly) treats this as a set of resources.

The context should be either an object or an array of objects, where each elemetn in the array is an object that has the same content as the object would have. The hook definition should define the cardinality of the context.

Github Notifications (Sep 09 2017 at 20:24):

kpshek commented on Issue #75

Context is an array of objects in our current implementation so we just have a bug in our current documentation. Thanks for raising this and I'll get it fixed today with a PR

Github Notifications (Sep 09 2017 at 20:24):

kpshek milestoned Issue #75

Github Notifications (Sep 09 2017 at 23:08):

jmandel commented on Issue #75

I think we're going to run into limitations with simple arrays. For example, let's imagine a future hook definition like reconcile-med-lists where two lists of medications will be passed into the service. Let's say List One includes: drug a, drug b; whereas List Two includes drug c, drug d.

If we just have a context array, the service will see:
[
{Prescription for drug a },
{Prescription for drug b },
{Prescription for drug c },
{Prescription for drug d }
]

... but it won't know which correspond to "List One" and which correspond to "List Two".

We can solve this by adding context parameter names as part of a hook definition like:

"context": [{
  "name": "list_one",
  "value": {Prescription resource for drug a}
}, {
  "name": "list_one",
  "value": {Prescription resource for drug b}
}, {
  "name": "list_two",
  "value": {Prescription resource for drug c}
}, {
  "name": "list_two",
  "value": {Prescription resource for drug d}
}, ]

Github Notifications (Sep 10 2017 at 13:49):

robs16 commented on Issue #75

@Josh Mandel I agree that the array is too limited. However I might take a page from the prefetch approach and use:

"context": {
  "list_one": {
    "response": {
      "status": "200 OK"
    },
    "resource": {
      "resourceType": "Bundle",
      "entry": [
        {"resource": {Prescription resource for drug a}},
        {"resource": {Prescription resource for drug b}}
      ]
    }
  },
  "list_two": {
    "response": {
      "status": "200 OK"
    },
    "resource": {
      "resourceType": "Bundle",
      "entry": [
        {"resource": {Prescription resource for drug c}},
        {"resource": {Prescription resource for drug d}}
      ]
    }
  }
}

Github Notifications (Sep 10 2017 at 14:11):

jmandel commented on Issue #75

Agreed @robs16! Agee discussion with you Alex, I think the cleanest thing to say is: context is an object whose properties are entirely specified in the hook definition.

Github Notifications (Sep 10 2017 at 16:10):

grahamegrieve commented on Issue #75

that's moving the deck chairs around... how is the hook definition going to say that?

Github Notifications (Sep 10 2017 at 18:42):

jmandel commented on Issue #75

I'd say that this approach is separating concerns between the generic spec and the hook-specific requirements. As for "how"... it could be prose, or a snippet of swagger (JSON schema), or whatever... We can be prescriptive on this point.

Github Notifications (Sep 10 2017 at 18:49):

isaacvetter commented on Issue #75

Hey @Josh Mandel,

At some point, the CDS Hooks community will start pumping out new hooks. For this reason, the process for defining a new hook, including specifying any required context, needs to be tightly defined.

Defining a minimal key/value pair as the structure of context seems like it's needed, otherwise, context format is going to be all over the board. I'd further suggest that we should not only define the structure ahead of time, but also provide guidelines for naming the keys and defining when resources are required.

Github Notifications (Sep 10 2017 at 18:52):

jmandel commented on Issue #75

Agreed @Isaac Vetter! I don't think this dissuades us from adopting the "hook-specified context" approach that @robs16 described above, right?

Github Notifications (Sep 10 2017 at 22:01):

bkaney commented on Issue #75

It would be nice if context were similar in schema/shape to resource in SMART, as we are finding it convienent to pass through. The data disparity requires more work in between.

Github Notifications (Sep 11 2017 at 01:13):

isaacvetter commented on Issue #75

Hey @bkaney ,

Are you using SMART's resource? If so, you'll be interested in this conversation.

Secondly, I don't think that SMART's launch parameters that specify a FHIR resource (patient, encounter, location, resource, etc) actually contain/include a full FHIR resource, rather they're just the resourceType/FhirId.

Isaac

Github Notifications (Sep 11 2017 at 11:13):

bkaney commented on Issue #75

Things are moving fast. And I didn't know resource wasn't able to be a full resource in SMART.

We are not quite there, but planning to implement over the next few weeks. Given this, I will not use it and see how else contextual launch information could be passed on.

Thanks!

Github Notifications (Sep 11 2017 at 13:27):

jmandel commented on Issue #75

As we work through the standardization process for smart, we will also clarify that launch context is extensible. It's OK to add details/parameters as needed (but if there's a standard way to accomplish your use case, that's clearly better).

Github Notifications (Sep 11 2017 at 13:43):

bkaney commented on Issue #75

@Josh Mandel right, I am thinking we will add a new key called context to the SMART launch_context, and have it pass what we get from CDS Hooks.

Github Notifications (Sep 19 2017 at 14:36):

bkaney commented on Issue #75

Re-reading this thread, and to summarize the proposal I think the idea is to advertise the context in the service definition (following the pattern we have for prefetch), like this:

{
  "hook": "medication-prescribe",
  "title": "Medication Foo Service",
  "id": "medication-foo",
  "context": {
    "list_one": "MedicationRequest?patient={{Patient.id}}&code=285018",
    "list_two": "MedicationRequest?patient={{Patient.id}}&code=1594660"
  }
}

Then when calling the service, include the resources, like this:

"context": {
  "list_one": {
    "response": {
      "status": "200 OK"
    },
    "resource": {
      "resourceType": "Bundle",
      "entry": [
        {"resource": {MedRequest resource for drug a, date 1}},
        {"resource": {MedRequest resource for drug a, date 2}}
      ]
    }
  },
  "list_two": {
    "response": {
      "status": "200 OK"
    },
    "resource": {
      "resourceType": "Bundle",
      "entry": [
        {"resource": {MedRequest resource for drug b, date 3}}
      ]
    }
  }
}

Is this correct?

Github Notifications (Oct 02 2017 at 21:46):

isaacvetter commented on Issue #75

Need to better document in spec:
- context is an object
- the structure of the context object is hook dependent.

We should update the spec's Hook Catalog to clarify the medication-prescribe and order-review hooks.
- Should medication-prescribe's context should be a list of one or more MedicationOrders?

Github Notifications (Oct 02 2017 at 21:46):

isaacvetter assigned Issue #75

Github Notifications (Oct 21 2017 at 07:27):

vlindhol commented on Issue #75

@bkaney I'm a bit confused, if context is so rigidly structured with FHIR search strings, how does that differ from prefetch? I use context for e.g. setting some request specific settings (like the version number of the data that the CDS uses to make its decisions). These are generally simple key-value pairs.

Github Notifications (Oct 21 2017 at 15:27):

bkaney commented on Issue #75

I think the difference is context is required to use the service whereas prefetch is an optimization but not required. I am guessing here though...

Github Notifications (Oct 21 2017 at 15:31):

vadi2 commented on Issue #75

That is my understanding as well.

On Sat, Oct 21, 2017 at 5:27 PM Brian Kaney <notifications@github.com>
wrote:

I think the difference is context is required to use the service whereas
prefetch is an optimization but not required. I am guessing here though...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/cds-hooks/docs/issues/75#issuecomment-338410256>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGxjJSVU42OhjTiQuWC3TzoR4_p7Sl1ks5sug1wgaJpZM4O0KzL>
.

Github Notifications (Oct 25 2017 at 03:57):

vlindhol commented on Issue #75

I see. Is there any official place to put small "configuration-type" values? Like my example above, where I basically want to have the config { dataVersion: "0.9.0" } somewhere, so my CDS can return a reply based on version 0.9.0 of its clinical data. Another use case might be setting the wanted language of the returned messages.

Should context be used here as well? Any special syntax to signify that it is not a FHIR search string?

Github Notifications (Oct 25 2017 at 04:03):

vlindhol commented on Issue #75

I should add that my CDS is stateless and pure, i.e. it does not contact the calling server for more information. I have been (wrongly) using prefetch for specifying what data I need using FHIR search strings, and context as a place to put both config values as well as FHIR resources that are not expressible through FHIR search strings.

Github Notifications (Nov 21 2017 at 22:51):

isaacvetter closed Issue #75

Github Notifications (Nov 21 2017 at 22:51):

isaacvetter commented on Issue #75

Hey @vlindhol , I think that you should check out this issue #76.

I'm going to close this issue in favor of #39 .

Isaac

---

Last updated: Apr 12 2022 at 19:14 UTC