Risk Assessments play a central role in Medical Device development. All medical device manufacturers apply risk management (they should because they have to!). All of them claim to be compliant with ISO 14971. And all of them do it differently.

I have worked with a large number of clients and I have seen more Risk Assessment variants than I can count. Some are good, some have, let's say, "potential".  

From this experience, I can deduce a few best practices that will reduce the risk assessment effort considerably.

Here are my top five tips:

Don't brainstorm to identify risks

You are required to identify and assess ALL potential risks. How do you find them ALL? That can be a daunting question for someone new to the medical device industry.

However, the solution is to be structured i.e. to use a structured approach to systematically identify risks. There exist several known methods to do this, including:

• Task Analysis (analysing the use process)
• System Analysis (analysing the system through decomposition)
• Using the ISO 14971 annex questions
• Using existing risk reports of similar devices

Regardless of the approach selected, brainstorming should not be one of them. There are a number of well-known reasons for this, the most important one being that you will miss important risks.

Next time around, try a structured technique. You will identify more risks. I promise.

Use both top-down and bottom-up Risk Assessments

Some companies rely on EITHER bottom-up OR top-down risk assessment techniques and miss out on the fact that both approaches deliver vital and often DIFFERENT risks.

Top-down risk assessment techniques (such as PHA or Task Analysis) can be done early in the development process without much knowledge about the actual design of the device. It is a great tool for early identifying use errors and probably misuses.

Once the device design is known, the selected design itself must be analysed for risks (such as materials used, geometry, movements, and energy emittance, etc.) through a bottom-up risk assessment. FMEA's are very popular and well designed for this purpose. Both these techniques complement each other and should be conducted by any serious medical device manufacturer.

Don't keep Design Controls and Risk Management in separate systems

Design drives risk. And Risk drives design. This will become apparent when you need to follow up on the implementation and verification of mitigations as well as the further analysis if mitigations introduce new risks. The glue between the design and the risks is traceability. The effort of managing this traceability in a paper-based documentation system will be VERY high (those of you who have done it will nod now!).

So is applying software tools the solution? Not necessarily, since proper traceability monitoring can not be done until the requirement management tool is integrated with the risk management tool (or vice versa). Only by automatically managing the traceability between the Risk Assessment Items and the Design Items, preferably in a single tool, can true trace monitoring be obtained.

Use reasonable probability and severity scales

I am glad to see a clear trend of tightening down the probability and severity scales during the risk evaluations. From previously having used up to 10 steps, the current trend tends towards five to six steps or less. People simply have a very hard time judging whether a probability should be six or seven on a 1-10 scale and spend too much time pondering such questions. The range of options is simply too large to be effective!

For the probability axis, I would like to endorse Dr. Johner's approach of having each step representing 2 orders of magnitude. He explains this very well by saying, that apart from such an approach lets the probability axis span over more than 8 order of magnitudes, "...the factor 100 indicates the precision which we can appreciate... If you ask a group of people, how long it takes (on average) for a hard disk to be defective, the estimates vary between 2 years and 10 years. But everyone realizes that this average is greater than one month and less than 10 years. And between these two values is about a factor of 100."

Make use of existing mitigations

In many cases, the risk assessment is carried out when the design is already known. In such cases: when coming up with mitigations for your identified risks, use the already existing mitigations in your current design!

I bet your current design already contains a whole bunch of design decisions that are risk mitigations without you really considering them as such. The absolute majority of design teams I have encountered are very, very good at designing innovative and safe devices. However, many of the design decisions taken are based on previous experience, industry state-of-the-art, or simply old habits having been refined over time. Since these engineers are often better designers than document writers, they simply do not see their design (often already in place) through the lens of risk management.

Bottom line: your current design already contains of an uncovered treasure of existing mitigations. Try to use your existing design as mitigations when performing your next risk assessment.

