FHIR Chat · docs / Issue #89 Cds service prefetch key is dynamic and ... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #89 Cds service prefetch key is dynamic and ...

---

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

isaacvetter opened Issue #89

Here's our sample discovery pre-fetch example:
"prefetch": {
"patientToGreet": "Patient/{{Patient.id}}"
}

By having the cds service define the "patientToGreet" key, serialization of a CDS Hooks request message by the EHR is many programming languages doesn't allow the use of standard serialization tools.

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

JustinStauffer commented on Issue #89

I brought this concern up to Isaac while investigating CDS Hooks. Having a dynamically named element in the message content essentially means there can be no schema defining the message structure and therefore, you cannot build a code-representation of the message at compile time. That seems like a very big problem to me.

Perhaps you can work around it by creating custom serializers/formatters but that also looks like a big red flag to me. When the solution to a problem with a spec is "Just write a custom _____", that doesn't smell right.

Github Notifications (Sep 12 2017 at 18:18):

brynrhodes labeled Issue #89

Github Notifications (Sep 12 2017 at 18:22):

jmandel commented on Issue #89

Are you asking for something more like:

"prefetch": [{
  "key": "patientToGreet",
  "value": "Patient/{{Patient.id}}"
}]

... the same assessment should apply to .context and other places where hook-specific variation may be introduced.

Github Notifications (Sep 12 2017 at 18:23):

jmandel edited Issue #89

Here's our sample discovery pre-fetch example:

      "prefetch": {
        "patientToGreet": "Patient/{{Patient.id}}"
      }

By having the cds service define the "patientToGreet" key, serialization of a CDS Hooks request message by the EHR is many programming languages doesn't allow the use of standard serialization tools.

Github Notifications (Sep 12 2017 at 18:39):

kpshek commented on Issue #89

Per discussion at the Sept WGM (Tue Q2), this is something we need to decide if we change prior to the 1.0 release (since it would represent a breaking change).

We want to talk with @JustinStauffer & @Isaac Vetter more on this issue to understand this in further detail.

Github Notifications (Sep 12 2017 at 18:39):

kpshek milestoned Issue #89

Github Notifications (Sep 12 2017 at 19:15):

jaredrn commented on Issue #89

I would agree that prefetch is a little tricky for a statically typed language like C#. It can be overcome with a little custom serialization logic to bridge the gap between a JSON parsing library and the C# reference implementation, but it's not entirely intuitive.

Github Notifications (Sep 12 2017 at 20:39):

JustinStauffer commented on Issue #89

Yes (to Josh / @Josh Mandel). That would work because the _value_ is dynamic and not the element name.

Github Notifications (Sep 12 2017 at 20:49):

grahamegrieve commented on Issue #89

I think that there's some mus-understanding here.

"prefetch": [ "patientToGreet", "value": "Patient/{{Patient.id}}" ]

this is easy to serialise natively - if you have a definition for this specific hook.

Github Notifications (Sep 12 2017 at 20:52):

JustinStauffer commented on Issue #89

@grahamegrieve - Yes but if you want to create a generic framework to handle many hooks, this would become unscalable.

Github Notifications (Sep 12 2017 at 21:05):

grahamegrieve commented on Issue #89

Yes. so you trade between various optimisation here. you can make it so that the generic format is a hard schema that's simple to write with OTS schema tools, but the consequence of this is that it's now equally hard to do it by schema the other way. For me, this is a bad idea - servers that handle many hooks should pay the price, not clients that handle single hooks

Github Notifications (Sep 12 2017 at 21:06):

jmandel commented on Issue #89

+1 to @grahamegrieve's assessment here.

Github Notifications (Sep 12 2017 at 21:11):

JustinStauffer commented on Issue #89

I'm not following what you mean by "it's now equally hard to do it by schema the other way". Also, I'm looking at this from the perspective of a client that may want to call many different servers. Or perhaps more accurately, many instances of a client spread across the world invoking different servers at each instance. If customer A wants to connect to CDS Hooks server A that supports prefetch/patientToGreet but then customer B wants to connect to CDS Hooks server B that supports prefetch/patientToSmileAt, I need to write two clients for them. What happens if customer A wants to connect to CDS Hooks servers A, B, C, D, etc. who all do it differently? That's unscalable.

Github Notifications (Sep 12 2017 at 21:16):

