Overview of Open Source and VistA in the UK's NHS

This is a great article by Ewan Davis on the current debate in the UK regarding NHS England's newly announced open source health IT strategy and whether VistA should be used as the "core EHR." This is the most exetensive and thorough discussion on the subject and Open Health News is very pleased that Davis has give us permission to reprint it here so that this information is available to a wider audience (the article originally appeared in Davis' blog). Roger A. Maduro, Publisher and Editor-in-Chief, Open Health News.

Many of the issues discussed here will feature at the HANDI Health Apps Conference – Collocated at EHI Live 5 6 Nov NEC Birmingham

Ewan DavisThere is much widely publicised interest from NHS England in encouraging the development and implementation of open-source software in the National Health System (NHS) with the debate raging in a number of forums, notably on ehealth Insider (EHI) where this article and the comments it has generated are vital reading for anyone interested in this issue.

This debate has been fueled by the availability of NHS England’s £260 million Technology Fund which is actively soliciting open source projects include bids to implement an NHS VistA based on the open-source EHR/HIS originally developed by the US Veterans Health Administration (VHA) and now used by a number of others in the US and elsewhere.

I have written before on this blog about VistA and concluded that this is not the right solution for the NHS. However, I’m now no longer sure and feel that it might have a role. I’ll return to VistA below but before I do I’d like to set some context.

First, and most importantly we should understand that the success of many open-source projects lies in the open, agile and collaborative approach that open source naturally engenders, rather than narrowly on the licensing model. VistA has been successful in the U.S. Department of Veterans Affairs (VA) because it achieved high levels of clinical engagement by allowing clinicians to get directly involved in quickly solving problems that mattered to them. Traditional models of user engagement where 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 too late and too expensive to make substantial changes) are completely ineffectual in a complex area like health (see Dr Tony Shannon’s blog  to understand what I mean by complex).

Design is critical both in terms of the user interface and user experience, but also in terms of the underlying information models and this requires the intimate involvement of clinicians and their patients throughout the software development lifecycle (see my blog  Time for Zero-Tolerance for more on design and Tony Shannon’s 1 developer 1 clinician for a practical example of agile user centred design).

NHS England's Focus on Open Source

NHS England’s interest in open-source the result of pressure from both above and below.

From above from Government CTO Liam Maxwell with the publication of the “Government Service Design Manual” which states: “There must be a level playing field for open-source and proprietary software solution [sic], that allows organisations the flexibility to change technologies and innovate based on data.”

With the current focus on open standards, open data, and open interfaces (APIs) – and while there is recognition that proprietary software can (and indeed will be required to) deliver these this things – there is a view that they go most comfortably hand-in-hand with open-source.

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. These projects have demonstrated how open-source approaches foster agile cooperation between disparate NHS organisations and how forward thinking companies can stimulate and support such activity building sustainable business models and creating wealth as they go. I’m thinking here of projects in London’s Moorfields, Leeds Teaching Hospitals NHS Trust, Kings College Hospital, Luton & Dunstable and work with the open-source nursing observation database app Wardware. 

At a national level pressure is coming from open-source projects spawned by the NHS ITK Information Sharing Challenge Fund (available on the eHealthOpenSource codeforge) and the replacement of NHS Spine using open source technologies.

Interestingly, although these projects started independently, both the projects 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 (in particular OpenEHR). Such cooperation is a direct result of the decision to embrace open-source and it is of great benefit to the NHS and those companies who understand how to exploit these new ways of working.

I’m convinced open-source has a central role in the development of digital health and care, but I also know it’s not a “magic bullet” and that its role is as part of mixed economy of both open-source and proprietary components (all supporting open standards, open data and open interfaces (APIs)).

Benefits of Open Source

Open source brings a number of benefits:

