Re: [Gnumed-devel] roadmap

[ju0815nk]

> > GUI of the existent drug browser somewhat and add XML-capability to the
> > lower level backend API in the future - just want to know if this still
makes
> Please do, we will eventually need a drug browser, it is not a core
> feature here in Oz as we don't (yet) have any textual data to display. We
do have basic drug
> names/brands/packet sizes type stuff that allows us to prescribe, I am
interested in
> writing a middleware to do this, before starting on the prescription
widget itself.
Well, sounds like we could share some code...

> I notice you have written a configurable drug infomration viewer in
> test-area/gmDrug, I would like to extend this for the prescription widget,
but I'm not
> sure it can provide the precision that is needed: this needs databases 
> to 'look' the same: use the same strings to define units, formulations,
> amounts etc. in the same way, plus (later) things like interactions
checking. 
If you have a closer look on gmDrug and it's short documentation in
developer-manual you will
notice that I gave it a three layer design, too: gmDrugObject hides the
backend interface. It supplies
a API that allows to access any backend data using keywords in a dictionary
to retrieve whole dicts of parameters belonging to a specified primary key.
Currently only SQL backends are supported, but it should be easy to derive an
object to get a XML-RPC client working. Query strings are defined in a data
file in order to change as few code as possible to add a new database.
The 'middleware' is represented by gmDrugView which tries to handle the data
fetched by gmDrugObject and in some way translate it to the format the GUI
layer (gmDrugDisplay) expects. It knows to handle missing entries, different
entry types and so on. I didn't implement something like transformation of
single entries - this was not needed in a viewer. Additionally, again, there is
the possibility to define information grouping and layout using config data
files.
I don't completely understand what translations/transformations you want to
do. I guess it will be quite difficult to transform any existing drug
database on the fly so that it data looks the same (I doubt that this is 
possible
even for subgroups of data like formulations, amounts and so on). I believe we
will have to accept that data from different sources look different - one
incentive more to create a single comprehensive database like drugref.org.
I could as well think of a prescription writer that works without
translation of existing data. One would let the user choose entries from 
substance/brand/whatever lists, get possible formulations (if available) as 
strings (or
lists of strings), too, and so on. This data could be stored as strings - not
quite comfortable, but might be easier than write a translation layer that
covers all possible cases (could even be difficult using python database
'drivers'.

> My original conception was for separate Python 'drivers' which do this,
which can hide more detail of  > the underlying database and export a higher
level API. 
This is somewhat similiar to my config files - I thought in including python
code too, but there was no need to do this until now. 

IMHO we could at least share gmDrugObject, not quite sure if some sort of
gmDrugDisplay or derivative is what you want.

Hilmar

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post