FHIR Chat · docs / Issue #36 Context as a list of FHIR Resources · cds hooks

Stream: cds hooks

Topic: docs / Issue #36 Context as a list of FHIR Resources

Github Notifications (May 05 2017 at 03:54):

euvitudo opened Issue #36

I would like to suggest that context be explicitly documented as a list of FHIR Resources, in order to more accurately interpret that is included in the list.

Github Notifications (May 05 2017 at 04:00):

euvitudo edited Issue #36

I would like to suggest that context be explicitly documented as a list of FHIR Resources, in order to more accurately interpret that is included in the list.

Github Notifications (May 06 2017 at 06:01):

isaacvetter commented on Issue #36

Hey @Phillip Warner !

Does this (more recently created) issue #39, capture your suggestion?

Isaac

Github Notifications (May 06 2017 at 06:08):

euvitudo commented on Issue #36

Hey @Isaac Vetter
For the most part it does with the exception that it doesn't actually explicitly state that context shall be a list of FHIR Resources (read: it seems to avoid saying as much). I'll be interested to see how the formal definition plays out.

Github Notifications (May 06 2017 at 06:19):

kpshek commented on Issue #36

@Phillip Warner - I definitely see FHIR resources being included in context. However, I'm not sure we should limit context to be composed only of a list of FHIR resources.

Eg, this issue seems to propose context be:

"context": [
 {...}, // some FHIR resource
 {...} // another FHIR resource
]

However, I think there are scenarios where context can contain FHIR resources + additional data outside of FHIR. For example:

"context": {
 "allergyIntolerance": {...}, // FHIR allergy resource being documented
 "someDataOutsideOfFHIR": "foo"
}

Coming up with additional hooks will help us see clarity on this topic. However, allowing context to be an object as opposed to an array will allow for greater flexibility when defining hooks (especially hooks unique to a particular EHR).

Github Notifications (May 06 2017 at 06:28):

euvitudo commented on Issue #36

@kpshek - The way I see it is that additional data can be represented by resources such as Basic (with extensions), Binary, Media and possibly others.

To wit: I don't see how a FHIR-sanctioned spec can use anything other than FHIR-sanctioned resources. If FHIR needs to support a more generic resource than Basic (again, with extensions), then that should be added to the FHIR specification.

Github Notifications (May 06 2017 at 06:32):

kpshek commented on Issue #36

@Phillip Warner - SMART is being published by FHIR as well and does not use FHIR exclusively in its representation of data (for instance, context data a SMART app receives). As mentioned in #37, we moved away from exclusively using FHIR for all representations.

Github Notifications (May 06 2017 at 06:32):

jmandel commented on Issue #36

To wit: I don't see how a FHIR-sanctioned spec can use anything other than FHIR-sanctioned resources.

My take is that we want to be pragmatic and move quickly. Design choices we make here might well influence future direction for FHIR (e.g. There's actively consideration now about a mere condensed Parameters representation). But first we have to show that this stuff works.

Github Notifications (May 06 2017 at 06:40):

euvitudo commented on Issue #36

From an implementer's point of view, I find that a specification that allows anything to be passed in makes my life more difficult, as my implementation needs to know how to handle the context or reasonably ignore it. If the impl ignores the context data, what use is it during decision support?

A well-defined, well-known specification allows me to have a level of certainty that the data received by the service can be reasonably leveraged to perform the CDS operation.

Github Notifications (May 06 2017 at 07:33):

jmandel commented on Issue #36

To be clear, we're not proposing allowing "anything" -- we're proposing that CDS Hooks should specify the content (ans leveraging FHIR resources wherever they fit).

Github Notifications (May 06 2017 at 07:36):

euvitudo commented on Issue #36

Fair enough. I would be helpful to have @kpshek define what he means by:

FHIR resources + additional data outside of FHIR

Github Notifications (May 06 2017 at 08:12):

kpshek commented on Issue #36

@Phillip Warner - By "FHIR resources + additional data outside of FHIR" what I meant was that I would be surprised to see context containing non-FHIR data, especially for hooks that are specific to a particular EHR. I don't concrete examples of this today because our definition and exploration of hooks has been limited thus far.

Non FHIR data aside, by allowing context to be a JSON object, it gives us more flexibility than an array.

Github Notifications (May 06 2017 at 09:19):

euvitudo commented on Issue #36

@kpshek - that makes sense. Thanks.

Isaac Vetter (May 11 2017 at 11:09):

Hey @Phillip Warner - should this github issue be closed - especially with https://github.com/cds-hooks/docs/issues/39 still open?

Kevin Shekleton (May 11 2017 at 11:10):

:thumbs_up: @Isaac Vetter

Phillip Warner (May 11 2017 at 14:49):

@Isaac Vetter, as long as context is well-defined (@Kevin Shekleton says it should be an object, and I'm fine with that) such that the data provided in the context can be handled by any system that implements the hook, through a standard definition.

Josh Mandel (May 11 2017 at 14:55):

Yeah, I think the general structure of "object with well-named keys (per-hook)" works well. In general, the values for these keys will sometimes need to be an array (e.g. for an order review hook). Should we model them all as arrays, or should we specify cardinality when we define the context parameters for a given hook?

Kevin Shekleton (May 11 2017 at 14:58):

I think we should define conventions around the value of context. My proposal would be that one of those conventions is that context is always an object. In your order review example, I think it could be:

"context": {
  "medicationOrders": [{}, {}]
}

Josh Mandel (May 11 2017 at 14:59):

Agreed: we can say context is always an object. Specific hooks name the keys. Do the keys always point to arrays (as in your example above)? Or do specific hooks specify cardinality, too?

Kevin Shekleton (May 11 2017 at 15:00):

Hooks would specify both the keys and value (object, array, string, etc...your normal JSON data types)

Josh Mandel (May 11 2017 at 15:04):

OK — that answers the question. (I was trying to see if there was any stronger consistency that we should try to apply, like "the value is always an array of FHIR resources"). But I'm happy with what you've just described @Kevin Shekleton.

Kevin Shekleton (May 11 2017 at 15:05):

- I'll capture this discussion on #39 now

Last updated: Apr 12 2022 at 19:14 UTC