Stream: cds hooks
Topic: STU2 block-vote-6 in two weeks
Isaac Vetter (Jan 26 2022 at 21:09):
:trumpet: CDS Hooks STU2 Block-vote-6 will be held in two weeks!
Isaac Vetter (Jan 26 2022 at 21:12):
Nice overview of the 19 issues in this vote is here: https://confluence.hl7.org/display/CDS/2022-01-26+Meeting+Agenda.
Isaac Vetter (Jan 26 2022 at 21:12):
Commenters include: @Bas van den Heuvel , @Celine A Lefebvre , @Matt Varghese , @Dennis Patterson , @Josh Mandel , @Kishan Patel , @Gunjit Chhatwal.
HL7 thanks you for your feedback.
Isaac Vetter (Jan 26 2022 at 21:13):
Anyone, for any reason, may request that one or more issues be withdrawn from this block vote for further, individual workgroup discussion.
Dennis Patterson (Feb 09 2022 at 15:22):
https://jira.hl7.org/browse/FHIR-28663 (allow next page links on prefetch) - If it's prefetch, what is the point of a next page link? I'm trying to avoid complexity in prefetch templates where a CDS Service now needs to specify whether to send the whole response or only the first page
Dennis Patterson (Feb 09 2022 at 15:23):
https://jira.hl7.org/browse/FHIR-28694 (Client authentication should not be mandated) - How does a CDS Service now advertise whether their endpoint requires authentication? Does we just want an allowance for a CDS Service to be able to ignore the header if they don't care? Or do we really want the CDS Client behavior to flex?
Dennis Patterson (Feb 09 2022 at 15:23):
https://jira.hl7.org/browse/FHIR-28761 (Add "patient" parameter as required by SMART App Launch spec) - Can we make addition of fhirAuthorization.patient a SHOULD instead of making this a breaking change? The issue description isn't necessarily proposing rfc-style language, but does use "should" regarding the use of this field
Dennis Patterson (Feb 09 2022 at 15:27):
https://jira.hl7.org/browse/FHIR-34274 (OO during prefetch)
- Will we break any existing CDS Services that assume template keys on a request mean that actual data is included? With this change, they may not be expecting the target resource to be absent
- Regarding supporting OO during prefetch, this resolution assumes implementation details about a CDS Client calling a FHIR Server. It also still allows the absence of the prefetch template for other errors and the "MUST NOT" language conflicts with the inclusion of an OO. Also, this OO should be in a Bundle, correct? What's not clear to me is the difference between known and unknown errors. Outside existing implementations, for what kinds of errors should the OO be included vs the prefetch key ommitted?
- I'm open to further wordsmithing, but here's a stab at including some additional language: "the CDS Client SHOULD send a Bundle with OperationOutcome(s) to communicate known errors prefetching the requested data to prevent the CDS Service from incurring an unneeded follow-up query but MUST omit the prefetch key if details cannot be provided. CDS Services SHOULD check any prefetched data for the existence of OperationOutcomes."
Josh Mandel (Feb 09 2022 at 16:18):
Dennis Patterson: https://jira.hl7.org/browse/FHIR-28694 (Client authentication should not be mandated) - How does a CDS Service now advertise whether their endpoint requires authentication? Does we just want an allowance for a CDS Service to be able to ignore the header if they don't care? Or do we really want the CDS Client behavior to flex?
Given this language in the spec:
CDS Services SHOULD maintain an allowlist of the iss and jku fields to only the CDS Clients they trust
It seems safe for CDS Services to ignore authn if they don't care about it. This may be worth stating explicitly, since it's reasonable behavior for many classes of CDS Services that never expose any sensitive information and are happy to respond to any client.
Dennis Patterson (Feb 09 2022 at 16:45):
I'm fine with that... flipping the resolution to be more focused on the CDS Services' decision to do something with it vs requiring the CDS Client to start flexing whether to send it
Last updated: Apr 12 2022 at 19:14 UTC
