This post was originally published on January 7, 2022.
Requirements Traceability – How to Go Live
Requirements traceability is required by many industry standards to ensure product quality and safety. The industry standards are based on decades of progress made in systems and quality engineering research with requirements traceability at the core. Benefits from requirements traceability are achieved if and only if traceability is used as a tool during the product development process. These benefits include greatly reduced or eliminated delays, defects, cost overruns, and rework. Here is an overview of the best practice approach to achieve Live Traceability™.
Live Traceability vs. After-the-fact Traceability
Let’s start with some definitions to make sure we are all on the same page. Requirement traceability is defined as tracking the development progress of product requirements from definition and design through development, testing, verification, and validation. There are two forms of requirement traceability: after-the-fact traceability and Live Traceability.
After-the-fact traceability occurs after the product has been developed and is typically a highly manual effort to try and re-create artifacts to demonstrate traceability that should have occurred during the development process but did not. This effort is undertaken solely for complying with industry standards and satisfying auditor requests for demonstration of process maturity.
Live Traceability occurs in real time as the product development process progresses to improve overall productivity (by ensuring engineers across disciplines are always working off the most recent and correct versions) and to reduce the risk of negative product outcomes (delays, defects, rework, cost overruns, recalls, etc.) through early detection of issues. The benefits of early detection of issues are significant. Research by INCOSE found that issues not found until verification and validation are 40 to 110 times more costly than if found during design. For this reason, most companies want Live Traceability but are stuck with legacy tools and spreadsheets that do not support it. Since each engineering discipline is allowed to choose its own tooling, the result is a large number of tools with no relationship rules or mechanisms to create Live Traceability across them.
Live Traceability requires a model of the key process elements and their relationship rules to monitor during the development process. The systems engineering V Model is a useful framework to start with for data object and relationship definition. Jama Connect® uniquely provides a point and click, configurable, relationship rule capability to enable Live Traceability. Below you see a sample relationship rule diagram from Jama Connect. Relationship rules vary by industry and company-specific requirements. Best practice templates are provided to comply with industry standards and configured to meet client-specific needs. The definition of a traceability model forms the foundation for model-based systems engineering since it defines model elements and their relationship to each other in a consistent manner across the entire system architecture.
Step 2: Setup Continuous Sync for Siloed Tools/Spreadsheets
Once the relationship rules are defined, the next step is to set up continuous sync with best-of-breed tools and spreadsheets used by the various engineering disciplines. The traceability diagram below shows a typical example of best-of-breed tools and where they sync in the Jama Connect relationship model to deliver Live Traceability.
Most companies prioritize the areas of the traceability model that are most prone to lead to costly issues in the absence of a continuous sync. Most commonly, these areas are:
Software task management – directly linking the decomposition of requirements into user stories enables Live Traceability through the software development process through testing and defect management. The most common best-of-breed tools used are Jira and Azure Dev Ops.
Test automation – test cases are managed in Jama Connect to align to requirements and ensure traceability across all engineering disciplines with the test automation results sync’d to the traceability model at the verification step. The most common test automation tools are TestRail and qTest.
Risk analysis (DFMEA/FMEA) – is most often conducted in multiple Microsoft Excel spreadsheets and the assumption has been that Live Traceability was not possible with Excel. Jama Connect is the first requirements management solution to enable Live Traceability with Excel functions and spreadsheets. Risk teams can now work in their preferred spreadsheets AND for the first time achieve live traceability to stay in sync with changes made by any engineering team. Ansys Medini is also a supported integration.
Model-based systems engineering (MBSE) – the first step in MBSE is to define a relationship model between all product requirements. Once a relationship model is defined, then specifications can be determined through modeling. Jama Connect uniquely provides model-based requirements to sync logically with a SysML modeling tool like Cameo No Magic. Other requirements management tools do not ensure a model-based approach, which most often leads to inconsistent and conflicting fields across teams and projects and provides no coherent relationship model.
Step 3: Monitor for Exceptions
Live Traceability provides the ability, for the first time, to manage by exception the end-to-end product development process across all engineering disciplines. The traceability model defines expected process behavior that can be compared to actual activity to generate exceptions. These exceptions are the early warning indicators of issues that most often lead to delays, cost overruns, rework, defects, and recalls. Below is a view of our Live Trace Explorer that shows you the LIVE state of development for any level of the development project you choose – from the entire cross-discipline effort down to a specific sub-component. Areas of greatest risk appear in red to show where requirement or verification coverage is lacking. Traceability is now a measurement that can be managed and improved with an overall Traceability Score and coverage and verification percentages..
Benefits of Live Traceability
The main benefits of Live Traceability across best-of-breed tools are as follows:
Reduce the risk of delays, cost overruns, rework, defects, and recalls with early detection of issues through exception management and save 40 to 110 times the cost of issues identified late in the process.
Comply with industry standards with no after-the-fact manual effort.
No disruption to engineering teams that continue working in their chosen best-of-breed tools with no need to change tools, fields, values or processes.
Increase productivity and satisfaction of engineers with the confidence that they are always working on the latest version, reflective of all changes and comments.
LEARN MORE
https://www.jamasoftware.com/media/2022/01/2022-01-07-v2-requirements-traceability-how-to-go-live.jpg5121024Marc Osofsky/media/jama-logo-primary.svgMarc Osofsky2024-10-30 06:00:452024-11-01 12:01:01Requirements Traceability – How to Go Live
In this blog, we recap our webinar, “Expert Perspectives: A Deep Dive Into Risk Management and Designing for Cybersecurity & Patient Safety” – Click HERE to watch it in its entirety.
Expert Perspectives: A Deep Dive Into Risk Management and Designing for Cybersecurity & Patient Safety
Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.
With more than 30 years of experience and a mission to elevate knowledge and proficiency in medical device risk management, Bijan Elahi has worked with both startups, and some of the largest medical device companies worldwide.
In this presentation on Risk Management and Designing for Cybersecurity & Patient Safety, Bijan covers:
Significance of a comprehensive risk management approach, including safety & security, for medical devices
Interfaces between safety and security risk management processes, and how they interact/complement each other
Upcoming industry trends that impact risk management (safety, security) like AI/ML, rise in connected devices, wearables devices
Below is a preview of our webinar. Click HERE to watch it in its entirety.
The following is an abbreviated transcript of our webinar.
Kenzie Jonsson: Welcome to our Expert Perspective series where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields. I’m Kenzie your host, and today I’m excited to welcome Bijan Elahi, a world-renowned expert on safety risk management for medical technology. With more than 30 years of experience and the mission to elevate knowledge and proficiency in medical device risk management, Bijan has worked with both startups and some of the world’s largest medical device companies. Without further ado, I’d like to welcome Bijan who’ll be presenting on risk management and designing for cybersecurity and patient safety.
Bijan Elahi: Hello. My name is Bijan Elahi. I’m delighted to be speaking to you about cybersecurity and medical device risk management. Before I start, I’ll briefly introduce myself. I am a technical fellow, a professor, and the founder of MedTech Safety, an education and advisory company. To give you a little background about myself, I come from the industry and have been a medical device product developer for most of my career. Most of the products that I have developed have been class III implantable devices such as pacemakers, defibrillators, and deep brain simulators. Now I’ve also developed a kidney dialysis system, which includes disposables. I’m based in Florida, but I teach and advise worldwide. Risk management is my passion. I have trained over 10,000 individuals worldwide in the latest knowledge and best practices in risk management.
Elahi: The companies that have benefited from my training range from small start-ups to the largest MedTech companies in the world. And here’s the sampling. I am also active in academia, for example, at Delft University of Technology and Eindhoven University of Technology in the Netherlands where I teach a graduate course to doctoral students in engineering. I am also an affiliate professor at Drexel University Graduate School of Biomedical Engineering and Health Science, where I teach safety risk management for medical devices. And lastly, I’m a contributor to the standard ISO 14971, and the author of two very popular books on medical device risk management published by Elsevier Publishing in the UK under the label of academic press. My publisher tells me that my books are bestsellers in the genre of medical books for them, and they’re available at all major booksellers such as Amazon.
So now let’s talk about cybersecurity and safety risk management. The threat of cybersecurity on medical devices is a rising concern as there’s an ever-increasing interconnectivity, interoperability, and reliance on digital technologies. Medical devices such as pacemakers, insulin pumps, and imaging systems often contain sensitive patient data and are integral to patient care. Cyber attacks on these devices can lead to severe consequences, including tampering with the device functions, unauthorized access to patient information, and destruction of critical healthcare services. The potential for harm is significant. For example, incorrect diagnosis, treatment delays, or even direct physical harm to patients. As cyber threats become more sophisticated, we need robust security measures, smart designs, and continuous monitoring to protect these vital components of modern healthcare systems. The safety impact of cybersecurity exploits must be considered in the overall residual safety risk of medical devices.
Safety risk management is distinguished from cybersecurity risk management. Safety risk management is primarily concerned with the safety of patients, users, and the performance of medical devices. This involves identifying, evaluating, and controlling the risks of harm to patients or users due to device malfunctions, use errors, or adverse interactions with the human body. The focus is on ensuring that the device functions safety and effectively under normal and fault conditions. On the other hand, cybersecurity risk management is focused on protecting the device and its data from malicious cyber-attacks and unauthorized access, which may have nothing to do with safety. Many hospital systems are currently under ransomware attacks with the intention of financial exploitation. Security risk management involves implementing measures to protect the data confidentiality, integrity, and availability of healthcare systems. Although these topics are distinct, there is an overlap between them.
Elahi: As mentioned before, there are different exploits that cyber attackers seek. Some are not safety-related. For example, private patient data, software codes or algorithms, financial data, money, et cetera. A famous example is the WannaCry cyber attack, which unfolded in May of 2017 causing widespread disruption across the globe. It all started on the 12th of May 2017 when many organizations began to notice that their computer systems were being encrypted and locked by ransomware demanding payment in Bitcoin to unlock them. The ransomware known as WannaCry exploited invulnerability in Microsoft Windows. The attack affected hundreds of thousands of computers in over 150 countries. Major organizations and institutions were hit, including the UK’s National Health Service, also known as NHS, FedEx, and many others. The impact on the NHS was particularly severe because medical staff were unable to access patient records leading to significant disruptions in healthcare services.
As you can see, this was a cyber attack with the intention of financial exploitation, but it ended up having a patient safety impact as well. A comprehensive risk management strategy for medical devices must integrate both safety and security measures. This ensures not only that devices are safe from operational risks, but also that they are protected against growing threats of cyber attacks, thereby safeguarding patient health and data integrity in a holistic manner. An interesting side note to the WannaCry story is that this vulnerability was known by Microsoft and they had released a security patch in March of 2017, two months before the cyber attack, but many hospitals and organizations have not applied the patch and remain vulnerable. This is a common issue even today, and many medical devices and healthcare systems remain vulnerable despite the available protections.
https://www.jamasoftware.com/media/2024/07/Interview-with-an-Expert-Series-Final-Template.png10801920Bijan Elahi/media/jama-logo-primary.svgBijan Elahi2024-07-16 03:00:512024-07-12 11:50:23Expert Perspectives: A Deep Dive Into Risk Management and Designing for Cybersecurity & Patient Safety
In this blog, we recap our whitepaper, “Applications of Systems Engineering in Healthcare” – Download the complete paper HERE.
Applications of Systems Engineering in Healthcare
When it comes to healthcare, time to market is one of the most crucial aspects of success or failure. However, medical product development teams face several challenges that slow product development, and in the quest to speed up the process, some teams are turning to systems engineering to improve the process.
In this whitepaper, we’ll look at the challenges healthcare development teams face, the difference between market-driven and contract-driven industries, and how the power of simplicity can help healthcare systems engineering teams strike a perfect balance to adapt, innovate, and succeed.
The Challenges of Healthcare Systems Development
To understand how systems engineering can help, it’s important to first look at the challenges development teams face.
The shifting regulatory landscape presents more challenges, including the increased cost of adherence to such regulations as Software as a Medical Device (SaMD), Software in a Medical Device (SiMD), Medical Device Regulation (MDR), and In Vitro Diagnostic Regulation (IVDR). At one of the top medical device development firms, for example, their product developers had to monitor approximately 8,000 regulations. Ensuring that products meet quality, safety, and performance standards has a significant financial impact; getting it wrong can cost billions of dollars. Across the industry, non-routine quality events cost between $2.5 and $5 billion per year.
In addition to increasing design complexity, there is also an increase in process complexity. Software development teams have gone from between 20 and 40 people to hundreds of people. Artificial intelligence (AI), machine learning (ML), and other new technologies represent complexity inside devices. Organizations are getting more complex as well, with a heavy focus on acquisition, which means constantly integrating new teams and cultures, sometimes dispersed across the globe.
Systems engineering can help product developers in healthcare manage these complexities and streamline development to keep them competitive in a rapidly changing market.
To understand how systems engineering can improve speed to market, it’s important to first understand the difference between a “market-driven” and a “contract-driven” industry.
In a market-driven industry, the first mover tends to get the lion’s share of the profits. Market-driven industries have many customers, and the stakeholders are internal to the business. Budget, time, and requirements are negotiated within the organization.
In a contract-driven industry, success means satisfying the contract. Budget and time are fixed by the contract with one (or very few) customers. In this scenario, requirements are a key commitment negotiated within formal design control.
The two different industry models present very different requirements challenges. In a market-driven industry, requirements are an internal business tool that helps communicate across business functions. They must be validated, but the development team decides on timing and features. If a team member develops a new, innovative feature, everyone can agree to take extra time to develop it. In a contract-driven industry, that likely wouldn’t be possible given the constraints of the contract.
Systems engineering can help the market-driven industry turn ambiguous needs into clear and feasible solutions to be implemented by hardware and software teams.
Systems Engineering: From Needs to Solutions
Product developers in a market-driven industry receive a lot of input from the various stakeholders within the organization. Their task is to turn that input into marketable products that work seamlessly on day one, day fifty, and years later. The key value produced is the seamless integration of those products into every customer’s workflow and work systems. Every installation and every service event must produce a uniform, high-quality, high-performing product.
Within those constraints, developers need to optimize the business value. When there are multiple options, marketing will inform the team of the customer value of these options. The implementation teams will pass on the delivery and product costs of those functions. The role of systems engineering is to make trade-offs between those and optimize the business impact based on the cost of implementing them. Associated with that is managing technical risks and scaling costs by risk.
The key value of systems engineering is making sure design decisions are identified and closed predictably with one voice across the team. Decisions are framed, the options are agreed to, the decision criteria are agreed to, and the final decision is closed, and stays closed even as stakeholders change. Once the team has a frozen design, integration or quality problems can be found and resolved prior to moving on to the next phase. By creating time to react, teams allow themselves space to adjust design early in the program rather than rushing to fix quality issues before shipping.
Winning products happen when systems thinkers are effective. When everyone across the program engages in systems thinking, the team will maximize the creativity of the entire program.
As a process example, at one leading US-based medical device development company, engineering teams start with the end customer’s performance requirements, such as delivering excellent image quality in their imaging
products or the proper humidity and temperature for neonatal products. As part of delivering that essential performance, teams must ensure safety and regulatory compliance.
Their product teams also put a high emphasis on usability, ensuring that their products are easy to use and delight the customer. The teams define the right implementation requirements and reliability strategy, and they ensure that their products can be installed and serviced properly.
While there is tremendous diversity in products and programs across most medical device and life sciences companies, there are several commonalities across the product teams as well. Teams have common program milestones and a common systems’ lifecycle based on the V-model with iteration and Agile built in.
What differs in product teams are the levels of safety hazards and FDA risk. Teams develop everything from anesthesia technology, which could easily kill a patient, to ultrasound, which is non-ionizing equipment operated with light, handheld probes. To accommodate these different levels of risk, teams adjust the process rigor so that higher-risk modalities have higher process rigor.
Additionally, systems engineering teams can look very different across the world. Many organizations operate in different locations with different cultures and different organizational sizes. Systems engineering teams can vary from fewer than ten engineers to over one hundred engineers. The scale of the programs can range from just a few engineers over a few months to many hundreds of engineers applied to a program that might last three years and is based on technology developed over the prior decade. (Even in that research phase, teams should apply some systems engineering thinking.) Organizations can be product-centralized or decentralized within an organization.
https://www.jamasoftware.com/media/2024/03/2024-02-08_applications-of-systems-engierring-in-healthcare-whitepaper-2.jpg5121024Chris Unger/media/jama-logo-primary.svgChris Unger2024-03-28 03:00:232024-03-26 14:32:48Applications of Systems Engineering in Healthcare
Pioneering Excellence in Healthcare: Q&A with Systems Engineering in Healthcare
The following is the transcript of a Q&A session from this event. Please note that the answers were given verbally and may not be exactly as recorded. Some changes have been made for clarity.
“What are some insights for product development teams to consider when keeping up with the speed of innovation?”
Chris Unger: Separate out research (from development), and spend certain time on long lead items. Typically, our programs are 6 to 18 months. And so, if there is basic research that takes more time, make sure you have a certain amount of your budget – 5, 10% – with risk retiring the initial basic piece of the work, and the handoff between research and [development] programs in where we think we can retire the remaining risks in the 12 months. And then the rest of it has to really focus on what is really core. Eating the elephant one bite at a time. Focus on what’s really innovative. But one of my general managers said, ‘You want your product development to be a wall. Big, small, small, big, small.’ Product development should be a phased approach where you work on various scoped tasks. Focus on the high-risk and most innovative stuff. Low-hanging fruit can wait. Spend the time really on the breakthrough, and then maybe every six months for the next year just do small iterations, maybe some covers, maybe some better user interface and workflow, while you’re buying time for the next major innovation to come through. So, portfolio management.
Bijan Elahi: With respect to risk management, innovation in new technologies is useful for reducing risk to medical devices. You may have seen the definition of “state of the art” in the latest edition of ISO 14971 Standard, which says that the manufacturers are required to consider the consolidated findings of technology research practice to incorporate into the medical devices to reduce risks as much as possible. However, it also says that the latest technology state of the art is not necessarily the latest technology [from all industries]. And medical devices, we are a little slower than other industries like semiconductors. So, for us, state of the art must be generally considered good practice, and then innovations that are proven and accessible to be used to reduce risk.
Chris Unger: The other comment I might make is one of the reasons you slow down is scope creep. For every function, every person is like, “I just need my one. It’s just small.” It’s the straw that breaks the camel’s back. And one of our most successful businesses, the ultrasound team, said that time to market and this time blocks delivery was a team effort. Instead of having one person beating away, that all the functions sort of gang up on each other. It’s like, “Well, I didn’t put my extra in.” We’re all committed to delivering this every year, something important every year. And so rather than having the program manager fighting for scope, it’s the team that says, “Look, I’m willing to commit to this limited scope to get something this year, you help me out.” So, make sure it’s the team’s focus on speed to market.
Vincent Balgos: In this post-pandemic event, collaboration can pose a challenge in working remote, hybrid, onsite, especially for systems engineering and risk management where we need to work across the aisle amongst different types of groups.
Vincent Balgos: “So my question to maybe Bijan first, is what are some lessons learned that you’d offer to maintain efficiency and progress, that works better than others? And we are a bunch of engineers here, definitely want to talk about technical, but are there any key soft skills that we may also want to consider as well?”
Bijan Elahi: In one of my classes, I teach that you need to cultivate humility and curiosity. So, what do I mean by that? As I said, risk management is a team sport, and humility does not mean self-deprecation, it means to recognize that the answer is not all within you, it’s within your team. And the curiosity part is that some people are just shy about sharing their thoughts. So, curiosity is to seek it. It doesn’t always just come to you. So, this is a soft skill that I can offer you, to cultivate humility and curiosity.
Chris Unger: This is a good advertisement for the February webinar I am hosting with Jama Software. I was going to plan something on requirements writing techniques, which will probably be later in the year. I’d say a couple of things, make sure that you focus on communication. So, in a crisis, a lot of people just focus on getting their work done. And the first thing that you should maintain, a lesson straight off, is making sure you talk to the team, that you get consistency and use simple forms, and keep publicizing. Example like “What are my decisions? What are the important ones?” Just keep over-communicating, it’s something simple in the survival handbook, “Guys, here’s my list of decisions, here’s my list of risks.” Keep it simple, keep it single reference.
And the other thing I do is, don’t use that to communicate, use that to archive your decisions. I get really annoyed when my team says, “I wrote defects in the tool. Of course, they’re going to respond.” Talk to people, call them up, ask them questions. Do they understand? Do they understand why it’s important to do this? Do they accept that it’s their defect? I had one, my first program at my previous employer, we got to each milestone, we had like a hundred open defects. And people came to me complaining, “Well, I got rid of my defects. I fixed 50 of them and I transitioned 50 to every other defect. But it’s not fair Chris, because everybody else transitioned their defects to me last night. How am I supposed to…” But we’re a team. Don’t reassign the defect in the tool and assume they’ll accept it. Talk to them. Say, “I’m going to reassign these five defects to you. Do you agree that they’re yours?” Talk more than use the tool to communicate. I love Jama Connect. I love the risk management aspect, all the risk files. But if you are going to assign a risk mitigation to somebody, talk to them before you assign them.
Vincent Balgos: “What are some market and technology trends you see coming to the industry in 2024?”
Bijan Elahi: The big ones are Artificial Intelligence (AI) and Machine Learning (ML). A lot of medical devices are now deploying technologies that are based on AI and ML. And this has really created the challenge for risk management. In fact, we don’t know how to really completely answer this yet. This is an unanswered question. And the regulatory agencies, ISO experts, they’re all working on this. So, answering this question of how do we manage the risks of a medical device that is constantly changing? With current medical devices, if you want us to make a change to it, you’re supposed to submit something to the FDA. What about a medical device that is changing by the hour? It’s not really possible to keep making submissions. So, this is one of the challenges that’s happening in 2024.
Chris Unger: Yeah, that’s the obvious thing. I was a skeptic. People a long time ago said, “Are you doing AI machine learning?” And I kept responding with “No, it’s not ready. It’s not ready.” It’s ready. It’s coming. It’s now. It’s 2024. I wouldn’t say it’s a 2024 trend, it’s ongoing and continuing in cybersecurity. I mean, all these things are connected. That we want to network. Radiologists want to work remotely. It was a long time ago that somebody talked to us and said, “Look, this is great. I’m the head of a radiology network in northern Jersey. We’ve got five radiologists. And when people come to my clinic, I’ll do a quick read of every scan in my area, but I’m the liver guy. So, all the liver scans get sent to me. And somebody else is the head guy.
But that means a network, which means you’ve got huge network security. So, cybersecurity is just always going to get more and more critical. And we’ve never been liable. We’ve had hospitals come to us saying, somebody’s stuck a USB stick into your system and you let that virus go and it infected their network, but it went through your product. Why didn’t you protect it? And that was a huge malware. Whatever ransomware hospital costs more money than effective fiber is going to be way more effective.
Audience Question: “I was curious, looking at your workflows with the dotted lines, I recently debated whether usability engineering should be its own pillar containing risk, containing system requirements or embedded within the existing infrastructure for those. Do you have any pros or cons or suggestions on whether you should look at usability engineering independently as a whole? Or as part of the risk plan system requirements plan?”
Bijan Elahi: Usability engineering is very well integrated into risk management. It is its own discipline, and it has its own standard IEC 62366:2015. But a lot of its work products are very similar to an actual integration with an ISO 14971 workflow. So, I can’t say that it should be independent, but I say integrated with risk management.
Chris Unger: Yeah, I think it’s both and, not either or. As Bijan said, there’s a use analysis report that is mandated. So, it’s its own discipline and it’s part of everything. It’s part of workflow. Remember I said, “Gee, we want, custom things that are easy to use. No training needed, just use it.” And that’s a customer value. It’s part of marketing. Think about reliability. So, if I take this and I drop it… what are the stresses? How do I test this stuff? It’s part of uses. When we did things, it was probably two-thirds of our reliability issues were unexpected use cases. So, we had this baby warmer, and it was in Philadelphia, so they had cobblestone streets, and they were just transporting it from one wing of the hospital to the other, no baby in it. And there was an infrared warmer, it went over it and the interim warmer fell over to where the baby would be. Because it was doing a shake test going over the cobblestone. And we didn’t think about that.
Another case we had a mobile X-Ray. Takes an X-ray system, moves it into the surgery, into the ICU, the recovery room. And it’s a battery… It was probably 600, 700 pounds. Great when you have this big hulking tester and they move it over this expected ramp, something like this was easy to move it over. You get 110-pound nurse in a hospital with a two-centimeter step going into the elevator and guess what? The only way they could get over the ramp was to take a running start and use the momentum. We had wheels falling off. What was that? So, we went to the hospital and watched them. Oh! We expected like 5 Gs and the upper limit (UL) is like 50 Gs or 10 x factor plus 200 Gs. Once we designed for 200 Gs, wheels stopped falling off. So, usability is part of reliability engineering. So, it’s part of everything and it’s used in analysis report.
Audience Question: This is a more general question, but for companies that have two or more variants of a product, what are your recommendations? And this is to both of you about managing both product development and product assets. So, let’s say 90% of the assets are common across three variants and how to handle risk management when the clinical usage of those three variants could be different?
Bijan Elahi: With respect to risk management. EU MDR allows you to do risk management for a family of projects. So, if this is a family that are very similar, you can do a common risk management and then do differential risk management for the differences between them to submit.
Vincent Balgos: I’ll also add that varying management configuration is a hot topic within the medical, especially as you build family of products and then you build your… Let’s say child products off that. How do you reuse and share some of that information for efficient product development? So, this is where Jama Software is really a great, unique opportunity where we’ve actually learned from other industries, particularly in automotive and in terms of how they deal with those different types of variants. So, we’re incorporating some good practices off the bat and again, happy to talk with each of you, especially if there’s specific questions on how to solve some problems.
Audience Question: My question is about integration. I mean we see more and more devices now have the ability to work together with solutions from other vendors. How can we can be prepared for that? I mean sometimes if your product is on the market, and somebody wants to use it and integrate it with a different solution. How can we be prepared for that from both a system engineer design perspective and for risk management?
Chris Unger: System engineering is kind of simple. Keep a configuration compatibility matrix to ensure that this version of your product is compatible with what version. And then really think through the use cases. The rainy day and sunny day. We had cases where our monitoring central station… So, we built some temperature monitors, fetal monitors, cardiac monitors, but we also then built a central station that have to work with our sensors but anybody’s sensors in the world. And we did pretty good with that.
We had a recall where somebody would plug in a… I forget what it was… temperature monitor? But it was a safety-critical device in the intensive care unit, and we didn’t have a fast enough response that it was plugging in. Usability. So, the nurse pulled it out, put it in again, pulled it out, and put it in again. And finally, the system had a race condition. It said you pulled it out, and when they put it in it tried to reset. So, the nurse had thought that it was plugged in it, and it wasn’t. And so, the nurse was assuming that the patient’s heart rate was monitored when it wasn’t, we had to recall the entire product. So have a standard interface. Have a compatibility matrix and test the unusual customer uses.
Bijan Elahi: With respect to risk management, if you’re making a medical device that is supposed to work with other medical devices together, then the together becomes a system. The patient is experiencing the risks that could come from the integration of all the devices that connect with your device. To manage the risk of that, what you need to know is which devices are going to plug into your device and then you test them to make sure that they’re safe together. And then you make a list of approved compatible devices that could be used with your device and your manufacturer makes another device that wants to be used with yours and you must check that too. Just keep expanding your list of approved devices.
https://www.jamasoftware.com/media/2024/01/new2024-1-25-medical-q-and-a.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-01-31 03:00:242024-02-06 11:05:54Pioneering Excellence in Healthcare: Q&A with Systems Engineering in Healthcare
In this blog, we’ll recap our eBook, “What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security” – Click HERE to download it in its entirety.
What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security
A comprehensive guide to understanding ANSI/AAMI SW96:2023 and mitigating security risks
Introduction
Managing risk around a medical device’s entire lifecycle has become increasingly complex. Many devices use third-party components, which is especially true for devices that require a network to operate. This increased need for connectivity, along with other emerging threats, is putting security at the forefront of medical device industry standards.
A recent report titled “2023 State of Cybersecurity for Medical Devices and Healthcare Systems” found 993 vulnerabilities in the 966 medical products it examined—a 59% year-over year increase from 2022. Software applications, including those that medical devices relied on to work, accounted for 64% of the vulnerabilities found.
With device vulnerability increasing, new standards aim to keep up with emerging threats. As a result, ANSI/AAMI SW96:2023 was created to help protect against threats, understand risk, and guide manufacturers in taking the most appropriate actions to enhance security. However, because the standard is relatively new, many device manufacturers are still finalizing the interpretation on how this impacts their organizational processes. If you’re still working to get familiar with the standard, we’ve created a complete guide to make the task easier.
Third-party components may increase security risk, with one study finding that software alone accounted for 64% of noted vulnerabilities.
What is ANSI/AAMI SW96:2023?
ANSI/AAMI SW96:2023 guides security risk management for medical devices, aligning with the processes included in ISO 14971:2019.
The new standard addresses the entire lifecycle of a medical device, including areas such as design, production, and post-production. It’s intended for use with AAMI TIR57 Principles for Medical Device Security – Risk Management, which addresses cybersecurity analysis, and AAMI TIR97, Principles for Medical Device Security, which guides processes for managing medical devices in the post-market space.
The goal of the new standard is to support manufacturers in ensuring that medical devices are reliable, work as intended, and don’t cause harm to patients, operators, or the environment. It also focuses on mitigating any potential risks around device failure.
What is ANSI/AAMI
SW96:2023? The standard includes policies, procedures, and best practices designed to evaluate, control, and monitor potential risks involved with a medical device.
Security has always been important to medical device manufacturers, which is why considerations are included in ISO 14971:2019. However, ANSI/AAMI SW96:2023 aims to deepen security-related standards.
Addressing potential security risks throughout the entire product lifecycle, including design, production, and post-production, enables manufacturers to identify and mitigate potential risks through a more focused and proactive approach. It helps manufacturers continually identify, review, and safeguard against fast-evolving threats.
Understanding the security risk management process
As you get up to speed with ANSI/AAMI SW96:2023, the “security risk management process” section includes details for mitigating potential threats. It includes six major sections, everything from
security risk analysis to production and post-production activities. Each section contains a detailed framework, but for the sake of simplicity, we’ve highlighted a few main points for each.
The 6 Sections of Security Risk Management
Security risk analysis. It focuses on selecting product security standards, performing threat modeling, and establishing capabilities to identify and detect security vulnerabilities across a medical device’s entire lifecycle.
Security risk evaluation. Establishes a security assessment strategy and testing processes.
Security risk control. Identifies, designs, and implements security risk control measures, as well as verifying the implementation effectiveness of any security risk control measures.
Evaluation of overall security residual risk acceptability. Determine if the “security residual risk” of a device is acceptable.
Security risk management review. A security management report is prepared.
Production and post-production activities. Potential vulnerabilities are monitored to identify any new security risks. Also, it establishes processes to stay aware of new threats, creating security incident response plans and other measures to identify ongoing vulnerabilities.
Section 1: Security Risk Analysis
The security risk analysis focuses on selecting product security standards, performing threat modeling, and establishing capabilities to identify and detect security vulnerabilities across a medical device’s entire lifecycle. It covers:
Security risk analysis process: It suggests that manufacturers perform a security risk analysis, and the results are recorded in the “security risk management file.”
Intended use and reasonably foreseeable misuse: The “security risk management” file includes reference documents developed in compliance with clause 5.2 of ISO 14971. It needs to account for “the use of a medical device in a way not intended by the manufacturer, but which can result from readily predictable behavior.”
Identification of assets and characteristics related to security: You’ll also identify potential medical device vulnerabilities such as third-party components, hardware, and software.
Security risk estimation: You will estimate the associated “risks” for each of the identified security vulnerabilities and potential impacts on areas like confidentiality and integrity.
Section 2: Security Risk Evaluation
The security risk evaluation establishes a security assessment strategy and testing processes. A few areas it considers:
Evaluation of each security risk: Identify each security risk area, determining if a “security reduction” is required.
Evaluation of security risks with a potential safety impact: Consider every potential risk to determine any potential safety impacts.
This section is focused on identifying, designing, and implementing security risk control measures, as well as verifying the implementation effectiveness of any security risk control measures, including:
Security risk control option analysis: Determine if a security risk control measure is appropriate for mitigating security risks to an “acceptable level.”
Implementation of security risk control measures: Security risk measures are selected based on the prior step.
Security residual risk evaluation: After the security risk control measures are implemented, the manufacturer evaluates the security residential risk and records this evaluation in the security risk management file.
Benefit-risk analysis: If a security residual risk is found to be “acceptable” using the criteria created in the security risk management plan, and further security risk control isn’t practical, the manufacturer conducts benefits versus security risk analysis.
Risks arising from security risk control measures: The manufacturer reviews the effects of the security risk control measures to understand whether new security vulnerabilities and threats are introduced that could impact security, safety, or privacy.
Completeness of security risk controls: The manufacturer periodically reviews security risk control activities to ensure all vulnerabilities and threats are considered and security risk control activities are complete.
Section 4: Evaluation of Overall Security Residual Risk Acceptability
After the security risk controls are implemented and verified, the manufacturer determines if the overall “security residual risk” created by the medical device is acceptable.
Section 5: Security Risk Management Review
The standard recommends a review of the execution of the security management plan before releasing a new device. According to ANSI/AAMI SW96:2023, the review should ensure:
The security risk management plan has been appropriately implemented.
The “security residual risk” is at an acceptable level.
Methods are in place to gather and review details in the production and post-production phases, and leadership has reviewed and approved the plan.
Section 6: Production and Post-production Activities
The final section is focused on establishing, documenting, and maintaining a system to monitor, assemble, and review information about medical device security in the production and post-market phases. Also, it establishes processes to stay aware of new threats, creating security incident response plans and other measures to identify ongoing vulnerabilities.
https://www.jamasoftware.com/media/2024/01/2fe8f5c4-37b4-47b3-b012-1ca0b0d208a1.jpeg512986Jama Software/media/jama-logo-primary.svgJama Software2024-01-09 03:00:592024-01-17 17:10:17What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security
A Wise Investment: Requirements Management and Traceability Solutions During an Economic Downturn
In the realm of business, the economy is a dynamic force that ebbs and flows, much like the tide. Economic downturns, while challenging and sometimes scary, can also present unique opportunities for businesses to reevaluate their strategies, streamline their operations, and invest wisely for future growth. One such investment — that might not be immediately obvious but holds immense potential — is in requirements management and traceability solutions. In this blog post, we’ll explore why it makes sense to invest in these solutions during an economic downturn.
1. Enhanced Efficiency and Resource Optimization:
In times of economic uncertainty, operational efficiency becomes paramount. Requirements management and traceability solutions provide a structured framework for capturing, organizing, and tracking project requirements throughout their lifecycle. By optimizing requirements management processes, businesses can ensure that resources are allocated to the most critical aspects of a project. This reduces the risk of scope creep, minimizes wasted effort, and enhances overall project efficiency. With a clear understanding of project goals and dependencies, teams can work cohesively, to not only avoid both unnecessary and costly duplication of work but also enable organizations to allocate resources where they are most needed.
Economic downturns often come with increased financial constraints, so allocating resources to any new software investments might seem counterintuitive. But investing in requirements management and traceability solutions can truly act as a risk mitigation strategy. The right requirements management and traceability solutions facilitate comprehensive end-to-end impact analysis, allowing businesses to understand how changes to requirements can affect other aspects of the project or organization. By foreseeing any potential pitfalls and addressing them proactively, companies can increase process efficiency, minimize costly errors, rework, and recalls, and streamline development to accelerate time to market — ultimately safeguarding their investments in both time and resources.
3. Regulatory Compliance and Quality Assurance:
In certain industries, compliance with regulatory standards is non-negotiable. Implementing robust requirements management and traceability solutions can streamline the process of documenting and demonstrating compliance. These solutions enable clear documentation of how each requirement maps to relevant regulations, making audits smoother and reducing the risk of non-compliance penalties. Moreover, well-managed requirements also lead to improved quality assurance practices, ensuring that products or services meet the desired standards even during challenging economic periods.
4. Agility and Adaptability:
Economic downturns often require businesses to pivot their strategies quickly to address changing market dynamics. Requirements management and traceability solutions provide a foundation for agile decision-making. When requirements are well-documented and linked, it becomes easier to assess the impact of changes, make informed decisions, and adapt to shifting priorities without causing disruptions. This agility allows businesses to seize new opportunities and respond to market demands more effectively.
While the initial investment in requirements management and traceability solutions might seem significant, it pales in comparison to the potential long-term cost savings. When requirements are managed efficiently, projects are less likely to overrun budgets or experience delays due to misunderstandings or miscommunications. The cost of fixing issues after they’ve occurred is far higher than preventing them in the first place. By investing in proper requirements management, businesses can avoid the financial strains that arise from project failures or inefficiencies.
Conclusion:
In the face of economic uncertainty, investing in requirements management and traceability solutions might not be the most obvious choice, but it’s certainly a strategic one. These solutions offer a structured approach to managing projects, reducing risks, enhancing efficiency, ensuring compliance, and promoting adaptability. By making this investment, businesses position themselves for not only surviving economic downturns but also thriving in the long run. As the tide of the economy inevitably turns, those who have laid a strong foundation in requirements management will be better equipped to ride the waves of change.
https://www.jamasoftware.com/media/2023/09/2023-09-14-wise-investment.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2023-09-14 03:00:392024-01-17 23:17:20A Wise Investment: Requirements Management and Traceability Solutions During an Economic Downturn
“While the security of IT hardware and software has strengthened in recent years, the security of Internet of Things (IoT) … has not kept pace,”Microsoft’s Digital Defense Report 2022.
The Internet of Things (IoT) promises a flood of amazing new products, including autonomous cars, networked medical devices, home automation, and new devices in industrial applications. But data breaches affect millions annually, and there is real fear that hacked devices could be used for surveillance, fraud or even weaponization. With 17 billion IoT devices in the world the surface area for attack dwarfs that of traditional computer malware.
Make Security a First-Class Citizen During Development
Too often with IoT devices, security is an afterthought; sometimes it even gets scrapped due to time and resource constraints. But organizations cannot provide reliable security after the fact. Security must be addressed from day one, by both product development and leadership.
Consider architecture: There are many chipsets available that provide a security architecture for embedded devices, but less than 4% of new devices in 2018 include embedded security. The explanation for this oversight is obvious: Development begins without security in mind, leading to an architecture that omits it. And it’s not feasible to change the underlying architecture of a product after release to account for security.
Many devices that are shipped to consumers have little to no update mechanism, or their update mechanism requires the customer to be aware of an update and go through a cumbersome process. This inevitably leads to out-of-date software that is an easy exploit for hackers.
Just like the PC industry, IoT developers must embrace secure, OTA updates to keep their customers safe. It is not enough just to offer updates; developers should push security updates to devices that are connected to their services. This is not just good business practice; it protects the service provider’s critical SaaS infrastructure as well.
The Argument for Security in IoT Devices
Security is often seen as a cost, but if you understand it correctly, you can turn it into a value proposition or a competitive advantage that customers are willing to pay a premium for. For instance:
Today’s customers are increasingly concerned with security and privacy. Companies like Apple can charge a premium because they address these concerns.
Insufficient security can lead to counterfeiting.
Good security increases brand value and decreases the risk of brand erosion.
Security is required by law, and failure to comply can result in heavy fines.
Security as an Integral Part of Product Development
Once you recognize the importance of security, it’s logical to make it an integral part of your product development process. This means, amongst other things:
Security is part of the stakeholder needs and therefore must be part of the core requirements. This also applies to regulatory requirements, such as those derived from legislation like GDPR.
Make sure your architecture fits your security requirements, since architecture is one of the most difficult (and expensive) things to change after the fact.
Ensure your security requirements are tested. You achieve this by maintaining correct end-to-end traceability from requirements to test results.
Collaborate on all levels. If you want to prevent security from being patched on an ad-hoc basis, make sure that all teams communicate properly. For instance, an engineer might be tempted to write custom code to detect a Denial of Service (DoS) attack, but this might be addressed more efficiently on the architecture level.
Implement a product line strategy and perform systematic reuse. Security extends to the complete lifecycle of products, so you must be prepared to provide security updates for years to come. Also, reuse allows teams to use previously tested elements, improve quality and accelerate development.
Embracing security today provides more than just a competitive advantage – it may be crucial for survival. While a product development platform alone is not enough to address security, it is an integral component for implementing security policies and frameworks.
https://www.jamasoftware.com/media/2023/08/2023-08-22-iot-security-1.jpg5121024Josh Turpen/media/jama-logo-primary.svgJosh Turpen2023-08-22 03:00:212024-10-03 09:48:14How to Develop IoT Products with Security in Mind
ISO 24089, developed by the International Organization for Standardization (ISO), is a standard that provides guidelines for managing software updates in a methodical and orderly way. Planning, testing, deployment, and monitoring are all included in the framework for managing the software update process that is specified by the standard. The main requirements and advantages of ISO 24089 as it relates to software update management systems will be highlighted in this post.
Software is a crucial building block of the modern connected and automated vehicles. Once the product is sold to the customer it starts its utilization phase. Important software updates are needed to keep the vehicle up to date, roll out new features, eliminate defects or bugs and most importantly redress security vulnerabilities. These software updates are in most cases delivered remotely through over-the-air technologies. There is no need to necessarily take the car to a workshop in order to install these updates. These over the air technologies make the whole process vulnerable and a proper framework needs to be set up to organize this process and make sure that the right updates are delivered to the right vehicles. Therefore, companies producing cars must have a software update management system. An organization may run the risk of security flaws, software bugs, and compatibility problems if software upgrades are not managed properly. The UNECE (United Nations Economic Commission for Europe) has put a new regulation R156 in place to regulate the Software update and software update management system which by this regulation become mandatory for the type of approval process in the regulated markets. The goal of ISO 24089 is to provide a thorough method for managing software updates that reduces risks and guarantees that updates are implemented in a consistent and efficient manner to support compliance with the UNECE R156.
The framework of ISO 24089 revolves around a list of conditions that must be fulfilled in order to comply with the standard. These prerequisites consist of:
Policy Planning: Establishing a policy for software updates and creating a plan for handling updates are requirements for the organization. The goals and parameters of the software update management system should be specified in the policy, along with the roles and duties of the various participants.
Risk Management: The company must evaluate the risks posed by software updates and put precautions in place to reduce those risks. This entails locating potential security gaps and making sure upgrades don’t interfere with business as usual.
Testing and Validation: Before updates are deployed, the organization needs to set up a process for testing and validating them. This procedure should make sure that updates are compatible with the current software environment and do not add any new errors or compatibility problems.
Deployment: A procedure for deploying updates to production environments must be established by the company. This procedure should guarantee that updates are distributed in a regulated and safe manner, reducing the possibility of operations disruption for the company.
Monitoring: Establishing a process for monitoring and evaluating the software update management system’s performance is necessary for the company. Regular audits and evaluations of the system’s effectiveness and the identification of potential improvement areas should be part of this process.
Businesses can make sure that their software update management system is well-designed, efficient, and compliant with ISO 24089 by following these requirements. The standard offers businesses a framework for creating a dependable and consistent procedure for managing software updates, lowering the risks involved with updates, and making sure upgrades are applied quickly and effectively.
One of ISO 24089’s major advantages is that it aids businesses in raising the caliber of their software updates. Organizations can guarantee that updates are adequately tested and verified before deployment by putting in place a structured procedure for testing and validation, which lowers the chance of errors and compatibility problems. As a result, the organization’s overall operational environment becomes more solid and reliable.
The ability to lower the risk of security vulnerabilities brought on by software upgrades is another advantage of ISO 24089. Organizations can lessen the risk of cyberattacks and other security breaches by putting in place a risk management plan that involves the identification and mitigation of potential security threats.
Additionally, ISO 24089 supports businesses in enhancing their adherence to legal specifications for software updates. Numerous regulatory frameworks mandate that businesses have a formal, written process in place for handling software changes. Organizations can demonstrate compliance with these criteria and lower their risk of regulatory fines and other consequences by adhering to ISO 24089.
ISO 24089 assists enterprises in lowering the risks related to updates, enhancing the quality of their software environments, and meeting regulatory obligations by providing a thorough framework for managing updates. A more effective, dependable, and secure software update management system can help organizations that use ISO 24089 improve their overall operational performance and lower risk.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson and Atef Ghribi.
https://www.jamasoftware.com/media/2023/04/2023-04-04.inrtoduction-to-iso-24089-1.jpg5121024Atef Ghribi/media/jama-logo-primary.svgAtef Ghribi2023-04-25 03:00:112024-01-18 00:26:27Introduction to ISO 24089: Your Ultimate Guide to Understanding and Implementing This New Standard for Automotive
Trace Score™ – An Empirical Way to Reduce the Risk of Late Requirements
Executive Summary
One of the main causes of rework, delays, and cost overruns in product development is the creation of new requirements late in the process. This is a well-known risk in product development, but what management practices can empirically be shown to reduce this known risk?
Using our proprietary database of metadata from over 50,000 complex product development projects, we were able to determine that the Trace Score is an empirical method to reduce late requirements. In fact, teams that maintain a high Trace Score reduce the burden late requirements have on their project by 67% compared to teams with low trace scores.
With this knowledge, our recommendation is that practitioners measure and monitor the Trace Score of their projects to resolve issues early and ensure that the risk of late requirements is kept to a minimum.
Dataset Background
Jama Software has the world’s largest, live dataset of engineering process performance with over 50,000 engineering projects updated and growing continuously. Leveraging this dataset, it is now possible to determine empirically which management practices improve the performance of the product development process. To learn more about our benchmarking, please review our Traceability Benchmarking Report.
The Empirical Questions
In this analysis we will explore three key questions:
What are late requirements?
How do late requirements negatively impact projects?
Does maintaining a high Trace Score reduce the risk of late requirements?
What are late requirements?
For the purpose of this analysis, we define “late requirements” as those requirements created after the completion of a project’s requirement decomposition phase which we estimate as spanning the middle 50% of all requirement creation activity (creation and refinement). To illustrate what late requirements look like, we show two actual projects below with requirement activity plotted over time.
Requirement Creation Over Time
In the Timely Project, requirement creation occurs in a defined requirement decomposition phase to form a necessary and sufficient set of requirements, with very few requirements being added after the fact (e.g. in fig (a), only 1.3% of requirements created late). In the Late Project’, requirement creation bleeds into future phases of the project, leading to a significant amount of late requirements (e.g. in fig (b), 9.2% of requirements are created late).
How do late requirements negatively impact projects?
We can measure the outsized burden late requirements have on project teams, which we have illustrated for our two projects below. We define late requirement burden as the total number of requirement activities (creation and refinement) attributed to late requirements as a percentage of all requirement activity.
Impact of Late Requirements on Project Team Activity Burden
In the Timely Project, minimal late requirements enable better forecasting of project completion and limit the rework and cost brought on by late requirements (e.g. in fig (c), late requirements only create an additional 8% burden).
In the Late Project, the high volume of late requirements makes it much harder to forecast project completion as the scope of the project is constantly changing, and project teams need to accommodate the late requirements (e.g. in fig (d), late requirements contribute an additional 31% burden).
Unsurprisingly, this additional burden of late requirements has an impact during testing for requirement validation. In our actual project examples, the Late Project has a test failure rate over 3x that of the Timely Project.
Does maintaining a high Trace Score reduce the risk of late requirements?
A core theorem of Systems Engineering is that maintaining high requirement traceability from the start of a project reduces the risk of late requirements and negative product outcomes. With our project dataset we can now test this theorem empirically. We define traceability as a measure of a project’s ‘expected’ traceability that has actually been established and calculate the Trace Score as follows:(1)
For our example projects, the Timely Project achieved a Trace Score over 6X that of the Late Project; suggesting that maintaining a high Trace Score throughout the project reduces the risk of late requirements.
To further determine if Trace Score correlates to late requirements, we divided our dataset of projects into quartiles based on their Trace Scores (Quartile 1 = bottom 25% trace score, Quartile 4 = top 25% trace score) and then compared the distribution of ‘Late Requirements Burden’ across these quartile groups. What we found is that projects within the bottom traceability quartile had a median Late Requirements Burden 3x greater than those in the top traceability quartile. In other words, the evidence supports that projects managed with higher traceability generally experience less risk from late requirements.
Recommendation
Our analysis has shown that late requirements negatively impact projects and that managing projects through a Trace Score is the only empirical way to reduce the risk of late requirements. Below you can see how one can measure the Trace Score over time as a project progresses to ensure system engineering best practices are being followed. A low or falling Trace Score can quickly identify areas to address to reduce the risk of late requirements.
Here you can see how managing the Trace Score directly as the project is underway would have identified the risk early in the Late Project.
Interested in learning more? Download the entire Research Notes: Trace Score datasheetHERE.
https://www.jamasoftware.com/media/2023/02/2023-02-08-research-note-tracebility-score-1.jpg5121024Marc Osofsky/media/jama-logo-primary.svgMarc Osofsky2023-02-08 03:00:522024-10-03 16:56:29Trace Score™ – An Empirical Way to Reduce the Risk of Late Requirements
In this blog post, we will cover key components of the important medical device standard ISO 13485 and cover steps for successful adherence.
In the complex world of medical device development, teams not only face challenges of innovation, but also a shifting regulatory environment and evolving standards.
Balancing the competing interests of customers and stakeholders with the guidance and regulations from different entities across global boundaries presents challenges that even the most organized and methodical teams may struggle to meet.
In this environment, systems thinking can greatly improve the ability of medical device development teams to get products from the idea stage to market. By breaking down complex problems into manageable pieces, teams can better evaluate their systems and streamline and strengthen processes.
Using an applied systems approach will also help resolve inefficiencies in the development process and produce the outputs necessary for the design history file (DHF).
A growing number of organizations and teams are already pursuing a general systems approach by applying the guidance in ISO 13485:2016. This standard helps define a framework for the Quality Management System (QMS) for medical device development and pushes the development process naturally toward a systems approach. But for those teams that have not yet adopted the standard, adding one more document or piece of guidance to the overall process can feel like another layer of complication.
It doesn’t have to be. Adopting this standard can help standardize and systematize the medical device development process. Though it may look daunting at first, once adopted, ISO 13485 can streamline processes and position organizations for a better outcome with regulatory requirements.
The standard was developed by the International Organization for Standardization (ISO) to outline the standard for a Quality Management System (QMS) for the design and manufacture of medical devices.
The ISO defines “medical device” as “a product, such as an instrument, machine, implant or in vitro reagent, that is intended for use in the diagnosis, prevention and treatment of diseases or other medical conditions.” It is a stand-alone document designed for use by organizations of any size involved in any stage of medical device development, from design to production to installation to service of devices. Both internal and external parties can use the standard to support the auditing process.
ISO 13485 is the most common standard for quality management in the field of medical device development across the globe. Adoption of the standard indicates a commitment to the highest quality and safety across the development process, and it provides a foundation for QMS requirements.
While not required by all government entities, the standard does provide a good foundation for addressing regulations such as the EU Medical Device Directive and the EU Medical Device Regulation. In 2018, the FDA proposed a rule that would align US FDA 21 CFR 820 with ISO 13485:2016; this rule would make this standard the mandatory QMS for medical devices.
Note: The rule was set for release in 2019; however, as of December 2020, the rule was still forthcoming. Check for current guidance.
Though adoption of ISO 13485 may look complicated or daunting, in reality, adhering to the standard helps eliminate some of the ad hoc nature of requirements and systems in the medical device field.
With increasing worldwide adoption of ISO 13485 by both companies and government entities, the medical device industry should start to realize some harmonization and consistency of processes and systems. This standardization will help streamline the industry overall and allow important innovations a smoother and potentially faster route to market.
The requirements to obtain ISO 13485 certification start with a QMS. ASQ defines a Quality Management System as “a formal system that documents the structure, processes, roles, responsibilities and procedures required to achieve effective quality management.” The QMS must include documentation that defines the overall scope and implementation of the QMS; important documentation includes Quality Policy, Quality Objectives, and Quality Manual.
Bottom Line These documents should be sure to address customer requirements. In addition, organizations need to create mandatory and additional processes and requirements necessary for all stages of development. Examples of documents required by ISO 13485:2016 can be found here.
Key Takeaways from Our Complete Guide
ISO 13485 and systems thinking go hand-in-hand; teams will find that adoption of ISO 13485 directs them toward systems thinking.
Adoption of this standard will streamline processes and position medical device teams for better regulatory outcomes.
ISO 13485 is a stand-alone document; however, it closely aligns with ISO 9001:2008 and EN ISO 13485.
ISO 13485 and ISO 14971 are related, but ISO 14971 is more focused on risk management – the two standards can be used in tandem.
This standard is not mandatory; teams can develop a Quality Management System (QMS) without the standard as long as it meets regulatory requirements. However, adoption of the ISO 13485 will create a QMS that is ideally positioned to meet the requirements of various regulatory and legislative entities, including the EU.
Jama Software’s Complete Guide to ISO 13485 for Medical Device Development covers requirements for adherence, the difference between ISO 13485 and other medical device standards, and steps for successful adoption and certification.
Download The Complete Guide to ISO 13485 for Medical Device Development to untangle everything there is to know about this important standard.
https://www.jamasoftware.com/media/2021/02/2021-02-18-ISO-13485-ebook-1024x512-1.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2022-09-08 03:00:002023-03-20 16:46:12[GUIDE] ISO 13485 for Medical Device Development
