Category Archives: IPR

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 www.nhsopensource.org and the second is HANDI www.handihealth.org and in particular HANDI www.handihealth.org  HOPD www.handi-hopd.org

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 www.nhsopensource.org and the second is HANDI www.handihealth.org and in particular HANDI www.handihealth.org  HOPD www.handi-hopd.org

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 england.opensource@nhs.net 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 england.opensource@nhs.net or ewan@woodcote-consulting.com

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!

 

What makes an Open Source community?

There has been a lot of interest in the role of Open Source software in the UK over recent months, initially stimulated by NHS interest in the American VistA Open Source EHR, but now taking on a broader scope including some of the exciting home grown initiatives.

Included amongst these are a number of projects that started in a closed source environment, where the IPR owner has decided to shift to an Open Source model. From a narrow technical perspective making software Open Source is easy – You just make release it under a recognised Open Source licence and make it freely available for download. However, Open Source is about much more than the licensing model and much more needs to be done to achieve the benefits of Open Source than what the Open Source community disparagingly call a “Code Dump”.

Open Source is about an approach and philosophy that at its’ heart believes that by creating a community who can freely use and contribute to a product that we can create better software and release new commercial and social value not available from other approaches. Open Source enshrines some import  freedoms and principles which defined and maintained by the Open Source Initiative  that also provides guidance on licences that meet these principles.

To be effective an Open Source community has to be diverse and well supported; containing all of those stakeholders needed to ensure a sustainable business model for the products’ ongoing development and use in which no single entity has effective monopoly control and requires governance structures around a particular distribution or version of the source code (often called a “Distro” in the Open Source world) so that users can have confidence in the safety, security and quality of that Distro including changes and new contributions made to it by the community – Something that is particularly important in context of health and care software.

Stakeholders include:

  • Those that gain financial value from the existence of the Distro – These might be organisation that use the software or the data it generates (like the NHS, researchers and other health and care commissioners and providers) or organisation that sell services to community made possible by the existence of the Distro (including developers, implementers and maintainers) – It is this group of stakeholders who will be the main source of resources to sustain the development and use of the Distro.
  • End users of systems and those who they seek to serve using the software – It is only by involving end users in an agile user-centred design processes that we can build systems that truly unlock the potential of digital technology – Too often the poor design of tools that people are expected to use is a barrier to doing what’s important. In the context of health and care this means involving frontline clinicians, other health and care professionals, managers and administrators – Their needs are often not well understood by policy makers, senior management and IT departments. Most important of all it means working with patients, service users and their informal careers who are too often the victims of poor service resulting from poor design.
  • Academics and technologists who are able to educate the community with regard to those things they know that might enable the community to improve the Distro and/or the effectiveness of its deployment and help the community critically evaluate it use. This might include ensuring that the community is aware of existing and emerging standards, technology and theoretical frameworks of potential value to the community.
  • Policy makers and senior management who need to understand how the Distro can be deployed to improve services and how such use can both shape and support policy.
  • A vibrant market of individuals and organisations who can provide a range of services to support the development, implementation and use of the system as well as relevant add-on products and services. This market should ideally include individual consultants and contractors, SMEs, social enterprises and large global system integrators. It is vital for the health of the community that there is a competitive market in the products and service needed to improve, deploy and exploit the Distro so that user organisation have a choice of who they contract to provide these service.

The Distro needs a custodian, owned and controlled by the community, who will promote nurture and protect the Distro, provide mechanisms to encourage, manage and quality control changes and improvements to it by the community and commission the delivery of enhancements and other services on behalf of the community.  The custodian needs to set and maintain source code and documentation standards and ensure that documentation is available of a sufficient quality to enable a competent developer without prior knowledge of the product to work with the source code and ideally should be able to provide additional guidance and training to enable those who want to work with the software to be able to so as quickly as possible.

