This article was drafted using Chat GPT 4 and then carefully edited and reviewed by the author.
The IEC 62304 standard requires medical device manufacturers to “transform the requirements for the medical device software into a documented architecture that describes the software’s structure and identifies the software items.”
The standard defines a Software Item to be “any identifiable part of a computer program or a collection of these items.”
When helping engineers document their device’s architecture (often for a 510(k)), we’re often asked: How Granular do our IEC 62304 software items need to be?
The granularity of software items depends on your project and approach to managing the software development process. Software items should be defined at a level where they can be managed, tested, and developed separately. This level of granularity can vary depending on the safety-risk and size of the software project, and there is no one-size-fits-all answer.
Here are some typical examples of granularity for software items:
- Modules: Software items can be defined at the module level, representing a cohesive set of related functionality. Modules often correspond to folders or directories in a project.
- Components: Software items can also be defined at the component level. Components are smaller units of software that perform a specific task or function. They are often part of a module, and their level of granularity can vary depending on the complexity of the task or function they perform.
- Libraries/packages: In some cases, software items can be defined as libraries or packages that provide specific functionality or utilities. These items can be developed, tested, and managed separately from the rest of the software system.
- Files: In some cases, software items can be defined at the individual file level. This level of granularity is more suitable for smaller projects or when there is a need for more detailed management and tracking of the software development process.
Defining software items too granularly (e.g., at the file or even function level) can be counterproductive, as it can lead to excessive overhead in managing and tracking the software development process. The key is to strike a balance between granularity and manageability. We more commonly see teams making their software items too granular, rather than not granular enough.
A key consideration with the software item decomposition, and the architectural design in general, is whether you can isolate safety risks originating from defects in one part of the device from other parts of the device. This is good old “modular design” that software engineers know and love. Often, if certain software items are lower risk or don’t include functionality related to the safety or effectiveness of the device, then you can consider them an “Other Functions” of the software and reduce your documentation and testing burden.
If you would like help putting together a 510(k) submission under a tight-deadline, we may be able to help! See our Fast 510(k) Service for more details.
