[Top][All Lists]

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

Re: [Gnumed-devel] Drug database/browser/prescription design

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Drug database/browser/prescription design
Date: Sun, 8 Sep 2002 17:20:32 +0200
User-agent: Mutt/

> 1. GUI :  
> - There is a notebook-page module to browse the whole drug
> database ('pharmaceutical reference browser') and display all information
> available about a certain drug.  
Very useful. I use it every day.

> - In the prescription dialogue, pharmaceutical data should be presented in
> a way facilitating prescription. This might include processing of regulatory
> information (positive lists etc.).
Yes. Also with interaction checks where possible.

> 2. Backend
> - gmdrug.sql
>   medical and regulatory data
We may need to split sql files per country:
gmdrugs.sql and
gmdrugs-de.sql for Germany to encapsulate regionally relevant

> Questions : 
> 1. What is the supposed relation of the pharmaceutical
> reference browser to the prescription dialogue ?  
One-key/one-click jump to the browser from a particular drug
in the prescription dialog (anywhere in GnuMed, really, as
long as GnuMed knows it's a drug). Other than that they are
just two different views on drug data with different levels of

> 2. The documentation of the prescription dialogue
Refers to Horst's first version of it. Prescriptions are under
quite some regulation in each country. I fear we'll need a
specialized one for most. For a rather extensive description
of what is needed in Germany have a look at the Analysis
document. Coming next here: prescriptions being transferred to
a chip card and to a server (the dumbheads seem to prevail).

> (gnumed/html/developers-manual/prescriptiondialogue.html) mentions
> abundant use of popup windows.
"popup" windows not POPUP windows. Windows that auto-fill with
data from the database. Poor choice of words, perhaps. The
phrase wheel is probably better suited here.

> I learned that popups are thought to be a bad 
> thing (although I don't quite understand why) and should be avoided.
Have you worked in a busy clinic chasing popups ?

I do think Richard's version may need careful adjustion here
or there but the design concept seems very useable.

> 3. If the backend definition for the drug database does not match the
> specification of some regionally available database, should the current
> definition made more general to match it or should it be customized to the
> special requirements ?
To me it seems cleaner to define an API around the particular
drug database. If we implement what's behind the API - fine.
If we have to wrap a third party drug database GUI - better
than nothing. The point is we need quality drug data in GnuMed
no matter how (without selling our souls :^)

Sure, if "our" schema can easily be made more general without
incurring too much redundancy/overhead it seems better to do
that. But there's a fine line between overgeneralization and
just wrapping two or more databases with a common API. And
we'll probably need the API in any case since we ain't gonna
have drug data available for all countries right away.

All this IMHO, of course.

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]