New ISO 14971:2019 Harm: unreasonable psychological stress, and cybersecurity

#1
As I'm trying to bring cybersecurity concerns into our safety risk management process, I am struggling with the right way to capture Loss of Confidentiality. Has anyone come up with a solid solution?

I think the addition of "unreasonable psychological stress" in 14971:2019 (see A.2.3) provides a good path. This is supported by 24971's example (table F.1), linking "loss of data confidentiality" to "psychological stress", as well as "deterioration of health"... but the latter has many options in current Harms Lists.

So, to add "psych stress" to a Harms List, using a typical 5-point Severity scale, I have this thought. Someone tell me if this is sound, or something else.

  • Unreasonable Psychological Stress, Minor; Severity 2 – patient or user is aware of issue (such as loss of PII), causes stress, distraction. No professional intervention is required.

  • UPS, Major; Severity 3 – issue causes patient/user stress, requiring professional intervention, such as counseling. Temporary condition.

  • UPS, Critical; Severity 4 – issue causes patient/user stress resulting in long-term/permanent effects (PTSD or similar); professional intervention, including psychiatric treatment, required for quality of life.

I don’t see a need for a Severity 5.

This remains consistent with the FDA’s definition of “serious harm”, aligning with S=3 and above: medical intervention is required.

So we have to keep people safe... AND sane!
 
Elsmar Forum Sponsor

Mark Meer

Trusted Information Resource
#2
As I'm trying to bring cybersecurity concerns into our safety risk management process, I am struggling with the right way to capture Loss of Confidentiality. Has anyone come up with a solid solution?
This is a great question!

I'm dubious about the idea of linking it to psychological stress in the way you've proposed though, mainly because the line between someone's confidential information being compromised, and the severity scale you've proposed is compounded by so many factors.

My suggestion would be to link severity to the nature of the information that could be compromised, and the potential harmful ways it might be used by a nefarious actor. For example:
- Low Severity: Names, dates (assuming nothing else could be inferred). Outcome of breach: Knowledge that you use the device.
- Medium Severity: General information on common / non-sensitive diagnoses. Outcome of breach: Knowledge that you have a condition.
- High Severity: Home address, Sensitive Personal Details, Specific information regarding sensitive diagnoses and/or treatments. Outcome of breach: targeted harassment, fraud, extortion

Obviously this is just an example, and would vary depending on the nature of the device, and what could possibly be inferred from the information compromised.

Just my suggestion....curious how others approach cybersecurity within their 14971 frameworks...

MM
 

Tidge

Quite Involved in Discussions
#3
My suggestion is to avoid addressing (non-medical, 1) cybersecurity harms in a 14971-based process. I suggest instead to establish a parallel risk-management process for cybersecurity concerns, and allow the two parallel processes to inform each other. As an example: design choices implemented to specifically address cybersecurity concerns could have an impact on the risk profile for medical harms, and vice-versa. This is no different than asking if a 14971 risk control has introduced a new hazardous situation.

(1) I've simplifying the description of "14971 harms" as "medical", because the medical device industry typically has some appreciation for harms (to patients, users, environment) that is derived from medical professionals, literature, etc. Such people/literature would not generally be able to make an honest assessment of the different types of cybersecurity harms, so my advices is to not confuse the 14971-compliant process with cybersecurity.
 

yodon

