Clause 5.1.12 of Technical Standard IEC 62304/A1

BargeSim

Starting to get Involved
#1
Good Morning,

I am currently a little stuck on Clause 5.1.12 of Technical Standard IEC 62304/A1
any help on this clause?

I can not understand what the Standard mean with a "procedure".

Can be enough to manage it through Risk Management and related evidence in the RMF file?

Thanks Everyone.
 
Elsmar Forum Sponsor

Tidge

Quite Involved in Discussions
#2
Section 5.1.12 is "Identification and avoidance of common software defects".

The requirement 5.1.12(a) to procedure-lize defect tracking (as part of the development plan) exists primarily so that all defects are identified, classified, and processed according to a common process (no ad hoc approach to identified defects). A medical device software developer may have a common software defect handling process or can establish one within the plan. Software Development Plans have a tendency to 'end' upon design transfer, so I recommend an issue/defect tracking process that can be used for both development and on-market phases.

In my opinion it would not be appropriate to expect that Risk Management activities act as a substitute for software defect tracking (a.k.a. "issue handling") any more than it would be to try to address Corrective Action through Risk Management.

The requirement 5.1.12(b) can be addressed via an interface with RM activities. A common approach is to reference relevant RM file line items within the defect tracker and to reference known defects within the appropriate RM files.
 

BargeSim

Starting to get Involved
#3
Thank you Tidge for your prompt reply.

I thought the point 5.1.12a) was highlighting the adjective "common" referred to the software defect, not to the procedure. But in your opinion I can refer to the "general" issue/defect tracking procedure for this point, too?

Ok for the point b), thanks.
 

yodon

Staff member
Super Moderator
#4
My take on it is not issue tracking but how you will avoid defects endemic to the programming technology. For example, memory leaks. You will likely attempt to avoid them through code reviews or maybe there's a tool that automates checking. We point to our coding standards to identify the types of common software defects and then use our code inspection / peer review process to find and eliminate them.
 

Tidge

Quite Involved in Discussions
#5
Ah, I see the point about 'trying to avoid endemic issues'.

62304 (all flavors) is peculiar in that it supposes to be a process standard but comes dangerously close into wanting to be a product standard(*1) that tells developers how to do in their job. It's my opinion, but I wouldn't waste time trying to establish criteria to tell the difference between 'common' and 'uncommon' defects (for potentially diverse methods of implementation) and establish a specific methodology for only one category (of a given implementation). There is simply too great a variety of 'mistakes' that can be made in any development effort to try focus only on the avoidance. If you look at the referenced table B.2 from TR 800002-1 as some of the examples of 'categories of defects'(*2) there are precious few that would not be uncovered by Testing or Analysis (as always, mileage varies on the robustness of test methods).

That being written, if 5.1.12(a) is all about identifying the defects to avoid it isn't clear to me that 5.1.12(b) brings much value as it presupposes that some of the defects that were 'predicted' might actually be willingly present and intentionally left in the finished product. The point of these two clauses in conjunction may be too subtle for me.

(*1) Some elements of 62304 feel as if this was a standard about the requirements for designing and developing a mechanically fastened object, that certain clauses would divert into specific discussions about driving mechanisms and surface finishes of particular fasteners.

(*2) Locally, we typically utilize multiple levels of test/analysis/inspection for our software (generally this is coded and compiled from text sources). The lowest level is code inspection, and even though we have some routine questions to answer about the code (some specifically appear in TR 800002-1 B.2) so I suppose this 'counts' for the purposes of 5.1.12(a) even though the specific defect types are not called out in a development plan. More likely is the case that the finished product fails a specific test due to a previously unrecognized defect (e.g. a race condition, or an asynchronicity) but in the circumstances I'm familiar with these aren't endemic to the programming methodology. In the interest of full disclosure: my practice has been that when system testing (beyond integration or unit testing) results in a failure due to a specific software defect, in addition to anomaly resolution, I actually do update the RM files to reference the specific failure (often as a potential contributing to a risk item)...but we've always eliminated that anomaly.
 
#6
Hi everyone!
I think "yodon" is correct. For me there are two key parts in the phrase 5.1.12.a), "categories of defects" and "programming technology".
Table B.2 in IEC TR 80002-1-2009 lists several software causes that can be considered inherent or intrinsic to a programming technology. So, if you go through this list you will be able to identify which ones apply to your situation (for example, if you use pointers in C or C++ you will face the problem of dealing with "Errant pointers").
For point 5.1.12.b), I'm not sure if the Standard is telling us to document this situations in a Risk Analysis or there is a door to do it some other way?
For example, if I face the problem of "memory-leaks" I could say that dynamic allocation of memory is not allowed. One way of documenting this could be to add a Risk Analysis with a Control Measure indicating this restriction; or I could also not do the risk analysis and add a check in the code review guideline. Are we forced to do the Risk Analysis? How would you document this type of considerations?
 
