Tag Archives: OpenEHR

Code4Health, Digital Health Ecosystem, OpenEHR, Software Development

The Future of Applications

Leave a comment


I was recently passed a link to an interesting paper from Accenture “The Future of Applications – Three Strategies for the High-velocity, Software-driven Business”. This paper is directed at a general business audience, but has much of relevance for the digital health world and in particular resonates with the points I was trying to make in my recent blog  “Would you like to build Health and Care Software 100 times Faster?”

Picking up a few key points from Accenture:

“The fact is, many companies are trying to compete in the world of social, mobile, analytics and cloud with applications that were designed for another era. Monolithic applications are often built from the ground up— slow to implement and slow to change. “

Very true of the systems in health and care, not just the big megasuites, but most of the applications in use today.

“What’s needed is a new way to build software—faster, flexible and more liquid—with reusable components that allow for rapid assembly of applications in support of dynamic business needs. This approach requires modular architectures……”

In the context of health and care this sounds very much like openEHR.

The other two other key points the paper makes: The need to build intelligent applications and to build and nurture  [open] ecosystems also seem to provide further support for the work I’ve been in with colleagues in NHS Englands Code4Health Programme.

There is much more in the Accenture paper which is well worth reading and thinking about how we can apply its recommendations in the context of health and care. You will find the paper on the Accenture web site here.

Design, Digital Health Ecosystem, EHR, Featured, Interoperability, OpenEHR, Software Development, Standards

Would you like to build health and care software 100 times faster?

2 Comments


I’ve written before about openEHR and how I think its time has come. I been talking to lots of people about openEHR and it’s clear it takes a while to really understand its power – It took me 15 years. In this blog I try and summarise what I think makes it different and special. If you are new to openEHR I suggest you read this first and then go to my previous blog and openEHR.org  for more detail.

OpenEHR is not a piece of software it’s an open specification from which software can be built. It has it roots as a way of creating electronic health records, but can be used to build records across the whole of the health and social care domain.

Its key benefits are:

  • It enables those designing systems to work at the information level rather than at the level of a particular technology separating
    • “content” – the domain of the clinician or social care professional
    • from “technical infrastructure” – the domain of the software engineer
  • enabling both to concentrate on their own domain without needing to worry about the complexity of the other.
  • It’s independent of any particular vendor or technology – There are multiple implementations from a number of vendors, built on various technologies, including open source options.
  • There is a vibrant global openEHR clinical community creating archetypes (the building blocks of openEHR), which are generally “open source” and can thus be freely shared, used and adapted. See Wooland’s  Cat for more on this 
  • There is an active vendor community which supports the clinical content development and a number of examples of implementation at scale, mainly outside the UK where it was invented!
  • The specifications are amazingly rich. There is very little than its creators have not covered including:
    • Interoperability, openEHR makes it easier to achieve interoperability than not.
    • Multilingual support and language independence
    • Federated multi-vendor implementations, with cross vendor querying
    • Complex access control capabilities
    • Intermittently connected devices
    • Versioning and backward comparability
    • Cybersecurity
    • Privacy protection and consent management
    • Terminology bindings

However, the most remarkable and powerful feature of openEHR is its ability to support new requirements with minimal changes to systems. To support a new requirement it is simply necessary to create new archetypes. These will be immediately deployable, storable and queryable; will not require any database schema changes, won’t affect parts of the system not connected with the new requirement and won’t break anything – This means that new requirements can often be deployed in hours rather than months. Let me explain further:

New requirements generally mean new information has to be collected and stored. Anybody, who has worked at the database level will know how problematic this can be. You have to modify the database schema, modify existing tables, maybe create new ones and then migrate data from the old schema to the new. In a database of any complexity it’s easy to break things and can require the rework of lots of software unconnected with the new requirement. While modern databases have tools that can help developers avoid schema changes like the plague and when they do consider them, the rework and testing required means that changes will be expensive and slow if they happen at all often leaving people with no recourse than another  Feral System

