Isaac Vetter

Hey @bvdh, At root - you're struggling to define how different CDS clients implement workflow and UI as it relates to the display of external CDS. Should CDS Hooks really...

Bas, Do note that we do try to call out a related risk already in the spec: >The risk that a CDS Service could return a decision based on outdated...

Hey Guys, With this proposed change of allowing a selectionBehavior = all, a cds developer must decide when their guidance is an action vs a suggestion and there’s not really...

Hey @bvdh , This distinction in the spec is between `context`, which can contain "in-memory" data that may not be available via the FHIR server, and `prefetch`'d data which MUST...

Per wg call conversation: Ultimately, the hooks that we've created thus far distinguish between mere FHIR ids in context and full draft resources in context. This distinction implies that the...

@bvdh - as a starting point, will you take a look at #506 ?

Hey @stefan-evinance , Overall, the current approach doesn't exclude an EHR from using a 3rd party authentication provider, it simply doesn't define the interaction between the EHR and this provider....

I thought I'd throw up a strawman proposal for consideration by better minds -- A CDS service indicates that a returned app link can be immediately opened **and that the...

Hey @olbrich! Currently the indicator /hard-stop value refers to a card, not necessarily a link, right? Some of the additional considerations that I've been thinking about are: * different EHR...

Hey Kevin, Thanks for the comments. The question is, how to do this: >Whether the CDS Service returns a card in which the card summary and source doesn't need to...