The goal of this publication is to help you in the setup of your medical software development environment. The earlier you start with good practices application the more value and time you will gain from it.

Targeted audience

The information gathered in this publication should be particularly useful for:

  • Head of Software Development Team,
  • Software Project Managers,
  • DevOps team,
  • Software developers.

Introduction

For introduction content, refer to the Part 1 previously published.

 

Good practices

Pointers and references management

To optimize memory size and time to pass parameters to one function or to an object, pointers and references are very useful. However, for critical code it is recommended (for example by MISRA guidelines) to avoid the use of dynamic memory allocation and therefore of pointers to dynamically allocated memory.

Therefore, Debiotech highly recommends to:

  • For critical code (e.g. Class C software components as defined in IEC 62304): use references and static memory allocation instead of dynamic memory allocation.
  • For non-critical code: use smart pointers to help your developers in the optimization of allocated memory but use references to pass inputs to functions or objects.

Exceptions and errors management

When creating a new object or function, the developer usually has in mind what values and behaviors are expected. It may seem so obvious that no control is done during code execution. However, another developer might modify the code or create new code that will take an unexpected path and result in non-expected code execution, potentially leading to software crash. In a way, it is the ideal scenario as this crash will push you to identify the root cause and fix it. In the worst case this unexpected behavior is not perceived and results in inaccurate performances that might endanger patients. Integrating simple exceptions and errors throwing mechanism is a way to avoid those unexpected behaviors and to help efficiently the developer to identify what’s wrong. However, it is common in medical software development to forbid the use of exceptions to minimize complexity, awkwardness, and performance overhead.

Debiotech recommends to:

  • Develop control mechanisms and propagate the information through errors.
  • Associate errors with clear messages allowing to quickly identify their origin.
  • Test your errors in your unit test and ensure 100% test coverage.

Use of event logging

To ensure traceability of software and hardware events, it is a common practice to use event logging. It provides a standard and centralized way for applications and operating systems to record important software and hardware events. The event logging service records events from various sources, components or objects and stores them in a single file: the log file.

Debiotech recommends to:

  • Define different types of events to be logged ( Debug, Warning, Error)
  • For each component and for the different branch types log only the level of events that is meaningful for this specific branch type.

User input validation & sanitization

Input sanitization is a cybersecurity measure of checking, cleaning, and filtering data inputs from users, APIs, and web services of any unwanted characters and strings to prevent unexpected behavior, crash or even injection of harmful codes into the system.

Debiotech recommends to:

  • Develop simple mechanisms to check data inputs validity: check length, characters, string, and values.
  • Block data inputs when invalid content is identified or filter out the unexpected content and throw an exception to keep track of this event.

User of compiler warnings and errors

Congratulations, after adding an important feature or additional external libraries, you finally get to the point where you have no more compilation error! Don’t stop fighting and remove now all compilation warnings. They are usually the sign that you do not have full control on your code cleanness, reliability, and robustness.

Some of those warnings might look acceptable but having a warning free source code is the only way to quickly identify new warnings that will block you further in the development. If you already have 10 compilation warnings, having an additional one might be perceived as a minor issue. While if you introduce compilation warnings in a warning free code, you will quickly see them and process them.

Debiotech recommends to:

  • Do not mask compiler warnings,
  • Fix compiler warnings.

Applicable regulatory landscape

This publication does not aim at answering completely to a specific standard or regulation but provide recommendations on multiple aspects that should be established early on in your development to ensure the efficiency of your team. However, it covers directly or indirectly multiple requirements from following standards and regulations:

  • Europe: MDR
  • US: CFR Title 21 Part 820,
  • International: ISO 13485, IEC 62304, UL-2900-1/2

Authors

Rémi Charrier
Business Development Director
r.charrier@debiotech.com

João Budzinski
R&D Director
j.budzinski@debiotech.com

Laurent Colloud
Software Project Manager
l.colloud@debiotech.com

Gilles Forconi
Software Quality Manager
g.forconi@debiotech.com

Next steps

Debiotech is glad to have the opportunity to share its knowledge with innovative companies from the MedTech industry. Your feedbacks on this publication are welcome and will be used to update it or to create new publications on topics you care about.

Continue your education on medical device development by:

Debiotech would be proud to be your partner and support you with:

  • Medical device design & development services:
    • Software: Digital Health, Firmware, Embedded, SaMD
    • Electronics: Design, Verification and Validation
    • Mechanics: Design for micro-fabrication & fluidics systems
    • Supply chain development and optimization
  • Support in medical innovation management:
    • Market analysis and segmentation
    • IP management
    • Business plan consolidation
    • Partnership development