Supporting new models of care means being able to meet new requirements 10 – 100 faster, by utilising openEHR’s ability to incorporate changes simply by creating new archetypes, the large preexisting set of open source archetypes, its openAPIs we can now achieve this.

If you not looked an openEHR already then I suggest you do and if you loked at it a while ago I suggest you look again.

This video produced by Dr Wai Keong Wong (@wai2k )provides a useful introduction to openEHR

Analytics, Code4Health, Digital Health Ecosystem, EHR, Innovation, Interoperability, OpenEHR, Standards

openEHR a Game Changer Comes of Age

1 Comment


I’ve been watching openEHR over more than fifteen years, and although I have always been impressed by its potential to enable us to do things differently, I must admit it has been a slow burn, and take up has been limited, particularly in the UK where it was invented. However, due to some recent developments, I think this is about to change, and that openEHR is going to take off in a big way. This is going to revolutionise how we think about and do digital health, and it should increase the speed at which we can do it by at least two orders of magnitude. Why do I say this, and what evidence is there to support my assertion?

openEHR has come of age with a large number of successful small implementations, and a few much larger ones (1) which have proven the approach works at scale. We have also seen the use of openEHR by governments and major health providers across the globe, including the NHS (2), as the mechanism for the creation and curation of clinical content standards in their territories. In addition, changes to the openEHR Foundation have made it unarguably an open source organisation with a global user community; a growing vendor community has developed offering both open source and proprietary tools and components supporting the standard; and there is serious interest from major system integrators. These changes make openEHR look like a much better alternative to the hegemony of the big US megasuite providers, who still want to shape health and care systems in their image and who own the platforms on which these providers will increasingly depend.

UPDATE (12 April 16)

Possibly the best explanation of openEHR I’ve seen “openEHR technical basics for HL7 and FHIR users” Well worth reading.

UPDATE (15 March 16)

Some great videos here which provide an easy way to understand various aspects of openEHR.

In particular:

Clinician-led e-health records – An introduction to openEHR for clinicians

National governance of openEHR archetypes in Norway – A national approach to building information models with openEHR. Many lessons here for HSCIC who have just started doing something similar here.

UPDATE (13 July 15)

In their PQQ which kicks of the procurement for the Datawell to support Devo Manch,  Manchester have mandated openEHR along with other established standards including IHE-XDS. This could potentially lead to the largest implementation of openEHR in the UK with Manchester building on pioneering work in Moscow and Leeds

UPDATE  (24 Apr 15) Further information and news about the growing interest in openEHR will be found here

Firstly, everything I read and all of the people I talk to across the globe about digital health agree on a couple of things.

  • Firstly, we need to move towards a platform architecture into which we can plug the thousands of apps and hundreds of traditional systems that we currently use in health and care; an architecture which will enable all of these to interoperate and work together.

  • Secondly, we need to separate content (the data, information and knowledge that applications consume and update) from the applications that process it; and that content needs to be expressed in a modular, computable and reusable format.

Beyond this, agreement breaks down – people do argue about business models (who should own and control the platform), and also the details of the particular standards and technology to be used – but on the core principles, everyone with any credibility agrees.

When it comes to business models, some would like to own the platform, because doing so would create a massive commercial opportunity. And while some still pursue this goal, most significantly Apple, others have decided, as I have, that ownership of the platform is neither achievable (competitive and customer pressures mean even the mighty Apple can’t win this battle) nor is it desirable from the perspective of citizens, health and care providers and payers – none of whom wish to be locked in or to pay the ‘fruit tax’ or its equivalent.

Others, including me, and more significantly some big players, have come to the view that while it might be great to own the platform, that isn’t going to happen and so we need to move to an open platform which nobody owns (in the sense that nobody owns the Internet). As for commercial opportunities, they will still exist higher up the value chain, and the existence of the platform will create such opportunities by the spadeful. Surely it’s more fruitful to concentrate on these, rather than waste time and resource on a battle no one can win.

