|
From: | Syan Tan |
Subject: | Re: [Gnumed-devel] re vaccination batch no |
Date: | Wed, 28 Dec 2005 05:27:53 +0800 |
practically speaking, there are sometimes when there is not enough time
to be parsimonious about using the oldest vaccine in the fridge, just enough
enought time to check it hasn't expired. Last batch number storage is a UI specific feature,
and probably should not be stored in the schema , and it encourages people to enter
the wrong batch number anyway.
also , transactions aren't just for atomicity, there designed for equivalence of a serial
schedule of transactions when interleaving the input of concurrent transactions . You could
argue that gnumed is "disconnected" and "mobile" ready and that is why it uses xmin , the
and double checks the transaction timestamp because it doesn' t hold transactions between
commits, but you didn't , and your assertion is wrong that transactions are for atomicity only .
what are the unix rights for your setup ? is pg_hba.conf only writable by root, and do you bootstrap
gnumed as postgres ? I remember a prompt existed in boostrap script once that asked you to be
root in order to run bootstrap. This might be in accordance with the need to put gnumed into python
site-packages as well, or so that is why I assumed the prompt was there.
postgresql 8.0 on unix makes it possible to have groups of databases with
independent conf files , so it would be possible to have a gnumed ony "cluster" , and allow your
installation to install a intranet only pg_hba.conf, and get it to prompt for the ip mask that applies to
intranet ( assuming a single ip mask for a small intranet for a practice). other applications running on postgres
would use a different cluster.
I had nothing to do, and wanted a working client in order to try out some au development, so I put the
changes in the cvs , which match your schema changes. I also fixed the "no repaint unless resize top frame"
which occurs on my gnome setup, by using a slightly hacky workaround where the user is required to
check the identity of the "next patient" selected, as the gui switches to the demographic tab;
it was possible to make HorstSpace gui container to *try* to call the RegetMixin data_reget() for each
last instantiated instance of a plugin's panel class , by storing the last instantiated panel object on the plugin, and
getting horstspace manager to try the reget mixin call, and not do anything if it fails. This means the emr browser
will now correctly reload when the user has checked the patient is the right patient in the demographic tab,
and selects the emr browser tab.
One of the most common errors when very busy , I find, is to start to write notes and print scripts on the previous
patient . Automatic timeout logout might be another feature you could add, as this can be a problem if one shares "rooms"
and does a session , and the previous doc hasn't logged out ( a minor problem, and a brief annoyance, but it happens
at 2 practices ).
On Mon Dec 26 15:02 , Karsten Hilbert sent:
On Sun, Dec 25, 2005 at 08:37:56AM +0800, Syan Tan wrote:
> can vaccination last batch number be stored in a separate table which has a
> foreign key to vaccine ?
>
> The reason for this is that if a widget displays a vaccine generically, and
> there are several batches in the fridge, and perhaps
> several brands of the same generic vaccine (which can be traced by their batch
> number), the last batch number might
> be better as a drop down list which can be added to , and definitely exhausted
> batch numbers removed after selection.
Let's see. There's two situations:
We have two different brands of vaccine for one and the same
indication (hence, generically the same vaccine). That case
is already covered.
We have two different boxes belonging to two different lots
of the very same vaccine brand in the fridge and we opened
the very same thing. For one thing GNUmed does support
entering *any* lot #. OTOH, it might be good practice to
keep on using up one of the boxes first, then the other,
perhaps based on expiry.
The last_batch_no is not intended to track inventory in
stock. Its only purpose is to enable offering a reasonable
default batch number when a new vaccination is entered.
Do you still see the need for changing the schema ? I'd need
more explanation as I can't entirely appreciate the use case
yet.
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
[Prev in Thread] | Current Thread | [Next in Thread] |