Develop software components compliant with IEC 62304 and FDA

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.

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:

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:

• Use the keyword "public" as often as possible for classes, methods, and functions (after all, everyone should be able to access the great functions ;) )
• Design methods with as many passing parameters as possible
• Define many global variables in order to be able to access from everywhere these values
• Define inheritance relationships across component boundaries
• Throw 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.