On the details of implementation, disagreement is less significant. The two major contenders, openEHR and the Healthcare Consortium, both have similar approaches, and they are already converging through the Clinical Information Modeling Initiative (CIMI) to reduce their differences to the point where they really don’t matter and can be dealt with at a purely technical level, with their components being easily interchangeable.

So, if we want to create an open platform, what do we need? We need openEHR or something like it – and frankly there is nothing else as mature or as well supported as openEHR.

OpenEHR is not software, nor is it a particular technology. It’s an open specification or standard for the representation of a key bit of content – the health and care record. The specification is open source (insofar as you can apply this term to something that is not software), and it’s curated by the openEHR Foundation, which is a not-for-profit company democratically controlled by those who choose to be part of the global openEHR community (and anybody can). The community is truly global and growing, and consists of both users and developers; and is supported by a number of vendors who can offer tools, components and services supporting the standard.

openEHR provides a simple, robust and stable over-arching reference model (3) which defines a formalism for the representation of the modular components of a health and care record. openEHR calls these ‘archetypes’ and they define the elements of a record, their properties, and how they are represented (including bindings to terminologies and classifications). Archetypes are intended to represent a superset of all those properties that might be associated with the concept they represent (at a high level these will be either an observation, an evaluation, an instruction or an action). Archetypes can then be constrained and/or combined in a ‘template’ to provide practical interoperable components for use in a particular context or system.

The tools available for the creation of archetypes and templates are open source (as are the vast majority of the archetypes and templates created with them), and this makes openEHR easily accessible to clinicians and other domain experts while also providing system developers with robust components to handle many of the technical complexities. openEHR enables clinicians to concentrate of the clinical stuff, and developers to concentrate on the technical stuff, without needed to understand more about the other domain than they want to.

By building systems using openEHR, system development work shifts from the technical level to the domain level. A repository that has been built to store an openEHR health and care record does not need to take account of the particular content of a given archetype. Whatever that archetype might represent, the repository will be able to store it, and you will be able to query that repository about its content. This feature of openEHR is the key enabler of much faster application development, because the addition of new features will not require changes to database schemas (with all the associated testing and data migration that entails). Instead, all that is needed is the addition of some archetypes and/or templates – and these may already be available as the result of work by others in the community, or else they can be created rapidly by a relevant domain expert – plus the creation of some new user interface components, and these can often be generated automatically from the underlying templates. In this way changes can be made by end users, or by people close to them. This will reduce the time to add new features from months to hours, and the time to build new systems from years to weeks.

openEHR is also technology independent. Applications don’t need to concern themselves with the technology of a particular implementation of an openEHR repository – that’s purely a matter for the implementer, who can chose whatever technology works best for them at a particular time and in a particular context. The applications that use it will not be affected, so long as they remain compliant with the standard. We can see this happening in the dozen or so existing implementations of openEHR repositories: they use different operating systems, different databases (SQL and NOSQL) and various development tools to create both open source and proprietary implementations of the standard. Compliant implementations of the standard from different vendors are interchangeable, and a single query can be executed across multiple implementations. openEHR is vendor independent, and it eliminates vendor lock-in.

Suppliers of openEHR repositories will have to compete on performance, security, robustness, value and service – they cannot rely on customer lock-in, as the vendors of many traditional EHR systems have in the past. From the perspective of health and care providers, openEHR puts them back in charge of their own destiny. This contrasts with most of the current successful approaches to the delivery of enterprise-wide EHR, where customer institutions have adopted one of the four big US megasuites, and then have had to adapt internal processes and organisation to fit with the chosen system – in effect, you become an EPIC, Cerner, Allscripts or Meditech institution, rather than a customer who calls the shots.