Aligned Elements, our medical device ALM, assists you in performing structured risk assessments. Its highly customizable risk assessment configuration can be set up for a large array of risk analysis variants. Should you be interested in a demonstration, contact us at Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.

The medical device as a stand-alone product is a waning concept.

The desire to make use of the information collected in a medical device in other health systems, coupled with recent advancements in networks and interconnectivity has resulted in more devices being connected to the Internet. As a consequence, they have become more vulnerable to hackers.

A 2015 KPMG survey found that 81 percent of health care organizations had their data compromised within the previous two years.

FBI reports (FBI Cyber Division PIN (Private Industry Notification) #140408-010) that due to the transition of paper to electronic health records, lax cybersecurity standards and higher financial payout for medical records in the black market, the "cyber actors will likely increase cyber intrusions against health care systems". 

During 2016, several ransom-attacks were launched against health institutions in the United States with wide-ranging consequences. 

FDA has shown heightened interest in cybersecurity issues and released three guidelines during the last two years. Medical Device manufacturers are likely to focus more on cybersecurity risk management activities in the near future and assign additional resources accordingly.

One integral part of the cybersecurity risk management process constitutes the risk assessment.

Performing risk assessments is a core activity in the medical device industry and many of the available techniques are well-known and well-used by industry professionals. Having long and thorough experience of risk management might lead the same professionals to believe that cybersecurity issues can be harnessed by the tools already at hand.

There are, however, key aspects where cybersecurity risks differ from traditional medical device risks.

Risk identification and the building blocks of a cybersecurity risk

The fundamental challenge during risk identification is to ensure that all relevant risks have been identified.

Verifying that this criterion has been fulfilled is often difficult and therefore structural help and practical advice is very welcome.

Due to the wide variety of possible medical device types, ISO 14971, the standard for medical device risk management, understandably has a hard time defining concrete identification techniques that are relevant enough to provide value for every kind of medical device. 

IT risk management, operating in a narrower technical scope, provides a host of techniques, tailored to this domain. Many of these techniques are based around the asset-vulnerability-threat model. 

These components can be described as followed.  

• Assets are the entities a cyber-intruder attempts to access and control. An asset has a value to the patient and therefore also to an intruder. In a safety-related context, we can exemplify assets as device configurations, health data, medical device functions, or battery power.
• Vulnerabilities represent weaknesses in the medical device that, when exploited, can give an intruder access to an asset. Software bugs, application design flaws, and insufficient input validation are examples of software vulnerabilities. But vulnerabilities can also be found in hardware, business processes, organizational structures, and interpersonal communication.
• A threat is defined as an event with the potential to an adverse impact on an asset. The threat is executed by a threat agent (i.e. an intruder) exploiting a vulnerability in order to access an asset.

A combination of these building blocks describes a cybersecurity risk. 

As a starting point, the manufacturer should be able to enumerate assets for the given device. By analyzing how these assets can be targeted, e.g. by performing a “Threat modeling analysis”, using a data flow analysis of the application, identifying "data-at-rest" (data storage) and "data-in-motion" (data transfer) will further help the manufacturer to identify vulnerabilities and threats, particular to the medical device.

Bottom-line: Identifying assets, threats, and vulnerabilities will support the manufacturer when enumerating potential cybersecurity risks. The identified items should be listed in the risk management documentation.

What is the probability of a cyber attack?

The Medical Device industry takes its risk assessment cues from ISO 14971, which defines risk as the combination of the probability of the occurrence of harm and the severity of that harm. 

The computer security industry, on the other hand, has used several kinds of assessment methods to estimate the "riskiness" of cybersecurity risks. None of them rely solely on the probability and severity of an event. Instead, these techniques estimate and/or quantify aspects of the assets, threats, and vulnerabilities that in combination say something about the computer security risk. 

So how can the medical device risk assessment methods concerned with the safety of patients be connected with techniques whose primary concern is information security?

In the AAMI paper "TIR 57 - Principles for medical device security - Risk Management", the authors address this discrepancy and attempt to transpose the cybersecurity line of thinking into the domain of ISO 14971. 

It is easy to see how the "potential adverse effect" can be regarded as analogue to the “Harm” in ISO 14971 and be quantified with a corresponding severity.

The probability factor in ISO 14971 does not have a direct equivalent in the cybersecurity risk domain. A composite factor called "exploitability" combining characteristics of the vulnerability, the threat agent, and the medical device itself is mentioned in the FDA guidelines. This factor intends to indicate the amount of work involved in order to invoke a successful attack.

The AAMI TIR57 group suggests a two-pronged approach to establish something similar, combining two likelihood factors.

The first factor, the “Threat Likelihood”, defines the likelihood of the threat agent having the motivation, skills, and resources to exploit a given vulnerability.

The second factor estimates the likelihood of harm being the effect of an exploited vulnerability.  These two factors in combination make out the probability of the cybersecurity risk.

Note that this approach is similar to the P1 (probability of the hazardous situation occurring) / P2 (probability of the hazardous situation causing harm) frequently used in the medical device community.

Information security theory recognizes that aspects and characteristics of the threat agent, the vulnerability, and the device itself drive these factors.

Bottom-line: caution shall be taken when estimating probability/likelihood/exploitability for cybersecurity risks. The manufacturer's Risk Management SOP shall address this concern accordingly and be adapted if necessary.

The drivers of cybersecurity risks

During classic medical device risk assessments, the identified causes leading to hazardous situations and potentially to harms are in most cases accidental. Although malicious use should be considered, this area often receives considerably less attention than harms caused by accidental events. 

For cybersecurity risks, the opposite is true. Here, a significant factor in the causal chain constitutes the intentional behavior of a threat agent causing harm by exploiting a vulnerability.

Whereas the software flaw might have been created accidentally, exploiting it is an intentional act.

A malicious agent may come in many shapes and forms, such as a criminal organization, a competitor, or disgruntled employees. Each of these has its own motivation, skill set, and reach when it comes to detecting and exploiting vulnerabilities, which affects the likelihood of a vulnerability being exploited as we have seen above.

Therefore, not only needs the focus to be shifted from accidentally caused risks to intentionally caused risks. The manufacturer benefits from analyzing the characteristics of the malicious intruder in order to do a proper risk assessment.

Bottom line: Manufacturers will need to shift perspective from accidentally caused risks to explicit maliciously caused risks during the identification and classification of the risk assessment.

The poisoned SOUP

Just like in the rest of the software industry, medical device companies use third-party libraries to increase productivity when developing medical devices.

These third-party libraries (or frameworks or applications), sometimes referred to as "SOUP" components (Software of Unknown Provenance) are of course also subject to cybersecurity scrutiny.

It is debatable if third-party components, and in particular open source components, are inherently more unsafe than proprietary produced applications (there are several arguments against such claims).

Regardless of this claim, it can be safely assumed that many of these libraries were not developed with a medical device cybersecurity context in mind. The security firm “Contrast Security” reports that 26% of downloaded SOUP:s contained known vulnerabilities and were still applied.

It shall be noted that SOUP:s themselves often rely on and integrate third-party software, which increases the scope of the problem accordingly.

The medical device manufacturer is responsible for any vulnerabilities caused by SOUP:s in his device and must therefore analyses his SOUP:s accordingly.

This shall include a systematic inventory of SOUP:s, actively collecting information on current vulnerabilities in SOUP:s as well as applying timely updates of the SOUP:s when available.

Bottom-line: The manufacturer must have a clear plan for how to handle potential cybersecurity risks in SOUP:s. 

Skills required to assess cybersecurity risks

Cybersecurity vulnerabilities are largely made up of software flaws. Understanding the technical details of how such vulnerabilities come into being, the technical influence they have, and how they can be mitigated requires precise software knowledge. Including software developers in the assessment group is, therefore, a highly recommended measure.

It is a misconception that all software professionals are software security professionals. The majority of today’s information security problems can be traced to flaws in code. Many software developers lack basic training and understanding of cybersecurity. 

As already mentioned, the security scope for an interconnected medical device is much larger than the device itself. The network infrastructure in which connected medical devices operate is often outside the control of the medical device manufacturer but still has a great impact on the overall risk exposure and needs to be included in the risk assessment.

It is likewise a misconception that cybersecurity is a strictly technical field. Cybersecurity vulnerabilities are not exclusively found in hardware and software but also in business processes, organizational structures, human behavior, and the environment in which the device operates. A thorough understanding of where, how, and by whom the medical device will be operated is therefore important input for the risk assessment.

Last but not least, the clinical experts are required for estimating the potential harm of compromised availability, confidentiality, and integrity of the associated data.

All these competencies are required in order to perform a comprehensive cybersecurity risk assessment and it is clear that it stretches beyond being an internal R&D activity.

The risk assessment benefits from involving stakeholders beyond the immediate software development team. If specific cybersecurity expertise is lacking in the organization, the manufacturer should consider employing or train their own experts or outsource these functions to a competent partner.

Bottom-line: the knowledge required to perform a medical device cybersecurity risk assessment is both broader and deeper than what is often immediately available in many medical device companies. 

Conclusion

The medical device industry has extensive experience with risk management and risk assessment techniques.

The cybersecurity dimension of medical device development is an additional aspect where risk assessments can enhance safety.

However, traditional medical device risk assessment techniques need adaptation in order to successfully be applied to cybersecurity risks.

Cybersecurity risks consist of other aspects and other drivers than "classic" medical device risks and are best mitigated by recognizing these differences.

Risk Management is a crucial part of Medical Device Development and if you are about to develop a Medical Device, you and your team are likely to find yourselves spending many hours compiling Risk Assessments.

There exist several techniques for performing a proper Risk Assessment but they all follow the same basic steps:

• Define your risk policy (risk acceptance criteria)
• Identify the Hazards through a structured analysis
• Evaluate the Risks by estimating severities and probability
• Mitigate the Risks that are not acceptable
• Implement and verify the mitigations for effectiveness

To get you started, we have made two free Risk Assessment Excel templates available for download.

The first demonstrates a Failuremode and Effect Analysis (FMEA) approach, a widespread technique used in many areas and industries. We often see it in bottom-up types of Risk Assessment.

The second one uses a Preliminary Hazard Analysis (PHA) approach which is an excellent top-down approach earlier in the design cycle where many of the design details are not yet known.

Both these techniques are available in Aligned Elements and we have compared and contrasted them in earlier posts.

The first amendment to the IEC 62304 was released in June 2015 and contains some welcome contributions, including:

• Clarification on the scope of the standard
• Information on how to approach Legacy Software
• Increased number of clauses applicable to Class A

There were also some interesting changes made to Software Safety Classifications in section 4.3.

For those familiar with the original IEC 62304 text, the following section describes to assign a Software Safety Classification:

"The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a HAZARD (being a potential source of Harm) to which the SOFTWARE SYSTEM can contribute.

The software safety classes shall initially be assigned based on severity as follows: 

Class A: No injury or damage to health is possible

Class B: Non-SERIOUS INJURY is possible

Class C: Death or SERIOUS INJURY is possible

If the HAZARD (i.e. the potential source of harm) could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100 percent."

This is essentially saying that severity alone decides the classification of your software system/item/unit. Since there is no consensus on how to determine the probability of software failure, the probability of a failure to occur is assumed to be 100%, effectively eliminating the probability factor from having any kind of influence on the software safety classification. 

Now, software in itself has never killed anyone. When harm occurs due to a software failure, there is always some other executing agent involved, e.g. some piece of hardware or a human actor. Consequentially, for harm to occur, there must exist a causal chain of events, tying the software to the harm via that external agent. A causal chain of events occurs with some probability, sometimes called probability of harm.

Probability of harm did not play any prominent part in the original release of IEC 62304 and focusing by effectually removing the probability of failure from the equation due to the difficulties of establishing it in quantitative terms sometimes lead to more or less absurd results. 

In examples where a failure has severe consequences but is extremely unlikely to result in any kind of harm, the software safety class is C according to IEC 62304:2006 (if no hardware mitigations exist), regardless of how unlikely the risk of harm is.

And here is where the authors of the IEC 62304:2015 Amendment 1 have done a great job reformulating the Software Safety Classification section.

The IEC 62304:2015 Amd 1 section 4.3 point a) now reads:

