Category Archives: Apps

Defining an Open Platform

It is widely agreed that the future of digital health lies in an “Open Platform”. However, it’s not clear as to exactly what an Open Platform is or how we get there. With McKinsey tell us that health care systems that create an open platform can save more than 11% of total health care cost this is a question we urgently need to answer

“…….each national or federal health system should consider an open innovation platform that holds healthcare data ……………., and provides data access that is enabled for application programming interfaces as well as common technical IT services such as identity, access, or consent management. This platform would serve as the basis for an ecosystem of digital-health-services innovation……”

“In 2014, we did considerable research into the economic value of digital technologies in healthcare and found ……..  net economic benefits of 7 to 11 percent of total healthcare spending. Over this past year, our work on the ground has confirmed this original analysis. However …………  we believe an even greater impact can be achieved through coordinated joint effort. This would involve the interconnection of all digital-health stakeholders through an open innovation platform.”

McKinsey and Co., Jan 2016

This blog is an attempt to do so on which feedback from others would be welcomed..

While any given instance of an Open Platform will be a specific implementation of a set of software components owned and operated by a particular organisation (this might be a health and social care organisation or a third party, operating the platform on behalf of a local health and care community), it is most usefully defined by a set of principles rather than the specific details of a particular implementation.

Open Platform Principles

Any platform implementation that is truly to meet the definition of being ‘open’ should comply with the following principles:

  • Be Open Standards Based – The implementation is based on open standards which any willing party can use, free of charge, to build an instance of the Open Platform – what these standards are will be described later in this article.
  • Share Common Information Models – There should be a set of common information models used by all instances of the Open Platform, independent of the specific technical details of a particular implementation.
  • Support Application Portability – Applications written to run on one implementation of the Open Platform can run with little or no change on another independently developed implementation.
  • Be Federateable – Any implementation of the Open Platform can be connected with all other independently developed implementations in a federated structure  to allow the sharing of appropriate information and workflows between them.
  • Be Vendor and Technology Neutral While those building an implementation of the Open Platform will chose particular technologies and may choose to use or include proprietary components, the standards should not depend on particular technologies or require components from particular vendors.
  • Support Open Data – An implementation of the Open Platform can expose all of the data it contains in an open, shareable, computable format in near real-time; it is for implementors to decide if they choose to use this format natively in their persistence (storage) layer of the Open Platform, or meet this requirement by means of mappings and transformation from some other open or proprietary format.
  • Provide Open APIs – APIs are the means by which applications connected to the Open Platform are able to access and update the data it contains. There are a number of available open APIs (see below) and ideally any platform should support a number of these to give the maximum flexibility for applications that wish to connect to it.

Open Platform Standards

Meeting these characteristics implies the use of certain approaches and the adoption of certain standards. However, it is important to understand that by its very nature an open platform, just as with the Internet, is not something that can be rigidly defined and indeed is something that will continually evolve. There are multiple ways to build an open platform and for these to work together we don’t need and can’t have rigorous standardisation; we need just enough of a common approach to make things work. This approach is different to that historically adopted in NHS IT, but it is the model on which the Internet and World Wide Web were built and have succeeded. See these two pieces on my blog here and here.

At the core of an open platform is the need for common information models, which define the clinical content (information) to be represented on the platform and which provide a sharable, open and computable format for that information. Currently there are only two approaches that have current support from the global health informatics community.  These are the Clinical Element Models (CEMs) and openEHR. They adopt very similar approaches, coordinated through the CIMI initiative. In the NHS, the HSCIC has chosen to use openEHR; which is the model that has achieved the most widespread global acceptance and use.

Information models, such as those created by openEHR can be used natively in the persistence (storage) and messaging components of the platform or be used simply to inform the design of these components using either another open standard such as HL7 FHIR, XML, JSON, or by using proprietary approaches. The critical point is that  an open platform can produce and consume data in a form compatible with the standard information models. It is for the designers of the platform to decide how to do this, but I would expect those building from scratch to use openEHR natively in the persistence layer and those adapting existing systems to converge their internal representation on these standards over time.

