Re: [Gnumed-devel] Vaccine table questions

[Jim Busser]

On 2011-09-12, at 1:44 AM, Karsten Hilbert wrote:

>> Would it not be better to allow new vaccines to have NULL?
> 
> No. It must be either or at the current state of medicine.
> 
>> It seems to me that the last thing you would want is human
>> failure (through a moment's inattention) to allow a default
>> when it could cause a live vaccine to be recorded as
>> non-live.
> 
> "Most" vaccines will be non-live, currently, but I agree
> with the reasoning on clinical grounds. Switched around now.
> 
>> Presently, whether or not a vaccine is live does
>> not interact with the user.
> 
> Except in the vaccine edit area.

Part of my reason for asking is because the Canadian drug database includes 68 
branded drugs having ATC = "J07foo".

From these, I can create 72 vaccine records (68 + 4 because, in 4 cases, a 
single branded vaccine is available in 2 routes, intramuscular AND 
subcutaneous).

Questions:

1) Is it ok for two different clin.vaccine records to be keyed to the same 
unique branded_drug? This would mean that, in 4 cases, there will be an IM 
route vaccine and a subcutaneous route vaccine keyed to the same unique 
branded_drug. Clinically, it does not seem to me there would be any problem of 
meaning.


2) Will the schema (based on discussion above) allow them to be imported with 
is_live is NULL? The information is not contained in the source file and there 
is no easy way for me other than to look up the product monograph for every 
product. If we should wish to have a safety constraint, it should be that the 
vaccine not be allowed to be "administered" while is_live is NULL so whichever 
clinician first "administers" it would have to first "initialize" this value.

-- Jim