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

blah01

Involved In Discussions
#31
So, given that these standards are optional (though they may provide the path of least resistance) and that the MDD requirements are the actual requirements in terms of risk management, compliance to ISO 14971 is therefore optional and therefore up to us how we decide to meet the MDD requirements, correct?

And, although in our case we are stating that we are compliant to IEC 62304, which calls up ISO 14971, a declaration of conformity does allow to list deviations as long as we can demonstrate that we meet the MDD requirements.

Is my thought process above flawed?

Your feedback is most welcome.

Thanks.
 
Elsmar Forum Sponsor

Marcelo

Inactive Registered Visitor
#32
So, given that these standards are optional (though they may provide the path of least resistance) and that the MDD requirements are the actual requirements in terms of risk management, compliance to ISO 14971 is therefore optional and therefore up to us how we decide to meet the MDD requirements, correct?
In principle, yes. But depending on the NB, they may want to force you to use standards (incorrectly, obviously), as this is the case that happened with you and 62304 as per your origina post.

And, although in our case we are stating that we are compliant to IEC 62304, which calls up ISO 14971, a declaration of conformity does allow to list deviations as long as we can demonstrate that we meet the MDD requirements.
Well, this is a little more complicated. If you use the harmonized standard (which means that you comply with the related requirements of the standard as listed in the EN annexes), you gain what is called "presumption of conformity".

In practice, you use EN ISO 14971 to fulfill most of the essential requirements, so I'm really not understanding why you are trying to avoid it (Update: now I remember, this is due to your original post). IEC 62304 can help you deal in particular with 1 ER. ISO 14971, with most of them.

The declaration of conformity does not list deviations, as you only list the harmonized standards used.
 

blah01

Involved In Discussions
#33
Thanks for the quick response Marcelo; much appreciated.

My biggest remaining concern in all of this is interpreting "foreseeable misuse", which can then lead to additional hazard/harm not considered when we did the safety classification of our device per IEC 62304, which we concluded was Class A. I really liked the example you provided about the red/green colours as a control method, which was used in a counter-intuitive method. However, what happens when you have a grey coloured button which could be interpreted in different ways?

To be specific, our SW device is an aid for people with visual impairment, intended to assist users with their typical "activities of daily living"; the fallback in any device failure is to just revert to their typical visual acuity (aided on non-aided...i.e. prescription eyewear). However, once you have this aid, some users may get a false sense of confidence and decide to go do things they typically wouldn't do with their typical visual acuity and who knows just what they might decide to do; it could be endless. There could potentially be some scenarios we could foresee, but people are people and who knows what they'll go out and do. We provide over 6 months of on-hand training to users when the product is delivered which includes cautioning them on proper use of the device, but I'm not sure anymore if such training would be considered an acceptable control method.

So i find I am spending more time trying to interpret the standard, while maybe I should just spend time interpreting the directive and find the best approach (although there would be similarities on how to go about it).

So that's where I am coming from. Our product is low risk, as long as people aren't stupid about it, to put it bluntly.

I carefully chose the title of this post when I started it, using the word "interpretation", because that's what i am struggling with, and concerned it may cause undue churn in our safety classification due to simply understand a standard. We did a good exercise when implementing 62304 and did identify potential safety concerns which were validated through hardware measures, and we are comfortable with the Class A classification. So I don't want to compromise that.

The feedback has been very helpful, though this "foreseeable" is still a bit mystic, given that we have a "grey" coloured control option to cnoisder (poor analogy maybe on my part...:confused:).

Thanks again.
 

Marcelo

Inactive Registered Visitor
#34
Your problem is really more related to IEC 62366 than IEC 62304.

In the case of the software safety classification of IEC 62304, the question is really simple. The failure of your software can probably give rise to some hazardous situations. But does this result in unacceptable risk? If not, it's class A. If yes, then you will have to check if it's B and C.

Also, if your device is software-only, you should be using IEC 82304, which is the product standard for SaMD.
 

Ronen E

