Tag Archive for: risk management

With the rapid innovation in digital health such as clinical web and mobile software applications which do not traditionally classify as a “device” due to its lack of custom electromechanics, the Software as a Medical Device guidance (SaMD) was adopted by the FDA along with global regulatory leaders to ensure such software products adopt the same general medical device principles to demonstrate safety, effectivity and performance. The creation of SaMD was heavily influenced by new entrants unfamiliar with medical device regulations and terminology developing a broad spectrum of applications in order to support the new and growing industry. 

On August 25th, 2020 Jama Software’s Clay Moore moderated a webinar featuring Beanstock Venture’s CEO, Shawnnah Monterrey, and past and present members of the FDA including John Murray and Bakul Patel.  

Watch the full webinar now or read an abbreviated version of the transcript below. 

My Software Is a Medical Device (SaMD). Now What?

Isabella Kennedy: As an industry, we are starting to see an influx of software applications being used for clinical support to inform clinical decisions, diagnosis, and treatment. We thought with all the new entrants unfamiliar with medical device regulations, it might be helpful to provide an overview and answer some questions. We’ve put together this amazing team of panelists that come from different organizations with tremendous offerings. 

For example, BeanStock Ventures provides Software Online Agile Regulatory training, otherwise known SOAR, QMS, DHF audit and assessments, as well as medical device software development. Software CPR provides expert regulatory and standards compliance advice, FDA negotiations and strategies, and internationally recognized training courses. 

We are all, of course, familiar with the FDA that provides numerous guidance documents related to software and specifically, in this case, SaMD. Jama provides software lifecycle management tools to aid in automating the process in facilitating compliance. As a follow-on, we will be sharing helpful resources from each company that might be available with you. 

 Let’s just have the panel members introduce themselves, starting with Shawnnah Monterrey. 

 Shawnnah Monterrey: Hi, I’m Shawnnah Monterrey, CEO of BeanStock Ventures. 

Clay Moore:  This entire category is around the definition and classification that drives regulatory status. 

 As technology evolves, and software becomes a platform and location independent, it is more important to understand what it does rather than where it resides. How does one determine if their software product is a medical device? Can you describe some elements of an intended use statement? 

John Murray: Well, I think that everyone needs to understand that you can describe a device or a product in multiple, multiple ways. You can have engineering description, architectural description, all this stuff. But intended use is kind of special. It’s a special subset of all of that. 

The focus of that description or that understanding, you need to focus on the patient and the practitioner. I think that’s the very important thing. I’ve seen lots of descriptions that don’t talk anything about the patient or the clinical use. When you’re addressing intended use, you may get confused by the definition and the regulation.  

But you need to start asking yourself basic questions. Some of the questions I’ve come up with are, “So, I’m a doctor. How is this product going to make me or help me practice medicine better? How is this product going to help my patients live better lives?” Those focuses, clinical focused questions are very important to be honest about when you’re addressing that intended use statement.  

That’s my first comment on that. Number two is that you have multiple customers here. You have the engineering staff, RAQA, marketing, and clinical staff. My suggestion before you tackle the intended use statement is to take a step back, and write a software product description, and get input from all four of those groups. 

You need to balance the wheel and you’ll end up with a document that basically everyone can read, everyone understands. That will become the first step to risk management, the first step to design, the first step to regulatory status. It’s well worth the money and the time to do this correctly. The third caution I have about intended use is it’s never static. You start out today with an intended use and everything is well under control. 

You design a great product, you have great customers, everything is fine, but before you know it, it’s being used in a different way. Your marketing team starts selling it in a different way. You need to make sure you keep that dynamic and alignment correctly. You don’t want to be in a situation where your intended use is stated this way, but your marketing intended use is a different way.  

There are three things. One is to lean towards the clinical and patient. Write a full software product description. Number three; keep track of the dynamic because every SaMD that I’ve ever seen is always sliding into the future. It never stays the same because once you have it, you go, “I can use it for this now. This is a great opportunity so let’s move on.”  

RELATED: Your Guide to Selecting a Medical Device Development Platform

Clay Moore: That’s fantastic. I think we’ll spend some more time later talking about the iterative nature of SaMD products. Bakul, what’s some additional thoughts that you might have around intended uses? 

Bakul Patel: Yeah, I think John hit up on most of it. I will just add to the concept of the clinical views and who the user is. From IMDR, and through work that we’ve done in defining and categorizing what Software as a Medical Device should look like and what’s a clear that definition looks like, I think we spend a lot of time talking about that. 

Internationally, we thought about two things. What the software is doing. Where it’s going to be used. Who’s going to use it. How it’s going to be used. If you think about what the software is doing in the care, in the practice and then you have the other dimension of the context of sort of where it’s going to be used. Context is a bigger situation.  

The term that we use in the IMDR framework is the healthcare situation and condition, which means it considers the disease, the condition of the disease through a varying spectrum of the disease you are trying to target. It’s not everything and anything. You can’t just say heart disease and cover the entire gamut because there are many things that you need to consider. 

Even in there, there is a spectrum. Then you have the user who is going to use it in certain areas and certain types. Just working through the logic of where it’s going to be used, who’s going to use, and how it’s expected to be used. It’s sort of honing down on your intentions. I like the point John made about it’s not static. I’m going to give you a non-static version of what John was talking about. 

Not just about static, about QMS. Start thinking you want to do this but then you find out your technology can only do this. There’s a difference between where you started and where you ended up. The result and what you want to put out to market should be exactly to what your product is performing. I think when that alignment happens between what the product does versus what you want the product to do is really what the regulatory terms calls intended use. 

Clay Moore: Thanks for that additional context there. Shawnnah, what are some other thoughts you might have around intended use? Also, if you could start to peel back a little bit and talk about what if there are gray areas and we’re not sure about whether this really should be classified as SaMD? 

Shawnnah Monterrey: Sure. I like to break down the intended use into four pieces. I like to focus on the user, the end user of the clinical product, the clinical utility of the product, the environment in which it’s going to be used, which could vary, and also the demographics of the patient. 

Giving you an example, maybe I can walk through a simple example of maybe a heart monitor. A heart monitor, the environment would be, for this particular product, would be home use. The end user for that would actually be the patient. The demographic of the patient let’s say it’s age, I don’t know, 55 and up with heart condition that can be self-monitored.  

The clinical utility is to monitor heart arrhythmia. Obviously, you would start there, and you can extrapolate further but I like to divide it in those areas to make sure all aspects of the intended use are covered. In terms of an example, I can give one particular example. I’m not sure if it’s still valid but if you consider Fitbit as traditionally not a medical device.  

I think they’re moving towards getting it cleared or they may have cleared a version of it as a medical device in recent times. There was a lot of clinical applications being built on top of Fitbit. How do you determine if your product is a clinical device at that point if you’re taking data from the Fitbit and displaying it to an end user? 

If you’re just taking data that’s being provided from the actual tool itself and you’re just passing it through, reading it basically, and rendering it, showing it on the display, generally, that’s not necessarily considered a clinical device. But if you take that data and you start providing additional analytics on top of it or start making clinical inferences based on that data, that’s the point where start getting into the medical device space.  

RELATED: How to Executive a Successful Design Review When Building Medical Devices

Clay Moore: That’s great. What if the software helps the patient to not be in a clinical setting, if it’s used at home? John, maybe you’ve got some comments on the, again, would we think of this as something that’s being classified as SaMD or not?   

John Murray: I don’t think that the device, not a device question starts with at home use or in clinic use. I think that’s a secondary question. It may determine the actual classification of the product. The product may be for monitoring blood glucose, take an example. You could have one product that’s for design to be used in a clinic, one for use at home. They may have different risk determinations. 

That may make the classification different. It always must start with the specific intended clinical use, in my opinion. Part B would be now what’s the risk of this application? That varies depending upon the patient population, the environment of use, and a bunch of other questions that could come into being. That would be how I would start framing that up as a question. 

