[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: GNUmed vaccination stuff

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: GNUmed vaccination stuff
Date: Thu, 5 Jan 2006 14:02:34 +0100
User-agent: Mutt/1.5.11

On Wed, Jan 04, 2006 at 07:01:38PM +0800, Syan Tan wrote:

> ok, I see your point about ease of entry with the 2 list panel.
Syan, I wasn't trying to influence your design for entering
*vaccinations*. It think you should implement what works best
for you in your situation. Perhaps my point was incomplete:

For our vaccination status calculating views to work
properly we would need the patients being put onto
schedules. The other point in favour of doing so is to be
able to have any number of schedules in the database but the
vaccination status calculations only be concerned with the
ones that are relevant to a patient. This is good both in
terms of internationalization as well as inter-cohort
differences. Consider this:

Your elderly gentleman patient may well be on the "older
cohort tetanus" schedule but you don't want to see "missing
shots for: younger cohort tetanus, German STIKO tetanus"
messages everywhere in his vaccination status box. That's
why we want to be able to put him onto the "older cohort
tetanus" schedule to make the code ignore the other
schedules. For that (rarely occurring) need of associating
patients with schedules the double-list panel might serve
well. There may, of course, exist any level of optimizations:

- in some countries automatically put new patients onto a
  defined list of (possibly age-dependant) schedules
- when entering a vaccination for an indication for which no
  schedule is associated with that patient yet offer schedules
  matching the indication to be selected from a list and
  associated with the patient - this would be sort of semi-automatic

> if someone is
> going to give vaccinations according to a schedule,
> then really should should not have to select anything, just describe 
> localizing
> details like date , batch number, given elsewhere,
> and click "given", and it is removed from the list of scheduled vaccinations
> and put on the list of given vaccinations.
Well, that happens dynamically in real-time via our views
:-)  When you enter a vaccination the indications you
vaccinated against are derived from the vaccine given.
Thereby the vaccination status changes via the associations
between patient <-> schedule and schedule <-> indication(s).

> the abnormal use cases might be  when someone has had vaccinations given
> elsewhere, but even then the approx date and location
> given is still needed for good documentation;
I would in that case suggest entering fake vaccinations with
a comment "auto-generated" or "estimated". Richard had a
wizard for that as far as I recall.

> another case might be parental
> objection to one or more vaccines, and this
> could be handled by a parental objection checkbox,
Parental objections against indications might be documented
with a fake entry again and a comment "not given - parental
objection". If it happens often enough we might consider
adding a field to the appropriate table allowing structured
documentation of objection for an indication.

So, all in all, I wondered whether we can come up with a
two-list panel useful for generically moving entries from
one list to another which can be used in a variety of use
cases - such as putting people on vaccination schedules...

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]