Medication viewing

[Jim Busser]

Just wondering if some concepts may be future-compatible with current  
construction:

The universe of what is relevant for a patient could include

a. what they had *ever* taken
b. what is currently available to the patient
c. what the patient is *advised* to be taking
d. what the patient *accepts* to be taking

The above is compounded by:
- self-medication is possible, even without a prescription
- a patient may not continue to take a medication in the dosage  
originally prescribed or advised
- a patient may refuse to try a therapy which may therefore not ever  
get prescribed

Traditionally we do not capture a refusal of therapy in a medication  
list, except *after* the medication had been tried. After the  
medication had been tried with refusal of adherence, the medication  
may be considered Intolerated or maybe just ineffective and therefore  
never makes it into Allergy/Intolerance and only into an archive of  
what *had* been tried.

Leaves me wondering about pre-emptively entering (into the Allergies /  
Intolerances) drugs which the patient would refuse to take. if we  
might do it for beta-blockers in asthmatic patients there is no reason  
a clinical group might not choose to use this method.

When making therapeutic choices, one might ideally be presented  
choices based on cost-effectiveness, and these could be listed against  
what a patient currently takes (or did previously take) and against  
whether there is a recorded allergy or intolerance. Notably a patient  
may agree to use a drug even despite that it gives side effects the  
patient can accept even while the information was entered in  
Intolerances. A display might set out (side by side)
        Options History Notes

Perfect-world would populate Options based on clinical decision  
support but even before that it should be possible to select drug  
categories (anti-depressant, anti-hypertensive, diuretic etc). The  
"Options" would list either generic single agents or maybe generic  
combos (trimethoprim-sulfa) -- not sure about that one -- or  
proprietary which may be combos.

The "History" would list whether there exists a current or past match  
for the drug.
- In absence of any match, the History would be blank
- in presence of a match, shown could be the date last started (+-  
stopped) plus the regimen
- regardless of History, if it was a drug for which there was a drug-
specific or class Allergy / Intolerance, that info would be displayed  
under the Notes column.

When Options are not having to be considered, the History listing  
would include what we know as the "Medication list (Current  
medication)" plus previous medication and could take into account  
whether the listed medications are intended to continue in perpetuity  
(as with chronic disease, maybe a duration symbol "+" and whether they  
have an anticipated ("soft") stop or supply reassessment date that may  
be understood distinctly from (hard) stop dates that denote an  
intentional discontinuation by patient (intolerance or ineffective or  
not needed) or doctor (intolerance or ineffective or not needed).

- provide unique listings, according to drug-strength-dosage, noting a  
single drug could appear in multiple active drug-strength-dosage  
listings (since not all daily/weekly regimens can be managed by  
fractions and multiples of tablets)

- filter / sort:
        "Group A" = current (blue) = "soft_stop_date" is {NULL or future-
dated} and hard_stop_date is NULL
        "Group B" = undefined (orange) = "soft_stop_date" is today-or-past-
dated} and hard_stop_date is NULL
        "Group C" = stopped (grey) = hard_stop_date is not NULL (NULL not >  
today)

... the idea of Group B allowing to identify patients whose medication  
may need special review whether for decision-making and/or adequacy of  
medication supply. You would only put in the hardstop date when you  
confirmed at the next visit that the patient actually stopped their  
medication as instructed at the prior visit, and when (if able to be  
determined). Red might be useful in relation to a supply calculated to  
be expired. It is not fully thought through, I can already see a  
conflict between "supply" and "clinical intention" but though I would  
at least share the general concepts.


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Thu, Oct 22, 2009 at 06:14:28PM -0700, Jim Busser wrote:

Excellent thoughts, most of which should be captured in the
Wiki for reference. There's one design concept and one
design goal to be kept in mind for the time being:

        No mixing of clinical and administrative concerns.

        The goal for this iteration of medication handling is
        recording the last known status quo of patient substance
        intake. Anything beyond that is currently optional (but
        worth considering such as to stay compatible with extensions).

> The universe of what is relevant for a patient could include
>
> a. what they had *ever* taken

