Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

Software release vs design transfer

A recurring question is the confusion, or more precisely the difference between software release of IEC 62304, and design transfer of ISO 13485.

A short answer is that design transfer happens after a release, but releases don't need to be attached to design transfer.
When a software development team releases a release candidate (RC) version or an alpha or a beta version (choose your nomenclature, I prefer RC), we're still in design. The product isn't validated yet.

release-and-design-transfer-embedded-sw.png, May 2020

This is quite straightforward for embedded systems: the steps can be easily separated. The software is delivered to the system team for system-level tasks like integration or validation. During these tasks, additional releases may be delivered by the software team, to fix integration or functional bugs. Likewise, releases may be delivered during clinical investigations, with a very constrained change protocol, though. release-design-transfer-place-market.png, May 2020

After the final release, the design is frozen and is transferred to industrialization. When industrialization processes are validated and the product is cleared by regulatory authorities, the product is placed on the market.

For software as a medical device (SaMD), releases are prone to be more frequent, as there is not a hardware specific to the device. Since there is no industrialisation step of a prototype, like methods for machining, the release and the design transfer can be merged into a single step.
Thus, the final software release and the design transfer can be performed at once during a single review. SaMD-release-design-transfer-place-market.png, May 2020

Likewise, the software deployment before placing it on the market can be a very short task, like uploading the installation bundle on the public server.

However, this is possible for small scale software system. For large-scale software system, the hardware system level can be replaced by a software system level, made of subsystems. Multiple releases of subsystems can happen before the final integration and validation of the whole system. For example, a subcontractor can deliver the release of their subsystem, before the integration and final release of the whole system.
The final release is dissociated from the design transfer, usually to complete the software documentation, like IFU's and supporting documents. big-system-release.png, May 2020

Another case where the design transfer can be dissociated from a release for SaMD is when that software is installed in the cloud. The SaMD can be released and tested on a pre-production or staging platform. Then the design transfer happens when the system is deployed to the production platform. (Note that when the software is in production in the cloud, is has to be validated according to 4.1.6 of ISO 13485). release-design-transfer-cloud.png, May 2020

To sum up, it's possible to merge final release with design transfer for small scale projects. For large scale projects, intermediate tasks require to dissociate the final release from the design transfer.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed