Electronic Health Reporter

Guest post by Mahshad Koohgoli, CEO, Protecode, and Martin Callinan, director at Source Code Control.

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 feedstock for the human evolution. All facets of life are touched by software, and healthcare is no exception.

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 healthcare providers range from individual clinicians such as general practitioners 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 organizations have created platforms to manage these solutions fairly autonomously, both within individual organizations 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.

For one minute, let’s compare this approach to the automotive industry – 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.

Code4Health is 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. For example, the NHS has 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.

• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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).
• 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 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.

Mahshad Koohgoli has more than 25 years’ in the technology industry, with a specialty in technology start-up businesses, having successfully managed three companies from the ground up. Currently, Mahshad is the CEO of Protecode, a provider of open source license management solutions, headquartered in Canada. For more information, visit www.protecode.com.

Martin Callinan has more than 20 years’ experience in the software industry with a focus of software asset management, IT governance and risk avoidance. He is currently the director at Source Code Control. For more information, visit: www.sourcecodecontrol.co.