Monday, 15 July 2013

Open Source in the NHS

Open Source in the NHS
I have worked in the UK health service for over 15 years.  During this time I have subscribed to the patient centric values of the system.  As an IT employee this is often overlooked when managing implementations, configuring hardware or developing software.  Over that time I have seen small systems come and go and a national programme deliver lacklustre benefits.  During that time I was working for a very successful Trust who ignored all the noise and continued to focus on one thing.  The patient.

Recently the government asserted the intention to utilise "Open Source" within the health service to ensure interoperability and sustainability for future developments.  This message was underpinned by the inclusion of 4 specific use-cases of Open developments in the NHS.  These being:-

·         Wardware - An open observation and assessment solution managed and controlled by Tactix4.  Source is not linked from home-page.
·         OpenEyes - An open solution for ophthalmology, available openly from GitHub. Here:
·         VistA - the veteran health information systems platform.  An *Open* platform built on MUMPS with a view to modernise using JavaScript.  Source available via FOI request.
·         King Integration Engine - an integration platform built around Apache Camel.  Cannot find the source or documentation online.

As a senior manager and software engineer by trade I am slightly miffed by some of the recent messages.  I am also slightly confused by the understanding of OSS in the literature produced to date.  For me an Open solution has to meet at least 3 key criteria in order to be classified as truly "Open".

1.       All the code should be Open, freely available online, well-documented and accessible.  The code should be managed with multiple commits from multiple sources.  It should be evident that regular commits are made to the code and the code-base is active. This is somewhat a utopia, but good open solutions tend to meet this criteria.
2.       The licensing for the *solution* should utilise an "Open" license.  Meaning that *all* elements of the solution should be free to use and unrestricted from modification and distribution.
3.       A corporate investment/viable service provider should be clearly backing the product.  This may sound counter intuitive but in order for an Open solution to be viable long-term it needs backing from a corporate entity.  Without corporate backing the solution is "unsupported" and there is little evidence to ensure continued development.  You could end up with a stale loaf of bread.

If you use the above as a check-list of Open compliance the case-studies identified fall short.  The only exception being OpenEyes, which apart from some UX polish, is delivering on its ambition and following open principles.  I know that Tactix4 and KCH are working towards this, but it shows the difficulty of managing Open-Source.

This is not an attempt to dumb down or belittle the message.  The individuals and organisations above are carrying a vital baton for the health software industry.  One, that executed correctly will change and empower the NHS with true interoperability and sustained platforms.  

What we need is some published  standards and approaches which are vital to NHS certification.  All of the solutions above vary drastically technically, from Php to Java to MUMPS and C.  This increases the TCO for an organisation and when the government is trying to reduce costs we should be looking to consolidate technology in our estates.  If this is unachievable the government needs to provide these solutions as cloud hosted services, shifting TCO to the government. 

Open-Source is an Eco-system that has a management overhead.  All software requires design, build and testing.  Even in an agile world this is difficult to do on a large scale.  To create an Open-EPR with no controlled assurance is high-risk.  Who owns the legal obligations of an open system with a buggy commit that impacts patient care?  Who fixes these issues and what are the SLAs? Who supports the developer community around these products?  These are all vital questions which need resolving to ensure a mature “Open” delivery.

I believe the government should invest in an open platform which provides the core technology stack for "App" development.  This platform will utilise standard "Open" APIs and architecture for integration and development.  The government can control the standards and approaches to inclusion, offering services to NHS trusts who wish to implement an open offering.  This SaaS federation approach is the "Cloud Model" and one that is untapped to date for clinical systems.

Each NHS trust is different, each has different views, values, choices and demographic issues.  A "one-size-fits-all" approach is not going to work.  This is the challenge in the IT space too.  Every Trust has different skills and expertise.  Some Trusts have no in-house skills whatsoever.  How will we achieve the flexible configuration without holistic involvement and commitment from local Trusts?  This is where NPfIT failed.  There was a lack of realisation that local configuration is critical to successful implementation and takes years to achieve.

It is going to be interesting to see where this goes over the coming years.  New services such as are appearing which genuinely excite me as an IT professional.  I sincerely hope that over the coming months some decisions are made around how openness will be delivered to the NHS.  Currently the message is unclear, lacks thought, governance and vision.  

As the message evolves and matures I look forward to the outcomes.  A world where free-solutions are available based on modern technologies that are safe, usable, configurable and interoperable.  Until that day comes I will continue to focus on the most important thing in health.  The patient.

No comments:

Post a Comment