Search the Elsmar Cove!
**Search ALL of** with DuckDuckGo including content not in the forum - Search results with No ads.

IEC 62304 vs. General Principles of Software Validation



Hi all,

I'm new in the cove,
We are a small company that are selling in US and around the world.
In the US we are medial device class 2, 510k exempt. We are NOT medical in the rest of the world.
We are ISO 13485 certificated and comply with 21 CFR 820.

Our product is integrating with software, so we are developing our software system in compliance with IEC 62301 norm.
I just read FDA General Principles of Software Validation and i think that i still don't comply with FDA with IEC 62301.

Please can someone help


Staff member
Super Moderator
Where, specifically, do you think you don't comply with FDA guidelines or requirements? I think it will be easier to address specific questions rather than to consider generalities.


Hi yodon,

Thank for quick response.

To be more specific. IEC 62304 field of application stipulate "This standard does not cover validation and final release of the MEDICAL DEVICE, even when the MEDICAL DEVICE consists entirely of software".

My question is: Since IEC 62304 doesn't cover validation, do i have to use the FDA general principles validation to validate my Medical Device?


Involved In Discussions
My question is: Since IEC 62304 doesn't cover validation, do i have to use the FDA general principles validation to validate my Medical Device?
Yes. Exactly.

Use of the V&V terms is often perplexing. Software testing determines that the software does what it is supposed to do. (Often called "Verification"). Then system-level testing and use-level testing is the "validation" that show it accomplishes its purpose.

If your product was pure software, having verified the software have you validated the product? I'd say you were almost there. The full product would include manuals and training materials that the software verification wouldn't address. If you've got good requirements above the software level (E.g., Customer Requirements) then you'd test against those.


Staff member
Super Moderator
glork98 is spot on, but let me just reinforce from another angle.

If you're selling a medical device in the US, you are compelled to follow the QSR (21 CFR 820). This is law. So you can follow 62304 but you are still required to meet all applicable aspects of the law first. Hopefully that puts it in perspective.


Quite Involved in Discussions
Actually, the one of the nicest confusion in the FDA guidances, what they consider software validation and what is per definition the design validation. These two are far not the same by definition, however it can be when there is a software only medical device.


Involved In Discussions
I know this is an old thread but I ran across this and felt the need to vent. To expand on Sagai's comment, I personally dislike the language in the FDA's "General Principles of Software Validation" because it implies that nearly every facet of the development life cycle is part of validation. Reliance on this guidance has led to a lot of confusing language in our quality system where it pertains to software. The bulk of the guidance discusses activities that are not normally considered validation - planning, requirements, design, design review, implementation, code review, verification, etc... These are all adequately addressed in IEC 62304.

To further complicate this, when the guidance actually does address validation, it blends it into two distinct ideas - system testing and user site testing. It defines system testing as occurring at the target environment and potentially under an IRB or IDE approval. Then it goes on to define "user site testing" as "any other testing that takes place outside of the developer’s controlled environment". Don't these sound like the same thing? The rest of the "user site testing" section is actually clearly addressing installation activities, not design validation.

In the real world, System Testing should be viewed as it is described by 62304. This is a verification activity to show that everything works when you put all the pieces together (did we build the software system right). 62304 does not address the next step, which is where you put the software into the users hands and evaluate whether it meets their needs (did we build the right software system). The FDA guidance does allude to this step but it does so in a very confusing way, as noted above. You're better off learning what validation means in the context of a product and relying on that understanding (see section G of the Design Control guidance).

OK, I'm done venting.
Annex C of 62304 shows it's relationship with other standards.

Figure C.2 shows which parts of the "V" model of verification and validation are part of 62304 and which have to be additionally addressed. It's not very clear when you first look at it but is worth having a look at.
Top Bottom