Level of V&V in Class II Medical Device (Dialysis Machine)



Good day all!
I've been doing V&V in the FAA domain for some time now and just recently came into the FDA domain. For the FAA I'm used to doing formalized Code Reads and formalized Unit Test all the way down to analyzing opcode level code coverage for Do178C Level A components.

I've been notified by my customer that this dialysis machine is class II which surprises me. I would think that it would be class III. Do you have any information or experience on what level of V&V detail will be necessary for the FDA on this type of device? My first reaction would be to do everything down to formalized Code Reads, but of course time is money and I don't want to really do more that what's completely needed (Even though I would if I had the time, I'm all about safety).

I also have a really short time frame to complete this project.

Any information would help and it would be greatly appreciated.

Thank you,
Elsmar Forum Sponsor


Starting to get Involved
The amount of V&V would depend chiefly on the product requirements for the product, the risks identified in the risk analysis, the degree to which prior testing can be used (due to similarity of a prior design), and the product complexity.

I've done quite a bit of V&V; let me know if you need some guidance.


Staff member
Super Moderator
The foundation for software in medical devices is still being built, I'd say. FDA has some guidance on what they expect in a 510(k) submittal but not much detail. The AAMI / ANSI IEC standard on software life cycle (62304) is a recognized consensus standard (both the :2006 version and the 2015 amendment) and provides more guidance and allows partitioning by safety class.

As Nancylove points out, your V&V should be driven by risk. And you should identify what your plans are for V&V in a V&V Plan. The Plan should establish the basis and rationale for exercises such as code reviews (per 62304 this would be probably considered unit acceptance).

A couple of more things that are coming to the forefront in FDA consideration: cybersecurity and usability. For the former, they are wanting to see assurance that reasonable means have been taken to protect from cybersecurity threats. For the latter, they want to see that a risk-based approach to usability has been taken, including validation that the system can be used safely and effectively.


Thanks all!

You mentioned that code review could be considered for unit acceptance.
Do you mean instead of doing actual unit tests?

It's a bit difficult for me since I'm used to doing requirement based unit tests including code coverage analysis.

Do you think dialysis machines should fall under class C software for class B software?

"I've done quite a bit of V&V; let me know if you need some guidance."
Thanks Nancylove, I might have to take you up on that guidance.
Last edited:


Staff member
Super Moderator
You mentioned that code review could be considered for unit acceptance. Do you mean instead of doing actual unit tests?
Correct but let me clarify just a bit (I kind of jumped ahead). You have to define what you will do for unit verification and then establish the acceptance criteria for whatever you do. If unit testing is your unit verification approach then there are some specific things to do and to capture.

It's a bit difficult for me since I'm used to doing requirement based unit tests including code coverage analysis.
That's certainly a valid approach. The standard implies that a certain level of rigor is needed for Class B but additional rigor is needed for Class C. Since you have a little more flexibility, let the risk drive the rigor.

Do you think dialysis machines should fall under class C software for class B software?
Realize first that if the architecture supports it, you can have different safety classes for software items in the system.

That said, it's hard to say without knowing exactly what the risks associated with the software are. If failure can lead to death or serious injury (and there are no hardware controls implemented - or as the update puts it controls external to the software system) then yes, C is appropriate.

Peter Selvey

Staff member
Super Moderator
About 10 years I did a lot of work with dialysis machines in Japan. Generally the construction is a 3 CPU system with one CPU for display and network, one for control and one dedicated to safety. The safety CPU has it's own set of sensors and is generally independent of the control CPU.

Although it is still extremely high risk (there are about 10 different ways to directly kill the patient), the separation of control and protection CPU makes things best suited for Class B approach, with extra emphasis on whole system tests.

It's likely that many manufacturers will be pushed to declare Class C for the safety CPU, but in practice it would be difficult to follow as there is a huge amount of software to pull apart. So it would likely be a fudge job if declared as Class C. There is definitely value in running through the code and checking variables for range limits, overflow, reset, but as for spending a huge amount of time writing up algorithms, well, us humans are pretty bad at trying to visualise or predict what happens in dynamic systems.

We found it was much better to run the tests on the whole system (hardware and software). There were often unexpected results that no amount of code inspection would have revealed. So, if you have limited time, I'd recommend to lean towards more system testing.


Thanks for the reply Peter. Since you were specific on the ways dialysis machines can kill people, Can you tell me what those 10 ways are? (This may may give me guidance on which components need most scrutiny)

Peter Selvey

Staff member
Super Moderator
Of the top of my head:
- overheating
- air infusion
- high flow rate
- wrong dialysate composition
- removal of too much / too little waste fluid
- blood loss (detached return needle, burst tube or other disconnection, leaking dialyzer)
- gross heparin delivery
- failure to disinfect
- failure to remove disinfectants after cleaning

These are basically covered by IEC 60601-2-16. There may be special functions or features in the equipment like feedback loops based on blood volume sensors. Not all are 100% sure to kill but most are fairly dangerous.

The standard requires not only independent protection but also start up tests of the protection and in some cases high frequency periodic monitoring of critical systems like air infusion, which can detect a fault in the protection before the air bubble can reach the patient.

So safety is primarily achieved by redundancy and self testing rather than relying on perfect code. This is normally the case in any high risk system.

In principle, if you have two completely independent systems that are 99.9% reliable (e.g. Class B controls) that gives you overall 99.9999% reliability. In practice it's not quite that simple but that's the basic concept.


Thanks again Peter.
I have another related V&V question.
The legacy code we're looking at has built in start up tests that include, memory test, CRC test and many many instruction tests.
I've never seen and/or heard of any CPU instructions ever failing. Do you see actual value added in having the CPU instruction tests? I understand the memory test, just not the instruction tests. I only ask because it's a lot of code that would require documentation and tests (previous owner of the code did not have proper documentation/tests for this startup tests).

