gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] script tables


From: Karsten Hilbert
Subject: [Gnumed-devel] script tables
Date: Sun, 22 Dec 2002 16:34:57 +0100
User-agent: Mutt/1.3.22.1i

Hi,

there's two issues here that we must not get confused about:

- storing previously generated scripts
- keeping a patient's list of current medications

Yes, we want them to be separate.

storing scripts
---------------
Yes, we want to store the exact content of what we put on the
script if only ever for medico-legal reasons. This CAN be a
field of type text. This WILL differ considerably from country
to country. This MAY come in a parseable text format. This may
even be considered worth signing at some point. This also
holds true for most if not all forms we generate.

We may also want to store pointers to prescribed items in the
drug database. Yes, this WILL go stale at some point. But we
need not care, I dare say, as we did our best.

Ancillary tables may be become necessary per country as a
whole slew of surrounding data comes up. Writing a proper
script is an art unto itself over here.

keeping a list of current medications
-------------------------------------
This will store a generic drug description linked to a problem
we hope to fight with it. This may be facilitated by the last
prescribed brand for that purpose but that can change from
script to script while the generic stays the same. In all
actuality, upon first prescribing a new type of drug it will
be the other way round, of course, the brand gives us the
generic and both will be stored in the current medication
list.


New scripts will be generated by going from the list of
current medications via the "most recently prescribed drugs"
(as found in the last few scripts). Repeat scripts can just
reprint the old script (perhaps in parts) and get stored as
their own script instance. All sorts of fancy tricks can be
played around this theme.

> Also, one of the databases (MIMS) is unstable in its internal data, for
> example omeprazole is "Losec" in one edition and "Losec Tablets" in the
> next. Richard had problems with his program in this regard. 
> Therefore we need to store the generic information (omeprazole), even
> though this will not perfectly describe the drug.
This is the part where we must not get confused. Of course,
the patient is on Omeprazole. Nonetheless, the most recently
prescribed brand was Losec. It matters little whether the
latter information will go stale at some point in the future.
If "Losec Tablets" does not produce hits anymore during a
repeat script generation we can a) search for "Losec" then
search for Omeprazole. The list of current medications will of
course say "Omeprazole (Losec Tablets) for gastric pre-ulcerous
lesion".

> (IMHO, if an "adjuvant" has serious implications for indications,
> adverse effects, etc., then its not really an adjuvant for our purposes:
> it should have its own entry in "constituents")
If you need to know you go back to the drug database via the
exact name of the prescribed drug. If it's not there anymore
and it matters someone upstream better come up with the information.

> True, the number is more a daily total for 'compliance-checking' so if
> you prescribe
> 20 tablets of temazapam, 1 nocte, and the patient comes for a repeat
> script in two weeks, the computer can alert you to the discrepancy.
This is useful. I see this happen every day in our commercial system.

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]