There is much, widely publicised interest from NHS England in encouraging the development and implementation of open-source software in the NHS.

In general, this has been welcomed. However, there has been a fierce debate about whether that encouragement should extend to Anglicising the US Veterans Health Administration’s open source electronic patient record, VistA.

EHI editor Jon Hoeksma has argued that NHS England should look closer to home  before it spends some of the £260m Technology Fund on a VistA pilot or VistA projects; and a lot of EHI readers have agreed with him.

I have previously concluded that VistA is not the right solution for the NHS myself. However, I now feel that it might have a role for some trusts in adding clinical functionality to their existing PAS systems – if localisation issues can be cracked.

I also feel it could play a wider role, if it can evolve into a digital health platform that will support the mixed economy of proprietary and open source solutions, and open standards, that we will need in the future. Although that is quite a big ‘if’.

Top down, bottom up

NHS England’s interest in open-source is the result of pressure from both above and below. From above, the pressure is coming from government chief technology officer Liam Maxwell, whose ‘Government Service Design Manual’ calls for a level playing field between open-source and proprietary software, to encourage flexibility and innovation.

From below, we have pressure from the growing number of open-source projects in the NHS that are demonstrating success and gaining traction on a greater scale.

I’m thinking here of projects at Moorfields Eye Hospital, Leeds Teaching Hospitals, Kings College Hospital and Luton and Dunstable trusts; although, at a national level open-source projects have been spawned by the NHS ITK Information Sharing Challenge Fund and the replacement of the NHS Spine using open source technologies.

These projects started independently, but both they and their commercial partners – companies like Tactix4, Ocean Informatics, BJSS, and Black Pear Software – are increasingly cooperating, sharing code and driving convergence to common open-standards and, in particular, OpenEHR.

Open source matters because it’s open, agile and collaborative

Open source is often pitched on its licensing model – the idea that because its licenses are free, it must be cheaper than proprietary software. In fact, open source will not necessarily be a substantially cheaper option.

Typically, only around 20% of the total cost of ownership of an IT system is in software licence cost and development still has to be paid for. Instead, the success of many open-source projects lies in the open, agile and collaborative approach that open source naturally engenders.

Traditional models of user engagement, in which users are only involved in requirements gathering (when they don’t really know what the technology could do for them) and final testing (when it’s too late and too expensive to make substantial changes) are completely ineffectual in a complex area like health.

By contrast, VistA has been successful in the VA because it has enabled clinicians to get directly involved in quickly solving problems that matter to them.

Thinking about an SOA for healthcare

The critical factor for any software product is that there is a sustainable business model that enables enough investment to support it, make sure that it continues to meet users’ needs and enables the development of further, innovative products.

The interesting debate is about which classes of components in the ecosystem are best delivered using open-source and which by proprietary solutions.

In a platform based or service oriented architecture, there are typically three classes of components.

First up, there are application components, which provide the user interface, manage workflows, and perform transactions to support the delivery of care.

Then, there are ecosystem services, which store the data resources created and consumed by the application components – in the healthcare setting, these include information about patients, knowledge about care and treatments, and decision support rules.

Finally, there’s the enterprise service bus, which provides facilities to allow the other two components to interact with each other.

To operate effectively, the ecosystem needs to operate within a governance framework agreed by participants, which might define things such as design and user-interface principles, the standards to be used, and information governance issues.

However, the point of the ecosystem is that it can evolve. It is possible to easily substitute alternative applications and services to deliver small, incremental changes. It is possible to change and extend the data resources in the system without needing to immediately change the applications that consume them.

This allows diversity and Darwinian selection and avoids the need for the periodic and incredibly disruptive upgrades and system changes associated current enterprise systems. It also makes localisation easier, as the data resources that define the local configuration are clearly separate from the applications that, if well designed, are locality independent.

VistA: really a “megasuite”

So to VistA. VistA looks nothing like a digital health and care ecosystem. It looks more like what Gartner describes as a ‘megasuite’; a set of tightly integrated components designed by a single vendor to work together to provide all or most of the functionality needed by a health care enterprise.

Gartner cites the products of companies such as Cerner, Epic, McKesson, Allscripts and others as megasuites. Typically these suites lack the clear separation between components which define an ecosystem and once you have chosen one you are stuck with it unless you are willing to accept considerable cost and disruption to make a change.

Indeed, because of its age, VistA is much more monolithic than some of the commercial megasuites. There are good historical reasons why this is the case.

VistA expert Rob Tweed says many of them come from the hardware limitations of the time – hardware was expensive, low-powered, and short on memory – so code was written to minimise resource usage at the expense of maintainability. There are also issues with the MUMPS language and the database it uses.

A megasuite that might become something else

That is why I was initially far from keen on VistA. However, the debate over the past couple of weeks has shown me that the VistA community accepts many of the weakness of VistA.

Indeed, it shares my vision for the creation of a open digital health ecosystem, and has been actively engaged in doing something to move VistA in the right direction (see Rob Tweed’s blog and the World VistA and OSEHRA web sites).