Clay Moore: That’s great. Bakul, any other commentary on example of things that are SaMD or aren’t SaMD? Maybe some gray areas. 

Bakul Patel: Yeah. Recently, in the act or jurisdiction doesn’t extend to things that are not meant for clinical purpose. It must be for caring, mitigation, treatment or preventing a disease. That’s statutory definition. 

An activity tracker just measuring how many steps you’re taking per day and helping you stay healthy is not something we would consider as a medical device even from that perspective. Then certainly, I think this is what Shawnnah was talking about, is you take that steps and say because you took X, or you took less or took more steps, it means certain disease, or it means certain condition.  

Clay Moore: Great. I think each of you mentioned risk at some point in time during each of your responses. Let’s move into more the things that are related to risk and the amount of effort that’s behind these things. Once a company determines their software product is a medical device, the next step is to determine its risk category. 

Risk categories are used to determine the rigor required to ensure that the product is safe, is effective, and it needs to perform its criteria necessary. For SaMD, risk is classified using a framework where one is the lowest risk and four is the highest risk. John, can you discuss why understanding risks is important when developing and maintaining a software to medical device? 

John Murray: Well, the fundamental basic idea is you don’t want anything bad to happen to good people. That’s the purpose of all these rules. We want to make sure your product doesn’t hurt anybody in a way that’s preventable. That’s the simple explanation of that. I want to talk a little bit about one of the special elements of SaMD in my opinion. 

That is that we have a specific risk category that I often see with many of my clients gets left off. I’m going to call that engineering or environmental risk, which is a little bit different than clinical risk, traditional clinical risk. Because you know you’re using a SaMD, you need to think about all the elements of that platform choice that may have an impact on harming people.  

It may have an impact on risk. The beauty of this is that once you set up this model, you can reuse these questions repeatedly with every product. One simple example is what if the Bluetooth connection becomes lost? What kind of impact is that going to have on my patient? What kind of impact is that going to have on my delivery of my intended use? 

All the known features of a general-purpose computing platform, wi-fi, Bluetooth, all that kind of stuff, you can ask those questions. The beauty of this is that I know the engineers are asking these questions all the time. Those questions never get translated over to the regulatory side where the risk management thing is set up. 

The idea is that you want to do what you can do. Maybe if you lose Bluetooth for five seconds, it’s not a big deal but what if you lose it for an hour or two hours? There’s a huge number of SaMD applications where you can lose that connection for a short period of time. It’s not going to be an impact. Do you need to know when that happens, and do you need to inform the patient when that happens? In some applications, a patient needs to know they’re not connected. 

One of the other ones that I thought of and we saw in some recalls was that what if you start your algorithm, and you are resource deprived? You don’t have the right amount of memory. 

You don’t have the right amount of algorithm power, computing power. All these questions, I know they get asked all the time by the engineering staff. The engineering staff needs to be accustomed to contributing that information to the design and to the regulatory affairs side so that when you present your case, you’ll say, “Yeah, we covered all the environmental engineering risk and here’s our list here.”  

That gets sandwiched together with the clinical risk, which I’m not a doctor so I don’t like to talk about that very much. That’s a hugely important thing, is being honest. Being honest that bad things can happen, but will they have an impact on my clinical application? 

Clay Moore: Shawnnah, why don’t we go over to you and would love to get some additional color on that as well as maybe thinking about what are some aspects that influence safety, effectivity, or performance? 

Shawnnah Monterrey: When I look at performance, I think about technological performance and analytical performance. From a technical perspective, especially for a SaMD product where it can be hosted in numerous environments, you really want to go back and understand how the operator is going to be using your system and the impact that that environment may have on your product. 

I’ll give you an example of something that could impact performance for a hosted cloud application could be the latency of the network. Something you can’t control, so it’s important to really understand the environment in which your product is going to be used and then how that would then influence some of the safety associated with some hazards to be identified. 

A top four list can include stuff like no result. What would happen if the network goes down and the end user wasn’t able to receive results? Delayed results as a result of network latency and is there any impact to false positive or false negative as a result? I think network latency may not directly influence a false positive and false negative but results in a no result or a delayed result. 

That’s something that you should assess and determine the severity based on, again, the intended use of your product. From another performance perspective would be the analytical side. That’s focused more on the sensitivity and specificity of your product and really, looking at a false positive and false negatives. 

That requires, again, an understanding of your demographics. What is that patient population that is needed to be able to truly test your product to show and prove the analytical performance of the system?  

Clay Moore: There was a question around the differences and overlap between SaMD when it’s a mobile medical application and software is inside a medical device considering the same software can be leveraged across different user contexts. 

Bakul Patel:  I think the intended use of a piece of software does not rely specifically on the platform that it’s residing on. I think that’s one thing you have be very clear about.  

 The software is going to take advantage of the computing resources and the surroundings of that environment is what I call it. I don’t think it matters from that perspective. Whenever somebody makes a choice to put a product out, they intentionally market it or design it for a particular product or platform. 

When you choose that, I think you need to make sure that you know all the things that you are going to depend on or not depend on in that platform. It could be a multi-thread application or a multi-thread operating environment, but you may not use multi-thread for all kinds of various reasons. 

You may know using multi-threading applications may lead to some issue that may raise conditions and you may want to think about that. When you start using operating systems and you are using instructors and you have multi-course going on today, you are going to have to say that, “Even if I used a simple programming language to be on a certain platform, the platform may use my program separately because you have different threads running.” 

Just knowing that will help you start answering some of the questions about what do you have to mitigate? How to reduce the risk to a minimum. How do you consider that? I think cloud services is very similar. I think you have very different challenges. Mobile is the same. Very different challenges and different sort of advantages. You just take those into account.  

To see more information specific to the medical device development industry, we’ve compiled a handy list of valuable resources for you!

SEE MORE RESOURCES

ISO 14971

Last week, Jama Software launched Jama Connect® for Medical Device Development, which helps teams speed time-to-market without compromising quality or compliance.

In our experience working with more than 200 medical device developers, we’ve realized how important it is to create best practices for risk management under ISO 14971, the FDA’s mandatory standard for risk assessment throughout the product development lifecycle.

In this post, we’ll outline the main clauses of ISO 14971 and explain how Jama Connect can help medical device developers build better, safer products that satisfy ISO 14971.

What is ISO 14971?

ISO 14971 is an international standard that sees risk management as a product lifecycle process encompassing the development, production, and post-production stages. Jama Connect offers a straightforward approach to managing risk according to ISO 14971 in one platform. The standard was updated in 2019, providing more guidance on risk management and adding more detailed requirements.

Managing Risks & Requirements for ISO 14971

Risk management is an inextricable part of the medical device development process. For medical device developers, risks are a core principle of product development and should be tied together in one powerful platform.

Many medical device companies continue to depend on Excel to capture risk data, but Excel simply can’t provide the end-to-end traceability necessary for satisfying ISO 14971. That’s where Jama Connect comes in: It allows teams to easily connect risks, requirements, and testing in one system where requirements and test results stay live in real-time.

Jama Connect and ISO 14971

Jama Connect guides compliance with Clauses 4 through 7 of ISO 14971, which covers how risk should be managed throughout the product development process.

RELATED: Understanding Integrated Risk Management for Medical Device

Risk Management Plan

Clause 4 of ISO 14971 concerns how risk is organized and administered for your product line. It requires the formation of a Risk Management Plan throughout the development lifecycle.

The Risk Management Plan is the record of a planned process for risk management: who does what and when, how risks are scored, etc. It’s a component of the Risk Management File, which contains all the outputs for risk.

Clause 5: Risk Analysis

Clause 5 of ISO 14971 requires that medical device developers identify potential hazards and hazardous situations. Each hazardous situation and its potential consequences must be evaluated. Jama Connect helps teams satisfy Clause 5 by defining device-specific hazards and capturing risk probability and severity.

Jama Connect offers risk management item templates to capture important information about the risk analysis process, including a description of the device, intended use, and the scope of the analysis.

