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

[Syan Tan]

not sure if you got my post about being able to put people on schedules per recommended by id.

I've got a tree with hidden root node, and next level nodes  are  "recommended by id".  these are activatable.

under each "recommended by id" , is the schedule definitions , ordered by minimum_age_given, so it appears

like the standard schedule as usually listed .

  any recommended by id node can be activated, and if confirmed in a prompt,

patient is either put on the schedule if not on, or taken off if already on.

An X and O appears against the nodes, and the nodes changes colour depending on whether a patient

is on it or not.

 

this is done in the second page of a subnotebook, which is a "vaccination enrolment page".

   The first page is the working vaccinations page,

and there is a side tree list lists the merged schedules a patient is on, in mimimum_age_given order.

these are meant to be marked ( color change, small tick or X) when the number of vaccinations given

and suitable interval between vaccinations match the schedule. eg patient happens to be on STICKO and AustNIPS

and has had 3 DTP , each indicating 3 x indications of D , T , and P have been given , and intervals were greater

than one month apart, so the first 3 DTP recommendations of STICKO and AustNIPS are marked given.

In the case of the older cohort patient, they may be on the tetanus schedule, but not on STICKO or AustNIPS,

( actually, may need to modify the AustNIPS input sql data, so that there is a childhood, and older adult AustNIPS  ).  

Is this similiar enough to what you were proposing ?


On Thu Jan 5 14:02 , Karsten Hilbert sent:

> 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
> 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...
>
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel