Stream: cds hooks
Topic: how can I pass non-String data from CQL to populate Cards?
Matt Storer (Jan 20 2021 at 21:16):
Hi -
First post, please be kind :)
I'm working to populate CDS Hook Card attributes from the results of executing CQL.
See: https://cds-hooks.hl7.org/1.0/#card-attributes
Some of these attributes are Strings, and they populate back into the Card structure in the calling PlanDefinition resource easily from the executed CQL (e.g. summary, detail, indicator).
However, CDS Hook Card attributes include other attributes that are not strings, i.e. source, suggestions, and links. We would like to be able to populate these from the executing CQL as well, but our understanding is that there is no way to pass complex data structures such as these back to populate the Card structure in the calling PlanDefinition resource.
Does anyone know how we can pass these other fields back?
Please let me know if any of that doesn't make sense and I'll try to explain better.
Thanks -
Matt
Paul Swarts (Jan 21 2021 at 06:49):
We are using extensions for this, but we also want to embed a Questionnaire in the cards so I have a similar question as @Matt Storer . What is the right syntax for this? We want to use valueResource as field. the valueReference field doesn't support in place resources if I understand the spec correctly (https://www.hl7.org/fhir/references.html)
Isaac Vetter (Jan 27 2021 at 05:54):
Hey Paul, as you've identified, there isn't really a method for returning a Questionnaire in a CDS Hooks card. Practically, the method to represent a form to the clinician is through a SMART app link.
Isaac Vetter (Jan 27 2021 at 05:58):
Matt, it would be great to better understand (and improve!) any obstacles for a CQL/Clinical Reasoning backend returning CDS Hooks card. Your question is pretty generic, and focused on json vs fhir data types. Are you asking for a mapping between CDS Hooks' json data types and FHIR's PlanDefinition fields? Does this help at all: https://www.hl7.org/fhir/clinicalreasoning-cds-on-fhir.html#:~:text=2.1%20Representing%20Hooks%20in%20FHIR,current%20activity%20in%20the%20system.
Paul Swarts (Jan 27 2021 at 06:30):
Hey Isaac, we also offer a SMART app link card with our UI to answer the Questionnaires. However we have customers (CDSM client's) that want to implement their own forms of the Questionnaire. Therefore we offer both ways. Do you have an idea how we can return this Questionnaire?
Lloyd McKenzie (Jan 27 2021 at 15:03):
CRD's solution is to return a card seeking the creation of a Task asking for the Questionnaire to be completed. (Part of the reason is there isn't necessarily an expectation that the Questionnaire would be filled out immediately, as the card is typically saying "You'll need to fill this out to seek prior authorization", and that's not necessarily done by the clinician, nor done at the time of ordering.
Matt Storer (Jan 28 2021 at 19:35):
Isaac Vetter said:
Matt, it would be great to better understand (and improve!) any obstacles for a CQL/Clinical Reasoning backend returning CDS Hooks card. Your question is pretty generic, and focused on json vs fhir data types. Are you asking for a mapping between CDS Hooks' json data types and FHIR's PlanDefinition fields? Does this help at all: https://www.hl7.org/fhir/clinicalreasoning-cds-on-fhir.html#:~:text=2.1%20Representing%20Hooks%20in%20FHIR,current%20activity%20in%20the%20system.
Hi @Isaac Vetter -
Thanks for the reply, and yes that link does help, at least insofar as understanding where things are coming from and where they go.
Basically, we are trying to construct more complete Cards from the results of CQL execution. Right now, we can populate summary, detail, and indicator (action.title, action.description, and action.extension, respectively) from the CQL through the "dynamicValue" object list. We would also like to be able to populate source, suggestions, selectionBehavior, and links from the CQL, but I haven't seen a way to do this.
Do you know if there's a way?
Alternatively, we're considering glomming all of these things into exiting text fields that we know we can populate (such as in the Rationale / Response.card.detail / action.description field), with appropriate delimiters and whatnot, and then parse that stuff out on the application side. That's sort of an ugly workaround though, but based on my current understanding, that may be the only way to get stuff to work the way we want.
Does that make sense? I'm trying to describe what we're trying to do without pasting loads of code and hundreds of lines of stuff.
Appreciate your assistance,
Matt
Isaac Vetter (Jan 28 2021 at 20:41):
@Matt Storer , my CQL/Clinical Reasoning knowledge is limited and I rely upon Bryn Rhodes a lot. The "CQL Hooks" pattern does appear to have a number of implementers.
Isaac Vetter (Jan 28 2021 at 20:41):
@Bryn Rhodes - do you have clinical reasoning servers that support CDS Hooks and support suggestions / links?
Isaac Vetter (Jan 28 2021 at 20:42):
Matt - just curious -- Are you working on integrating the guidance via CDS Hooks into your organization's EHR?
Bryn Rhodes (Jan 30 2021 at 17:42):
@Matt Storer , we were testing this exact behavior in the most recent connectathon, we used an ActivityDefinition to define the resource to be created and referenced it via the defintionCanonical in the PlanDefinition: https://github.com/cqframework/opioid-cds-r4/blob/99fa38d37ea895c3dfeba7a49aaac68056feb8e0/input/resources/plandefinition/plandefinition-OpioidCDSREC10PatientView.xml#L132
Bryn Rhodes (Jan 30 2021 at 18:05):
@Paul Swarts , for questionnaires, we have been using a Task resource with a reference to the Questionnaire, but for the purposes of the response, you could put it in the contained of the Task. There's an ActivityDefinition example of this here
Last updated: Apr 12 2022 at 19:14 UTC
