> this makes sense for EHR and similar systems because there is very low / no write competition for the same piece of the same patient record
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 Grahame On Mon, Apr 15, 2013 at 10:47 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 15/04/2013 11:54, Thomas Beale wrote: > > > the update logic is Composition-level, and you can't commit something > smaller than a Composition. The default logic is 'optimistic' meaning that > there is no locking per se; instead, each request for a Composition > includes the version (in meta-data not visible to the data author), and an > attempt to write back a new version of a Composition will cause a check > between the current top version and the 'current version' recorded for the > Composition when it was retrieved. IF they are identical, the write will > succeed. There is also branching supported in the specification. Read the > Common > IM <http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf>for > the details. > > > I had meant to say here: this makes sense for EHR and similar systems > because there is very low / no write competition for the same piece of the > same patient record, as a general rule. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > 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/ +61 411 867 065 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130415/634c5659/attachment.html>
