Validation Plan for a new Class II Medical Device (Critical Care Medical Ventilator)

T

tooruokada

Hello!

I'm writing a validation plan for a new critical care medical ventilator that we are developing. For that device we want to obtain CE mark.

The device uses an embedded system with GNU/Linux and a custom
application (developed by us too).

I would like to know if i need to validate the software separated, or the validation of the whole device is enough. Also, i made the validation plan in two parts: technical and usability validation. Is that approach right?


We are new in validation plans, and i will greatly appreciate any help with that topic.


Thank you,

Esteban.
 

yodon

Leader
Super Moderator
Re: Validation Plan for a new Class II Medical Device (Critical Care Medical Ventilat

Would recommend that you get a copy of IEC 62304 and drive towards compliance to it.

Just to ensure there's no confusion, there's an expectation for verification (confirmation that the requirements are met) and validation (capable of meeting intended use / user needs). Generally speaking, most "technical" testing is on the verification side and usability is addressed in validation (you might also want to consider compliance to ANSI / AAMI 62366 for this aspect).

It's typical that there is software-specific testing.
 
T

tooruokada

Re: Validation Plan for a new Class II Medical Device (Critical Care Medical Ventilat

We already have the 62304 and the 62366. I did write the technical validation (in addition to the appropiate verification processes) as a means to confirm that the device complies with the intended operation in simulated use conditions.

I'm not sure if i must address separatly the validation of the software.

Thank you for your help!
 

yodon

Leader
Super Moderator
Re: Validation Plan for a new Class II Medical Device (Critical Care Medical Ventilat

You should have software requirements (ref 62304 5.2.1) as well as any risk controls implemented in software. The standard (ref 62304 5.7.1) expects evidence to demonstrate those are fulfilled. It doesn't have to be a separate protocol as long as you have the mapping to show what tests confirm the requirements and risk controls.
 

Peter Selvey

Leader
Super Moderator
Re: Validation Plan for a new Class II Medical Device (Critical Care Medical Ventilat

Apologies for the long digression but it is an interesting area. I found there are actually three distinct uses or meanings for word "validation", which often get mixed around:

1) field trials
2) the process of tackling complex situations
3) verification against top level specifications

Field trials are a great idea but they don't have much of a place in regulations per se as they are usually more of a fishing expedition (undefined, not final design). Manufacturers sometimes refer to field trials as "validation" but they really should be slotted in as part of the early prototyping, before specifications are fixed.

The "process" meaning is common in regulations, guides and also the meaning in ISO 13485. In this context, to say a system is "validated" means a complex system has been broken down into more manageable parts, verified, re-assembled systematically in a way which provides more confidence than just trying to tackle everything at a system level.

Finally there is meaning that validation is just top level verification, i.e. for the whole device as finally assembled, in the conditions of normal use. This seems to be the meaning in standards like IEC 62304 and IEC 60601-1. It is no different to normal verification, it is just the top level.

It is possible to combine meanings (2) and (3) and this is probably the best way, but it is not done in practice. An example helps to illustrate:

In the ventilator there is a flow sensor which is susceptible to room temperature. So there is separate sensor to measure the room temperature and software compensation is applied. You now have two options:

(a) at a lower level, verify the compensation works properly from 10°C to 40°C with detailed tests at various temperatures, flow rates and pressure. It could even involve further sub-system breakdown, hardware, software, ambient sensor parts and so on. Once complete, full system tests are done on a spot check basis only,

or

(b) full system tests need to be performed at 100's of combinations (room, flow, pressure settings) to make sure the system works under all conditions.

In principle either (a) or (b) is OK. But obviously (a) is more efficient and popular way.

The mistake though is to refer to the system spot checks as "validation". In truth, the validation is the combination of the spot checks, the lower level tests, and the decision that these combined are enough to provide confidence in the system.

There is a third option which is just buy an off the shelf sensor from a well-recognised maker with integrated compensation which means you don't have to worry about the lower level testing. Which illustrates the point that you really can't start writing detailed verification and validation test plans until the design is stable. Decisions on what to verify and validate will depend as much on the implementation as the "user specifications".

So, in the early stages, a "validation plan" should just be a placeholder in the overall design plan to say that validation plan will be developed when the system design is stable.
 
Last edited:
Top Bottom