Category Archives: ESB

Open Interfaces, Open Standards and Open Source

Everyone I talk to agrees that we have to create an Open Digital Health and Care Ecosystem in which a range of digital health and care service can be delivered. This needs to support the interoperability and orchestration of ecosystem components and provide the infrastructure to make it easier for innovators to deliver safe and secure services by offloading the technical and governance complexities from applications and by supporting a diversity of business models to enable sustainable digitally enabled health and care services.

In this context, pretty much everyone I talk to agrees that the existence of stable, robust, open interfaces on both legacy and contemporary systems is critical. Also most agree that both Open Standards and both Open Source have a role to play in the creation of Open Interfaces. However, I think there is some conflation of various issues, which I think could be usefully clarified and I attempt to do this in this blog.

Neither Open Source or Open Standards are necessary or sufficient in the creation of Open Interface and Open Standards and can be a Barrier to Innovation

Open Source and Open Standards have a role to play in the creation of robust Open Interfaces and I’ll attempt to describe what I think this is, but both are neither necessary nor sufficient and in some circumstance insisting on either can be a barrier to innovation and progress. What’s important is the availability of freely available, robust open interfaces not necessarily that they are Open Standard or Open Source.

Interfaces can exist at file levels of maturity which are illustrated in the diagram below.

Open API Pyramid

What’s important is the availability of freely available, robust open interfaces not necessarily that they are Open Standard or Open Source.

At the lowest level (5) Closed Systems lack stable, documented interfaces. Such a design approach is still encountered in monolithically architected legacy systems which were designed to “stand alone” at a time when, amongst other reasons, hardware constraints made the use of modular software architectures too computationally expensive. The only way to interface with such systems is to “hack” into the systems source code and data structures (always possible with Open Source systems, in the gift of the IPR owner otherwise.) Such interfaces tend to be fragile and are easily broken by changes to the underlying system.

Systems at the next level Private Interfaces (4) are the most commonly found in health and care systems today, with more modular software architectures. Such systems will typically have both internal interfaces (between modules) and external interfaces. Private interfaces are intended for the use of the systems software developer and are typically insufficiently documented, and less robust than is required for their easy and safe use by third party developers, so you might add a Software development outsourcing to up keep. With proprietary systems access to the interfaces is controlled by the IPR owner; with Open Source anyone can use and improve the interfaces.

The concept of a partner interfaces (3) applies only to proprietary systems and such interfaces are commonly found in health and care systems in use today. Partner interfaces are designed and documented to make them easily and safely usable by third party developers, but access to them is controlled by the IPR owner who can choose with whom they wish to partner – Otherwise partner interfaces are identical to open interfaces (2)

Open interfaces (2) are designed and documented for safe and easy use by third party developers and differ from partner interfaces only insofar as the IPR owner has made the interfaces irrevocable freely available to all. This is automatic in the case of Open Source systems and can be achieved by a range of licensing or contractual arrangements in the case of proprietary systems – Public policy encourages public bodies to insist on the availability of open interfaces as a contractual requirement in procurement of systems. Open interfaces may be produced directly by the system developer or by a third party as a layer above a freely available private interface – Typically as an Open Source plug-in.

At all levels described above the technical and content characteristics of the interfaces are defined by the software developer but at this highest level Open Standard Interfaces (1) the interface implements wildly accepted open standards for both technical and content aspects of the interface. Such standards might be formal (ISO, CEN, BSI etc.) Industry/community de-facto (IHE, HL7,etc) or NHS (ISB, PSRB, etc). While a requirement for the use of open standards where such standards exist is highly desirable, insistence on the adoption of formal/NHS standards before they are fully mature, stable and widely accepted can be a serious barrier to innovation and adoption, as can onerous accreditation requirements in relation to standards compliance. Often a better approach can be the partial use of open standards in open interfaces (2) covering those characteristic where there is consensus.

The priority then is to get to level 2 – Open Interfaces. Ideally such interfaces should make use of those technical and content standards that support aspects of what they do, but the priority should be to expose rich interfaces able to allow access to all of the data and functions supported by the system.


PHRs – An important but limited role

There is a lot of interest around PHRs at the moment at senior levels within the NHS, but there seems to be a lack of clarity the role PHRs might play in the UK