There's a full audit trail which carries this information.

> b. what is currently available to the patient

This is an administrative concern.

> c. what the patient is *advised* to be taking

Regardless of what the patient is actually taking, right. We
support that by means of an intake_is_approved_of in
clin.substance_intake (btw, the schema docs are online now).

> d. what the patient *accepts* to be taking

This will be captured in a mixture of pre-maturely
discontinued medication (best accompanied by a clinical
note), allergies/and intolerances records, and clinical
narrative.

> The above is compounded by:
> - self-medication is possible, even without a prescription

And we cater for capturing that should the patient relate
appropriate information.

> - a patient may not continue to take a medication in the dosage
> originally prescribed or advised
> - a patient may refuse to try a therapy which may therefore not ever
> get prescribed

This would usually result in a clinical note documenting as much.

> Traditionally we do not capture a refusal of therapy in a medication
> list, except *after* the medication had been tried. After the
> medication had been tried with refusal of adherence, the medication
> may be considered Intolerated or maybe just ineffective and
> therefore never makes it into Allergy/Intolerance and only into an
> archive of what *had* been tried.
>
> Leaves me wondering about pre-emptively entering (into the Allergies
> / Intolerances) drugs which the patient would refuse to take. if we
> might do it for beta-blockers in asthmatic patients there is no
> reason a clinical group might not choose to use this method.

Sounds reasonable to me.

> When making therapeutic choices, one might ideally be presented
> choices based on cost-effectiveness,

Surely so but purely administrative.

> a patient may agree to use a drug even despite that it gives side
> effects the patient can accept even while the information was
> entered in Intolerances. A display might set out (side by side)
> Options History Notes
>
> Perfect-world would populate Options based on clinical decision
> support but even before that it should be possible to select drug
> categories (anti-depressant, anti-hypertensive, diuretic etc). The
> "Options" would list either generic single agents or maybe generic
> combos (trimethoprim-sulfa) -- not sure about that one -- or
> proprietary which may be combos.
>
> The "History" would list whether there exists a current or past
> match for the drug.
> - In absence of any match, the History would be blank
> - in presence of a match, shown could be the date last started (+-
> stopped) plus the regimen
> - regardless of History, if it was a drug for which there was a
> drug-specific or class Allergy / Intolerance, that info would be
> displayed under the Notes column.
>
> When Options are not having to be considered, the History listing
> would include what we know as the "Medication list (Current
> medication)" plus previous medication and could take into account
> whether the listed medications are intended to continue in
> perpetuity (as with chronic disease, maybe a duration symbol "+" and
> whether they have an anticipated ("soft") stop or supply
> reassessment date that may be understood distinctly from (hard) stop
> dates that denote an intentional discontinuation by patient
> (intolerance or ineffective or not needed) or doctor (intolerance or
> ineffective or not needed).
>
> - provide unique listings, according to drug-strength-dosage, noting
> a single drug could appear in multiple active drug-strength-dosage
> listings (since not all daily/weekly regimens can be managed by
> fractions and multiples of tablets)
>
> - filter / sort:
> "Group A" = current (blue) = "soft_stop_date" is {NULL or future-
> dated} and hard_stop_date is NULL
> "Group B" = undefined (orange) = "soft_stop_date" is today-or-past-
> dated} and hard_stop_date is NULL
> "Group C" = stopped (grey) = hard_stop_date is not NULL (NULL not >
> today)
>
> ... the idea of Group B allowing to identify patients whose
> medication may need special review whether for decision-making
> and/or adequacy of medication supply. You would only put in the
> hardstop date when you confirmed at the next visit that the patient
> actually stopped their medication as instructed at the prior visit,
> and when (if able to be determined). Red might be useful in relation
> to a supply calculated to be expired. It is not fully thought
> through, I can already see a conflict between "supply" and "clinical
> intention" but though I would at least share the general concepts.

This is something to be captured for later use.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-10-23, at 4:07 AM, Karsten Hilbert wrote:

