IEC 82304-1 is one of many standards that medical device companies should use while developing software as a medical device (SaMD). It covers the requirements for manufacturers building health software products that are used without a dedicated hardware device.
However, IEC 82304 is still not as well known as another standard often used for SaMD, IEC 62304, the international standard for software lifecycle processes.
The two standards address different aspects of software development, but they also intersect in many ways. In fact, IEC 82304 requires the use of IEC 62304 and builds on its requirements in places.
In this article, we’ll take a look at what IEC 82304 covers, how it differs from IEC 62304, and how both standards relate to one another.
IEC 82304-1 - General requirements for product safety was published in 2016 and was last reviewed and confirmed in 2021. It covers the general requirements for the safety and security of health software products that are “intended to be placed on the market without dedicated hardware.” And while that does include SaMD, the definition of health software used in IEC 82304 is much broader than that.
The standard defines health software as “software intended to be used specifically for maintaining or improving health of individual persons or the delivery of care.” This could include software not classified as a medical device such as:
Prescription management systems
Laboratory information management systems
Radiology information systems
In essence, the standard can be used by both medical and non-medical software developers. Also keep in mind that IEC 82304 is a “product standard”, meaning it offers you guidance on how to design a product. In this case, the standard is focused on system-level requirements for health software manufacturers, such as:
Product use requirements
Product validation plans and reports
Product identification and instructions for use
Post-market activities
IEC 62304 applies to a more narrow subset of software than IEC 82304: medical device software. Medical device software includes both SaMD and embedded software, also known as software in a medical device (SiMD). Some examples of SiMD are:
Software that controls the mortar in an infusion pump
Software used in closed loop control of a pacemaker or other hardware medical device
This is one of the major differences between the two standards. IEC 82304 is for standalone software only—products that are used “without dedicated hardware.” IEC 62304, on the other hand, can be used for SiMD that is embedded in a hardware medical device.
Another difference is that IEC 62304 is a “process standard”, meaning it defines requirements applicable to certain processes and activities. In other words, it tells you how to work. In this case, the standard is telling you how to structure your software lifecycle processes in a way that will result in safe and effective software. That includes:
General requirements
Software development process
Software maintenance process
Software risk management process
Software configuration management process
Software problem resolution process
For an in-depth look at how to apply IEC 62304 to your medical device software, head over to Greenlight Guru Academy and get started with this informative course on IEC 62304.
Though they address different aspects of software development, IEC 82304 and IEC 62304 are closely related and both apply to SaMD development.
The graphic below, which is included in IEC 82304, shows where the two standards overlap.
When you read IEC 82304, you’ll notice that it references IEC 62304 several times, explicitly naming specific clauses from the standard for software-level requirements.
Section 4.7 of IEC 82304, which covers software system testing:
The manufacturer shall ensure that the Health Software Product system requirements are updated as appropriate, e.g. as a result of modification on the Health Software Product use requirements, as a result of system requirement Verification (see 4.6), or as a result of applying 5.2 of IEC 62304:2006 and IEC 62304:2006/AMD1:2015
Section 5 of IEC 82304, which covers software lifecycle processes:
The requirements in 4.2, 4.3, Clause 5, Clause 6, Clause 7, Clause 8, and Clause 9 of IEC 62304:2006 and IEC 62304:2006/AMD1:2015 shall apply to the Health Software in addition to the other requirements of this document.
Section 6.2 of IEC 82304, which covers performing validation:
When anomalies are found in the Health Software Product during validation, these shall be resolved through a problem resolution process according to Clause 9 of IEC 62304/AMD1:2015
However, IEC 82304 also expands on the requirements of IEC 62304, and its guidance on defining and validating product use requirements may be particularly helpful to SaMD developers using IEC 62304.
That’s because it’s possible to develop software and verify that it functions correctly using IEC 62304. But that standard doesn’t offer guidance on validating the software to ensure it meets user needs. And that’s a big gap, because software validation is an integral part of design controls and a key regulatory requirement.
IEC 82304 helps bridge the gap between IEC 62304 and the regulations on validation. For SaMD manufacturers already using IEC 62304, adding IEC 82304 should help ensure that their software has been validated and maintained through the entire product lifecycle.
Medical device industry standards require that software components be managed separately, just like the hardware and software components of traditional medical devices. And while that may initially sound like a headache for developers, it doesn’t have to be.
With the dedicated Design Control Software workflow in Greenlight Guru, you can easily manage each individual module or component of a device through its own design workflow and ensure that they are all reviewed and approved in a timely manner.
Don’t let design control requirements slow down your development team. Get your free demo of Greenlight Guru today.
Etienne Nichols is a Medical Device Guru and Mechanical Engineer who loves learning and teaching how systems work together. He has both manufacturing and product development experience, even aiding in the development of combination drug-delivery devices, from startup to Fortune 500 companies and holds a Project...