"a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the RISK of HARM to the patient, operator, or other people resulting from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-case scenario as indicated in Figure 3.

The SOFTWARE SYSTEM is software safety class A if:
the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM.

The SOFTWARE SYSTEM is software safety class B if:
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.

The SOFTWARE SYSTEM is software safety class C if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY.”

The pivotal point lies in the use of the terms "RISK of HARM" and "unacceptable risk". RISK, in this case, being a combination of severity AND probability.

Now, the probability of harm, (the probability that someone gets hurt) is different from the probability of failure (the probability that the software malfunctions).

The combination of these two probabilities becomes the probability of occurrence of harm. IEC 62304:2015 Amd 1, explains this further in section B4.3 and also includes a Figure (B.2) from ISO 14971.

This means that it makes sense to incorporate both the probability of failure and the probability of harm in our risk assessments. We will still stay true to IEC 62304:2006 by setting probability of failure to 1 (100%) (and avoid the problematic discussion of the probability of a software failure) and concentrate our efforts on correctly estimate the probability of harm.

The amendment of the standard also claims clinical knowledge might be necessary to correctly estimate that the probability of harm following a hazardous situation, in order to “distinguish between hazardous situations where clinical practice would be likely to prevent HARM, and hazardous situations that would be more likely to cause HARM.” This certainly makes sense since the casual chain of events leading from a hazardous situation to a harm typically takes place in a clinical context. 

