Software verification and validation procedure

#1
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
1619095843295.png

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!
 
Elsmar Forum Sponsor

Tidge

Trusted Information Resource
#2
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.
 
#3
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

Trusted Information Resource
#4
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.
 
#5
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.
 
#6
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

Trusted Information Resource
#7
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).
 
Thread starter Similar threads Forum Replies Date
R Validation of Software used in Verification Testing ISO 13485:2016 - Medical Device Quality Management Systems 2
M Software verification and validation AS9100 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 4
T Class II Software Device 510k V&V (Verification and Validation) Criteria and Results 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
T Medical Device Software Verification & Validation for Client Specific Configurations Design and Development of Products and Processes 2
S Medical Device Software Verification and Validation Results - What is necessary? Software Quality Assurance 4
G IATF 7.1.5.2.1 Calibration/verification records :Program/software verification IATF 16949 - Automotive Quality Systems Standard 7
I Software (SaMD) mobile application verification testing: objective evidence Medical Information Technology, Medical Software and Health Informatics 2
S How to perform verification of the Statistical Analysis Software? Qualification and Validation (including 21 CFR Part 11) 7
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
J IATF 16949 7.1.5.2.1 software verification IATF 16949 - Automotive Quality Systems Standard 1
D Software Revisioning and Verification IATF 16949 - Automotive Quality Systems Standard 7
L Documentation of Medical Device Software Verification activities Other US Medical Device Regulations 7
S Verification software - EN 62304 applicable? IEC 62304 - Medical Device Software Life Cycle Processes 18
W ISO9001 Clause 7.4.3 - Verification of Purchased Product - Software ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 14
Chennaiite Is Design Verification Software required to be Calibrated IATF 16949 - Automotive Quality Systems Standard 7
J Medical Device Software Verification Requirements Design and Development of Products and Processes 7
Q ISO 62304 (Medical Device Software Development) Verification Requirements IEC 62304 - Medical Device Software Life Cycle Processes 1
S Checklist for RA and QA Review of DVT (design verification test) for Software Other US Medical Device Regulations 2
B Ford - Verification of Software (SPC) Statistical Analysis Tools, Techniques and SPC 2
A Review and Verification for Maintaining Software Software Quality Assurance 10
J How & how often to perform verification of Test Software of Automatic Test Equipment? General Measurement Device and Calibration Topics 3
F 4.11.1 Test Software Verification ? QS-9000 - American Automotive Manufacturers Standard 1
S Process Monitoring using SPC software Quality Assurance and Compliance Software Tools and Solutions 1
J Megger MIT520/2 adjustment software? Calibration and Metrology Software and Hardware 0
M Product Acceptance Software (PAS) PROCEDURE (BOEING D6-51991) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
M 3D Scanner Software validation ISO 13485:2016 - Medical Device Quality Management Systems 7
Y Software to Manage IEC 62304 Traceability Requirement IEC 62304 - Medical Device Software Life Cycle Processes 3
T Software item classification and Detailed Design IEC 62304 - Medical Device Software Life Cycle Processes 4
T Software Unit definition - IEC 62304 - Medical Device Software Life Cycle Processes 3
T Software user interface - definition of hazards ISO 14971 - Medical Device Risk Management 15
T Classification Accessory Software medical device EU Medical Device Regulations 4
G Software Medical Device Classification EU Medical Device Regulations 7
D Software Validation Question ISO 13485:2016 - Medical Device Quality Management Systems 10
C. Tejeda Computer system validation approach for Minitab Statistical software Software Quality Assurance 7
B Can a software that receive data from a MD be classified as Class I?or is not a MD? EU Medical Device Regulations 5
A What JIRA Software workflows you use for your software lifecycle? IEC 62304 - Medical Device Software Life Cycle Processes 4
G Software change management Design and Development of Products and Processes 2
John C. Abnet ...validation of computer software ISO 13485:2016 - Medical Device Quality Management Systems 14
N Free statistical software Reliability Analysis - Predictions, Testing and Standards 7
T ISO quality system software such as MQ1 (which is what we currently use) Document Control Systems, Procedures, Forms and Templates 8
X Looking for 17025 auditor to perform internal audit on IT software testing laboratory ISO 17025 related Discussions 3
B ERP software validation - risk assessment vs validation scope ISO 13485:2016 - Medical Device Quality Management Systems 11
D Guidance for Medical records software/template ISO 13485:2016 - Medical Device Quality Management Systems 1
M MDSW Software importer distributor CE Marking (Conformité Européene) / CB Scheme 2
B Software as a Medical Device - Language Requirements EU Medical Device Regulations 6
B Software as a NON-medical device Medical Information Technology, Medical Software and Health Informatics 23
qualprod 8.3 for software development. ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
S Software design document NMPA guidance and consultant China Medical Device Regulations 4
C How to place software version for SaMD product in HIBC secondary data structure (UDI-PI)? Other US Medical Device Regulations 4
L Acquiring software from 3rd party company IEC 62304 - Medical Device Software Life Cycle Processes 8

Similar threads

Top Bottom