Hi Gavin and others! On Mon, Apr 15, 2013 at 4:39 PM, gjb <gjb at crs4.it> wrote: > > 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. > [...] > Gavin Brelstaff - CRS4 >
Some of the "magic" behind multi-user/multi-device editing in Google docs is referred to as "operational transformation" algorithms. Have a look at for example: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation or http://en.wikipedia.org/wiki/Operational_transformation Very interesting stuff when you look closer at it. Some years ago one of our student projects used some of that power provided in Google Wave to experiment with an experimental partial implementation of a multi-user archetype editor. In that case the operational transformation operated on XML pieces. The simplest case is operations on plain text - that case is usually described in explanations. Open source implementations of operational transformation working with for example pieces of JSON are also available (http://sharejs.org/). In the upcoming (BMC accepted) paper "Applying representational state transfer (REST) architecture to archetype-based electronic health record systems" (and briefly in my thesis) - I mention the thought of using operational transformation in the EHR editing stage taking place before doing "real" openEHR contribution commits. This would be a possibly interesting replacement or upgrade of the "Contribution Builder" component described in the paper. It would allow for simultaneous shared multi-user and multi-device data entry for many (but not all) use cases. It won't scale to thousands of users simultaneously preparing the same contribution for the same patient but it should scale well for a handful of simultaneous users per patient if they are somewhat aware of each others duties and responsibilities. The possibility to flag openEHR content as "incomplete" would allow snapshots from the shared contribution build to be persisted in the proper EHR at a regular interval and/or actively triggered by the user when they need to shift attention to other things. Later when considered complete, another version could be marked as complete, be signed and committed. If anybody currently has time or resources (e.g. master thesis students) to pursue an operational transformation openEHR data entry approach in an open source project, then don't hesitate to contact me for more detailed discussions and potential cooperation. A bit wiser from my work with the repeatedly delayed REST implementation and publication approach, I'd prefer to do such experimentation in an incremental, multi-site, open, public way instead of only having a big publication/delivery in the end. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ P.s. Qoute from the upcoming paper "Applying representational state transfer (REST) architecture to archetype-based electronic health record systems": > Shared contribution builds is another interesting potential future work. > The current contribution builder design works best if a contribution build > is personal and the user uses one device at a time for editing it. For more > dynamic teamwork or multimodal or multidevice data entry, using systems > based on Operational Transformation (OT) would likely enhance the user > experience. OT is a lock-free resolution mechanism that is used for example > in collaborative systems like Google Docs and Apache Wave (formerly Google > Wave). Since OT involves many small transactions a use of approaches like > WebSockets for accessing shared contribution builds is anticipated. When > explored properly, specific OT application recommendations should be added > to the architecture. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130416/08fb3a55/attachment.html>
