It’s time to be more open
We need to be more open
Outside of healthcare, open source software dominates. The internet is driven by it, most mobile phones are powered by it. It has become a byword for reliability, scalability, and security. Its promise to accelerate innovation has been proven time and time again. So in healthcare – what’s holding us back?
The answer I think, is found in a combination of three different aspects of our industry: Healthcare culture itself; the need for software suppliers to grow; and, above all, the need for those who do build open source projects to control them. And it’s this last point that I want to stress: if we want to accelerate innovation in healthcare software, we just need to be more open.
Healthcare is, quite rightly, a highly regulated industry. New services, new treatments, new software and even new ideas, are thoroughly evaluated before being adopted. This is as much a cultural norm as it is an operational requirement. Innovation carries risk and risks in healthcare can have serious consequences. As a result, the main question asked when a healthcare provider buys new software is: where has this software been used before? This presents a real challenge to software suppliers who need to strike a balance between innovation and maintaining an evidence-base for legacy systems. Clearly, at its extreme, if the entire healthcare market only adopted software already in use – nothing new would ever be developed.
Supplier profit and growth
Many companies move into healthcare from other industries, taking a product that is in current use and trying to adapt it for healthcare. For ‘back office’ applications this might not be that hard – there is nothing healthcare specific about payroll or email. But for clinician and patient-facing applications, these companies usually run into problems. The first is that healthcare is not a single industry: it is a meta-industry. Changes made for one specialty will require additional changes for the next – a cause of constant frustration for the naive market entrant. The second is related to the first. The need to continually adapt the product can limit business growth. While a company can generate profit with a few customers, the need to continually, exponentially grow, is practically impossible. The final problem is market demand. Why would companies that have established simple products need to innovate when they can simply sell what they already have? A risk averse market does not reward innovation.
A need to control
While it might require unusual effort from both software suppliers and healthcare providers, innovation does happen in our health service and there are many impressive isolated examples. The problem is trying to replicate these elsewhere. Obstacles to wider adoption are often attributed to ‘resistance to change’, ‘not-invented-here syndrome’ or ‘healthcare complexity’ – but I find these explanations unconvincing.
From my perspective, the biggest obstacle has been the need to control by the innovators themselves. When a healthcare provider develops a homegrown solution, almost immediately the question of selling the solution to others is raised. Care providers are not set up to commercialise software or sell it to others and the need to protect their (now financial) investment can stifle wider adoption.
When a software supplier takes the time to really understand their customer and builds a solution that ‘just works’, pressure for growth and a return on their investment, prevents more money being spent to make the changes required for the next customer – and again wider adoption stalls.
Few now question that the best way to ensure wider adoption of innovative software is to open source the code. However, the desire for control can still lead to problems resulting in projects that are open source in name only, with code not being readily available, out of date, or just too difficult to use. There are sadly too many examples of this in healthcare.
This last point is for me the most important and is why is Interneuron is supporting the new OpenChain project backed by the Linux Foundation.
The OpenChain Specification defines a core set of requirements every quality compliance program must satisfy – making open source compliance simpler and more consistent. Organisations can display their adherence to these requirements and build trust for both customers and partners.
If we want faster innovation in healthcare software, something has to change. We aren’t going to change the culture of healthcare or the nature of commercial industry, but we can change how open our open source projects are – and we can insist they comply with new industry standards like OpenChain.