If we are to make progress we have to develop a shared understanding of what we are hoping to achieve, what we mean by a PHRs and what role they might play in meeting our objectives?

For many, including me,  the key feature that separates a PHR from other forms of health records is that it is controlled by the person to whom it relates – i.e. they decide if it exists, what form it takes, where it is held, what it contains, who has access to it and if and when it might be destroyed.

It seems to me that in the UK context PHRs have a limited, but important, role to play as a driver of innovation and change, but that many of the benefits they might bring would be better archived through patient access to existing records, particular GP records, and by a step-by-step evolution from siloed institutional records to a single logical record under share curation and governance.

In this long blog:

  • I provide some background about the purposes of EHRs and the Rights and Responsibilities of both record subjects and record users, an understanding of which I think is essential to understanding the limitations of PHRs and where they fit in the bigger picture.

  • Some thoughts about what I think are seen of the benefits of PHRs. I believe it is important to start with a shared view of what we are trying to achieve rather than jumping to the conclusion that the answer is PHRs

  • Finally, I lay out what steps I think we should take to move towards a shared record and what this is (which is definitely NOT a single physical record) and how patient record access to existing systems fit into this journey.

I conclude:

PHR are not the solution to the problem of sharing Electronic Health Records, but an intermediate step on a journey to a single shared logical record for every patient under shared governace with the paitient as “first amongst equals”. We should encourage the further development of PHRs and in particular explore the use of a common model for data persistence across multiple PHRs based on OpenEHR. Recognising that this is a long and difficult journey we should also continue to open up patient access to existing EHR systems (particularly GP systems) which for many will provide a better solution than a PHR to support patients engagement in their own care and the relevant sharing of their  data. We don’t know the answers to some of the challenges we will face achieving  our objectives, but answers will emerge from an exploration of PHRs, Patient Record Access and Shared Governance Models.


Before coming back to what we do with PHRs I want to develop three points.

  • The purpose of health and care records

  • Rights and responsibilities in relation to such records

  • What we hope to get out of PHRs?

Purpose of Health Records

Health records have a wide range of purposes and these include:

  • Directly supporting the delivery of care to individuals

This category includes both clinical and administrative activities that are necessary for the maintenance of health and wellbeing of and the delivery of care to identifiable individuals including:

    • The provision of an aide-memoire for those involved in care.

    • To facilitate the engagement of patients and their family and informal carers.

    • As a means of communication within teams responsibly for an aspect of care.

    • As a means of communication between teams responsible for the different aspects of care.

    • The provision of the data need by decision support tools design to provide automated guidance to patients, formal and informal carers

    • The provision of data to support workflows, care processes and transactions related to care.

  • Supporting the Health of Populations

The category includes all those uses that are concerned with the health of populations, the planning of care and the development of health knowledge. These uses don’t offer a direct and immediate benefit to individuals, often don’t require identifiable personal information and are often referred to as secondary uses. These uses include:

    • Healthcare planning and commissioning

    • Public health and epidemiology

    • Risk stratification and risk scoring

    • Predictive modelling

    • Drug safety surveillance and pharmacovigilance

    • Clinical audit and outcome measurement

    • Population based healthcare research

    • Identification of subjects for clinical trials

  • Providing a Medico-Legal Record

Those providing care need to be able to demonstrate that they did so with due professional care, recording relevant information appropriately and acting reasonably on the basis of the information available to them. The medical legal record needs to meet the requirements laid down by statue and common law for the admissibility of evidence in both civil and criminal proceedings (principally the “Civil Evidence Act 1995” and “Police and Criminal Evidence Act 1984”. A medico-legal record needs to:

  • Be able to reliably represent the record as it would have been at any particular point in time

  • Securely represent the provenance of information recorded

  • Ensure that information once recorded cannot be repudiated

  • Provide an audit trail of additions, changes and access to the record

The record has to support the needs of all those involved in care which includes health and care professionals, administrative personnel, family and informal carers and patients themselves.

Rights and Responsibilities

In order to understand the issue surround the use and access to health records I think it is helpful to think in terms of a set of rights and responsibilities.

Rights might include: The right to;

  • Determine where and how the record is stored

  • Determine the information stored in the record

  • Decide who has access to the record and the purposes for which they use it

  • Collect information

  • Know the provenance of information stored in the record

  • Use the information in the record for defined purposes

  • Retain/destroy the record

  • Change, clarify or comment on and challenge the veracity of information in the record

  • Disclose information to others for defined purposes

Responsibilities and obligations might include: The requirement to;

  • To ensure the accuracy of information recorded

  • To maintain the currency of information in the record

  • To protect record from inappropriate use or disclosure

  • T disclose information as required by law, regulation or overriding public interest

  • To protect information from loss or damage

  • To maintain details on the provenance of information

  • To maintain audit records of access to, disclosures of and changes to information

  • To securely destroy particular copies of information (typically in compliance with retention policies)

  • Not to disclose certain information even to the patient

Many individuals and organisations may have some of these rights and responsibilities including the patient; those who have contributed to the record or delivered care on the basis of the record; those responsible for maintaining systems on which the record is stored; those who have paid for care on the basis of information for which the record is the authorative source, third parties referenced in the record and those executing certain regulatory or statutory functions.

A PHR as defined above is a record in which the patient has all of the rights and few if any of the responsibilities and in which others have few if any rights and only those responsibilities that may flow from providing and/or hosting the record on behalf of the patient.

Those who wish to maintain records can take one of two basic approaches (and many variations at points between) to ensure the record is fit for their purposes At one extreme each stakeholder maintains their own record for their own purposes (this is broadly the current situation) and at the other extreme we try and create a single logical record under shared governance that satisfies all.

Why PHRs

What then do we hope to achieve by creating PHR? Proponents of PHRs cite many potential benefits, which include the following:

  1. Greater engagement of patients and their informal carers in their health and care.

  2. Facilitation of innovation and experimentation with new approaches to health and care records.

  3. The creation of a truly integrated life-long record which covers all aspects of wellbeing, health and care.

  4. Greater transparency so that patients and their advocates are better able to assess the cost and quality of care that they receive and if needbe challenge it.

  5. Improvements to the completeness and accuracy of health and care records by allowing patients, their digital devices and their informal careers to contribute to and validate the information recorded in the record..

  6. Provide a mechanism which allows patients to see what is recorded about them and manage informed decisions about the sharing of data for both primary and secondary purposes.

  7. To enable patients to record information about the health and care beliefs, values and preferences.

  8. To allow patients to record data about their health and care for their private use which they don’t wish to be available to others.

However, with the exception of the 5th and 8th points above all of these things could be achieved using facilities that are available now in GP systems and which have been offered to patients by pioneering practices for over 10 years. Extending systems to support the 5th and 8th points while non-trivial, is entirely doable.

So what should we do?

My answer to this question is not a simple one as I think we need to pursue multiple paths.

  • First, we need to push forward with GP record access to meet the Goverment’s commitment that all patients who wish to do so should be able to access their GP record online.

  • Secondly, we need to start to lay plans to provide a single shared record under shared governance and curation with the patient as “First Amongst Equals”

  • Thirdly, we should encourage the development of PHRs as a transitional approach for those patient groups who needs would not well met by access to GP records (these are typically those groups undergoing an extended episode of care outside of general practice e.g. renal patients) and as a vehicle to experiment and drive innovation which will inform the creation of shared record.

  • Finally, we should enforce the Open APIs policy being developed by NHS England which requires all new procurement of systems to make open APIs available and require  all systems to enable patients to obtain a machine readable download along the lines of the US “Blue Button” model

Making GP record access a reality

Given that the technical facilities to allow patient access to GP records have been available to the majority of practices for many years and that they have be used successfully by pioneering practices, Government wrongly assumed that getting wider take up would be easy. What they failed to understand is that pioneering practices had chosen to ignore the risk of the unlawful disclosure of third party information to patients, something neither the Government nor their professional bodies could advise others to do. Solving this problem retrospectively is not practical and as a result a more limited approach is now being proposed as laid out in ‘Patient Online: The Road Map’.   We should get on with this and also work to ensure systems are amended so that future recording of third party data is tagged to enable it to be easiy redacted.

Building a shared record

Building a shared record will be a slow process, but one that can be approached incrementally. It’s also important to understand that I’m not proposing a single national record, but rather that for an individual there should be a single authoritve record. Every application that needs information about the patient would get it from this record and any application that needs to persist data about that patient would write it to this record. There could (and should be) multiple providers of repositories for records and the patient should be able to choose which one they use and be able move their record to another provider should they wish. It might even be appropriate for different sections of a record for a single patient to be stored in different services? It would be the responsibility of the service provider to ensure the security and integrity of the record and to put mechanisms in place to enable all those with an interest in the record to secure their rights and responsibilities in relation to the record.

The record architecture required would need to be flexible and extensible and able to handle record dissonance and maintain multiple versions of the truth where the contributors to the record can’t agree a single version.(I will shortly publish a further blog detailing my proposed model for shared governance and the role of multiple truths) It would need to be based on a set of open standards shared (at least) across the UK to ensure interoperability. For me the only currently available viable contender for this architecture is that provided by OpenEHR, which I believe can meet these complex requirements of my proposed model. In this model record storage becomes a commodity service in the cloud and various organisations could offer such storage under a range of business models, but it the UK I would suggest that the default choice of most citizens would be to use the repository funded by their local public sector care provider.

For this approach to work other things need to be in place:

  1. A discovery service for applications to find where the record for a particular patient is – This could be most simply be provided on a centralised basis by the NHS Personal Demographic Service, but could also be achieved using a distributed directory service .

  2. A service to maintain a registry of those who have contributed to the record or have a legitimate interest in it along with the consents granted by the patient for access and particular uses. Again this might be provided centrally as a service on the NHS Spine or as a distributed service. The work of has potential to address aspects of this requirement.

  3. Governance structures (probably with a statutory underpinning) to regulate the record service providers to ensure they are irrevocable obliged to: Satisfy the rights and responsibilities of all those with a legitimate interest in the record,  transfer the record  to an alternative provider if they cease to be able to  do so or on request of the patient and ensure that records are protected from loss in the event of a technical or business failure of a provider.

This architecture is one that I have described before  and is built round an enterprise service bus (ESB) that connects back-end services (which would include record repositories) to front end applications that consume these services. An appropriately designed ESB would:

  • Provide a single interface (API) to the various record repositories and supporting services avoiding the need for applications to deal with multiple APIs with the ESB handling mappings and transformations between different APIs, technical and clinical content standards facilitating incremental progress toward common standards.

  • Protecting services from badly behaved applications and denial of service attacks.

  • Off-load many functions from application and service providers to make their lives easier, requiring these functions to be implemented just once in the ESB rather than in each principal system e.g. authentication, identity management, access control, consent management IG, load balancing (to name a few.)

  • Provide an accounting platform that could support innovative business models for apps (such as pay for use models) and a mechanism for charging the responsible party for compute resource and services consumed by applications.

  • Provide a comprehensive patient portal integrating access to existing NHS national web services; NHS Choices, NHS Direct online and NHS 111 online content with record access, and transactional services.

Migration to a Shared Record

My expectation is that, over time, existing systems would migrate to using the shared record to persist the patient information rather than their own local storage. For this migration to occur existing system vendors and users will need to be confident that the shared record can deliver a level of performance and availability to match that provided by local storage and some may wish to start by maintaining of local cache of the record to improve performance and provide resilience. Also, initially that many will continue to use their own storage simply using the ESB for messaging, interoperability and to provide access to transactional services.

Where does the PHR fit

In this model I see that existing PHRs will also migrate to using the shared record just as other ExRs will do.

Many existing PHR systems are already using the latest web technologies and the agile and innovative nature of most PHR vendors and their flexible business models mean that they should be amongst the first to migrate to the shared record.

Similarly the agile and innovative nature of the PHR sector and the much similar Information Governance issue that exist with PHRs (as the patient is in control) will combine with the emerging shared record to enable of slew of PHR developments in which the developers can concentrate on the user experience and user interface design and experimentation with novel business models free from much of the burden of managing record persistence.

For those wanting to experiment there are already facilities provided by the Leeds Health Innovation Lab Platform  which offers what a test platform that could be used to start to build exactly the sort of shared record I’m suggesting.

EhrScape also based on OpenEHR has also recently annocunced an Open Health Data Platform that could also provide a basis for experimentaion

There are also a number of Open Source PHRs that could provide a rapid route for those wanting to experiment or provide live services quickly. Including Indivo and Renal Patient View

We should encourage and facilitate such activities which will help and refine and develop the shared record and the supporting open digital health ecosystem at a pace not possible with the more complex issued raised in the migration of existing large scale EHR systems.

So, in conclusion:

PHR are not the solution to the problem of sharing Electronic Health Records, but an intermediate step on a journey to a single shared logical record for every patient under shared governace with the paitient as “first amongst equals”. We should encourage the further development of PHRs and in particular explore the use of a common model for data persistence across multiple PHRs based on OpenEHR. Recognising that this is a long and difficult journey we should also continue to open up patient access to existing EHR systems (particularly GP systems) which for many will provide a better solution than a PHR to supporting patients engagement in their own care and the sharing of data. We don’t know the answers to some of the challenges we will face achieving  our objectives, but answers will emerge from an exploration of PHRs, Patient Record Access and Shared Governance Models.

NHS VistA and NHS Open-Source

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 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 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 focuses on the specific open clinical technology while provides a valuable resource covering a the international clinical knowledge management domain.)
EWD Files
eHealthOpenSource codeforge

SPINE 2 – A Game Changer for NHS IT

I attended a presentation of SPINE2 from CfH at Intellect today. I think it’s the first thing from CfH to really excite me (at least in a positive way) since they were established. While I’m reminded of  “The Second Coming of the Great Prophet Zarquon”, who fans of Douglas Adams will remember only managed to get this in just before the end of the universe.

I have been hearing reliable rumours for some time about skunkworks activity within in CfH to try and re-implement SPINE (at least as used, rather than as specified) using open source components and an agile development methodology, but today was the first official confirmation of this. It would seem that the initial skunkworks proved the concept and has been thrown away, a great example of the value of a “fail-fast” philosophy, and that this has been followed by a second phase of the project which appears to be close to delivering a production version of SPINE2. I’m reliable informed that the initial skunkworks involved just a handful of people within CfH with a cost of under £250k. The next phase of the project has been support by some external development resource procured under G-Cloud from BJSS ( and while I don’t know how much this cost I think it pretty clear that it will have been only a tiny fraction of what it must have cost to get SPINE1 to the same stage.

If we are to believe what the SPINE2 Team told us– And I’m inclined to do so, because they spoke with obvious conviction and it tallies with other intelligence – this project is going to be a game changer for NHS IT. It will create lots of new opportunities for those in supplier community who can embrace new ways of working, has a much better chance of delivering what the NHS needs while providing a nasty surprise for those on both the customer and supplier side of the Fence Repair Service who have built empires and companies on bloated ways of working.

There are two key features of this project which I find very encouraging and I think are the basis of its’ likely success. The first is extensive use of proven open source components and the second the adoption of agile technologies. These together drive down development cost and risk and provide a much more responsive and flexible approach than traditional waterfall methods (for a light-hearted view of this see ) Add to this the use the project has made of G-Cloud to simplify the procurement of external resource and you have a much more responsive approach all round.

The team made some interesting comments. The first that they would be able to provide a copy of SPINE2 on a DVD that would allow suppliers to have their own test environment that they could run on a laptop, this will be a great help to developers. The second was that they had the capability to open up code and new interfaces which could potential provide a much easier route for third parties to interface to SPINE. This step would not be welcomed by some suppliers who businesses are built on their knowledge of and access to existing interfaces and the CfH team made it clear that no decision had be made to do this. However, while there have been previous promises from other parts of CfH that they would not do anything to undermine the business models of those who had invested heavily in interfacing to SPINE1, I don’t believe that it is the business of NHS to protect outdated ways of working and hope that a decision to open up SPINE2 to the maximum extent possible is taken. I for one would like to see the source code of SPINE 2 freely available on GitHub and when I asked if this was a possibility I got a positive answer.

The slides of the presentations will be available to Intellect members shortly and I will include a link to these here as soon as I have it. I will also explore if these can be made publicly available.

This planet maids could provide a new model for deliver NHS IT and deserves further development. My initial reaction is that I would like to see more of the work outsourced to the private and third sector, as I don’t think a return to in-house development on a wide scale is a great idea, but I think this project provides a great basis for a move to a more responsive, better value approaches built on an open and agile philosophy.

Finally, I’m encouraged because I think this approach fits with other ideas I’ve been promoting around GPSoC and the potential role for an ESB (which is fundamentally what is at the core of SPINE) See here for my blog “An ESB for GPSoC Phase 2 ?”