Teams can identify and evaluate potential hazards, sequences of events, hazardous situations, and harms in a single item type.

Clause 6: Risk Evaluation

Clause 6 requires the evaluation of risk for each hazardous situation and the definition of acceptability criteria for determining when risk reduction is required. To satisfy Clause 6, teams take the inputs from Clause 5 and determine the risk level for each hazardous situation.

In Jama Connect, risk acceptability criteria can be customized for a particular product line or medical device classification in the risk management item.

RELATED: Understanding FDA Medical Device Class and Classifications, and its Impact on Requirements Management

Clause 7: Risk Control

Clause 7 requires risk control measures to be developed, implemented, and verified across the product development lifecycle. Risk control measures could include product design, preventative measures in the product, and labeling. Residual risk must be evaluated against acceptability criteria, and risk control measures must be reviewed in case additional risks have been introduced inadvertently.

The risk evaluation item lets users identify risk control options for a specific hazardous situation, such as inherent safety by design, protective measures in the medical device or manufacturing process, and safety information.

Risk control measures, implementation verification, and verification of risk control effectiveness can also be accounted for in the risk evaluation item. Links to system requirements and verifications in Jama Connect can easily be created from the risk item to demonstrate traceability from hazardous situations to risk controls.

Clause 8: Residual Risk

Clause 8 requires an evaluation of the medical device’s overall residual risk. If the overall residual risk is unacceptable, it must be demonstrated that the medical benefit outweighs the residual risk.

When defining risk control measures, teams can capture those measures in Jama Connect and link them directly to risks before updating the rankings to determine the residual risk level.

With traceability through all phases of risk, users can quickly identify potential pitfalls in the product development process and address them before they become bigger barriers to success.

The Bottom Line

ISO 14971 requires a cohesive, well-documented narrative of your product’s lifecycle to assure the FDA that the device is safe, effective, and compliant. Any decisions or actions that aren’t documented could keep your product from reaching the market or result in a recall.

Finding and fixing errors early in the product lifecycle saves money, speeds time to market, and improves product quality. Jama Connect allows medical device developers to review risks and risk controls holistically so that teams can operate with confidence.

From a compliance perspective, the Jama Connect for Medical Device Development illuminates the risk management and product development process, while simultaneously generating the required documentation to support that narrative.

For a deeper dive into ISO 14971 and how Jama Connect for Medical Device Development offers a comprehensive way to manage risk and requirements throughout development, download our white paper, “Application of Risk Analysis Techniques in Jama Connect to Satisfy ISO 14971.”


medical device risk management

Building and then bringing a medical device to market as quickly as possible—all while preserving acceptable levels of quality and regulatory compliance—requires adept medical device risk management. By minimizing potential risks such as mislabeling and software-related issues, medical device manufacturers make each product safer for the patients who will use them. All of these risks and others are present through the product development lifecycle, where they must be addressed through specific risk management activities

The ISO 14971 standard, as encapsulated in ISO 14971:2007 and then revised in ISO 14971:2019, is the modern framework for such efforts. An FDA Recognized Consensus Standard, it has a nine-part structure defining the criteria for medical device risk management during production and post-production. ISO 14971 is also required by higher-level regulation under ISO 13485. All medical device companies follow ISO 14971, but their individual approaches to the risk management standard will vary based on not only product type but the actual tools used for handling risk analysis and control measures as well.

Risks as requirements: What’s the best approach to medical device risk management?

Effective medical device risk management is integral to patient health and safety. A study published by The British Medical Journal found that one in 20 patients experiences preventable harm when receiving medical care. Moreover, many medical devices in active use are many years old, meaning that even flaws implemented long ago can continue to pose risks to patients. That means risk must be curbed at every stage of the product lifecycle.

Another way to look at it: Risks are central requirements when it comes to the medical product development process, and safely managing them in accordance with ISO 14971 requires a comprehensive modern solution capable of delivering the necessary coverage, speed and preparation. Risk management is requirements management in the medical device industry. Accordingly, it’s crucial to have the capacity to, for instance, connect eventual verification tests back to requirements, so that teams can be confident of adequate risk mitigation.

However, many existing workflows and tools cannot consistently ensure acceptable compliance, leading to the possibility of recalls, or inadequate workarounds such as alterations to the label or instructions-for-use. Spreadsheets exemplify the limitations of older approaches to requirements management and risk management during the medical device lifecycle.

The problem with document-based processes

Medical device manufacturers may rely on Microsoft Excel to capture risk data and fuel their risk management planning and reporting activities. The potential problems with this approach include:

  • Limited scalability to teams working at multiple locations.
  • Siloed data sources that take time to comb through and reconcile.
  • Human factors such as miskeyed entries or inadvertent deletions.
  • Difficulty proving compliance, due to lack of end-to-end traceability.

Taken together, these issues make it onerous to maintain and execute on a medical device risk management plan that fulfills all provisions of ISO 14971. This standard requires a combination of risk analysis, evaluation and control – all processes that a risk management plan helps simplify by documenting all of the potential risks across the product lifecycle.

How to more reliably put a risk management plan into action

The risk management planning process should produce a plan that contains product-specific data and follows all standard operating procedures in the domain. The plan should also be a living document that can be continually updated as requirements and risks evolve, as it will serve as the blueprint for ongoing risk management activities such as reporting on hazards and risk control measures and also linking back to requirements. Ensuring acceptable levels of detail and accuracy in the risk management plan is much easier with an all-in-one solution than with a collection of discrete documents.

Let’s say a hypothetical medical device company was developing an MRI machine. If it were centering its risk management processes within a massive Excel sheet, lots of valuable time would be lost to stakeholders on the development team having to constantly review the requirements in the shared asset.

Plus, this highly manual, error-prone process can itself create further complications for overall medical device risk management, such as a risk going initially overlooked due to outdated data in a spreadsheet cell. Going back later to write a report about the risks is not a great alternative to building in risk management throughout the development process—but the right tools are needed for the latter strategy.

By switching to a more modern solution, this development team could instead:

  • Take advantage of risk plan templates to ramp up more quickly.
  • See live risk mitigation data, not outdated entries.
  • Avoid the various administrative risks of Excel, like splitting/merging cells.
  • Easily adjust probabilities and severities of the defined risks.
  • Enable real-time collaboration between teams.
  • Visualize and trace risks across the whole product development lifecycle.
  • Prove ISO 14971 and other regulatory compliance more easily.

At the end of the development process, the team making this hypothetical MRI machine would be able to see clearly how its verification tests traced back to the risks and requirements it initially set. More specifically, they would know if the product could move the right amount of air, survive the expected transport and storage conditions and comply with all applicable rules and regulations.

Demonstrating ISO 14971 compliance with Jama Connect

Jama Connect offers a modern alternative to document-oriented processes for medical device risk management. Jama Connect is built to help streamline compliance with ISO 14971.

For example, Clause 7 of ISO 14971 requires attention to residual risks, or those risks that exist even after all risk control measures have been implemented. In Jama Connect, those measures can be efficiently defined and linked to corresponding risks for maximum traceability. That way, teams can spot potentially unacceptable risks early on in development and mitigate them before the associated costs and logistics become impractical.

There are many other features within Jama Connect for complying with all clauses of ISO 14971 and modernizing your general approach to medical device risk management to keep up with changes such as the FDA’s Safety and Performance Based Pathway. To learn more, connect with an expert today.

To learn more on the topic of risk management, we’ve compiled some helpful resources for you.

LEARN MORE

 

 

Risk Management in Medical Device Development

Risk management plays a pivotal role in medical device development, helping ensure patient safety and product quality. Risk management is often misunderstood. It’s a process that could be cumbersome for organizations who don’t know where to get started, or worse, start too late in their development process.

After our recent half-day risk management seminar in the Netherlands, we sat down with award-winning medical device risk management educator, author, and consultant Bijan Elahi to hear his thoughts on risk management in medical device development.

