Hi Horst, answer below Quoting Horst Herb <[EMAIL PROTECTED]>: > On Wednesday 20 September 2006 09:53, [EMAIL PROTECTED] wrote: > > Horst, I'm unsure what you mean here: are you refer to program code > > modularity or data aggregation size. The latter is what I was > referring to > > in my previous emails. > > I don't worry about data aggregation size in this context. > I worry about referential integrity and concurrent access issues. > > Let us say three users need to concurrently access a "file". The user > interface cannot know whether there is any intent of modifying data or > not. > > In a non-atomic document-centric data storage, you would have to "lock" > the > complete "file" for all other users as soon as the first user does the > first "document" manipulation other than just reading it. In an atomic > data > model, you only need to lock the individual component (single "column" > or a > single "record") inorder to allow safe concurrent read/write access > > Common situation in my practice: > - my practice nurse just did a few on-site tests (e.g. INR, BSL, Hb, > urinalysis) plus a few observations (BP, Spirometry, ECG, weight ...). > She > starts entering the data while > - the patient is already transferred to my rooms and I start entering > history, > examination findings at the same time > - while my secretary is just in the process of scanning in multiple > dopcuments > for the same patient > - and the pathology downloading module simultaneously keeps adding test > results that have just been received for that very patient > > May not happen every hour or every day, but in even a small practice > like mine > this is likely to happen at least weekly. > > How do you handle such concurrent data access in a document centric > storage > model, eg native "full document" XML database? (Unless you have just > middle > ware emulatiing a virtual document while in the background you have a > relational storage engine plucking the document apart and keeping it > "valid" > in real time by two way communication with your middle ware)? Everything you say I accept as real world but there is a design parameter that is adjustable that changes the scale of the concurrency problem ( although it is hard to diminish it to zero). The presupposition I read into your scenario is that all the data you describe is locked into a SINGLE document, like a database record locks up all patient info, where as under our model that would seem to be unlikely ( but not impossible). The matter is the granularity of the forms system you develop for your context. If each one of those users are recording different info on different forms then there is no concurrency issues whatsoever. Each form is stored in the database as a document linked by the patient identifier, and when you as the doctor retrieve the practice nurse's form of test results you see it EXACTLY as she recorded it, as if it were a piece of paper. In the ED example, we have discussed the case of the clinician and nurse at the same bedside filling out different parts of the same form on tablet PCs- as you well appreciate that is exceedingly tricky and we don't have a solution - but we are thinking about it. Ultimately we say we are engineering system generators where you design your system for your workflow ( and therby minimise concurrency collisions) and furthermore if you later discover an error in your workflow design you can change your design immediately without losing any access to your (now) legacy data. Anyway - that's the theory. My students reported today that they have the terminology server operational for basic functions, that the first form exactly replicating the EDIS registration form is operational and the first transfer of the populated form into the database has been completed( now we just have to read it back out). So little by little we are edging out of the clouds theory into trampled soil of practice. cheers jon
> > Horst > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
