These scenarios were one of the reasons we were very careful to properly model commit time (system time) separately from the times of the visit, observations, actions etc (world time). The commit of the info may come days late, but it is always easy to determine a) what other clinicians could see on the system at time T and b) in what order things happened in clinical reality. The caveat is that the system won't tell you the full story until everyone has committed their data.
This doesn't mean there are no tricky competitive write situations, but via the above, and the versioning semantics (which include system-based branching), there are reasonably obvious strategies for correctly resolving the confusion. - thomas On 15/04/2013 20:11, Karsten Hilbert wrote: > On Mon, Apr 15, 2013 at 08:40:59PM +0200, Bert Verhees wrote: > >> On 04/15/2013 06:12 PM, Thomas Beale wrote: >>>> patient sees the GP, then visits a practice >>>> nurse, without the GP record being committed first. >>> yes, that's certainly a possibility, if the practice solution isn't >>> designed to deal with it, and the staff are not trained... >> In the Netherlands there is, what we call, the "door-handle-patient". >> At the moment he is leaving the room, and is busy opening the door, >> he tells what he is really worried about. > That's standard GP land. > >> The GP asks the patient to sit down for an extra minute and explains >> why he thinks it is not cancer, or he makes another appointment >> because he thinks the patient has a point.. >> So a GP at latest should commit after the door is closed and the >> patient has definitely gone and just before the new patient enters. > For one thing that moment (the patient being "gone for > good") never comes in reality. > > However, there's no need to define such a moment in time. > The GP writes into the EMR whatever is known at any point > during the consultation. Yes, that will be subject to > editing, deleting, amending, but that's normal ! > > The nurse (that is, any other workplace of the GPs network) > will see whatever has been committed. Whenever something is > committed a change notification is pushed out by the storage > engine and clients can update themselves if relevant (that's > how GNUmed does it). This, of course, does not yet solve the > conflict of the user editing something that's just being > changed but at least there's no chance to not be aware of > it. > >> At the moment a patient arrives again at the nurses or >> assistants-desk, the dossier should be fully up to date, or it should >> be recognizable that it is not up to date > In reality "fully up to date" never happens. It is always > the current state of affairs. > >> and then the nurse has to wait until the lock is released. > Ah, no, it doesn't make a difference whether the nurse waits > for a lock to be released or not - because even if the GP > released the lock the nurse has no way of knowing whether > the GP committed everything (instructions) needing > committing or whether the GP forgot something. That can only > be assured by out-of-band means, say, the patient knowing > what the nurse needs to do for him (or GP and patient > agreeing and sending an "action sheet" *before* the patient > leaves the room -- and still that does not prove the GP does > not remember something needing doing after the patient left > the exam room). > > It is a problem not solvable by technical means alone. > > Karsten -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130416/fa0de6c9/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130416/fa0de6c9/attachment-0001.jpg>
