Medical software manufacturers must meet the legal 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.
1. What software components / items are
There are different definitions of “software component”, also referred to as software items as defined by IEC 62304:
a) Definition
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.
b) Examples
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.
- A logical software component would be, for example, a package or a web assembly. UML classes and UML component diagrams model logical components.
- On the other hand, physical software components are parts of software that are recognizable as files, such as .dll, .exe, HEX, or script files.
2. Regulatory requirements
a) Europe
MDR, IVDR
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.
IEC 62304
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
- decompose the software items into software units (Chapter 5.4),
- specify the interfaces of these items,
- review whether the software items behave as specified,
- integrate the software items piece by piece and test their interaction (Chapter 5.7; integration tests).
b) USA
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
- a software architecture with a “modular structure,”
- the “unit (module or component) level testing” and
- the special handling of off-the-shelf components. It has published further guidelines on this subject.
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“).
3. Seven tips for practice
Tip 1: Determine real software components
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.”
Tip 2: Determine component according to functional considerations
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.
Tip 3: Define the interfaces early and precisely
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.
Tip 4: Use tools for defining and testing interfaces
Describe the interfaces as API. For web-based applications, tools such as OpenAPI, the successor to Swagger API, are helpful.
Tip 5: Ensure good encapsulation
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.
What helps
You can achieve weak coupling of components by
- making only a few methods and variables of this component public,
- minimizing the number of passing parameters of methods,
- avoiding inheritance across components boundaries, and
- abstracting methods by interfaces.
What harms in the process
The following procedures are harmful:
- Using the keyword “public” as often as possible for classes, methods, and functions (after all, everyone should be able to access the great functions 😉)
- Designing methods with as many passing parameters as possible
- Defining many global variables in order to be able to access from everywhere these values
- Defining inheritance relationships across component boundaries
- Throwing errors across component boundaries
Tip 6: Use existing components
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.
Tip 7: Test components automatically
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.
4. Summary and conclusion
The regulatory requirements for handling software components / items are relatively homogeneous worldwide. Professional software development will meet these requirements. This requires that the manufacturers
- define the software architecture early and precisely,
- identify the components and specify their interfaces, and
- ensure with software tests that the components meet this interface specification.
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.
