|Subject:||Re: [Gnumed-devel] Re: GNUmed vaccination stuff|
|Date:||Fri, 06 Jan 2006 05:42:38 +0800|
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...
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Gnumed-devel mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|