FHIR Chat · docs / PR #458 Explicitly clarify the intent behind optio...

Stream: cds hooks/committers

Topic: docs / PR #458 Explicitly clarify the intent behind optio...

Github Notifications (Jan 15 2019 at 20:20):

Should be expanded to clarify behavior of strings, objects, arrays, including accurate terminology. Will follow-up in a later CDS meeting -

Motion: Will incorporate language into spec to ensure that object property values are never null.

Mover/Seconday: Isaac Vetter/Josh Mandel:
Yes: 38
Abstain: 2
No: 0

Github Notifications (Jan 15 2019 at 20:54):

kpshek commented on PR #458

This past Sunday (Jan 13th) we had a breakout session for CDS Hooks at the HL7 Connectathon. 30+ people we in attendance representing EHR vendors, CDS Service providers, and healthcare organizations. This PR was a topic of discussion and for the most part, the informal poll we took in the room was that the majority just want a decision on this topic (whatever that may be) and that aligning with FHIR's model in this regard was fine.

In a hallway conversation with @brynrhodes, we both think we change the only exception case we have right now (the response cards array which must always be valued, even with an empty array) to following this new requirement. This would mean that this line:

If your CDS Service has no decision support for the user, your service should return a 200 HTTP response with an empty array of cards.

Would be changed to something like:

If your CDS Service has no decision support for the user, your service should return a 200 HTTP response and the cards field omitted from the response object.

While that would mean the response object would be {} today, I foresee us adding additional top-level response fields in the future (like the system actions in the decisions proposal). Did this get discussed in the working group meeting today along with the vote?

Github Notifications (Jan 15 2019 at 21:03):

pcurc commented on PR #458

Is a 204/No Content response another possibility here?

Github Notifications (Jan 15 2019 at 21:23):

kpshek commented on PR #458

Is a 204/No Content response another possibility here?

I remember thinking about this (unfortunately, there is nothing about this in our past issues). IIRC, I was thinking that we would likely add additional fields to the response which would mean that 204 likely will not be sent in all 'no decision support' scenarios.