Read the full interview below for Elahi’s take on the importance of risk management, best practices, and how use it to gain confidence in your compliance.

Jama Software: Thank you for joining us Bijan. For our readers who may not be familiar with your work, can you tell us a little bit about your background and experience with risk management?

Bijan Elahi: I’ve been doing systems engineering and risk management for the last 30 years, beginning my work in the aerospace industry at various companies, with my last job at NASA. In the early 1990s I was approached by the medical device industry for help with risk management. This was a time when there were no standards for medical device risk management, and medical device companies had no consistent way of doing risk management. I began helping one medical device company, then another, and soon I changed industries altogether, from aerospace to medical technologies.

The first version of ISO 14971 was published in the year 2000, finally providing risk management guidance to the global medical device community. I’ve been helping medtech companies understand that standard and apply it to product development ever since. In the last five or six years, I’ve also started teaching and consulting in risk management more broadly.

Jama Software: Looking back at your work in risk management, can you summarize for us what it is and why it’s so important to medical device development?

Bijan Elahi: Risk management, in a nutshell, is the process of identifying hazards, estimating the risks, controlling the risks, and then monitoring and reporting how you did. But once you identify the hazards, you also need to know why they happened, what are the causes of those hazards, and then what you can do to minimize the risk of harm from those hazards. Risk management is both an art and a science. It is not like mathematics that is perfectly clear. There are a lot of grey areas in risk management that require sound judgement and both a creative and a scientific approach.

Risk management is important because you can’t commercialize a medical product without it. It’s legally required to perform risk management before you can get approval to sell your product globally. Second, it helps you make safer products. We have a moral obligation to our patients to make the safest possible products for them.

It’s also important for business and financial reasons. Poor risk management can be expensive and often results in recall costs and even punitive damages. If you make safe products then you’ll have a better reputation, and you can sell more. In addition, it helps save money in product development, because risk management allows for the early identification of design weaknesses and allows targeted allocation of limited engineering resources with priority to the safety critical areas. 

Jama Software: What are some risk management best practices product developers should consider as they’re moving through the development cycle?

Bijan Elahi: One of the things that medical device developers should recognize is that risk management should be done as early as possible. Even as early as the concept stage. Another thing is having a robust process for risk management that is both compliant and efficient. You can get really complex with risk management. So, avoid overcomplexity and have a process that is both understandable and explainable. Understandable to your own staff and also to regulatory bodies. When you have a regulatory auditor or reviewer asking questions about your risk management process, if you can’t help them understand, your process isn’t working. Because ultimately, you need to persuade a regulatory authority to approve your product.

Read our eBook to learn more about risk management for Class II and Class III medical device development.

Jama Software: You spoke in your presentation about an old vs. new way of thinking about risk management, can you expand on what you meant for our readers?

Bijan Elahi: The old way of thinking was where product developers saw risk management as a necessary evil. They would be focused on the design of the product and making it work. And then when they finished the design, they would say, “Well, if we’re going to commercialize this product, we need to show that we did risk management, and find somebody to do a retrospective analysis and write a report that this product is adequately safe.” That’s old thinking. The new way of thinking is to consider risk management as a value-added activity and a partner with product design. Risk management and product design should work together in lockstep. This way, we get real value from risk management.

In fact, regulatory bodies today expect this new way of doing the work. They don’t want to see that you didn’t do any risk management during the development process and that at the end you just wrote a report to retrospectively cover your bases. This way of thinking is not only bad for your company, it’s also bad for the consumer and bad for the product. A lot of times if you have finished your design, and then suddenly you make a discovery of a safety hazard, it may be too late to fix it or maybe just too expensive. Some companies would just try to somehow get the product out anyway, which is bad for everybody and doesn’t really save you any money.

Jama Software: Let’s talk a little bit about the latest version of ISO 14971 that was released at the end of last year. Have you had a chance to review the latest 2019 version and are there any new changes developers should be aware of?

Bijan Elahi: Yes, I have. ISO 14971 is the international standard for medical device risk management, and it is recognized by most countries. It is a very important standard because conformance to it is the easiest way to establish the safety of your medical device and to persuade a regulatory body to approve your device. The 2019 version has some changes in it, but they are not so extensive that they would overburden the manufacturers. There are some new definitions and some changes to existing definitions.

Also, there are some new concepts that are introduced. For example, in the 2012 version, the requirement was to reduce the risks “as far as possible.” In 2019, a new concept is introduced to reduce the risks to “as low as reasonably achievable.” And then in the previous version, 2007, there was another concept called “as low as reasonably practicable.” So, there are now three concepts in the most recent version about how can you strategize about reducing risks.

Jama Software: Speaking of changing industry regulations, one topic that’s been top of mind for medical device developers in Europe is the upcoming EU Medical Device Regulation (MDR). Is there anything that developers should consider when getting ready for MDR?

Bijan Elahi: Yes. MDR really created a ground shift for the medical device manufacturer. It caused a lot of change, and it’s more of a quality regulation. Some of the biggest changes with respect to risk management are the requirement to submit an annual Periodic Safety Update Report (PSUR). The PSUR is for Class II, and above medical devices. Another requirement is Post-Market Surveillance Reports (PMSR) for Class I devices. There will also be more emphasis placed on post-market clinical follows ups. The regulators expect you to continue to follow up your product and to see how it is clinically performing.

MDR puts more emphasis on post-market surveillance plans. You’ll need a plan ahead of time for surveilling your medical device and how it performs in the field. You’ll also need to identify and declare the lifetime of the medical device and provide a rationale. Article 88 in the MDR also requires trending, which will result in more reporting required by the manufacturer. If an adverse event hasn’t happened yet, but looks like it’s going to happen, then you have to report that too.

Jama Software: Interesting. So, you need to anticipate risks before something happens and there will be more documentation required?

Bijan Elahi: Yes. Before, we had vigilance reporting. Which means something bad has already happened, and you had to report it to the governmental agencies in Europe. Now in addition to vigilance, you have to predict if something bad is going to happen and report that as well. 

Jama Software: Do you foresee any changes to risk management or requirements management being impacted by MDR?

Bijan Elahi: Good requirements management is just so smart to do for better and more efficient product development. I use it in risk management as well.

Basically, I treat hazards, risk controls, and safety requirements all as elements in the requirements management system. So, they’re all connected and traced. Traceability is another thing that is really emphasized in ISO 14971. It is so easy to do traceability with a requirements management solution like Jama software and, so hard to do it manually.

If you try to do it by manually, e.g., with an Excel spreadsheet, it’s so easy to lose traceability and have errors. It’s also hard to maintain. Anybody who has done traceability analysis knows how much work it is and how hard it is to maintain it because designs are dynamic. Things change all the time. Anytime you make a change, you could break your traceability. This is one thing that I always advise my students and my clients, to use a tool like Jama Connect.

Learn more about how Jama Connect™ helps medical device developers streamline and speed up the development process while reducing risk.

Jama Software:  Are there any specific best practices or any highlights that you can address in regard to risk and requirements management together? In regard to the discipline of combining those two and how they can help product development and launching products. 

Bijan Elahi: Yes, I am a strong believer that risk-management and requirements-management are better together. For example, safety requirements: How do you know which requirements are safety requirements? A safety requirement is that which is linked to a risk control. As risk controls themselves are elements in the database, if you link some of your requirements to those risk controls then you can tag those requirements as safety requirements.

Sometimes when you are audited, an auditor asks you, “What are your safety requirements?” With the explanation that I just gave, it is very easy to run a query with a solution like Jama Connect for all of the requirements that are tagged as safety and get a list of them. Very easy to do! Without a tool, it’s not so easy to answer that question.

Another example is connecting Failure Modes and Effects Analysis (FMEA) analysis to your risk management. The tool can help manage the connections of the causes and effects that lead to hazards. Again, those causal factors themselves could be elements in a database which are linked together and that creates what’s called a sequence of events, which explains how a hazard can manifest itself. By creating this chain of events, you can connect the hazard to the hazardous situation, and subsequently to the harms. You can do a quantitative computation of risk, if you follow this methodology.