>> The universe of what is relevant for a patient could include
>>
>> a. what they had *ever* taken
>
> There's a full audit trail which carries this information.

Once a row has been created in the medication listing, it can display  
the {drug, dosage, schedule} as it was last known to be taken by the  
patient. However the simple existence of an item

        acetylsalicylic acid 81mg daily

created three years ago and which needs no prescription does not mean  
the patient continues to take it. Maybe nine months ago their surgeon  
directed it to be stopped a week before surgery and no-one ever made  
clear that it was supposed to be restarted. This is an inverse of the  
allergy situation where just because "No allergies" was true when  
asked 5 years ago it is worth verifying from time to time (if not  
every visit) and maybe capturing this verification. Can I attract us  
to a medication column

        last_confirmed (date, maybe NULL is ok in a case where the  
information was pre-entered from documentation and it turns out the  
patient says "no, that's wrong")

??

The end result is a set of rows that always contains the last-altered  
version. At discontinuation, the row could be updated to reflect when  
a patient last used it, as well as the reason for discontinuation  
which could be any combination of not needed, not tolerated or not  
effective. But unless a row can be deleted:
- the rows will always represent a mix of current and no-longer used  
medications (i.e. not just current medications)
- the rows will not offer a complete history (as some alterations  
would be in the audit file).

So.. the "current medications" might more correctly be seen as a  
partial index of drugs that the patient did, at some point, take and  
*may* currently be taking. For drugs that are no longer being taken,  
we could see the most-recent regimen as last-used. But a key  
dependency as to whether it is a complete index is whether, upon  
changing the strength of a drug (or changing brands), the doctor  
discontinued an existing row and added another or just made the  
alteration inside the row. That affects whether it is an inventory of  
*medications* that the patient has used, or medication *regimens* that  
the patient has used. I imagine that for this table we are preferring  
medications, but a regimen that mixes different strengths maybe has to  
be handled in two rows. Failure to do so might greatly complicate  
later efforts to administer the supply (prescribing).

At the point where in future we will want to view the total history of  
any drug, will it be no trouble to query-combine information from the  
current medication table with information taken from an audit table (I  
am supposing the audit table constraints would protect against  
inappropriate alteration)?



_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-10-23, at 4:07 AM, Karsten Hilbert wrote:

>> a patient may agree to use a drug even despite that it gives side
>> effects the patient can accept even while the information was
>> entered in Intolerances. A display might set out (side by side)
>> Options History ...
>
> This is something to be captured for later use.

Allocated across

http://wiki.gnumed.de/bin/view/Gnumed/CurrentMedicationList#Desirable_layout_inside_GNUmed

and

http://wiki.gnumed.de/bin/view/Gnumed/CurrentMedicationList#Future_consideration


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

I am very much liking what a medication list can offer us, depending  
on how we further think it through.

Let us imagine that we last saw a patient 6 months ago on April 15 for  
high blood pressure, and we started them on a 3 month supply of let us  
say ramipril, and the patient was *supposed* to come back 3 months ago  
in July, but was busy and did not manage to do so until now (say  
October 15)

... their medication list (until we would update it) would still show  
the ramipril as a "current medication" even though we may be able to  
know from the progress note or from a yet-to-be-created prescribing  
function that their supply would have run out in July

I now prescribe a new supply, and at the point where the patient again  
starts on the medication, the list will be correct. However (and this  
is important) I do not want it to appear that the patient has been  
taking this drug continuously since April. While it is true that the  
notes can contain a record of the explanation, there is 9to me) still  
value in being future-able to computationally show what the patient  
was taking at various points in time.

I would want to make the medication list show that the ramipril was  
stopped July 15 owing to a lapse ("ran out"). As soon as I make this  
change, the drug is no longer a current medication. However I will  
wish (before the end of the visit) to again *make* it a current  
medication.

For this reason, I do not want the original ramipril row to disappear  
as "deleted" from the Medication list. As soon as I would modify it,  
to make its status discontinued at at July 15 for reason "lapsed / ran  
out", a copy of the original would be preserved in the audit table

