FHIR Chat · docs / Issue #158 Lists of resources should be bundles · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #158 Lists of resources should be bundles


view this post on Zulip Github Notifications (Jan 28 2018 at 20:48):

robs16 opened Issue #158

medication-prescribe currently is using a list of FHIR resources for the medications. While this seems logically to make sense, it does not jive well with existing FHIR resource interpreting packages such as HAPI. The result is a bit of nasty code to decode as JSON, iterate the list, creating JSON strings from the resource, and then using HAPI to parse (alternatively you must do something similar but create a bundle). A list of resources is generally represented by a bundle within FHIR, and I think this is how any list of resources should be represented in cds hooks context/prefetch.

view this post on Zulip Github Notifications (Jan 28 2018 at 20:59):

kpshek milestoned Issue #158

view this post on Zulip Github Notifications (Jan 31 2018 at 17:28):

euvitudo commented on Issue #158

One advantage of the suggestion by @robs16 is that related resources (e.g., Medication, Practitioner) could be included in the payload. However, 'medications' would become a misnomer in this case (maybe 'prescribeBundle' or 'orderBundle'?).

view this post on Zulip Github Notifications (Jan 31 2018 at 17:42):

kpshek commented on Issue #158

@euvitudo - Are you referring to the medication-prescribe and order-review hooks? In that case, I think the attribute names (medications and orders, respectively) still make sense as that is the core content of those fields. By suggesting that related resources could also be included in the bundle, are you thinking of contained resources?

view this post on Zulip Github Notifications (Jan 31 2018 at 17:49):

euvitudo commented on Issue #158

@kpshek - mostly medication-prescribe, but order-review would be relevant too. I'm indifferent about attribute names, though, insofar as they make sense.

Regarding resources included in the bundle--I was not thinking of contained resources (I'm honestly not a huge fan of contained resources), but bundle entries, where resources could reference other resources in the bundle so as to preclude additional retrieval of resources from a FHIR payload.

As it stands, the example in medication-prescribe that includes medicationCodeableConcept seems to be sufficient, but it may be useful (maybe not necessarily in medication-prescribe) to include other resources that are needed for service operation.

view this post on Zulip Github Notifications (Jan 31 2018 at 18:15):

robs16 commented on Issue #158

So my service will handle this in any case, but I would generally expect medications for medication-prescribe to be a list of MedicationOrders with potentially Medication contained resources (not as bundled resources). In the case of order-review, orders may contain MedicationOrders, which in turn would also possibly contain Medications. Generally for any MedicationOrder, it is really useful for my service to have the associated Medication. There is not a good way to do this through prefetch (at least I don't think there is). While not a 1.0 issue it might also be good to have some way to tell the EHR what we really need for context data in a future version. This could drive in the direction of #155 or what @euvitudo is suggesting. In either case, using a bundle rather than an array works well.

view this post on Zulip Github Notifications (Feb 21 2018 at 16:41):

isaacvetter assigned Issue #158

view this post on Zulip Github Notifications (Mar 26 2018 at 17:43):

kpshek closed Issue #158


Last updated: Apr 12 2022 at 19:14 UTC