There are also further complications. Where it previously was sufficient to map severity to the  “no injury”, “non-serious injury”, and “serious injury” categories, which is fairly straightforward, we now have the additional possibility of bringing in the risk's acceptability into the picture.

Establishing severity and probability is one thing that can be done fairly objectively, but in a rational manner argue why a particular combination of these factors is “unacceptable” or “acceptable” is subjective at best, opening the software safety classification establishing to an amount of arbitrariness. On the other hand, "unacceptable" and "acceptable" risks are terms defined in ISO 14971 and should therefore not be new territory to the average medical device manufacturer.

The software safety classification method in IEC 62304:2015 Amendment 1 has certainly become more intuitive. The price for this change lies in the extra effort of:

1. Establishing the probability of harm following a hazardous situation, with the involvement of clinical expertise if and where applicable.
2. Establish and rationalize what makes a particular risk limit acceptable or unacceptable, if not already defined in the general risk management process. 

To finalize this discussion on Software Safety Classification in IEC 62304:2015 Amd. 1, I would like to point out sections in the standard that have received some welcomed clarifications.

Segregation

The new version of the standard amends that segregation of software items does not necessarily have to be physical. In the 2006 version, the only segregation exemplified was hardware-related, which has lead to the false belief that segregation between items has to be physical. This is not the case. The 2015 Amendment makes it clear that the main concern is to assure that one item does not negatively affect another. Furthermore, the segregation applied shall make sense in the context it is used as well as clearly documented and rationalized.

