Yes, in the lab situation we typically saw this multiple times a day - multiple people trying to update the same cluster of records at the same time. So the scenario is a typical relational database- a cluster of related records, some information in fields, and some in blobs as a structured text. Someone would start editing that cluster in a GUI, and then either someone else or a machine would also want to perform some operation that caused updates to some portion of the same cluster of records. A user might spend several minutes editing the record - or even several hours, particularly if they get distracted by phone calls, and it's a complex report like an autopsy, for instance.
So you can't afford to do this as database transactions, but you can't afford to do either version based merging, or to lose either the previously committed information, or the newly committed information - and the users managing this are not abstract thinkers with the time to figure out the clash. And losing good clinical infornation due to bad IT - the users are particurlarly intolerant of this. And as I said, it happened much more often than you'd expect. I spent a couple of years refining the kestral system for managing this issue. I haven't seen the same against current lists in an EHR - just that they are updated continually. I've no reason to think that the in principle issue is different, though the frequency might be. To Randy's point - managing concurrency is a real issue. Period. Grahame On Tue, Apr 16, 2013 at 2:08 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 15/04/2013 14:37, Grahame Grieve wrote: > >> "big risk" - it's a combination of how likely it is, and how bad it is if >> they are. >> >> Generally, current location, current medication lists, summary lists are >> things where contention can happen. Quite often, I've seen, a cascade of >> things will happen on a patient simultaineously as multiple people focus on >> the patient >> >> The other place where contention is a problem I've experience has been >> pathology reports that are not complete - in a busy lab doing 2000 >> reports/day, I observed editing contention 10-20x a day on average. That's >> pretty low, but the consequences of a clash.... bad..... >> > > Grahame - can you elucidate on this? Are you saying that you have seen > multiple parallel committers trying to update the same lab report (same > patient, order etc) at the same time? The only way I can imagine this is if > multiple specialist lab systems contribute to a common overall report (i.e. > some kind of order grouping). In this case, there is unavoidably logic to > do with how the pieces get stitched together anyway, so I am not sure how > contention errors could arise. > > - thomas > > > > ______________________________**_________________ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org<openEHR-technical at > lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au/ +61 411 867 065 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130416/a8f13ae9/attachment.html>