The ‘megasuite model’ has worked spectacularly well (if expensively) in a number of big US hospitals, particularly for EPIC, but that model starts to break down when you seek to extend the scope of a system from an institution to an integrated health and care community. It also fits badly with UK and other European models of health and care, which are not so close to the US model as the megasuite vendors might hope them to be.

Of course European health and care providers don’t want to remodel their processes along American lines – why would relatively successful European providers want to adopt systems designed primarily for the inequitable and unsustainable US system? According to the well respected US Commonwealth Foundation the United States ranks last among eleven leading developed countries on measures of access, equity, quality, efficiency, and healthy lives (and, by the way, the UK’s NHS takes the number one spot).

Much of my conviction about openEHR comes from work I’ve been involved in with HANDI, in building HANDI-HOPD – the HANDI Open Platform Demonstrator, which has now been adopted by NHS England as the NHS England Code4Health Platform. This platform provides a simulation environment for any system or service that wants to expose an API (interface) within an open ecosystem, and it includes an openEHR repository loaded with test data from the Leeds Lab Project.

We have exposed SMART and FHIR APIs, as well as the native openEHR service API, on top of the repository; we have used this to build a number of apps, and also demonstrated how you can simply plug in apps that were developed elsewhere using the SMART API. We have also used this platform to prototype a UK localisation of an open source ePrescribing product (www.openep.org), and the speed at which we have been able to carry out the localisation and meet some special mental health requirements has been impressive – indeed so impressive that we will shortly be announcing the first NHS Trusts who will be taking the system live.

Work is currently being completed to re-brand the HANDI platform as the NHS Code4Health Platform, and this will shortly be available for those who want to learn more and experiment with this and other open technologies.

openEHR has come of age – If you don’t believe, me give it a try.

Notes:

This is a slightly updated version of the original with a few minor changes to make it more readable to the general reader and correct some typos my thanks for this to my friend and colleague Conrad Taylor.

1) Large scale implementations of openEHR include:

Moscow – Integrated health and social care 12 million population 

Slovenia – Country wide 2 million population

Brazil – Unimed Medical cooperative

2) Health systems using openEHR to create curate and publish clinical content.

NHS HSCIC

NHS Scotland

Australia

Norway

Slovenia

Brazil

openEHR Foundation 

Applications built on openEHR platform

OPENeP EPMA product www.openep.org

Marand Think!Med Clinical, Ljubljana Children’s Hospital http://www.marand-thinkmed.com

Ocean Multiprac Infection control, Queensland Health, Australia http://www.multiprac.com/?portfolio_4=infection-control-2

Ocean LinkedEHR, Western Sydney, Australia  http://openehr.org/news_events/industry_news.php?id=121

DIPS Arena, Norway http://openehr.org/news_events/industry_news.php?id=97

mConsole, Mental Health patient portal, Code24, Netherlands

Clinical Decision Support, Cambio, Sweden http://www.cambio.lk/News-and-facts/Produktnytt/COSMIC-Clinical-Decision-Support1/

See also http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities

3 Some key documents on OpenEHR

OpenEHR Architecture Overview

OpenEHR Reference Model

Code4Health, Digital Health Ecosystem, EHR, Featured, Interoperability, Open Source, OpenEHR, Standards

Moscow eHealth a Model for the UK

1 Comment


The approach that Moscow City Council has adopted to create an open platform to support health and social care services in Moscow which uses some of the same technology as the Code4Health platform would seem to have relevance to the UK and in particular is a good fit for the needs of emerging new approaches to the integration of health and social care like that recently announced for Manchester.

Many of you will know about HANDI-HOPD the HANDI Open Platform Demonstrator  that we have been working on for the last few months, this has now morphed into the NHS Code4Health Platform launched by NHS England during eHealth Week in London this week (5th March 2015).  However, what you probably won’t know is that one of the key pieces of technology available on the platform is the same as that which is currently powering the whole of the eHealth system in Slovenia and even more impressively Moscow.

Moscow

The Platform deployed in these two places brings together OpenEHR www.openehr.org and IHE XDS  in a very impressive way. And I believe provides a model for what we might do in the UK and even more interestingly aligns with the thinking in a number of UK city regions who are already looking at IHE XDS and/or OpenEHR and who in a number of cases have already implemented one or the other. However, the UK initiatives appear to know little of what’s been done in Slovenia and Moscow and in particular how XDS has been successfully integrated with OpenEHR, which I believe takes the capabilities of the platform to a new level – This blog aims to put this right.

One of our key partners in the Code4Health Programme who have provided the core of platform and open source components for the OPENeP Project www.openep.org are Marand,  and they are also the company who provided the platform for both Slovenia and Moscow and it is from their charismatic CEO Tomaž Gornik that I draw much of my inspiration and information.

Before turning to some of the technical details I’d like to describe a little of what I understand of the somewhat different approaches in Slovenia and Moscow and the motivations behind them, as while both use what is fundamentally the same technical platform they came to the solution from different directions in ways which graphically illustrate the flexibility of the underlying technology.

Moscow City Council is responsible for pretty much all of the health and social services serving Moscow’s 11 million citizens covering broadly what we call primary, community and social care and outpatient clinics. Moscow is a complex environment and has large number of siloed legacy systems, which made interoperability difficult and created significant vendor lock-in of data and systems. Moscow wanted to separate data from applications and store its data in a vendor and technology neutral format and chose OpenEHR to do this. They piloted this approach using the Marand Think!EHR OpenEHR implementation (which is one of the components on the Code4Health Platform) and IHE XDS components from  www.forcare.com. The same basic technology as Marand had already successfully implemented in Slovenia where the IHE componets were supplied by www.tiani-spirit.com . The pilot was successfully and the platform is now rolling out across the City.

While both Slovenia and Moscow have ended up with broadly similar solutions they reached this point from opposite directions. Slovenia started simply wanting to implement IHE XDS to allow sharing at a document level, but came to realise that this did not support their need for fine-grained structured data to support big data analytics. They solved this problem with the integration of  OpenEHR. Moscow on the other hand started with a view they just needed OpenEHR, but were persuaded of the quick wins IHE XDS could bring with document level sharing and in particular its ability to mobilise documents already produced by legacy systems that would take some time to be replaced or upgraded to take full advantage of the power of OpenEHR.

In both Moscow and Slovenia the same proprietary components have been used to implement both XDS and OpenEHR.  However, both have the comfort that because the data is stored in an open format, these components can easily be replaced if alternatives emerge which appear to offer better performance or value. Indeed this portability of data is something that HANDI have already proven in the creation of the Code4Health platform which required the data to be moved between two competing OpenEHR implementations.

Requirements and technology will evolve, but for me for now and the foreseeable future the approach taken in Moscow seems like the best bet for the integration of systems and information in the complex environment of health and social care across a city region. It brings the long-term benefits of OpenEHR, which has the capacity to put data into an open, fine grained, structured format that is technology and vendor neutral, with the tools to easily engage frontline clinicians and other Health and Care Professionals in its curation while delivering the quick wins with XDS that can ensure the right document is available in the right place at the right time to support safe, efficient care.

 

Apps, EHR, Featured, NHS Policy, Open Source

VistA for the NHS

6 Comments

Ewan Davis – Director of Woodcote Consulting shares his thoughts on VistA

VistA is the open source electronic health record (EHR) system developed and used in the American Veteran’s Health Administration (VA). It is widely acknowledged that over recent years the VA has transformed itself from one of the worst healthcare provider to probably the best in the USA with its use of VistA rightly credited as on of the key enablers of this transformation.

