There is a discussion going on on the NHS Technology Community site on what the barriers to open source are in the NHS, and how to address them. The posts are interesting, but one thing is lacking: a statement of what it is people are trying to achieve, other than solving local problems. I made a post that may interest others more widely, as follows (slightly adjusted here).
I would suggest that if people want to understand barriers to open source in the NHS, they need to understand the supposed need for open source. Is it:
- to enable in-house developers to add to an existing product?
- They need access to something like plug-in interfaces to do this. Probably not the main product source (e.g. Intersystems Ensemble, Cerner, ….) though.
- to enable in-house developers to develop the main product, e.g. HIS/EMR?
- This probably isn’t sensible, since a HIS is a huge undertaking, and it’s a waste of money if every trust develops more or less the same thing.
- But a common effort to build pieces of a large ‘product’ could make sense.
- to enable developers across trusts / NHS to work on a single common solution / set of solutions?
- This would be an interesting idea, but the NHS central funding structure works against this, e.g. by handing out Safer Wards/Safer Hospital funds to trusts but not to any core development entity
- to improve interoperability?
- I’m sorry to say that open source probably won’t directly help here. The evidence over 20y is that open source solutions create just as many lock-in data structures as commercial ones – lesson: interoperability is only solved by making specific efforts. Open source can help greatly in making those efforts.
- to ensure certain IP has longevity unhindered by specific commercial entities lifetimes or management decisions?
- This is certainly reasonable.
The only way open source can make a big difference is if multiple small and large projects can co-exist, and yet produce components & solutions that work together. That can only possibly happen with a ‘platform’ concept, and it needs to be backed centrally, although not developed centrally.
Some may find this blog post on ‘what is an open platform’ useful. As soon as you get into platform territory, you are talking about standardisation. Now this topic is a minefield in e-health. Some possibly useful posts I have made in the past on this:
In sum I would suggest that systemic improvement in the open source situation in NHS requires a) a systemic look at what is trying to be achieved and b) the right kind of central backing (but not ownership) of a platform definition. With the latter the industry could start to commit to an open source platform and related components, and an ecosystem of development projects can emerge that won’t each be their own private silo. This could get started with funding for existing industrial quality platform components to be made open source for the NHS, as well as existing funding for apps, current NHS open source activities like HANDI-HOPD (which assumes and needs an open platform).
The main aim here shouldn’t be to take on the Cerner, CSC, etc, or GP supplier systems or integration vednors like Intersystems. It is to attack the ‘Access database’ problem in trusts, to enable faster development of more useful apps, and to get more secondary value out of existing data. And to slowly standardise. The big vendors will come to the party over time.
If the NHS were to support this, it would enable thousands of talented developers, geek-docs and small innovator companies to provide value for the UK health system, have some fun, and get a bit of kudos into the bargain. We shouldn’t be wasting this talent pool. These local developers often know better than anyone what to do with the locally available data.
The key to this is understanding that open source and open standards go together, and can only be realised in an open platform.