• Users are guaranteed value in relation to the services they buy to help create and implement open source solutions. No organisation has a monopoly position in the provision of these services created through the ownership of intellectual property rights, ensuring a vibrant and competitive market for such services.
• Open source projects can make use of proven pre-existing open source components, the licensing terms of which typically require products incorporating them to be made available as open source.
• Open source fosters cooperation and sharing. This is particularly important when addressing difficult problems where fragmentation of effort can mean nobody finds a solution and for infrasructrucal components where equal access is essential.
• All users get the benefits of any enhancements anyone else chooses to make to the product, not just those upgrades they are willing to buy or fund themselves.

However, open source is not necessarily going to be sustainably cheaper 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. Many argue that other cost are likely to be broadly the same using open-source or proprietary solutions (I’m not so sure that the loss of the built-in advantage the IPR owner has in delivering many of these other services, won’t increase competition and drive prices down, but we don’t have much evidence either way).

The Advantages of an SOA Architecture

The critical factor for any software product is that there is a sustainable business model enabling investment to create innovative products and to support it to ensure it continues to meet users needs and in some cases this is more easily achieved with proprietary software – The interesting debate is about which classes of components in the ecosystem are best delivered using open-source and which proprietary solutions. Let’s look at what I think a digital health and care ecosystem should look like. This is illustrated in the diagram below:

This represents a platform based or service oriented architecture (SOA) which creates a digital ecosystem in which multiple components compete and cooperate to provide the digital capabilities needed by individual user.

There are three classes of components in this architecture:

• Application components – These provide the user interface and manage workflows and perform transaction to support the delivery of care. They do not contain any knowledge or information about how to do these things nor do they persist the data they create in the performance of these things, rather they draw on ecosystem services for the data, information and knowledge they need and to store any data, information or knowledge they create. Some of these components provide tools for the creation and maintenance of the data, information and knowledge in the ecosystem and to perform “back office” functions.
• Ecosystem Services – These store the “data resources” created and consumed by the application components – These resources include: Information about patients (the EHR); knowledge about care and treatments (care pathways, decision support rules and heuristics and the data and metadata to populate and drive them); and information about resources and services available to deliver care (people, equipment, physical facilities and services).
•  The Enterprise Service Bus (ESB) – This provides facilities to allow application components to interact with ecosystem services and each other. It is able to provide transformations between supported standards and services to facilitate and/or enforce ecosystem operation and polices – I describe in more detail what an ESB might do in my earlier blog  and while this relates to GP systems similar principals apply more widely.

The key feature of this architecture is “separation,” both vertically and horizontally. Data resources are separated from each other and the application components that consume and maintain them. Similarly, application components are separate from each other performing a limited range of functions communicating with each other only through the ESB. To some extent, the way in which the scope and granularity of services and application are defined in arbitrary and this needs to be tuned to give the best balance of flexibility, performance, usability and sustainability. Also to operate effectively the ecosystems needs to operate within a governance framework agreed by participants. Such a framework might define things such as design and user-interface principals, the standards to be used and principals concerning information governance issue such as security and consent.

A secondary feature of this architecture is that it does not require a single authoritative instance of any one component. You can have multiple competing applications and services performing similar functions and even multiple ESBs (maybe federated, hierarchical or both),  although in practice it might be decided to restrict the diversity, particularly at the service and ESB level to simplify operation (e.g. a care community might decide to have just one EHR).

These two key features make it much easier for the ecosystem to evolve as it is possible to easily substitute alternative applications and services to deliver small incremental changes and 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 (such as the “megasuites” described below).

Over time it becomes possible to change all of the components and underlying technologies in the ecosystem as better alternatives emerge while maintaining care and business continuity. This approach also makes localisation easier as the data resources that define the local configuration are clearly separate from the applications which if well designed are locality independent.

The Issue of VistA in the NHS