Among the records in the Medication List, the ramipril would  
presumably auto-sort lower down the list (into Group C as proposed in  
the last 24 hours) but it would be from the convenience of this  
location that I would want to re-activate it as newly current.

Is there disagreement here?

It would mean that within the Medication List, it would only be a  
subset of records that represent the current medications (substances).  
others would be recorded as having lapsed (without being restarted) or  
discontinued for lack of tolerability or effectiveness or  
affordability or desire or need. The difference could be managed in  
the filtering of the display and any ambiguity avoided by the use of  
last_used and status fields.


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-10-23, at 4:07 AM, Karsten Hilbert wrote:

We support that by means of an intake_is_approved_of in
clin.substance_intake (btw, the schema docs are online now).

re schema...

I notice within clin.clin_medication a column drug_db but no other table to which this relates... 

I would expect that row creation by the clinician would be aided by a phrasewheel so I wondered whether the source (drug database) remains yet to be created in the schema?

Also I wondered how the tables below relate to the one above:

clin.active_substance

(Active) substances (consumables) a patient may be taking.

clin.consumed_substance

Substances currently or previously actually being consumed by patients

clin.substance_intake

The substances a patient is actually currently taking.

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

> > We support that by means of an intake_is_approved_of in
> > clin.substance_intake (btw, the schema docs are online now).
>
> re schema...
>
> I notice within clin.clin_medication a column drug_db but no other  
> table to which this relates...

Never mind that table ;-)   It is outdated.

The relevant tables are:

> clin.substance_intake
>  The substances a patient is actually currently taking.

This is the table holding the actual medication records.

> clin.consumed_substance
>  Substances currently or previously actually being consumed by patients

This table holds the *substances* (Metoprolol, tobacco, Phenprocoumon,
alcohol ...) patients are taking. I am still thinking of folding this
into substance_intake itself.

> clin.active_substance
>  (Active) substances (consumables) a patient may be taking.

This table normalizes active ingredients of brands (for which there
is no definite table yet).

We are so far lacking a table to link together "substances being taken"
into combinations such that such combinations can be documented regardless
of brand.

Karsten
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-10-23, at 3:27 PM, Jim Busser wrote:

I am very much liking what a medication list can offer us, depending on how we further think it through.

... (snip)

For this reason, I do not want the original ramipril row to disappear as "deleted" from the Medication list

I maybe misunderstood the audit constraints... I think we *do* actually permit clinical table records to be deleted... (upon which they are copied into an Audit table).

The GUI would need to provide buttons to distinguish whether to delete a row, or just mark a medication discontinued, but if a medication were to be marked "discontinued" (say, stopped at a datetime prior to current) would auto-deletion of the row be proposed?

What then about putting a medication on "hold" without deleting it? The question may not be so simple as may have first seemed!?

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

A screenshot just for information.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

well, now

--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Fri, Oct 23, 2009 at 09:57:43AM -0700, Jim Busser wrote:

> The end result is a set of rows that always contains the
> last-altered version.
...
> - the rows will always represent a mix of current and no-longer used
> medications (i.e. not just current medications)
...
> So.. the "current medications" might more correctly be seen as a
> partial index of drugs that the patient did, at some point, take and
> *may* currently be taking.

Now, wouldn't that be a reality of life no matter how
precisely things are modelled ?

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Fri, Oct 23, 2009 at 09:57:43AM -0700, Jim Busser wrote:

> Once a row has been created in the medication listing, it can
> display the {drug, dosage, schedule} as it was last known to be
> taken by the patient. However the simple existence of an item
>
> acetylsalicylic acid 81mg daily
>
> created three years ago and which needs no prescription does not
> mean the patient continues to take it. Maybe nine months ago their
> surgeon directed it to be stopped a week before surgery and no-one
> ever made clear that it was supposed to be restarted. This is an
> inverse of the allergy situation where just because "No allergies"
> was true when asked 5 years ago it is worth verifying from time to
> time (if not every visit) and maybe capturing this verification. Can
> I attract us to a medication column
>
> last_confirmed