Thread starter Similar threads Forum Replies Date
R ISO13485:2016 Clause 4.2.3 - Changes in Technical File Requirements ISO 13485:2016 - Medical Device Quality Management Systems 18
J Scope of ISO 9001 clause 10.2 in the product life cycle ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
E PEMS Hazards - IEC 60601 Clause 14.6 - Internal data use - Pressure sensor IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
B IEC 60601-2-43 - Clause 203.6.103 - Physical button? IEC 60601 - Medical Electrical Equipment Safety Standards Series 1
K Contamination Control - Class Is medical devices (Clause 6.4.2 ISO 13485:2016 (E)) ISO 13485:2016 - Medical Device Quality Management Systems 12
R Clause 7.7 Replicate, Recalibration and Intermediate checks using Artifact ISO 17025 related Discussions 1
A ISO 13485 - Clause 8.3.3 appropriate actions in response to nonconforming product ISO 13485:2016 - Medical Device Quality Management Systems 2
M Description of the requirements of clause 9.2.2.3 manufacturing process audit- needs your feedback IATF 16949 - Automotive Quality Systems Standard 0
A ISO 41001:2018 - Clause No.8 Operations Part Quality Management System (QMS) Manuals 2
L AS5553 Clause 3.1.7 e "Control packaging material ..................reused" AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 0
R What is meant by Use of COMPONENTS WITH HIGH-INTEGRITY CHARACTERISTICS in ME EQUIPMENT (clause no 4.9) IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
K What is mean by Oxygen Rich Environment as per the IEC 60601-1 clause no 11.2.2 IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
P Definition of production tooling in IATF16949 clause 8.5.1.6 IATF 16949 - Automotive Quality Systems Standard 4
K ISO 13485:2016, Clause 4.2.3 Medical Device File ISO 13485:2016 - Medical Device Quality Management Systems 4
I Master Document Access - ISO 9001:2015 clause 7.5.3 Document Control Systems, Procedures, Forms and Templates 5
Q Why new clause (7.1.6) in ISO 9001:2015? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 11
F ISO 13485 8.2.3 Reporting to regulatory authorities: Question regarding a procedure for this clause. ISO 13485:2016 - Medical Device Quality Management Systems 4
R Process control documents - Context of API Spec Q1, Clause 5.7.1.3 Other ISO and International Standards and European Regulations 0
T ISO 17025:2017 Clause 4.2.2 - The difference between "be notified" and "be informed" ISO 17025 related Discussions 4
O How can I justify excluding the R&D group and the design and development clause? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
V IS/ISO/IEC 17025:2017 Clause 7, sub clause 7.11 Control of data and information management ISO 17025 related Discussions 1
V IS/ISO/IEC 17025:2017 Clause 4.1 Impartiality ISO 17025 related Discussions 3
F ISO 17025:2017 Clause 7.7 Ensuring the validity of results - Threshold ISO 17025 related Discussions 9
L Clause 0.4 of ISO 9001 and EHS - Where should I stop the inclusion of EHS in my QMS ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
F ISO 17025:2017 Clause 7.4.1 - Requirements for Procedures ISO 17025 related Discussions 4
F Measurement Audit and ILC for ISO 17025 Clause 7.7.2 - Comparison with results of other laboratories ISO 17025 related Discussions 0
K ISO 17025:2017 clause 7.6.2 - Performing calibration of its own equipment shall evaluate the measurement uncertainty ISO 17025 related Discussions 6
S What's meant by ISO9001 clause 8.7 non conforming output? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 11
K AS9100D Clause 7.5.2.a) - What is considered to be "documented information"? AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 5
A Fire hazard classification - Clause in IEC 60601 about gauze and electricity ISO 14971 - Medical Device Risk Management 0
S Clause 8.2.2 Determining the requirements for products and services ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
S ISO 9001 Clause 8.3 Design for an education services provider ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
S ISO 9001 Clause 8.3 - Design & Development for training course center ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
L ISO 13485:2016 Clause 8.4 - Analysis of Audit Observations ISO 13485:2016 - Medical Device Quality Management Systems 8
C Determining if Maintenance Contractor is an External Service subject to ISO 9001 Clause 8.4 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 43
Q Connecting AS9100 D Clause 4.2 to 9.3.2 b - Interested parties and relevant issues AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 24
P IATF 16949 Clause 8.4.2.3 - Justification for non-certified suppliers IATF 16949 - Automotive Quality Systems Standard 12
M IATF 16949:2016 clause 8.4.2.3 - We don't have ISO 9001:2015 certificate IATF 16949 - Automotive Quality Systems Standard 26
R Material safety data sheet (MSDS) related clause in IATF 16949 manual IATF 16949 - Automotive Quality Systems Standard 17
R IATF 16949 Clause 8.5.1.6 a) maintenance and repair facilities - Production tooling management and personnel IATF 16949 - Automotive Quality Systems Standard 4
I Environmental Policy Content - ISO 14001 Clause 5.2 ISO 14001:2015 Specific Discussions 2
QChas IATF 16949 Clause 8.5.1.2 - C -Standardized Work IATF 16949 - Automotive Quality Systems Standard 1
M Dilemma about choosing the most applicable clause related to Risk ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 19
S ISO 9001:2015 Clause 9.3.2 - MR (Management Review) - Adequacy of resources ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
S ISO 9001:2015 Clause 8.7 Control of Nonconforming Outputs ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 19
M Contract Manufacturers and MDF Responsibilities, ISO 13485:2016, Clause 4.2.3 ISO 13485:2016 - Medical Device Quality Management Systems 3
C Internal Audit - Process Clause Matrix / Audit Checklist ISO 13485:2016 - Medical Device Quality Management Systems 7
Q ISO 9001 Clause 9.1 - Monitoring measurement analysis and evaluation ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
D ISO 9001:2015 Clause 8.4.3 "Information for External Providers" buying from online retailers. ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
Similar threads


















































Top Bottom