S&T | Healthcare Driven by Open Source Software
IndraStra Open Journal Systems
IndraStra Global

S&T | Healthcare Driven by Open Source Software

By Martin Callinan
Director, Source Code Control Limited, U.K.

S&T | Healthcare Driven by Open Source Software

From relieving people of repetitive tasks, to building everything around us that shapes our lifestyle, and on to transformation of volumes of data into new insights and perspectives, software has become the new feed-stock for the human evolution.  All facets of life are touched by software, and healthcare is no exemption.  

The Complex Web of Health Industry  

The health and social care industry is a highly fragmented and complex industry with medical practitioners, nurses, health professionals, hospitals, clinics, government and non-government agencies all providing health services.  

The spectrum of health care providers range from individual clinicians such as General Practitioners (also known as GP or doctor) to large monolithic entities such as the National Health Service in the UK which is the third largest employer in the world today.  

Health and social care providers offer a complex and diverse range of facilities and services. By the nature of these services the healthcare industry is driven by large and varied amounts of data which in turn require varied and complex IT systems to manage this data. Generally, these systems come under the umbrella term of eHealth. While there is no consensus on the exact definition of eHealth two example definitions are:  

“…the cost-effective and secure use of information and communication technologies in support of the health  and  health-related  fields  including  healthcare,  health  surveillance  and  health  education, knowledge and research.” - The World Health Organization (WHO)  

“…the use of modern information and communication technologies to meet needs of citizens, patients,  healthcare professionals, healthcare providers, as well as policy makers.”-The European Commission  

Whatever way people choose to define eHealth it generally encompasses:  
  • Electronic Health Records (EHR)
  • Electronic Medical Records (EMR) 
  • Telehealth and telemedicine 
  • Health IT systems 
  • Consumer health IT data 
  • Virtual healthcare 
  • Mobile Health (mHealth) 
  • Big data systems used in digital health.
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.  


A  great  example  of  this  re-purposing  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 
  • 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-pre-approval 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) 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.  


There is a significant opportunity to advance the calibre 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.  

About the Author:

Martin Callinan – Director, Source Code Control Limited

Cite this Article:

Callinan, M "Healthcare Driven by Open Source Software",  SourceCode Control , May 27, 2015,  http://sourcecodecontrol.co/healthcare-driven-by-open-source-software/

SourceCode Control

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.