Tag Archive for: risk management

Navigating the New DOGE Impacted FDA: How MedTech Companies Can Build a Competitive Advantage

Navigating the New DOGE Impacted FDA: How MedTech Companies Can Build a Competitive Advantage

The Center for Devices and Radiological Health (CDRH) is a key branch of the FDA that is responsible for ensuring the safety and effectiveness of medical devices. Companies interact with the CDRH through premarket submissions, quality inspections, recalls, and a variety of other activities.

In 2025, the Department of Government Efficiency (DOGE) was established to streamline federal operations, reduce redundancy, and improve cost-effectiveness across agencies. While its goals are rooted in efficiency, the implementation has led to substantial structural and operational shifts that will have a profound impact on the industry.

For companies developing medical devices, understanding these changes is essential for navigating the evolving regulatory landscape. This blog will help you learn all about those changes and provide actionable strategies to stand above the competition while navigating the new frontier.

Key Changes to CDRH Under DOGE

Workforce Restructuring

One of the most immediate and highly publicized impacts has been a reduction in staffing. The CDRH has experienced layoffs, hiring freezes, and a mandated attrition ratio. These changes have affected teams working on new technologies, slowing down review processes and resulting in a reduction in internal expertise.

Budget and Operational Adjustments

DOGE reforms have also reduced discretionary funding, increasing the CDRH’s reliance on user fees from industry sponsors. This shift has created operational bottlenecks, particularly in areas not directly supported by these fees, such as early-stage innovation and public health initiatives.

Regulatory Process Reforms

With fewer staff and resources, the CDRH has had to adjust some of its regulatory workflows. It has been reported that pre-submission meetings are less frequent, and review timelines have lengthened. While the agency remains committed to scientific rigor, the capacity to provide interactive feedback has diminished.

RELATED: Jama Connect® for Medical Device & Life Sciences Development Datasheet

Strategic Reforms Planned for the CDRH

Proposed Guidance Still Moving Forward

Despite the challenges mentioned above, CDRH plans to continue advancing its strategic priorities. The FDA has released its 2025 guidance agenda which includes the following amongst a larger list of items:

  • Cybersecurity in Medical Devices: Updated guidance on quality system considerations and premarket submissions.
  • AI Lifecycle Management and Change Control Plans: Recommendations for predetermined change control plans.
  • Use of Real-World Evidence in Regulatory Decisions: Revised guidance to support regulatory decision-making.
  • Updated Q-Submission Program Guidelines: Updates to improve feedback and meeting processes for device submissions.

These initiatives reflect CDRH’s ongoing commitment to modernization, even amid structural constraints resulting from DOGE actions.

AI Use in Submissions: A New Frontier

In another move to improve efficiency and modernize the agency, the FDA has begun using Elsa, a generative AI tool to assist in the scientific review of medical device submissions. This tool will help automate repetitive tasks such as document parsing and data extraction, allowing human reviewers to focus on more complex portions during the evaluation. The rollout is expected to be complete by mid-2025, with early results showing promise in reducing review times and improving consistency.

Proven Strategies for Navigating the Changes

For those in the medical device industry, these changes present both challenges and opportunities. Companies that embrace the changes and take a proactive approach to interacting with the FDA will find themselves at the forefront of the new era.

Here are some key approaches to consider:

  • Prioritize Proactive Regulatory Planning: A clear and complete regulatory plan is a vital piece of every new product development project. It will be especially important now as you should prepare for longer review times and less interaction with reviewers. Build extra time for regulatory approvals and work with regulatory consultants to anticipate and address obstacles.
  • Maintain Clear Communication with the FDA: Given the FDA’s reduction in resources, clear and targeted communication is more important than ever. Leveraging the FDA’s pre-submission program allows you to gain valuable insights early in the submission process. Regular interaction will help build rapport with the agency while addressing concerns before they delay approvals.
  • Collaborate Across Teams to Document All Product-Related Information: Interdepartmental alignment is critical when interacting with the FDA. Your product development, QARA, and manufacturing teams must communicate effectively to address compliance needs and streamline decision-making. Working together to tell a cohesive and complete story about your device will be imperative when interacting with reviewers. It will be especially important in the future as AI tools may flag inconsistencies or gaps more rigorously than human reviewers.
  • Leverage Digital Transformation: Investing in digital tools is no longer optional for medical device product development teams. Modern platforms help teams track requirements, manage testing, and maintain documentation seamlessly. Digital platforms also ensure traceability, streamlining compliance audits, and reducing risks of regulatory missteps. Additionally, automated workflows and AI-powered solutions can reduce manual effort and free up critical resources to do what they do best, designing life-changing technologies.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

How Jama Software Can Support Your Success

When navigating regulatory pressures, Jama Software is the trusted partner MedTech companies need. Our platform empowers organizations to overcome compliance challenges while maximizing efficiency. Here’s how Jama Connect will help you navigate the changes at the FDA:

  • Simplify Regulatory Compliance: Jama Connect® simplifies compliance with FDA regulations by providing complete traceability throughout product development. Built-in templates for ISO 13485, ISO 14971, and FDA requirements help teams comply effortlessly with the regulations.
  • Reduce Submission Errors: Errors in FDA submissions can lead to costly delays and loss of potential revenue. Jama Software’s traceability matrix ensures all requirements are accounted for and verified, reducing the likelihood of mistakes that can delay review times or even result in resubmissions.
  • Accelerate Time-to-Market: Our real-time collaboration and requirement management tools optimize project workflows, reducing rework and enabling faster decisions. This means your products reach the market sooner, even when facing FDA review delays.
  • Improve Risk Management: With Jama Connect’s risk management capabilities, teams can capture failure modes and hazard analyses for medical devices, ensuring adherence to safety requirements under FDA guidelines.
  • Stay Aligned Across Teams: Jama Connect’s centralized platform fosters alignment between engineers, designers, and quality assurance teams. Eliminate silos, improve team collaboration, and keep every stakeholder fully informed at all stages of development.
  • Create a Competitive Advantage in the New Era of MedTech: The DOGE-era FDA brings unprecedented change to the MedTech industry. With the right strategies and tools, your organization can turn these challenges into opportunities to build resilience, operational efficiency, and create a competitive edge.