Software Items implementing risk controls

A software item implementing a software risk control (i.e. not external risk controls which can have a positive effect on the classification) shall be assigned the same software safety classification as the software item containing the risk it is controlling. This idea is applicable not only on System level (as described in the 2006 version) but also Item/Unit level.

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304

Risk Identification is an early and essential part of the risk management process and ISO 14971 requires us to make a complete risk assessment, to identify ALL hazards. 

But, how do we know if all of the hazards have been identified? How can we prove this?

You could brainstorm or have a whiteboard session gathering ideas that pop up, but the only way to truly achieve confidence in your risk identification process is by using a structured approach. 

There are several techniques available depending on the assessed source, including:

• Assessing established potential hazards from internal records or published standards
• Analysis of the manufacturer's experience with similar medical devices
• Conducting a User Task Analysis on the user’s interaction with the device to uncover use errors
• Assessing Field data and published incidents from similar devices in use
• Assessing critical components for safe and effective use

Because of the difficulty involved with thoroughly identifying all of the hazards, ISO 14971 provides a number of aides – such as Annex C (2012) (becoming the ISO 24791 Annex A in the 2019 edition) – which provide a list of questions to assist in establishing device characteristics that may impact safety. Although not exhaustive, these questions can serve as a starting point and become one of several potential approaches from which the complete risk identification can be assembled. 

