Re: [Gnumed-devel] Prescription printing in arbitrary countries and services.

[Karsten Hilbert]

On Sun, May 29, 2005 at 10:05:46PM +0100, Adrian Midgley wrote:

> Prescriptions in history are not very bulky, basically a line in a table
> for each one (in systems I've looked at, havn't dug that far into
> GNUMed, yet).
> So the overhead of storing on each occasion a prescription is issued,
> not a pointer to a list of descriptions of items, but the actual text of
> the item is small.
> The design is surely simpler?
> One specific benefit is that when the name of the drug changes -
> Frusemide becomes Furosemide, or whatever, the record of what was
> prescribed remains the record of what was described.  You don't have to
> add another line to teh dictionary to point to, and you don't have to go
> back through the history changing it.  Although you can.

Let's be very precise here and make sure we talk about the
same things:

prescription:

 - the database equivalent of the finished (paper) form a
   patient is given to carry to a pharmacy

current medication:

 - an item in the list of medications a patient is taking regardless
   of whether the items in this list come from a <prescription>
   or not

Now, I think our current objective was to generate
prescriptions, right ? Let's assume paper forms for now. As far
as those go one surely wants to keep around the actual text
printed onto the form regardless of changes elsewhere. It could
be argued that a "cache" table in the local clinical database
may contain all versions of a drug name ever used and forms
just link to it. However, this IMO goes against the notion of a
form instance being a self-contained unit of template and data
(deliberate denormalization). Which in turn means we would
indeed want to store the actual text of a prescription right in
the form instance regardless of a cache table. However, the
form instance may still have a (then redundant) link to that
cache table for more feature-rich coding. One reason for
keeping the actual text with the form instance is that users
may well edit the drug name right before printing and one would
not want to keep all edited drug names a user comes up with in
the cache table.

In summary, prescriptions would be form instances. Form
instances are defined by a form template and associated form
data. The form data is denormalized actual text as it was when
the form instance was considered finished by the user. It may,
however, include pointers into a cache table of drugs (which
may at some future point in time turn stale).

Notice how we haven't taken into account any interaction with
a current medication list at all yet. Which can be developed
entirely separately and connected by a cleanly defined in/out
API.

So much for how to handle prescriptions.

I just now realize that the pick - queue - group_as_prescription
workflow is very amenable to supporting the problem-oriented
documentation of GNUmed. Eg. from within one progress note
editor I would queue one drug for prescription which thus is
tagged with the appropriate problem. From within another
progress note I might queue another drug tagged with that other
problem. Only at the end would I issue the "prescribe queued
items" command which would then group queued drugs into form
instances and send those to the printer. The queued drugs
would then be removed from the queue but the form instance(s)
would be kept around. This is also one junction at which
interaction with the current medication list would occur.

BTW, the queue - group part is quite exactly the way Richard's
prescribing mechanism works as I recall.

Adrian, I very much enjoy this exchange of thoughts. Perhaps it
may lead to a useful "generic" implementation of steps 2/3 of
the prescription handling as I outlined earlier.

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