Hi karsten, Comments in text.
-Thomas Clark ----- Original Message ----- From: "Karsten Hilbert" <karsten.hilb...@gmx.net> To: <openehr-technical at openehr.org> Sent: Wednesday, May 07, 2003 4:14 AM Subject: Re: openEHR security; Directed to Thomas Beale > 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. > OK > > 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). > I admit, then, to be image-crazed. If you properly order an X-Ray in the ER because you suspect visual indications are insufficient, then the image should be in the record. If the Patient is treated for an injury that is not obvious upon admitting and/or leaves the facility with identifiable injuries that were not present previously the tail gets pinned on the facility. Tracking is super-important. Include the image. As for clinical evidence, many Patients have records in multiple facilities, insurance companies and individual practitioners files. They are neither available nor in a form that would require a modicum of effort to interpret (obviously suggesting that prior diagnosis/review of a Patient's records is a good idea; a priori data mining performed by software applications). Sufficient/insufficient clinical evidence at any point is an issue. One benefit of EHR/EPR/EMR systems is that this issue becomes substantially muted. > > 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. > The 'multiple-update' problem can be solved mechanistically. Consider a Healthcare where entries can be associated with the Patient, facility, Practitioners (including Nursing Staff), support functions, medical devices, administration, billing and groups/sub-groups of the above. A lot gets dumped into the record. There needs to be structure! There are others that have to access and interpret all that stuff. You can turn it into a format similar to an analog tape, or microfiche, and spend time/bandwidth/etc accessing it. Could turn it into a structure format so that the contents can be quickly loaded into a database and accessed therefrom. My preference is for an object-oriented database since I might want to retrieve all ER-related information quickly (includes narratives and images). > > 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".) > Used 'Single-user, semaphore-based UI applications' as an example since some deployed software relies on this approach. "lock/unlock" approaches are sometimes used in secure OS/applications because of a 'security hierarchy'. Used as an example; not recommended. > > 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 Everything contained in the 'final' form will be retrieved. The 'encrypted, compressed, pdf file' becomes an object managed by the record system. An issue is the encryption and who holds the keys. This has to be a secure, permanent object. If content is there upon retrieval it likely was not there upon creation. > -- > 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
