Originally posted here.
Medical Devices are utilising software more than ever before. For most, it’s not something that comes into their minds. However for those involved within software will be wondering where it has been sourced, how was it chosen? Similar in an instance to a car enthusiast buying a car but not being told what is under the hood. Previously I had reported on how Software issues are the primary reason for Medical Device recalls for 14 consecutive quarters and likely to continue to grow.
Recent challenges from COVID-19 have outlined some of the great benefits of utilising open source within the Medical industry. Medtronic has made their ventilator design open source to support the current shortage that has emerged. With the current ventilator shortage, hospitals still have the issue of getting the systems repaired from the OEM due to the system plans not being available. This adds further delays and costs during a demanding period.
The premise behind Open Source Software (OSS) is being readily available for the benefit of larger groups of people, usually at a lower cost, if not free. The positive motives of open-source transfers across to the Medical industry with many engineers being interested to potentially contribute to the benefit of people’s health.
Leading companies across other industries are now making use of OSS projects and collaborations. The TODO Group is a group of companies open for collaboration on open source and features many of the tech’s leading companies such as Google, AWS, Microsoft, Facebook, Bloomberg, Samsung and many more. With the tight requirements and regulations for Medical Devices to be placed onto the market, would it make sense to have an Open Source Software group with some of the key pioneers of the Medical industry similar to The TODO Group?
I take a look at the benefits Open Source Software and projects could bring to the industry, as well as potential drawbacks of implementing an open-source initiative:
Looking at various industries such as tech and automotive; industry-leading companies are collaborating on open source projects for the mutual progression of systems in the industry. Tesla has made a pledge to make their work open source for the benefit of the development of sustainable transport, for example. Would it take a new Elon Musk-type of an entrepreneur (or maybe Elon himself), to inject a disruptive change for the greater benefit of the Medical industry and worldwide healthcare also?
With many engineers working on software developments, updates are frequent and consistent. OSS offers the opportunity for plenty of customisation, rather than being limited to the realms of what a proprietary provider has allowed to be modified. An OS like Linux provides greater customisation for a system e.g. Yocto.
In a study from Nature, more than 70% of researchers have tried and failed to reproduce another scientist’s experiments, and more than half have failed to reproduce their own experiments. One of the main causes for this being that there is a distinct lack of availability of the data, source code used and more.
Are we severely slowing down innovation within the Medical Industry by not making data more accessible?
Large scale medical devices are costly machines to purchase and maintain. Consider a snowball effect: with the reduction in development costs which OSS offers, this will reduce overall costs of system development, making them more affordable for healthcare establishments and can be reflected upon the cost of private treatments for individuals.
However, with the structure of the Medical Devices industry requiring far greater regulation in comparison to other industries, there remains the potential for costs to remain high due to the extra investment required for approval of new innovative solutions. This does remain a very profitable industry also, would the initial changes with no short-term profit potential be of any interest for large companies?
By uniting the efforts of collaborators from around the world in an open-source approach, we will create a unique pool of knowledge that will help advance the field. Our efforts may provide a model for other communities interested in giving greater global access to medical technologies by decreasing costs of development and maintenance.
In the instance of a global pandemic outbreak, we would be much better equipped to fight against the outbreak. The use of open-source projects to help the current battle against COVID-19 for the likes of ventilators, PPE and other devices has already presented its great benefits in this scenario. What if these resources were already in place from the start?
Having access to an array of Medical technology is perhaps something we can take for granted in today’s world. Yet for millions around the world, healthcare is not available, adequate, accessible, appropriate and affordable (the five A’s). A big effort of open source communities is to make software (and hardware) more available to those who do not have access to it normally.
All medical devices are required to meet the same quality standards. By utilising an open-source prototype, it gives a much easier platform to build a design from. The question of quality from not knowing who has developed parts of a system is removed as it will be required to meet these stringent standards before being released, avoiding poor coding ‘from anyone’ to be put on to the market.
The availability of code for developing particular parts of medical system software would encourage engineers to be more involved in the medical industry, promoting greater talent within the sector. As mentioned previously, the medical industry has a positive cause which gives it a certain allure over the tech sector.
The tools available on Linux would allow for greater customisation on Medical Devices, and any other system for that matter. As of last year, the ELISA group was formed under The Linux Foundation: "ELISA will make it easier for companies to build safety-critical systems such as robotic devices, medical devices, smart factories, transportation systems and autonomous driving using Linux".
It recently came to light that 70% of medical devices will be running outdated versions of Windows. A large number of devices on Windows were suspect to the Bluekeep exploit. 83% of medical imaging devices are running on unsupported operating systems, due to the end of support for Windows 7. The transition of OS and more frequent updates are more available with OSS variations. The level of updates going toward a platform like Linux makes it much more future proof, with no worries of an OS going end of life and much fewer pains in looking to migrate OS.
The WannaCry ransomware attack back in May 2017, which hit more than 300,000 machines in 150 countries, targeted Windows operating systems and succeeded where those operating systems lacked security updates. According to data from Kaspersky Lab, roughly 98% of computers affected by the ransomware were running some version of Windows 7. Whether this is due to them having more exploits in its software or purely the fact that Windows is more prevalent in the NHS is not clear.
HIPAA calculated the average resolution cost per capita/per personal health information (PHI) record in healthcare in 2018 at $408.3 This puts the average cost of containment, investigation, disclosure and notification at $7.3 million per breach. Such breaches are incredibly costly to companies and public organisations, making it of extra importance (besides the fact they are leaking patient confidential data!). Could this be substantially reduced with incorporation of OSS?
Greater visibility on the code will allow for easier checking of bugs/errors. All modifications made to code will be submitted for approval to a central group, so changes will be audited. In the scenario we can get create a collaborative group of the top Medical companies, there will be eyes on the code from the top engineers across the industry, rather than one specific company who isn't specialised with Medical Device compliance.
Linux is a prime example of OSS, Linux is currently being used to an extent within the Medical industry, it is the most used Operating System with over 850,000 Android phones activated every single day and nearly 700,000 TVs sold every day, most of which are running a variation of Linux. Eight out of ten financial trades are powered by Linux. Nine out of ten of the world’s supercomputers run Linux.
It comes down to individual preference, however, Linux is generally preferred by programmers due to it supporting all main programming languages (C++, Python, Java). Many engineers begin learning through Linux, for continuity it may well be preferred for their work to continue using what they are most familiar with for their day to day projects.
Licensing & Compliance
With open source licensing, they allow for the inclusion of OSS on your system, without harming your own IP rights. The Open Chain Project “defines the key requirements of a quality open source compliance program” and features companies like Microsoft, ARM, Siemens, Sony, Fujitsu, Qualcomm and many other world-leading companies. If something similar were to be developed for the Medical Devices industry, could it potentially save much of the quality assessment time in the development life-cycle and significantly reduce the number of FDA Medical Device recalls?
Will having an open-source cybersecurity group for the industry help reduce the level of software issues that have been growing year on year? Companies would be required to use a proprietary open-source provider or much of the compliance checks would fall on their own responsibility.
Disadvantages and Considerations
This isn't a privately funded health documentary on Netflix, so I'm going to actually look at both sides of the argument:
Within such a heavily regulated industry, incorporation of open-source software in companies adds a whole host of new paperwork and headaches to even have it incorporated, it may be classed as Software Of an Unknown Pedigree (SOUP). Who is liable if there was an instance of software failures? Each piece of software must have all the required documentation and be frequently updated to meet regulatory frameworks.
There would need to be enough support and momentum behind a project to satisfy IEC 62304, in which there must be a clear software lifecycle development plan. With comprehensive security documentation (rightly so). Gaining initial traction would take time and cost money before seeing any kind of end product. Would companies be willing to put resources into that? Due to the nature of the adoption in the industry, much of the onus of testing and quality checks is still on the individual companies to do. It will also be required for individuals to monitor updates & releases, this is where having a nominated central body to do this initial work would be of benefit but who covers the cost of that?
Development of Linux within safety-critical, real-time applications is still relatively young and thus may not be suitable for Class III Medical Devices. Although the ELISA group could be a step in the right direction for this.
Medical Devices industry is still a profitable market. The potential benefits of creating new initiatives, lowering costs for patients or improving the quality of systems doesn't provide a short-term monetary value for companies. Open source doesn't equal free in all instances. Linux distros are still managed and charge for their support. The cost-saving may not be enough motivation for change despite the other potential benefits. Of course, making the transition from proprietary providers will also take a period of time to adjust and affect current production. Encouraging companies to do this together in order to collaborate on new industry initiatives would take years, dollars and potentially some market disruptions (besides a global pandemic) before the value is seen.
As I will show some examples below, open-source software development is already prevalent in the industry, along with the use of Linux as an OS for many devices. With all the potential benefits OSS provides, adoption in the Medical Devices industry will likely be slowed down by regulatory concerns.
There is potential for a collaborative group to be formed among the leading Medical Device companies to develop basic frameworks for particular systems and work on developing initiatives to progress the industry. The employees within the industry are the most passionate about their field that you will find and the potential to benefit the development of Healthcare I could envision gaining widespread interest, attract some great engineers from other industries and also encourage graduates to look at the industry with more open-source projects available.
Codethink are experts with open source technologies. Codethink continues to support industry-leading companies in the development and usage of open source initiatives for system-level software development, build and integration projects.
Medical Open Source Software Projects
For those interested, below are some active Open Source software Medical projects:
OpenAPS - The Open Artificial Pancreas System project (#OpenAPS) is an open and transparent effort to make safe and effective basic Artificial Pancreas System (APS) technology widely available to more quickly improve and save as many lives as possible and reduce the burden of Type 1 diabetes.
Open Source Imaging — The project will pool the knowledge and experience of many experts in open-source designs for Magnetic Resonance Imaging devices (MRI) which can be built and maintained for a fraction of the price of current instruments.
OpenEMR — Electronic health records and medical practice management application. It is ONC Certified and it features fully integrated electronic health records, practice management, scheduling, electronic billing, free support, a vibrant community, and a whole lot more.
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Cycling around the world
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- Getting into open source
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Codethink creates custom USB 3 switch to support customer's CI/CD pipeline requirements
- Codethink unlocks data analysis potential for British Cycling
- MIT Doctor delivers Manchester masterclass on innovative safety methodology
- Balance for Better: Women in Technology Codethink Interviews
- Introducing BuildGrid
- Full archive