Software verification and validation procedure

[plmiquelon]

Hi,

I'm working on implementing a software verification and validation procedure for the small medical device company I work. We developed all PCB and software internally (1 person) for a Class I medical device that integrates a software to control some feature of the device. The software would be classified as class A based on IEC 62304 definition. I'm trying to follow the V-shape model


Here is what we have in mind:
1) Risk analysis for the whole medical device (product)
2) Requirement traceability matrix for the product that triggers software requirements
3) Risk analysis for the software
3) Requirement traceability matrix for the software
4) Produce a software architecture (input and output, logical structure (state machine)), and PCB architecture scheme (input-output, illustration of each PCB component and interactions). In these, we will identify the input and output and link the hardware and software input-output.
5) Verification : Confirmation that the requirements of the software have been addressed from a software and hardware standpoint (How would you do that?) - Integration and Implementation testing (IQ)
6) Validation : Multiple tests case that evaluates the behavior of the software-hardware depending on the input-output implemented (Expected results vs real results) - System testing (OQ)
7) After that, I would see a last step where we test the device itself with the software (Acceptance testing) but this remains difficult for me to define what we need to do exactly. The design verification-validation is clear to me from a hardware standpoint but new for software...

I'm looking for concrete steps, particularly from a software point of view. Reading multiple threads and website remains very vague.

Thank you!

 

[Tidge]

Generally this looks good, but I would completely abandon reference to IQ and OQ. Those methods are most appropriate for process validation and not for design verification.

Instead, I recommend thinking about verification testing at different levels:

1. Unit testing at the smallest level you can hold individual elements accountable for satisfying requirements
2. Integration testing of how the units interact necessary to satisfy requirements
3. System testing where you no longer are stimulating individual units to study behavior but challenging the complete system against the requirements.

The architecture and detailed designs are the key tools for Unit and Integration testing, the system requirements are the key tool for System testing.

The trick will be to define units appropriately, and then understand how to perform integration testing. For example, in a physical design a battery might the correct "unit". There is more going on inside the battery, but there is (typically) nothing to be done by trying to test what is happening inside a battery as far as cells, ion transfer, etc. The Battery is to provide current at a specified voltage. You can test batteries all by themselves. Integration testing could be putting an Ammeter on one of the leads running from the battery to a charging circuit.

In this example, System level testing might be verifying that the battery charge indicator light correctly shows the charge state of the battery.

 

[plmiquelon]

Thank you for you quick answer.

Would you say that the integration testing is where the hardware (PCB) meets the software ?

What would be the unit testing for the battery example?

Thank you

 

[Tidge]

Would you say that the integration testing is where the hardware (PCB) meets the software ?

What would be the unit testing for the battery example?

Strictly speaking: Integration of software units is different that integration of software with hardware. You must consider both, and it is common to use hardware for some elements of (strictly) software integration (for certain types of systems), but they are distinct. Software as a medical device may have no specified hardware but the need for integration testing of the units is still appropriate (based on 62304 classification).

In the example of the battery: For a hardware design, it is unlikely to have specific user requirements about the precise details of a subcomponent (here: a battery...if this example bothers you, think of something else most users would know very little about, such as a discrete surface mount resistor), but the engineers will settle on the necessary specifications for the battery. In this example, unit testing would be analogous to verifying the identified specifications of the battery, independent of its place in the larger design.

 

[plmiquelon]

I see, thank you for clarifying.

I'm also a bit confused with IEC 60601-1 section 14 - PEMS. It ask for verification and validation. Is there a parallel with IEC 62304 requirements?

Since our software is class A, the requirements in IEC 62304 are less...

Thank you for your help.

 

[Yvonne]

Hi,

May I know how do we classify the software safety classes? As in IEC 62304, it only tells us the software safety class is differentiated into Class A, B and C. Do it have the classification rules stated in EU MDR 2017/745 to classify the medical device class?

 

[Tidge]

The classification is based on the level of risk for the Medical Device, as determined through a 14971-compliant process. If you don't want to make a strict SSSC you don't have to; you can default to class C.

An inappropriate yet applicable method of cross-checking a 62304 classification would be to perform a determination of Level of Concern (for product software), per the USFDA. There are enough fundamental difference between the two (and their purpose) that you cannot use a LoC for a SSSC. I am ONLY recommending this as a sort of 'sanity check'.

In my opinion, there would only be a limited number of particular circumstances where the LoC categorization (minor, moderate, major) would not map to SSSC (A, B, C). If I was reviewing medical device software and saw a misalignment between the two, I would be surprised (and possibly disappointed).