Open Platform Architecture

The architecture of an open platform will evolve over time and it is likely that different implementations of the platform will vary in the detail of the architecture and the particular components included. What’s important is not that different implementations are identical, but that they comply with the principles described above. The diagram below proposes a possible architecture. Any open platform of this kind is likely to have similar components, arrayed in a functionally equivalent architecture and to implement a similar set of standards.

Open Platform Architecture

The heart of the platform is an Enterprise Service Bus (ESB) which links the components together and provides authentication along with the management of the Application Programming Interfaces (APIs), which serve both platform components or services and external systems connected to the platform.

Core components of the platform include:

  • repositories for both structured and unstructured data (documents, images, etc);
  • a Master Patient Index (MPI) and Registry which stores basic demographic data and provides a locator service to help find where the records for a particular patient are held (e.g. on the platform, elsewhere in the local health community or on other federated platforms);
  • knowledge services that provide access to knowledge (particularly workflows, processes and decision support);
  • a range of external connectors which allow applications on the platform to connect to existing systems relevant to the local health community including other local systems and national services (such as NHS Spine);
  • a range of platform services, none of which are essential, but which, if available, remove the burden of dealing with the functions they support from application developers. These might include:
    • terminology services;
    • identity management;
    • consent management; and,
    • access control (role based access (RBAC) legitimate relationships (LRs) and workgroups.
  • Connectors and federation services to other platforms to allow platforms to be connected in a federated web allowing an authorised user to discover and access any relevant data in any location.

It is my strong view that the right choice for a structured data repository is openEHR and the right choice for the unstructured data store is IHE-XDS. (IHE-XDS also provides a suitable option for the registry). Both of these open standards are well supported by vendors with a number of proven proprietary implementations and emerging open source options. However, there are alternative approaches that could comply with the principles described above.

I don’t have fixed views with regard to the best approach with regard to the knowledge repository, but the work of Synapta to draw together a number of available standards including BPMN 2.0, GDL, CMMN, Drools and PROforma looks promising.

Examples of Open Platforms

There are a number of examples of open platforms that adhere to the principles outlined here and a number of people working to create more.

Established platforms that include both openEHR and IHE-XDS, working together include Moscow City support health and social care for 12 million patients and Slovenia support the entire population of 2 million. There are many more examples based on one or other of these standards that could easily be extended to do the same, including a number of UK projects.

There are also a number of other projects in the UK working together to refine the definition of an open platform and build implementations these include.

  • NHS England Code4Health This is based on my work with Dr Ian McNicoll for HANDI. The Code4Health Platform provides a simulated environment where people can explore open platform concepts and APIs and build applications to test their ideas.
  • Ripple who have an operational open platform based on openEHR in Leeds.
  • The Endeavour Health Charity who are building a platform using HL7 FHIR and a number of connectors to legacy systems.
  • Operon who are developing Synapta to provide components to support open workflow standards including BPMN 2.0, GDL, CMMN, Drools and PROforma

All of these projects are working together coordinated by the Apperta Foundation  (a clinically led not-for-profit company established with initial grant aid from NHS England) and are already committed to using a common set of information models created using the openEHR tools. The aim is to agree a common set of standards and components which will enable them to build implementations of open platforms which comply with the principles here. Each implementation will be different, enabling us to learn what works best, but similar enough to enable federation and interoperability.

We are actively talking to a number of projects in the pipeline and some other existing projects already using one or more of the core standards described here, so we expect to see many more open platforms complying with the principles outlined here. If you like to join us get in touch


Feral Systems (or I’ve got a great big Access database)

In my work, both within NHS England and as a judge in the EHI awards I have come across a number of promising bits of home grown software development in NHS organisations. Also as I talk to people in the NHS find that as well as these publically acknowledged systems that there are many others that are often a unknown beyond the project or service that use them and typically invisible to IT departments. On Director of ITC of a teaching hospital of my acquaintance who went looking and found many hundred such systems and was sure he hadn’t found them all and termed them “feral systems” comparing them to the feral cats that also infested his hospital.

The hundreds of “Feral Systems” in an average large hospital represent a goldmine of knowledge and innovation that could be harness in the design of digital systems that really work, but as they are today they also create a massive technical debt and create safety, governance and reputational risks for the organisation in which they are used.

We have to enable these developments to continue without too much interference but we need to make it as easy to do this in ways that are as  safe, scalable, interoperable and sharable as it is currently with those tools and approaches that are not. 

There are two things I’m involved in that I think can help, The first is the NHS England Open Source Programme and the second is HANDI and in particular HANDI  HOPD

Typically these developments have been by people who are amateur software developers with other day jobs in the NHS (clinical, management or IT) who are not professional trained in Computer Science or Software Engineering. They have produced these, typically small programmes or apps, because they are frustrated by the ability of their enterprise systems to meet their specific needs in a timely manner and because they understand what’s needed and have the skills and the modest resources needed to just do it.

In general these programmes are written with no intention that they should ever be used anywhere other than in the author’s own immediate environment or that anyone other than the original development team (often a team of one) will ever need or want to delve into the source code to maintain or develop the software. They are produced using whatever tools are to hand using whatever techniques the author is familiar with. Historically this was often Microsoft Access or Excel with some VBA, increasingly it is with some easy to use web or app development stack. PHP, Javascript, Python, Ruby etc. This work is typically done in blissful ignorance good software engineer practice and governance requirements, but in the intended context of use this matters hardly at all.

These developments are often great, because the author is very close to the user (probably they are one of the users) knows exactly what’s needed in their environment and is on hand to rapidly deal with bugs, support issues and enhancement requests.

This approach has much positive aspect but raises many serious issues.

1)      Stuff that could be really useful in other places lies undiscovered and in any case is not actually in a fit state to be easily used and developed elsewhere if it is discovered. (see also my piece “Making the most of NHS IPR” )

