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

blah01

Involved In Discussions
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.
 

Marcelo

Inactive Registered Visitor
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
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
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
Moderator
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
Moderator
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
Moderator
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
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
Moderator
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
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)
 
Top Bottom