I would argue against that on the grounds that

a) we've got a (mandatory) .started from which the nature
   of the drug will prompt some consideration as to the
   validity of the entry

b) we've got a .duration field and and .is_long_term marker which
   are bound to give some indication as to the suspectable nature
   of the drug in question (which then lends itself to a), if
   those aren't used properly neither will .last_confirmed, likely

c) we've also got .last_modified from the audit machinery which
   can be different from .started if a row was changed to adjust
   for, say, different strength or schedule

d) it is not quite as crucial as with allergies to be hit upon
   the head to re-confirm the status quo, the above mechanisms
   may suffice for now

> The end result is a set of rows that always contains the
> last-altered version. At discontinuation, the row could be updated
> to reflect when a patient last used it, as well as the reason for
> discontinuation which could be any combination of not needed, not
> tolerated or not effective.

While I agree this seems desirable it does stray away from
the "current state of substance intake as best known to
date" design decision. Let us reserve that (in a documented
way) for the next iteration.

> But unless a row can be deleted:

It can.

> - the rows will always represent a mix of current and no-longer used
> medications (i.e. not just current medications)

And thus, no, except for when we don't yet know of the
no-longer.

> - the rows will not offer a complete history (as some alterations
> would be in the audit file).

In fact, *any* previous state will be found in the audit
table. The clin.substance_intake are designed to not show
any history (apart from what can be guessed at). That was a
deliberate decision.

> So.. the "current medications" might more correctly be seen as a
> partial index of drugs that the patient did, at some point, take and
> *may* currently be taking. For drugs that are no longer being taken,
> we could see the most-recent regimen as last-used. But a key
> dependency as to whether it is a complete index is whether, upon
> changing the strength of a drug (or changing brands), the doctor
> discontinued an existing row and added another or just made the
> alteration inside the row. That affects whether it is an inventory
> of *medications* that the patient has used, or medication *regimens*
> that the patient has used. I imagine that for this table we are
> preferring medications,

yes but "is using" not "has used"

> but a regimen that mixes different strengths
> maybe has to be handled in two rows. Failure to do so might greatly
> complicate later efforts to administer the supply (prescribing).

I don't currently comprehend the complication ?

> At the point where in future we will want to view the total history
> of any drug, will it be no trouble to query-combine information from
> the current medication table with information taken from an audit
> table (I am supposing the audit table constraints would protect
> against inappropriate alteration)?

I don't foresee trouble, no.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Fri, Oct 23, 2009 at 03:27:45PM -0700, Jim Busser wrote:

> Let us imagine that we last saw a patient 6 months ago on April 15
> for high blood pressure, and we started them on a 3 month supply of
> let us say ramipril, and the patient was *supposed* to come back 3
> months ago in July, but was busy and did not manage to do so until
> now (say October 15)
>
> ... their medication list (until we would update it) would still
> show the ramipril as a "current medication" even though we may be
> able to know from the progress note or from a yet-to-be-created
> prescribing function that their supply would have run out in July
>
> I now prescribe a new supply, and at the point where the patient
> again starts on the medication, the list will be correct. However
> (and this is important) I do not want it to appear that the patient
> has been taking this drug continuously since April. While it is true
> that the notes can contain a record of the explanation, there is to
> me) still value in being future-able to computationally show what
> the patient was taking at various points in time.

That's quite some: computationally. But, yeah, I do see what
you want here.

> I would want to make the medication list show that the ramipril was
> stopped July 15 owing to a lapse ("ran out"). As soon as I make this
> change, the drug is no longer a current medication. However I will
> wish (before the end of the visit) to again *make* it a current
> medication.

Agree.

> For this reason, I do not want the original ramipril row to
> disappear as "deleted" from the Medication list.

I understand.

> As soon as I would
> modify it, to make its status discontinued at at July 15 for reason
> "lapsed / ran out", a copy of the original would be preserved in the
> audit table

