Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search


MD and IVD standards: IEC 60601-1 and IEC 61010-1, versus IEC 62304 - Part 1

Manufacturers of medical devices often ask themselves the obvious question:
Is it mandatory to be compliant both with IEC 60601-1 and IEC 62304?

Similarly, manufacturers of in vitro diagnosis devices ask themselves:
Are my devices in the scope of IEC 62304?

Obviously, medical devices (MD) with electric or electronic components are in the scope of IEC 60601-1. And in-vitro diagnosis devices (IVD) with electric or electronic components are in the scope of IEC 61010-1.

Do MD and IVD that embed software, fall in the scope of IEC 62304?
This is not so obvious.

Medical Devices - IEC 60601-1 and IEC 62304

You probably have already seen this diagram:
Software in Medical Devices - relationships between IEC 62304 and IEC 60601-1
It comes from annex C.1 of IEC 62304 standard. It aims at explaining the relationships between IEC 62304, software design, and other standards.
It tells that both IEC 60601-1 and IEC 62304 influence the design of software medical devices.
For sure, both standards are about software design:

  • IEC 62304 is all about software lifecycle,
  • Section 14 of IEC 60601-1 3rd edition is about Programmable Electronic Medical Systems (PEMS).[1]
Section H of IEC 60601-1

Having a quick look at section 14 of IEC 60601-1, you will see that it's pretty much like IEC 62304. It contains sub-sections about software design, risk management, problems resolutions, and so on. But, at the same time, it references IEC 62304 for software development.

So, when is it enough to be compliant with IEC 60601-1 and when is IEC 62304 mandatory?

There are two interesting diagrams in IEC 60601-1: Figures H.1 and H.2 in annex H (an informative annex), which are, uh, very informative.
Software in Medical Devices - PEMS decomposition into hardware and software subsystems
They more or less tell that IEC 60601-1 "sees" software as black boxes (components in Annex H) that are designed and integrated during the PEMS development lifecycle.

Software architecture: the big difference

If it is necessary to split software into software elements and software units, to show how:

  1. system requirements are translated in software requirements,
  2. risks mitigation actions assigned to software, are translated in software requirements,
  3. software requirements are allocated to software elements or software units,
  4. software interfaces are implemented by inner software elements,
  5. unit tests and software (not system) integration tests are necessary to demonstrate that:
    1. software units and elements work unitary,
    2. software requirements (including risks mitigations) are fulfilled,
    3. software units and elements work integrated together,
    4. software interfaces work with the surrounding system,

Then IEC 62304 is mandatory.

On the contrary, if it is only necessary to address software as a black box, to show how:

  1. system requirements are translated in software requirements,
  2. risks mitigation actions assigned to software, are translated in software requirements,
  3. software interfaces are implemented,
  4. tests of the software entity as a black box demonstrate that software requirements (including risks mitigations) are fulfilled,

Then IEC 62304 shouldn't be mandatory and it should be possible to apply IEC 60601-1 standard alone.

So, the big difference between IEC 60601-1 and IEC 62304 is the work of software (not system) architectural design and software (not system) integration.
IEC 62304 ensures that this work is consistent by reviews and traceability between requirements, risks mitigation actions and tests.
If you have both standards, have a look at Figure C.2 of IEC 62304 and compare it to Figure H.2 of IEC 60601-1 to see the difference.

Some examples

FPGA, ASICs and HDL

Quick answer: apply IEC 60601-1 only.
Although hardware description languages can be seen as source code prone to error, they're not software.

FPGA, ASICS, plus a tiny C (or other language) program

Quick answer: apply IEC 60601-1 only.
There's possibly a tiny C program (or another language) limited to a small source file, running on the hardware. Both elements (hardware + software) can be seen as a black box. They don't require software architectural design.
There can be a phase of tests of hardware alone, followed by unitary tests of hardware + software. But tests of software + hardware integrated (seen as a black box) are enough to demonstrate that requirements are fulfilled by the component.

System on a Chip (SoC), Micro-controllers and C (or else) programs

Quick answer: apply IEC 60601-1 if program is tiny enough, otherwise apply IEC 62304.
If hardware is big enough to have a program running on it, and if the source code of the program is more that one source file, then we have a borderline case.
It's up to the software and hardware designers to decide if IEC 62304 is applicable or not. It depends, once again, on the complexity of software. To give a help, if the answer to one of these questions is "Yes":

  • Is it relevant to split the software component into smaller components to show how requirements are allocated?
  • Is it relevant to split the software component into smaller components to show how risks mitigation actions are allocated?
  • Is it relevant to split the software component into smaller components to show how requirements about software interfaces are allocated?

Then IEC 62304 is probably yours.

Everything of higher complexity

Quick answer: apply IEC 62304.
If the answer to one of the above questions is frankly yes, if there are dozens of software requirements, if your software requires more than one person to design it, or if your thumb tells you to do so (you'd rather need experience), then IEC 62304 is yours.

To go further

Deciding whether or not it is necessary to apply IEC 62304 + IEC 60601-1 or IEC 60601-1 alone has a lot of consequences on the amount of work to do. IEC 62304 requires many processes and is rather time-consuming.
If you're still doubtful and want to sell in the US, read also the guidances on software made by the FDA to see if what they recommend is relevant for your case. I gathered the links on these guidances in my essential list of guidances for software medical devices. At top priority, see on this page the link to the guidance about General Principles of Software Validation.

In the next article, we'll ask the same question about IVD, with IEC 61010-1 and IEC 62304.

Note

[1] Note: Section 14 of IEC 60601-1 3rd edition is the former IEC 60601-1-4 collateral standard of IEC 60601-1 2nd edition.



Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed