CCHIT - Patient Reminders

OpenEMR Development
1

anonymous wrote on Tuesday, January 26, 2010:

We have completed initial coding for patient reminders. This MU is closely associated with Clinical Decision Support.

http://www.openmedsoftware.org/wiki/Patient_Reminders

The reminders can now be sent via email and automated VOIP phone call. We have upgraded “phpmailer” to the lastest 5.1 version and allowed three methods (PHPMail, SMTP, and SendMail) to be used. The work for letter/postcard printing is in progress.

Please also review the codes posted in the Tracker. For demo, go to http://www.medbloom.com/, and log in using “test1” as both the username and password.

2

bradymiller wrote on Wednesday, January 27, 2010:

hey,
Here’s code review

Overall review
1) I am still noting some potential fundamental flaws in the health plan/reminders section. This thing has matured enough in code to start doing practical tests on it. The best thing to show is how the health plan works for DM type II (foot exam, A1C, optho exam, flu shot). So for example what if require Q6month foot exam, Q3month A1C, and Q12month optho exam. Please show how the health plan will work with that example. Then need to apply the following tests to that:
–Patient gets an A1C one month early (so need to adjust future reminders)
–Patient gets an A1C on month late (so need to adjust future reminders)
–Patient entirely skips an A1C (not sure what is needed here)
–Repeat above for foot exam, optho exam, and flu shot (note flu shot is easy because it’s seasonal)
I do not think your current algorithm will be able to adjust to these extremely common scenarios. Once your algorithm can actually cope with real world behavior, then it seems logical that the clinical alert summary widget could simply leverage the data within the Health Plans.

Individual File Reviews
interface/batchcom/batch_reminders.php
-what is siteID and token stuff at maviq?? (should this go in interface/globals.php)
-I’m confused by the status indicator.
----What if patient who’s been seen for awhile decides to allow messaging and email. Won’t they then get a bunch of out of date messages and emails from the reminders table.
----What if user is getting both messages and emails? If message fails and email works, then status is ok (isn’t that an issues that messages failed). I’m assuming this script will also be used to send out mail reminders. Just seems like these should have separate status mechanisms.

interface/globals.php
-clarify HTML charset (ie. for email; could be confused with other charset stuff)

interface/main/left_nav.php
-no input since this will change with the GUI refactoring

interface/patient_file/health_plans/health_plans_admin.php
-instead of using formTrim(variable), use formDataCore(variable,true)
-whenever you echo into a value tag with a variable use htmlspecialchars(variable, ENT_QUOTES); (example line 1936 of patch)
—or else ’ and “” will break it
-If possible, try to avoid stuff like ucfirst() and strtolower(), since this has a habit of breaking utf8 encoding of different language characters (example 2165 and 2166)
-See 1) for main conceptual issues i have

interface/patient_file/health_plans/health_plans_patient.php
what is the point of showing all the uneditable items (filters etc.)?

interface/patient_file/health_plans/manage_categories.php
-seem ok

interface/patient_file/health_plans/patient_reminders.php
-Why this at line 3537 of patch within the sql: strip_escape_custom($_POST)  ???
-whenever you echo into a value tag with a variable use htmlspecialchars(variable, ENT_QUOTES); (example  at line 3558) (lots more…)

library/classes/class.phpmailer.php
-seems ok

library/classes/class.smtp.php
-seems ok

library/classes/postmaster.php
-seems ok

library/maviq_phone_api.php
-seems ok

library/phpmailer.lang-en.php
-seems ok

sql/3_2_0-to-3_3_0_upgrade.sql

  • on your lists, consider making the option id’s all non-caps and without whitespace(use _ instead). This make it easier to use them in the algorithms and especially reduces risk of any sql upgrading traps in the future.
  • i’ll defer database structure stuff to Rod
    ( I am assuming you are testing this script now…)

