Open-source software is no longer a niche topic in the healthcare and life sciences sectors. Against the backdrop of the digital transformation of the healthcare system, the expansion of telematics infrastructure, the European Health Data Space (EHDS), and increasing regulation regarding data protection and IT security requirements (including the GDPR, NIS 2 Directive and its implementing legislation, KRITIS), ensuring the legally compliant implementation of open-source software is becoming increasingly important.
The use of open-source software generally offers many advantages. Despite the increased effort required in specific application areas, it is more cost-effective than comparable proprietary solutions. Open-source software can generally be freely configured. It is also typically designed to minimize data usage or, at any rate, can be configured accordingly. The free availability of the source code also enables a particularly high degree of transparency.
Nevertheless, there are several pitfalls that must be taken into account when using open-source software in the healthcare and life sciences sectors.
1. Compliance with Open-Source License Terms
Failure to comply with open-source license terms can lead to legal and economic risks. Thus, the general principle applies in the healthcare and life sciences sectors as well: violations may result in the automatic revocation of the license. Rights holders can demand injunctive relief - including a sales ban or a recall of delivered hardware (e.g., telemedicine devices with embedded software). Further information on risk profiles and liability scenarios in the event of non-compliance can be found here.
2. Establishing Governance Structures
Without clear internal company guidelines, open-source software components are sometimes integrated spontaneously by IT or business departments (“shadow IT” in research projects, pilot programs, and proof-of-concepts), making it impossible to obtain a complete overview of the software in use. However, open-source libraries are also regularly used in proprietary healthcare IT products and software solutions without this being fully disclosed to customers. Therefore, a holistic open-source corporate governance framework is required, one that treats the management of third-party software as an integral part of the company’s own compliance organization. Further information on open-source corporate governance can be found here.
3. Data Protection Liability for Ensuring an Enhanced Level of Protection
When software is used in the healthcare sector, health data - which is subject to special protection - is typically processed. The technical and organizational measures in place must ensure a level of protection commensurate with the increased potential for harm. In the case of open-source software, the data controller has a special obligation to conduct actual security assessments. Relying solely on the manufacturer’s specifications is not sufficient. Open-source projects must, for example, be capable of implementing encryption, rights management, and logging. From an organizational perspective, security updates must be ensured to maintain the level of protection.
4. Security Vulnerabilities and Update Management
The fact that the source code of open-source software is freely available does not automatically mean that its use is secure. While widely used open-source projects are subject to close monitoring by security solution operators and have a large user base - and security vulnerabilities are often detected early and corresponding updates released - the freely available code base also means that these vulnerabilities are exposed to everyone. Updates must therefore be installed promptly. This requires update management, which is sometimes neglected.
Especially in older medical systems, outdated open-source components can be found for which security updates are available but have not been installed. Such inadequately maintained open-source components with known vulnerabilities can serve as a gateway for attackers. Unlike proprietary software solutions, the responsibility for update processes in open-source software often lies more heavily with the user. Both KRITIS and NIS2 require structured vulnerability management in this regard.
5. Increased Certification Effort
Unlike operators of commercial software solutions, open-source projects typically do not follow a business model geared toward meeting specific regulatory requirements for users. Consequently, open-source components usually do not come with certificates, test reports, or CE declarations of conformity, as is customary with commercial software solutions.
The responsibility for meeting regulatory requirements thus lies with the user of the open-source-based software solution. The user must independently verify whether the open-source components used comply with the relevant regulatory requirements. In some cases, additional technical and organizational measures must be implemented to meet the necessary standards. In addition, the user may need to seek the necessary certifications, which involves additional effort.
6. Conclusion
Due to the sensitivity of the data being processed and the more stringent regulatory requirements, open-source compliance is of particular importance in the healthcare and life sciences sectors.
Our recommendations are therefore as follows:
- Establish an interdisciplinary governance structure.
- Integrate open-source components into your existing patch and vulnerability management processes.
- Use tools for the automated detection of outdated components and known vulnerabilities and weaknesses; document response and remediation times.
Regularly raise awareness and train your development teams on licensing obligations and security requirements (Security by Design, Compliance by Design).
Taylor Wessing supports clients with combined expertise in IT law, IP strategy, and technical knowledge to ensure that innovations are legally compliant and sustainable.
