Re: [Gnumed-devel] Re: Vaccination Maintenance Module Progress

[Karsten Hilbert]

On Sat, Feb 18, 2006 at 11:41:58AM +1100, Ian Haywood wrote:

> My vaccination practice is (well, was, I'm working in psychiatry now)
> quite different to most GPs in that I was generally vaccinating older 
> children and
> adults as catch-up.
> In other words, I didn't follow the official schedule, I would do the 
> appropriate
> serologies, then vaccinate what was missing.
I see. That's the *proper* way of doing it.

In GNUmed it *is* possible to store vaccinations in the
backend which aren't linked to any schedule. Moreover, when
a schedule is eventually activated for a patient existing
vaccinations which cover some or all of the indications of
said schedule are automatically counted against the
then-scheduled vaccinations - regardless of vaccine used.

> As have said, what I want is a widget which auto-computes the vaccines 
> indicated today,
> based on previous vaccines and age.
We already have a view which does that
(clin.v_missing_vaccinations) but it will need refinement
over time.

> So min_age represents the official schedule, the age at which
> vaccines "appear" on the list,

our schema has:

comment on column clin.vacc_def.min_age_due is
        'minimum age at which this shot is due';

Each shot definition (vacc_def) is linked to a schedule
hence the shot definition with the seq_id = 1 gives the
earliest a shot is due for a given schedule.

> I need max_age too,
> for both clinical (adults don't get whooping cough)

we have:

comment on column clin.vacc_def.max_age_due is
        'maximum age at which this shot is due,
         if max_age_due = NULL: no maximum age';

which covers the clinical maximum age due.

Someone who is too old right from the beginning should just
not be put onto that schedule anyways.

> and bureaucratic (chickenpox will only be subsidised between 18 months and 2 
> years of age)

GNUmed does not have that yet. It will obviously need it but
this belongs into either the drug database or the AU
specific schema part, surely not into the clinical part.

> Ideally it would look at my serology results too, but this
> is not possible as serology (like all path) comes as
> unparseable free text.
Which does not mean we should eventually support this
concept.

For one thing people known to be immune to a disease before
any shots were given for it should simply not be put onto a
schedule with this indication. There probably should be a
note in the notes somewhere saying that they weren't put
onto the schedule despite it being recommended courtesy of
their immunity. A put-new-patient-onto-schedules wizard
would support that sort of thing.

The other case, however, is more difficult. We will need a
way to mark a schedule "done" due to the patient already
developing a high enough titer or being tested immune
mid-schedule. In which case the scheduled vaccinations will,
of course, stay in the database linked to the schedule the
patient was on. However, the schedule needs to be markable as
"done" manually.

> Instead the user would manually dismiss a
> vaccine (and the rest of its sequence) from the widget.
Dismiss a schedule, not a vaccine. And possibly activate a
lesser schedule which doesn't cover the indications that the
patient is now known to already be immune against.

> >>Maybe different, but one conceptual thing I've not come to terms with is 
> >>when 
> >>one sometimes has to give a booster say for rubella, but has to use an MMR 
> >>vaccine (bad example), but you get the gist.
The data storage solution to this in GNUmed is to capture
real vaccinations independant of (but linkable to)
schedules. IOW, if MMR vaccine is given, an MMR vaccination
is captured. It doesn't matter which schedules a patient is
on.

> In Australia the Government generally subsidises one
> vaccine only for a specific position in the schedule,
... 
> The point is, Australian schedules are printed with
> the vaccines by brand: "at six months, give Priorix(TM)"
...
> Richard is also dealing with a brand-based drug database,
> the database doesn't indicate what epitopes a vaccine has.
> This is why (I think) he wants to tie specific vaccines to
> specific points on the schedule.

Aha, eventually the reasons for Richards lust for
vaccine_schedule emerge. So, after all, it's non-clinical
reasons and thus they need to be captured outside the
*clinical* part of the database. Fine with me. Put the stuff
into the AU schema, I'd say.

Ian, Richard, Horst, here's a question on AU:

Is it safe to assume that if there is a vaccine which
matches with a certain schedule in all the indications
that that vaccine is also AU-approved for that schedule ?

> the higher valencies often just aren't available.
> (I'm thinking, for example, of the six-valent "Infanrix Hexa" which is 
> MMR-diptheria-tetanus-pertussis, IIRC.)
> Maybe in some rich area there are sensitive housewives who will pay ~$50 to 
> save their little darling one more
> needle, I don't see such individuals where I work ;-)
I see lots of them. I also see lots who decide at their
whim: "Well, I don't like this horrible <insert epitope
here> vaccine. Let's not vaccinate my child against it."
Which leads us to put those kids onto reduced schedules.

> As is generally the case, Karsten has adopted a more conceptually pure 
> solution, but this means more work for
> use (we have to translate our schedule into a generic epitope-based one, then 
> manually link vaccines
> to epitopes, so the official schedule can be "re-constructed" by a join 
> between these tables)
Exactly. But his has to be done only ONCE per schedule and
does not concern the end user in the least given proper
widgets. Which is a small price to pay for proper clinical
medicine, I dare say.

> You can see for someone like Richard (whose mostly
> vaccinating off the schedule), it's extra work for no real
> gain.
It is only extra work *once* and only if no one else (like
Ian, Horst or Syan) does it for him.

And, of course there is gain: He will be able to make
vaccinations given by *me* to a patient we share fit into
*his* schedules. And he gains off-schedule due-ness
computability if vaccines, schedules and indications are
properly linked.

And don't be fooled, it's more work for me, too, since most
vaccinations are within schedules in Germany, too.

> I would add somewhere under sql/country-specific/au
> 
> ALTER TABLE vaccine ADD COLUMN au_subsidised boolean;
> 
> to mark which vaccines are paid-for.
Nope, not if I have any say. This approach (technically
valid) would lead to conceptually insolvable situations.
What if you, me, Carlos, and Jim want to share a database ?
The local needs will surely collide at some point,
eventually even in the needed *columns* not just the content
thereof.

Locally needed tables should *really* be kept in their part
of the schema, eg "au".

create table au.vaccines_subsidised (
        pk,
        fk_vaccine,
        ...
);

is perfectly fine with me. The real solution would be

create table drugdb.subsidised (
        pk,
        fk_drug integer
                references drugdb.drugs(pk),
        ...
);

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