Staff member
Super Moderator
#4
...so my advice is to not confuse the 14971-compliant process with cybersecurity.
First off, I *completely* agree with your post. 14971:2019 is chock-full of mentions of cybersecurity and as @Bill Hansen points out, the TR does, in fact list "psychological stress" as a harm resulting from a data breach (and I also agree with @Mark Meer that linking data exposure to stress is a bit dubious but if one does consider worst case, in terms of the patient, that's understandable, I guess). Obviously there are some devices (implanted pacemakers) that, if hacked, could result in death.

Need to do some more noodling on this to come up with a solid approach. Good discussion.
 

Tidge

Quite Involved in Discussions
#5
AAMI TIR57 (2016?) spells out three areas of concern for cybersecurity (my paraphrasing follows, these are actually defined)

Confidentiality: The concept of restricting access to and disclosure of information.​
Integrity: The concept of improper data loss/modification of system/information.​
Availability: The concept of timely and reliable use of system/information.​

TIR57 is based on the principles of 14971 (2007): It recognizes the potential overlap with (medical device) safety concerns, but it explicitly considers elements of the three areas above to be worth addressing outside of safety. If any of the areas can be shown to lead to patient/user/stakeholder harm, then I would expect them to appear in a 14971-compliant process. An example of integrity issue leading to a safety issue could be: an infusion pump which is hacked to allow for more delivery of an opioid. A hacked pacemaker that is shut off would be an example of availability leading to a safety issue. If a harm can be established between confidentiality and psychological stress, then I won't stand in the way of addressing it in a 14971 process.

My reading of the discussion in informative annex A.2.3 implies that potential psychological harms are meant to be considered (as part of 14971) in the context of intended use (dare I write "essential performance"?); the example specifically given is of "false positives" from some sort of diagnostic determination. I'm not privy to the discussions of the joint working group so I won't speculate to what level TIR57 was considered.
 

Mark Meer

Trusted Information Resource
#6
...TIR57 is based on the principles of 14971 (2007): It recognizes the potential overlap with (medical device) safety concerns, but it explicitly considers elements of the three areas above to be worth addressing outside of safety. If any of the areas can be shown to lead to patient/user/stakeholder harm, then I would expect them to appear in a 14971-compliant process....
It seems to me that, with respect to risk-management, these can all be considered within a 14971 framework.

Otherwise, I'm curious what is intended by "addressing [confidentiality, integrity, availability] outside of safety"?
Presumably there is still the concept of severity assessment in cybersecurity risk-management, no? If taken outside a context of harm/safety, then what risks are we talking about? Strictly customer satisfaction and product reliability?
 

yodon

Staff member
Super Moderator
#7
For one, a data breach may well be considered "acceptable" within the framework of patient harm. But if you consider it in the framework of security, it's pegging out. (And given the fines associated with GDPR, you're darn well going to take actions to prevent.)
 
#8
Good discussion so far. Thanks to all.

I agree with the point that not all security issues are safety issues... TIR57's "crossover" diagram illustrates the concept. We're looking to build a security process that is parallel to safety risk management, with distinct analyses, containing references back and forth when appropriate. As @yodon and @Tidge said, Loss of Availability or Integrity had some obvious related safety risks, like delay of procedure or inaccurate measurements.

Prior to 14971:2019 coming out I'd planned to keep Loss of Confidentiality in the security path, but it seems we're compelled to bridge the gap for that as well. With ransomware attacks as a prime example, how does one capture the safety risk? The possibilities of Harms due to denied service because the HDO is locked down, are endless... so that's why I'm leaning toward using the Psych Stress. (Selected by our Clinical Expert, of course... it has to make sense! @Mark Meer , your suggestions for levels of severity would factor into the situation for sure.)

I've also struggled with the security process and what to call its version of "severity"... being a Risk Management guy for the last decade, I try to protect 14971's "back yard"... "Impact" seems to make sense. So, the Impact of a Security risk is not necessarily equal to the Severity of a Safety risk. One event could lead to either, or both.

But I've been told I'm overthinking this...
 

Tidge

Quite Involved in Discussions
#9
Otherwise, I'm curious what is intended by "addressing [confidentiality, integrity, availability] outside of safety"?
Presumably there is still the concept of severity assessment in cybersecurity risk-management, no? If taken outside a context of harm/safety, then what risks are we talking about? Strictly customer satisfaction and product reliability?
For one, a data breach may well be considered "acceptable" within the framework of patient harm. But if you consider it in the framework of security, it's pegging out. (And given the fines associated with GDPR, you're darn well going to take actions to prevent.)
@yodon has hit the bullseye with his response.

