Dear healthcare IT community…A software developer’s perspective

As a software developer working for a small vendor I sympathise with the sentiment expressed in Wai Keong Wong’s open letter on e-health insider this week . However, I think the current situation with vendors is largely due to the way procurement has been handled, at least in my 8 years experience.

Like many healthcare IT software companies, ours was started by an NHS doctor who, frustrated with the IT systems he was  using at work, developed a replacement for use in his department. The product was very successful internally – largely down to being developed very closely with the end users and the small scale allowed rapid product iterations. Unfortunately, despite many years of successful use and continued development through the CfH years we effectively locked out of the market because nobody wanted to commit to non-CfH systems.

Fast forward to the demise of CfH and we’ve expanded to several trusts and continue to work closely with end users and raise the bar when it comes to hospital IT. It’s been a sharp learning curve working out how to sell into trusts. Attitudes towards vendors are changing, but I have the following observations (in no particular order) which may explain some of the reasons we’re in the current state.

  1. Most trusts are very risk averse – no surprise here! Procurement processes tend filter out companies which don’t have £X million turnover and have software deployed in lots of trusts (immediately disqualifying most startups!) before there any discussion about whether the product is any good. That makes starting a company to sell into the NHS very difficult and no doubt is a blocker to innovation.
  2. The market is very price competitive. There is almost no money to be made up-front and the cost of sales is very high (all those procurement hoops you have to jump through). If you have a business model like that then there is no option but to charge more for support / changes which leads to tension on both sides (customers don’t want to pay for every little change and vendors want to fix / improve things but the customers aren’t always willing to pay for it).
  3. Tender requirements are usually backwards looking. It is common to see something like “software must work on a Windows XP machine running IE6 with 256MB RAM” but I have never seen anything along the lines of “software continually be updated to support the 3 most popular web browsers on all Microsoft desktop operating systems still in support” (we do that, but nobody asks us to). I don’t think we have ever been asked to support the common user interface or provide guarantees about future interoperability. Customers need to start demanding these kind of things from vendors.
  4. It is too easy for companies to answer “yes” to tender requirements and then negotiate out of it later. The tender acts as documentation but then isn’t very useful in actually evaluating whether the product is going to be able to deliver. Thus you end up with a Market for Lemons.
  5. There are often many different IT solutions to a problem. This frequently gets political and means that the user ends up with a substandard solution (design by committee). For instance if a trust has committed to an expensive solution then it would take a lot to steer them towards a better, low cost solution, even if they are already running the software.
  6. Vendors are in a fantastic position to promote best practice and knowledge sharing between customers. We see trusts trying to solve the same problems and have the clinical and process change expertise to advise but, disappointingly, this is often seen as outside of our remit. There is a lot of process variation between trusts trying to achieve the same goals and we are in a position to recognise that and get them to talk to each other.
  7. In general, the NHS lacks in-house experts in core IT standards such as HL7, ITK, SNOMED CT / DM+D, NACS / SDS data sets. Many trusts still don’t have integration engines despite the availability of free / open source solutions.
  8. We can usually develop fixes / features much faster than trusts are in a position to accept product updates. If somebody reports a bug we will probably fix it within a day or two but it might be anywhere between 3 months and 2 years before a trust wants to upgrade. We prefer small and frequent updates but that doesn’t usually fit with trust policies.

So, we seem to be  in a position where there is a market hostile to small companies, high up front costs and little recognition for high quality product design – it’s no wonder that NHS IT is in poor shape. It is not all doom and gloom though! There are encouraging signs with events like NHS hack day on the horizon and increasing awareness of the problems with current approaches to software in the NHS and discussion around a different approach. Exciting times ahead!