Clarification on interpretation of some EN ISO 14971:2012 & IEC 62304:2006 req's

blah01

Involved In Discussions
#1
Hello all,
I have some questions regarding interpretation of the requirements related to EN ISO 14971:2012 (I use ‘ISO 14971’ interchangeably below) and ISO 62304:2006. Note that I am fairly new to the Cove; I posted 1 question last year and couldn't even figure out how to find it again on the site...a bit pathetic on my part I guess :bonk:...

I have spent nearly 2 days reading through the many posts on these standards to make sure I didn't simply throw out questions that were answered already, and found it to be very informative, although I still have a couple of questions left over which I would greatly appreciate some guidance on.

First as background information, we are a North American manufacturer and our product is a stand-alone software which is considered "aids for disabled/handicapped people", per definition "2.9 medical device" Note 2 in ISO 14971:2012, and which we have classified as a Class A device under ISO 62304. We are compliant to ISO 62304 and are now in the process of implementing EN ISO 14971:2012 since we will be selling in Europe. Note that I am also familiar with the Essential Requirements in MDD 93/42, of which the relevant requirements are addressed by Annex ZA in EN ISO 14971.

My questions are as follows:
1) One of my main questions is in regards to interpreting "misuse" when assessing hazardous situations. The Medical Device Regulation, section 2.1 indicates that "The first requirement of the ‘Essential principles of safety and performance of medical devices’...when used under the conditions and for the purposes intended...they will not compromise...". So in other words, it intimates that hazards/hazardous situations should be identified and analyzed based on the intended use of the product (that's my interpretation anyhow). This is the approach we took when we defined the safety classification of our product under IEC 62304. However, ISO 14971 says that "...The manufacturer shall document the intended use and foreseeable misuse...". How far are we supposed to go in identifying misuse? For example, you can develop a prosthetic leg intended to aid with simple daily activities such as walking, but if a user then decides to go rock climbing because the prosthetic has given him a greater sense of confidence (and false confidence), then he goes and falls off the cliff because the prosthetic broke off or slipped (due to being exposed to stress beyond what it was designed for); keep in mind that proper use of the product and the intended daily activities they are intended for would be clearly described up front. This would be a misuse of the product, but, is it a misuse we need to identify during our risk analysis? We don't control what people go out and do with the aid of the product. I would like to limit ‘misuse’ to things like not properly attaching the prosthetic (and resulting consequences), and thus staying within the scope of our intended use statement. Is this acceptable?

2) We've been told by our NB that IEC 62304 is a requirement so we did it (note that this was a good ‘hand in glove’ fit for us so it was no big deal...we would have spent more time debating it than just doing it). However, it is unclear if ISO 14971 is a requirement. IEC 62304 section 4.2 says we need to have a risk management process complying with ISO 14971, however per definition "2.9 medical device" Note 2 in EN ISO 14971:2012, it indicates that there is no harmonized approach yet to devices such as ours, so it is unclear if ISO 14971 is indeed a requirement or not for "aids for disabled/handicapped people". Could anyone shed some light on this?

3) In parallel with question 2, is the approach we took in defining the safety classification of our device per 62304 correct, meaning that we only considered “when used under the conditions and for the purposes intended”, and not “misuse”? When defining our ‘intended use’ statement, we actually identified some exclusions to this, meaning we identified uses of the product which it is not intended for (for example, “does not include rock climbing” ...again, our device is a software product, so the prosthetic/rock climbing example is simply an analogy).

4) I’m a bit confused on interpreting deviations 5 & 6 in Annex ZA in 14971:2012 (and I know I’m not the only one...I read the posts :)). They seem to indicate that BOTH “inherently safe design” AND “protection measures” are to be applied, ...taking into account the generally acknowledged state of the art..., and it actually says that the MDD (93/42) says that these are to be applied “cumulatively”. I don’t see in the MDD any reference that they must be applied cumulatively, because it actually says “In selecting the most appropriate solutions...”. I interpret the MDR as saying that we can still choose between either the first or second bullet (inherent design/protective measure), but 14971 seems to say that both must be applied. Am I interpreting Annex ZA correctly or not?