So to VistA – VistA looks nothing like a digital health and care ecosystem – It looks more like what Gartner describe as a ‘megasuite’ as 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. Garner cites the products of companies such as Cerner, Epic, McKesson, Allscripts and others as megasuites and some of these products have the significant advantage over VistA that they are already either localised or being localised for UK use. Typically these suites lack the clear separation between components which define an ecosystem and once you chosen one you’re stuck with it unless you are willing to accept considerable cost and disruption to make a change.

Indeed, because of its’ age VistA is more monolithic than some of the commercial megasuites. There are good historical reasons why this is the case as eloquently described by VistA expert Rob Tweed who says:

“VistA: Why it’s like it is

• Hardware limitations at the time:
–Very expensive
–Very low-powered hardware–Very little memory– Developer time relatively less costly

• Code written to:

– minimise resource usage
– Maximise performance
–At the expense of maintainability”

This is taken from Rob Tweed’s Excellent EWD Files where he has a lot more to say about VistA, The MUMPS language and database it uses and also about how we can solve these problems and modernise VistA without throwing out the bay with the bath water. I’ll come back to this later.

So why my partial change of heart about VistA described in my introduction? Well this flows from some things I participated in over the last couple of weeks where I have been able to meet more people from the VA and VistA, talk further to VistA users, experts and proponents and explore some of the issues emerging with experienced NHS clinicians, industry and other colleagues.

The central driver of my changing opinion is the discovery (to some extent a confirmation of things I already knew) that the VistA community accepts many of the weakness of VistA, shares my vision for the creation of a open digital health ecosystem and have been actively engaged in doing something to move VistA in the right direction. You’ll find all you need to know about this by looking at the EWD Files  referred to above and the World VistA and OSEHRA web sites.

These discoveries leave me with one burning question. Does it make sense for the NHS and the UK open-source health and care community to join the VistA community on their journey?

The VistA community has no alternative but to start from where they are. 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 as would be any attempt at a big bang re-implementation of VistA using modern technology with previous attempts and millions of lost dollars providing all the evidence needed to confirm this view.

However, 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 ways as which the VA rely on VistA. We also have a number of open-source projects built using more modern tools and approaches, many based on work that already has international support. So we have a choice of starting points some of which may be more attractive than VistA.

Pros and Cons of Using VistA as the "Core" EHR in the UK

So the issues and the pros and cons ?

Pros

• We share a common vision with VistA to create an open digital health ecosystem – A vision shared by many others global by amongst both the open source community and the existing vendor community. By working with VistA we get the benefit of the investment and intellectual resources of the VA others in the USA and the World VistA community, which might make it easier to achieve our vision.
• The VistA community can help us learn and develop the tremendously successful approach they have used based on strong clinical involvement and agile user centred development. This approach and culture is the single most important reason for VistA’s success.
• VistA provides rich function breadth and depth making it the only thing to come close to the functional richness of the commercial “megasuites.” Building such functional richness from scratch is a major barrier in the delivery of enterprise wide open-source solutions. However, like 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 the MUMPS database provides a robust, scalable and performant database well suited to handling health data (many other successful EHR systems use MUMPS; EPIC, EMIS LV, Partners HealthCare, Meditech, GE Healthcare). It’s important to understand that using the MUMPS database need not tie you into the integrated MUMPS language (again see the EWD files for more.)  I favour polyglot persistence in the ecosystem, which would allow multiple technologies in the persistence layer so we can explore what works best and above all avoid getting locked into a particular technology.
• There is some very influential support at the “top of the office” for VistA which includes Ministers, senior officials and some very senior clinicians. In my view to some extent these people conflate the amazing broader transformation of the VA with the effects of VistA, but the VistA concept provides a powerful synecdoche. This combines with more practical enthusiasm from some of our most gifted young clinicians (and some not so young) in the open-source community, who have had the opportunity to see VistA in action to create the support needed for the broader open-source agenda to be driven forward.
• 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.
• VistA broadly as is plus essential localisations has the potential to act as a market disruptor supporting alternative business models based on open-source and driving competition and value for the NHS.

Cons