I think it is important to recognize that safety-compliance (in a 14971-context) is 'mandated' through regulatory requirements for marketing medical devices. As regulations are added and modified (such as those that relate to cybersecurity), new standards will have to be developed to allow for consistent application of controls such that risks which are the focus of the new/modified regulations will be controlled in an acceptable manner.

I personally don't think that expanding the safety aspects of 14971 to cover cybersecurity is a good idea. The primary reason for my attitude is that cybersecurity is an important concept that is completely independent of patient/user/stakeholder safety. I expect devices that are not medical devices to also consider cybersecurity, and it doesn't make sense to me to have medical device manufacturers examining a security concept like confidentiality as a medical safety issue while a non-medical device manufacturer 'ignores' this potential for user harm. This is not to say that I'm downplaying the potential liability which can arise from poor (non) implementation of risk controls relating to cybersecurity... rather that we medical device professionals should recognize that we need a new tool to analyze these risks rather than reach for our comfortable 14971 tool.
 
#10
If you check out AAMI ISO DTIR24971:2020, Table F.1 provides some examples, including:

Hazard = Loss of data confidentiality
Sequence of Events = The vulnerability of unnecessarily opened network port is exploited, and disclosure of personal health information
Hazardous situation = Denial of insurance coverage leading to lack of treatment
Harm = psychological stress, deterioration of health

It's a draft, but it works in the meantime until we get the final version.

Personally, I think the distinction between the degrees of stress doesn't add value because it is must more subjective than the physical harm, and your risk control measures are probably going to be designed-in cybersecurity features verified by standard testing regardless. As the manufacturer, you have very little ability to control what happens to the data once it is breached, so your RCMs largely be will be preventative.

I wouldn't worry about the severity ranking too much and choose a reasonable estimate with your team. The production and post-production risk management reviews will tell you if you were wrong.

I'm not sure how you've defined the criteria for individual Benefit-Risk Analysis, but I think this would be a good candidate for one to plead your case that the risk is acceptable.
 
