Re: [Gnumed-devel] gmdrugs structure

[Hilmar Berger]

Hi,
On Wed, 20 Nov 2002, Ian Haywood wrote:

> > 2. tables conditions, subsidized_products:
> >  those are certainly country specific and should IMHO be marked as such
> > (i.e. conditions_au or similiar). I'm not quite sure if those tables
> > should be part of the standard gnumed drug database, on the other hand
> > these tables can be just ignored by a client running in a different
> > country.  
> Yes, the prescribing conditions ('the Authority') are a peculiarly Australian 
> institution, however I believe 
> the Americans have a similar system. Countries fortunate enough to have no 
> Authority can have the table empty.
It's not like there was no prescribing conditions in Germany - they are
just different. So we will need another (and much different) table to
reflect those conditions. I just suggested to make clear to which
country/medical system that tables belong, since we might end up having a
lot of different tables with similiar names holding data on subsidies once
gnumed spreads to other countries.

> > 3. table drug_element:
> >  - what is the difference between therapeutic vs. pharmaceutic class ?
> Pharmaceutic: a particular receptor or structure: viz. beta-blocker.
> Therapeutic: a therapeutic group, viz. anti-hypertensives, anti-arrthymics. 
Well, I get the idea. I would suggest using a classification that is
already available, e.g. the ATC classification by the WHO. ATC combines
anatomy, therapeutic classes and chemical (pharmaceutical) classes in one
classification and should be abolutely sufficient. (I append two files
listing ATC codes and classification from 
http://www.msupply.org.nz/download.html).
Since almost all available drugs are listed with an ATC code, it shouldn't
bear big problems to convert different classifications possibly used by
other drug databases. 
On the other hand I'd rather hesitate to create a new classification from
scratch - that most times proves more complicated than it might seem at a
first glance.
 
> >  a) the substance itself (i.e. active substance, adjuvant or whatever,
> ...
> This is drug_element. "drug_element" also covers drug classes as above in a 
> single table.
> This may seems strage, but the alternative is total insanity from a coding 
> perspective.
I don't see any problems with this design.
 
> >  b) the specific form of appearance of substances defined by formulation,
> > (i.e. tablet, solution etc.), amount of drug, adjuvants etc. This is IMHO
> > ...
> > level without being ambiguous ('preparation' ?).
 
> This the "products" table.
IMHO table 'product' has properties that belong more to the package than
to a single unit (drug) e.g packing unit, package size. I tend to believe
that a further normalization of that table would allow for better
representation of packagages containing different amounts of the same drug
'unit' (I'm not quite sure if that plays a role in Australia, but in
Germany there are usually at least three different package sizes (called
N1 through N3) for every available drug. ) 

Additionally, the table link_product_component would IMHO make more sense
if it referred to a single unit of a drug and not the entire package
(which the link seems to indicate). That is particularly important for
soluble drugs, where the amount of active substance is sometimes given as
amount per ml, sometimes as amount per bottle.  

Which means that we will in any case need some way to define what is the
unit the amount in link_product_component refers to (ml, tablet, bottle,
bag, etc.)

> For the mixed insulins, I am inclined to list them as seperate
> compounds in drug_element, with a "human insulin" substance as a
> component. Similar for other drugs were the adjuvants play such a key
> role in the drug characteristics.  The modified insulins, Lispro etc,.
> are separate substances, with an over-arching class "insulin" to cover
> them all.
If we generalize the idea of compounds then every 'drug' is a compound of
'substances' (active substance(s) plus adjuvants) in a certain
presentation and with given amount. Every component and the presentation
(that defines the drug route, too) might change the characteristics of the
active substance. That's why I believe that differences between drugs
containing the same active substance are not an exception but more or less
the rule (at least that's my impression I get from having a look at the
information in the comprehensive german drug list ('Rote Liste')).

> Aspirin and heparin are interesting: different indications at
> different doses. However this situation is the exception. There is a
> "notes" field in the "drug_dosage" table to cover this. maybe the link
> to drug_indication shuld be here.
IMHO it would be much clearer to have a class or substance specific
default of characteristics on a given active substance at the *substance*
level (aka drug_element). Then, at the *drug* level, one could have
another pivot table holding modifications of that information. In the
'Rote Liste', there are class specific entries with subentries (e.g.
adverse effects numbered a through f for a given substance where one drug
could include effect a-c and another one a-d,f). Same is possible for
indications, hints etc.

> >  c) the package-level (containing x units of level b), having a brand
> > name, manufacturer and so on. 
> 
> > There may be two types of compounds then: compound packages (containing 
> > two or more types of level b) and compound 'preparations' (level b) 
> > containing two or more active substances  (level a). 

>This is true, another level is needed for "kits" containing
>several types of tablet viz. triphasic Pills or the H. pylori
>elimination courses ("Losec HP7"). Again, this are the exception, one
>hestiates to complicate the structure for just a dozen or so things. 
Sure, I don't want to propagate overkill. But all we need to have compound
packages is a table 'package' (see above) and a flag in that table that
tells us that this package is a compound package. Than we could have
another pivot table 'compound_package' that lists the additional compounds
in the same way as does table 'package'.  

> > 6. table link_drug_component: 
> > id_component:  references drug_element, as does table 
> > product.id_generic_drug. 
> > What is the difference ? 
> The database has the concept of a "compound", such as
> co-amoxyclav, with *no* dose data. This is an entry in drug-element,
> so it can have side-effects, indications, etc. ,etc.
> "link_drug_component" provides this general link.
Yep, now I get it - that's because of the mixture of active substance and
drug we currently have. The link in product should point to the drug, the
link in link_drug_component to the substance.

> I have question of my own: Indications and therapeutic classes
> essentially repeat the same information, can we simpilify this?
IMHO the information is similiar but not equal. It's not that rare that
you can use a drug far outside the primary indication (e.g.
corticosteroids and antidepressants in pain therapy or clonidin for
postoperative shivering and as an mild analgesic). Plus it's possible that
a drug is not available for a specific indication in a certain country
(particularly secondary indications). And last not least you might have a
more fine-grained indication list in Indications than in therapeutic
classes (think of analgesics again: some are used for bone injuries, some
for head aches, and you can't use all opioid analagesics for
treatment of cholelithiasis).
 
Hilmar