Aligned Elements users can kick start their risk identification process by downloading and importing our ISO 14971:2012 Annex C Extension, assessing them and start generating risks and mitigation. 

The ISO 14971:2012 Annex C Extension contains:

• RVT file for an ISO 14971 Annex C Question and a corresponding DOCX Reporting style template
• 37 importable questions built on Annex C in ISO 14971 to assess and integrate into your Risk Assessment

This Extension facilitates the assessment of the questions, the creation of both an automated assessment report of the Annex C questions as well as a starting point for generating new risks and mitigation. 

It gives medical device manufacturers a predefined starting point when setting up their technical file with the intention of accelerating the documentation effort.

The user is of course welcome to expand this question list with questions that are particular for his/her device and the conditions under which it needs to operate.  

The ISO 14971:2012 package can be combined with other risk identification packages from Aligned or in-house developed approaches by the manufacturer.

The ISO 14971:2012 Annex C package is free to Aligned Elements users.

For more information on how you can include our ISO 14971 questions in your risk assessment, contact the Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. today. 

Performing Medical Device Cybersecurity Risk Assessments is something we Medical Device Manufacturers must get used to. And the sooner the better, During 2016 and 2017 a mounting number of health associated cybersecurity incidents have been reported. Cybersecurity breaches may well become THE main safety concern in our industry within the next few years. Increased regulation on this matter is to be expected.

FDA has already published guidelines on its view on how medical device manufacturers ought to address cybersecurity in Medical Devices. The guidance outlines the documentation FDA expects to see in the premarket submissions as well as what is expected to be conducted for SOUPs and during postmarket activities.

At the core of this documentation lies the Cybersecurity Risk assessment. As already discussed, this type of risk assessment is slightly different to the typical Design Risk Assessment conducted during development.

To address this task, which many manufacturers will have to perform, we have developed a risk assessment template set specifically for documenting Cybersecurity risks and mitigations.

This template package is free to download and use for all Aligned Elements customers.

Are you interested in how the Cybersecurity Risk Assessment can be conducted and integrated with the rest of your Design Controls?

Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. for a free demonstration!

The Aligned Elements Cybersecurity Risk Assessment package contains:

• Risk assessment templates based on AAMI TIR 32, modeling Assets, Threats, Vulnerabilities and Risk Controls as Measures
• More than 30 Best Practice Cybersecurity Risk Mitigations ready to use

If you are looking for a Cybersecurity Risk Assessment Word Template, you can download an example here:

Cyber Security Risk Assessment Word Template

A smoother and faster IEC/ 60606-1 experience with Aligned Elements IEC/ISO 60601-1 Risk Assessment Checklist

Whenever we come across risk management SOPs from different companies, we always keep an eye open for how that company solved the requirement 7.4 in ISO 14971 to perform a Risk vs Benefit Analysis as well as the handling of Residual Risks.

