Re: [Gnumed-devel] re vaccination batch no

[Syan Tan]

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