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

[Adrian Midgley]

On Sun, 2005-05-29 at 23:51 +0200, Karsten Hilbert wrote:

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

OK...

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

Hmm...
in the UK, up to 3 items can go on one form.

If a patient is given 4 items, has he had one prescription (on two paper
forms) or two prescriptions, one for 3 items and one for 1 item?

I think there is a faultline in the definition, hence I talk about
items.

If a patient has 3 drugs (prescriptions/items, to me) for hypertension,
and because of a newly painful knee gets another item - Paracetamol -
for it, and all 4 are issued at the same time, does he have two
prescriptions, one for HT and one for knee pain, albeit they may be
arranged on the paper as 2 HT drugs and Paracetamol on page 1 and 2 HT
drugs on page 2?
 

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

> 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 

Ouch.  This would be specifically forbidden in the UK, under
requirements for accreditation (compliance testing).

> and one would
> not want to keep all edited drug names a user comes up with in
> the cache table.

But if we can edit the items, I think we would like them to be presented
to us next time.  I'd go for the base drug dictionary though, to edit
it.

> In summary, prescriptions would be form instances. Form
> instances are defined by a form template and associated form
> data. 

I have not seen it that way, I think - rather I see each preparation
prescribed as an entity, and putting them on a form just as something
one might do in order to output a list of entities.

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

Definitely something to do before printing (or despatch electronically)
occurs, I'd think.  SO per item rather than per form.

>  ... Only at the end would I issue the "prescribe queued
> items" command 
Print/send/despatch/release/authorise rather than prescribe, I think.

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

I don't see a lot of point in saving that grouping.  
Looking at the trail and the locktimes on the items prescribed, we would
see that three items had the same time of locking, and from teh same
machine with the same user.  It is a reasonable step to take it that
they were prescribed together, and barely of interest whether they went
on one sheet of paper or three.

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

Hope so.

-- 
Adrian Midgley <address@hidden>