gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] pharm information as XML


From: Horst Herb
Subject: Re: [Gnumed-devel] pharm information as XML
Date: Mon, 7 Feb 2005 09:08:40 -0500
User-agent: KMail/1.7.1

On Mon, 7 Feb 2005 06:46, Karsten Hilbert wrote:
> Does the current drugref API allow to access databases which
> we cannot import into any schema, eg to which we only have
> access via a dedicated frontend provided by the database
> vendor ? This would amount to a "passthrough" "driver" type
> thing that just routes drugref API calls to proprietary calls
> (at the level this is even possible with the proprietary
> frontend - it may well be that all this amounts to is: "let
> user select drugs" - "here is the list of selected drugs").

Yes. The newest API version allows functional parameters - what the query 
functions actually do, is now completely transparent (whether they connect to 
a Postgres database, or ring your uncle via modem and voice recognition is 
now irrelevant). ANYTHING you can somehow run queries of some sort against 
can be integrated now fairly easily.

Just committed the updated "draft" for the 2nd generation drugref API - sort 
of works, but needs some serious de-crapping, commenting, and error-checking.

It allows not only to register queries, but it also allows to register 
functions.

Principle behind it:
1.) we publish a catalogue of attributes for each adapter we write.
2.) either functions or queries can be registered with the service provider 
class, along with the attributes they provide.
Example: "drug_brandname", "drug_genericname" would be such attributes
3.) whenever adapter.get(attribute, key) is invoked (either directly or via 
XML-RPC), the adapter checks whether it can provide the requested attribute. 
If so, it checks whether the cache contains such attribute already for the 
respective key parameter, and returns it. Else, it checks whether there is a 
function providing this attribute, executes the function, and returns the 
function result. Else it checks whether there is a query able to return the 
attribute, executes the query, and so forth.

The easiest way to try the concept is to download python/drugrefapi_base.py, 
python/drugrefapi_holbrook.py and 
interactions/holbrook/interactions-holbrook.dump from the php-drugref CVS.
Restore the dump into a postgres database "interactions", and execute python 
drugrefapi_holbrook.py

A few more lines of code and, in conjunction with python/atcmapper.py, you can 
basically throw any list of brand names, generic names, or ATC codes at the 
holbrook adapter and it will return you all applicable interactions it can 
find for any pair-permutation of drugs within that list (which right now 
contains some3872 mapped/expanded interaction records in the most recent 
dump) . Great, isn't it?

Jay is working tomorrow full steam to make it fully functional, and I'll join 
him in the afternoon once I have finished my operating list.

When the Holbrook adapter works, the WHO EML adapter will quickly follow, then 
the MIMS annual and the MIMS abbrev, then the Canadian DPD, then the 
Malaysian Blue Book, then the Mercy Ship Model Formulary. That'll provide 
plenty of examples on how to do it, so I hope we'll soon see drugref adapters 
sprouting for all sorts of free AND proprietary databases.

We spent much of today modifying the concept again and again until it suited 
all cases and constellations we could imagine (hence the residual crap in the 
base class etc)

Horst




reply via email to

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