• The EU has drastically tightened the requirements for the development of medical software. A VDE guide shows what is really important.

• Matthias Wufka from Zühlke was the author of the chapter on the development of medical software from the idea to the final product.

• The core aspects of medical software development are summarised in this article.

The EU has drastically tightened the requirements for the development of medical software. This is not a reason to panic, however – a guide shows what really matters. I have summarised the most important things here.

Digitalisation does not stop at the healthcare system – with all its opportunities, risks and challenges. As a result, software in this area is also becoming increasingly important. From a regulatory perspective, an essential distinction can be made between "embedded" software and "stand-alone" software. The former is an integral part of a medical product; the latter is itself a medical product, e.g. a medical App. Only recently, the European legislator drastically tightened the requirements for medical products. There are therefore fears that small and medium-sized manufacturing companies in particular will no longer be able to meet these requirements.

This is where the recently released second publication from the German Society for Biomedical Engineering (German: DGBMT) in the field of "Standards in Medical Technology" comes in handy. It deals with the development and production of medical software and is intended to provide small and medium-sized companies in particular with guidelines for implementing the requirements.

Knowing that Zühlke had extensive experience in this area, VDE approached me to ask if I would co-author the chapter on the development of medical software, from the idea to the product. The result is an overview of the modern principles of agile software development under the general requirements for the regulated development of a medical product.

The standards in the field of medical technology place high demands on the development process. The most important ones for App development are, in my opinion, the following:

• Planning of activities prior to implementation
  Applicable to medical products is the requirement for a regulated and planned procedure that satisfies all aspects of the standards. All activities must be planned prior to implementation, and this planning must be documented.
• The level of detail depends on the software's contribution to safety
  Risk management and the resulting patient risk are a central component in determining the level of detail and intensity of activities.
• Design input before design output
  Design input is required before activities are performed or design output such as source code is generated. Or a bit less formally: Without the requirements defining what is to be developed, we can neither write source code nor verify a program
• Change Management
  A released configuration element (e.g. a documentation or a source code) may only be modified after a previously released change request. The history of all configuration elements concerned must be traceable up to the current status.
• Compulsory documentation
  One of the principles in the development of medical products is that planning, implementation and results must be documented. Short and concise: "Fully functioning and tested software without documentation is worthless."

The example of documentation makes it clear that standards in medical technology not only stipulate requirements, but also allow certain degrees of freedom. In principle, consistent documentation must always be available at the end of the regulated development of a software product. In most cases, a graphic representation in the style of the V-Model is used here.
 

On the left-hand side of the V, the requirements are listed in detail and implemented – from the intended purpose via the specification of the overall system to the design specification. On the right-hand side, corresponding test cases are contrasted with the specifications, thus ensuring compliance with the requirements. The accompanying risk-management and usability processes lead to requirements and verifications at the various levels of detail.

From this presentation, readers often draw the wrong conclusion that the V-Model or waterfall-like processes are prescribed as development processes. At the same time, a great deal of freedom for the development process is allowed by the standards in medical technology, which also meet the modern requirements for software development. Neither EN 62304 nor the FDA prescribes a life-cycle model; on the contrary, EN 62304 names the agile development process as a possible approach.

Freedoms such as these continue to make it possible for small and medium-sized companies to develop medical software. Only the demands on the know-how and organisation have increased.

We would be happy to develop software solutions for medical applications for you – from the idea to the final product! Please contact me about this by email