This has success has spurred the development of WorldVistA and The Campaign for NHS VistA I’ve been aware of VistA for may years and have followed its’ progress with interest, but had not been convinced that it had much to offer in a NHS context. However, over recent months, mainly through my work with HANDI I’ve been lucky enough to meet some of those promoting VistA in the  UK, from the VA and from WorldVista and am now persuaded that bringing VistA to the UK could help to enable transformation in the NHS.

My vision for VistA in the NHS varies somewhat from that of The Campaign for NHS Vista, who as I understand it see the ultimate goal being VistA as the single IT system for the NHS, but I hope a vision which is compatible with the direction of travel of the  VistA community.

My earlier lack of enthusiasm  for VistA flowed from a view that it was simply “a better way of doing the wrong thing”. The wrong thing because the idea of a single system across the whole of the NHS is neither achievable or desirable and a better way, because I believe in this part of the domain open source is a better way.

My view that “single system across the whole of the NHS is neither achievable or desirable” has not changed, but I am now convinced that VistA can be used widely in the NHS to facilitate transformation through front-line engagement and that VistA could be a key component in a open ecosystem for health and care.

In this blog I want to make a few observations about the VA and VistA, explain why I think  VistA is great and how I think we should deploy it in the NHS.

Before the 1990’s the VA which delivers  health care to 8.6 million American ex-servicemen and their families was heavily criticized for providing poor quality care. The VA responded to this with a transformation programme in the late 1990’s which saw massive increase in quality with costs held constant despite a greater than 30% cost increase in the US healthcare system as a whole over the same period.  Today the VA provides some of the best care available and provides one of the few models for sustainable health care in the USA (much to the embarrassment of the American right) See Philip Longman’s inspiring book: “Best Care Anywhere: Why VA Health Care Is Better Than Yours”

There where a number of factors supporting for this transformation:

  • Strong and inspirational clinical leadership focused on improving quality, patient safety, and efficiency
  • Strong links with academic medicine
  • A major shift to primary care
  • A lack of perverse financial incentives for both the VA and it clinicians
  • VistA which provide an integrated EHR to support the processes of care and mobilised information to support the planning and delivery of care.

The important point to note is that while VistA was an important enabler of the transformation it was just that, an enabler.

As the only significantly publicly run health provider in the USA the VA is probably the most NHS like entity in the US healthcare system but it is none the less very different, much smaller (less than 1/6 the size of the English NHS) and is a single, if complex entity. This compares to the NHS which consists of 900+ separate legal entities (excluding GPs, dentists, community pharmacist and opticians) with increasing autonomy as many become Foundation Trusts. It also important to acknowledge that despite the criticisms levied against it the NHS is actually a high performing health system in the global context, nothing like the basket case the VA was prior to its transformation, and the NHS has well developed primary care supported by  world leading IT.

In my view VistA’s strength is not that it is a single system, but that it is a systems built from the ground up with development that has been clinically led from the front-line and which because of its open source model has managed to get strong engagement from front-line staff and been able to benefit from improvement and extension from a community of users and developers (particularly users who are also developers) which is now global.

VistA is a venerable product with is basic architecture created in the late 1970’s and its seminal development occurring during a period when the perceived wisdom in healthcare IT was to try and build single enterprise wide systems. Compared to most other attempts to do this VistA was spectacularly successful, but at this level VistA operates in a 20th century paradigm providing, as I said earlier, “a better way to do the wrong thing”.

However, what I now understand, is that because of its open source model and the passionate commitment of its community VistA is capable of, and indeed already is, metamorphosing into something that can provide a core component of the healthcare IT ecosystems that we have to create to take healthcare IT into the 21st century.
VistA offers us two things:

  • Software honed by real use and front-line input over many years that we know works in a number of different healthcare systems.
  • A model for development and continual improvement that allows meaningful engagement with front-line staff (particularly clinicians) and which enables the resources of a global community to be applied for the benefit of all.