• VistA technology and architecture is old. The work underway to incrementally transform it into a SOA based platform is impressive, but the task in 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 – Something I have previously described as “a better way to do the wrong thing.” If VistA’s transformation to a platform is successful this issue will eventually go away, but at its’ current state VistA is unlikely to be attractive or appropriate to those communities and institutions already well advanced in their journey to digitisation.
• The VistA software does not offer any significant functionality that is not available in the commercial megasuites (indeed if you accept the Gartner report (1) of 2011 it lags somewhat behind overall). There are also  there many more narrowly focused systems which could be integrated into a “best of breed” approach whose functionality exceeds the equivalent functionality in both the megasuites and VistA and which in many cases have been built for the UK market.
• The localisation challenge is significant and in my direct personal experience usually vastly underestimated. The tangled architecture of VistA with no clear separation between clinical content, configuration and functionality along with tight integration between functional modules will make localisation more difficult. I have heard from American colleagues who have localisation experience in Jordan that this won’t be such a problem, but I don’t believe it the NHS is not Jordan and my concerns about localisation are shared by all I know with direct experience of  localising US products for the NHS.
• Resource with an understanding of VistA and MUMPS is scarce and in particular finding and retaining developers able and willing to work in the arcane MUMPS language has been a challenge for VistA. While the modern VistA tools described elsewhere remove this constraint from much VistA development localisation is likely to require work in the core with the MUMPS language. It been suggested to me that if work is available for developer in MUMPS they will learn the language a beat a path to our door. I don’t believe this, in my experience gifted young developers value using the latest tools over financial reward and in any case demand for them is such that they can easily get both although health care has the advantage that its’ potentially  high social value will attract the top developers if we can create stimulating projects.

The Challenges Posed by the Patient Administration Systems (PAS) and Clinical Content

I have had the opportunity to discuss the localisation challenge with others with relevant experience and we conclude that the two main areas of challenge are the PAS and clinical content.

Patient Administration Systems (PAS) are the foundation of which hospital systems are built. PAS systems are not complex but can be complicated and deal with many things that are uniquely peculiar to the English NHS (mandatory reporting, SPINE and C&B interfaces, PbR) and deals with those things that if not done mean the Trusts does not get paid and the CEO (and probably the whole Board) get fired. Industry experts warned the National Program for Information Technology in the NHS (NPfIT) that PAS replacement was a bad idea and that they should build clinical functionality on existing PAS infrastructure, but this advice was ignored. This led to a massive lack of progress as the LSPs discovered that PAS replacement was not as simple as they thought and those Trusts persuaded to take this route experienced much pain, found a negative impact on patient care (it must of cost some lives) and lost income, with the promised enhanced clinical functionality coming much later (indeed with Lorenzo in the North it has still not arrived for most).

Clinical content is at the heart of system configuration and encompasses many things. At the simple end code lists, catalogues, service and resource directories but becomes more complex as you start to deal with terminologies (SNOMED is particularly treacherous territory) clinical models, workflows, pathways, decision support rules and statutory and regulatory requirements. Configuration management (including clinical content) is complex because in needs to support subsiduarity allowing multiple levels of localisation in a sustainable and maintainable way that allows national changes to flow down and local innovation to flow up without breaking individual localisations. My view is that we may be able to  kludge these issues in the short-term but that an adequate solution is urgently required will require the clean separation of content and function with standardised and computable representations of the various classes of content in which I feel things including OpenEHR, OpenClincal, SNOMED, and CIMI have an important role to play.

In the context of VistA we believe that the PAS issues can be addressed by implementing VistA on top of existing PAS and not repeating the error of the NPfIT. The practicality of this needs further investigation but an initial discussion between VistA and PAS experts are encouraging.

Clinical content is more challenging and this needs further work to identify the scope of the issue. NHS England have ePrescribing at the top of their agenda and this means that one of the more complex aspects of clinical content will need to be addressed early on.