5) Regarding IFU and deviation 7 in Annex ZA, I realize that IFU is no longer an option in terms of a risk control measure, though in reading some of the posts you might be able to lump IFU as “adequate protection measure including alarms” with proper justification (but that's not the point of this question), but what’s not clear to me is if information to users must be disclosed for EVERY residual risk (which would be nuts). I have read much material on this and it’s still not clear. Could someone clarify?

6) Does anyone know if IEC TR 80002-1:2009 is applicable to stand-alone software? I saw a post that seem to indicate it might only be applicable to when a software product needs to be verified at the user end (example hospital network) so I’m wondering if it would add any value in our case. I’ve bought so many standards so far for this risk management stuff I’d like to avoid another one if possible.

Sorry for the long post, but any information any of you could provide would be greatly appreciated.

Thanks in advance.
 
Elsmar Forum Sponsor

Marc

Hunkered Down for the Duration
Staff member
Admin
#2
... I posted 1 question last year and couldn't even figure out how to find it again on the site...
The easiest way to find posts you have made is:


Click on your name (and this works on any person's name in the forum) and you will see the above dropdown.

You can also go to the Forum Search and enter your name (or any forum user name) and do a search without any other search terms.

 

Marcelo

Inactive Registered Visitor
#3
1) One of my main questions is in regards to interpreting "misuse" when assessing hazardous situations. The Medical Device Regulation, section 2.1 indicates that "The first requirement of the ‘Essential principles of safety and performance of medical devices’...when used under the conditions and for the purposes intended...they will not compromise...". So in other words, it intimates that hazards/hazardous situations should be identified and analyzed based on the intended use of the product (that's my interpretation anyhow). This is the approach we took when we defined the safety classification of our product under IEC 62304. However, ISO 14971 says that "...The manufacturer shall document the intended use and foreseeable misuse...". How far are we supposed to go in identifying misuse? For example, you can develop a prosthetic leg intended to aid with simple daily activities such as walking, but if a user then decides to go rock climbing because the prosthetic has given him a greater sense of confidence (and false confidence), then he goes and falls off the cliff because the prosthetic broke off or slipped (due to being exposed to stress beyond what it was designed for); keep in mind that proper use of the product and the intended daily activities they are intended for would be clearly described up front. This would be a misuse of the product, but, is it a misuse we need to identify during our risk analysis? We don't control what people go out and do with the aid of the product. I would like to limit ‘misuse’ to things like not properly attaching the prosthetic (and resulting consequences), and thus staying within the scope of our intended use statement. Is this acceptable?
The usual definition of reasonably foreseeable misuse (from IEC guide 51) is "use of a product, process or service in a way not intended by the supplier, but which may result from readily predictable human behaviour". In fact, from a usability engineering standpoint, it's related to use error. This is one of the things I'm trying to change I the revision of ISO 14971, because this "reasonably foreseeable misuse"should be based on the usability engineering process and thus be identified later in the process (not in the beginning).

2) We've been told by our NB that IEC 62304 is a requirement so we did it (note that this was a good ‘hand in glove’ fit for us so it was no big deal...we would have spent more time debating it than just doing it). However, it is unclear if ISO 14971 is a requirement. IEC 62304 section 4.2 says we need to have a risk management process complying with ISO 14971, however per definition "2.9 medical device" Note 2 in EN ISO 14971:2012, it indicates that there is no harmonized approach yet to devices such as ours, so it is unclear if ISO 14971 is indeed a requirement or not for "aids for disabled/handicapped people". Could anyone shed some light on this?
Formally, standards are voluntary in Europe (although it's the best way to show compliance with essential requirements, and using a harmonized standard gives you presumption of conformity). So IEC 62304 is not a requirement (although you can use it to show compliance with the software ER). Nor is Iso 14971. But obviously, there's a high expectation (sometimes translated into "requirements" as you mentioned) that standards are used.

ISO 14971 is applicable to medical devices (and is used to show compliance with the ERs). It's applicable to all medical devices. If your device is a medical device, ISO 14971 is applicable o your device.

3) In parallel with question 2, is the approach we took in defining the safety classification of our device per 62304 correct, meaning that we only considered “when used under the conditions and for the purposes intended”, and not “misuse”? When defining our ‘intended use’ statement, we actually identified some exclusions to this, meaning we identified uses of the product which it is not intended for (for example, “does not include rock climbing” ...again, our device is a software product, so the prosthetic/rock climbing example is simply an analogy).
The software safety classification is related to "RISK of HARM to the patient, operator, or other people resulting from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute"(I'm using AMD 1 language). This does include hazardous situations caused by misuse, yes, if the software is part of the sequence of events.

4) I’m a bit confused on interpreting deviations 5 & 6 in Annex ZA in 14971:2012 (and I know I’m not the only one...I read the posts :)). They seem to indicate that BOTH “inherently safe design” AND “protection measures” are to be applied, ...taking into account the generally acknowledged state of the art..., and it actually says that the MDD (93/42) says that these are to be applied “cumulatively”. I don’t see in the MDD any reference that they must be applied cumulatively, because it actually says “In selecting the most appropriate solutions...”. I interpret the MDR as saying that we can still choose between either the first or second bullet (inherent design/protective measure), but 14971 seems to say that both must be applied. Am I interpreting Annex ZA correctly or not?
Annex ZA requires that you apply both. ISO 14971 says that if the first reduces the risk to an acceptable level, you don't need anything else.

