Medical software manufacturers must meet the statutory requirements for software components in order to "approve" their devices.
This article presents these requirements and gives seven tips on how to fulfill them quickly and easily.
There are different definitions of “software component”, also referred to as software items as defined by IEC 62304:
IEC 62304 defines the term software item as follows:
any identifiable part of a computer program
Thus, software items include all parts of the software, both the software system itself and all software units (see Fig. 1).
The term software component is usually used synonymously with software item, with the exception of “software system” that is a software item, but not a software component.
Software items / components also are called software modules, a term used by the MDCG 2019-11 guideline. SOUP are also software components because they are also identifiable parts of a software system.
IEC 62304 does not define whether the software items are logical and physical components.
EU regulations such as MDR and IVDR do not impose explicit requirements on software components. But they do require a software architecture. By definition, a software architecture is the decomposition of a software system into components respectively items.
The harmonized standard IEC 62304 also requires decomposition into software items.
It places further requirements on SOUPs. In addition, the standard obligates the manufacturers to
The FDA formulates its requirements for software primarily in its General Principles of Software Validation. It does not distinguish between the terms unit, component, and module. It does, however, require from manufacturers
The guidance document Content of the Premarket Submission specifies which documents manufacturers must submit. In it, the FDA also specifies the software architecture (e.g., "detailed diagrams of the modules").
An item is a logical or physical entity. It is not enough to paint a frame around an arbitrary selection of classes in PowerPoint and call this a "component."
Once you have the software requirements, you can start grouping these requirements by functional aspects. This helps to form the components also according to functional considerations. A component should perform exactly one task.
Determine the architecture and, thus, the software components and their interfaces at an early stage of development. Only then will it be possible to allow different teams to work in parallel.
Microservices are one example of components. With these, different development teams even benefit from different technologies and programming languages when they program against the specified interfaces.
Describe the interfaces as API. For web-based applications, tools such as OpenAPI, the successor to Swagger API, are helpful.
Software components should encapsulate functionalities and make them available only via well-defined interfaces. The weaker software components depend on each other ("weak coupling"), the better the software is to maintain and test.
You can achieve weak coupling of components by
The following procedures are harmful:
The fastest way to make a software component available is not to develop it in the first place. It is, therefore, helpful to reuse already proven components such as libraries and other SOUP/OTS.
Manufacturers who can fall back on proven components, frameworks, or platforms for different medical devices are faster in development.
In extreme cases, manufacturers pursue a test-driven development approach. At the very least, they should test all interfaces of all software components automatically from the beginning and repeat these tests as regression tests for all changes.
The regulatory requirements for handling software components / items are relatively homogeneous worldwide. Professional software development will meet these requirements. This requires that the manufacturers
Actually, no witchcraft. But the practice reflects the tangles in development and compromises in excellence. This should not be the case because professional development is not only efficient: it leads to software of a high quality and thus to safer medical devices.
The Johner Institute supports you in creating lean and standard-compliant software files and bringing your medical devices to market quickly and safely.
With the Medical Device University, you will learn how to create a lean and IEC-62304-compliant "software file" step by step through video training. A complete set of templates additionally relieves you of a lot of work.