In excel-based approaches it is not uncommon to see something similar to the table below:

The QMS expects that each risk (representing one row) should be addressed in the spreadsheet. When I see this, I personally feel inclined to ask:

- What happens if someone in the team does not agree that the risk is acceptable, claims that the risk does not outweigh the benefits or simply cannot decide?

In many cases, these extra columns made it into the template after an audit of the QMS to quickly fix any audit findings, a somewhat unfortunate result of increasing regulations.

Let’s look at these requirements in a bit more detail.

Is the risk acceptable?

Answering this question is very much like shooting from the hip. Either the answer is trivial, e.g. the risk is frequent and severe, in which case we should definitely control the risk as per the procedure. The other complex scenario is that it very much depends on a lot of different factors. The complex scenario is only possible to answer in the scope of the benefit of the device. Still, we often come across it as an individual item in the risk analysis.

The solution is straightforward

The principle of lowering risks as much as possible should be applied and when all possibilities for applying risk measures have been looked at, the company needs to do a proper Risk vs Benefit Assessment for the complete device.

Hint: The risk management report is a good location for this. 

Benefit-Risk Analysis

One could imagine that looking at an isolated function and weighing the risk towards the benefit of that function may give us an insight into if the function is acceptable for the device. In most cases, a function cannot be handled as an isolated part of the system, nor can the benefits of that function be easily compared to the risks it may impose on a user, patient, or operator. E.g. Trying to argue that a power unit may impose risks to a patient but having the benefit that the device needs electricity to work is not a meaningful exercise. ISO 14971 (2019) is exceptionally clear in this matter:

Good reasoning and sensible pros and cons are asked for

Here we recommend looking at the Device as a whole. Will the discovered residual risks still make it beneficial in the scope of the intended use of the device? In case of doubt, look at trying to apply additional Risk Control Measures to open risks. Remember that all identified risks acceptable or not are considered residual risks for the device. See ISO 14971 (2019) Section 6:

Once again:The risk management report is a good location for this. 

New Risks?

Claiming that there are no residual risks involved is in our opinion not possible to handle in a spreadsheet column. The questions cannot simply be answered with a yes or no. Let me be a bit provocative and suggest that this question alone could replace any risk analysis method altogether. Something like this:

Although I’ve seen similar approaches at very large established medical device manufacturers, I do not recommend this approach!

Here is what ISO 14971 (2019) has to say about it:

Bring the analysis to completion

Here we need to use our toolset properly and link the risk control measures to any implementing functions and continue with a new loop of risk analysis.

The outcome of that task will answer if there are still any residual risks present. This exercise may need to be repeated for any suggested risk control measures.

Finally, summarize all your findings in the risk management report and do not forget to remove these columns from your risk analysis templates!

ISO 14971 provides great assistance when identifying potential Hazards through its annexes, but it does lack a strong identification catalogue for Software Hazards. 

Luckily, IEC TR 80002-1:2009 Annex B comes to rescue. This Technical Report, "Medical device software - Part 1 Guidance on the application of ISO 14971 to medical device software", takes a software angle on ISO 14971, just as the title suggests.

Annex B of the report elaborates on possible software hazards and factors to consider in order to properly assess whether and how they are applicable to a particular device. 

To assist the risk identification of software hazards, we have built this extension, inspired by the Annex B of IEC/TR 80002-1. 

It includes:

• RVT file for a Software Hazard aspect and a corresponding DOCX Reporting style template
• 70+ importable potential Software Hazards to assess and integrate into your Risk Assessment

You may of course expand this hazard list with hazards that are particular to your device and the conditions under which it needs to operate.  

This extension package can be combined with other risk identification packages from Aligned or in-house developed approaches by the manufacturer.

The "Software Hazard Identification based on IEC 80002-1 Annex B"  extension is free to Aligned Elements users.

For more information on how to include the hazards in your risk assessment, contact the Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. today.