Both are an interpretation of the safety integration - application of the “3-step-methodology” - see this http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=903-01-20.

5) Regarding IFU and deviation 7 in Annex ZA, I realize that IFU is no longer an option in terms of a risk control measure, though in reading some of the posts you might be able to lump IFU as “adequate protection measure including alarms” with proper justification (but that's not the point of this question), but what’s not clear to me is if information to users must be disclosed for EVERY residual risk (which would be nuts). I have read much material on this and it’s still not clear. Could someone clarify?
This is a misinterpretation of the deviation (but the deviation is still written in a weird way). What the deviation says is that the information on residual risk is does not reduce risk. This is relate to the disclosure of residual risk which might be required after residual risk is evaluated.

6) Does anyone know if IEC TR 80002-1:2009 is applicable to stand-alone software? I saw a post that seem to indicate it might only be applicable to when a software product needs to be verified at the user end (example hospital network) so I’m wondering if it would add any value in our case. I’ve bought so many standards so far for this risk management stuff I’d like to avoid another one if possible.
It's applicable to any software, stand-alone (SaMD) or embedded.
 

Jean_B

Trusted Information Resource
#5
Adding to Marcelo's excellent post.

The notified bodies also issued a consensus statement clarifying their position towards interpreting the 14971 Z annexes. This is available here: http://www.team-nb.org/wp-content/u...nterim_NBmed_Consensus_Version_140812_1_1.pdf

In the same vein the guidance ISO TR 24971 also provides additional guidance for risk management. Much of this guidance is also interesting with regards to 14971's Z annexes.
 

yodon

Staff member
Super Moderator
#6
Also want to add on to Macelo's excellent post... :)

And apologies if this is piling on but you didn't mention IEC 62366 (Usability Engineering - another harmonized standard, I believe). It too wants you to address risk from a usability / use standpoint. So there's this whole (dare I say it) Risked Based Thinking drive that needs to be fully integrated into your development and postmarket approaches.

Final note (and yet another case of piling on): Since we're talking about risk and software, if you're also considering release in US (and maybe not a bad idea in general), you'll want to address cybersecurity (at the various levels). That can also be integrated into the risk analysis. The FDA has 2 guidance docs (premarket and postmarket).
 

blah01

Involved In Discussions
#9
Thanks for the feedback everyone, especially the comprehensive response from Marcelo and the consensus paper provided by Jean_B. It's very much appreciated.

