SBS - The Best Value in QMS software

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
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
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 Examples of FDA acceptable Software Design Specification (SDS) Medical Device and FDA Regulations and Standards News 6
D Integrated Management System Software Quality Manager and Management Related Issues 2
B Sampling strategies/techniques for software QA Software Quality Assurance 2
K MDCG-2020-3 (about the software of UI) EU Medical Device Regulations 3
D PFMEA Software search IATF 16949 - Automotive Quality Systems Standard 6
C MDR software classification EU Medical Device Regulations 12
H Class II a vs "software safety class A" IEC 62304 - Medical Device Software Life Cycle Processes 3
Z Software for design control ISO 13485:2016 - Medical Device Quality Management Systems 3
V Medical Device Literature Translation Software ISO 13485:2016 - Medical Device Quality Management Systems 1
D FDA Guidance on Computer Software Assurance versus 21 CFR Part 11 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
Aymaneh UDI-PI Software CE Marking (Conformité Européene) / CB Scheme 0
Q Software as a medical device vs software not sold as medical device: local regulations for sale? EU Medical Device Regulations 4
Y Software updates considered servicing (7.5.4) ISO 13485:2016 - Medical Device Quality Management Systems 4
I Document Control Software Document Control Systems, Procedures, Forms and Templates 2
E Software maintenance Process Software maintenance Process to IEC 6204? IEC 62304 - Medical Device Software Life Cycle Processes 3
L Micro-Vu InSpec Software Program Qualification and Validation (including 21 CFR Part 11) 6
A For software change - New Channel of interoperability CE Marking (Conformité Européene) / CB Scheme 5
T IVDR Medical device software CE Marking (Conformité Européene) / CB Scheme 8
N ISO 13485 7.3.9 Change control in medical device software ISO 13485:2016 - Medical Device Quality Management Systems 6
C SharePoint Contract Management Software General Information Resources 0
gramps What do you think about automated QA testing For software app industry? Misc. Quality Assurance and Business Systems Related Topics 5
V Software as medical device (SaMD) replicated for multiple clients through APIs IEC 62304 - Medical Device Software Life Cycle Processes 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
B Complaint Records - Accessing records on Easy Track Software Records and Data - Quality, Legal and Other Evidence 3
GreatNate Master Control QMS software Quality Tools, Improvement and Analysis 0
GreatNate Anyone using the Intellect QMS software? Quality Assurance and Compliance Software Tools and Solutions 1
S DHF/DMR/MDF for a software-only, cloud-based, single-instance device Medical Information Technology, Medical Software and Health Informatics 2
H Software Validation for FFS Packaging Machine Qualification and Validation (including 21 CFR Part 11) 1
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 1
Q ISO 13485 7.5.6 Validation - Off the shelf Software ISO 13485:2016 - Medical Device Quality Management Systems 3
M ERP / QMS related software standards for Validation IEC 62304 - Medical Device Software Life Cycle Processes 6
J Do Software Subcontractors need to be ISO13485 compliant in the EU? EU Medical Device Regulations 3

Similar threads

Top Bottom