Jama Software: What are some common mistakes that you’re seeing medical device developers make in their risk management process?

Bijan Elahi: The first mistake that comes to mind is actually just an approach that is suboptimal. One of the things that many device manufacturers do when it comes to assignment of severity of harm is assign just one classification to it. For example, if you are infected, they would ask, “What’s the severity of the infection?” And they would assign a severity classification like serious or critical. These are key words that I’m using, by the way.

The thing is that a harm doesn’t create just one kind of outcome, but multiple outcomes. For example, an infection could cause anything from just a little bit of a fever, to organ failure, to even death. So, it’s not best practice to assign only one severity class to a harm. It’s best to assign a spectrum of severity classes to harms.

Jama Software: As we enter a new decade and medical devices are becoming more complex and more embedded in our everyday lives, how do you think risk management might change?

Bijan Elahi:  Well, I think risk management is going to become more and more important. Especially with the introduction of EU MDR. EU MDR puts more emphasis on risk management. I see a lot more ‘risk-based’ language everywhere. Decisions need to be risk-based. That applies to all kinds of decisions, including design changes and verification testing. If you’re going to make ‘risk-based’ decisions, you need to know what risk is. And where you get risk information: is from risk management. Risk management is a progressively more prominent endeavor in medical device development.

Developing medical devices in Europe? Join us on February 21 in Belfast, UK for our half-day seminar, “Risk Management for Medical Devices: The Expectations of ISO 14971.”

Grifols Improves Medical Device Development

Spanish multinational pharmaceutical and chemical manufacturer Grifols is the leading producing of blood plasma-based products. With over 21,000 employees in its four divisions—Bioscience, Diagnostic, Hospital, and Bio Supplies— Grifols develops, produces, and markets innovative medical device solutions and services in more than 100 countries.

As a leader in the future of healthcare, Grifols strives to set the standard for continuous innovation, quality, safety, and ethical leadership. On an operational level, it knew that its requirements and risk management processes played a key role in facilitating innovation, and its current solution wasn’t up to the task.

Grifols Sees Opportunities for Process Improvement

When Grifols’ Diagnostic division began a new project in 2018 to improve the management of disease detection in blood bank laboratory operations, the company knew it had an opportunity to improve its requirements and risk management processes. While the company’s legacy solution had served its purpose for many years, the task of reviewing requirements was arduous. The solution was also unable to facilitate the collaboration needed to keep the project’s team — split between Spain and the United States — on the same page.

“Our globally dispersed teams need to work on the same projects and using our previous legacy solution was very slow,” said Carmen Pazos, Diagnostic Divisions R&D Instruments Senior Manager at Grifols. “We experienced performance issues. We were looking for a way to expedite the process.”

Legacy Solutions Impede Innovation in Medical Device Development

Not only were the processes tedious and error-prone, but since Grifols’ products are considered medical devices, they must also comply with ISO 14971 — the standard for the application of risk management to medical devices. So, on top of Grifols’ manual process being time consuming, it also made things difficult to document and prove compliance.

It was then that the Diagnostic division was introduced to the solution that Grifols’ Hospital division had been successfully using. “When I saw how Grifols was already using Jama Connect, I thought, ‘I really need that,’” Pazos said.

Learn more about how Jama Connect helps teams improve medical device development.

Grifols Improves Risk Management and Speeds Development

Within two or three months, Grifols began working from a medical device pre-configured template within Jama Connect on a small, low-risk project to test its capabilities. Things went well and Grifols began implementing Jama Connect into more projects.

The immediate benefits the Diagnostic team saw from Jama Connect were how user-friendly and intuitive it is, while also keeping people in different time zones instantly in synch. The ability to comment and facilitate robust discussion within Jama Connect helps remote teams drive clear agreement on project items while also automatically building an audit trail for compliance.

And the results are also worth mentioning. Within months of onboarding Jama Connect, Grifols reported:

  • Savings of 80 hours or more per project
  • Review cycles reduced from three months to fewer than 30 days
  • Requirements linked to risks, tests, and executions for traceability
  • Improved communication and efficiency
  • Reduced rework

Read the full case study to see how Grifols was able to increase efficiency and cut costs by optimizing their requirements and risk management process with Jama Connect.

You’ll gain more confidence that your recently-released products avoid recalls, fines, or worse if you perform failure mode and effects analysis (FMEA) as part of your risk management.

That’s according to Bethany Quillinan, senior quality systems consultant with Oregon Bioscience Association, who presented on the topic in our recent webinar, “Best Practices for Improving Risk Management Using FMEA.”

Over the course of the hour-long webinar, Quillinan and Jama’s senior product manager, Joel Hutchinson, provided some key elements around the value of risk management and FMEA, and the importance of modernizing your risk management process to accommodate.

At the conclusion of the webinar’s presentation, the pair answered a range of questions from the hundreds of participants in attendance. Unfortunately, they weren’t able to get to everyone’s questions, but luckily they took some extra time afterward to answer some of those remaining, touching on everything from risk mitigation in aerospace to specific standards like ISO 14971.

We’ve compiled the questions (some of which have been slightly modified for clarity) below and encourage you to check out the full webinar and Q&A session here.

Q: Given that FMEA teams in companies can be non-permanent and have a fluid scope, which role should own and drive the activity overall?

Bethany Quillinan: I think the ownership role should align with those of the design/new product introduction process. If there is a project lead, then that person would make the most sense. There may also be a particular functional group who is given ownership of risk management, like Quality or Compliance teams. I think it really depends on the organization. What we want is alignment and integration within the design process, not a separate “silo” for risk management.

Q: Do you have any suggestions for criteria that would help when selecting a good FMEA facilitator?

Quillinan: A good facilitator will be someone who is well-versed in the FMEA process and the organization’s particular methodology, rating scales, etc. Additionally, the facilitator should be skilled in well, facilitation, and by that I mean having meeting management skills — things like tracking time, noticing when energy is low and a break is needed, drawing out quieter members, dealing with overly-dominant members, and generally equalizing the field. The facilitator should not get involved in the “content” of the FMEA, just the process itself. Ideally, there is also a content leader who can keep the team focused on the scope of the FMEA. That said, the facilitator should be aware of the scope, in case the team gets way off track and no one is calling it.

Gain Confidence in Your Risk Management Plan with Jama Connect. Learn how.

Q: Any suggestions for facilitators to keep people from taking things personally?

Quillinan: One engineer I worked with who had facilitated a lot of FMEAs shared a good technique — to ask people, “How could you make it fail?” And that turned around defensiveness to creativity. From a facilitation aspect, I think emphasizing that the analysis is “potential,” that we’re not saying it’s going to happen, but that it’s a just a possibility to consider. Depersonalizing statements can help — talk about “the design” vs. “your design,” for example. If someone is super defensive, the facilitator may need to call a break to let things cool down and talk to the person offline. Diplomacy is important!

Q: What you talked about is used in the automotive field which is very effective, but the aerospace industry tends to use FMEAs focused on managing the effects and quantitative failure rates (assuming constant failure rates). How do you get the benefits of automotive FMEA and, at the same time, satisfy aerospace FMEA requirements? 

Quillinan: Having quantitative failure rate data to inform the discussion of the probability of occurrence is a big benefit. Failure mode, effects and criticality analysis (FMECA), where “C” is criticality analysis brings in more of the quantitative factor, and I see that terminology used more in aerospace. Satisfying specific Aerospace requirements is somewhat out of the scope of this presentation. In the context of the AS9100 quality management system standard, the requirement is to perform risk management, and FMEA is not prescribed but is a possible tool. Bottom line, I see FMEA as a prioritization tool rather than a reliability prediction. (In the early days, the military hoped to use FMECA to calculate an actual reliability metric, but it didn’t work out that way.)

