Why hacking and platforms are the future of NHS IT Apart from those who have a commercial vested interest does anyone still believe in large top-down centrally architected IT solutions? Public sector IT in the UK is littered with expensive white elephants, and it sometimes seems as if the only beneficiaries are the large IT contractors, who can threaten significant job losses or …
I mean how can you write a "platforms" article (which is really an article about standards and interoperability provided by standards) on platforms in the health sector and *not* mention HL7, either positively or negatively?
Anyone?
Yep - standards and interoperability are the things you need to mandate centrally. The platforms and apps can come from diverse sources. This is true for any vertical - banking, etc. Anyone who doesn't get this is doomed to be blackmailed by proprietary software vendors in perpetuity.
Not a Brit and not in that end of IT Support, so I haven't heard of it specifically, but on a generic basis have to concur. The other bit which would greatly concern me, especially since we are talking about health information, is what would security look like without a central certification regime. Not that it seems to be all that great with one mind you, but I'd expect worse without it.
AC 10:22 "who's not heard of HL7"
Tom 13 11:04 : "Not a Brit and not in that end of IT Support, so I haven't heard of it specifically"
AC 10:22 here again. Fwiw HL7 is a set of standards which started life in the US, but it has some visibility internationally.
I'm not in healthcare either, but even in the UK I've been aware (at a trivial level) of HL7 for a couple of decades. I just don't know whether it's any good or whether it's a pile of poo. In principle it makes far more sense to mandate standards and interfaces and then allow the rest to sort itself, but if the mandated standard is a pile of poo, the end result may not be brilliant.
Security does indeed need doing properly. There are plenty of folks whose input I would trust. BT and Microsoft (as per NPfIT) are not obvious candidates to trust with any kind of secure distributed system.
"BT and Microsoft (as per NPfIT) are not obvious candidates to trust with any kind of secure distributed system"
As someone who has to support this debacle on a daily basis I hate to tell you but BT support one of the largest patient administration systems used and also run the N3 backbone the whole thing hangs off, with mixed results in both.
The problem between the central vs local debate is it completely misses the point in what it attempts to argue. The interoperability between the different systems (the many, many different systems) could be overcome by having a central database, rather than a central patient administration system. A one time interface has to be built for any legacy programs to access it and any new programs would automatically have the language to query it ready to go before the design even begins, meaning local trusts could still make their own decisions and invest in their own innovations without the need to worry about compatibility with data exchange, the central database can be held securely by the government (don't laugh, this is "in principle"), and the country wouldn't be wasting billions of pounds trying to impose applications that never work on everyone involved. Some trusts are coming up with some great applications at a local level but they won't interface with anything else at a national level because of the lack of enforced standards (as others here have gone into great detail about) and because there's no central repository for the data with a standardised interface. I'm sure the peeps who are actually working on this stuff will tell me why it's a bad idea, but it seems, in principle, to be an obvious answer to a simple support person.
Completely agree.
Look at the history of HTML and the Web - at the time there were office systems and information retrieval systems which ran on individual platforms (IBM Profs for instance).
Berners Lee developed the standard for exchanging the information - and produced DEMONSTRATION web browser and web server instances. You DIDN'T have to buy a NeXT computer to use the Web - allt you needed was something which parsed and displayed HTML.
There was a difference in the way the web browsers were developed and the way the consultancies tried to deliver the NHS program.
Many browsers trace back to Mosaic which was developed by a small number of highly skilled individuals. The browsers we see today have taken the code base and built on it.
The consultancies were only interested in one thing from the NHS and that was to make as much money as quick as possible. People that did not know much about computing were on the projects and soon the budgets were exhausted and the end result a complete disaster.
Well, quite. I've got quite a lot of NPfIT scars on my CV, having started work on it back in 2004.
The most astounding part about the National Programme was the enforced adoption of vapourware and flaky customised American software across the board. That's not a swipe at the US by the way, but the healthcare sector in the UK is very different from that across the pond.
What they should have done was to mandate the use of HL7 as an interoperability standard and allocate the budget to individual NHS trusts to implement it as they saw fit. That would have given them the option to buy new software or develop a dedicated integration facility and amend their existing systems to communicate with it.
That's how the electricity market deregulation worked. A central set of interoperability standards was produced and each 'leccy company put their own solution in. A popular choice involved a dedicated integration hub that sent and received all messages across the national network and handled all the internal distribution, including reformatting messages for communicating with mainframes. What the companies did behind those hubs was up to them.
Some companies bought new software, while others amended their existing systems to handle the new messages. By and large, it worked pretty well. The scale of the cock-ups - and there were a few - pale into insignificance when compared with NPfIT.
So yep, NPfIT failed to make proper use of all that HL7 had to offer. I've often thought that if they had done it properly, they might have encountered less resistance from the clinicians. BUt you know how it goes - in the users vs consultants war, the users lose.
HL7 was the standard mandated by NPfIT from the start. There's a copy of the documentation on my desk right now. Trusts had time to implement it, as we did, but most didn't understand it and lacked funding because, well, it's IT, and most trusts don't invest heavily in IT.
The failure of NPfIT, however, was it was being run by committee. That's why there was cost over-runs, delays and failure to deliver. It's what plagues most public sector projects: Just look at the Scottish Parliament building for a classic example.
That doesn't mean the idea was bad, just how it was managed doomed it to fail right from the start.
Platform systems, therefore, are a safer bet. But where NPfIT implemented HL7 quite well (as I said, it was there from the start and it was pretty much text-book correct), it's really hit and miss with smaller suppliers. They might claim to be HL7 compliant, but they then prove they don't know the difference between an A01 and an A03, or an A08 for that matter! And as for message handling, they struggle with a few hundred messages an hour where as we handle over 10,000 and don't break sweat.
So it's bad news for the NHS either way. One side is a committee run project that doesn't deliver, the other side is a minefield of platform systems that may or may not meet requirements, and that we can't rely on recommendations from other trusts who use the system because half the time they're just accepting it works and haven't noticed it's wrong!
Gah - I really need a beer! That or the BOFH's cattle prod and a visit to yet another system vendor...
I know what you mean about smaller suppliers (no names, no pack drill) and yeah - when NPfIT themselves were driving it, it generally worked fine.
But there was still the problem where trusts were forced to pick from a small list of PASes which turned out to be either vapourware, needing a lot of work to adapt them for the NHS or just plain cack. If they'd been able to pick whatever they wanted, provided it met the HL7 interoperability standards (an NHS-wide set of tests could have proved that, with payment on acceptance only) then it might not have been such a disaster.
Thankfully, I'm out of it now and don't miss the frustration at all.
Have a beer on me :-)
An absolutely sound idea. I completely agree that all the Department of Health should mandate is an interoperability standard, and then let local units (Trusts / PCTs) get on with it. I also think that clinicians should be involved early on the vendor side during software design, and also on the purchasing side when selecting software features. Sadly, neither of these things happens very often.
The procurement process also needs to change. The whole tender process is just an expensive smokescreen formality. In reality, Trusts and PCTs have a preferred supplier in mind, then enlist that supplier's help to write the tender so that the tender naturally favours that supplier. At the moment tenders are so heavily based upon past experience, and shut out SMEs by requiring arduous policy documents and certification.
We applied to a tender for clinician facing software and were asked to submit 12 different policy documents ranging from Equality & Equal Opportunities Policy to Environmental Sustainability Policy. 70% of the marks in total were for past supplying of the NHS, yet the scoring system did not penalise companies that had failed to deliver on past contracts with the NHS. The most absurd thing about the tender process was a question asking us to list our company's "key personnel" and "relevant qualifications". My medical degree and 4 years medical experience counted for zero points, however an European Computer Driving Licence qualification would have scored much higher. How f**king stupid have you go to be to rank the latter above the former for software aimed at doctors?!
I disagree with your choice of proposed standard though, purely because a more modern, more versatile one exists. HL7 is not a full open standard, and is deficient in certain areas as healthcare has progressed. The NHS poured money into funding version 3 of HL7, but this to my understanding is now on ice and will never be released.
A much better standard to mandate adopton of is EN13606. This standard was conceived by academics with a specific interest in data interoperability, so is thoroughly well designed rather than HL7 which has been assembled piece-meal by US software companies. It is the only healthcare data standard which is fully open thus not requiring subscription to use it. Being more modern, it addresses some of the shortcomings of HL7 v3. It plays nicely with XML. What's more, EN13606 is backwards compatible with HL7.
So, yes we absolutely need a national interoperability standard and I strongly agree with you for that. My vote is for EN13606 (www.en13606.org).
Source: I'm a medical doctor (4+ years) AND a software developer (6+ years).
I agree, it's all about interoperability.
Another huge omission from this article is the Interoperability Toolkit (ITK) which is largely an NHS interpretation of HL7v3. It's complex, but worth investing in as many of our suppliers are starting to support it, particularly for correspondence (e.g. letters, discharge summaries, etc.)
Having successfullly developed four ITK projects over the last 6 months I can testify to both the complexity and the business value of the ITK. The interoperability promise of the ITK can really help to deliver value and savings to a Trust so its worth getting behind if you want your product to be considered by NHS organisations as more than an another silo.
The ITK is ridiculously over-the-top, WS-DeathStar based hot air. Every implementation that uses it adds man-months of absolutely unnecessary developer time, and hence financial and opportunity cost, to its delivery. It's the equivalent of an appendix: it simply is not needed. Mind you, neither are all the people in IT architecture in the NHS. Perhaps we could start fixing things by getting rid of Chief Architects who can't code for toffee. Unless you eat your own dog food, you'll never find your design flaws.
That goes double with HLv3. It's the most awful XML based standards I have every seen. Insanely verbose. A document deserialisation-serialisation is of the order of hundreds of milliseconds. Massive amounts of unintelligible boiler plate. It was never, ever designed from the standpoint of 'how does this kind of application process data' (even better - write the apps and extract the standard). Imagine scaling that up - not. Classic ivory tower masturbation.
The problem with these standards is that they are large-consultancy driven, and the entire ecosystem is very much closed to the outside. Heck, many NHS jobs won't even hire people who don't have NHS experience.
AC, because my current job depends on using this stuff.
I have to disagree with your general sentiment - I actually think ITK is a good thing, and they've got it largely right. Yes it's very complex, but it needs to be to support the endless healthcare scenarios you and I deal with on a daily basis.
They have made some mistakes, and the web transport specification (including the WS-* standards you mention) is somewhat bonkers. However in my experience the team behind it have been fairly responsive, and were willing to make changes to the specification to accommodate reasonable suggestions we put forward.
I dread to think how much money CfH could have invested in ITK had they not based it on an existing standard.
Schools seem to be doing this quite well - A small choice of Information Management Systems actually helps us as data can be transferred to other schools/LA's/Government (there is of course the issue of vendor lock in).
Most schools IT systems are then managed on a local authority or individual scale.
I don't see why hospitals can't take this sort of approach if they had the standards
The problem is it's insourcing, and the beancounter can't see past the wages.....
The NpfIT only really delivered two working projects, NHS Mail and Choose and Book. The rest were either abandoned or vastly scaled down. The Lorenzo patients records system in particular was an unmitigated disaster.
What's always puzzled me is how NpfIT's failure has been treated so casually by all parties concerned as well as the press, when it should really be treated as a national scandal. Not only is it a tale of colossal incompetance both by the government and the contractors but there's more than a smattering of corruption that has lead to its failure.
The NHS is one of the largest employers in the world. It could easily employ a relatively large number of developers and write pretty much all of the software in needs in-house. They would never be idle as there's a huge amount that always needs writing.
I'm a hospital governor, and I've worked within the private sector on a large number of NHS projects and proposals. The amount of money scammed out of the NHS by large SIs is sickening. The tendering process takes a huge amount of time and effort on everyone's part, and the cost to the UK economy as a whole must be huge. What's more, once the project is delivered the NHS doesn't have that institutional knowledge and the suppliers have them over a barrel for support. At the moment, if a clinician finds a problem with software then it's bad luck if the spec wasn't quite right - the supplier might change it for a huge fee. Maybe.
Think of the money saved not having to put everything out to tender, but having a large permanent staff on hand to develop anything that needs doing. What's more, the knowledge wouldn't be lost every three years and there would be people around to work on problems in any system.
Of course, this would never happen under a government that is in thrall to the 'free market'. This is sad, since the fact that it would be cheaper, quicker and more efficient is without doubt.
@Dominic T
We do develop IT solutions in-house. We can't keep up with the internal demand, though: We'd need a team 10 times as large and that's not going to happen in this climate. We do offer our solutions to other trusts, too, as not all hospitals are large enough to support in-house development. What's more, we cooperate on developments and have won awards within the NHS for that work.
Would a central funded group work better? No. We deal with local issues and know our data very well. Centralize development and you lose that, unless you are thinking of having dedicated teams to cover specific trusts, at which point you might as well do it in-house at your trust. The only advantage is a central team could cover more platforms. A central team could have a small team for Tablet development where as a local team couldn't, but that would be one of the few benefits.
No, the best option is to do as we do: Cooperative development between local trusts, but keep the development teams local.
Then I get to keep my job :p
A hybrid approach would seem apposite, where single central platforms are developed by distributed teams.
Take the example of the Linux kernel - initially developed by a single individual, with basic requirements. Very much a single-platform project.
These days, large commercial parties cheerfully contribute to it's development - to support their hardware, to support their business needs. And small independents cheerfully contribute to it's development - in my case, to selfishly serve my own needs and fix driver bugs for my hardware, but *everyone* got to benefit from my changes.
Even relatively long-lived forks for selfish reasons - the Android versions of the kernel, for example - have a tendency to drift back towards the middle.
And if you really can't live with the direction of it any more, you can always fork it as happened with XOrg, OpenOffice / LibreOffice amongst others.
The NHS has certain common, core, needs. PAS should be a total no-brainer.
So ; yes to local dev teams as the best way to work out what local needs are. You pool together enough local needs, and you end up with common needs - which is where the central project maintainers have a role.
Stick a big Git server in the middle and have at it!
I find it frankly worrying that a hospital governor posts these sorts of comments and wonders why the NHS does so badly.
> The NHS is one of the largest employers in the world. It could easily employ a relatively large number of
> developers and write pretty much all of the software in needs in-house. They would never be idle as there's
> a huge amount that always needs writing.
As the largest employer should it also hire builders the next time a infrastructure project is under taken. Of course not what expertise is there in the NHS to hire competent developers and to project manage an IT project of this scale, forget implementation and support afterwards.
> I've worked within the private sector on a large number of NHS projects and proposals. The amount of money
> scammed out of the NHS by large SIs is sickening.
I too have seen sickening amounts of money squandered in the NHS. But often this is due to ineptitude on the part of those procuring. Why should suppliers have the NHS over a barrel. Negotiate the support contract right in the first place and there is no barrel to be put over. Also where were you when the plain sighted scam was being undertaken. Surely you should have spoken up and put a stop to it.
> At the moment, if a clinician finds a problem with software then it's bad luck if the spec wasn't quite right -
> the supplier might change it for a huge fee.
Again poor contracting. At the time of the tender, establish the hourly rate for further work and have it in the contract. Work with your supplier. Build a relationship. And don't bury mistakes so that no one else can learn from them.
The last thing the NHS needs is to diversify into being an IT company. But institutionally it needs to understand the fundamentals of what it is trying to procure. It needs to understand that insisting upon open standards in the software that is delivered is essential. Open interfacing with other system should be a requirement not an expensive bolt on or non-existent. It needs to understand that there are suppliers other than microsoft and that they in all likelihood will deliver a better product.
So the onus is on the clinicians and managers to understand the importance of maintenance, understand the importance of open standards and loose coupling, understand the ecosystem of OSes and platforms? And if they screw it up it's their fault? In a nutshell, there's everything that's wrong with the consultancy business. Caveat emptor, we just build what we're asked to build, not our fault guv.
His point is that without in-house expertise, they're sitting ducks for Crapita et al. And you just illustrated it brilliantly.
"The NHS is one of the largest employers in the world."
This is true, but it's something of a misconception. The NHS, as a complete system, is one of the largest employers in the world, but it is broken up and subdivided into dozens of regional organisations (mostly foundation trusts), each one an independent body with its own budget, employees, systems and processes. Crucially, they're all organisations with their own IT systems. Remember the job is not just creating the One True Software to support healthcare, it's doing that AND migrating every trust over to the new system without so much as a hiccup.
Further complicating the fact is that budgets and commissioning of services is now controlled by GPs, meaning service providers will further fragment and lose a lot of the assurances they once had as to the continuity of service.
> Of course, this would never happen under a government that is in thrall to the 'free market'. This is sad, since the fact that it would be cheaper, quicker and more efficient is without doubt.
After that NHS blew 11 x 10⁹ GBP on zilch (how many patients can be treated with that kind of money?), where the only responsibility was MANAGING, having some claim that ADDITONALLY DOING would be cheaper, quicker and more efficient is optimistic at best.
Claiming that the current way of top-down mandates with taxpayer moneysplurge as reward for failure has anything to do with a "free market" is a plain incapacity to comprehend the situation.
"(how many patients can be treated with that kind of money?)"
Surprisingly few. £10bn is the NHS's budget for about 30 days, and the NPfIT existed for about 8 years. National IT infrastructure spending represented c. 1% of NHS spending in any given year. Yes it's a tremendously large amount of money and the project has been a failure almost entirely across the board*, but in the context of the NHS, an organisation that employs c. 1m and provides services to c. 65m, it's not that large an amount.
*certain elements succeeded well, mainly N3, Choose & Book and NHS mail - N3 has since been "upgraded" by being scrapped and integrated into the wider public service network, where "integrated" means "all local operators now have to go begging to their local ISPs for their connections and then implement their own methods of connecting to the rest of the PSN.
The NHS is starting the benefit from leading hospitals such at Leeds Teaching Hospital and Kings College Hospital who are developing in-house and then releasing these developments as open source code bases. Examples of these include the Clinical Portal at Leeds and two projects from Kings; Wardware, en electronic observations system, and some recent work around Apache Service Mix for systems integration.
I'm a big fan of Carl. He doesn't brook any nonsense or failure in healthcare IT. NHS Hackday highlights the art of the possible and has successfully produced one system that is (nearly?) in production use at a Trust: CellCountr. See http://www.cellcountr.com/about/.
With the support of commercial organisations like Tactix4, not-for-profit projects like HANDI Health and openGPSoC and with the leadership of these exemplary trusts, opensource is becoming less of a 'perceived risk' for Trusts and is becoming a business decision that Trusts and other Healthcare providers are taking with increased confidence and, most importantly, understanding more often than ever before.
Declaration of interest: I have been at each of the last three NHS Hackdays, led eHealthOpenSource (an industry/NPfIT JV), am co-founder of HANDIHealth and openGPSoC and a Director of Tactix4.
Except of course they have, actually, released code publicly.:
http://www.ehealthopensource.com/codeforge/
Github is not the only code publishing service ... or are you a one true way zealot?
There is plenty more code inside N3 as well ... so I guess it depends on how people choose to define community....
Even beyond the forward thinking trusts that have put a lot of work into producing these excellent open products, there are some examples of trusts managing to get things right with their unholy mix of commercial suppliers and consultants. The one that springs to my mind immediately, mostly due to my proximity to the project, is North Tyneside. Their chief exec comes from a pure corporate management background, so he's not easily taken for a ride. He got all his various IT suppliers (and there are many; MS, Dell, TPP, CapGemini, Accenture etc. etc.) sat around a table all at once and simply stated that if they didn't get their act together and deliver on the trust's 3 year plan for integrating all their systems (leading to a growth in remote healthcare etc.), he'd simply take it all in house.
The best bit was this was an amazing bluff. Nearly no trust has the money to develop these kind of solutions on their own, and they certainly don't have the money to do that AND migrate mission-critical healthcare systems based on proprietary consultant-mangled backends. North Tyneside based this bluff on an IT staff of about 30-50 (dominated by first/second tier support staff)
And yet, somehow, they're pulling it off. I don't know whether it's the contractors finally realising the NHS is no longer a bottomless pit of money, or elements of the Foundation Trust programme paying off in terms of good commercial management, but somehow they're finally dragging all these old elements, inherited from the NPfIT, into one thoroughly modern system on schedule and on budget.
I guess my point is that the top-down design approach can work, just like the bottom-up hacking approach can work. My fear rests in that the realities facing the NHS, with naive and inexperienced GPs with no experience of either specialist healthcare or large scale organisational management holding the budget, endanger any and all approaches. Trusts will be fragmented, forced to fight for every scrap, limited in their strategic planning, almost outright banned from co-operation. How can any organisation, particularly one that employs a million people, expect to adapt to the modern world in that environment?
1. Get some people who know what they are doing . Pay them to do it. Come back when it's done.
2. Choose the people in charge at random and change them at irregular intervals. Get big players in a similar industry to tell them what them want. Throw in disruptive political party expediencies for good measure.
Method 1 has a patchy track record. Has had some notable successes. Has little career enhancing pay back for the politicos of the day.
Method 2 has consistently and spectacularly failed. Gives politicians regular opportunities for claiming money saving 'new initiatives' and 'it was all the other guys fault.
Which would you choose? That's why you are not currently on an all-expenses-you-can-get-away-with all-power-no-responsibility gravy-train and have to work for your money instead.
How do you know if a solution is any good? Only if it solves your problem. Vendors don't understand the government's problems, even if they claim they do.
Mind you, the government doesn't understand its own problems. They think the problem is IT. It isn't. The problem is all about information.
That article makes the same mistake as the government, hence the title "Why hacking and platforms are the future of NHS IT" The future of the NHS lies in the NHS working out what information it needs, how it is gathered and how it is managed. Only then can anyone decide if a solution (or platform) is any good.
The platform approach outlined in the article is a bit like going to a builder because he has all the right builder's tools. And then finding out you need a back-hoe and crane, which the builder hasn't got. The builder (and his tool "platform") is useless.
Working out the value of a solution means understanding what problem you are trying to solve. That's where the value of solving a problem lies, not in the solution space. Solutions just cost money.
Platforms are all about solutions, not problems. The government will only make progress when it realises that solutions are cheap and plentiful - every vendor has lots of them. The government owns its problems and will get value from solving them; it's about time it started to understand its problems - starting with information, not technology.
I worked in the NHS when the NPFIT (Connecting for Health) was implemented.
The implementation failed for a number of reasons, but mostly because they did not get "buy-in" from any staff, in fact I think it was NHS IT staff at a Trust level that made the biggest impact on its failure; partly by refusing to co-operate and partly by incompetence. They either refused to provide critical access control information or would play dumb. Many IT staff told me that they would do all they could to wreck it.
The whole system was badly conceived, never mind what software exists and can be interfaced with HL7, let's spend billions rewriting everything from scratch. Never mind 20 years of research data held in those legacy systems, many of which worked perfectly well.
Consider how Wales did their National Programme for IT, they did a needs analysis, left what was working in place and replaced what was necessary.
Then you had systems being implemented without critical functions like clinics, so hospitals could not run clinics to see new patients, a complete joke, the leads time for clinics was quoted as a future update (3 years away).
As for the LSP's well I was encouraged to bribe one very senior manager and when I declined, we were cut out of that whole area.
Now there is evidence that credit check companies have got access to the spine data, is that a form of hacking, I think so.
"does anyone still believe in large top-down centrally architected IT solutions?"
Well-built ones, sure? The problem seems to be related to the fact the NHS has no clue about IT and they'll pay any invoice levelled at them. In principle a national system for the NHS is a Good Thing (TM). Actually there's an argument that this is a government cluelessness problem, but one that's easily fixed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
