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

[Karsten Hilbert]

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

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

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

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