5.5.3 - Software Unit Acceptance Criteria (Risk Control Measures)

A

andypatkinson

#1
Hi,

When it comes to verifying our software units that contain a RCM, we use unit tests to evaluate the RCM implementation (is it present and working as expected) and where we cannot test for it (for one resaon or another) we verify by code inspection.

Does anyone see any probem with this?

I have heard from other medical device SW developers ('around town') that because the example in the standard says:

NOTE Examples of acceptance criteria are:
? does the software code implement requirements including RISK CONTROL measures?


That code inspection / review is the only acceptable verification method and that verifying RCMs with unit tests is not 'meeting the intent of the standard'. I have a hard itme accepting that - for me we're verifying that the RCM is present in the unit and I choose to do that by 1st, testing and 2nd, inspection (but only if I have to, i.e. I cannot test for it).

Am I on the money or really going against the 'intent of the standard'?

Thanks in advance......

Andy
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
In general, I would agree that some requirements can only be verified through unit test (weak) or code inspection (weakest).

For risk controls, though, the expectation is that you demonstrate the control is available and effective at the time of need. It's clear that in some cases, demonstration could only be shown via unit-level testing. I would have a hard time defending verification of a risk control via code inspection - I don't think you could defend the effectiveness of the control.

Can you share a scenario where ONLY code inspection could verify a risk control?
 
A

andypatkinson

#3
Hi Yodon

Thanks for the reply.

The issue seems to be that because the example given in the standard talks about 'code', that the expected method of verifying this is via a code inspection, rather than testing. I agree that testing is a better method and is my preference.

Given that the standard talks about verifying risk control measures and traceability of requirements to tests, I don't see the point of section 5.5.3 and the focus on checking that a risk control measure had been implemented (if we're going to test for it before releasing the software, e.g. all verification will be completed before release).

Perhaps this is another example of a 62304 clause that if poorly written and simply causes confusion / misinterpretation.

Any further advice appreciated, Yodon

Regards, Andy
 

yodon

Staff member
Super Moderator
#4
I can't argue for the merits of the verbiage in the standard. :) But maybe some discussion can clarify what I believe the intent is (at least I can express my opinion).

5.5.2 is where you define how you establish verification methods for the units. Note that it's limited to class B and C (potential for patient injury). Note also that they explicitly indicate that there are other methods besides test for unit verification. For some units; e.g., those that are on one side of an interface, maybe you do some testing with a debugger to confirm the unit properly handles all data passed - both valid and invalid (something that should not be possible in normal operations).

5.5.3 establishes unit acceptance criteria and again only required for class B and C. If you have units that implement risk controls, the expectation, as I read, is that you do a code inspection to verify the implementation of the control. This is NOT requirements verification; this is how you accept the UNIT. This is a very low-level acceptance gate. The examples are quite appropriate for such a low-level verification: did you write the code per your standards, did you conform to the interface defined, etc.

So for class B and C software, if you have risk controls implemented in software, you're effectively saying that you are ensuring patients aren't harmed (or worse) via these controls and so the expectation is that you take extraordinary measures to ensure it's done right.

If you consider the 'V' model, you would have a low-level confirmation at the implementation level to confirm (via code inspection) that the risk control was implemented properly. (There's merit to this given testing can't or won't necessarily test every possible scenario.) Then moving up the food chain, once you get to the requirements level, you would have some type of functional testing to formally verify the risk control is effective.

Keep separate unit acceptance from requirements verification. Hope that makes sense.
 
Thread starter Similar threads Forum Replies Date
C Software Unit Acceptance Criteria (5.5.4) IEC 62304 - Medical Device Software Life Cycle Processes 3
I IEC 62304:2006 Definitions - Software System, a Software Element and Software Unit IEC 62304 - Medical Device Software Life Cycle Processes 13
C 7.6 for a Software Company - Calibrating Unit Testing ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 0
M Recurrent event analysis software (python) General Auditing Discussions 2
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 2
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
S Manufacturing Execution Systems Software Costs Manufacturing and Related Processes 0
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1
K SOUP (Software of Unknown Provenance) Anomaly Documentation IEC 62304 - Medical Device Software Life Cycle Processes 2
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 3
I Old Time Scatter diagrams for defect type and location- software Quality Tools, Improvement and Analysis 3
SocalSurfer AS9100 new certificate, but need QMS software, help Quality Assurance and Compliance Software Tools and Solutions 2
C Is my software an accessory? Telecommunication between HCP and patients EU Medical Device Regulations 10
K Verify Software Architecture - supporting interfaces between items IEC 62304 - Medical Device Software Life Cycle Processes 1
A What are the pros and cons of using an audit software for internal auditing? General Auditing Discussions 4
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
R MSA for ATE (Automatic Test Equipment Embedded Software) Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 9
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
L Turkish Requirements - Does the Software need to be translated? CE Marking (Conformité Européene) / CB Scheme 2
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 1
D Software User Interface Languages for LVD and IVD CE Marking (Conformité Européene) / CB Scheme 2
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
K Software Validation for Measurement Tools used in Process Validation ISO 13485:2016 - Medical Device Quality Management Systems 2
B ISO 14971 Applied to Software ISO 14971 - Medical Device Risk Management 2
N ERP Software Implementation Manufacturing and Related Processes 3
C NCR (Nonconformance System) Software Nonconformance and Corrective Action 7
U Document Approval - Software company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
S SOP for ISO 13485:2016 Quality related Software validation ISO 13485:2016 - Medical Device Quality Management Systems 9
J Designing new gauge tracking software IATF 16949 - Automotive Quality Systems Standard 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 4

Similar threads

Top Bottom