UK Drug information, knowledge, coding and classification

I wrote this piece below to brief some US colleagues, but thought it might be worth sharing with a broader audience for what’ it’s worth.

The coding of drugs and medical devices in the UK is based on the NHS’s Dictionary of Medicines and Devices (dm+d) which is very closely related relevant sections of SNOMED (all dm+d identifiers are SNOMED codes).

It provides a hierarchical  representation of medicines starting from Virtual Therapeutic Moieties down to individual manufactures packs as illustrated in this diagram taken from the the dm+d website

dm+d also contains a “Trade Family” Class which is equivalent to the VTM class to allow the prescription of those small number of branded medicine where no VTM exists (eg Lipitor) which could otherwise only be prescribed at the  AMP or AMPP level which is at odds with usual inpatient prescribing practice which occurs at VTM level.  Trade Family TF and the associated Trade Family Group (TFG) and more fully described in the  SNOMED CT® UK Drug Extension Editorial Policy .

Despite it’s name medical devices coverage in dm+d is very limited with coverage by and large only extending to medical devices listed in the NHS Drug Tariff which includes all items including medicines, dressings, appliances, reagents and devices that can be prescribed on the NHS by UK general practitioners.

VTM, VMP,TF and TFG concepts exists as part of the core SNOMED namespace while VMPP and AMPP concepts form part of the UK extensions to SNOMED

The dm+d contains includes medicines by both generic name (usually aligned to International Nonproprietary Names ) and UK trade names and is designed to promote generic prescribing (the usual UK practice) for all medicines except in those few cases where generic prescribing is clinically contraindicated (even when only branded products are available to fill such prescriptions).

dm+d contains information about drug forms, strength, and licenced routes of administrations, but contains little other clinical information about the drug. However, it does provide mechanisms to link dm+d to a range of drug knowledge sources (e.g. the British National Formulary BNF) and many commercial drug knowledge suppliers maintain mappings from dm+d to their proprietary identifiers of have adopted dm+d as their native coding. These links allow prescribing based on dm+d to be link to a range of knowledge sources and prescribing decision support tools.

dm+d also contains a large number of data and metadata  items related to UK pricing, regulatory, best practice and supply chain operation (including links to the information in the Drug Tariff) which will be required by ePrescribing systems that wish to comply with UK statutory, regulatory and best practice recommendations and operate satisfactorily with medicines supply chain arrangements that apply in the NHS. There is a considerable volume of useful guidance on the implementation of dm+d freely available via the web with the dm+d web site providing a good start point from which to find this.

There are a numbers of sources of high quality UK specific drug information and knowledge to support both professional responsible for prescribing and administering medicines and patients which can be incorporated in to prescribing and medicines management systems. Information in these sources includes both eye-readable information (manufacturer’s data sheet (SPC’s), drug monographs, warnings, prescribing guidelines, patient information leaflets etc) available to the relevant actor at appropriate points in the treatment process and machine readable data and metadata intended to support automated prescribing, dispensing, administration and associated decision support. Such data will be provide in a structured and coded format to facilitate automated processing and may be supplied with computable  decision support rules and/or software components and APIs to aid it’s implementation.

Computable data is typically intended to support functions that might include.

  • Therapeutic recommendations
  • Drug-drug interactions
  • Drug-lab interactions
  • Drug contraindications
  • Dose recommendations/calculations
  • Dose range checking
  • Defined daily doses
  • Cross-sensitivity allergy checking
  • Drug administration
  • Side-effect identification
  • Drug substitutions
  • Drug-Gene interactions

Drug knowledge suppliers assemble their data from a range of primary and secondary sources. Each provides a different range of data which is likely to be provided in a proprietary format using a variety of open and proprietary coding systems. Common coding systems found in UK data sources include (Read, CTV3,  (widely used in UK general practice), dm+d, ICD, SNOMED (Op sit), ATC, BNF, PIP) mappings exist (of variable completeness and quality) between many of these systems where their domains overlap – Coding systems common in the US like NDC and LOINC are rarely found in UK drug knowledge sources (although some direct and indirect mappings may exist).

There are some significant differences in regulation and  prescribing practice,  reflected in the way medicines are supplied, between Europe and the USA, which affect  (while there are also differences between individual European countries there is increasing harmonisation across the EU and EEA) drug information requirements and ePrescribing and medicines management and administration systems.

  • Drug names both generic and trade names can be different for the same drug
  • The range of forms/strengths available can be different
  • Licensed indications can be different and some drugs available in the US  may not be available at all in the EU and vice versa
  • Legal classification are different and often not directly comparable
  • Most medicines in the EU are supplied and dispensed in patients packs (invariably blister packs for solid medications) – For drugs with a short duration of use these pack will be designed to provide one course of the medicine, for drugs with a longer or indeterminate period of use patients pack will generally be for 28 days supply, although other sizes of patient pack exist for some drugs.  Bulk packs of medicines designed to be dispensed into vials, compliance and unit dose systems and medicines pre-packed for unit-dose dispensing  are NOT  generally available.  This reflects the very low levels of unit-dose dispensing in UK hospitals compared to the US which is probably the single most significant difference in medicines management practice between US and UK hospitals.

Further Information

References to further information about issues covered are generally included as hyperlinks in the text above. Additional sources of note:

British National Formulary BNF – The UK “Gold Standard” for medicines information and guidance on prescribing.

Royal College of Physicians – Standards for medication and medical device records – technical annex  Contains and points to some of the latest work