Learn why Frost & Sullivan likes Jama Connect as a modern solution for risk management.
Read the brief. 

Q: What happens when multiple users are creating individual risk analyses? How do they collaborate if they are analyzing similar things?

Joel Hutchinson: As Bethany mentioned during her presentation, we understand that there’s going to be overlap in various FMEAs. An example of this is subsystems, which may have additional functionality that is only present at the system level. Risk management in Jama Connect helps the cross-functional team that works together to perform a risk analysis and has the ability to add view-only roles for context. One way of addressing this would be for the moderators of the two overlapping risk analyses to add each other as view-only roles to their respective analyses. This way, each cross-functional team is aware of what the other team is doing and how they’ve scoped their risk analysis.

Do you know where, when, and how intended Use FMEA (uFMEA for medical devices, per IEC 62366-1:2015) and software FMEA (life cycle requirements for medical device software per IEC 62304:2006+A1:2016) integrate into the requirements management process and product development timeline?

Quillinan: Generally speaking, risk management for usability, software, or any other aspect of a design should be integrated with the design process as soon as these aspects enter the design conversation. For example, early on during the initial “concept” phase, we need to be thinking about usability risks to inform the design concept and assist in evaluating different design routes to take. I also think useability/human factors could potentially be considered at any level of the product, so it could follow the same general timeline I showed in the presentation.