Does anyone know if this “Consensus Paper“ is widely recognized and accepted in interpreting and applying Annex ZA?

I also just went through IEC 62304:2006/AMD1:2015 and noticed they’ve now replaced section 4.3.a/b to now align with ISO 14971 method and terminology, which clarifies things a bit. I noticed in another post a reference to EN 62304:2006/AC:2008 saying it was a harmonized standard, and found a one-page corrigendum saying annexes ZA and ZZ were added, then underneath it has Annex ZZ listed (3 small paragraphs). Would anyone know how extensive Annex ZA is, and if the Annex ZZ in this corrigendum is all it is on this annex?

I would also like to confirm that when determining potential hazard/harm, that this also applies to other people in the vicinity such as the general public, and not just to the user. Is that correct?

Lastly, in the many websites I’ve browsed through for ISO 14971 I saw somewhere that said that formal training in ISO 14971 was a requirement, which I found odd. The standard simply says that persons performing risk management shall have appropriate knowledge and experience. I’m trained and quite experienced in doing FMEAs and other types of basic RM activities, and although I would like to go on a course for ISO 14971 to better comprehend it, it’s just not that readily available in Canada or US. Therefore, does anyone know what the expectations are in regards to ‘qualification of personnel’ when it comes to risk management techniques?

Thanks again.
 

Ronen E

Problem Solver
Staff member
Moderator
#10
The usual definition of reasonably foreseeable misuse (from IEC guide 51) is "use of a product, process or service in a way not intended by the supplier, but which may result from readily predictable human behaviour". In fact, from a usability engineering standpoint, it's related to use error.
In this context it's worth mentioning the concept of misuse (or use error) vs. abnormal use. The first stands for an unaware deviation from the intended use, while the latter is a deliberate detour or in plain language disobeying the labelling instructions / indications. I find this distinction more useful than the phrase "readily predictable human behaviour" because human behaviour is not always easily predictable, and that means that a lot of "normal" mistakes would not count as (and be addressed as) misuse, while they should.

In my opinion by including contraindications or warnings a manufacturer can usually transfer a specific use from the domain of misuse into that of abnormal use. Of course, it's impractical to list down all conceivable misuses, but in the process of considering the more significant ones they might also be addressed in other ways and maybe eliminated altogether. The problem, I feel, is that "abnormal use" is not adequately addressed in the standardised risk management process. I would be very happy if that could be addressed in upcoming standard revisions.
 