So after all this I find myself climbing back on the fence with an inclination to at least put a foot down on the side of NHS VistA. For me the unanswered questions are about localisation and the ways in which any NHS VistA activity can support and integrate with the existing UK based open-source activity.

I remain fervently opposed to the idea of VistA as a single system for the English NHS, but 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.

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 in particular how we integrate with other work based on open source and proprietary implementations open-standards. For me this is the key attraction of VistA, that it might help us speed the development of an open digital health platform. This to me is the great attraction of VistA. If it can do this, and I think it can,  it has my support. Otherwise it is  probably a distraction and has little relevance in the UK.

Collaboration as Key to Successful Open Source Projects

But, finally I return to my opening point “the success of many open-source projects lies in the open, agile and collaborative approach that open source naturally engenders, rather than narrowly on the licensing model” There is a danger that the NHS could treat open-source projects (and particularly NHS VistA) as like a open-source version of the NHS NPfIT. 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 and the focus has to be on agile user centred design with clinicians and other frontline health and care professional working with their patients and service user, supported by the very best digital engineers and other informatics professionals  to rapidly and incrementally deliver digital tools that support the delivery of high quality care.

I welcome comments please add these below.

Acknowledgements

I’d like to acknowledge the help of the following in reviewing and contributing to this document although the views expressed are mine and not necessarily endorsed by them.

• Bill Aylward – OpenEyes and Moorfields Hospital
• Silas Davis – Developer – SwiftKey
• Rob Dyke – Tactix4 and Wardware
• Prof. John Fox – OpenClinical, University of Oxford and Royal Free Hospital London
• Dr Phil Koczan – GP and UCL Partners
• Dr Ian McNicoll – OpenEHR and Ocean Informatics
• Dr Tony Shannon – Emergency Physician – Leeds Teaching Hospital
• Colin Smith – NHS VistA
• Rob Tweed – M/Gateway Developments Ltd
• Dr Wai Keong Wong –  Hematology Registrar, North Central London Rotation (Royal Free Hospital/ UCLH/ Whittington Health)

References

In most cases wen links to items referenced are embedded in the text above the only exception is the Gartner Report which does not seem to be available free to web:

(1) Gartner  “VistA Comparison to the Commercial Electronic Health Record Marketplace” Final Report February 4, 2011

Some significant web site with a broad range of material relevant to matters discussed in this blog.

• www.handihealth.org
• www.openclinical.net
• www.openclinical.org
• www.openehr.org
• www.worldvista.org
• www.osehra.org
• EWD Files (http://robtweed.wordpress.com)
• eHealthOpenSource codeforge (http://forge.tactix4.net)
• http://frectal.com/
• http://nhsvista.org/

Note: openclinical.net focuses on the specific open clinical technology while openclinical.org provides a valuable resource covering a the international clinical knowledge management domain.

Ewan Davis is a Director of Woodcote Consulting Ltd www.woodcote-consulting.com  and HANDIhealth CIC www.handihealth.org and has worked in Healthcare Informatics in the UK since 1981. Ewan was founder and Managing Director of AAH Meditel (a leading supplier of EPR systems to family physician (GP) practices in the UK ) from 1987 to 1999. He is a past Chairman of the Primary Healthcare Specialists Group of the British Computer Society of which he remains an active member.

Ewan has been an active member of Intellect (the UK trade association) www.intellectuk.org  and its predecessor bodies (CSSA and CSA) since 1981. He was Chairman of the CSSA Primary Healthcare Group from 1996-99 and has served as Vice Chairman of the Intellect Healthcare Group and is currently a member of the Intellect Healthcare Council. Ewan’s current interest is focused on work to encourage an open health IT ecosystem which will allow health and care software and apps from multiple vendors to play nicely together  enabling a transformation in the way we deliver health and care and creating much greater opportunities for players in the sector.

[email protected]  @WoodcoteEwan