On 15/04/2013 16:15, Bert Verhees wrote: > On 04/15/2013 03:37 PM, 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 simultaneously 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..... > > In the lab, are that updates, or new records? > How do you deal with long time transactions? Suppose a lab edits a > dataset, saves it in an archetype-model which will be used to store more > items. > Then lab employee does the following test and saves it. Should it be > saved in the same data-set, or in a new version? > I don't think you should have long lasting transactions, lasting longer > then one millisecond. > Maybe in a lab, there should be a client/GUI which stores/caches local > until the results are complete. > So it depends on the EHR-system and archetypes. > > And in the current medicationlist, how big is the chance that two edits > are done simultaneously? > And is it also a GUI question, to refresh the screen, once in a while, > so that the chance of a care-professionalist to be looking at the really > current medications increases from 99,99% to 99,999%? > There can always be a late update from a pharmacy, mostly they update > the system at moment of providing medication, but it can always go > wrong, electricity fall out, etc. > Those screen refreshes are also a GUI-thing. > > But, of course, it must be prevented. But I think you will agree that > there is no need of fancy isolation-schemas. > The most basic one will do. And transactions should never take longer > then a minimum of time. Say one millisecond. > > Not everything needs to be resolved by a OpenEHR-kernel. > Some things are really a GUI matter. > I thought about this a few years ago and came to the conclusion that the GUI/Client would need quite a bit of savvy HCI. The person working on the data need to be kept informed of how/when the system maybe changing under him.
Google documents has now come along and does something like that. You're busy editing one section of an article then a networked colleague begins to edit the same thing. GDocs tells you who it is and how to communicate with them by a secondary channel (EHR would be the primary channel). You can both still keep editing but at least you know you are going to have double check the result afterwards. Conflict resolution is best avoided by timely human intervention rather than automated attempts afterwards. And GDocs does well even when clients go offline for a short time. my 2cents Gavin Brelstaff - CRS4