2)      There are multiple people doing similar things who would achieve even more if they knew about each other and had a way of working effectively together. Judging the EHI awards I saw lots of examples where I knew of other similar work of which the entrants were unaware and even multiple entrants independently doing similar things unaware of the others.

3)      These systems tend to grow, because their developer is so close to and responsive to user needs, such that systems originally intended to do just a few limited things becomes the mainstay of the IT supporting a unit or service and it all falls apart when the original author moves on.

4)      These systems are typically written to do just what’s seen as essential and pay scant attention to security, information governance and interoperability issues. This is fine initially but is a major source of future problems and exposes the organisation to significant risk and the response of senior management and IT Departments is often to try and shut these things down on the rare occasions they find about them.

The last thing I want to do is inhibit this sort of development as it is a massive potential source of innovation and a great way to get frontline staff engaged in the development of digital systems but I do want to make it easier for them to create systems that are safe and interoperable and help make any innovations that have value available to the wider community as a sustainable product. I’m also keen to help ensure that when the problem has already been solved or partially solved elsewhere that people know this and that when multiple people are working on the same problem that they are encouraged to think about teaming up.

There are two things I’m involve in that I think can help, The first is the NHS England Open Source Programme and the second is HANDI and in particular HANDI  HOPD

Open source is a natural way do collaborative projects and ensure good work is available to others. In many case developers have no desire to commercially exploit their IPR, but there are also lots of ways to build successful commercial enterprises around open source products. If you want help and advice on creating open source software or taking an existing product where you or your organisation own the IPR email the team and I or one of my colleagues will be very happy to help you whatever your ambitions are for your product (see also see my blog piece “What makes an Open Source community?” 

HANDI-HOPD is the HANDI Open System Demonstrator and will give you access to enterprise quality components, tools and knowledge sources to help you build prototype apps in a way that will address many of the interoperability, orchestration and governance challenges that are otherwise really hard to deal with, with minimal effort. It can also provide free compute resources in the Cloud with free access to knowledge sources and test data in a realistic simulated environment where you can create and refine your app and engage with a community of other likeminded people. HANDI-HOPD is vendor neutral and agnostic as to whether your business model is proprietary or open source. It’s strictly for experimentation and non-operation use with test (fictitious) data but because it’s based on open standards apps developed on the HOPD should be easily transportable to one of a number of production environments (offered by our partners and others) for operational use or your own live environment if you support the same open standards.

Making software functional, desirable, safe, robust, scalable, maintainable, interoperable and fit for collaborative development requires skills and knowledge that most gifted amateur developers don’t have (and in many cases don’t have the time or inclination to acquire). Indeed, many IT professionals in the NHS, whose expertise lies in implementation and support or more traditional development approaches, and many of the commercial organisations currently service the NHS don’t have these skills either. However, there are a few organisations working with the NHS and more outside who do know how to meet these challenges (in particular some of the successful Enterprise Open Source companies offering more generic and commodity products) and  some specialist SME currently servicing open source projects in the NHS. It is critical that we identify these organisations, find ways to get them effectively engage in the NHS and increase the capacity and capability of those that are already engaged. The NHS England Open Source Team are keen to hear from organisations that think they have the skills required.

However, as well as NHS England Open Source and HANDI there are many organisations who can provide advice on basic things you can do to help ensure your software has these desirable characteristics and for those who want to find a commercial partner who can help you address these issues, help you deploy, support and develop your own or others open source solutions we can also help – We are also interested in hearing from both commercial and social enterprises that are able to provide such services or want to better understand the opportunity to do so – Please email either or

HANDI-HOPD provides a safe simulated environment to easily develop the sort of tools that typically get designed as feral systems, but the standards and approaches used make them safe, scalable, interoperable and sharable with minimal overhead. HANDI-HOPD itself does not provide a hosted environment for operational deployment, but actually uses the technologies that can  (Elastic Cloud Computing, Software and Platform as a Service (SaaS and PaaS) and Docker Software Containerisation) and we know other will mirror these with Internet and N3 Hosted Operational service. This creates the opportunity to create a simple app in a few hours on the HOPD and deploy it at scale in a few minutes on a laptop, data-centre, private or public cloud and it many case for small scale use this first tier of service will be free to us.

Lets herd those feral cats!


GPSoC – PQQ Deadline 4th July

This procurement is NOT just relevant for those in or wishing to enter the GP clinical systems market – Don’t miss your opportunity.

The new GPSoC procurement provides an important opportunity for anyone who wants to sell products or services in or which interoperate with UK general practice. The OJEU Contract Notice was published on 28 May and  has now been followed by more information including  the Memorandum of Information  and a link to request the pre-qualification questionnaire (PQQ).

The deadline for submission of the PQQ is noon on 4th July and Woodcote Consulting stand ready to advise and assist anyone who wants to explore these opportunities further.

This framework is very broadly drawn and while its core purpose in the provision of GP Clinical Systems to English general practice it provides a procurement vehicle  which could provide a route to market for a wide range of apps, digital tools and services for use in general practice or related to interoperability with general practice from other parts of the care system , with the  framework available for use by any public sector body across all the home countries in the UK.

There are three lots.

Lot 1 is centrally funded and relates to  GP Clinical Systems and certain high priority subsidiary products and apps

Lots 2 and 3 are not centrally funded but provide a flexible procurement route for local NHS or other public sector bodies wanting to procure the products and services covered. Lot 2 covers additional GP IT services while lot 3 covers cross-care setting interoperable services. My reading is that these lots could also include patient facing apps and services which GP Practice, CCG or CSU wish to procure for use by patients they serve.

The future GPSoC Contract also place a requirement on principle system suppliers to provide open interfaces to third party products and services, which together with the procurement framework provided create a very significant opportunity for vendors large and small in this key market, which all vendors should investigate. If you would like to explore how we can help contact Ewan Davis +44 207 148 7170 or +1 (347) 688-8950

An ESB for GPSoC Phase 2 ?

A key feature of the proposed new GPSoC contract is the opening up of interfaces of the principal GP systems to subsidiary system suppliers (this can include pretty much any product or app that might be offered in the primary care market.) The plan is to address the interfacing issue into two phases which will start broadly in parallel, but deliver over different timeframes.

Phase 1 is intended to be available from day 1 on the new GPSoC contracts and will simply place a contractual obligation on principal suppliers to make available broadly those interfaces they currently make available at their discretion (although some principal suppliers will have a little work to do to meet the minimum requirements.)

Phase 2 aims to make available a standard interface across all systems and while it will probably do this in an incremental fashion is not expect to deliver anything until at least 18 months into the new contracts.

This approach seems very wise to me, as I suspect 18 months is an optimistic  view of how long it will take to get to even a first version of a standard interface. Opening up what’s available now, particularly with some enhancement to the weaker systems, will be great stimulus to the market.

Work on the approach in phase 1 is going well, looks like it will substantially address the concerns raised in my last blog on this subject and enjoy broad support from both principal and subsidiary system suppliers and I don’t plan to say anything more about this here. What I want to do in the rest of the blog to look towards phase 2.

Point-to-point connections between principal and subsidiary system suppliers and accreditation on a similar per interface basis provides a viable option in the short-term but becomes increasing difficult as the number of subsidiary systems increases and becomes unsustainable when we look to moving the scope beyond GP systems. At this point we will need some form of intermediary bus such that all systems have only to conform and be accredited to the standards supported by the bus. It seems to me that while we might not absolutely need this in the immediate GPSoC context developing this as part of phase 2 would lay excellent foundations for the future.

I’m not a technical architect but it seem to me that it would be possible to use Enterprise Service Bus (ESB) technology to provide such a service (I would propose one of the existing health aware Open source ESBs) at it simplest the ESB would simply pass through interface requests looking no different to a third party supplier than an interaction directly with the principal systems. However, an ESB could do much more than this and its’ interposition would have many benefits:

  •  It could  off-load many functions from the principal supplier 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.)
  •  It could protect principal suppliers from badly behaved applications and help in the arbitration of interface malfunctions (avoiding confrontation between principal and subsidiary system suppliers.)
  • It could  provide a transaction accounting platform that could support innovative business models (such as pay for use models) driving usage, better value and  more desirable and functional systems. The accounting platform could also provide a mechanism for charging the responsible party for compute resource consumed by interface users.
  • It could provide transformations and mappings between different technical and clinical content standards used in systems (making like easier for all participants) and facilitate incremental progress toward common standards.
  • It would provide infrastructure for interoperability beyond the scope of primary care.
  • Provide an access point for developers to other NHS systems (eg SPINE, EPS, C&B, Customer Service Platform) building on the good work done with the NHS Interoperability Toolkit ITK.

