[Top][All Lists]

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

[Gnumed-devel] GnuMed drug browser/prescription writer

From: Hilmar Berger
Subject: [Gnumed-devel] GnuMed drug browser/prescription writer
Date: Thu, 12 Sep 2002 00:09:56 +0200 (CEST)

Hi, thanks for all those helpful comments.  After having had one more look
at the AMIS-database specification I believe that the major problem with
drug databases is the intermingling of pharmaceutical and regulatory data.
Pharmaceutical data alone is rather easily generalizable. In contrast,
regulatory data in is highly specific to regional conditions and as such
almost not generalizable in an simple way. As regulatory data controls and
modifies the way drug data are displayed it isn't easy to separate these
two parts. I'm not quite convinced that handling regulatory data by
importing 'bureaucracy modules' is practical - that would only work if one
could easily separate and encapsulate regulatory information, which IMHO
is quite difficult.

I would suggest having a basic design that is as general as possible and
derive the actual implementation with as few changes as possible. If no
regulation exists, we can still use the standard version.  
IMHO a reasonable approach would be to use a three level design (database
- middle layer - GUI).

The database layer would comprise of a rather general part containing the
pharmaceutical information, a second optional part containing possible
additions (e.g. AMIS has data about other medical material like bandages, 
plasters etc.) and a specific part containing regulatory data.

The middle layer could be just same as the database service
'pharmaceutica', which can be tailored to the specific needs of a
particular drug database. Alternative it could be replaced by a wrapper
for a third-party, binary drug database interface.

The GUI layer should match the underlying database and will therefore has
to be customized to regional requirements, too. 

This design would mean having customized parts in every of the three
layers, but would still base on the same basic implementations. I believe
that this way is practicable and does not impose the risk of regional
versions drifting apart to much (at least for now).

As always, comments welcome.


reply via email to

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