NHS – dm+d Implementation Guide (Secondary Care) 2009, but still full of relevant, useful and detailed information


A Pilot Site for NHS VistA – Please?

Moving the open source agenda require that NHS Trust submit Expressions of Interests (EoI) for open source projects under NHS England’s £260 million Technology Fund by the deadline on 31th July.

Over recent weeks I’ve been persuaded that there would be real value for the patients, the NHS and the UK health informatics industry in the creation of a UK version of an open-source EHR, and VistA would be a good place to start.

This represents something of a volte-face for me and I’ve spent the weekend breakfasting on my diminishing collection of headgear.  The reason for this change are explained, at length, elsewhere on this blog and I summarise them briefly below, but first I want to cut to the main reason for this piece – Identifying some NHS Trust or Trusts willing to make an Expression of Interest (EoI)  by the deadline on 31th July.

NHS England’s publicity around the fund have made it very clear that they would welcome a bids based on open-source in general and VistA in particular, but they rightly understand that the strength of a VistA development lies in its’ ability to drive clinical engagement from the grassroots – as it has demonstrated in a number of US and overseas implementations and it’s willingness to drive this forward will depend on Trusts coming forward NOW with appropriate EoI’s.

My previous negative position on VistA was based on a profound disagreement with the position of the Campaign for  NHS Vista which envisages VistA as a single EHR system for the NHS.  Simply, in my view,  a “Better way to do the wrong thing” and a lack of understanding about the direction of travel of the global VistA community, who I now discover are working towards a vision of an open digital care ecosystem which aligns with mine and that of many others in both the open-source and established vendor community and who have a strong appetite to work with others to create this ecosystem.

I suspect than many in NHS Trusts still have the misconceptions that I  recently harboured and I would not wish these to result in a failure of Trust to seize the opportunity offered by the Tech Fund.

Trusts who engage with this vision for NHS VistA do not need to buy-in to the vision of VistA as a single system and will not need to abandon systems that are already working successfully for them and in their broader health and care communities.  Rather, in the short-term, they can look to the rapid provision of some key functionality based on well proven clinically developed software and the immediate availability  open interfaces (SMART , MWDS and  OpenMWDS) that will enable developers of all sorts to connect the latest innovative apps and encourage the development of many more using the latest technology. In the longer term we expect to see VistA evolving into open digital care ecosystem alongside other open-standards and open-sourced based initiatives already making progress in the NHS. NHS VistA, therefore, is not a single rigid system imposed on Trusts but a powerful and flexible system; a digital core that enables each Trust to optimally configure its healthcare IT platform to meet its individual needs.

Trusts who adopt VistA can also expect to have access to the support of a range of commercial service providers who will be able to provide a “service wrap” and warranties around the implementation and ongoing support of VistA.

The key issue today is for Trusts to make an EoI. This urgent first step is not onerous and you don’t need fully formed plans, but the recognition that there’s a better way to achieve the goals we all share. The process that follows an EoI  is such that there will be an opportunity to develop the detail, obtain support from both the open source community as well as NHS England and link with others who express collinear interests. An EoI, is just that and a Trust would be free to decide not to proceed if it subsequently discovers it is not appropriate for their local use or needs.

What’s critical is making the EoI so your Trust is in the game and eligible for support from the Technology Fund. I and others in the VistA community stand ready to provide pro bono help to Trusts in submitting an EoI.

At this stage NHS VistA is likely to most attractive to Trusts who are at the early stage of their digital journey and want something that will help them accelerate their progress. Trust who already have a committed path to the “Clinical 5″ ( PAS, order communications, coded letters, scheduling and e-prescribing) beyond PAS are not likely to benefit from what VistA can immediately offer.  The expectation is that initial versions of NHS VistA would sit on top of existing a Trusts existing PAS (avoiding the disruption, risk to income and many of the localisation issues that PAS replacement creates) interface with the existing LIMS (Lab systems),  RIS/PACS (imaging) and Pharmacy systems that nearly all trust already have (although VistA can offer these application if required).

My thoughts are that the focus should be on delivering enough VistA functionality to support ePrescribing and nursing observations the two application most likely to create “Safer Hospitals and Safer Wards”, for individual Trusts, the public,  patients and frontline staff to tell us where the priorities lie.  Again, the beautiful thing about an open source approach is that the development community can respond quickly with examples and reference implementations.  We know we can win before the heavy investments are made.

Finally,  just to summarise why I think this is a golden opportunity.

  • VistA and open-source in general are a market disruptor that will help drive value and openness. We can simultaneously improving health delivery and care and creating commercial opportunities for the UK digital health sector.
  • Open-source naturally encourages clinical engagement and agile usercentered design. VistA already has influential champions in the UK clinical community (both at a very senior level and amongst future clinical leaders) which will help achieve the clinical engagement that has so far eluded most outside of primary care.
  • VistA is the most functionally rich and best proven  of any of the currently available open-source EHRs.
  • The VistA community shares a common vision with many in industry and the NHS to create an open digital health ecosystem. Working together will enable us more easily to tap into the massive investment the US recently made and to the intellectual resources of the global VistA community. The successful creation of such an ecosystem would be good news for the NHS,. UK plc and the vendor community. I have many positive discussions in the last few days that make me think there is a real appetite for this both sides of the pond and substantial work towards this is already underway.

If you are working in a Trust that you think might benefit from NHS VistA do consider making an EoI to secure your place in the game get in touch if you want to discuss your options or need some free consultancy to help complete the EoI email me and either I or a another volunteer from the community will be in touch to try and help.


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