What we need to move forward is an open ecosystem in which apps designed to meet the specific needs of end users can be orchestrated to work together and can interoperate to share information and manage the processes of care. I believe that as a result of work going on in and around the VistA community that it will evolve to become a key component of this platform while simultaneously being able to meet the needs of those NHS organisations whose current requirement is for a good quality traditional EHR.

VistA will require localisation to make it suitable for the NHS, but would seem to already be closer to NHS requirements than many commercial product emanating from the USA. My experience with commercial suppliers is that they wildly  underestimate the localisation effort, and I suspect the same will be true for VistA, certainly an evaluation by the Scottish NHS some years ago rejected VistA as it was then on the grounds of localisation costs, but things have moved on and  given the support of an enthusiastic UK community this does not seem an insurmountable barrier and with such localisation VistA would immediately be able to provide a much better solution for NHS organisations than many closed-source alternatives.

However, what makes VistA really attractive to me are other things:

  • The open-source  approach to development and implementation which engages and empowers clinicians and other frontline staff
  • The ability to share improvements from and with the growing global VistA community
  • Work being done in and around VistA to enable it to provide a platform for apps and take advantage of the the latest web and  cloud technologies

My ambitions for VistA are not the same as many in the NHS VistA community. I’d like to see VistA (as an EHR) widely used in the NHS, but I don’t want to see it as the one systems for the NHS. I am also interested in how VistA can provide a core part of an open ecosystem for health and care IT but I don’t want it to be The Platform for the NHS, just part of it.  However, I believe my views about the next steps are broadly aligned with others  and I want to work with them and am happy to see where this leads us with an open mind.

I want to see more plurality both in systems and platforms. I want to encourage cooperation so we can explore how we can get things working together and I’m particularly interested in working with those things that have an open model: VistA, SMART Platforms, OpenEHR, Open Clinical, etc, but also with those vendors with proprietary  models where they are willing to open up their systems, particularly those of a pragmatic bent like the many existing vendors that work with IHE to demonstrate real world interoperability between commercial systems.  However, I also want to see competition, particularly  in the app space so entities with different business models can compete to provide niche functionality and the best user experience confident that the underlying ecosystems will enable their apps to interoperate and be orchestrated to share data and work together.

I also want see some plurality in the platform with competing suppliers of  EHRs and PHRs (so patients can decide who they trust to hold their data) and multiple providers of knowledge and information that apps can consume, allowing users  to decide who the trust and which business models they are comfortable with.

We also need to address the weaknesses in VistA:

  1. Its core is built using 1970’s technology (MUMPS) and even it most ardent users describe it source code as “labyrinthine”
  2. Its user interface looks increasingly jaded
  3. As VistA is used more widely in many different health care systems it becoming increasing difficult to handle source control and configuration management so that improvements from all parts of the community can be used by all others who might benefit from them.

However, I believe the above  can addressed and indeed work is already underway.

The first two points can be dealt with by wrapping VistA’s core code in a service wrapper to provide an API that allows new user interfaces to be built outside the core using whatever technology is available to deliver the best possible user experience. As most development occurs in the user interface layer most developers will have no need to work with the core code, will be insulated from its complexity and can use whatever tools they wish to develop user interface components.  Tools such as EWD  and SMART  are already available to support this approach and although SMART is currently read-only  it is of particular interest as it provides a standard layer for apps that allows the same code to work with any SMART enabled EHR.

The third point requires a more sophisticated approach to configuration management and source control, (more info from OSEHRA) fortunately the issue is recognised and work has already been commissioned to address it, but it’s not an easy problem (details here).

So in conclusion I have a different vision for VistA in the NHS than  the NHS Campaign for VistA. However, we both want to see an NHS version of VistA and we both want to see it widely implemented. So let not worry about where we hope and think this should lead. Looking at the NHS Campaign for VistA’s  8 point plan http://nhsvista.net/our-ambition/  The first six steps align broadly with what I want to see happen so lets get on an do it and see where it leads us which I suspect might be a different than any of us currently expect.