This thread takes me back (30 years) to a Cobol-based NHS payroll system which in one glorious month paid every single NHS employee in the region a safety boot allowance, because the first person on the payroll was an ambulance man who at that time got it and the record was not cleared down between processes!!!! It was only a pittance per person but it was a lot overall but still too costly to recover. ..... and that one was only money. To have similar this far on and with clinical data is frightening and just the sort of thing that UKCHIP (www.ukchip.org.uk) registered health informaticians should not accept. If any of you are at HC2004 in Harrogate - come to BCS stand D2 and tell me how things are progressing, please
Jean Roberts Brit Comp Soc Health Informatics Committee In message <1078561911.1262.925.camel at emilio>, Tim Churches <tchur at optushome.com.au> writes >On Sat, 2004-03-06 at 05:55, Matt Evans wrote: >> The application allows the creation of documents with standard windows form >> controls (e.g. drop down lists, multiselects, radio buttons etc). When I >> open a document it pulls though the appropriate value to each field from a >> previous form. Let's say I have a free text field that says 'Reasons patient >> unfit for surgery' and I have entered "pneumonia" as the value. I save the >> document and can view the information from the document viewer. >> >> 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 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! 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. > >First of all, I would ask the developers to show you the data model they >are using, and in particular explain how it stores versions of >documents/records. Don't be fobbed off. If they say "it's too >technical", explain that you are not thick and insist that they explain >it to you. > >The detailed answer is that there needs to be some way for the EHr >application to determine, for each data item, whether pre-filling the >field for that data item on a new form/record with the value from a >previous record/form is a useful, neutral or counterproductive thing to >do. For example, sex is unlikely to change, so it is a safe bet to >pre-fill the form with the patient's sex last time. Likewise DOB and/or >current age. Others are value-dependent. For example, there is no such >thing as chronic pneumonia (recurrent, yes, but not chronic), so there >is no point repeating such a diagnosis, whereas if the diagnosis is >diabetes, it is worth keeping. Obviously, under the bonnet, an EHR >should not be modelled like a paper-base medical record, but rather as >many different but related data items, some of which are persistent >properties of the patient, others of which relate to the particular >clinic episode or service. All these may be presented using a paper form >paradigm, but that's not how it should be stored. That's why you need to >ask to see the logical data model, or maybe the conceptual data model >(the physical data model probably contains too much operational clutter >to make sense to anyone but the developers). If the developers don't >have a logical data model to hand, which they can explain to interested >testers/end users like yourself, then it is time to get some new >developers... > >> 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. > >Yes, a budget of ?2.3 billion is a problem, given that the probability >of success seems to be an inverse function of the funds available. > >> I am something of an amateur dabbling in the world of IT so would appreciate >> some informed opinion... > >The worlds of IT and health are about to collide, or coalesce, or >intersect, or something, in an inescapable way. So no need to apologise >for being a "dabbler". It is the IT people who need to apologise for so >often obfuscating and complicating things (of course, the same criticism >has been levelled by patients at the medical profession...). Anyway, >just as (some) patients now come armed with copies of the latest >clinical trial results or meta-analyses, so should health professionals >meet with their IT providers clutching entity-relation diagrams and be >prepared to ask difficult questions about data models and other "arcane" >IT matters. Of course, the openEHR two-level model hopes to make this >interchange easier. > Please note - Phoenix Associates, has now moved to 68 Churnet Valley Road, Kingsley Holt, Staffs ST10 2BQ The email remains : jean at hcjean.demon.co.uk, Phone no: +44 1538 753297 or mobile 07771 804472 Fax is still 01538 266944 for the moment - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
