[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Mon, 07 Dec 2009 13:32:28 +0000 Simon Waters <simon@xxxxxxxxxxxxxx> wrote: > Neil Williams wrote: > > > > Government should stop moving the goal posts. The first reason the > > pharmacy side of the NHS IT scheme has gone so far over budget is that > > the entire basis of the mechanisms and protocols were abandoned and then > > redesigned time and time again. > > Who/what was/were the driver for those changes? Department of Health and political expediency. Couldn't decide initially whether to go with a push or pull model then the interface got tangled up with other unrelated changes (unrelated at a technological level but, sadly, not at the political level) and clashes with the results of the same process going on with the other end of the connection into other proprietary computer systems in doctor surgeries. NHS IT *is* a very large, very complex task. To do it right needs a clear direction and open collaboration between all parties. Code duplication and indecision - which have characterised the process so far - are fatal errors. > I think the government understand project management as a Prince II > thing, and where this is followed, and done by people who understand the > methodology, you often get reasonable project management, and thus > reasonable software projects. > > Where I see it go wrong, if where work is outsourced, or where the > project is not well understood (the current NHS system is a case in > point, I know someone who was managing a subproject for something it > wasn't even clear was technically possible), or the project management > is inexperienced. All these were visible to me in the current big NHS > project, and I only happened to know a few people who worked on bits of > the project socially. Absolutely. The biggest problem was continual changes of direction driven by political winds - fatally undermining any kind of long term planning or even rational decision making. The end result is that although a partial system does now exist, almost nobody uses it because it slows down the generation of data at the prescriber end, slows down retrieval of data at the dispensing end and produces unusable data at the payment end. That mess cost us an estimated £10bn. In the 9 months since the system went live (3 years late), I've seen less than 1% of incoming prescriptions carrying the electronic information, of those less than 1% actually get dispensed using that electronic information (because reproducing it by hand is 5 times quicker than downloading) and none have been paid using that information. The original plan was that 90% of scripts would use the electronic system at prescriber level, 90% of those would use the electronic system at pharmacy level and all electronic forms submitted electronically would use the electronic payment system by 2010. Now <1% of <1% of 5 billion is still quite a few items but the system cannot even cope with that number - crashes and system failures are common. Of those that do get through the system, probably 50% need manual changes to the data entered by the prescriber anyway. What the prescriber types into the "directions" box is literally copied into the electronic data and thence onto the dispensing label. Not many patients understand what "i qds po 7/7" actually means. I've seen suppositories and inhalers with electronic instructions of "Take 1 tds" etc. instead of "insert" or "inhale N puff(s)". Prescribers are busy, these are standard codes that could use auto-completion (the pharmacy systems do so when typed by hand but not when processing electronically) but the systems were not programmed with users in mind. The pharmacy systems don't provide a simple way of editing these instructions when processing the script electronically, so you end up wasting time by going back into the record and changing the text to reprint the labels. It's quicker to ignore the electronic data and type the whole thing yourself - plus you get less paper waste (which is confidential and needs expensive, specialised, handling) by only printing the labels once. The costs of the NHS IT failure are not just those of the payments to proprietary software houses. Even just switching to a pharmacy computer system *capable* of handling electronic forms causes a three fold reduction of processing speed compared to the simpler systems that don't understand electronic forms. It doesn't matter if you don't use the electronic information system at all, just having it as part of the software causes the bloat due to the poor code design. In maxed-out dispensaries, this either means a combination of more staff *and* more terminals or patients simply not getting their medication in time. Sadly, "efficiency savings" in the Department of Health mean that funding for staff or extra computer stations has been cut in real terms - in part to fund the waste of developing the unwanted and unused computer systems that are causing the need for the extra staff in the first place. The impression gained at the front line is that none of this software is being tested with anything like a realistic data set. It's fine with a few dozen records of unrealistic test data with no complex layers or inter-dependencies. Throw it at a real data set with duplicate records, incomplete records, missing data, tens of thousands of records going back several years and the new electronic support software simply doesn't scale. It's routine now to have to create an entire new patient medication record every few thousand records because the systems cannot cope with loading a patient with more than that number of entries in the database. It's laughable. I've seen patients with A DOZEN medication records, most marked "DO NOT USE - WILL CRASH COMPUTER" instead of a patient address. If patients are on weekly medication and have 10 or 12 regularly prescribed items, this comes about probably once maybe twice a year per patient - there are millions of patients in the UK with weekly medication like that, most nursing homes have a number of such patients. Some patients need daily records and get a new record every few months. It's shameful. These are (supposedly) modern databases - you and I could probably write a flat file database system that could cope with more records than that! These systems exist because those writing the code are not users of the code and those using the code have no recourse to those who make the decisions. Entering a single new record into these systems can take 15 long seconds. That doesn't count any typing, that is merely the time taken from the final key-press of one patient to the system being ready to accept the next key-press for the next patient. i.e. a single database transaction takes 15 seconds - routinely, day in, day out. The hardware hasn't changed - the same systems were capable of doing the same in less than half a second using the old software that knew nothing about electronic data handling. Simply unacceptable. It's almost at the point where one person can use two computer terminals contiguously. > > Free software methods.... > > The Government would need a more detail than "free software methods". There are people and organisations ready and able to provide all the detail that government could want - IF requested. An important facet of free software methods is that the developers of the code are users of the code *with realistic data*. Developers of apache run big sites using apache. Developers of PHP maintain busy websites with lots of complex PHP. This doesn't seem to happen with the NHS IT systems - it could, even whilst retaining a proprietary system, but it doesn't. It would currently be impossible to develop and debug these software packages using realistic data sets because the code is so inefficient. Lots of software projects handle similar problems, whether free software or proprietary - but the developers of the NHS IT system have been prevented from accessing realistic data sets. Calls to helldesk frequently get the "works fine at this end" response because of the unrealistic test data. It's not that hard to anonymise a real data set, just by making patient and prescriber names and addresses from random data. > Also, I'm not sure that Free software methods are that efficient alone. > > There are aspects to free software, that make it more efficient. For > example the Savannah/Freshmeat/source-forge model, isn't as obvious > aspect, one could write "make all Goverment software GPL'ed" and achieve > little without proper tools for sharing, collaboration etc. Code duplication is a huge barrier as are changing specifications. Both can be less problematic if agile programming is used in a free software development model because each team collaborates and shares the ABI/API. The licence merely supports collaboration, it is sharing interfaces that is of overriding importance in the development of any large scale project, especially where targets can change and time-scales are large. Sharing is the true goal. > There are also social aspects that affect how things work. Debian being > a good example of a group that self organised, imposed their own quality > control on contributors, own decision making model. But that model > probably couldn't be used in government easily, if only because the > potential pool of direct contributors would be smaller, and there would > be external pressures to do things particular ways. It's the external pressures that lower code quality; i.e. political meddling. However, open and collaborative development practices can minimise the results of such interference by preventing companies wasting time developing their own implementation of yet another change in the protocol. (There are external pressures on Debian too.) If the specification changes once, the software should change once - not once per company, just once for all companies. When the spec changes again, one change in the software, one migration, one interface. That only works if the interface is fully open and shared. Debian and others have shown how that can be done, we do it every release for GTK+ and hundreds of other migrations. Share the interface and migrate everyone once per interface change. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpnQj1Tmghjw.pgp
Description: PGP signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html