The final piece of the Open Health Informatics jigsaw is the use of open development processes. Open source software is most usually constructed using an agile software development process, with continuous builds, automated testing and open issue logs. There is nowhere to hide in such a development process – what you see is, quite literally, what you get and if you want something different you can either contribute through the existing development community, or do it yourself.
But open development processes, as embodied by agile methodologies such as Scrum, can deliver more than just software products. They can deliver solutions on time and within budget, through a true partnership between customer and supplier.
So how can agile methodologies deliver openness in the process of systems development and solution delivery? For a start, agile methodologies don’t pretend from the outset that customers know what they want, and that suppliers know how deliver it. This may sound fairly fundamental, but current practice in many large scale procurements is to encourage each side to commit to these pretences far too early in the overall development process.
IT project managers often make reference to the Project Triangle — combining the three variables of resources (equating to timescale and cost), scope and quality. It is commonly accepted that its possible to fix any two of these, but almost impossible to fix all three i.e. to deliver a system that works reliably, does everything originally required and costs what was originally budgeted.
With agile development, there is constant reappraisal of both the requirements and the scope of the solution, which allows the budget and quality to remain fixed; it is almost guaranteed that a working system can be delivered within the timescale and budget originally agreed — it’s just not possible to say at the outset exactly what the system will do! On first consideration this may sound a mistake, but in fact it addresses two of the most common causes of failure in IT systems development, namely the failure to accommodate change and to manage risk.
In an agile project, working software is delivered very early in the process; it is then reviewed by users, extended by developers and tested by quality assurance specialists on a repetitive basis (usually in one month cycles) until the end of the project. Progress is measured by the number of features completed to the satisfaction of users, not by ticking off tasks on a project plan. Customer and supplier share all the same information about the project on a continuous basis; which features are on the backlog to be developed; which are currently being implemented; how quickly features are completed; whether the software builds successfully and can be run by a user; how many tests have been run (usually on a continuous, daily basis with the latest build of the software); how many defects there are. This process fosters a genuine understanding from all parties of the challenges faced in any software development project. It allows users to change their minds about what they need, and developers to learn new ways of meeting those needs.
The use of agile implementation processes, aided by open source toolkits that help users to define data sets, input forms, care pathways, customised reports and views, can also break the dependence of healthcare providers on external systems integrators. There are many examples of locally developed, clinician led systems which have successfully met local needs. What many of these systems have lacked is the means to transfer to other specialties or care providers, to integrate with other healthcare systems or national services and to be maintained as part of the mainstream IT infrastructure once the original developers have moved on. By using the principles of Open Health Informatics, this type of clinician-led development could start to deliver a next generation of more effective and sustainable clinical information systems.