Thread starter Similar threads Forum Replies Date
B Timeframe for updating QMS / transitioning from ISO 14971:2012 to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
D ISO 14971:2019 vs MDR Annex 1, Requirement #4 - "Manufacturers shall inform users of any residual risks" ISO 14971 - Medical Device Risk Management 2
K Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
M Gap analysis on ISO 14971:2019 with previous revision ISO 14971 - Medical Device Risk Management 3
A EN ISO 14971:2019 does not include the Annex Zs ISO 14971 - Medical Device Risk Management 4
Ronen E Informational What's new in ISO 14971:2019 ISO 14971 - Medical Device Risk Management 2
T ISO 14971-2019 doubt - Evaluate if estimated risks are acceptable ISO 14971 - Medical Device Risk Management 9
Y When will Notified Bodies require MedDev manufacturers to fully implement ISO 14971:2019? ISO 14971 - Medical Device Risk Management 1
S Practical Implementation of ISO 14971 ISO 14971 - Medical Device Risk Management 6
R Identify Medical Device characterstics as Annex C of ISO 14971 Risk Management ISO 14971 - Medical Device Risk Management 5
A ISO 14971 PFMEA Manufacturing Risk ISO 14971 - Medical Device Risk Management 2
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
B ISO 14971 Applied to Software ISO 14971 - Medical Device Risk Management 2
D Recent changes to ISO 14971 - SOP required for managing standard revisions ISO 13485:2016 - Medical Device Quality Management Systems 1
J ISO 14971 applied to ISO 13485? Low risk class 1 devices ISO 13485:2016 - Medical Device Quality Management Systems 3
A We are ISO 13485:2016 should we be audited to ISO 14971 ISO 13485:2016 - Medical Device Quality Management Systems 16
P Risk acceptability alignment between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 6
S ISO 14971 Risk Management - Questions for Hazard identification ISO 14971 - Medical Device Risk Management 2
M Informational ISO 14971 / ISO TR 24971 revision update – atualizações sobre a revisão Medical Device and FDA Regulations and Standards News 1
R The difference b/w FMEA & Risk analysis as per iso 14971 ISO 14971 - Medical Device Risk Management 8
D Risk management according to ISO 14971 - When to document risk controls? ISO 14971 - Medical Device Risk Management 10
D Where does FMEA fit in your ISO 14971 Risk Management process? ISO 14971 - Medical Device Risk Management 13
Q Information for safety EN ISO 14971:2012 - Customer Risk Reduction ISO 14971 - Medical Device Risk Management 6
M Informational ISO TC 210 JWG 1 meeting in São Paulo – Revision of ISO 14971 and ISO TR 24971 – Medical Device Risk Management Medical Device and FDA Regulations and Standards News 0
A Our auditor requires us to attend a training on EN ISO 14971:2012 Other ISO and International Standards and European Regulations 3
S In a risk analysis, how can we tie mobile app security breach to ISO 14971? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
F IMDRF opened a Consultation on Annex E & F and the link to ISO 14971 ISO 14971 - Medical Device Risk Management 4
M Updates to EN 62366 & ISO 14971? Other Medical Device Related Standards 3
D IEC 60601-1 and ISO 14971 Assessment IEC 60601 - Medical Electrical Equipment Safety Standards Series 12
M Example ISO 14971 policy and risk criteria ISO 14971 - Medical Device Risk Management 0
P ISO 13485 and ISO 14971 - one mandates the other? ISO 13485:2016 - Medical Device Quality Management Systems 8
D Rationale for Risk Acceptability Matrix - ISO 14971 ISO 14971 - Medical Device Risk Management 9
H Task analysis and ISO 14971 ISO 14971 - Medical Device Risk Management 9
M ISO 14971 and Stand-Alone Diagnostic Software ISO 14971 - Medical Device Risk Management 4
dgrainger Benefit - What is the definition of Benefit in ISO 14971? ISO 14971 - Medical Device Risk Management 7
Y Training as a risk control for ISO 14971 ISO 14971 - Medical Device Risk Management 13
W Risk Benefit Analysis - ISO 14971:2012 Requirements ISO 14971 - Medical Device Risk Management 27
thisby_ ISO 14971 - ALARP and P2 - New ISO 14971 does not allow the concept of ALARP? ISO 14971 - Medical Device Risk Management 3
C What is the difference between "Overall Risk" and "Risk"? (ISO 14971) ISO 14971 - Medical Device Risk Management 10
B New EU Medical Device Regulation & Reconciling with EN ISO 14971 EU Medical Device Regulations 41
B IFU and deviation 7 in ISO 14971 Annex ZA ISO 14971 - Medical Device Risk Management 1
B Interpreting Deviations 5 & 6 in Annex ZA in ISO 14971:2012 ISO 14971 - Medical Device Risk Management 1
B Our NB says that IEC 62304 is an ISO 14971 Requirement ISO 14971 - Medical Device Risk Management 1
B Clarification on interpretation of some EN ISO 14971:2012 & IEC 62304:2006 req's ISO 14971 - Medical Device Risk Management 46
H ISO 14971 vs. IEC 62304 vs. 98/79/EC vs. ISO 13485 (Software Medical Device) ISO 14971 - Medical Device Risk Management 1
M ISO 14971 and ISO TR 24971 revision ISO 14971 - Medical Device Risk Management 32
F ISO 14971:2012 and the FDA ISO 14971 - Medical Device Risk Management 5
M ISO 14971:2007 Revision Approved - The Delft ISO TC 210 plenary meeting - Nov 2016 ISO 14971 - Medical Device Risk Management 2
S Organizing Risk Analysis and Controls for a New Medical Device (ISO 14971) ISO 14971 - Medical Device Risk Management 4
M The future of ISO 14971:2007 ISO 14971 - Medical Device Risk Management 2

Similar threads

Top Bottom