Re: [Gnumed-devel] gmdrugs structure

[Ian Haywood]

On Wed, Nov 20, 2002 at 10:27:41PM +0100, Hilmar Berger wrote:
> 
> Hi,
> On Wed, 20 Nov 2002, Ian Haywood wrote:
> 
> 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.
Do you mean different as in the *text* of the condition is different
(which is obvious), this is covered as all product information can be
specified by country.

Or, is there extra meta-data about the subsidy? In Australia we have
maximum repeats, maximum units at single dispensing, etc.  What would
these extra fields be?

I am keen to avoid filling the schema with "foo_au" and "foo_de"
(although I admit sometimes it may be the only solution) If it only
needs a couple of extra fields I would put them in subsidized_product:
other jurisdictions can just have NULLs on these columns.

 
> 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
ATC sounds good. But for some databases (say MIMS) it may be easier to
import their own system than try to link with ATC. 

> 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.
I agree.

> 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. ) 
Point taken. So we need a preparation table (the substance, amount,
unit, tuple), linked many-to-many with product (pack_size, form,
packing_unit).
 
> 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.  
"mg/ml" and "mg" are listed as separate in drug_units.

> 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.)
Not sure I understand here. If we link (penicillin, 1, gram) to (bottle,
10, ml) then it is 1g of penicillin in a 10ml bottle, there is no need
for a separate link.

 
> > 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.
I am not sure I fully understand. Could you post a couple of pages from
Rote Liste to demonstrate?

What I *think* you are talking about is class<->substance inheritance.
The purpose of classes,IMHO, is to save the pharmacist's keyboard. That
is, if a particular attribute is truly a class-effect, it goes in the
class. If it's shared only by some elements, then they have to be
entered separately, or you need a new class. The point is, adding an
effect in the class, and then overriding it may work well in a dead-tree
version, but on the computer it means a lot of work (both coding the
support and in data-entry). 

The other issue is the next level: ascribing drug attributes to the
drug-dose-route tuple. I agree indication can be drug-dose-route
dependent, but the other attributes? Can a drug change it's
side-effects, receptor-binding, etc. by a different route? NSAIDs for
example, still cause ulcers when given rectally.

> > 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).
True. Thought I could save myself some lines of PHP ;-)