Thread starter Similar threads Forum Replies Date
A Clarification on the Interpretation of a Few AS9100 Clauses AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
K IPC-610 Section 10.4.2.2 clarification - Distance to be measured Various Other Specifications, Standards, and related Requirements 0
M Off-Label Use - Clarification of FDA Policy US Food and Drug Administration (FDA) 1
T Implant Card - Article 18.1(a) and MDCG 2019-8 clarification EU Medical Device Regulations 3
Q Need clarification on requirements.... Class i, gmp & 510(k) exempt Medical Device and FDA Regulations and Standards News 12
M Informational TGA Consultation: Proposed clarification of the regulatory requirements for medical device systems and procedure packs Medical Device and FDA Regulations and Standards News 2
R ASQ reference material clarification - Spiral bound materials allowed in ASQ Exam? Professional Certifications and Degrees 1
Q ISO 3310 Clarification Help - Aperture sizes for sieves used for particle sorting Other ISO and International Standards and European Regulations 2
S The Severity of a Medical Device Hazard - Risk Analysis Clarification ISO 14971 - Medical Device Risk Management 6
M 8.3.2.3 Development of products with embedded software - request for clarification IATF 16949 - Automotive Quality Systems Standard 1
M FDA News USFDA Draft Guidance – Clarification of Radiation Control Regulations for Manufacturers of Diagnostic X-Ray Equipment Medical Device and FDA Regulations and Standards News 0
T Clarification on MDR - Article 18(d) - Implant Card EU Medical Device Regulations 14
S QS, RS deflection - clarification wanted IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
A ISO 2859 Single Sampling - Clarification regarding the sampling table Inspection, Prints (Drawings), Testing, Sampling and Related Topics 4
S Requirements for Interval Measurement test & Frequency Response test clarification IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
S Clarification regarding tests in IEC 60601-2-25 IEC 60601 - Medical Electrical Equipment Safety Standards Series 1
J Internal Audit clarification - How to perform the audits IATF 16949 - Automotive Quality Systems Standard 6
V Clarification - Hydrogen De-embrittlement Manufacturing and Related Processes 6
K UDI Direct Marking Compliance Date Clarification and one other UDI question Other US Medical Device Regulations 0
N Applied Parts Classification Clarification - Breast Pump IEC 60601 - Medical Electrical Equipment Safety Standards Series 1
V Clarification of Injection part shrinkage ratio Manufacturing and Related Processes 1
J ISO 9001:2015 8.2.3 - Review of Requirements (Clarification on compliance) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
B Health Canada Recall Definition - Seeking Clarification Canada Medical Device Regulations 5
Q ISO 9001:2015 - Clarification in 6.1.2 Note 1 (Options to Address Risks) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
S Clarification of threaded ring gage calibration procedure/requirements General Measurement Device and Calibration Topics 2
M Clarification on Calibration/Verification Records 7.1.5.2.1d (IATF 16949) General Measurement Device and Calibration Topics 11
S AS9102 - Clarification - PO asking for an Assembly at Rev B (Print at Rev C) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
Pmarszal Clarification for 21 CFR Part 11.100 - General Requirements Other US Medical Device Regulations 14
B Clarification of ISO 9001:2015 Clause 8.5.6 Control of Changes ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 11
M Integrated Phased Processes - AS9100D cl. 8.1 Operational Planning - Clarification AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 8
A Monitoring and Measuring Resources (7.1.5) - Clarification ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
dubrizo Clarification Requested in 6.2.2 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
F TS 16949 Clause 7.2.1 - Note 2 - Recycling program - Clarification IATF 16949 - Automotive Quality Systems Standard 4
K EN ISO 15223-1:2012 Clarification or Examples on when to use Safety Symbols Other Medical Device Related Standards 3
S Clarification regarding types of processes ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
D Clarification of Applicability of TS 16949 Requirements to a Non-Automotive Business IATF 16949 - Automotive Quality Systems Standard 13
M Request for clarification on TS 16949 Clause 5.6.1.1 IATF 16949 - Automotive Quality Systems Standard 5
Q Configuration management clarification and example AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 6
S Clarification in organizing required documents for ISO 27001 IEC 27001 - Information Security Management Systems (ISMS) 6
J Definition Actively Manufacturing - ISO 13485 Definition and clarification Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 8
T Early Research & Development - ISO 13485:2003 requirements Clarification ISO 13485:2016 - Medical Device Quality Management Systems 34
B Detachable Power Supply Cable Connection ESD Clarification IEC 60601 - Medical Electrical Equipment Safety Standards Series 7
D NIST HDBK 44 Table T.3. Class III Tolerance in Divisions Clarification General Measurement Device and Calibration Topics 4
M UDI - Direct Marking and Reprocessing Clarification Other US Medical Device Regulations 12
S 21 CFR Part 820.40(b) Clarification on Required Document Approvers 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
E Clarification on Document Signatories under ISO9001 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P ISO 27001:2013 Clause 4.1 and 4.2 Clarification and Guidance IEC 27001 - Information Security Management Systems (ISMS) 13
C Positional Tolerance - Bonus / Datum Shift / ASME Y14.5M - Clarification Various Other Specifications, Standards, and related Requirements 9
K Free from any Undue Internal and External Pressures - 4.1.5b clarification General Measurement Device and Calibration Topics 2
B MSA 4th edition reference manual - Page 120-121 Clarification Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 6

Similar threads

Top Bottom