To streamline product development, tackle complex compliance requirements, and stay ahead in the fast-evolving MedTech landscape, consider partnering with Jama Software. Curious how Jama Software can help your team thrive? Learn More Today.

 

Requirements Traceability – How to Go Live

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.

RELATED POST: Requirements Management Guide: Requirements Traceability

So how do you achieve Live Traceability?

Step 1: Define a Traceability Model

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


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.

RELATED: Jama Connect® for Medical Device & Life Sciences Development Datasheet

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.

RELATED: Mastering ISO/IEC 27001: A Guide to Information Security Management

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.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Expert 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.

First, teams must balance time demands with the need to launch products that are both safe and effective. Today, the time to define requirements has increased by 29%, and unplanned requirements churn has increased by 81%, resulting in about 70% of medical products being delivered late.

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.

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

Market-Driven vs. Contract-Driven

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.

RELATED: How to Overcome Three of the Biggest Challenges in Medical Device Development

What is Systems Engineering in Healthcare?

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.

TO LEARN MORE, DOWNLOAD THE COMPLETE WHITEPAPER HERE:
“Applications of Systems Engineering in Healthcare”

 

 

 

 

 

Pioneering Excellence in Healthcare: Q&A with Systems Engineering in Healthcare

Pioneering Excellence in Healthcare: Q&A with Systems Engineering in Healthcare

On December 5th, 2023, Jama Software® hosted an exclusive one-day thought leadership event, featuring industry experts Chris Unger – Retired GE Healthcare Chief Systems  Engineering Officer – PracticalSE LLC, Bijan Elahi – Founder of MedTech Safety, and Vincent Balgos – Director of Medical Device Solutions at Jama Software. Attendees of this event were invited to deep dive into best practices in Systems Engineering and Risk Management, crucial pillars of successful medical device development.

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.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

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.

RELATED: 2024 Predictions for Medical Device & Life Sciences Product, Systems, and Software Development

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.

What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security

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.

RELATED: Understanding Integrated Risk Management for Medical Device

Why is security for medical devices important?

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

  1. 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.
  2. Security risk evaluation. Establishes a security assessment strategy and testing processes.
  3. Security risk control. Identifies, designs, and implements security risk control measures, as well as verifying the implementation effectiveness of any security risk control measures.
  4. Evaluation of overall security residual risk acceptability. Determine if the “security residual risk” of a device is acceptable.
  5. Security risk management review. A security management report is prepared.
  6. 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:

  1. Security risk analysis process: It suggests that manufacturers perform a security risk analysis, and the results are recorded in the “security risk management file.”
  2. 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.”
  3. Identification of assets and characteristics related to security: You’ll also identify potential medical device vulnerabilities such as third-party components, hardware, and software.
  4. 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:

  1. Evaluation of each security risk: Identify each security risk area, determining if a “security reduction” is required.
  2. Evaluation of security risks with a potential safety impact: Consider every potential risk to determine any potential safety impacts.

RELATED: Application of Risk Analysis Techniques in Jama Connect® to Satisfy ISO 14971

Section 3: Security Risk Control

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:

  1. Security risk control option analysis: Determine if a security risk control measure is appropriate for mitigating security risks to an “acceptable level.”
  2. Implementation of security risk control measures: Security risk measures are selected based on the prior step.
  3. 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.
  4. 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.
  5. 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.
  6. 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:

  1. The security risk management plan has been appropriately implemented.
  2. The “security residual risk” is at an acceptable level.
  3. Methods are in place to gather and review details in the production and post-production phases, and leadership has reviewed and approved the plan.

Image showing the flow of different stages of risk.

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.

DOWNLOAD THE ENTIRE EBOOK: What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security

A Wise Investment: Requirements Management and Traceability Solutions During an Economic Downturn

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.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Software Development

2. Risk Mitigation:

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.

RELATED: Requirements Traceability Diagnostic

5. Long-Term Cost Savings:

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.

Download the complete eBook to access simple, interactive ROI calculators and learn the financial benefits of investing in a requirements management solution during an economic downturn >>
Why Investing in Requirements Management During an Economic Downturn Makes Good Business Sense


How to Develop IoT Products with Security in Mind

“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.

RELATED: Four Key Considerations When Choosing a Cloud-Based Engineering Tool Provider

OtA Updates Should Be a Requirement

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.

RELATED: What is DevSecOps? A Guide to Building Secure Software

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.


Introduction to ISO 24089: Your Ultimate Guide to Understanding and Implementing This New Standard for Automotive

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.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Software Development

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

RELATED: [Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System

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.


trace score

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:

  1. What are late requirements?
  2. How do late requirements negatively impact projects?
  3. 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).

RELATED: Requirements Traceability Benchmark

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.

percentage chart

RELATED: Unlocking The Power of Live Traceability with Jama Connect

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)

established over expected

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.

traceability chart

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.

Benchmark Chart

To learn more about achieving Live Traceability™ on your projects, please reach out for a consultation.

Interested in learning more? Download the entire Research Notes: Trace Score datasheet HERE.