Thomas, >> To me this is simply:
> Patient prior history missing. Sure but that was just an example to illustrate that a text field can easily provide storage for reassessing narrative. > Relying 100% on visual inspections and observations may not cut it, Of course not. But even in the imaging-crazed US American Healthcare industry www.trauma.org teaches one to dismiss a potential neck injury patient if there's no clinical evidence whatsoever for such injury (clinical being hand/eyes/mind here). > An append-only text field might be great for a User Interface supporting > text input but handling this over a course of treatment by multiple > Practitioners gets a little tough. Suppose four Practitioners decide to > update their narrative simultaneously and they all 'finish' simultaneously. > What happens to the record? Uhm, you end up with as many additions to the record as there are updating doctors ? (This is the multiple-update problem well known in CS). So, what's the big issue here ? I mean, what they all type is not going to be funny essays about their recent holidays but information relevant to the current encounter with that patient. > Single-user, semaphore-based UI applications are just not good enough. If > someone forgets to unlock the record and leave for the evening I hope you > have their cell number. Why would the application have to lock the entire record ? Why would there not be a timeout for that lock, perhaps based on presence-detection (timeout) + timebased login restrictions for the account that forgot to "unlock" ? Why is the front-door swipecard system not sending a signal to the EMR: "X is leaving" ? (This, again, does not apply todoay to "remote areas of Y".) > Narrative in their 'final' form are of interest to the record designer and > they will likely not look like anything you though you entered, e.g., > encrypted, > compressed, pdf file that becomes a history file (unchangeable). But it better make damn sure it *contains* everything I typed in the way I wanted to represent it with the given input means (eg. hand formatted into columns or such). Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
