PlanDefinition & CQL for PHQ9 and GAD7 administration

[mcjustin]

No description provided.

[mcjustin]

@achen2401 @pbugni just FYI at this point. I'm aiming to run this through encender $apply today on my local install of that.

[mcjustin]

Out of scope for this MR:

1. nesting actions and PlanDefinitions (supported via encender's "applyAndMerge").

[mcjustin]

@achen2401 if the screener is going to request $apply from encender I think it would do so at https://github.com/uwcirg/asbi-screening-app/blob/master/src/components/Survey.vue#L411 , ie after it has successfully saved each QR.

Per https://github.com/ccsm-cds-tools/encender#usage , I think it would call that applyPlan, get the new CarePlan from encender, and then write that new CarePlan to the SoF host.

Thoughts?

Aside: one complexity is that for DCW (and probably most other projects) we expect most CarePlans to have multiple questionnaires, and for daily administration of each questionnaire. We'll probably iterate a bit on the level of sophistication we implement here... For example, after processing the first QR per above, the new CarePlan would ideally not include the Questionnaire that was just presented, since it is no longer needed - I think it would be on me to build that into the PlanDefinition logic.

[achen2401]

if the screener is going to request $apply from encender I think it would do so at https://github.com/uwcirg/asbi-screening-app/blob/master/src/components/Survey.vue#L411 , ie after it has successfully saved each QR.

@mcjustin I was thinking more like here, where we call $apply so that the careplan is generated first and the app can look in the care plan to see what questionnaire(s) are to be administered. (see here )

I think there should be logic in the Plan Definition that will determine what questionnaire(s) is required still from the questionnaire responses. Here is a breakdown of my thought process:

1. The app executes $apply to generate Care Plan
2. The app then looks in the Care Plan generated from 1. to see what questionnaire(s) is required.
3. The user goes through the questionnaire and hits submit to save the responses.
4. The app refreshes to administer the next questionnaire.
5. So back to 1. again (by this time there should be responses saved from 3 for the logic involved in generating the care plan to determine what questionnaire(s) are left)

[mcjustin]

@achen2401 your suggested approach is intriguing... it implies that any consumer of a CarePlan will need to call $apply to get it, whereas my approach puts the onus on the system which is doing the modifying, to both call $apply and POST/PUT it to the FHIR store.
Advantages to the consumer calling $apply:

• The consumer is guaranteed to have a fresh CarePlan.

Advantages to the modifier calling $apply and persisting it:

• A downstream consumer need not calculate it. This is an advantage because a) the consumer may not have $apply at its disposal, and b) the consumer may need to have up-to-date CarePlans for a number of patients, eg in the patient list.

Since fEMR isn't calling $apply yet, and since the screener is the only thing changing data of relevance (for the DCW MVP, we're starting w/ a set of test patients - no need to add patients or modify their clinical state once they've been seeded), I'd be inclined for the screener to either call after QR write, or do it both before and afterwards...

@pbugni care to weigh in?

[achen2401]

@mcjustin Before proceeding further with this, I need to note that it seems, unfortunately, that encender only works in the node environment, not in the browser environment. When I tried running it in the browser, the app errored out at the encender commonJS code, used solely in the node environment (see screenshot):

The example they give can only run in the node environment. I tried it last night (see the screenshot I took):

It seems that they might be working on adding browser support for the tool (see here) but it looks to be in the works.
I don't know that we can use encender for our purpose at the moment, unless you think otherwise. We should think about pursuing alternatives, e.g. generate careplan ourselves.

[mcjustin]

@achen2401 From your console screenshot, it looks like you have the isNodeJs flag set to true (default) here: https://github.com/ccsm-cds-tools/encender/blob/main/src/simpleResolver.js#L18 . Have you tried changing that?

Below is a chat between me and David Winters from August.

---

David Winters: Encender uses the cql-worker library, which works in both the browser or server-side. Web workers are used in the browser and worker threads are used in Node.

David Winters: See this line in Encender.

David Winters: If you don't provide a worker factory function via the aux input, then Encender defaults to using Node worker threads. This is what happens when you run the Encender built in tests.

David Winters: Here's an example of running Encender with Node.js: https://github.com/ccsm-cds-tools/ccsm-cds-with-tests/blob/main/apply/screening-example.js

David Winters: Here's an example of creating a web worker in the browser: https://github.com/ccsm-cds-tools/ccsm-cds-dashboard/blob/main/src/hooks/useCds/index.js#L33

[achen2401]

@mcjustin thanks. I am not certain if that is the issue as I was still encountering errors after setting the variables.

    const WorkerFactory = () => {
        return new Worker();
      }
    
    const isNodeJs = false;
    // Define aux object containing ELM JSON and value sets
    const aux = {
      elmJsonDependencies,
      WorkerFactory,
      isNodeJs
    }

Feel free to try out the branch I started here. This is the latest error (see the screenshot):

There is a discussion of that error here. Noting that both modules and work_thread modules are native nodejs modules.

[mcjustin]

@mcjustin thanks. I am not certain if that is the issue as I was still encountering errors after setting the variables.

    const WorkerFactory = () => {
        return new Worker();
      }
...

@achen2401 It looks like you need to pass cql.worker.js to the Worker() constructor like they do here:
https://github.com/ccsm-cds-tools/ccsm-cds-dashboard/blob/main/src/hooks/useCds/index.js#L37

Also, is your order of parameters correct here? https://github.com/uwcirg/asbi-screening-app/pull/44/files#diff-8c11bc890bb34855fbe12928704387db4d404de2fae418849b0eead8d61001d6R91-R95 ? It differs from the useCds example.