sql/database.sql

  • on your lists, consider making the option id’s all non-caps and without whitespace(use _ instead). This make it easier to use them in the algorithms and especially reduces risk of any sql upgrading traps in the future.
  • make the ‘seq’ stuff the same as in your sql/3_2_0-to-3_3_0_upgrade.sql
  • i’ll defer database structure stuff to Rod

If we decide to go the new phpmail route, then thinking it would be best to just get this committed into SF soon so other groups that want email in their code can use this mechanism also.
-brady

3

bradymiller wrote on Wednesday, January 27, 2010:

hey,

Not even gonna attempt to deal with formatting to get above message to look better, will email to Thomas. If anybody else wnat to see it, just send me an email.

-brady

4

wooyi wrote on Wednesday, January 27, 2010:

To deal with these situations:
–Patient gets an A1C one month early (so need to adjust future reminders)
–Patient gets an A1C on month late (so need to adjust future reminders)
–Patient entirely skips an A1C (not sure what is needed here)

Here’s my 2 cents on how to make it fairly simple, yet workable.

The algorithm has to calculate the next due date one instance at a time. Initially only the next reminder is calculated, and when that task is completed or refused, the next reminder is calculated, based on the repeat delay (ie 3 months). For the last case, if a patient entirely skips the tasks, that task will remain overdue and a repeated instance of the reminder is never created. There can be a cron job that periodically checks for tasks that have been overdue for over a time period and resends the reminders. If you want to be more sophisticated  you can have a “count” on each reminder to keep track of the number of retries and to limit them to a max… say a reminder will retry for 3 times, with a month between retries… then it will just stop and the patient is on his/her own… there is only so much we can do.

5

anonymous wrote on Wednesday, January 27, 2010:

Hi Brady,

Currently, we have two ways to changing the action start dates:
1. Go to Health Plans in Patient/Client section, open up an enrolled plan, and you can adjust the startup date for any action in there. All reminders for that patient are renewed (i.e. delete and create new) when you save. This is the easiest way to deal with changes. The provider can do this with the patient while s/he is in the office or on the phone.

This also answer your other question regarding the grey-out fields. We want to show the entire plan so that the doctor can review it with the patient and make any needed changes.

We have already discussed how to repeat any action. It’s done by simply adding a new action to the plan. You can adjust the repeat action startup date in the same way.

2. Go to Health Plans in the Administration section, and you can change the startup dates for all patients. When you save the changes for a plan, the reminders for all patients enrolled in the plan are renewed.

6

bradymiller wrote on Wednesday, January 27, 2010:

Thomas,

Isn’t the point of this automation? Not feasible to expect practitioners to modify action dates for almost every patient for almost action (and future repeat actions); again, patients are almost never reliable. Also not feasible to expect practitioners to review/modify these plans with their patients. Code is mature enough; I think it’s now an ideal time to show a proof of concept utilizing diabetes with my above basic real life situations.

-brady

7

anonymous wrote on Wednesday, January 27, 2010:

Hi Brady,

My recommendation is not to automate it. I have configured and use a multi-million enterprise system. It has “some” action frequency automation just like what you said. However, it is very costly to develop, complicated to use, and creates many maintenance problems because you cannot cover every scenario. In addition, a patient may have multiple health plans. There is almost no way to deal with multiple health plans without checking with the patient to see what is going on.

