BrightInsight Drives Efficiency Using Jama Connect
ABOUT BRIGHTINSIGHT
BrightInsight is a trusted partner for top life sciences companies, delivering regulated digital health solutions like Software as a Medical Device (SaMD) that transform patient care. In collaboration with leading BioPharma and MedTech firms, BrightInsight has developed pioneering solutions across more than 11 therapy areas.
CUSTOMER STORY OVERVIEW
Operating in a highly regulated industry, BrightInsight navigates strict deadlines, complex regulatory requirements, and dynamic client expectations. To maintain its competitive edge, the company needed a robust requirements management tool to refine its processes. A key challenge was integrating cybersecurity into its overall patient safety risk management framework.
By implementing Jama Connect, BrightInsight created a novel, integrated approach to risk management. This allowed them to automate traceability, optimize documentation, and significantly improve project efficiency. As a result, BrightInsight has reduced risk assessment activities by more than 50% and accelerated project timelines, all while ensuring comprehensive cybersecurity and patient safety.
“We’ve been able to link cybersecurity risks back into patient hazards, which is something many companies struggle to do. Jama Connect’s traceability and item relationships make that possible.” – Lucas Holt, Director of Systems Engineering, BrightInsight
WITH JAMA CONNECT, USERS EXPERIENCE:
Ability to seamlessly link cybersecurity risks to patient safety hazards, creating comprehensive risk models that improve safety and compliance.
Optimized workflows and reusable requirement repositories help users reduce project timelines by months, expediting product launches and increasing efficiency.
Real-time feedback tools and robust traceability features streamline collaboration while ensuring audit-ready documentation that impresses regulators.
“Jama Connect really forces you to think about traceability right from the get-go of the project, where in the old way of doing it, traceability was often an afterthought. It’s the right way to do it.” – Lucas Holt, Director of Systems Engineering, BrightInsight
CHALLENGES
Before implementing Jama Connect, BrightInsight faced several industry-wide challenges that hindered its ability to innovate safely and efficiently.
Fragmented Risk Management: Managing cybersecurity and patient safety risks in separate streams resulted in disjointed assessments. This separation made it difficult to understand the true impact of a cyber threat on patient health.
Inefficient Documentation: Manual processes using Word and Excel were inefficient, prone to error, and limited collaboration across global teams.
Cumbersome Traceability: The document-first approach made tracing relationships between requirements, risks, and test cases a time-consuming manual task, often delaying regulatory submissions and product launches.
BrightInsight leveraged the powerful features of Jama Connect to build a unified and efficient development process, with a groundbreaking approach to risk management.
A Novel Approach to Cybersecurity Risk The most significant change was integrating cybersecurity directly into patient safety risk management. Using the powerful traceability features in Jama Connect, BrightInsight linked cybersecurity threat models directly to patient hazards. This innovative structure allows them to create comprehensive risk models connecting assets, vulnerabilities, and threats to specific patient safety outcomes.
Item-Based Management for Seamless Traceability Jama Connect’s item-first approach enabled BrightInsight to manage traceability from the very beginning of a project.
Optimized Reuse and Standardization BrightInsight created reusable requirement repositories, particularly for common elements like cloud-based services. New projects can now pull from this “off-the-shelf” library of pre-built modules with fully linked requirements, risks, and testing frameworks.
Streamlined Reviews and Collaboration Jama Connect’s Review Center replaced lengthy meetings with real-time, asynchronous collaboration. Teams can now access shared projects, provide feedback, and monitor revisions, dramatically improving review timelines.
“The reusability of items, requirement sets, and risk management really shines for us, it has significantly reduced our design cycles.” – Lucas Holt, Director of Systems Engineering, BrightInsight
OUTCOMES
Since implementing Jama Connect, BrightInsight has achieved measurable improvements, solidifying its position as an industry leader.
Faster Cybersecurity Risk Assessments: By integrating and standardizing its processes, the team reduced the time for cybersecurity and patient safety risk evaluations from six weeks down to just two.
Boosted Overall Efficiency: Optimized workflows have expedited product launches, allowing BrightInsight to reduce project timelines by three to six months for its pharma clients.
Enhanced Regulatory Confidence: During audits, BrightInsight can now produce audit-ready documentation with full traceability instantly. This organized, structured approach leaves auditors impressed and confident in their compliance.
Improved Client Satisfaction: Faster turnarounds and greater assurance of quality documentation have led to increased trust and stronger, more successful business relationships.
Write Clear Design Inputs: A Practical Guide to ISO 13485 Compliance
In the medical device industry, the clarity of your design and development inputs is vital. Unclear or conflicting requirements can slow down development and make it harder to meet regulatory expectations. This session offers practical guidance to help ensure your design inputs are clear, complete, and fully aligned with ISO 13485 standards.
In this webinar, industry expert Peter Sebelius, CEO and Trainer at Medical Device HQ, shares proven strategies for writing effective requirements. Discover how to avoid common mistakes and build a strong foundation for compliant, successful product development.
Key Takeaways:
Identify and steer clear of the most common mistakes in requirements engineering, using real-world examples.
Learn straightforward techniques to make your requirements clear and organized.
Put proven patterns to work so your documentation is complete, audit-ready, and easy for all stakeholders to understand.
Understand ISO 13485 expectations so your design inputs are unambiguous, verifiable, and consistent.
Walk away ready to write clear requirements and robust design inputs that stand up to ISO 13485 audits and set your team up for development success.
WEBINAR VIDEO PREVIEW BELOW – CLICK HERE FOR ENTIRE PRESENTATION
Tom Rish: Thank you for joining us today with today’s webinar on How to Write Design and Development Inputs. We’re very excited for today’s speaker, Peter, and I’ll give you a proper introduction to him here in a few minutes, but I want to cover a few housekeeping things about the webinar platform.
First off, my name is Tom Rish. I’m the head of vertical marketing for the medical device and life sciences group at Jama Software. I’m very excited to introduce our speaker, Peter Sebelius. Peter is one of those rare people who can take something very complex like medical device regulations, product development, and make it understandable. He’s a highly respected trainer, consultant, and entrepreneur in the medical device industry. And one of the most exciting things for all of us here is he’s a member of the joint working group that authored the latest versions of ISO 13485 and ISO 14971 standards. So you don’t get very many chances to interact with somebody who has that much influence on the regulations.
One of the things I love most about Peter is he’s known for his clear no nonsense explanations, very practical teaching style. I think one of my favorite things is to find a post on LinkedIn that I sometimes think, “Oh, I don’t know if I fully agree with that.” And usually if I go to the comments section, I see Peter there correcting it and I always enjoy reading those. He speaks for what’s true and that’s great in this industry.
His focus areas are design controls, requirements engineering, risk management. I’ve actually had a chance to take one of Peter’s courses myself in the past. It was the risk management course and I’m very grateful for that. I was about years into my career, actually. I wish I would’ve taken it earlier. Many of you in this industry, if you’re like me, had a bunch of binders plopped on your desk on your first day and said, “Read through these regulations.” And unfortunately, that doesn’t really teach you enough about what you need to do to do things right. That risk management course was amazing and I learned a lot about how to do it the right way. If I was leading a new medical device project right now or had a team of people, whether young or old, I highly recommend taking some of Peter’s courses.
And on that, his courses, Peter is the founder of Medical Device HQ, which is this company that we’ll hear more about on the next slide. And Peter has a great team behind all of the training courses that they deliver. What makes them stand out specifically is they’re created by ISO and IEC standards committee members, so very impressive, important people providing practical application, not just the theory behind it, which I think so many of us get exposed to, but actually how to do it. They offer fantastic resources in the form of articles and YouTube videos. Check out their YouTube channel. If you go to YouTube, it’s just Medical Device HQ. Their training cover a lot of topics ranging from design controls, requirements engineering, risk management, usability. I know I’ve seen the ISO 13485 on quality systems as well. So there’s a training for about everything. You can do it online, you can do it in blending formats with live classroom sessions or even through your company’s LMS. We’ll include a link to all of those courses in their website and a follow-up email after this webinar.
So with that, I’d like to hand it over to Peter. And thank you for being here, Peter. We’re excited to learn more from you.
Peter Sebelius: Thank you so much for that introduction, Tom. It was a pleasure. So let’s get to it. In this session, I’ll be showing you how to write unambiguous design and development inputs and meet ISO 13485 requirements. One of my first questions to you is really are requirements important? Well, yes they are. Now, studies have shown that the root cause of a lot of nonconformity and quality problem would be poor requirements. Now, one thing about the medical device industry that makes me really sad is that many medical device organizations, they work with requirements not because they see the value in it, but because they have to. And this I would say is a general problem in our industry. Too many organizations do what’s required without knowing why and without seeing the value, it’s compliance above quality, which I think is a very sad or odd way of looking at things.
So I hope that after this webinar you will believe in the value of writing good requirements, but if you don’t and you’re entirely focused on compliance, should you then be paying attention? Well, yes you should because if you take a look at sub-clause 7.3.3 in the ISO 13485 on design and development inputs, you can see that your design and development inputs or requirements shall be complete, unambiguous, able to be verified or validated, and not in conflict with each other. Now, if you don’t know what these things mean, trust me when I say not many do, you are at risk of getting non-conformities. And luckily, for those who don’t know the meaning of these characteristics, not many auditors do either. Only in some cases are auditors likely to react if your requirements don’t fulfill these characteristics. And that is one of the reasons why I created a pretty unique course on requirements engineering for medical devices on Medical Device HQ, because I’ve seen that there are very few who knows this area in the medical device industry.
So what you will be seeing today are some highlights from this course. If you’re interested in learning more, you are obviously very, very welcome to register on the full course, which is much more comprehensive than what we are looking at today. So during my training courses, I often ask how many of the participants have participated in risk management? And then I ask, how many of you have formal training or risk management? And usually about 90% would say that they are involved in risk management and that they have some kind of training. And then I continue to ask, how many of you have been involved in writing requirements? And it’s almost as many as in risk management. Then when I ask how many have formal training and requirements engineering? And when I say training, I don’t mean read and understood. That doesn’t count. Like Tom’s reference, read all the binders. That doesn’t count as training if you ask me.
Now, what do you think happens when I ask about that? Well, it becomes very silent. It’s less than 5% who says that they have some kind of training on writing requirements. And that’s really unfortunate because writing requirements is a critical task if you want to be successful with product development and medical devices, it’s the foundation. But not only that, if you don’t know what you’re doing in this area, it also creates lots of frustration and conflicts between the team members and then you’re wasting time. And I really dislike wasting time. I think we should be bringing medical devices to market as quickly and as efficiently as we can because every new medical device should be an improvement compared to the previous ones, which means if we are wasting time, we’re depriving the public of better healthcare. And that’s unethical, believe it or not.
Now, this task, the writing requirements requires both knowledge and skill to be done correctly and successfully. Now, before getting to how to write good requirements, let me talk about two more pain points in the area of requirements engineering in the medical device industry and let me know if you agree and you recognize any of these issues in the chat. And like Tom said, we appreciate if this is interactive. So if you say yes or you’ve seen exactly this, do share it in the comments. That just makes everything nicer and more attractive. So the first pain point is that requirements end up in the wrong processes. It could be that you find design outputs together with the design inputs or you find risk controls that are documented as user needs. There are so many mix-ups, and when you try to push the various types of requirements through the wrong processes, it’s utterly confusing. It could even result in non-conformities and it will not work well. And I will come back to why.
Jama Connect® Features in Five: Nuclear Reactor Design and I&C Development Solution
Learn how you can supercharge your systems development process! We always want to be respectful of your valuable time. Still, in this Features in Five video, we do go beyond the promised five-minute format to include an information-packed session, hosted by Vlad Tanasescu, GM, Industrial & Consumer Electronics, Jama Software.
Designing nuclear reactors is a complex, high-stakes process requiring precision, safety, and collaboration. Jama Connect’s out-of-the-box framework simplifies this complexity by guiding engineering teams through requirement decomposition, safety assessments, and risk analysis while ensuring traceability across the entire digital thread.
With AI-driven automation, real-time gap detection, and seamless tool integrations, Jama Connect empowers teams to streamline processes, enhance collaboration, and accelerate time to market, all while maintaining the highest safety and compliance standards.
VIDEO TRANSCRIPT
Vlad Tanasescu: Hi, I am Vlad. I lead our energy business unit here at Jama Software, and today I will walk you through a brief live demonstration of our new out-of-the-box nuclear reactor design and instrumentation and control (I&C) system development framework. Our engineering management platform, Jama Connect, enables an intelligent, guided, and measurable product development approach. In Jama Connect, we use process rules to define end-to-end engineering and design processes. Jama Connect will leverage this process to automatically guide the engineering organization through their development, intelligently measure system and process completion, and automatically detect gaps and risks so that engineers know where to take action.
On a high level, our nuclear reactor design framework starts from the decomposition of the requirements and the parallel decomposition of our designs and architectures from the highest level of the plant all the way to the mechanical and software implementations. The framework natively enables the initial deterministic safety assessment, the classification of initiating events in design-based accidents, the categorization of security and safety functions, and the classification of structures, systems, and components in alignment with the guidance of the International Atomic Energy Agency (IAEA) and local nuclear reactor design assessors.
The framework also includes the probabilistic safety assessment, the accident, and those consequence analysis and the analysis of combined risks. Nuclear reactor design is highly iterative. As our design and construction progresses, we will continuously find new safety and security requirements and functions as well as new reliability requirements and special treatments, all of which will need to cascade and feedback into the functional and non-functional levels of our reactor. Nuclear reactor design practitioners integrate model-based systems engineering, product life cycle management, pipeline and instrumentation diagramming and software development tools to Jama Connect to extend the traceability from the definition of our reactor to how our reactor is being implemented in mechanical software and electronics disciplines.
Tanasescu: These integrations will enable us to programmatically measure traceability and system completion across all of our tools, part of the engineering digital thread. For example, from one of our high-level mission needs, energy efficiency, we can directly visualize the allocation to a plant design coming from a model-based systems engineering solution, and then we can follow the decomposition of the requirement and the plan design all the way down to the mechanical implementation.
For example, from this plan design, we have derived multiple system architectures of the key reactor systems, which are further decomposed into multiple subsystem designs, which are further decomposed into component designs, which are ultimately decomposed into mechanical implementations like parts and key assemblies. This end-to-end traceability across the entire digital thread will enable us to understand the impact of changes starting from a requirement all the way down to the lowest implementation level. For example, if I were to change this energy efficiency requirement, I could run an impact analysis in Jama Connect, and then Jama Connect would show me that multiple design levels would be impacted by the change, but five levels down, I would also be impacting implementations in mechanical parts. I would be impacting safety mitigations and risk mitigations as well as executed tests, which is very powerful to understand before the change.
Jama Connect will use intelligent engineer management features like the Live Trace Explorer to intelligently measure the completion of our traceability across the entire digital thread. These intelligent measurements will programmatically summarize the completion of the decomposition of the requirements, the decomposition of the designs, the test coverage, the risk mitigations, as well as the completion of the implementation of our system. Due to the integrations with other tools like product lifecycle management or model-based systems engineering applications, we can start measuring to what extent our component designs have been implemented in parts or our software requirements in software implementations. For example, here we can see that only 2% of our component designs have been implemented in parts or only 2% of our component designs have been analyzed and taken into account in the initial deterministic safety assessment. These intelligent measurements will enable companies to mitigate, rework and reduce their time to market. We will always be able to understand where we have gaps and risks in our system so that we know where to take action.
Tanasescu: In Jama Connect, we use the project tree to visualize and access all of our engineering data in one view. The project tree will also enable us to set up our product breakdown and systems engineering structure. Here, we can see the key subsystem of the reactor and the balance of plant, each subsystem having its respective requirements, designs, and tests, and then one level down, we can visualize the key components of our subsystem. Each component, including requirements, designs, tests, and mechanical software, electronic specific implementations like parts or software user stories. Our out-of-the-box nuclear reactor design framework also contains data models for the automatic calculations and classifications of initiating events and design-based accidents for the categorization of safety and security functions and for the classifications of structure systems and components. The Jama Connect Nuclear Reactor Design framework will also enable the automatic export of initial, preliminary, and final design safety reports and will enable the programmatic creation of security and safety cases.
Our I&C system development framework is reduced to the scope of the development of nuclear reactor subsystems. And in accordance with standards like EEC or EEC61508, the I&C development decomposition starts at the level of the safety design base. The I&C systems development framework also enables codevelopment. Nuclear reactor OEMs, I&C system T1s, and external engineering partners can use Jama Connect as a central source of truth for the entire design and engineering-related collaboration, and they can use Jama Connect’s intelligent engineering management capabilities to measure system completion and identify gaps across the entire engineering data coming from all the partners from our development ecosystem.
We view the adoption of artificial intelligence as essential for reducing time-to-market and increasing efficiency in nuclear development. Jama Connect’s engineering AI enables engineers to highly automate day-to-day and manual tasks like the definitions of tests or the decomposition of requirements. For example, here I have a requirement related to the nuclear fuel and instead of me deriving the test manually, I will use Jama Connect’s engineering AI to derive multiple tests automatically*, and then Jama Connect’s AI will proceed to derive multiple tests that our engineers could choose to take over and relate in traceability with the requirement.
This way, both the test generation and the traceability creation will be highly automated. Thank you very much for your time. If you want to learn more about our nuclear reactor design and IC system development framework, please visit our website. Thank you.
*Test Case Generation available through our add-on product, Jama Connect Advisor™
Jama Connect® Features in Five: Empowering Project Owners in the AEC Industry
Managing construction projects can feel like trying to juggle a dozen tasks at once while standing on a tightrope. For project owners in the architecture, engineering, and construction (AEC) industry, the stakes are even higher. Misalignment among stakeholders, inflated risk costs, and compliance challenges can derail even the best-laid plans, causing delays, inflated costs, and unnecessary headaches.
But what if there were a way to simplify the complexity and take control? That’s where Jama Connect comes in. Designed to tackle the toughest challenges in construction project management, Jama Connect gives project owners the tools they need to streamline processes, align teams, and keep projects on track.
In this Features in Five session, we’re featuring a must-watch video with Michelle Solis, Solutions Architect at Jama Software. She breaks down the persistent challenges facing project owners and demonstrates how Jama Connect empowers teams with clarity, accountability, and confidence. Whether you’re managing public infrastructure, real estate developments, or any large-scale project, this is your opportunity to discover smarter solutions for project success. Read on to learn more!
VIDEO TRANSCRIPT
Michelle Solis: Hi there. I’m Michelle Solis, a solutions architect at Jama Software. In this Features and Five video, we break down real problems the AEC (architecture, engineering, and construction) industry is facing, and how smart teams are solving them. Today, we’re speaking directly to project owners. Whether you’re a public agency, real estate developer, or infrastructure lead, if you’re responsible for project outcomes, this episode is for you.
We’re going to cover three of the most persistent challenges owners face: misalignment across stakeholders, risk-inflated bids, lack of accountability and compliance exposure, and, more importantly, how Jama Connect helps you get ahead of them.
Managing construction projects isn’t easy, and owners face a range of interconnected challenges that can derail success. These challenges include:
Misalignment across stakeholders: When teams interpret requirements differently, it leads to design errors, miscommunication, rework, RFIs, and change orders. Without a unified system to manage and communicate requirements, projects are prone to scope creep and wasted resources.
Risk-inflated bids: During bidding, contractors often pad their numbers due to unclear expectations. This results in risk premiums, vague assumptions and inconsistent comparisons, forcing owners to choose between suboptimal options and inflating costs.
Lack of accountability: Without clarity on who owns specific requirements, you’re left exposed to safety risk, regulatory penalties, and liability due to non-compliance. Invisible accountability creates confusion, finger-pointing, and increased project risk. Together, these problems affect your ability to deliver projects on time, within budget, and with confidence. Addressing them requires a solution that brings clarity, alignment, and accountability to every phase of the project.
Solis: Jama Connect empowers project owners with comprehensive solutions to streamline construction projects, reduce risk, and improve outcomes. Here’s how it addresses key challenges.
Stakeholder alignment: By providing a shared source of truth for all requirements, from design to regulatory to contractual, Jama Connect ensures that everyone is on the same page. Requirements are traceable, version controlled, and validated, allowing teams to see who authored a requirement, what changed and why. This proactive alignment helps catch gaps early and prevent costly mistakes.
Clear scope for competitive bids: Jama Connect eliminates ambiguity during the bidding process by clearly defining scope and acceptance criteria. This clarity gives contractors the confidence to price jobs accurately, reduce inflated risk premiums, and ensure you’re comparing apples to apples. The result; faster bids, competitive pricing, and a smarter use of project budgets.
Built-in accountability: Accountability is made seamless with Jama Connect. Every requirement is assigned to an owner and tracked in real-time, ensuring comprehensive oversight. Requirements are also linked to compliance standards, contracts, or codes, providing audit-ready documentation whenever needed. If issues arise, traceability tools help resolve them quickly and transparently. Together, these capabilities equip you with the visibility, clarity, and confidence you need to deliver successful construction projects.
Solis: Let’s quickly look at Jama Connect in a project owner dashboard. Jama Connect dashboards are a visual tool to help with the three problems we just explored.
Accountability. This bar graph shows us who’s assigned to each of these stakeholder requirements. If multiple PMs are working a project, you can manage them all in one place.
Stakeholder alignment. This list of owner requirements is easily configured to show the data owners might be tracking daily. We have the priority column that shows us how the requirement has been categorized and the percent of downstream completed requirements. Owners are able to see all of this information in one place.
Clear scope. This last widget is a pie chart that separates the project requirements by their status. I can quickly see which are being worked on, have cost implications or schedule delays. These are all interactive, so I can click into the section like the schedule delay and see the specific information for those requirements.
Here’s the takeaway for project owners. Construction is complex, but you don’t have to lose sleep over scope creep, inflated cost, or compliance headaches. Jama Connect gives you the visibility, control, and confidence you need to deliver successful projects from planning to handover. Thank you for watching this demonstration of how Jama Connect empowers project owners in the AEC industry. To learn more about optimizing your projects, visit our website at jamasoftware.com. If you’re already a Jama customer, your success manager, or Jama software consultant, can provide you additional insights. Together, we can build better outcomes.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
