On Thu, Jul 06, 2006 at 03:54:01PM +0300, Peter Damoc wrote: > >Well, no. I am solving my real-world problem. My daily work > >includes concurrency. So that needs to be solved. I am > >encountering patient locks caused by concurrency constraints > >*daily* in the software that I use. Mind you, they are > >needed to ensure consistency but they do unnecessarily stop > >my workflow.
> Could you provide a small example? I admit I cannot imagine concurrency > being all that often. Maybe there is something I'm missing... Patient comes in, is treated, gets told to pick up several prescriptions, referrals, letters at the front desk. Patient leaves exam room heads down to front desk. During that time I *start* filling in the forms and sending them to the front desk for printing (by way of our EMR). Patient arrives at front desk. Front desk starts printing out the forms I already entered. Now, one of two things happens: Either I block the front desk from printing out forms by still entering additional forms for that patient or the front desk blocks me from entering the still missing forms. It is not unusual for front desk staff to phone me up in the exam room to urge me to write the missing forms -- all the while blocking me from doing so because they still have the patient open (front desk doesn't have a clue how all this works). Another example: Patient is sent to X-ray dept. They open up the patient EMR, take the X ray but "forget" to close the patient again preventing me from entering further data into that patient EMR. Much worse because I cannot phone the X ray dept. but have to physically walk down the hallway to get them to release the patient. Same thing when I phone a consultant upstairs to take a look at some X ray or some document. Unless we are careful we block each other out from patient editing. A daily hassle. And all that with the software recently having gotten *better* in that regard ! I hope to have none of this crap in GNUmed. Nevertheless, in well-defined circumstances it *is* possible to create a reality which does not need concurrency. Not in *my* reality, unfortunately, though. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
