Re: [Gnumed-devel] Getting Canadian drug data into FreeDiams

[Karsten Hilbert]

On Fri, Feb 19, 2010 at 11:49:56AM +0100, Hilbert, Sebastian wrote:

> > On Fri, Feb 19, 2010 at 11:12:46AM +0100, Karsten Hilbert wrote:
> > > The Canadian data is more normalized. One either needs to
> > > denormalize that into the FreeDiams table(s) or else
> > > normalize the Canadian data more.
> > 
> > "more normalize the French data", I was to say
> > 
> > Karsten
> 
> Excuse my ignorance but what are the pros and cons trying to fit all data in 
> a 
> single table strucure ?

Pros: you have fewer tables
Cons: it will be hard

No, really, the question is wrong. It is not advisable to
try and "fit *all* data" into one structure. The advice
would be to unify as much as *sensible*.

The reason for that is that it will make you think about
what it really IS that you are dealing with. Medical truth
does not concern itself with legislative boundaries. Neither
should application thereof. Thus it is useful to think hard
about what really is the same across boundaries.

ATC is the same

components are the same (not their wording, however)

interactions are the same (not their wording)

side effects are the same

precautions are the same

contraindications are the same

forms are the same (pill, liquid, iv solution)

recommended and useful dosages are the same



brand names are NOT the same

amount per package is NOT the same

mix of ingredients of brands is NOT the same

hence contrainidications/intolerances/interactions at the
brand level are NOT the same (they depend on all
ingredients)


It'll be easier to present drug data aggregated across
several sources if one doesn't store redundant data. The
more knowledge is encoded into a data structure the fewer
bugs source code will have. If data is encoded into the
layout of the database other software (like GNUmed) will
have a lot less to duplicate should it want to access the
data directly rather than through FreeDiams.

But this is only sanely doable to a degree.

Hence my suggestion to first work towards a lowest common
denominator - attaching ATC codes to INNs for each supported
data source.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346