Hi Karsten, Comments in text.
-Thomas Clark ----- Original Message ----- From: "Karsten Hilbert" <karsten.hilb...@gmx.net> To: <openehr-technical at openehr.org> Sent: Tuesday, May 06, 2003 4:43 PM Subject: Re: openEHR security; Directed to Thomas Beale > Thomas, > > maybe I'm too dense but I cannot appreciate the complexity of > the issue as you hash it out. > > To me this is simply: > > 3.5.2003 10:35 am first seen patient > medium pain frontal skull after contusion in traffic accident > 5 mins ago, no neurological abnormalities right now, GCS 15 > Patient prior history missing. Potential head injury should indicate query-response might be a problem. Record might show allergies to drugs and injuries to other areas that could complicate such procedures as X-Ray, e.g., steel plate in neck which may represent collateral damage that is not obvious. Relying 100% on visual inspections and observations may not cut it, especially where the Patient has an easily accessible EHR, etc., such as the hospital you are standing in. Good legal material, i.e., the Patient has a medical card for the hospital and has had prior surgery at this hospital. Why not punch up the card number on the computer terminal in the ER? > 3.5.2003 10:45 check up > pain on pressure to 2nd cervical vertebra, dizziness, > nausea, claims fuzzy vision, left pupil dilated responding to > light slower than right, now severe pain frontal/retroorbital/ > right temporal region. GCS 12. > Narratives are supplements to tracking which should be integrated into the record. Doesn't really help if the record shows that the Patient entered the hospital but not what transpired. Big RED button. > Clearly, there's some new and some updated information in this > narrative. This is the point where I immediately ship the > patient to the next CT/MRI scanning facility with on-duty > neuro/neuro-surgery. > Narratives are great tools are are used frequently today, and are often interpreted in the legal environment. They can include charts and images to support a diagnosis and treatment. They can also be very lengthy and difficult to accomodate in records systems, e.g., a digital representation of a CAT scan requires large numbers of storage with high resolution scans requiring lots of bytes (e.g., several gigabytes). A lot of these images are trashed (could be redundant or just bad). 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? 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. Inside the EMR there needs to be practitioner identification, events, pointers to associated data, etc so that something later backtracking and reconstruction are possible. Everything of significance is entered, even spelling errors. > All this requires is an append-only text field. Of course, it > can be handled much more fanciful inside the EMR, trying to > link items, graphing trends on scales, etc. etc. The basics, > however, can be handled by free text fields. And even they do > not just emulate the paper based record but offer one clear > advantage: they are readable by me even if someone else wrote > down the first assessment. > > > Narratives can be hard to handle in record-based systems as can scannable > > entries, e.g., charts and images. > But they are absolutely necessary. > > Karsten The User Interface is a 'connected' issue; it generates input for the record. Medical devices generate input. Both will get formatted, possibly encrypted, compressed and integrated or linked to the record. 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). > -- > 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
