Good practices for Medical Software development environment setup. Part 1/5: Basics

Mai 18, 2022

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

Software innovation often starts with the writing of a significant number of lines of code to test the feasibility of an idea. Code clarity, structure and testing may not be perceived as priorities in this phase. Once first positive results are obtained it is easy to fall into a loop where more and more code and features are added but no significant effort is put on the code clarity, maintainability, and robustness. This can easily result in a chaotic situation where it becomes very hard for a developer to update or even just fix a piece of code written by someone else or even worse written by themselves some months ago.

The more developers you have the higher the challenge to ensure good productivity. To allow your company to follow a fast innovation track, you need to start as soon as possible with good practices and collaborative software development culture.

In this publication, Debiotech experts will describe what they perceive as the essential tools and practices in software development in general, and for medical software development specifically.

Good practices

Source code management platform

Basic code repository management

The source code management platform is the cornerstone of your development environment. It is the basic tool for any developer even for single individual teams. It allows you and your team to share and manage the different versions of your source code. Finally, it ensures a decentralized backup to avoid the loss of long hours of work in case of destruction or inaccessibility of your local data.

Multiple platforms exist, including:

  • Git
  • SVN
  • Mercurial

Figure 1. Illustration of basic source code management platform item & features

Basic items are available within those platforms, including:

  • Repositories: they are the basic containers of your source code and contain a collection of files of different versions of a project.
  • Branches: they are the main item allowing you to follow the different versions of your code. A branch is an evolving entity that changes through commits of code. Branches can be created and deleted; some will exist all along the lifecycle of your product. More details about branch types and structure are provided in the Chapter 1.3.
  • Tags: they allow to identify specific versions of your code. A tag is a static item associated to a given branch at a given point in time (and therefore to a specific commit). It allows to quickly find important versions of your code as for example: versions used for clinical trials and the ones used for your deployed product.

Basic actions are available within those platforms, including:

  • Basic actions associated to repositories:
    • Create: it creates from scratch the centralized repository to store the various branches of your code.
    • Fork: it creates a deep copy (complete and independent copy) of the centralized repository.
    • Clone: it creates a local copy of your centralized repository.
  • Basic actions associated to branches:
    • Checkout: to get a local copy of a given branch on your computer.
    • Create: It creates a branch from an original one and keeps track of its modifications independently from the ones of the original one.
    • Commit: to put local changes within the corresponding branch of the centralized repository.
    • Merge: to update the content of a target branch with the modifications performed on another branch. This does not copy and replace the target branch but only push the modifications performed on the merged branch. Therefore, those two branches can have evolved independently before the merging and the modifications brought on both branches will be combined. This can result in conflicts (if modifications are brought to the same piece of code). Conflicts resolving is not always straightforward but will not be developed further within this publication.
    • Pull request is described further in Chapter 1.2.
    • Other features are available but will not be described further in this publication.
  • Basic actions associated to tags:
    • Create tag: associate a specific commit with a tag that allows to quickly identify it and retrieve the associated content.
    • Get commit associated to a tag: get a local copy of the content associated to the commit to which the tag is associated.

Advanced code repository management tools

Some advanced solutions exist to help you and your team in the management of your source code repository and to create interfaces with other platform such as task/issue management systems (refer to Chapter 5.14) and continuous integration platforms. And finally, they provide user friendly code version comparison tools that allow to quickly identify differences between branches or commits.

Those advanced tools also give the possibility to define pre-requisites before validating a commit in a controlled branch (development branch) for example:

  • Pull request review and validation by different persons
  • Continuous integration tests all successful.

Figure 2. Pull request & Continuous integration principles illustration

Commonly used platforms include:

  • Github
  • Gitlab
  • Bitbucket

Debiotech recommends you to:

  • Integrate an issue management system to record features, user stories, epics and bugs (refer to Chapter 14)
  • Put in place peer reviews to review and approve pull requests.
  • Implement a continuous integration environment, including :
    • Static code analysis (refer to Chapters 12 & 5.13),
    • Automated tests, ideally including hardware in the loop for embedded systems (refer to Chapter 10).

Use of branch types and tags

During the development of your software multiple branches will be created. Each branch has a different purpose and different characteristics.:

  • You want to have branches that are stable and well tested for example for demonstration to your customers or investors.
  • Other branches should be opened and merged quickly to allow a developer to work on a new feature freely before adding it to a more controlled branch.
  • You will need dedicated branches that will correspond to your release candidates.
  • Some branches will be there to provide hot fix for an identified bug on a controlled branch.
  • Finally in the medical device industry you will also need a branch for fully tested (verification and validation) version that can be used for clinical studies or as products.

To identify the different versions of your product, use tags on your main branch (the branch with the highest level of control).

Debiotech recommends you to:

  • Define different branch types,
  • Adapt the automatic testing you perform on a branch depending on its type (no need to perform complete testing for commit on a new feature branch),
  • Clearly differentiate branches based on the level of control and security you want to have on their content.

Figure 3. Illustration of possible branch type structure

Define coding guidelines

For clarity, homogeneity, and ease of review, you must establish common rules for your own code, including:

  • Naming conventions for variables, functions, and files,
  • File and folder organization,
  • Format for comments,
  • Code indentation and formatting.

Coding guidelines are specific to programming languages and shall not be applied to external libraries. For the code developed by external partners, you should request them to respect the guidelines you established or review and validate their coding guidelines.  Debiotech recommends that you choose to apply the same coding guidelines for all projects in the same programming language. And perhaps a naming convention to be used regardless of programming language would be to include the unit information on all variables that contain physical units (distance, weight, pressure, temperature, speed, etc.).

Debiotech does not recommend any specific naming conventions but here is an example of a set of simple rules:

Name Convention
Class name Should start with uppercase letter and be a noun (e.g., String, Color, Button, System, Thread, etc.)
Interface name Should start with uppercase letter and include an adjective (e.g., Runnable, Remote, ActionListener, etc.)
Method name Should start with lowercase letter and include a verb (e.g., performAction (), main(), print(), etc.)
Variable name Should start with lowercase letter (e.g., firstName, orderNumber, etc.)
Package name Should be in lowercase letter (e.g., java, lang, sql, util, etc.)
Constant name Should be in uppercase letter (e.g., RED, YELLOW, MAX_PRIORITY, etc.)

Table 1. Simple illustration of naming convention

Setup automatic code formatting tools

Having a homogeneous format for your source code is a way to simplify the work of your developers and increase their productivity. They will be at ease with consistent formatting while heterogenous formatting will use some of their energy just because there is one space more or and additional empty line compared to what they are used to.

You can define simple formatting rules and ask everyone to follow them, but why wasting energy on this when automatic formatting solutions exist and are simple to integrate in your development environment:

  • Clang-format
  • Astyle
  • Uncrustify

Debiotech recommends you to:

  • Integrate such automatic formatting tools,
  • Run them automatically at every compiling request on modified files.

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
Download full publication
Back to news