I plan to explore these ideas with the GPSoC Team and through my work with HANDI and Intellect and would welcomes others views.

More Information

More information about GPSoC and copies of many of the draft documents are available from the GPSoC web site.

What is an ESB?

There are a number of open source ESB with healthcare specific functionality that could be candidates for such a service:



Apache ServiceMix

More information about ITK is available at their web site

There is also relevant material on the HANDI and OpenGPSoC websites




The power of information and digital technology to transform the NHS

I believe passionately in the power of information and digital technology to transform the way we deliver health and care, indeed I consider it essential if we are the meet the growing demands the health and care system faces within the resources likely to be available.

We need to mobilise information to help us redesign services and target the resources available most effectively. We need to use digital technology to deliver higher quality more convenient services more efficiently and we need to make information about how services perform transparent  so that the public, patients and health and care professionals can see how they perform and how they can be improved.

However, we need to leave decisions about how local health and care communities realise this potential to them, measure their success in terms of the health outcomes and efficiencies they achieve and avoid mandating particular approaches. While I think it is inevitable that the effective uses of digital technology will lead to a reduction in reliance on paper and an increase in the use electronic record systems it is not true that a move away from paper towards electronic records will necessarily lead to an improvement in the quality of care, indeed when the emphasis is on implementing particular systems rather than improving the processes of care experience tells us that the opposite is more likely. Focusing on becoming paperless and implementing EPRs is a dangerous distraction which potentially provides local health communities with an excuse to fail at their core task of delivering higher quality care.