I appreciate your experience on this subject.

Peter Selvey

Staff member
Super Moderator
This sounds like the "functional safety" which I was taught when I worked in TUV SUD.

Personally I don't subscribe to this as it is virtually impossible to test a CPU's core ALU and the tests that TUV accepted were more of a token just to be able to write "Pass" in a test report.

The real story is as you say the core CPU is super reliable, probability of failure is in the region of 10^-9/year or less. It's the nature of CPUs that they have to be super-reliable to be practical.

It's possible to write it up as a "high integrity component" in the risk management file which then allows it to be excluded from any fault analysis.

But, if third party testing is involved, it might be best to retain it just to allow them to write "Pass" for their functional safety tests. And then just keep some simple records for V&V.

Memory is a different story and I have seen flash memory corruption over long term even in my own products (albeit likely cause being power supply brown out events).
Thread starter Similar threads Forum Replies Date
T Level of Concern for Class II Medical Device Software 510(k) Submission 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
B UKRP to what level should you audit Class I Technical Documentation? UK Medical Device Regulations 0
A Level of details required for Class IIb Product Verification and Validation CE Marking (Conformité Européene) / CB Scheme 1
N Extent of Product Traceability Required by ISO 13485 (Low Level Class I Devices) ISO 13485:2016 - Medical Device Quality Management Systems 3
H Cleanroom vs. Clean hood - MIL-PRF-38534, Class K (space level) for hybrids Manufacturing and Related Processes 3
M Packaging level EU Medical Device Regulations 2
D What does a level 1 (PSW) PPAP actually promise? APQP and PPAP 16
A % of defects on the whole batch based on result from inspection under AQL Level II Inspection, Prints (Drawings), Testing, Sampling and Related Topics 6
R IATF and ASPICE level 2 Design and Development of Products and Processes 9
B ANOVA 3 level and 4 factors f and p values are not showing Using Minitab Software 0
N Level 3 PPAPs APQP and PPAP 4
J Part submission warrant for Level 1 PPAP APQP and PPAP 1
A Defining a lower ESD test level in IEC 60601 safety test IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
was named killer Onsite Level II N.D.T. Training in Florida Training - Internal, External, Online and Distance Learning 0
D High level understanding of EUDAMED EU Medical Device Regulations 3
D Supplier Quality level category help - high level ISO 13485:2016 - Medical Device Quality Management Systems 6
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
Y What are different Special Inspection Level 1-4 and General spesification 1-3 ? AQL - Acceptable Quality Level 0
D Supplier Quality - How to classify a supplier level Medical Device and FDA Regulations and Standards News 10
E Received a Major finding during IATF Surveillance audit for loss of BIQS Level 3 (more than 6 SPPS in 6 months)...how should we address SYSTEMIC CA? IATF 16949 - Automotive Quality Systems Standard 11
J Level 3 KPI Excel Template Manufacturing and Related Processes 1
M Informational How to perform a clinical evaluation of medical devices – Part 2 – Level of clinical evidence and what sufficient clinical evidence means Medical Device and FDA Regulations and Standards News 9
R Bottom up approach versus system level ISO 14971 - Medical Device Risk Management 2
C Failure nets - Same level effects FMEA and Control Plans 0
H Graphical analysis of results - Confidence level bands nomenclature Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 2
S Level of Clinical Evidence - MDR EU Medical Device Regulations 3
D GM BIQS level 5 requirements Customer and Company Specific Requirements 5
I Sampling processes - Who must define the AQL level? AQL - Acceptable Quality Level 9
R Identifying internal issues.. at what level? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
I What level of change in documentation requires re-training? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
M Level 3 PPAP submission of intentional defective parts APQP and PPAP 4
eule del ayre List of Level 3 PPAP requirements for automotive suppliers APQP and PPAP 20
I Document levels and approval requirements for lower level documents like work instructions, forms etc. Document Control Systems, Procedures, Forms and Templates 18
B AS9102 FAI & Lower Level Drawings - How should we perform the FAI? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
Rameshwar25 What is a Control Plan at "Material Level"? IATF 16949 - Automotive Quality Systems Standard 4
N How to resolve discrepancies in Level 3 PPAP supplier dimensional reports? APQP and PPAP 11
M Creating a Plant Level Value Stream Map Process Maps, Process Mapping and Turtle Diagrams 1
K Defining Acceptance Quality Level, I need clarity on AQL 1.5, 2.5, 4.0 AQL - Acceptable Quality Level 5
P GM BIQS level 5 training? Training - Internal, External, Online and Distance Learning 2
Ron Rompen Dual level holes - Measurement method suggestions wanted General Measurement Device and Calibration Topics 9
D System Level FMEA example wanted FMEA and Control Plans 2
samer Do we have to determine Educational level for all Staff as pr 7.2 b clause? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
J What level PPAP for 5 critical parts? APQP and PPAP 8
Paul Simpson Informational The role of Annex SL - High Level Structure of ISO MSS's - Revision Update February 2019 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 26
E High level structure - Planning and operation control Occupational Health & Safety Management Standards 2
rob73 Worldwide device regulatory authorities at country level Other Medical Device Regulations World-Wide 6
K Biocompatibility Testing - Component Level or Assembled Medical Device? ISO 13485:2016 - Medical Device Quality Management Systems 7
C Example Work Instruction/Procedure for AQL (Acceptable Quality Level) AQL - Acceptable Quality Level 4
K FDA Premarket Submissions for Embedded Software - Level of Concern Other US Medical Device Regulations 4
Highground Identifying Guidance on Medical Device Software Level of Concern for the EU EU Medical Device Regulations 2

Similar threads

Top Bottom