kensaku-kawamoto commented on Issue #89

I would +1 the thoughts from @JustinStauffer

Github Notifications (Sep 12 2017 at 21:22):

JustinStauffer commented on Issue #89

As a compromise, I'd be fine with either approach as long as the list of choices for that element name were defined in a finite list. Honestly, I think that is my bigger issue. This could be _anything_. There's nowhere else in an industry standard that I'm aware of where an element in a message can be named _anything_. It's actually an ugly piece of ebXML/IHE that has the generic Slot structure.

So if we had a well defined list of options (like a FHIR resource container), that'd be fine by me.

Github Notifications (Sep 12 2017 at 21:28):

jmandel commented on Issue #89

In general, the job of prefetch is to support ad-hoc, client-specific requirements. So we won't be able to enumerate a finite list of what these should be called.

Github Notifications (Sep 12 2017 at 21:32):

JustinStauffer commented on Issue #89

Then the ad-hoc portion of it needs to be part of dynamic _content_ -- not part of message structure itself. (for the reasons I mentioned above).

Github Notifications (Sep 12 2017 at 21:43):

jmandel commented on Issue #89

I think the distinction between "content" and "message structure" is not so stark. In any case, "needs" is a bit strong (after all, that's the subject of discussion here :-))

Github Notifications (Sep 13 2017 at 02:50):

kensaku-kawamoto commented on Issue #89

This is probably pretty obvious -- but is there a reason why there needs to be name(s) associated with the data asked for in a prefetch in any case?

Github Notifications (Sep 13 2017 at 03:47):

olbrich commented on Issue #89

I'll just re-iterate my comment from the connectathon. It seems like a bad idea to me to allow the structure of the message to be dictated by implementation details of the underlying languages. There are systems that are quite capable of handling the originally proposed structure with little modification. Making the proposed change will undoubtedly inconvenience those developers.

Another option might be to package the prefetch data as a Bundle (of type 'collection') and give each entry an id in a cds-hooks specific code system so the CDS service can easily determine which one is which.

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

JustinStauffer commented on Issue #89

Does anyone have examples of other healthcare interoperability standards where an element name in a message is variable?

FHIR does not do this as far as I'm aware. The closest thing I know of is the ResourceContainer that can contain any type of resource. However, those resource types are finite and defined at "design time" so that type is represented in schema as a choice element. How would you represent the current approach in a schema? Do we not care about this?

@olbrich , yes anyone can handle this with modification with some programming (what problem cannot be solved with programming?). However, I'm pretty sure one of the goals of FHIR (and presumably, CDS Hooks too) is to lower the implementation barrier versus prior standards (e.g. HL7v3). By requiring people to customize off-the-shelf functionality provided in well-known programming libraries, we're raising a barrier to implementation and then we need to ask ourselves what we're really trying to do here...

Also, other than "This is the way it has been proposed and that's how I already wrote my system based on a draft specification", I have seen no argument for why the current approach is better than a key/value pair as Josh replied with above. Perhaps Grahame could clarify what he meant by "it's now equally hard to do it by schema the other way" as I don't understand what he means by that.

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

isaacvetter assigned Issue #89

Github Notifications (Oct 03 2017 at 14:18):

JustinStauffer commented on Issue #89

Note that the CDS service response handles this issue just fine in via the Action type. This is used in cards/suggestions/actions.

The structure of Action is:
- type - Type of action being performed: create, update, delete
- resource - The associated resource info

Prefetch could work the same way by using the exact same type. This way, the element name wouldn't be variable -- the value of the "type" field would be variable.

"prefetch": { "action": { "type": "patientToGreet", "description": "This is the patient to greet when they arrive." "resource": { "resourceType": "Patient", "gender": "male", ... etc ...

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

isaacvetter commented on Issue #89

Ultimately, yes, serialization is harder because of this format. It's not impossible. This issue is the only feedback that CDS Hooks has received around this issue.

I think that @grahamegrieve 's point is ultimately persuasive:

Yes. so you trade between various optimisation here. you can make it so that the generic format is a hard schema that's simple to write with OTS schema tools, but the consequence of this is that it's now equally hard to do it by schema the other way. For me, this is a bad idea - servers that handle many hooks should pay the price, not clients that handle single hooks

Closing.

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

isaacvetter closed Issue #89

---

Last updated: Apr 12 2022 at 19:14 UTC