2. eHealth Software Complexity
Software complexity is increasing with no end in sight as today’s code becomes the foundation for
tomorrow’s more complex functionality. Historically, healthcare organisations have created platforms to
manage these solutions fairly autonomously, both within individual organisations and industry wide. Quite
often these systems were procured at significant expense from software vendors who lock them into
solutions that restrict innovation, stifle diversity and have little ability to be re-used.
In the past, developing all software internally was a point of pride for many organizations. Today, the
complexity of modern software, coupled with the pressures to release applications and products on
tight deadlines, has made delivering projects that rely exclusively on internal code development almost
impossible. Increasingly, organizations are turning to commercial third party code, code brought in from
outsourcers and contractors, and open source software (OSS) to accelerate development and reduce costs.
If this approach is compared to other industries such as the automotive industry where in the early days
of car manufacturing car models were largely custom made. In more recent times, automotive
manufacturers have developed “platforms”, commonly re-used across companies and continents. This
gives them the ability to re-use existing components and enables greater flexibility – a new model is no
longer a completely new design and as a result costs are significantly reduced.
The same approach is now being applied to eHealth systems and with the emergence of Open Source
Software there is a shift to adopt Open Systems, Open Platforms and Open Data. These solutions are
developed efficiently without licence restriction where the code can be shared and re-used across the
public and private healthcare industry.
Code4Health
A great example of this repurposing is an initiative launched recently by NHS England called
Code4Health.
Code4Health is a resource used by healthcare professionals and providers of services to deliver better
patient outcomes. It provides a platform for clinicians to come together with IT suppliers to identify and
experiment with the systems in their Trusts and develop new functionality and products or solutions
that they can potentially deploy.
“Our ambition for Code4Health is to educate clinical and administrative staff to develop their interest in
digital technology and stimulate a desire to engage more closely in the design, development and
delivery of systems and apps”.
Code4Health are currently piloting ‘App In a Day’ where individual clinicians are being trained and
encouraged to play an active role in the development of apps or even develop their own apps using
LiveCode.
Overtime, the goal of the NHS is to:
Create a market of viable Open Source solutions
Provide evidence of the value of Open Source software to the wider Health and Social Care
Community
Ensure by default all code created in the NHS is shared as part of a library of assets for re-use
3. Ensure a level playing field for Open Source commodity and infrastructure services
Achieve a self-sustaining eco-system of communities
Managing Open Source and Other Third Party Content
Clearly there are huge benefits to be gained from this approach but it is not without its risks. Along with
the advantages realized by using third party code, there are a few challenges that can arise. Governing
the quality, security, licensing and intellectual property (IP) ownership attributes are imperative in
avoiding risks and potential downstream costs of using third party software. Last year Community
Health Systems Inc. lost data related to 5.4 million patients which could end up costing the health
system between $75 and $150 million. This data breach leveraged the bug Heartbleed to access VPH
log-in credentials.
The process of managing third party content in a code base can be time-consuming and resource intensive,
and an understanding of the effort associated with this exercise is the first step in optimizing the process
and mitigating the costs. This highlights a need for a governance program to underpin Open Source
initiatives. Indeed the NHS have created a custodian model for Code4Health and will have “code
custodians” to manage the risks of OSS and make the adoption of OSS based solutions easier for less
technically proficient trusts.
A study of common practices deployed at software
organizations, concerning adoption of open source and other
third party software components, has revealed a pattern
consisting of a number of necessary as well as some
discretionary steps. Originally coined as Open Source Software
Adoption Process (OSSAP), this process is equally applicable to
any third party software that is deployed and used in a project
within any organization. Eight steps are identified in a
structured open source adoption process.
1) Establishing a software policy, identifying acceptable
attributes of a third party software, and highlighting remedial
actions that should be taken in case of a violation of the
policy. Typically, an “open source committee” consisting of
legal, technology, security and business stakeholders are
responsible for establishing and communicating the policy.
2) An optional software package pre-approval workflow process that allows technology teams to
request open source and other external packages to be approved for use on a certain project under certain
use-case scenarios. The package-preapproval process would allow the “software clearing house” in an
organization to open and assess the requests and grant or deny permission depending on how well the
requested package aligns with the policies established in step 1.
3) Establishing a baseline, or taking stock of the existing code in the organization. This is a necessary
step in all but the simplest cases and is performed using automated tools creating a detailed view of the
code that is already present in the software organization. This will produce a resulting map of
proprietary, commercial or open source components and their licensing, security, quality and supplier
attributes. Furthermore, the results obtained at the conclusion of this step are compared against the
established policies and components and can be blacklisted/whitelisted as a result for future projects.
4. 4) Assessment of all code delivered to the project by contractors and outsourcing suppliers against the
policies using automated tools, and extending the software inventory map that was established during the
baselining process of step 3.
5) Regular scanning and examination of the project code library. This can be done by scripting an
automated policy-based scanner to review the complete library for any changes at regular intervals, for
example, every weekend, and highlighting content that violates a policy component.
6) Optional real-time assessment of code as it is checked into the organization’s Source Control
Management (SCM) system against the policies, and taking appropriate action if a violation is detected.
This step ensures that the project repository contains only acceptable code.
7) An optional real-time automated scanner residing on the developer’s workstation. Similar to a virus
checker, the content that is downloaded from the web, brought in through, for example from a USB
memory card or simply assembled on the developer’s workstation is continually scanned against the
project policies. Any violations against the policy can be highlighted to the developer (and the
developer only), allowing for either quick remedy at the source or a comment to be inserted against the
offending code (e.g. “will be used for testing only”).
8) Final build assessment, usually through an automated process tied into the build (for example
Jenkins) process.
The purpose of steps 2-7 is that all the code that could potentially end up in a project is logged and
approved in that it satisfies the project IP, security and exportability policies. By the time the final
application is built at step 8, there will be no surprises if steps 2-7 are diligently followed.
Conclusion
There is a significant opportunity to advance the caliber of healthcare by applying intelligent software
solutions to electronic health records, delivery of consumer health information, and the provision of
mobile and virtual health services. Leveraging open source software and drawing on the associated groups
accelerates the identification and development of healthcare applications, creates a level playing field for
all ecosystem communities, and allows the sharing and re-use of efforts across a wide range of healthcare
domains and geographies. The distributed and crowd-based nature of the open source development can
be managed by applying a structured open source software adoption process that will ensure quality,
security and legal compliance to the re-use obligations inherent in any open source code.
List of Additional Resources
Code4Health |Code4Health is a programme managed by NHS England to enable the best use to be made of digital
tools and technology to deliver safe, high quality, efficient and compassionate care.
Apperta Foundation |The Apperta Foundation is a not-for-profit community interest company supported by
NHS England led by clinicians and social care professionals to promote open systems and standards for digital
health and social care.