That said, the VistA community has no alternative but to start from where it is. The idea of replacing VistA in the VA (where it is liked and understood by clinicians and where it has played a key role in the transformation of VA Healthcare from “Basket Case” to “Best Care Anywhere”) is a lunatic one.

In the NHS we don’t have the baggage of the VistA legacy. Our legacy is much more diverse – great in parts, dreadful in others – but we haven’t got a single system on which the NHS relies in the same way that the VA relies on VistA.

We also have those open-source projects built using more modern tools and approaches. So we have a choice of starting points, some of which may be more attractive than VistA.

VistA and PAS

We also have a different history to learn from. Patient administration systems are the foundation on which many hospital systems are built, and they deal with many things that are uniquely peculiar to the English NHS (mandatory reporting, Spine and Choose and Book interfaces, Payment by Results).

Industry experts warned the National Programme for IT in the NHS that PAS replacement was a bad idea and that the programme should build clinical functionality on existing PAS infrastructure, but this advice was ignored.

This led to a massive lack of progress as the local service providers appointed by NPfIT discovered that PAS replacement was not as simple as they thought. Those trusts persuaded to take this route experienced much pain (and the promised clinical functionality of Lorenzo has still not arrived in the North, Midlands and East).

When it comes to VistA, I believe that our PAS issues can be addressed by implementing VistA on top of existing PAS systems, and not repeating the error of NPfIT. The practicality of this needs further investigation, but an initial discussion between VistA and PAS experts is encouraging.

VistA and clinical content

Things are different when it comes to clinical content, which is at the heart of system configuration. At the simple end, there are code lists, catalogues, service and resource directories; but things become more complex with terminologies, clinical models, workflows, pathways, decision support rules and statutory and regulatory requirements.

Configuration management (including clinical content) is complex because it needs to allow national changes to flow down and local innovation to flow up without breaking individual localisations.

This makes clinical content more challenging, and we need further work to identify the scope of the issue. NHS England has e-prescribing at the top of its agenda, which means that one of the more complex aspects of clinical content will need to be addressed early on.

My view is that we may be able to kludge these issues in the short-term, but that an adequate solution is urgently required. This will require the clean separation of content and function, with standardised and computable representations of the various classes of content.

OpenEHR, OpenClincal, SNOMED, and CIMI will all have an important role to play. The unanswered question is whether NHS VistA activity could support and integrate with the existing UK based open-source activity in this space.

The balance sheet

So, I remain fervently opposed to the idea of VistA as a single system for the English NHS, because there is a danger that the NHS could treat it as an open-source version of NPfIT.

However, I can see value in implementing it with the minimum necessary localisations in a few suitable NHS trusts, as a step on the journey to the creation of an open digital health ecosystem.

This means that, in parallel, I would like to see an exploration the transformation of VistA into a digital health platform that can support a mixed economy of open-source and proprietary solutions and integrate with other work based on open-standards.

In all of this, though, the centre has a role in catalysing and enabling open-source in the NHS, not in managing it. Leadership needs to come from the frontline, supported by the very best digital engineers and other informatics professionals, to rapidly deliver digital tools that support the delivery of high quality care.

About the author: Ewan Davis is the managing director of Woodcote Consulting. He is also one of the founders of the Healthcare App Network for Development and Innovation. This column is a shortened version of his blog posts on the NHS and VistA.

Pros and cons of NHS VistA

Pros

  • We get the benefit of the investment and intellectual resources of the VA and the World VistA community. The latter can also help us to learn and develop the tremendously successful approach it has used, based on strong clinical involvement and an agile, user centred development.
  • VistA itself provides rich function breadth and depth; it is the only thing to come close to the functional richness of the commercial “megasuites”. Building this from scratch is a major barrier to the delivery of enterprise wide open-source solutions. However, as with many of the megasuites, extracting individual elements of functionality for use in a SOA is not trivial.
  • MUMPS is a very mature example of the now trendy NOSQL database and is well suited to handling health data. Using the MUMPS database need not tie you into the integrated MUMPS language and I favour polyglot persistencel.
  • There is some very influential support at the “top of the office” for VistA; this includes government ministers, senior officials and some very senior clinicians. There is also more practical enthusiasm from some of our most gifted young clinicians in the open-source community.
  • There is enthusiasm in the VistA community (and indeed a little existing work) to look at how some of the open-source approaches in use in the UK can be integrated into the VistA modernisation programme.

Cons

  • VistA technology and architecture is old. The work underway to incrementally transform it into a SOA based platform is impressive, but the task is non-trivial and far from finished. Do we want to become mired in it?
  • Going down the VistA road means a least a partial commitment to the idea of a single (or primary) open-source system in a health community or institution. If VistA’s transformation to a platform is successful this issue will go away, but in its current state VistA is unlikely to be attractive to those well advanced in their journey to digitisation.
  • The localisation challenge is significant and vastly underestimated. The tangled architecture of VistA with no clear separation between clinical content, configuration and functionality. This, combined with tight integration between functional modules, will make localisation more difficult.
  • Resource – particularly developers – with an understanding of VistA and MUMPS is scarce; and I don’t believe that developers will rush to learn MUMPS just to work on an NHS VistA project, however socially rewarding it might be.