Medical Device Software Terms and Definitions – IEC 62304 & FDA (Part 1)
This article is part of a series on IEC 62304, which focuses on understanding the standard and its correct implementation in medical device software development.
Previous Articles:
In this first part, we will focus on terms and definitions that are often a source of discussions and misinterpretations, particularly related to software architecture and decomposition.
- What is ANOMALY?
- What is CONFIGURATION ITEM?
- What is DELIVERABLE?
- What is SOFTWARE ITEM?
- What is SOFTWARE UNIT?
Clarifying Terminology for Better Communication
Have you ever found yourself discussing an issue with colleagues only to realize that you are going in circles because you are using different terms or interpreting them differently? This is a common situation I encounter during client consultations. That is why I always recommend starting by clarifying terminology and aligning our understanding.
A clear interpretation of terms is crucial for working with the standard, as subsequent chapters reference these terms without further explanation.
This step is not about finding the “best” interpretation but about achieving consensus. Without a common understanding, it becomes challenging to describe and address problems effectively.
Aligning IEC 62304 Terminology with FDA Guidance Documents
There are two common challenges I frequently encounter:
- Different interpretations of the “Terms and Definitions” section in IEC 62304.
- Terminology discrepancies between IEC 62304 and various FDA guidance documents related to the medical device industry.
In this article, we will address both. We will start with the terms and definitions from IEC 62304 and expand their interpretation with insights from relevant FDA guidance documents.
Where to Buy IEC 62304
In the first part of this series, How to Start with the IEC 62304 Standard Implementation, I recommended an alternative source for purchasing the standard at a lower cost than on the official ISO or IEC websites. You can find it on the EVS website , the Estonian Centre for Standardisation and Accreditation. Here is the direct link to IEC 62304, including the 2015 amendment.
Once again, I remind you to rather purchase a multi-license.
Key Medical Device Software Terms and Definitions from IEC 62304
The Terms and Definitions section is found in Chapter 3. Despite its title, it does not always clarify each term thoroughly. Often, it requires referencing other standards for a full understanding. Below, I will explain some of the more complex terms in plain language, similar to how I discuss them with clients. I will focus on the terms you will most frequently encounter in your work with the standard and medical device software development.
In this series, we will deliberately skip terms related to risk management as they will be covered separately. Additionally, we will omit terms that are self-explanatory or less critical for working with the standard.
What is ANOMALY in IEC 62304?
Definition: An anomaly is any deviation from an expected or intended result. It may involve a functional discrepancy in medical device software, documentation inconsistencies, or deficiencies in quality management requirements.
Anomalies Are Not Just Software Errors
Many interpret an anomaly as a failed test. This is because IEC 62304 primarily discusses anomalies in Section 5.7, which focuses on software system testing. However, anomalies can take many forms, such as:
- A software requirement that is ambiguously defined, making it unclear how the software should behave. The issue is not that the software is malfunctioning, but that the description is vague.
- A system response that is slower than expected under specific test conditions. If this delay is due to a less powerful test environment rather than an actual software issue, it may not be a production concern.
Anomalies Do Not Necessarily Delay Software Release
Recognizing that anomalies are not limited to software errors is crucial because it allows for more flexible handling. The presence of an anomaly does not automatically mean that a software release must be halted.
While you should not release medical software with known functional defects, minor inconsistencies that do not impact functionality may not be a reason to delay deployment.
Even IEC 62304 itself permits software release with anomalies after analysis, as stated in Section B.5.7.
What is CONFIGURATION ITEM in IEC 62304?
Minimal Definition in the Standard
IEC 62304 provides a brief definition, stating that a Configuration Item is “anything uniquely identified at a given time.”
A better understanding can be gained from IEC 12207, a referenced standard that offers valuable insights into system and software lifecycle processes.
What Is a Configuration Item?
A Configuration Item (CI) is any element related to your medical device software that must be identified and updated to maintain clarity in development and maintenance.
Common Configuration Items include:
- Software requirements specification
- Software architecture
- Test specifications
- Risk management file or cybersecurity file
- Source code (including compiled code)
- External libraries (SOUP or OTS)
- Development and deployment tools (e.g., IDEs, compilers, CI/CD configurations like GitHub, Dockerfiles, Kubernetes YAML, Jenkinsfiles)
- Test environments
- User manuals
Understanding this term is important because Chapter 8 of IEC 62304, “Software Configuration Management Process,” is dedicated to managing Configuration Items.
A separate standard, IEEE 828-2012 - Configuration Management in Systems and Software Engineering, provides further guidance on configuration management.
What is DELIVERABLE in IEC 62304?
A Deliverable is any output resulting from a specific activity. In medical device software development, this includes not just the source code but also technical documentation.
Recognizing this is important because IEC 62304 expects deliverables to be traceable and verifiable. This applies not only to the source code but also to documents such as:
- Software Requirements Specification (SRS)
- Software Architecture
- Risk Management File
As you can see, Deliverables often overlap with Configuration Items.
What is SOFTWARE ITEM in IEC 62304?
The term Software Item in IEC 62304 is a common source of confusion. Many place excessive emphasis on defining it, though the standard itself uses the term flexibly.
Definition: A Software Item is any software element identified during decomposition. It can be anything you deem necessary to separate for any reason.
Instead of overcomplicating it, define Software Items in a way that benefits your software development process. Follow standard architectural principles.
Examples of Software Items:
- Frontend Application
- Communication with Backend
- Notification and Alerts
- Secure Input Handling
- Backend Application
- Database
- User Authentication
- Audit Logging
- REST API
- HL7/FHIR Interfaces
What is SOFTWARE UNIT in IEC 62304?
A Software Unit is the smallest indivisible Software Item.
For example, if “Communication with Backend” is a Software Item, but it is not further divided, it is also a Software Unit.
The granularity of Software Units is defined by the manufacturer based on maintenance, security, reliability, and scalability needs.
Software Items and Software Units are also considered Configuration Items.
What Comes Next?
In the next article, we will cover additional Terms and Definitions from IEC 62304. If you spot any inconsistencies or have a different perspective, feel free to reach out—we welcome feedback and discussion!