gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] design comment: prescription/drug ID


From: Ian Haywood
Subject: Re: [Gnumed-devel] design comment: prescription/drug ID
Date: Fri, 9 Apr 2004 12:50:17 +1000

On Fri, 9 Apr 2004 02:22:07 +0200
Karsten Hilbert <address@hidden> wrote:

> A prescription is sort of a denormalized replica of parts of
> drugref. But this is on purpose. And it is the same as in our
> current records. It's not like I write down "take Rote Liste
> 64585 twice daily". I note down the brand name (or generic
> name). Hence, prescriptions should store a) brand name (if
> given), b) generic name, c) an identifier. Also note that the
> backlog of prescriptions IS NOT IDENTICAL to the the
> current-medication list. Prescriptions are prescriptions are
> prescriptions. They are form instances. Current medication better
> be handled separately, IMHO (with re-use to-fro, of course).
Point taken, 

> The clinical schema cannot depend on the drugref schema as
> GnuMed clients should access drugref via xml rpc. 

My point is that writing an XML-RPC layer for AMIS could
be just as hard as rearranging the data and importing it into the drugref 
schema, the advantage 
of the second approach is that we can impose a "PUPIC for drugs" via drugref.

> As for functionality/re local legal rules I think we should
> focus on supporting what the doctor actually wants to
> *accomplish*. I want to prescribe a treatment, be that drug,
[snip]
> Hilfsmittel) etc etc. IMO it should be possible to have generic
> therapy-intent collecting code and branching out to locale
> specific code upon script instantiation/actuation. I know this
> could lead to more work.
I like this idea, but it deviates somewhat from the existing GUI approach.
What this implies is a "super-widget" that subsumes the prescription, referral 
and requests editareas
(and vaccinations, which are really a special case of prescription anyway)
presumably it adds new fields dynamically depending on the values of the ones 
previous.

Actually, thinking about it, you don't need a editarea at all: have one 
"permanent" phrasewheel at
the bottom, and a text box (wxStyledTextCtrl: lots of pretty colours) above 
which displays the clinical narrative 
generated so far, and a "prompt" on the bottom left
which changes as we work, from "health issue", to "presentation", "physical", 
"impression", "therapy", "drug", "form", and so on.
We need some method of skipping steps and going back of course.

Ian
-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

Attachment: pgpkE3y2tvG21.pgp
Description: PGP signature


reply via email to

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