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