Likewise, for software, at the concept phase, the conversation will likely include software needs for satisfying customer expectations. From a systems standpoint, I feel the sooner the better. (I often use the initial rollout of the Healthcare.gov website for the Affordable Care Act (ACA) marketplace as an example of a “silo’d” approach to design. Each module was developed and tested in isolation and the “validation” of interfaces between modules was when it went live… and crashed.

We have to remember that the ultimate focus is at the system level — the end-user interaction with the product. In a medical device setting, most consultants are going to advise you to build in human factors considerations throughout the design process rather than waiting until the final human factors validation test on the finished design, for all the same reasons I described in the presentation.

The FDA guidance document “Applying Human Factors and Usability Engineering to Medical Devices” (Feb 3, 2016) is a helpful document and can complement ISO 14971.

Find out how to better manage medical device development in accordance with ISO 14971.
Read our guide.

Q: Risk Priority Numbers (RPNs) seem to always be subjective from one party to another, specifically the occurrence and detection. The occurrence is difficult to gauge when the failure mode and risks are new or when little-to-no history is available. For detection, we’ve had difficulty assessing the controls in place and how to rate them in terms of efficiency.

Quillinan: One way to help make the RPNs more objective is to establish and use consistent rating scales with descriptions that are relevant to your organization’s products and processes.

When there is no history and risks are new, the typical practice is to be conservative and give them high ratings. I often find that people have difficulty distinguishing prevention controls from detection controls.

Preventive controls typically act on the inputs to a process or are the controls during the process — think of mistake-proofing, for example not being able to choose an obsolete revision of a component for a bill of material (BOM) or having design guidelines to follow. Detection controls are after the fact and are inspections of the output of a process. In design, a typical detection control is a second person (or more) performing a design review.

Q: What is the relationship between design failure mode and effect analysis (DFMEA) and process failure mode and effect analysis (PFMEA), in terms of the failure modes and causes?

Quillinan: In DFMEA, we are looking at how the product could fail, and causes are from the design process itself; the assumption is that the process is being run correctly. In PFMEA, we’re looking at how the process could fail, assuming the product is designed correctly. Of course, this depends on FMEA scope. If we’re looking at a design for manufacturability, then we’re looking at how the design process could fail in terms of designing the product in a way that it can be easily and efficiently built.

Hear the full presentation, as well as questions and answers to many other FMEA and risk management questions, in our webinar, “Best Practices for Improving Risk Management Using FMEA.”

avoid product recall with functional safety and risk management

While a positive brand reputation takes years to nurture and build, irrevocable damage to a brand — and a business — can happen in only moments.

As innovative companies are asked to move faster than ever to bring products to market, it’s worth taking a moment to step back and look at the cost — financial and otherwise — of a misstep that could lead to product recall or failure. In addition to fines, regulatory reprimands, and decreased market share, a product recall inevitably impacts your brand and can have a major impact on your bottom line.

Brand erosion, for instance, is one consequence of a major product recall. As the name suggests, brand erosion is the gradual destruction or diminution of your organization’s reputation when your products are deemed unsafe, unfit for the marketplace, or simply don’t perform as marketed.

If you’re working in an industry where functional safety is a top priority, like automotive or aerospace, guarding against these types of scenarios means getting crystal clear on the standards and regulations that help protect your product. That also means ensuring proper risk management techniques like Preliminary Hazard Analysis (PHA) and failure modes and effects analysis (FMEA) are being performed correctly.

Often times, penalties come as a result of companies not properly performing these functions, and instead rushing to deliver products that haven’t met benchmarks for quality, compliance, and — in the case of many industries — functional safety. Other times, companies simply fudge the data. Let’s look at a few famous examples:

Ford Motors’ 1980 Failure to Park Product Recall

While product recalls can happen in any industry, some of the most notorious and detrimental have happened to automotive companies. Such was the case for Ford Motors which, in 1980, was determined by the Department of Transportation to have more than 23 million cars and light trucks in circulation that contained a functional safety defect that permitted the vehicle to accidentally slip from park into reverse, although to the driver the placing of the shift lever appeared to be in park.

And while the company would have faced financial ruin if all 23 million automobiles had been recalled, regulatory authorities ruled that instead of recalling all vehicles involved, Ford could make amends by sending out a sticker for drivers to place on their dashboard warning that “unexpected and possibly sudden vehicle movement may occur” if the car was not properly parked.

The failed safety catch was found to have led to 6,000 accidents, 1,700 injuries, and 98 deaths, and Ford was tied up in litigation for years, costing the company tens of millions of dollars. The “failure to park” issues continued even after the sticker warning was issued.

While the cost of this functional safety error included lost revenue and expensive lawsuits, the safety malfunction may have additionally cost Ford the trust of their consumers. Especially in industries that are highly regulated — and thus highly trusted — recalls related to safety and reliability can cause devastating harm to the foundation of the organization.

Learn how how a Fortune 100 semiconductor company is meeting the challenges of developing automotive-related technology by downloading our case study.

Volkswagen’s “Defeat Device” Scandal

 While some product failures and recalls are the result of honest mistakes, such as the example above, others can be attributed to downright dishonesty. Such was the case for Volkswagen in September of 2015, when the company admitted that they had installed software in 550,000 automobiles that could figure out when the cars’ emissions were being tested and modify their performance to meet mandated standards.

Initially, Volkswagen spokespeople claimed that a “few software engineers” were struggling to meet stringent U.S. emissions standards while also producing a diesel engine that would perform well. That, the spokesperson said, was the reason those individuals decided to design a “defeat device,” a system to switch on emissions controls when the cars were being tested and turn them off when the automobile was driving normally. What we now know is that knowledge of this system went much higher, and some believe awareness could have been as high as the CEO, who resigned and was later indicted.

The scandal cost the company over $29 billion dollars in recalled automobiles, but the damages didn’t stop there. After losing the trust of the public, the company posted their first quarterly loss in 15 years, showing that consumers weren’t likely to invest their money in an organization that had deceived them.

A recent study by Edelman shows that consumers are more interested than ever in purchasing from organizations that they believe are “doing the right thing.” The study revealed that 64% of consumers around the world — up 13% from 2017 — now buy on belief, meaning that they will choose, switch, avoid, or outright boycott a brand based on where the organization stands on issues they care about.

The same study showed that consumer trust dropped 10% (from 58% to 48%) in the last year, and that nearly half of consumers don’t trust businesses to “do what is right.” And organizations whose products are recalled due to deceiving functionality are certainly not going to earn a reputation for doing what’s right for their customers.

An additional 8 million cars were sold in the E.U. with the same “defeat device,” but because emissions standards are much lower there than in the U.S., Volkswagen legally committed no crime in the E.U.

NASA’s Costly Math Mistake

On December 11th, 1998, NASA launched a robotic space probe called the Mars Climate Orbiter into space with the hope of studying the Martian climate, atmosphere, and surface changes. Nearly 10 months later, in September 1999, the $125 million probe burst into flames and fell to pieces in outer space. While this was certainly not the first, or last, failed space expedition, what sets this one apart is that the reason for failure comes down to a simple math error.

 The navigation team at the Jet Propulsion Laboratory (JPL) used the metric system of millimeters and meters in its calculations, while the team that designed and built the spacecraft, Lockheed Martin Astronautics in Denver, provided crucial acceleration data in the English system of inches, feet, and pounds.

The result was that the software controlling the orbiter’s thrusters was faulty. The software calculated the force that the thrusters needed to exert in pounds of force, while a second piece of code that read this data assumed it was in the metric unit— newtons per square meter. And while fortunately no lives were lost, this simple mistake pushed the orbiter dangerously close to the planet’s atmosphere, destroying the spaceship and killing the mission.

Despite NASA’s next Mars mission also resulting in a lost spaceship, the organization did bounce back from the ordeal. They recovered over the following years by returning to the basics, rebuilding the Mars program based on conservative strategies and concepts that had already been tried and tested.

In the case of NASA’s space mishap, detriment took the form of missed opportunity and lost ground in their research efforts. Because of the immense time, money, and resources it takes to launch a space mission, failures and missteps can result in years of setback. What was supposed to be the first weather observer in another world became a $125 million mistake.

Learn more about Jama’s Avionics Services by downloading our whitepaper. 

How Better Requirements and Risk Management Can Help You Avoid Product Recalls and Failure

Developing complex systems and products requires teams to have the ability to effectively define and track requirements, adhere to safety-critical regulations, collaborate and communicate effectively across teams and functions, and evaluate and mitigate potential risks. Failure to do so may result in product recalls or failure, and in the case of safety-critical products, injury or worse.

According to the CHAOS Reports from The Standish Group, three of the biggest contributors to projects that fail are lack of user input, incomplete requirements and specifications, and changing requirements and specifications.

Unfortunately, too many organizations struggle with requirements and risk management and the effects, some outlined above, can be devastating.

In the case of the Mars Climate Orbiter, the simple miscommunication between JPL and Lockheed Martin not only shows how small mistakes can lead to mission failure, but also highlights the need for teams — especially those in different physical locations — to work collaboratively instead of in silos, and for organizations to invest in solutions that help teams achieve this.

With the Jama Connect Risk Management Center, development teams can participate in risk management techniques including PHA and FMEA in accordance with industry-specific standards like ISO 14971 and IEC 60812. By working with live data, teams can efficiently identify and mitigate risks early in the development process, ensuring quality and safety in complex product development.

To learn more about how Jama helps organizations thrive in critical product markets by reducing risk and providing a single source of truth, download Frost & Sullivan’s recent executive brief,“Safeguarding Regulated Products Amidst Growing Complexity.”

Many products must go through a risk management process to ensure safety, but it’s the severity of the potential outcomes that vary.

For our customers creating products in heavily-regulated industries — such as automotive, medical devices, and aerospace — the consequences associated with not correctly mitigating risk puts lives in jeopardy. And there’s ample evidence that too many in these fields are still struggling to find a process that works.

Even while tougher safety regulations and standards are being enacted, product recalls are still soaring. In February and March alone, millions of vehicles were recalled due to quality issues. And, within the fourth quarter of 2018, recalls of medical devices spiked 449% to just over 161 million, which was the second highest quarter in at least 14 years.

These examples showcase why teams building complex products need a smarter way to identify the probabilities and severity of risks early so they can track and mitigate them throughout development. And while risk management is imperative, it can’t come at the expense of the speed of development; in fact, it should complement rather than hinder efficiency.

Earlier this year, we introduced Jama Connect™ Risk Management Center for medical device developers, and now we’re excited to announce that we’re opening it up to all our customers working within regulated industries with the introduction of FMEA templates.

The Jama Connect Risk Management Center was developed from best practices learned from our work with companies that deliver quality products in safety-critical industries. With the newly-updated Risk Management Center, development teams can participate in risk management techniques including Preliminary Hazard Analysis (PHA) and FMEA in accordance with ISO 14971 and IEC 60812.

As an overview, here are some common problems we’ve often seen around managing risk and how the Jama Connect Risk Management Center solves them.

Problem: Not sure how to implement a solid risk management process

Risk management is a daunting challenge, especially for startups vying to disrupt an entire industry. Whether it’s ISO 14971, IEC 60812, or beyond, many new companies aren’t sure where to start when creating a risk management plan to bring their products up to international standards and government regulations.

Solution: Pre-configured risk analysis templates and startup services

In Risk Management Center, users receive guided templates based on best practices like FMEA and ISO 14971, which helps remove the bulk of the guesswork.

For medical device developers, Jama also has a Professional Services division that can work directly with your team to provide the best possible start to your process in accordance with ISO 14971. Through training and consultation, they’ll help customize your templates in a way that matches your team’s risk management process so you can start managing and mitigating risks quickly while accelerating development.

Jama’s professional services dramatically speed time to value, so much so that one customer began developing medical devices in less than a week with our guidance.

Frost & Sullivan points to Jama Connect as a way to better manage risk for companies in regulated industries. Read the report.

Problem: Risk management process can be siloed

In many organizations, managing risk during development is painfully cumbersome, disconnected, and inefficient.

If you can imagine a company emailing gigantic Excel spreadsheets around to manage risks for large, complex products — whether its airplanes, automobiles, medical devices, or software that interacts with any of these elements — you can also envision the unintended errors that can manifest as a result.

Solution: Streamlined risk management

The Jama Connect Risk Management Center takes a strong, team-based approach, ensuring risk analysis is not done in silos and instead performed early, collaboratively, and continuously throughout development.

With your risks and requirements housed directly within Jama Connect, Risk Management Center helps you track both in a single place. And since the data in Jama Connect is updated in real time, you’ll always be working from the most recent version of any risk analysis. Invited individuals can simply log in to Jama Connect and participate throughout the development process.

Through this effort, risk management becomes a continuous and collaborative part of the development process saving you valuable time and rework cost.

 

Problem: Aligning teams around risk management

Throughout the frenzied pace of development, those charged with leading the risk management process at organizations can find it difficult to keep teams engaged and focused on reviewing risks. The issue often manifests itself in long, painful, cross-functional meetings, wherein risks are reviewed in detail.

By their very nature, cross-functional teams aren’t performing risk management full time. As a result, review meetings can become susceptible to the same problems all meetings are prone to: participants don’t prepare, precious meeting time is spent on what to focus on, and action items aren’t clearly identified or resolved. This type of disorganization can significantly extend the development cycle if risks are still discovered late in the design or commercialization phases – times when efficiency is most needed.

Solution: Centralized risk management activities

Lengthy meetings around risk management can be halved with the Jama Connect Risk Management Center. Throughout development, key stakeholders in the risk management process can be given select access to Risk Management Center.

These chosen team members can then easily and efficiently view and contribute to the risk analyses that matter most to their expertise and experience. Users also get the ability to easily bookmark, organize, and identify recently-viewed analyses so they can pick up right where they left off.

Organizations using dedicated requirements management platforms receive fewer warnings, recalls, fines, and production stoppages than those that don’t, according to Engineering.com. Get the full report.

Problem: Tracking accountability in risk management

If your team is still relying on spreadsheets when building complex products, that’s going to cascade into other problematic areas.

In the whirl of development cycles, it can be difficult to manage the multitudes of requirements and tasks, leaving teams with a sense of unease around whether or not they’ve properly tracked and mitigated all possible risks when it comes time to launch.

Solution: Visible risk tracking and mitigation

In Risk Management Center, you’ll have the ability to link risks to requirements and verifications to better manage development complexity and assess the impact of changes to ensure quality. This feature also allows you to easily track open risks and those that are still needing mitigations, effectively eliminating the chance something slips by your team.

When it comes time to prove compliance, risk analysis and plan elements can be easily exported to allow sign-off in another compatible document or management tool.

Learn more about Jama Connect Risk Management Center by downloading our datasheet or contacting your account manager.

Companies are facing intense pressures to bring complex products to market faster than ever. In addition, those delivering products in safety-critical markets must also create and execute against a risk management plan for expanding standards and regulatory oversight.

In these cases, inefficiencies and blind spots in the development process can lead to risk management errors which not only throw releases off schedule but can put lives in jeopardy.

To help raise awareness around these issues, prominent research and consulting firm Frost & Sullivan recently observed the product development landscape and its relationship to risk. The output is a recently-released brief, “Safeguarding Regulated Products Amidst Growing Complexity,” that spotlights Jama Connect™ as a remedy for ineffective risk analysis in product development.

Symptoms of Ineffective Risk Management

The Frost & Sullivan brief outlines the current competitive environment facing organizations producing products in regulated industries and makes the case that relying on outdated processes impedes success.

“Many businesses in these spaces have invested heavily over the years in their document-based systems to manage their product development process and are hesitant to upgrade to unknown technologies or solutions,” writes Frost & Sullivan. “These antiquated systems are often static and spreadsheet- or even paper-based. And while they may offer a (possibly false) sense of reassurance against the costs and risks associated with a live digital system, they end up creating more costs and causing more harm.”

As we’ve heard from many companies, performing requirements management and risk analysis through versioned spreadsheets and extensive meetings not only drains resources, slows development, and creates errors, but it’s just no longer an effective strategy when you need to build safe products quickly.

Gain a stronger handle on ISO 14971 — the FDA’s mandatory standard for risk assessment in medical devices — by grabbing our whitepaper.

Strengthening Collaboration During Development

One other notion dispelled by Frost & Sullivan is the idea that remote development teams can operate at maximum efficiency without a powerful, shared solution for centralized enablement.

For instance, with regulated companies, there’s too much at stake to leave issues around requirements, risk mitigation, and compliance up to emailed documents.

“A strong, platform-based solution can provide a virtual space in which different but interdependent teams can collaborate, key stakeholders can review and weigh in on decisions, and regulators can trace end-to-end compliance,” writes Frost & Sullivan. “It can also enable risk mitigation as an ongoing, semi-automated process that catches and integrates changing conditions. Such a solution can help ensure compliance across processes, functions and locations, as well as with product definitions and design, processes and test cases.”

Learn how how a Fortune 100 semiconductor company is meeting the challenges of developing automotive-related technology by downloading our case study.

A Better Risk Management Solution

For businesses still hesitant to invest in improvements to their risk management process, it’s not always strictly a question of budget. The move involves a change in mindset and executable process, according to Frost & Sullivan. For instance, tracking and managing risk needs to be an intrinsic, collaborative, ongoing part of the development process, and not something performed by a specialized team in a silo.

Some organizations, especially newcomers to regulated industries, may not even be sure where to start with complex standards like ISO 14971, let alone assembling a risk management plan. It’s in these cases you’re more likely to see a development team dig into a risk management framework in the later stages of development, potentially adding rework and cost when schedules and budgets may not allow for either.

Frost & Sullivan contends Jama Connect is worth a look for all organizations interested in mitigating product risk, as it can “provide risk management, collaboration, efficiency and regulatory compliance as aspects that strengthen, rather than complicate, each other.”

Whichever path a company chooses, what Frost & Sullivan make clear is that staying the course with an ineffective risk management process isn’t really an option at all.

“Teams will otherwise struggle to get their people up to speed, across the globe and across groups,” writes Frost & Sullivan. “A team-based approach… is the ideal solution in heavily regulated industries.”

Access the full Frost & Sullivan brief, “Safeguarding Regulated Products Amidst Growing Complexity” by downloading it now.

Compliance standards, especially those that involve relatively new functional safety elements, will likely add additional requirements to the development process.

For example, the increasing complexity and abundance of automotive electronic systems led to the creation of a functional safety standard called ISO 26262 in 2011. And to ensure that new electronic functions remain functionally safe in the industry’s rapidly evolving environment, the International Organization for Standardization (ISO) recently introduced a second edition of ISO 26262 in December 2018. Similar regulations for other industries abound: DO-178B/C for aerospace standards, and IEC 60601 and ISO 14971 for medical standards.

Common to all of these safety standards is a risk-based approach to determine the criticality and potential hazards associated with key system functions. The primary goal of these standards is to prevent the failure of a system or device that could cause injury, harm or death. If a failure is unavoidable, then the system should fail gracefully.

Watch our webinar: “Understanding ISO 26262 Compliance for Automotive Suppliers”

The Impact of Tools in Functional Safety

ISO 26262 complements good systems engineering practices by requiring that hardware and software safety concerns be addressed and documented in a systematic way throughout the development lifecycle. In the past, safety design was considered part of general requirements activity. But merely identifying and tracing requirements in the software and hardware teams is not enough. The common practice of hardware and software teams working in silos will not guarantee the level of safety coverage required by ISO 26262.

How can the problem be resolved?

One of the key things missing from the general approach to requirements are the traceability links between phases. Many tools do a great job of requirements management and traceability within a particular phase but provide a poor auditable trail for traceability between phases. The activities of comprehensive and complete lifecycle traceability become an auditing afterthought, to be finished after the project is completed. This is the result that ISO 26262 tries to avoid through documented attention to the development process, decision-making and selection of supporting tools.

And because functional safety is a top priority for so many of our customers, Jama went through the process of earning a certification from internationally recognized testing body TÜV SÜD. Jama Connect™ is certified as a fit-for-purpose software tool for development of safety-related products according to ISO 26262 (up to ASIL D), IEC 61508 (up to SIL 3), IEC 62304 and EN 50128, giving our customers confidence that the products they are building are safe to use.

Learn more about ISO 26262 and automotive electronics development.

Tool Implementation Strategies

Tool qualification depends upon how the tool is used, which in turn determines what impact it could have on safety. For example, depending upon its usage, can the tool introduce a hardware defect or software bug into the system? How the tool is used within a tool chain will also determine the probability that an error introduced by the tool will be detected.

A confidence level is assigned to a given tool, or a flow within a tool, based upon the probability that it will insert or cause an error, combined with the likelihood that the error will be detected during the development process. The importance of the tool confidence level is that it will determine the cost an organization must invest in tool qualification.

As with other standards, implementing the ISO 26262 process requires iteration of a number of basic steps:

  1. Determine the existing process and tools to answer the question “Where are we now?”: Review the current embedded hardware and software development processes and tool chains. Understand the application(s) to be developed and assign levels of confidence in terms of safety.
  2. Gap analysis to answer the question “Where would we like to be?”: Perform a gap or impact analysis to identify current challenges and process efficiency improvements – often done using model-based design techniques.
  3. Training and instruction: Provide design-for-safety training and instruction to address the previously identified gaps.
  4. Hands-on deployment support: Apply the knowledge gained in the previous steps to a specific pilot project. This will require assistance in a wide range of areas including requirements traceability, modeling, simulation, code generation, verification, validation, tool qualification and system integration.

Jama Software is the first SaaS and Agile vendor to be ISO 26262 fit-for-purpose certified by TÜV SÜD. Read more.

Alignment with Best Practices for Functional Safety

This holistic approach to functional safety exemplifies several key elements of good system engineering processes: collaboration, traceability, validation and verification (V&V), risk analysis and mitigation, and careful integration within the tool chain.

Watch our webinar, “Jama ISO 26262 Certification and Best Practices for Development,” to learn more about how teams creating products for any safety-critical industry can lower the costs and risks of complying with functional safety standards.