gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Medication viewing


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Medication viewing
Date: Thu, 29 Oct 2009 19:05:19 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]