Congratulations! Your organization has gained regulatory approval and launched its medical device product. The ‘History’ in Design History File may elicit impressions that all those design and development requirements are now done and considered part of the past. However, several components of the DHF continue as a reference and evolve, including requirements and risk management. Here are 3 ways active management of requirements and risk continues after commercialization:
1: Post-market surveillance
Once your medical device is on the market, post-market surveillance programs, including complaint management processes, must now be exercised. That includes evaluating feedback, determining if it is a complaint, investigating complaints, and determining whether to initiate corrections or corrective actions. As part of this process, requirements and risk management are being used in 2 ways, 1) as a resource to evaluate complaints and 2) a living document to be updated with the experience gained.
As a resource, it is important to reference risk management files to determine if the frequency of occurrence and types of failure modes documented during design and development matches the infield data being gathered. A more frequently occurring failure or new failure mode indicates an investigation is warranted and re-evaluation of the risk. Depending on the outcome, corrective action may be needed.
For example, during design and development, it was determined that a sensor failure leading to customer annoyance occurred rarely, leading to a low risk rating at the time of market launch. The first year on the market, reports of this failure occurred rarely, matching the occurrence rates in the risk management file. Given the low risk and lack of trend, further failure investigation and corrective action were not taken. However, one year later, a change in supplier coincides with a change in occurrence from rarely to frequent, leading to a medium risk. This increase in risk prompts an investigation to determine why the sensor failure rate is higher and to determine corrective actions and controls with the new supplier.
As a living document, the risk management files are to be updated with the observed occurrence rates, new cause(s) of the failure mode of the sensor, mitigations and controls put in place, resulting verifications, and revised risk rating.
2: New Products
Another reason requirements and risk management continue once a product is commercialized is to aid in the development of new products, including line extensions, new models, and next generation platforms and portfolios.
The existing product’s requirements and risk management, supplemented with what is learned from post-market surveillance and other feedback from the field, provide the foundation for new products. A requirements and risk management tool like JAMA Connects® can simplify the management of requirements and risks shared between products to keep teams aligned and prevent requirements or risks being missed during the transfer from one product’s design history file to another. Likewise, line extensions can be more easily incorporated into an existing design history file if requirements and risk management have been properly updated as needed and are accessible.
3: Change Control Evaluation
Change control evaluations is another way management of requirements and risks continue after commercialization. Changes to a product and how it is manufactured occur for many reasons, including replacement of a component that has reached its end of life from a supplier, software upgrades to address bugs, duplication of a manufacturing line, and changes that address complaints.
Changes must be evaluated as to their impact on the form, fit and function of the product, and can have varying degrees of potential impact. Well managed and active requirements and risk management, with traceability to design outputs and verification, become a strong tool for organizations to evaluate the potential impact more quickly.
For example, say a temperature sensor was added as mitigation to prevent overheating of a medical device; overheating that could result in burns to the patient. The sensor, including the necessary accuracy, is listed as a control for the risk of overheating and burns. There’s also a corresponding design requirement, and the sensor and its specification are linked as design outputs. The supplier of the sensor has recently informed the medical device manufacturer that the sensor is reaching its end of life and will no longer be available in 6 months’ time. A change owner is assigned to identify and evaluate a new sensor. This person is most likely not the same engineer who originally designed and selected the first sensor. And that the original engineer may or may not still be with the organization, and may not remember why that sensor was selected. This is where having accessible and well managed requirements and risk management becomes important. The change owner can reference and look up the sensor, see the design inputs and risk with which it’s associated, and understand more quickly the criticality of the sensor and ensure the proper selection and testing are performed on a new sensor.
While change post-commercialization is inevitable, difficult change control management is not.
Management of requirements and risk extends through the entire life cycle of a medical device, including after a device has gained the necessary regulatory approvals and reached the market. Thus, take care in selecting the tools and developing the processes your organization uses for requirements and risk management.
In this post, we will discuss why start-up medical device companies should prioritize requirements and risk management before a quality management system.
As a medical device product development consultant, I often see start-up companies having trouble deciding what to prioritize – design controls and risk management or the quality management system (QMS). And what they mean specifically is, which software systems should the company invest in first – the requirements and risk management solution that will aid in building a regulatory compliant design history file, or the electronic-QMS system to establish the FDA required and ISO 13485-compliant QMS?
From my experience over the past 15 years, here are the 3 reasons why I advise start-ups to prioritize requirements and risk management over an eQMS system.
1. Design controls and risk management processes start earlier
For best product, schedule, and compliance success, incorporating design controls should be done proactively instead of reactively. Companies are typically developing their medical device from day 1. This is compared to other QMS processes that may not be used until years later when the product is being transferred to manufacturing and being commercially distributed. A few of these other processes include non‑conforming materials, device master record, product change control, and complaint management.
Thus, purchasing a full eQMS system earlier than necessary results in paying for functionality that may not be used for years. That is of low value to the start-up closely watching its funds.
In contrast, as the medical device is being developed from the onset of the company, the benefits of requirements and risk management solutions can be realized very quickly and much sooner than a full eQMS system.
2. Requirements and risk management is often unwieldy
Unless your device is ‘simple,’ for example no software, no electro-mechanical parts, low-risk Class 1 devices; thoughtful consideration should be given to the processes and solutions that will manage the various requirements and risk management for your medical device development. Organizing all the user needs, design inputs, regulatory requirements, requirements from industry standards, system requirements, sub-requirements, and risk management can quickly become unwieldy without proper management.
In my experience, even a Class II electro-mechanical device can easily approach a thousand line items to manage and connect. Add on embedded software or a digital interface, and that number can easily jump to multiple thousands of line items or more, depending on the complexity of the medical device. A solution like Jama Connect® has immediate value to ensure all items are linked, traced, verified, and validated for a regulatory complaint design history file and medical device file.
3. In the early years, a company can create and manage a regulatory compliant QMS without an all-electronic system
Does forgoing the eQMS mean settling with a non-compliant QMS? No. A company can implement a regulatory compliant QMS without an eQMS system. SOPs can be implemented in stages, prioritized on the stage of the company. These SOPs, along with a cloud-based document sharing repository, is often sufficient in those early product development years. As the company approaches transfer to manufacturing and commercial distribution, then is the time to evaluate whether it’s time to transition to an eQMS system.
Summary
In summary, these are the three reasons I advise start-ups to prioritize requirements and risk management first before an eQMS system. This path allows for the development of a successful product and complaint design history file, as well as establishing the rest of the quality management system, all in a practical manner that maximizes value and meets regulatory expectations.
In this post, we look at how Teledyne e2v leverages Jama Connect for improved communication and better risk management.
Teledyne e2v is a global leader in specialized components and subsystems for innovative solutions in medical, science, aerospace, defense, and industrial applications.
Over 1600 employees in countries across Europe, America, and Asia.
As a result of their track record of innovation and technological breakthroughs, Teledyne e2v continues to be involved in many high-profile ground-breaking programs
Teledyne e2v’s success is built on long-established relationships with industry partners. The combination of their strong, in-house technical capability and links with technical authorities and universities, ensures that they can bring together the right level of expertise for a diverse range of technical challenges.
They offer:
RF Power solutions for defense, medical, marine, industrial, and security applications
Imaging solutions including CCD and CMOS sensors and cameras, for space and earth observation, life science, machine vision, and medical applications
Semiconductor solutions for aerospace and defense hi-rel microprocessors, high speed data converters, and high reliability ICs
A Single Source of Truth Increases Product Development Efficiencies and Improves the Flow of Information for Teledyne e2v
To meet the challenge of producing components and systems with increasing complexity, Teledyne e2v turned to the easy-to-use Jama Connect platform to provide a single source of information and end-to-end traceability for some of their product development teams.
OBJECTIVES
Optimize information flow
Improve formal review process
Find a product development tool that would garner broad adoption
After selecting Jama Connect, Teledyne e2v saw these results
Time-Saving Efficiencies in Meeting and Decision Making
With the single source of truth and real-time structured collaboration that Jama Connect provides, the Teledyne e2v team has streamlined the development process resulting in increased cross-team efficiencies and expedited decision making.
Streamlining and Simplification of Tools
After determining that Jama Connect was a sensible, easy-to-use, and easy to adopt tool that would increase efficiencies, having a customer saying they were going to use Jama simply sealed the deal and is helping Teledyne e2v achieve their goal of streamlining and simplifying their tools and processes.
Jama Connect has enabled a focused model of engineering leadership, with identified owners of top-level vision, and a streamlined, single source of truth. This has shown strong potential to leave developers with greater freedom to manage the detailed development and implementation in-line with the vision that is clearly communicated and controlled within Jama Connect. Leveraging this further across all projects and product developments is a key ambition for the team.
Driving Systems Thinking Across the Organization
Teledyne e2v’s leadership knows that tackling complex engineering problems and projects requires a structured and systematic approach. They needed a tool that would support their engineers and technical specialists to work in a structured way—without the tool getting in the way. Jama Connect enables this and is helping to drive systems engineering discipline further into the team, not only standardizing the way people work, but making it a positive experience.
To see how the team is now leveraging Jama Connect and how their risk management process has already improved, read the full customer story here.
Editor’s Note: This post about how autonomous vehicles was originally published here on EngineerLive.com on October 6th, 2020, and was written by Jeremy Johnson, Jama Software’s Vice President of Product Management.
Never before have so many automotive engineers been tasked with bringing increasingly complex machines to market as they have with autonomous vehicles (AVs). Not to mention, it’s not simply a game of speed – elevating only the companies which manufacture products quickly – but a matter of those organizations taking these steps, while pushing the envelope on innovation and prioritizing consumer safety.
While important advancements are being made daily to bring fully autonomous vehicles into commercial availability, we are still a ways off from seeing the Level 5 autonomy we hope for. We’ve witnessed this in the significant challenges and shortcomings reported in the news in recent years, even amongst some of the biggest names in autonomous vehicle production. There are, however, a few actions engineers can take to stay nimble, innovative, and reduce the number of safety-critical mistakes throughout the development process.
Focus on your core business: advancing technology
This is particularly important for start-ups or companies looking to apply their technology to the automotive space for the first time. If you’ve heard the saying “don’t reinvent the wheel,” it comes into play when considering what processes and procedures for meeting industry best practices must be in place. Seek a consulting or technology partner that can enable your business to continuously practice requirements, risk, and test management in alignment with market standards such as ISO 26262 and ISO/PAS 21448. By starting with a proven framework that can be applied and moulded to a particular business, engineers can focus their innovation and organizational energy on delivering new technology to customers.
This focus is noticed in how Tesla drives its business, where the organization leans more heavily into internal development to drive technology advancement and differentiation in the marketplace. Audi, which attempted to meet Level 3 autonomy with its 2019 A8, sought outside suppliers such as Aptiv, Intel, Infineon and NVIDIA– a different approach to Tesla. Although Audi ultimately pulled back stating the car was too far into the lifecycle, it was realized through properly executed business and safety procedures.
Support collaboration internally and externally
Rapid innovation requires tight collaboration, often occurring across various hardware and software teams, and increasingly with partners or traditional competitors. Whether a formal joint venture or targeted collaboration around specific technology development, this “co-competition” has become more common as companies look to drive innovation in AVs forward.
Ensuring the tools and processes to enable this collaboration are in place, and capturing the critical output that comes with it, will guarantee that R&D efforts move quickly while maintaining strong focus on verification and validation. It’s especially important engineering teams get out of their silos and work with adversaries on this front, because in the U.S. in particular, there’s no mandatory compliance enforced by the government to follow standards such as ISO 26262 or SOTIF.
There have been promising signs of collaboration by some automotive companies to exchange learned information during AV development. One example is the collaboration among Aptiv, Audi, Baidu, BMW, Continental, Daimler, Fiat Chrysler Automobiles, Here, Infineon, Intel, and Volkswagen to develop a whitepaper, “Safety First for Automated Driving,” describing a potential framework for the development, testing, and validation of safe AVs.
Maintain traceability of requirements, tests, and risks
Developing complex, safety-critical systems that marry software and hardware requires a great deal of rigor and planning. Keeping track of each step of the development process with cumbersome documents and spreadsheets greatly hinders engineers’ ability to remain agile. By ensuring all of these steps are tightly managed, integrated into other product lifecycle phases and available for flexible reporting will enable organizations to innovate quickly. This also allows for prioritization of safety and compliance and the ability to rapidly adapt as the regulatory landscape continues to evolve..
Most countries do not yet have specific regulations that govern autonomous vehicles, leading to uncertainty around requirements, reporting, and future regulatory compliance. As previously mentioned, in the U.S. there is also an absence of tightly defined regulations which means states could implement differing standards that require specific nuances in technology and regulatory compliance. There’s also basic differences in infrastructure that makes development and safety a challenge – such as variability in road surfaces, lane markings, and signage.
The key for teams in this fluid environment is to remain close to standard development and regulatory agencies, as well as supply chain partners, to define and influence these regulations. And they must be prepared to show traceability of requirements, risk, and testing information in multiple formats to support the various potential points of oversight – be it downstream customers or regulatory auditors.
Ultimately, we’re likely a decade or more away from commercial availability of a Level 5 autonomous vehicle. As we inch closer, it’s vital engineering teams take advantage of the modern systems management tools at their disposal in order to get it right now – before it’s too late.
To see more information related to the automotive development industry, we’ve compiled a handy list of valuable resources for you!
Today we are excited to announce the availability of Jama Connect for Airborne Systems, a solution designed to help systems engineering teams reduce barriers to the compliance process for their aircraft and aviation systems development process.
Jama Connect for Airborne Systems lets customers seamlessly manage requirements, risks, and tests in one powerful platform while supporting mission and safety-critical standards. The solution is built with the digital engineering ecosystem in mind, empowering engineering teams to better manage requirements, while simplifying regulatory alignment for civil aircraft system development, including ARP4754/ED-79.
The aerospace and aviation industry is experiencing innovative changes not seen for decades, where rapidly evolving technology has driven companies to develop disruptive products. The first commercial greater than 50-seat hybrid-electric aircraft is expected to make a fare-paying flight by 20321 and the FAA estimates over 545,000 commercial drones to be in use by 2021.2Innovation brings increased complexity in the design process, including the connected networksthat handle autonomous flight systems and unmanned, autonomous aircraft. The industry currently relies heavily on paper documents to track requirements— which simply can’t be depended upon in a digitized world with predominantly autonomous aircraft.
The Chosen Solution for Leading Aircraft Companies
As the chosen requirements management platform for five of the leading global electric aircraft companies driving innovation, Jama Software recognizes and answers these challenges. The company has worked closely with its partners to provide an all-in-one solution to address and overcome these challenges with ease. Jama Connect for Airborne Systems helps engineering teams get set up quickly, allowing them to focus on product design and innovation, while reducing the costs and effort required to align their development processes to meet mission and safety-critical standards.
“Aerospace systems engineering teams have a tough job: they are tasked with developing innovative, mission-critical systems at an accelerated pace and with unwavering quality standards,” said Keith Johnson, Chief Solution Officer at Jama Software. “Our new solution, designed specifically for these teams, will help facilitate the development process from start to finish. Jama Connect allows developers to hit the ground running with a purpose-built, out-of-the-box framework and best–practices guides that save critical time in the engineering process.”
Key features of Jama Connect for Airborne Systems
Frameworks aligned with key industry standards and regulations: ARP4754/ED-79, DO-178C/ED-12C, and DO-254/ED-80 and SEBoK
Best practices, including procedure and configuration guides for aircraft and aviation systems development
Export templates and reports, including requirements specifications
Supply chain collaboration to enable an ongoing exchange of requirements between customers and suppliers
Training and documentation aligned to aircraft and aviation systems regulations, which provides accelerated onboarding to set systems engineers up quickly
To learn more about how Jama Connect for Airborne Systems helps teams to improve their ability to communicate, track, and test requirements for teams in the aerospace industry, download our solution overview.
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.”
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.
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 butresults 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!
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.
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.
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.
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.
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.
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.
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.
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.
