[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.3.22.1i |
> 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