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 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.....
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. But I am interested in arguments. Bert > > Grahame > > > > On Mon, Apr 15, 2013 at 11:25 PM, Bert Verhees <bert.verhees at rosa.nl > <mailto:bert.verhees at rosa.nl>> wrote: > > On 04/15/2013 02:56 PM, Grahame Grieve wrote: > > well, that's true for some parts of the record - the > historical parts. Other parts, summary parts, that's quite > untrue. In most enterprise systems, records tend to be rarely > updated, or intensively updated, and not much between > > > > Can you give an example of parts of records which are at big risk > for competitive updates? > > Thanks > Bert. > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > -- > ----- > http://www.healthintersections.com.au / > grahame at healthintersections.com.au > <mailto:grahame at healthintersections.com.au> / +61 411 867 065 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130415/4ae97c5e/attachment-0001.html>