Problem Solver
Staff member
Moderator
#35
I agree, it's still abnormal use from the standpoint of the application of regulatory requirements regarding label. But depending on the case, I would not consider it consistent with the IEC 62366 definition.

Another example, lets say the device has a control which uses the green colored to identify "stop"and red color to identify "go on". It's implemented on the device this way and described in the instruction for use this way.

But it is not right from the standpoint of human factors because it's not according to human behavior (and established "standards"of color). People will use it incorrectly because of bad design. It's still "abnormal use" from a regulatory standpoint but it's not "beyond any further reasonable means of USER INTERFACE-related RISK CONTROL by the MANUFACTURER".
We seem to agree, actually. You didn't quote me fully; a more complete quote would have been:

I still think that going against an explicit contraindication should be considered abnormal use (provided that there's no practical way to prevent that specific use through actual device design)
[I added the emphasis to show which part was missing in your quoting - a very significant part.]

Further, we seem to use the term "contraindication" differently, and maybe that's where the misunderstanding stems from. For me it means a user condition (typically medical) or a patient characteristic (age, gender etc.) that the manufacturer considers contradicting the use of the devices, ie establish situations where the device must not be used. You, on the other hand, seem to include under that term any warning or instruction not to do something with the device and maybe even the negative of every instruction provided by the manufacturer in the labelling. So when I say "going against an explicit contraindication" I mean using the device on/for a patient which is in a patient group or having a (medical) condition where the device shouldn't be used (according to the manufacturer's labelling); and you seem to be meaning doing something that goes against the labelling - a much broader meaning.

To go back to your example - in my terminology that wouldn't be considered going against an explicit contraindication.
 

Ronen E

Problem Solver
Staff member
Moderator
#36
And that's what I'm concerned. Everyone will have it's own interpretation because there's no formal definition and understanding now, and because there's has never been a formal definition and understanding in the past.
I agree that the situation is far from perfect. However, I believe that a lot of people understand the term along similar lines as those I've noted; not because I'm so clever, but because of the opposite - that interpretation is super-simple and it actually comes from the animalistic origin common to all of us (evaluate risk to survive).

The problem, in my opinion, is that people think that there's so much more to it, something glorious beyond their grasp. Nobody wants to be seen as "stupid" so the discussion about what this extra wisdom is is mostly avoided. What I was trying to express is that I think there's no extra and therefore not much to discuss and understand beyond understanding that risk management can (and perhaps should) be applied to almost everything the org does.

How the phrase is interpreted and enforced by registrars is a different issue, on which I have no special insights.
 

Ronen E

Problem Solver
Staff member
Moderator
#37
Our product is low risk, as long as people aren't stupid about it, to put it bluntly.
That's a very useful way of looking at the situation.

You should always assume that people will act stupidly every now and then. It's called fool-proofing your device.

If there are categorical ways you can envisage your software being used where it shouldn't, include a prominent contraindication against them. If you can't do anything else to prevent such uses by-design, you're in the realm of protection measures and labelling warnings. Extensive training / support such as what you've described is in my opinion a risk control measure in that realm (whether or not it's effective is a different matter and maybe worth some serious assessment). Once all that is done, going against your contraindication will be an abnormal use (from your statement that your SW is state of the art I gather that such use would not be common). Abnormal use is not within the domain of "foreseeable misuse" and not even in the scope of the currrent ISO 14971, so that should settle your "official" concern.

How to actually address abnormal use in real life I'm not sure; as far as I know existing published standards give us little advice on that (I'd be glad to learn something new about it). I suspect that some useful concepts can be (and maybe are) imported from the legal field and particularly liability, but I never actually researched that direction.

Other than that, any conceivable negative (or dangerous) use that you haven't excluded under a contraindication should then be considerd as a foreseeable misuse and evaluated for risk and acted upon as necessary.

Added in edit: A useful way to identify (some of the) foreseeable misuses is to take the IFU and reverse every single instruction.
 
Last edited:

blah01

Involved In Discussions
#38
Thanks again for the feedback guys.

From Marcelo's reply:
Also, if your device is software-only, you should be using IEC 82304, which is the product standard for SaMD.
:mg: ...another standard?

The scope in IEC 62304 says that it applies to "...MD software when software is itself a MD...". The scope of IEC 82304 says "...HEALTH SOFTWARE PRODUCTS designed to operate on general computing platforms and intended to be placed on the market without dedicated hardware, and its primary focus is on the requirements for MANUFACTURERS...".

I find the scope of 82304 ambiguous...for example:
> computing platform...could mean different things to different people.
> requirement for MANUFACTURERS...what the heck does that mean?

(Note that I do not have a copy of 82304...only going buy a preview that I could find...we're a small, young company with budget considerations...trying to decipher all these standards is getting expensive...)

I did some searching trying to understand the differences between 62304 & 82304 but couldn't find much. From the little bit that I could find, if I interpreted it correctly, is that 62304 seems to be more of a process level standard, while 82304 seems to be more at the product level, although I can't tell just what it imposes at a product level. I did see a comment that 82304 still had not been harmonized, but that was from a document from last year. So is 82304 now released and harmonized? Also, are 62304/82304 intended to be used together or does 82304 override 62304?

Since standards are not mandatory, and our NB has not said anything about it, that can't we just keep using 62304?

From Ronen's reply:
If there are categorical ways you can envisage your software being used where it shouldn't, include a prominent contraindication against them. If you can't do anything else to prevent such uses by-design, you're in the realm of protection measures and labelling warnings. Extensive training / support such as what you've described is in my opinion a risk control measure in that realm (whether or not it's effective is a different matter and maybe worth some serious assessment). Once all that is done, going against your contraindication will be an abnormal use (from your statement that your SW is state of the art I gather that such use would not be common). Abnormal use is not within the domain of "foreseeable misuse" and not even in the scope of the current ISO 14971, so that should settle your "official" concern.
I'm new to the term 'contraindication' but this really helped me understand it (along with the green/red example provided by Marcelo). So thanks for the info. The issues we are facing are really not things we can deal with through design controls or built-in warnings, so I think contraindications are our only avenue.
 

Ronen E

Problem Solver
Staff member
Moderator
#39
I'm new to the term 'contraindication' but this really helped me understand it (along with the green/red example provided by Marcelo).
Let me please re-emphasise that in my understanding the red/green button example has little to do with contraindications. Instead of repeating myself I'll illustrate with an example. A contraindication for a device could be "Pregnant women must not use this device" or "Not for use by children under 12YO".

The red/green button is more related to instructions and warnings (and also to human factors / usability engineering, through a widely accepted convention).
 

Marcelo

Inactive Registered Visitor
#40
We seem to agree, actually. You didn't quote me fully; a more complete quote would have been:

[I added the emphasis to show which part was missing in your quoting - a very significant part.]

Further, we seem to use the term "contraindication" differently, and maybe that's where the misunderstanding stems from. For me it means a user condition (typically medical) or a patient characteristic (age, gender etc.) that the manufacturer considers contradicting the use of the devices, ie establish situations where the device must not be used. You, on the other hand, seem to include under that term any warning or instruction not to do something with the device and maybe even the negative of every instruction provided by the manufacturer in the labelling. So when I say "going against an explicit contraindication" I mean using the device on/for a patient which is in a patient group or having a (medical) condition where the device shouldn't be used (according to the manufacturer's labelling); and you seem to be meaning doing something that goes against the labelling - a much broader meaning.

To go back to your example - in my terminology that wouldn't be considered going against an explicit contraindication.
Sorry, my bad, I quoted the part on contraindication, but wanted to showcase labeling in general. That's why I mentioned that anything in the label defines, from a regulatory (and normative) standpoint, how the device should be used (and this includes contraindications).

And not, I understand contraindication the same as you (I generally use the FDA guidance as a basis)
 
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
qualprod D5 of 8D clarification, how to verify root cause Problem Solving, Root Cause Fault and Failure Analysis 24
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

Similar threads

Top Bottom