Here’s the diabetes example:
Action 1: Perform an annual dilated eye exam on 1/1/2010.
Action 2: Perform a quarterly A1C test (#1) on  2/1/2010.
Action 3: Perform a quarterly A1C test (#2) on  5/1/2010.
Action 4: Perform a semi-annual foot exam (# 1) on  3/1/2010.
Action 5: Perform a quarterly A1C test (#3) on  8/1/2010.
Action 6: Perform a quarterly A1C test (#4) on  11/1/2010.
Action 7: Perform a semi-annual foot exam (# 2) on  9/1/2010.

Here are some scenarios:
1. If a patient is late for Action #1, do we need to push everything back? Probably not since it doesn’t affect the other items. But how do we know that in advance in order to automate the process?

2. If a patient is one week late for Action #2, do we want to push it back? What about two weeks? How late is late? How do we automate that for every action item? What if the physician says, "You are two weeks late for Action #2, but due to our busy office schedule, please come in for Action #3 as scheduled.” How do we account for that?

3. If a patient is one month late for Action #2 and wants to do it together with Action #4, how can we predict that?

4. What if a patient has two health plans: flu shot and diabetes? The patient calls and wants to come in early for a flu shot while he/she gets the A1C test. But we don’t want to change the next appointment date for flu shot because it will be out of season (or the flu shot may not be available yet).

The easy way is the manual way or we could spend weeks on building a complicated system that may not work.

8

blankev wrote on Wednesday, January 27, 2010:

Or do it both! Manual and Automatic. But be sure to leave a remark as “should be revised” due to (non-)compliance reasons.

So if the quarterly A1C test was not done, automatic review will show that some tests could be postponed and others should continue as stipulated. But since the reviewing person (doctor/nurse has to revise, the real world options can be changed and get everything in the normal schedule again and give the necessary tests preference.

Pimm

9

anonymous wrote on Wednesday, January 27, 2010:

Hi Pimm,

I would treat Health Plans more like a guideline or to-do-list. To do the kind of automatic review that you want will require even more work. It will need to be integrated with the appointment system and CPOE (order entry) in order to know if a test has been performed, and if not, suggest when it can be rescheduled (based on test type and available slots). I have not seen this done in any system. This is way beyond the MU scope. Sorry.

10

sunsetsystems wrote on Wednesday, January 27, 2010:

Ignoring the above design issues, here are some comments on the code:

  3_2_0-to-3_3_0_upgrade.sql:

  * The new tables seem to have too many fields that permit null values.
    Could not most of these default to 0 or ‘’?  But as already noted,
    I do suggest use of a null date to indicate no date.

  batch_reminders.php:

  * You have a WHERE clause including this:
    “scheduled_date <= NOW() and scheduled_date != ‘0000-00-00’”
    In the case of a null date, the whole expression will evaluate to
    null which mysql treats as false, and so you get the desired
    result.  However this is poor and confusing programming practice.
    Better and more clear is something like:
    “scheduled_date is not null and scheduled_date <= NOW()”
    (assuming you are not permitting entry of 0000-00-00).
    See also:
    http://dev.mysql.com/doc/refman/5.0/en/working-with-null.html

  * Why is there a hard-coded URL:
    $endpoint = “https://174.143.155.231:8443/Maviq_CarePlus/rest”;
    That can’t be right.

  * Error messages are being displayed without using xl().

  globals.php:

  * Why are $webserver_root and $web_root set to empty strings?

  * Why do you need $HTML_CHARSET?  When would it not be UTF-8?

  manage_categories.php:

  * You can use formData() now instead of ffescape(), and many references
    to form fields are not using either.

  health_plans_admin.php:

  * Lots of code here, I have no comments but did not have time to study it in detail.

  health_plans_patient.php:

  * Nothing major jumps out at me, but there are some text strings that need
    to be wrapped in xl().

  manage_categories.php:

  * Just skimming, seems OK.

  patient_reminders.php:

  * Just skimming, seems OK.  Some lines of code are very long and should be
    split up for easier readability.

  I’m not interested in reviewing phpMailer.  :slight_smile:

Rod
www.sunsetsystems.com

11

bradymiller wrote on Wednesday, January 27, 2010:

Thomas,

Please don’t confuse the situation with more scenarios. Why not solve my simple ones first? Also, bringing up multi-million dollar projects or the multi-decade experience of your DBA is not helpful. Focus on the problem, which is that your algorithm and database schemes can not yet realistically deal with my simple real-life scenarios.

As Wooyi (whom I feel the need to state is the author/admin of Mavic) eludes to, perhaps a better option is to calculate the next due date one instance at a time. Logically, when I go through your algorithm and database scheme the flaw seems to be applying frequency to the entire plan, rather than the action items themselves. For example, if I said action item #1 was an A1C and to repeat it every 3 months then you have the information in place to deal with all my simple scenarios. Then you can move onto more complicated scenarios…

-brady

12

anonymous wrote on Wednesday, January 27, 2010:

Hi Brady,

We need to keep the work within budget, meet the delivery date, and not to do anything beyond the MU requirements. Your comments implied that you will add more requests beyond the action frequency. So I shared with you lessons learned to avoid costly mistakes. It’s very easy to get carry away with ideas.

If all you want is to automate the reminders frequency for selected actions, then it can be added as a configuration option for each health plan. So if you pick 4 for an action, it would repeat itself to a total of 4. And if you change the start date “manually” for any action for each patient, then the dates can be adjusted automatically. The complication is that we also need a manual button to override the automatic adjustment. The complication increases when you look at other health plans. An example is flu shot, the frequency needs to be in seasons. So we also need a begin date and an end date for each action. The more scenarios we look at, the more complicated it becomes.

In my opinion, it’s best to defer health plans management to the patient. I would suggest granting online access to the patient as per MU #19 (http://www.openmedsoftware.org/wiki/Patient_Electronic_Access_to_Health_Information). I have seen several online systems that do this well.

13

bradymiller wrote on Wednesday, January 27, 2010:

Thomas,

I don’t buy it. What I’m suggesting is very feasible, and it’s really not that complicated. There’s an opportunity here to build a “clinical decision support” rules system, and your health plans is not that. Where in MU does it state that standard care health plans and clinical decision support rules should be modifiable for each patient (even so, if you really wanted this feature could always create custom “feel good” health plans for each patient that a physician could play around with in all their free time or the patient to dabble with over the internet; ie. “I’m sick of being reminded for my annual PAP, delete…”).

Resource-wise, after developing a sophisticated filtering engine and input mechanism for the Health Plans, you are now developing a separate sophisticated filtering engine and input mechanism for the Clinical Alerts. Considering both of these mechanisms will in fact be using the same rules, why not build one that works first and then leverage it for the other.

-brady

14

anonymous wrote on Wednesday, January 27, 2010:

Hi Brady,

I have already presented you with the proposed solutions for your scenarios.

–Patient gets an A1C one month early (so need to adjust future reminders)
So you adjust the date manually for Action #1. The other three will adjust automatically. But an override button is needed in case it’s not early enough to move the other three actions forward.

–Patient gets an A1C on month late (so need to adjust future reminders)
So you adjust the date manually for Action #1. The other three will adjust automatically. But an override button is needed in case it’s not late enough to push the other three actions back.

–Patient entirely skips an A1C (not sure what is needed here)
Then you just add a new action or move into the new year.

– Flu shot
I already said what is needed (begin and end dates for each action).

My point is that we need to look at each of the health plans or tests to see what else is needed. Otherwise, we are building 1 solution at a time. The solution may only work for the one that we focus on.

As for clinical alerts, it’s being integrated with the health plans. The work is not done yet. Why do you say that it’s separate from the health plans? I have not sent you the codes yet.

15

bradymiller wrote on Wednesday, January 27, 2010:

hey,

How will the other three A1C’s adjust automatically if the interval is not know? The point here is I see no solution that allows you to get away without assigning intervals(or month of year for flu shot) to each target. And if you follow this logic:
-then there is no need for a frequency and number of years entry in the Health Plan entry itself.
-there is no need for multiple targets of same issue (A1C) if follow regular intervals

My scenarios are simply sanity testing. I don’t want to get ahead of myself, but the next scenarios are:
1) What happens in the year 2011
1) Seasonal flu shot
2) Series shots (like hep B shot)
3) Redundant targets across different health plans (ie. flu shot in DM and preventative health)

If you can cover these and my previous scenarios, then it will be useful; otherwise garbage-in/garbage-out as far as I’m concerned.

I saw the clinical_alert database schema in your patch which is eerily similar to the health plans schema.

-brady

16

anonymous wrote on Wednesday, January 27, 2010:

The “interval” is given if you go with automatic adjustment.

1. To automate it, we would extend the changes to the next year. This will double the amount of patient reminders in the table. In practice, the provider should review the plan with the patient once a year.

2. Seasonal flu is already covered. It needs a begin date and an end date to prevent the actions from moving outside the seasons. Is it worth doing it just for flu shot? Because the two dates could be misused for other actions. We can put a condition in the codes to restrict their use, of course. But why we do want to treat this one specially and not the others?

3. Series Shots. I think this is more commonly managed in a med injection/lab system. If you want to use Health Plans to manage it, then just break the series down into multiple actions. The interval is useless here if the series has inconsistent intervals, e.g. 1st one in 1 week, 2nd one in 4 weeks, and third one in 10 weeks. The first step is to look at all the series to see what kind of intervals they have.

4. Use a separate flu shot plan or create an integrated plan to take care of all the actions. No easy automation can be done here.

17

blankev wrote on Wednesday, January 27, 2010:

Brady, Thomas and others,

working on this sub-OpenEMR project, is there a of making this part a WEB-installed version?

To have a working real life version as proposed by the Developer?

I think you both say the same thing in different words. So if we can test the prototype we can see where the problems might arise? And we sure will find a solution for the possible contradictionsor as you like to call them different opinions.

Testing without administrator rights is not a real life test and only shows the possible options!

Pimm

18

bradymiller wrote on Wednesday, January 27, 2010:

Thomas,

Being a clinician; I would argue in practice the clinician should never have to “review” and manually configure the plan with the patient. “Hi, Mr. Patient, lets go through these 10 plans that apply to you and data entry the changes etc.”  I’m just having a hard time understanding:
why you have the following:
-health plan frequency
-years to repeat
and not the following:
-target frequency

With a target frequency your reminders and alerts could produce one instance per target, and then create another one at that interval once it’s complete(hence, no need for the physician to ever modify the actions except to check complete). This is an issue I have brought up consistently during development of this system, never got a good reason, but figured maybe I was missing something.  But now that the code is nearing “completion”, this still seems to be a fundamental flaw.

-brady

19

anonymous wrote on Wednesday, January 27, 2010:

Hi Brady,

“I don’t do data entry” is the complaint we often hear when we ask a provider to start using an EHR ;-).  I have actually seen it done at several places.

Health plan frequency is an option for a plan that has only one or two actions and one that needs to be repeated within the same year.
e.g. flu shot (for healthy people who don’t need to do anything else.) We have not reviewed all the different health topics. So this is an option that can be kept or removed.

Years to repeat - this is useful for determining the completion status of a health plan. It’s also good for such plans as biannual mammogram or biannual pelvic exam.

Currently, there is no need to change the actions, except for the start dates. You can see that most of the fields are grey out. But based on our discussion here, there will be more fields to change if we address your scenarios (i.e. when the provider wants to override the automated settings).

I’m not sure what you meant by check complete. So do you want a status for each action? I thought you wanted an interval. So are we now holding the provider responsible for checking each action status? If the provider forgets to do so just one time, the patient will not get any more reminders. 

20

bradymiller wrote on Thursday, January 28, 2010:

hey,

So:
health plan frequency isn’t needed since it won’t cover multiple targets (why have two separate frequency mechanisms)
Years to repeat isn’t needed, because you already have an age filter in the health plan

The last thing is target frequency, which we obviously do not agree on. If enable a target frequency or date (not with year), then you could potentially cover scenarios 1-4 above (the scenario combo with year 2011) automatically and indefinitely.
1) set one A1C target frequency, and your done
2) set the ideal flu shot target date (10/15) without the year, and your done
3) set multiple identical hepB targets with dates, and your done
4) if the target names are found in the same health plan, simply use the most stringent/recent one

Forget I mentioned the check the status thing for now (I was getting ahead of myself and this is part of clinical alerts, which should tie in with the health plans and reminders at some point down the road.)

-brady
-brady