[Gnumed-devel] Enhancement proposal: Medication cloning

[Busser, James]

Presently, when you would make a change to a patient's schedule for example to 
increase or lower the dose, you have these choices:

=============================
 select a medication and edit it, but

1) the tooltip "Revision: # " > 1 is the only indication of the change

2) you cannot easily see from the medication list the previous values for this 
*drug* was originally started, or at what dose, and what other maximum and 
minimum dosages have been tried, because each edit will cause the previous 
version to be ON UPDATE copied over to the audit table, and this is accessible 
only to gm-dbo only to gm-dbo (and not via Report plugin), and even with gm-dbo 
access to Office > Audit trail menu, there are no provisions to filter the 
relevant information in the way that would be desired.

=====================================
select a medication and set it to be discontinued

then 'add' the same medication
        - input often-different schedule information (which you would do anyway)

        but also
        - ensure to pick the same branded or unbranded substance
        - sometimes re-input the same episode
        - sometimes re-input the same aim and advice information

While tedious, this allows better patient care because while you can still view 
*just* the current medications, you can optionally 

        include [  ] inactive

        Sort by (  ) Brand

and see the changes over time (see screenshot) wherein the tooltip allows to 
easily see the reason for the change.


I think it warrants a rethink of a couple of things:

1) to achieve this, you do not Delete a drug. Instead, you Edit and discontinue 
it

2) except you are not necessarily discontinuing that *substance*, you may just 
be changing brands or adjusting the schedule

3) therefore in the place where we currently input

        Discontinued <date>
                … Reason
        it might be better to generalize this to
        
        Changed <date>
                … Reason

        where '… Reason' could be

                still symptomatic
                BP not yet at target
                HbA1C not yet at target

4) if it is reasonable to relabel 'Discontinued' to 'Changed' then a change 
would also be needed in the tooltip

5) we see from the example that a change of Brands, sorted by Brand, will 
depend on the substance having the same or similar name but sometimes a brand 
is changed for reasons of cost or availability which will make it hard to see 
what is going on. Can we add a

        Sort by (  ) Substance 

        where the sort order would be Substance, Started, Strength descending 
(in case a regimen was composed of two strengths)

6) should we lose the 'per plan' button? My reasoning is:

- sometimes there is a reason worth recording even when it was not our idea e.g.
- patient gets side effects, lowers dose on their own, sees us, we agree to 
continue with this lower dose, it was not our idea but we are agreeing to it. 
So, it was not really our plan, but we do wish to preserve the reason for the 
change (which we cannot presently do, unless we click the 'Per plan' button.) 
This raises the question "what if we do not approve of this dosage?" Well, we 
can uncheck 'Approved of' so that instead of using it only for unapproved-of 
substances (cigarettes, street drugs) it could also indicate unapproved-of 
regimens or schedules.

This way, we can have 'reason' to be available any time we would make an 
alteration.

7) how can we make it easier to perform a paired task:

        preserve an updated copy of the original in clin.substance_intake

        also create a 'new' row when the drug is not being fully discontinued

as distinct from

        I wish to tweak the information or instructions (including typos) and 
have no need to keep handy the old one

What about resolving it inside the Edit function (which I suggest to rename to 
Change):

- user changes whatever information is needed to be changed (including 
previously-empty column info)

- the field 'Discontinued' would be better labelled 'Changed'  with the tooltip 
hinting 'When did, or will, the existing schedule change?'

- before clicking OK, user decides whether they wish to 'uncheck' a 
checked-by-default option

                [  ] preserve prior entry among inactive medications

- if they *uncheck* it, it behaves like the current Edit function (the original 
is simply copied into the audit table) and only a single copy resides in the 
table clin.substance_intake

- if they *keep* it checked,  clin.substance_intake will have two rows:

        - one to hold the original data (including 'date last taken' and an 
incremented revision number)
        --> essentially current Edit *where* a date of discontinuation has been 
inputted

        - one to hold the new data (including the reason for this new schedule)

e.g. original was metoprolol 100 mg bid (1 - 0 - 0 - 1) long-term, beginning 
October 1

patient returns October 7 complaining of ++ fatigue, feeling cold and says that 
for the past two days (October 5, 6) plus this morning, they have taken only 
half (50 mg) twice daily and today they feel a little better but wanted to make 
sure this was ok to have done

under the proposed enhancement:

        click Change button
        input date of change of October 4 since that was when they last took 
100 bid
        do not bother to click 'Per plan' … we simply leave checked [  ] 
'Approved of'
        input reason 'did not tolerate 100 bid (++fatigue, cold)'
        input new schedule 0.5 - 0 - 0 - 0.5
        leave checked [  ] 'Long-term'
        leave checked [  ] 'preserve prior entry among inactive medications'
        click OK

result:

        inactive will list

                metoprolol 100 mg 1 - 0 - 0 - 1 Started Oct 1, 2011 Until Oct 
5, 2011

        active will list

                metoprolol 100 mg 0.5 - 0 - 0 - 0.5 Started Oct 6, 2011 
Duration ∞

                tooltip shows 'Reason: did not tolerate 100 bid (++fatigue, 
cold)'


When you think about it, this is actually helpful, to know the reason that they 
are 'on' their current schedule of 50 bid (because they had trouble with 100 
bid) instead of the reason why they are not on what they are not taking.

It would also make sense to relocate the main plugin's Delete button inside 
this Change widget. I know Karsten previously balked on the basis that 
'Deleting is distinct and different from Editing' but the counter-argument is 
that presently we warn people who would delete a record that they should alter 
the clinical data before they would do the deletion which is no more 
semantically correct.

Placing the function which we are calling 'Delete' inside the Change widget 
would

- allow the reason information to be entered
- allow a button Discontinue to be clicked and which would, in combination with 
        [  ] preserve prior entry among inactive medications

do as follows:

- when Discontinue has been clicked, no extra row will get created in 
clin.substance_intake. Instead, what will happen is that all inputted changes 
will get written as an updated version of the original record, with a copy of 
the original trigger-written into the audit table and where the effect of

        [  ] preserve prior entry among inactive medications

will be whether or not to delete the original after the update has been done:

(a) in the normal case, we would preserve it, because it is nearly invariably 
clinically helpful to see when (in the past) a patient did in fact receive a 
medication

(b) in the case of a mistaken entry -- say a drug had been entered on the wrong 
patient record, and provided they did not receive and fill (much less ingest) a 
drug they weren't supposed to, you could justify to uncheck [  ] preserve (and 
in any case, the mistaken original would still live in the audit table)

-- Jim

Medication history.png
Description: Medication history.png

ATT00001.txt
Description: ATT00001.txt