This entire thread was interesting. I was reviewing a versioning design proposal with some of my physician customers the other day and we worked through some of the same territory. One thing we talked about a bit that did not get touched on here was the issue of interim saving of data for short term recovery from technical failures.
This is the functional equivalent of the "Autosave" feature of Microsoft Word, which continually writes over a temporary file in accordance with a time schedule as you are editing a document. This file is typically deleted when the copy in program memory is formally saved by the user. If for some reason the editing process terminates abnormally, the program recognizes that an in-process document was not closed properly and offers the opportunity to re-open the document at the point of the last automatic save. One of the questions raised during the discussion is whether the overriting of the temporary file would be considered a violation of proper medical record handling procedures. Clearly, once a version of the document is formally saved, it has standing as a historical document that prevent subsequent modification without appropriate noting regarding the source of the change, original text, and the date and time of the change. Do you thing that a document being informally saved by an automated process designed to support recovery of the document should be subject to the same modification constraints as a formally saved document? Best Regards, Ken Thompson UNC Healthcare -----Original Message----- From: Thomas Beale To: Matt Evans Cc: openehr-technical at openehr.org Sent: 3/6/2004 8:03 AM Subject: Re: Basic EHR functionality Matt Evans wrote: >A month later I review the patient and they no longer have pneumonia. I open >the pre-op assessment document (which pulls through pneumonia to the >relevant field) and delete it. The form is therefore either saving a zero >length string or null value. The amended document is saved and the correct >information can be viewed in the document viewer. > >Now, the patient phones up with some additional information which I wish to >add to the assessment. I open it up to add that info. On a different page >of the document however the 'reasons not fit' box pulls through not the last >value (null or "") but the last non-null or "" value i.e. pneumonia. When >the document is signed the author has unwittingly signed the fact that the >patient is unfit for surgery as that is the value in that field now. The >system automatically runs a theatres scheduling query and that patient is >permanently rejected as being unfit for surgery. > > this is basic software error. Where it is, or how indicative it is of the quality of the whole package I have no idea, but it is unacceptable. You have to proceed on the principle that if such an error can occur in this part of the system, it can occur anywhere - which really means the whole system has to be viewed suspiciously - what if such an error occurred in some more vital bit of information? I would be asking for proof of quality assurance and customer acceptance testing - this means documents showing that numerous system level tests were performed and passed. Mike Mair mentioned versions - he is right, it's a key issue in this scenario - correct conceptualisation and implementation of versions is crucial to properly capturing changes to data. And usually badly / not implemented. > >This is one of a number of significant problems with the system that in my >opinion make it at best inconvenient or in some cases unsafe to use. All >control types are affected and the solution we have been offered thus far is >that you don't pull any values through. Therefore you have to retype all the >information every time! > that's also completely unacceptable - apart from the annoyance factor, you will eventually make keyboard/fatigue errors and put a wrong value in - what logic does the system have for resolving conflicts? > The other worrying thing is the number of hours >spent by Trust staff and IT staff on designing and building all the >documentation is phenomenal and has resulted in very little. > >The UK government has spent an estimated ?2.3 billion on systems for the NHS >for the first 3 years of a 10 year contract. This causes me concern given >the above issue may be the tip of the iceberg. > >I am something of an amateur dabbling in the world of IT so would appreciate >some informed opinion... > > > I would ask for: a) documented requirements which this system is supposed to fulfill - i.e. what must have been given to the vendor. If no-one can supply this, you can be sure that the system has no fitness for purpose b) proof that those requirements were fulfilled in the form of customer witness test results - as I say above - a standard procurement exercise (these consists of: a test plan, procedure and test cases, and a set of reports showing which ones passed and which failed during controlled, witnessed testing). If no-one can supply this, you know nothing about the quality or fitness of the system to fulfill the requirements (assuming you can get those). c) documents describing the problem reporting and fault-rectification process, and some indication of time the vendor will take to recitify faults of high priority (like those you describe) that's just for starters. Please report back on how you get on! - thomas beale - 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
