Many of the issues discussed here will feature at the HANDI Health Apps Conference – Collocated at EHI Live 5 6 Nov NEC Birmingham
A slighty amend version of this blog piece with a brief commentary for those outside the UK is available on Open Health News a shorter version is available on eHealthInsider
There is much widely publicised interest from NHS England in encouraging the development and implementation of open-source software in the NHS with the debate raging in a number of forums, notably on EHI where this article and the comments it has generated are vital reading for anyone interested in this issue.
This debate has been fuelled 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 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 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 involve 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 term 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 interest is 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 While at a national level 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 they and their commercial partners (companies like Tactix4, Ocean Informatics, BJSS and Black Pear Software) and 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 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))
Open source brings a number of benefits:
Users are guaranteed value in relation to services they buy to help create and implement open source solutions as 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 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). Overtime 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.
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 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 have 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.
So the issues and the pros and cons ?
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 usinbg 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.
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 focussed 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.
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 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.
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
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)
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.
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.)
EWD Files http://robtweed.wordpress.com
eHealthOpenSource codeforge http://forge.tactix4.net