Org Web Adapter

Editing journals/2019_03_18.org

:PROPERTIES:
:ID:       7be0ce8c-bbc3-46f3-82bb-20561bee9b73
:END:
#+BEGIN: clocktable :scope file :maxlevel 2
#+CAPTION: Clock summary at [2019-03-19 Tue 10:46]
| Headline           | Time   |      |
|--------------------+--------+------|
| *Total time*       | *8:08* |      |
|--------------------+--------+------|
| Monday, 03/18/2019 | 8:08   |      |
| \_  Tasks          |        | 8:08 |
#+END:
* Monday, 03/18/2019
** Tasks
*** Today's meetings
:LOGBOOK:
CLOCK: [2019-03-18 Mon 16:02]--[2019-03-18 Mon 17:00] =>  0:58
CLOCK: [2019-03-18 Mon 13:30]--[2019-03-18 Mon 13:47] =>  0:17
:END:
**** Team IO Standup
Meeting went very quickly today, a testament to both the work I'm doing and the
ability of Ed to finish some parts of the CQM calculator up. Ayhan was also out
sick so a discussion with Ed that would have gone a bit longer due to Ed and
Ayhan working on angora testing.
**** *E All hands meeting
**** Select board
[[file:town.org::*Second%20March%202019%20Selectboard%20meeting][Second March 2019 Selectboard meeting]]
*** DONE Start on draft of budget narrative for town
:LOGBOOK:
CLOCK: [2019-03-18 Mon 09:50]--[2019-03-18 Mon 11:00] =>  1:10
:END:
*** DONE Deposit CMT cash :@errand:cmt:bank:
CLOSED: [2019-03-18 Mon 11:15]
:LOGBOOK:
CLOCK: [2019-03-18 Mon 11:00]--[2019-03-18 Mon 11:25] =>  0:25
:END:

*** DONE Grab immersion blender from Big house
CLOSED: [2019-03-18 Mon 11:35] DEADLINE: <2019-03-18 Mon 11:00>
*** DONE Cancel GEICO insurance :@errand:pfin:
SCHEDULED: <2019-03-18 Mon>
:LOGBOOK:
CLOCK: [2019-03-18 Mon 11:48]--[2019-03-18 Mon 12:00] =>  0:12
:END:

*** DONE RSVP to info@manor-inn.com regarding Men's Club on Wednesday :emma:@errand:email:
SCHEDULED: <2019-03-18 Mon>
:LOGBOOK:
CLOCK: [2019-03-18 Mon 13:07]--[2019-03-18 Mon 13:13] =>  0:06
:END:
I need to check with Emma to make sure Wed. night is free.

After talking with Emma, decided this wasn't worth it.

*** DONE Check that CQM reports went out on time :@work:cqmreport:
SCHEDULED: <2019-03-18 Mon>
:LOGBOOK:
CLOCK: [2019-03-18 Mon 11:30]--[2019-03-18 Mon 11:45] =>  0:15
:END:
Was able to verify by checking the prod database that three reprorts were properly created and emails sent.

*** DONE Figure out why flu vaccine CDS always calculates to the same dates :@work:cds:fluvacc:
SCHEDULED: <2019-03-18 Mon>
:LOGBOOK:
CLOCK: [2019-03-18 Mon 22:57]--[2019-03-19 Tue 00:24] =>  1:27
CLOCK: [2019-03-18 Mon 14:07]--[2019-03-18 Mon 16:02] =>  1:55
CLOCK: [2019-03-18 Mon 13:14]--[2019-03-18 Mon 13:30] =>  0:16
CLOCK: [2019-03-18 Mon 12:00]--[2019-03-18 Mon 13:07] =>  1:07
:END:

Managed to get this to work by hacking the `code` field on the measure
definitions for 2018 and 2019 CMS147 measures. Very strange.

There appear to be two CDS triggers here, but only one is an ecqm_proportion_measure:
#+BEGIN_SRC python
[{'trigger': 'ecqm_proportion_measure', 'actions': ['immunization', 'alreadydone', 'delayed', 'referred', 'contraindicated', 'declined'], 'summary': '$flu_vaccine[Influenza Immunization] for Patients 6 mo. and older'},
 {'trigger': {'$excluded': [{'all': ['$next_flu_shot_not_needed']}], '$pending': [{'none': ['$next_flu_shot_not_needed']}], '$relevant': [{'none': ['$next_flu_shot_not_needed']}]}, 'actions': ['immunization', 'alreadydone', 'delayed', 'referred', 'contraindicated', 'declined'], 'summary': '$next_flu_vaccine[Influenza Immunization] for Patients 6 mo. and older'}]
#+END_SRC
So one  kicks out a False on whether it should be shown and the other a True
https://github.com/elationemr/hippo/blob/master/elation/quality_measures/reporting/elation_clinical_reminders.py#L144
** 09:48 Goals
I still haven't managed to get a mentorship document written up for working with
Ed. That's top of my list today, beyond getting the Flu vaccine CDS working
again.
** Work log
Started out the day double checking that CQM reports went out on time. Everything looked good in the database, which was nice to see for a change. We still probably ought to build out some sort of a API for managing task-based reports like that so someone without database access can double check things like that.

I spent most of the day then looking at the flu vaccine issue, which is the same thing I did the past few working days. I started out today by returning the data that I wanted from the API call that returns which CDS should be displayed. This way, I was able to debug the fact that the influence CDS will display if the response to the per-patient CDS call (https://elation.onec.me/patient/64058687489/cds/2019/) is true for the NQF code for the flu vaccine (0041).

After confirming that the CDS works, I went backward to how that true response is generated and discovered something quite curious. Just like with the BMI CDS,  which has three different CDS alerts that can be displayed, the flu vaccine CDS has two different alerts. One is for the vaccine, and the other seems to be about when the next vaccine is due.

I honestly couldn't figure out how to trigger the second alert, but it turned out that when we lookup the particular reminder, the first in the sequence was being set to False, i.e. the patient does not need the vaccine (despite the fact that they do), and the second alert in the sequence was being set to True. But the CDS only displays the second alert if the first on is non-False, so it was never appearing.

I need to talk to Sam tomorrow about my findings, because he mentioned something about how the flu vaccine CDS never actually worked as designed. I  think this may be the culprit. If I remove the second reminder (for the next vaccine date) from the measure definition file, everything displays as you'd expect, and addressing the alert properly adds the patient to the numerator and all that jazz. So I think this is a solution, but I'm still unhappy with the fact that I don't know WHY it's the solution specifically.