That is correct. You would do so by modifying the .duration
to, say "3/12" or "12/52" (which you *might* have done back
in April but not necessarily). By doing so the previous
state (life-long True, no .duration) would get sent to the
audit table. Upon re-activation as again-current I would,
again, modify the duration, and perhaps the instructions
("report back for repeat") or aim ("keep up good control of
HT"). Which would prompt another row in the audit table this
time preserving the previous already-run-out duration of 3
months.

> Among the records in the Medication List, the ramipril would
> presumably auto-sort lower down the list (into Group C as proposed
> in the last 24 hours) but it would be from the convenience of this
> location that I would want to re-activate it as newly current.
>
> Is there disagreement here?

That should work (except that we don't yet support the ABC
grouping in the client).

> It would mean that within the Medication List, it would only be a
> subset of records that represent the current medications
> (substances). others would be recorded as having lapsed (without
> being restarted) or discontinued for lack of tolerability or
> effectiveness or affordability or desire or need. The difference
> could be managed in the filtering of the display and any ambiguity
> avoided by the use of last_used and status fields.

Yes. Judicious use of the available fields would allow for that.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-10-29, at 11:47 AM, Karsten Hilbert wrote:

>> It would mean that within the Medication List, it would only be a
>> subset of records that represent the current medications
>> (substances). others would be recorded as having lapsed (without
>> being restarted) or discontinued for lack of tolerability or
>> effectiveness or affordability or desire or need. The difference
>> could be managed in the filtering of the display and any ambiguity
>> avoided by the use of last_used and status fields.
>
> Yes. Judicious use of the available fields would allow for that.


I cannot find in the PG autodoc-generated v12 (via browser) a field  
last_used so am not sure if it has been removed or was never  
implemented.

I think it is helpful to hold such a value when for example a patient  
had been instructed to take an antibiotic for a duration of 10 days  
but at a followup visit in 10 days admits they only took the  
medication for 4 days and because they were both nauseated -- and did  
already feel better from their original symptoms -- flushed them down  
the toilet.

It is IMO totally wrong to alter this current medication row to change  
the duration to 4 days, unless the meaning of "duration" is changed from

        How long is this substances intended to be taken.

to

        Intended (or post-hoc actual) duration of use, if known


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-10-29, at 11:05 AM, Karsten Hilbert wrote:

> c) we've also got .last_modified from the audit machinery which
>   can be different from .started if a row was changed to adjust
>   for, say, different strength or schedule

modified_when records the moment of the transaction but clin_when  
could capture when the change was done by the patient except the  
change could have been disapproved-of even though the medication  
remains approved-of




_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Mon, Oct 26, 2009 at 04:06:49PM -0700, Jim Busser wrote:

> >I am very much liking what a medication list can offer us,
> >depending on how we further think it through.
> >... (snip)
> >For this reason, I do not want the original ramipril row to
> >disappear as "deleted" from the Medication list
>
> I maybe misunderstood the audit constraints... I think we *do*
> actually permit clinical table records to be deleted... (upon which
> they are copied into an Audit table).

That is correct. For clinical *narrative* there simply
wasn't a way to do it from the client until recently. There
is not drop dead easy way now, either (for reasons of
repelling people from resorting to it too thoughtlessly)

> The GUI would need to provide buttons to distinguish whether to
> delete a row,

There's a button.

> or just mark a medication discontinued,

If
        .is_life_long is false
                and
        (.started + .duration) < today

then it can be considered discontinued to the best
of our knowledge.

> but if a
> medication were to be marked "discontinued" (say, stopped at a
> datetime prior to current) would auto-deletion of the row be
> proposed?

Not currently but at some point it could - at the client
level, certainly not the database.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Thu, Oct 29, 2009 at 12:25:28PM -0700, Jim Busser wrote:

> >>It would mean that within the Medication List, it would only be a
> >>subset of records that represent the current medications
> >>(substances). others would be recorded as having lapsed (without
> >>being restarted) or discontinued for lack of tolerability or
> >>effectiveness or affordability or desire or need. The difference
> >>could be managed in the filtering of the display and any ambiguity
> >>avoided by the use of last_used and status fields.
> >
> >Yes. Judicious use of the available fields would allow for that.
>
> I cannot find in the PG autodoc-generated v12 (via browser)

