Re: [Gnumed-devel] vaccination edit are is really odd

[Karsten Hilbert]

> Ah, the ad/disad/vantages of age (just turned 51!!!) - gives one a greater 
> overview of others failings, and more of an acceptance of ones own. Funny 
> things happen when one gets older such as difficulty with the retrieval 
> mechanism (not seen in someone of your age).
Never mind, I suffer short-term memory weakness, too.

>  Take my word for it Karsten, we 
> need the top line which is target disease/schedule.
No. I will not take your word for it. The reason being that I
trust that you CAN INDEED explain exactly why you think we need
it. And I'd like to follow your rationale - I'll follow suit in
the conclusions if they make sense.

> > > 2) I still think we need schedules eg in AU we have 2.4.6 month schedules
> > > etc.
> Many reasons. Firstly because one can attatch multiple vaccines to a schedule.
Sure one can. But I fail to see the reason why one would need
to do so. I would rather attach indications to vaccines and
indications to schedules (be that single-indication or
multiple-indication is another matter).

> When the phrase wheel pops up after selecting a schedule (eg 2/12) and one 
> accepts this by hitting enter - then the next phrase wheel which 
> automagically pops up contains a list of all the vaccines in that 
> schedule(and variations of brands) for the user to select - so not only do 
> you get the memory jog, you get to see what;s due.
Aha. You are using the data-entry mechanism to provide medical
knowledge. That would make sense. However, IMHO the bottom
list (missing vaccinations) should remind me what's due. An
item in the right-click menu thereof may well be "show
matching vaccines" such that I don't need to remember which
vaccines I can apply to cover that particular missing vaccination.

One could argue for separating out "medical" regimes (eg how
to vaccinate against a particular indication) from
"administrative" regimes (which Body of Authority recommends
when to combine which vaccines to reach a certain vaccination
status).

> This is especially 
> important when  running parallel vaccine schedules which vary according to 
> date of birth and racial origin (eg aboriginals in AU get slightly different 
This is best solved IMHO by associating schedules with abstract
patient details, eg conditions on schedule applicability. We
currently only have min_age, max_age but may need min_born,
max_born, gender, ethnicity, etc.

> vacccines on occasions. Secondly I found that associating vaccines with 
> schedules made it programmatically easier to work out which vaccines were 
> missing for each age group.
Maybe true but IMHO not a significant reason.

> > > Each schedule contains multiple vaccines.
> > No question about that. It does not, however, explain why we
> > would need to be able to input the target schedule when
> > entering a vaccination.
> see above
When I enter the vaccine I effectively say which indications I
have vaccinated against. The system can now go and tick off
the scheduled vaccinations for the various schedules that are
directed against that indication. Where does the need to enter
the target schedule come in ? The vaccine IS the target
schedule by way of its indications matched against the
indications of the schedules.  Yes, we may need a way
to say "now, this pre-1920 aboriginal is on that pneumococcus
schedule and not that one" but that's another story. Do you
follow what I am getting at ? I may be wrong but need to see
use cases where this won't work.

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