Re: [Gnumed-devel] vaccinations, again

[Karsten Hilbert]

Hi Richard,

thanks for bearing with me. I'd like to get this right. Hope
you had a good time on vacation with Charlotte.

> > in the left middle list we are listing regimes/schedules
> > a patient has been vaccinated against.
> This seems to be correct. (the list can contain a regime or only  a disease 
> name or course)
This is exactly the problem. In GnuMed we have a table
vacc_indication which generically lists all indications (well)
against which vaccinations are known regardless of what any
Vaccination Council in any random country suggests be given at
a particular age. (This table is, of course, linked to disease
codes via a link table.) We also have a table vacc_regime
which lists vaccinations regimes as recommended by some Body
of Authority (be that the WHO, the CDC for travel
vaccinations, the MPH for national disease control, the
medical Vaccination Council, or even a vaccine manufacturer).
This table might not always contain regimes for all
known/possible vaccinations as some are irrelevant in some
parts of the world (say, Jap.Enz. in Germany - except for
nutheads like me :)  Note that this table does not list
recommendations for *vaccines* but recommendations for
*vaccinations*, eg. it doesn't say "childhood hexa-valent
course" but rather lists 6 recommendations for vaccination.
Our Vacc Council (STIKO) endorses those 6 courses and gives
the *additional* recommendation that composite vaccines be
used where possible (and accepted by the patient !). This
table goeth thusly:

create table vacc_regime (
    id serial primary key,
    name text unique not null,
    fk_recommended_by integer,
    fk_indication integer
     not null
     references vacc_indication(id)
     on update cascade,
    comment text,
    unique(fk_recommended_by, fk_indication, name)
) inherits (audit_fields);

Each regime is linked to an indication which accommodates for
both the fact that there may be several (say, age-dependant)
recommendations on how to vaccinate against one indication and
also that there are country-specific differences.

Now, to generate the middle-left list one can go to either the
vacc_regime, the vacc_indication table, or both. The last case
is all-inclusive, ends our argument but also brings about
vagaries that are undesirable. I understand you go through
vacc_regime while I do believe we should pull up data via
vacc_indication. This will also consolidate data not strictly
following just one regime per indication, say, patient had
started base immunisation under a particular regime but
dropped out and now comes back for eventually having the
shots. We discover that recommendations have changed and also
that the previous shots are to be ignored according to the
Vaccination Council recommends. Thus we re-vacc according to a
different regime (for the same indication). But IMHO the
middle-left list should group *all* those vaccinations under
the same "target" !

As for missing "recommended regimes" one might argue that this
doesn't occur as there's always at least the (informed)
opinion of the manufacturer as to how to administer her
vaccine...

> I saved vaccination data back to data_immunisations, I include a screen dump 
> of this table structure.
Same here, there's a clinical data table "vaccination":

create table vaccination (
        id serial primary key,
        fk_patient integer
                not null,
        fk_provider integer
                not null,
        fk_vaccine integer
                not null
                references vaccine(id)
                on delete restrict
                on update cascade,
        site text
                default 'not recorded',
        batch_no text
                not null
                default 'not recorded',
        unique (fk_patient, fk_vaccine, clin_when)
) inherits (audit_fields, clin_root_item);

And, of course, despite the abovementioned normalizations
patients are vaccinated with real-life vaccines! And vaccines
cover several regimes, let alone indications. Hence "vaccines"
links to the indications covered by a vaccine via a link
table.

> The schedule_ID contained within this data table 
> pointed to the regime/shedule/disease target.
In GnuMed the vaccination row is linked to a vaccination event
definition via a link table. Several vaccination event
definition rows are linked to the above vacc_regime table.

The flow of data is this (yes, there is redundancy):

vaccination
 -> vacc_def
    -> vacc_regime
       -> vacc_indication
       -> recommended_by
 -> vaccine
    -> vacc_indication

> When the patients clinical data is loaded a join from the data_immunsation 
> table to the lu_shedules table pulls out the text to load into this list to 
> display in the listbox
Why, of course. Except that we pre-do this via views
(v_patient_vaccinations).

> lu_vaccines (the vaccine only data) (see lu_vaccines.png)
create table vaccine (
        id serial primary key,
        id_route integer not null references vacc_route(id) default 1,
        trade_name text unique not null,
        short_name text unique not null,
        is_live boolean not null default false,
        is_licensed boolean not null default true,
        min_age interval not null,
        max_age interval default null,
        last_batch_no text default null,
        comment text
) inherits (audit_fields);

> lu_vaccine_equivalents (used to cross check vaccine completion where 
> different 
> - brand names or combinations used)
you mean *vaccination course* completion, right ?

> lu_vaccine_schedules
vacc_regime

> lu_vaccines_in_schedule (schedule_id linked to a vaccine_ID(s)
our vacc_regime does not aggregated recommendations as those
are administrational rather than medical, their occurrence,
however, shows up in the vaccine used for a particular
vaccination

> the age-due can be in the schedule table or dedicated table.
in GnuMed it is "in" the schedule table - or rather in the
vacc_def table whose rows constitute the vaccination event
definitions for the various regimes

So, I personally think we should generate the middle left list
from vacc_indication rather than from vacc_regime. What do
others think ?

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