[Top][All Lists]

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

Re: [Gnumed-devel] Re: Medication viewing

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

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.


> 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

> 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.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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