I just this afternoon updated the public database.

> a field
> last_used so am not sure if it has been removed or was never
> implemented.
>
> I think it is helpful to hold such a value when for example a
> patient had been instructed to take an antibiotic for a duration of
> 10 days but at a followup visit in 10 days admits they only took the
> medication for 4 days and because they were both nauseated -- and
> did already feel better from their original symptoms -- flushed them
> down the toilet.
>
> It is IMO totally wrong to alter this current medication row to
> change the duration to 4 days, unless the meaning of "duration" is
> changed from
>
> How long is this substances intended to be taken.
>
> to
>
> Intended (or post-hoc actual) duration of use, if known

I see the value in a .last_actually_used field. Let's
document that and keep it for a future revision.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Thu, Oct 29, 2009 at 12:29:23PM -0700, Jim Busser wrote:

> >c) we've also got .last_modified from the audit machinery which
> >  can be different from .started if a row was changed to adjust
> >  for, say, different strength or schedule
>
> modified_when records the moment of the transaction but clin_when
> could capture when the change was done by the patient

Ah, no, .clin_when is already used as .started.

> except the
> change could have been disapproved-of even though the medication
> remains approved-of

That discrepancy would typically be recorded in a progress note.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-10-29, at 12:50 PM, Karsten Hilbert wrote:

> I see the value in a .last_actually_used field. Let's
> document that and keep it for a future revision.

Made me think of a wrinkle surrounding "when was the medication  
started" (.clin_when) ...

Suppose I provide a prescription, instructing the patient as follows:

- if the current symptoms do not improve by X days
- if in future you should develop
        - symptoms of H1N1
        - an exacerbation of COPD
        - a flare-up of gout

you should being taking
        - oseltamivir x 5 days
        - doxycycline x 5 days
        - colchicine x 3 days

So maybe in this case it is important to not forget that this  
medication despite that it is not current "at this moment" could  
easily become current at any time after the visit has ended. So I am  
thinking that maybe in this case

- clin_when could be NULL
- duration could be a definable interval

What approach to data creation is taken in GNUmed / Postgres... in  
other words, when in a widget a user would click 'New", is there:

- a row created in a Postgres table that takes on default values which  
are then displayed to the user?
- being not yet committed until after the user clicked "Save", would  
this so-called row be equivalent to a 'virtual" row?
- is it known whether the client has the ability to receive schema  
default values and refresh them based on contextually-available  
information so that without user interaction the user could already be  
presented something closer to what they need?
- if the client would default to offer 9as clin_when) the current  
datetime and the user would delete this datetime to make the field  
empty, would this result in the value being saved as NULL?




_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

1) .clin_when (= .started) cannot easily be null because it
   is part of clin.clin_root_item

2) subject to the above perhaps being changed later I put
   the following logic into the view over the current medication:

        (case
                when csi.started is null then false
                -- from here on csi.started cannot be null
                when csi.started > current_timestamp is True then false
                -- from here on csi.started must be < current_timestamp and not null
                when is_long_term is True then true
                -- from here on csi.is_long_term must be false or null
                when (csi.started + csi.duration > current_timestamp) is True then true
                when (csi.started + csi.duration < current_timestamp) is True then false
                -- from here on csi.duration must be null
                else null
        end) as is_currently_active::boolean

So, while we currently don't allow .clin_when to become NULL
we can still achieve a similar effect by setting it to, say,
(today + 5 years) which would also nicely document the
duration of validity of our suggestion to eventually start
said medication :-)

Now, in Germany, there's administrative obstacles with this
approach: prescriptions lose their validity 10 days from the
date of issue, narcotics even earlier than that. The patient
could work around that by seeing the pharmacist in due time
and then stocking the medication at home - shelf live of
which is then limited (legally) by expiration date and
(medically) by (typically not easily known) decay to levels
below therapeutic substance concentrations.

Anyway, so there :-)

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel