gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Languages and drug interactions was (FreeDIams) Re: Inter


From: Jim Busser
Subject: [Gnumed-devel] Languages and drug interactions was (FreeDIams) Re: Interactions engine available with Canadian drugs database
Date: Sat, 24 Jul 2010 19:09:04 -0700

On 2010-07-24, at 3:05 AM, Karsten Hilbert wrote:

> Ah, excellent, that helps a lot understanding the structure.
> May I respectfully suggest considering changing the tables
> to something akin to:
> 
>       Interactions table
>               ID
>               ATC_ID1
>               ATC_ID2
> 
> 
>       Interaction_knowledge table
>               `ID` INTEGER PRIMARY KEY, `TYPE` INTEGER NOT NULL
>               'INTERACTION_ID' INTEGER NOT NULL FK(Interactions.ID)
>               'LANGUAGE_CODE' varchar(5) NOT NULL
>               `RISK` varchar(2000) NOT NULL 
>               `MANAGEMENT` varchar(2000) NOT NULL 
>               `XML` varchar(10000) 

I concur on at least two use cases (maybe three) where it could be useful for 
the language of the interaction (risk information and suggested management) to 
be uncoupled from the drugs database language:

1) no drugs database available (at least, not natively inside FreeDIAMS) ... in 
this case, the EMR might be able to just query the interactions based on ATCs 
that are known to the EMR when the user's country did not provide any free 
national data of drugs that are available to be prescribed. Karsten pointed out 
that english information would be very useful to him even despite not having a 
free db of drugs available in Germany. The same might be true of Rogerio.

2) drugs database available, but the interactions did not (yet) get translated 
into the same language as the drugs database. This may be the situation for 
Portuguese and South African dbs for which apparently free data may be 
available.

3) drugs database available in non-native language and interactions available 
in native language. This could apply for native French speakers in Canada where 
-- English being the main language of commerce -- the French speakers may 
regard it easier to use the Canadian (en) drugs db while choosing to use the 
French interactions strings and FreeDIams GUI.

If there would be agreement on the above, a separate step would remain to 
consider the schema options. The suggestion above maybe (?) implies 
directionality, that the interactions table is the parent table based on ATC 
and that it is from this table that the knowledge is linked, always depending 
on an unchanging UID for the interaction. The potential problem with this is 
that the primary data source AFSSAPS is keyed only to french drug names which 
is maybe why the existing interactions table maintains a foreign key to the 
knowledge.

The second issue is whether to normalize the language strings out of the 
knowledge table, in which case it would no longer be a knowledge table but 
rather a link table in which case I maybe do not see how a language code value 
in each record of Interaction_knowledge would work (?)  

-- Jim




reply via email to

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