MD and IVD standards: IEC 60601-1 and IEC 61010-1, versus IEC 62304 - Part 1
By Mitch on Friday, 5 April 2013, 16:50 - Standards - Permalink
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:
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.
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:
- system requirements are translated in software requirements,
- risks mitigation actions assigned to software, are translated in software requirements,
- software requirements are allocated to software elements or software units,
- software interfaces are implemented by inner software elements,
- unit tests and software (not system) integration tests are necessary to demonstrate that:
- software units and elements work unitary,
- software requirements (including risks mitigations) are fulfilled,
- software units and elements work integrated together,
- 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:
- system requirements are translated in software requirements,
- risks mitigation actions assigned to software, are translated in software requirements,
- software interfaces are implemented,
- 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.
Comments
1. FPGAs are configured not programmed. It is a misnomer to call an FPGA programmed.
2. Tools (often misleadingly called compilers) are used to create a configuration file for an FPGA. These tools run in a computer completely separate from the FPGA. This is the same way tools are used to draw schematics and pcb layout. Using tools in a computer to create something does not make that something "software".
3. This configuration file organizes the internal connections between transistors (or logical gates) inside the FPGA. There is no code running on anything (inside an fpga there is nothing like a processor running instructions, unless of course there is core inside the fpga).
4. State machines are not processors.
5. State machines do not run code, nor execute instructions.
6. A processor is a very special type of state machine. For this reason a processor itself is verified/validated as hardware not software. Just ask Intel/AMD or any other microprocessor/microcontroller manufacturer.
7. Most integrated circuits are designed using the same hardware description languages (VHDL or Verilog) that are used to configure FPGAs. Here the word "languages" is used the same way somebody would use it to say math is the language of numbers. They are not programming languages used to create programs/instructions that run in a processor. After VHDL or Verilog is "compiled" the output is not something that runs, is just a description of circuit connections (literally a schematic). In fact, because of this, only an extremely restricted subset of the "languages" can be used to describe hardware. How can anybody validate/verify a schematic like a program?
8. An FPGA is not a software system. It is a hardware system, which can be used to create a software system, if and only if, a hard/soft core is present/instantiated inside the FPGA.
9. IEC 62304 Amendment 1: 2015 makes this clear again: any instruction that runs on a processor is to be considered software. Unless there is a soft or hard core inside an FPGA, there are no instructions nor software running on a processor at all. Therefore the configuration file for an FPGA is not software.
10. A processor with its code in ROM is a system that is defined completely in hardware and is immutable, but nobody in their right mind would consider it as an only hardware system. There are instruction (in the ROM) that are executed by the core/processor. This instructions are hard coded/wired, but nevertheless they are instructions to be executed by a processor/core.
11. Both CPLDs and PFGAs are just ICs/ASICs whose internal connections are not fused, like in a ROM, but are (quite literally) placed in RAM. That fact confuses people who don't completely understand the difference between custom ICs, ASICs, CPLDs, and FPGAs. The configuration file is changing the way the transistors inside the FPGA are connected; is all electrical connections (literally shorts and opens).
12. As mentioned before an FPGA can have a processor/core inside, and then the code running on that core would be software, not the configuration file that creates the core inside the FPGA. I hope it is clear enough that in this case there would be two files, one to configure the FPGA, the other would be the software being executed by the core inside the FPGA.
13. Unfortunately many people writing standards, writing software, or managing (any of which could be electrical engineers) do not completely understand what is an FPGA and how it is used. They only see a file being created by a computer which is then transferred to the FPGA. All integrated circuits (even analog ones) are nowadays created in a computer that creates files that are eventually transferred to the integrated circuit. This transfer can be done in a volatile or non-volatile way, and using one or the other does not make the IC magically hardware or software. The same way burning code into ROM instead of RAM does not convert the program into something people would stop calling software/code/program. The fact that you can change the connections in an FPGA a lot quicker and cheaper than in a custom IC or an ASIC (which would require creating a new set of masks and running a new batch of chips at the fab), doesn't make the two processes any different.