The primary focus needs to be on how we apply digital technologies to mobilise information and knowledge at the point of care to improve the experience and outcomes for patients and health and care professional at the frontline, while an important secondary focus should be on how we use information and knowledge to design, target, evaluate and improve care.

We should have zero-tolerance for systems that slow down or make tasks at the frontline more difficult (as is so often currently the case) Our expectation must be that good design can create systems that meet upstream information needs without additional frontline burdens.

The incremental upgrading and of digital technology in line with the incremental redesign of care processes is more likely to bring about positive-only changes in care quality than radical big-bang implementations which at best typically result in a substantial negative impact before any net positive benefit is achieved (which in health and care means avoidable death and suffering.)

This requires a new approach from the health IT industry, but one that current technologies can deliver and which can be successfully built on top of the substantial, and in many places excellent IT, already in place. This approach will draw heavily on app and portal technology, open-systems, open-interfaces, open-standards and data transparency. It will require the extension and opening up of existing systems and infrastructure to create an open health IT ecosystem creating a mixed economy for open-source and proprietary components. My experience with both the established health IT vendors and the rapidly growing app community convince me they are more than up to the challenge.

The Centre does have a role to play in creating an environment in which local health and care communities are encouraged and enabled to embrace information driven, digital ways of working, but have to be careful balancing  this with the risk of creating unintended consequences and sub-optimising behaviour in local health and care communities. The Centre needs to ensure that personal and organisational incentives are aligned with the need to deliver integrated patient centred services in ways that improves overall quality and drives down overall cost (which they currently are not) and also has a role in creating the technical, cultural and commercial environment in which successful innovation can be translated in to widespread adoption creating a vibrant market.

In playing its’ part the Centre needs to have a clear understanding of the history – In NHS this history of has many clear examples of both spectacular success and failure and needs to engage with those who not only share their vision, but who also understand this history, what life’s really like on the front-line of the NHS and the practical implementation challenges of achieving the vision.

Patient record access – A spur to innovation

I’ve been involved in one of the working groups which are part of the RCGP-Led Online Patient Access Project,  which has been funded by DH to help deliver on the Government’s promise to deliver online access for all to their GP records and a range of associated transactional services by 2015. As part of this work I attended a meeting tyesterday (25 Oct 2012) between the project and interested suppliers from the Intellect Healthcare Group.

This was an open meeting with selected press present so unlike other parts of my work with the project I’m free to talk about what went on. However, it’s not the core subject of the meeting I want to talk about, but how the meeting illustrated the potential that is unleashed when you start talking about opening up systems.

First some background. GP record access has been pioneered for some years by EMIS  working with Paers  and delivers full read-only record access along with support for transactional services (appointment booking, repeat medication requests, secure communication). So far only a handful of pioneers have turned on full record access while many more have opened up one or more transactional service. The two other significant GP suppliers also now offer transactional services and have full record access ready to go and it seems likely that the RCGP project, combined with sticks and carrots from Government , aimed at GPs, along with demand from patients will mean that the services become available to all GP practices during 2013, although I think it remains to be seen how many practices will opt to grant  full online record access and how strongly they will promote the services they choose to offer to their patients.

Government, however are not content with just getting basic services delivered by the incumbent GP suppliers, but have much more exciting plans to see core systems opened up to encourage third parties to develop a range of innovative services that will deliver record access and transactional services in a variety of ways.  There is an expectation that some of these new services will simply provide a slicker interface or access in ways more suited to particular patient groups while others will integrate patient record access in to products with broader scope (particular as part of services designed to help patient and their informal care networks manage long-term conditions) and finally there is a hope that some new things will emerge that those of us currently involved have not yet imagined.

From today’s meeting it seem to me that hopes for innovation are likely to met or exceeded if Government can get the technical stuff right and tweak incentives to ensure an opportunity for viable business models is created.

My reasons for reaching the opportunistic conclusion are based on what infer from examining the list of attendees and what was said at the meeting.  There were about 35 companies represented at the meeting including the large and small, many were primarily IT companies but a significant number were organisations offering a range of clinical and health management service. Interestingly, only one of the incumbent GP suppliers was represented and they had little to say.

The focus from the companies present was unsurprisingly on what might be available to them as a result of the records access project, but it was clear that they were also interested in the broader opportunities for innovation created for them by the opening up of systems, the data they contain and the transactions they manage.

The potential here is massive and I think this was not lost on the officials present from the Dept. of Health and the NHS Commissioning Board. I hope they will take the buzz from the meeting back to their masters as evidence that their commitment to open-data and open-systems does have the transformational power they hope for.

However, as you might expect there is a caveat. Catalysing the transformation requires more than just opening systems and data it requires action and investment to create an technical, cultural and contractual environment  which will allow the reaction to proceed at pace. Technically, this is about infrastructure and infrastructural  services (like identity management) and the right approach to standards see my blog: Standards are a barrier to innovation Culturally it’s about selling the benefits of transparency and managing legitimate fears about the “Daily Mail” effect. Commercially it’s about addressing procurement issues and creating an ecosystem in which sustainable business models can be built around openness.

There is much in what’s happening to encourage us but Government needs to act to ensure that the excitement and innovation they have created delivers sustainable benefit.


VistA for the NHS

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, OpenEHROpen 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  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.

HANDI – The Healthcare App Network for Development and Innovation

Most of you will know of my involvement with HANDI and new not-for-profit organisation intended to support and encourage the development of health and care apps to transform health and care. which I would urge you all to support.

People keep asking “are apps things that run on mobile phones?” and keep talking about “mHealth” as the coming thing.

Well, yes apps run on mobile phones and ubiquitous connectivity changes the world, but there is an underlying “app” paradigm that’s more important so forget the “m” and concentrate on the paradigm.

While it is true that the “app” paradigm comes from the mobile world, the mobility of apps is not the primary thing that makes them a powerful, disruptive technology, rather it is their other characteristics, and these can apply irrespective of the device an app is running on and the modality of its current connection.

My vision for an app is that it is an agile, lightweight and intrinsically connected thing, running on whatever device, from phone to 80 inch digital TV, that happens to be right for the user at any moment, adjusting itself to the form factor of the device it’s currently running on, using mobile connectivity when it’s mobile with a seamless handover of app and data as the user moves from device to device.

Apps are easy to build; at their most powerful when designed do a few things well; are easy to distribute, install and use; and with care can be orchestrated to work together.

Apps are easy to build because they make substantial use of pre-built components in a well defined development framework and can make use of third party data and services, available to them in the cloud, allowing the developer to concentrate on the unique not the generic features of their app.

App stores make it cheap and easy for developers to promote and distribute their app and for users to find and install it

Finally, if they have an appropriate platform, open APIs and a few standards Apps can be orchestrated to work together to meet the broader needs of an individual user.

Together, these thing drive cost down, quality up and enable new ways of working.

Already this new paradigm has produced a flurry of free or low-cost apps in health and care and enabled people who previously could not have got their idea to market to do so. But, this is only the beginning. If we can work together to make it even easier and cheaper to build health and care apps and if we can encourage the development/adoption of open APIs, open platforms and open standards to facilitate the orchestration of apps to support the processes of health and care, we will improve well-being and transform the way health and care are delivered .

This is what HANDI is about. Join us.