A key aim of the custodian is to try and keep the community together on a common Distro. Too often, short-term pragmatism results in changes to source code somewhere that breaks something somewhere else creating a “fork”in the source code tree. While some limiting forking might be healthy if too many users “fork off” the benefits of Open Source are diminished. Avoiding this requires that the custodian provides support for people to make changes to meet their needs without breaking things important to others, in a rapid agile and responsive way. However, making changes in this way will still be slower, in terms of achieving immediate local priorities, but doing so has damaging medium and long-term sequelae. The custodian has to close the gap between the two approaches and educate developers about  the benefits of doing things for longer term benefit.

Additionally , the custodian has a role in providing assurance and warranties to users that deployments based on the Distro support by organisations accredited by the custodian will be safe and secure to deploy in live health and care settings.

Enabling the custodian to deliver its’ responsibilities will require that it is funded by the community to do so. To facilitate this the custodian is probably best constituted as not-for-profit Community Interest Company (CIC) whose control is vested in the community such that no single class of stakeholder can determine its’ actions.

If we can build effective communities then the wider introductions of Open Source software in the NHS as part of a mixed economy alongside proprietary products will help drive better value and front line user engagement and commitment  across the board, just dumping source code under an open source licence (or worse some bowdlerised licence) will not.

 

 

 

Digital Healthcare – Making the most of NHS IPR

I’ve got what I think is an important question for NHS England.

How do we get the best value out of the IPR (intellectual property rights) created by NHS organisations developing digital tools – Is it by freely sharing this IPR or by seeking to exploit it commercially?

Encouraging innovation, and more importantly getting it adopted across the NHS, is rightly a high priority for NHS England another is the digitisation of the NHS and in regard to the later NHS England has been a welcome and powerful advocate of transparency, participation, open data, open systems and open source.

However, as is often the case with the NHS there appears to be a lack of common purpose across the organisation and a failure to align incentives with these objects, indeed there are incentives in place that seem to be designed to discourage them.

In the context of digital tools I am increasing coming across examples of in-house or wholly NHS funded development of innovative digital tools and services where a ill-considered and a generally futile desire to exploit the IPR created by the NHS organisation concerned is acting as a serious barrier to the diffusion of innovation into other NHS organisations and at the same time denying the developing organisation the help of others to improve what they have created.

I’m all in favour of the tax-payer getting a return from the IPR created by their investment, but when the prime customer is the UK public sector, in this case the NHS, this is at best a zero-sum game and given that the economic benefit from making innovation freely available for others to use and improve is considerable I would assert that the cost to the tax-payer of restricting the free use of NHS IPR in this domain far outweighs any commercial return that might be available.

My proposition is therefore that the IPR created in digital health tools with public funding should be made available as open source for others to use and improve.

If I need to cite example to support this I would choose VistAhttp://www.worldvista.org/ and SMART Platformshttp://smartplatforms.org/ Both are examples of open source health software the development of which has been substantially funded by the US Taxpayer, but which are freely available to all.  This has two benefits to its funders. Firstly,  the investment is available to other US Health providers and the software benefits from input from a global community to improve and extend the products.  Secondly, the availability of these products has created an ecosystem in which many commercial organisations have be able to build sustainable business models creating economic benefit.

So how then do we achieve this? Firstly, we have to educate both the NHS and the commercial vendor community as to the benefits of open source development and how this delivers best value for the NHS and creates commercial opportunities – I write more about this in future blogs.

Secondly, we have to remove pressure on NHS organisations to attempt to exploit their IPR where sharing it delivers better value to the taxpayer and we need to realign incentives to ensure this makes sense for the individual NHS organisation as well as the system as a whole. Currently we have pressure and incentives in the system that creates sub-optimisation1 and inhibit the spread of innovation in the NHS.

So my plea – If your part of an NHS organisation that has developed innovative digital tools or paid others to develop them for, don’t let them wither on the vine while you look for opportunities for commercial exploitation – These will be difficult to realise and it’s not what your organisation should be about.  Look to the benefits to your organisation and the system as a whole of making your IPR open source and join me in campaigning to realign incentives to make it easier for you to do so.

1 An interesting description of sub-optimisationhttp://pespmc1.vub.ac.be/SUBOPTIM.html