Medical Device Software Terms and Definitions – IEC 62304 & FDA (Part 2)
This article is part of our series on IEC 62304, focusing on understanding the standard and how to implement it properly in medical device software development.
Previous articles:
This is the second part of our look into the terms defined in IEC 62304. In this article, we’ll discuss the following concepts:
- ARCHITECTURE
- SOFTWARE DETAILED DESIGN
- SYSTEM & SOFTWARE SYSTEM
- SOUP/OTS
- TRACEABILITY
- PRODUCT LIFE-CYCLE
If you don’t yet have your own copy of IEC 62304, you can purchase it for a very reasonable price from www.evs.ee, the Estonian Centre of Standardisation and Accreditation.
(We recommend choosing the PDF multi-user license. It’s much easier to access and read without needing any extra software with copyright protection plugins.)
You can also find the official wording of most terms and definitions on the ISO website.
Understanding the Term Will Move You Forward
Throughout my consulting career, I’ve often encountered situations where teams aren’t aligned on the terminology used in the standards they follow. This usually leads to recurring discussions about whether internal SOPs actually comply with the norms, or whether the terms used in internal processes truly match those described in the standards.
It’s important to remember that all ISO and IEC standards have evolved over time; they weren’t created all at once. Because of that, you’ll naturally find some discrepancies between them. What matters more than chasing the “perfect” definition of a term is deciding how your organization will interpret it, documenting that interpretation, and applying it consistently.
Having clearly defined terms and definitions allows your organization to use them consistently across processes. It also makes it much easier to adapt or update them when needed, ensuring everyone speaks the same language and helping to avoid confusion during audits.
Below is the second set of terms and definitions that we at QMLogic use when helping clients develop their internal procedures. These are based not only on our experience with IEC 62304 process design, but also on our participation in numerous audits and our work on customer findings and CAPA remediation projects.
Architecture and Architectural Design in IEC 62304
The term Architecture is straightforward for many developers, and also the norm IEC 62304 doesn’t say much about it in the section Terms and Definitions. It just describes it as an Organizational structure of a system or component.
Despite its seeming simplicity, it causes a lot of trouble in organizations, mainly regarding traceability or connections to various activities associated with it.
When you read the norm IEC 62304 further, you will encounter this term in many places, and the defined requirements on architecture will reveal the true expected meaning. Furthermore, you will encounter that the norm distinguishes between Architecture and Architectural Design.
And without a proper understanding of this distinction, you might have difficulties complying with the norm.
Architectural Design
Architectural design is an activity. It’s what software architects, or developers in general, do regularly during specific stages of design and development. In contrast, the output of this activity is the Architecture itself.
Throughout the design and development process, you’ll reflect software requirements in the Architecture, define interfaces between software components, and identify SOUP/OTS components (see the next chapter) to integrate them into the overall software system.
All these steps are part of Software Design — the process of defining the software’s structure, components, and interfaces to meet the specified requirements.
Everything resulting from these activities is then documented as the Architecture.
Software Architecture
A common mistake — and a frequent source of struggle for development teams — is treating Software Architecture as nothing more than a graphical diagram. However, a picture alone cannot capture all the activities and outcomes of Architectural Design, as defined earlier.
IEC 62304, section 5.3.6, states that software architecture verification should be conducted and documented to ensure that all software requirements are properly reflected in the overall Architecture and that the overall architecture supports the interfaces between components. This level of verification simply isn’t possible based on a picture alone and would need a detailed picture.
Therefore, it’s best to think of Software Architecture as a living document, one that developers actively work with and update regularly.
This document should typically include:
- A graphical diagram showing the relationships between components
- A description explaining what the diagram represents
- A list of software items
- A list of external software components, also known as SOUP/OTS
- Defined architectural views and levels of detail
What do I mean by architectural view or level of detail?
It’s important to understand software architecture as a set of diagrams and descriptions, not just a single visualization. Each diagram can show a different level of detail depending on what it represents.
For example, one diagram might illustrate an interface to a hardware component, another could show how sensitive data is segregated in the database, and yet another might describe how communication is encrypted. Each of these diagrams addresses different requirements at the necessary level of detail.
At QMLogic, we are big fans of FDA guidance documents because they often provide clearer insight into regulatory expectations. We recommend reviewing the FDA guidance “Content of Premarket Submissions for Device Software Functions” (June 14, 2023), specifically Section E: System and Software Architecture Diagram.
Software Detail Design in IEC 62304
Once we understand that software architecture can exist at different levels of detail, it becomes easier to grasp another term from the standard — Software Detailed Design.
Although IEC 62304 doesn’t clearly define Software Design, Chapter 5.4, which focuses on this topic, shows that you can apply the same principles as with Software Architecture, just with more depth and precision. In other words, Software Detailed Design can be seen as a more detailed view of the architecture for a specific software component.
So, don’t get too caught up in trying to separate Software Architecture from Software Detailed Design strictly. They represent different levels of detail within the same concept, and it’s perfectly acceptable to describe both within a single document.
Further guidance can again be found in the “Content of Premarket Submissions for Device Software Functions” (June 14, 2023), where the FDA refers to this document as the SDS (Software Design Specification).
Figure 1: Software Design Specification as defined by the FDA
Maintain Software Detailed Design – FDA and Cybersecurity Implications
According to IEC 62304, a Software Detailed Design document is formally required only for Software Safety Class C systems (we discuss this topic further in our article “How to Start with the IEC 62304 Standard Implementation”). However, we strongly recommend maintaining such a document for several other important reasons.
First, the FDA may request this document during a premarket submission or an FDA inspection.
Second, IEC 62304 defines the required level of technical documentation primarily from a product safety perspective. But in today’s world of interconnected devices and cloud-based solutions, cybersecurity has become just as critical, and software design now plays a more significant role in cybersecurity than before.
Cybersecurity standards, such as IEC 81001-5-1, explicitly require software design activities like those described below in excerpts from the standard.
Figure 2: IEC 81001-5-1: Software architectural design
Figure 3: IEC 81001-5-1: Software design
Software System, System, and Solutions
The meaning of Software System is fairly straightforward; it refers to a collection of Software Items (see Part 1 of this series for the definition of “Item”).
However, it’s important to remember that IEC 62304 also defines a System. The standard describes it as a combination of interacting elements such as processes, hardware, software, and people.
While we can set aside processes and people for now, you should not overlook the hardware, data storage, cloud environment, or communication infrastructure associated with your software products.
From my experience, these interfaces tend to be more apparent to developers working on embedded software, but they are often overlooked in higher-level development of a stand-alone medical device software.
Why does this matter? Because the performance, availability, and security of your software product can all be influenced by the System it operates within. That’s why it’s important to consider the entire system, not just the software system, when performing testing, risk management, or cybersecurity activities.
You might also encounter the term Solution. This term isn’t formally defined in the norm and can be used in different ways. It may refer to the same concept as a System, to a collection of internally defined systems, or even to a group of different medical devices.
You’ll save yourself a lot of confusion and rework if you define internally what your organization means by a “Solution.”
SOUP/OTS in the Software Life Cycle
- SOUP stands for Software of Unknown Provenance
- OTS stands for Off-the-Shelf Software
There’s plenty of discussion online about whether SOUP and OTS are the same or different. To put it simply, no, there’s practically no difference for you in practice.
Both refer to software components that:
- Were not originally developed to be part of a medical device, and
- Lack complete technical documentation
The only subtle difference is that SOUP could, in theory, be software that was previously developed by your own organization, whereas OTS typically comes from an external source.
In reality, though, in 99.9% of cases, SOUP or OTS refers to external software integrated into your product, not something your team developed earlier. This distinction has very little practical impact on how you manage SOUP/OTS, except perhaps in cybersecurity, where internally developed (even undocumented) software might be considered more secure than a random library downloaded from the internet.
Examples of SOUP/OTS include:
- External libraries used in your software
- Operating systems
- Database systems
- Cloud solutions
- Backend or frontend development frameworks
In short, SOUP and OTS are software components, called “Software Items” in IEC 62304, that originate outside your organization.
Why Is That Important To Identify SOUP/OTS?
SOUP/OTS represents external software that your product depends on for safety, effectiveness, and security. That’s why it’s essential to identify these components and evaluate the risks associated with them.
You should ask yourself questions such as:
- Can I trust this piece of software?
- How can I minimize potential hazards related to it?
- What would happen if the SOUP/OTS stopped working?
- Is it fully compatible with our software system?
- Could it contain security vulnerabilities or even intentional backdoors?
Traceability and IEC 62304
The term Traceability is defined somewhat cryptically in the standard, and its interpretation and practical application aren’t always clear. IEC 62304 defines it as “the degree to which a relationship can be established between two or more products of the development process.”
Here, “products” don’t refer to your medical device itself, but rather to any deliverable, any output generated during your development activities. This includes design controls such as requirements, architecture, risk control measures, and other related documents.
In practice, this means you should have a logical system that connects your documents and the information within them, ensuring everything remains consistent and non-contradictory.
One common form of traceability used in most organizations is the linkage between requirements, risk control measures, design, and verification. In simple terms, it can look something like this:
Figure 4: Traceability in Design Controls
However, the definition of Traceability also mentions that it includes Architecture. This brings us back to the earlier chapters, where we discussed what Architecture actually means, and this understanding helps clarify how Traceability applies within the architecture itself.
As we’ve already said, Architecture is more than just a graphical diagram; it’s a comprehensive document that includes descriptions and may also contain links (traceability) to specific requirements.
Why is Traceability Helpful?
Having clear interconnections between requirements and architecture helps ensure that all specific needs, such as those related to interoperability or security, are properly reflected in the architectural design.
Let’s look at an example. Suppose there’s a requirement for encrypted data exchange over Bluetooth between a peripheral IoT device and a mobile application.
This requirement should be visible within the software architecture:
- The architecture should reflect the peripheral IoT device.
- The data exchange between the peripheral IoT and the mobile app should be illustrated.
- The encryption requirement should be mentioned in the architecture.
- The implemented solution should be described, including details about the pairing and encryption behavior.
With this kind of traceable setup, if your manager, an external auditor, or an FDA investigator asks how data is exchanged between the peripheral device and the mobile device, you’ll be able to present a complete, transparent, and traceable picture.
Product Life-Cycle
Although the standard itself includes life cycle in its title, we’re only now arriving at this term.
While IEC 62304 provides a clear definition of the Software Development Life Cycle Model, it’s equally important to understand the broader concept of the Product Life Cycle.
Many companies tend to associate the Product Life Cycle mainly with design and development activities.
In reality, though, the product life cycle encompasses the entire lifespan of a medical product, from its initial concept all the way to its end of life. This broader perspective is especially important for software, where maintainability plays a central and ongoing role.
Why Does the Product Life-Cycle Matter?
The environment surrounding medical device software is constantly changing. Operating systems evolve, cloud infrastructure updates, libraries develop new security vulnerabilities, and the software components your product relies on may eventually
become incompatible. All these factors must be monitored and managed after your product is released.
In addition, the data your software handles remains subject to regulatory and privacy requirements throughout its use. During the phase-out or end-of-life stage, it’s essential to have defined processes that ensure no sensitive medical data remains accessible or improperly stored once the product is discontinued.
Ask yourself:
- What happens when a user stops using your application?
- Do you detect this event and have procedures to identify and delete that user’s data?
- Can you confirm that all customer data no longer in use has been securely removed?
- Are there any known new security vulnerabilities in the software components I use?
- Is my product compatible with all current operating system versions?
- Are there any issues in the app or product that were not discovered during testing but appear in production?
These questions highlight why the product life cycle extends beyond design and development.
In today’s digital era, such life cycle considerations are increasingly examined by auditors and regulatory authorities, including the FDA.