This blog recaps part of our recent Whitepaper “Engineering Governance is a Critical Business Strategy for Product, Project, and System Development Excellence – Click HERE to read it in full.

Engineering Governance is a Critical Business Strategy for Product, Project, and System Development Excellence

Having a robust business strategy that reduces risk is critical for managing complex product, project, and system development.

What Is Engineering Governance?

Engineering governance is a system of policies, processes, and standards that guides everything from product or project design to production. It serves as the guiding star for engineering teams to ensure that they are building the right products or facilities in the right way, so that every decision aligns with industry and regulatory safety, security, sustainability, and other standards. When engineering teams design a new product or project, engineering governance ensures that the final outcomes meet these standards, as well as customer expectations and broader corporate goals. It touches every stage of the product or project lifecycle from design to delivery and beyond.

Engineering governance will also ensure that concerns about the rapid adoption of AI and AI-related cybersecurity risks and ethical decision-making are addressed. With increasingly complex products that can take an ecosystem to develop, companies face the significant challenge of seamlessly integrating hardware, software, and other inputs from suppliers and partners. This necessitates robust engineering governance, along with efficient collaboration and cutting-edge tools to ensure that all systems and subsystems coexist harmoniously.

RELATED: Buyer’s Guide: How to Select the Right Requirements Management and Traceability Solution

Why Engineering Governance Matters

For companies, failure to follow strong engineering governance risks expensive recalls, lawsuits, and fines, as well as harm to customer health and property, and significant negative brand impact. Here’s why getting it right matters so much:

1. Ensuring Regulatory Compliance and Audit Readiness

Companies operate within a tightly regulated or audited environment. Engineering governance provides a structured approach to ensure that the development process and tools comply with applicable regulations and auditor checklists in all markets where the products are sold or projects are located.

2. Managing Risks Proactively

Engineering governance helps identify and mitigate risks early before they escalate or snowball. Without comprehensive safety and quality testing, defects or other issues might surface after delivery to customers, necessitating recalls and refunds, rather than during development when fixes and rework are much less costly and damaging to reputation in the marketplace and relationships with customers, resellers, and other partners.

3. Maintaining Quality Standards

A robust engineering governance framework ensures that products or projects meet or exceed customer, industry, and regulatory requirements without cutting corners during design, manufacturing, or testing.

4. Pursuing AI and Other Innovation Responsibly

Innovation without governance can spiral into impractical or unsafe ideas. Engineering governance ensures that the adoption of innovative technologies or processes is balanced with feasibility, compliance, and cost control. Companies racing to incorporate AI into their products or the development process, for example, need engineering governance to ensure that new products and processes undergo rigorous safety tests, align with evolving regulations, and deliver innovations responsibly.

5. Achieving Sustainability Goals

Sustainability has become a business imperative for companies in response to demands from governments, consumers, and clients. Engineering governance helps them achieve sustainability goals by embedding eco-friendly practices into every stage of development and production.

RELATED: From Requirements to Regulatory: How AI Is Transforming Submission Readiness

Engineering Governance Scenarios

Here’s how engineering governance plays a role at every step in the development of any new product, project, or system:

• Design Phase: Engineering governance ensures compliance with safety and security standards applicable in each industry and region.
• Testing and Validation: Engineering governance frameworks ensure rigorous testing of every primary and secondary system and subsystem, including hardware, software, and other elements. Engineers follow defined processes to simulate real-world conditions.
• Supply Chain Oversight: Engineering governance identifies suppliers whose products and processes meet quality and sustainability standards.
• Post-market Monitoring: Even after development is complete and products or projects have been delivered, engineering governance mechanisms monitor performance through data collection to identify recurring issues and develop structured response plans to ensure quick fixes that reduce customer or client dissatisfaction.

Download the entire Whitepaper to read more, including
“Engineering Governance: An Industry-by-Industry Breakdown” and “How Jama Software Supports Engineering Governance”

The post Engineering Governance is a Critical Business Strategy for Product, Project, and System Development Excellence appeared first on Jama Software.

In this blog, we recap our recent webinar. Watch the entire presentation here: IEC 62304 Edition 2: What to Expect and Why It Matters.

IEC 62304 Edition 2: What to Expect and Why It Matters

IEC 62304, the international standard governing medical device software lifecycle processes, is undergoing its first major revision in nearly 20 years. While the upcoming second edition aims to clarify requirements and better reflect modern software practices, it also intentionally preserves the stability manufacturers rely on for compliance.

This webinar, co-presented with Medical Device HQ, provides a clear, practical view into the direction of IEC 62304 Edition 2, directly from someone involved in drafting the standard.

In this session, Christian Kaestner, member of IEC TC 62 / SC 62A and contributor to IEC 62304 Edition 2, joins Tom Rish, Head of GTM Strategy at Jama Software to explain what is changing, what is deliberately not changing, and what these updates mean in practice for medical device and Software as a Medical Device (SaMD) manufacturers.

Key Takeaways:

• Understand why IEC 62304 is being revised and the core objectives of Edition 2
• Learn how the IEC standardization process has shaped the scope and content of the revision
• Discover what the draft edition says about key topics like SaMD and artificial intelligence (AI).
• Hear why AI will not be a significant part of IEC 62304 — a deliberate design choice you need to understand.
• Find out which proposed changes are most likely to affect your organization and get practical advice on how to prepare.

Get a grounded, standards-focused perspective on IEC 62304 Edition 2 and what it means for your software lifecycle processes.

THE VIDEO BELOW IS A PREVIEW – WATCH THE ENTIRE PRESENTATION HERE

TRANSCRIPT PREVIEW

Christian Kaestner: Thank you, Tom. So to avoid seeming too nerdy, I just want to share more of my human side, because we got a bit technical before, perhaps. I have three adult children, four cats, four beehives, 15 hens, and I love gardening. So now you know everything about me. Back to my nerd side, and what could be better than starting with a disclaimer? This is not an official IC presentation. It’s my perspective on the ongoing work, and I’m one of 73 experts on the project team. Even though I haven’t asked my 70-plus colleagues, I believe today’s presentation is a fair summary of the current status. I would say we are roughly 25 experts actively involved in the work, and it’s definitely a team effort. I just want to emphasize that it’s not my own work. Before we get going, I’m curious, what type of software do you mostly work with? So please participate in the poll and let me know what field of interests you have or what you’re working with.

Let’s see. We’ve got some poll answers. We’ll let you get some time to find the right window. So I see we have a combination, so a mix of both. It’s actually one-third each. Have you all agreed on voting like that? It’s interesting because sometimes there’s a tendency to believe that everything is sampled nowadays, but there’s still quite a big bunch of software in the medical SiMD components out there. Okay. Thanks a lot for participating. Let’s continue. While I’m presenting, perhaps you get bored, but if you do, please share your thoughts in the chat. I’m generally interested in hearing about any challenges you face with the current version of the standard, or what guidance do you seek regarding AI in medical devices? And as Tom mentioned before, please also use the dedicated Q&A box if you have any questions, and I’ll do my best at the end of this webinar to answer to your questions.

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

Kaestner: Now, let’s get started. Before we discuss the upcoming changes in the second edition, I want to share the reasons behind these changes, because if you don’t understand what’s behind it, it might be difficult to understand why changes are implemented. I also want to provide insight into the behind-the-scenes process involved in developing standards. The first version of IEC 62304 was published in 2006 to meet regulatory requirements and expectations for standardized guidance on software development. In 2015, the standard was amended to include guidance on managing legacy software. The D, with the introduction of the legacy clause, was to help manufacturers bring products developed before the establishment of the standard into compliance. Additionally, there were minor changes to the software safety classification aimed at helping manufacturers manage the classification process more effectively, rather than consistently ending up in class C. Whether that really worked or not, that can of course be debated.

In addition, a major change is the scope shift from medical device software to health software. This adjustment is made to full align with IEC 820304-1, which is the product standard for standalone software, often called SaMD. There will also be simplification of the software safety classification by reducing the number of levels from three to two. And whether that will be simplification or not, we will get back to that, because it comes with some challenges as well. Lastly, considering that the current version is nearly 20 years old, I expect a new addition to include a level of, let’s say, modernization to reflect today’s state of the art. I haven’t seen any updated timeline for the project, but I’m guessing, or perhaps hoping, crossing my fingers, it will be finished by 2028, but you never know. And I’ll come back to why I don’t know, because there are some uncertainties on this path.

RELATED: Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications

Kaestner: For those unfamiliar with the standardization process, here comes a short summary. It begins with a working drop, which is often referred to as a new work item proposal, and that’s especially when it develops the creation of new standards. It’s worth noting that there was a previous attempt to develop a second edition of IEC 62304. Unfortunately, this effort stalled due to challenges in achieving consensus among key stakeholders. However, an important outcome of that previous work was a design specification that now functions as a working draft and leads the project. The specification has guided the development of the first committee draft and will continue to inform the project moving forward. So you can see it’s kind of the rail guards for the project. Although not all national committees are happy about the design specification, it has gathered a majority acceptance, and the project team is keen not to deviate too much from the specification to avoid yet another stopped project.

Here is a summary of the key guiding principles for the project team. So as mentioned earlier, the scope will change to health software. Three levels will change to two. IEC 62304 is a process standard that relies on other standards for product-relevant requirements. This will be emphasized. So, where do you get, for instance, risk management from? And this is not all. Due to the scope change, normative references to medical device standards is not an option longer. The legacy clause has to some extent been used to cheat, unfortunately, I would say. This has resulted in suggesting moving the legacy clause to an informative annex. State of the art expects some level of architectural planning for all levels nowadays. Annexes shall be developed to cover relations to other standards and modern technologies, and also development methodologies such as agile. You will find a link to the design specification in the webinar resource section.

So if you’re interested in the details, please have a look. It’s just like, I think it’s two to three pages long, so it’s not that massive of a document. With the help of the design specification, a CD or committed draft was developed and sent out for commenting at the beginning of last year.

Together with the CD, a change rationale was provided to explain the changes being made, because some changes could seem like kind of unexpected perhaps, and that’s why the change rationale was provided as well to explain these changes. I’ve selected a few key topics addressed in the document. I will also revisit several of them shortly. So the classification of the former software safety classification will be called process rigor level, and the criteria for the determination of the level will also change. There will be new requirements for AI planning, and there will be clarification on supporting items to be controlled. Simply put, you must control whatever items are needed to recreate the software. Whether that is a compiler, test tools, or source code, it’s up to you as a manufacturer to determine what you need to control. The current version has some requirements for communicating with users and regulators. This is typically a product requirement and will be shifted towards the requirement for planning what information shall be communicated to whom and when.

THIS HAS BEEN A PREVIEW – TO WATCH THE ENTIRE WEBINAR, VISIT:
IEC 62304 Edition 2: What to Expect and Why It Matters

The post [Webinar Recap] IEC 62304 Edition 2: What to Expect and Why It Matters appeared first on Jama Software.

The Simplification of the EU MDR: What MedTech Needs to Know

The European Medical Device Regulation (EU MDR) continues to present challenges for quality and regulatory teams, as well as for the medical device industry more broadly, years after its publication. The updated legislation was introduced with the objective to improve patient safety and harmonize regulatory standards across EU Member States.

Four years after the initial date of application of the regulation, the medical technology industry has gained enough experience to assess its practical impact. While the regulation has strengthened oversight and transparency, it has also introduced complexity, capacity constraints, and unintended consequences that affect product development and market access.

The European Commission has recently proposed a simplification of the EU MDR, supported by a targeted evaluation of both its successes and its limitations. In the following sections, we review the regulation’s background, summarize the key findings of the recent evaluation, and outline practical steps organizations can take to adapt to evolving regulatory expectations.

A Brief History Of The EU MDR

To understand the current regulatory climate, we must look at the system that preceded it. The Medical Device Directives governed the European market since the 1990s. While effective for a time, serious safety events exposed critical flaws in the system. High-profile incidents involving industrial-grade silicone in breast implants and complications with metal-on-metal hip replacements made it clear that the directives lacked sufficient clinical oversight.

The European Union responded by adopting the MDR in 2017, aiming to ensure that only safe, performant devices reached patients. The new framework sought to create a robust, transparent, predictable, and sustainable regulatory environment. It introduced several major changes:

• Stricter requirements for clinical evidence and post-market surveillance.
• More rigorous criteria for the designation and oversight of notified bodies.
• The establishment of the European database on medical devices (EUDAMED) to improve traceability.
• The introduction of the Unique Device Identification (UDI) system.
• The regulation officially applied in May 2021, but the scale of these changes brought significant growing pains for the industry.

Assessing The Current State Of The EU MDR

The recent European Commission Staff Working Document Evaluation of medical and diagnostic device regulations for the proposal to simplify and lessen regulatory burdens provides a comprehensive look at how the regulation operates today. The findings show a mixed reality. The framework successfully strengthened safety protocols, and vigilance activities increased significantly, giving authorities better tools to detect and manage risks. However, the implementation revealed severe bottlenecks that constrain market functioning.

Innovation And Competitiveness Challenges

The regulation places massive administrative burdens on medical device manufacturers. The assessment highlights that small and medium-sized enterprises are facing disproportionately high compliance costs. Manufacturers reported expenses of approximately €30,000–€250,000 per clinical evaluation, depending on device class and study complexity, with the highest costs incurred for Class III devices. The heavy financial and administrative toll forced many companies to divert resources away from research and development, slowing the pace of innovation. Consequently, some developers began prioritizing market launches in regions with more predictable regulatory pathways, such as the United States.

Notified Body Bottlenecks

Notified body capacity became a major hurdle early in the transition. Lengthy designation processes and extensive documentation requirements led to certification delays lasting 13 to 24 months. These delays threaten the availability of critical medical technologies. To prevent widespread market shortages, the European Commission extended the transition periods to December 2027 for legacy high-risk devices and December 2028 for legacy medium-risk devices.

Transparency And Predictability Gaps

While the regulation aimed to improve legal certainty, stakeholders still struggle with ambiguous definitions and inconsistent applications of the rules. The Medical Device Coordination Group issued over 100 guidance documents, but practical implementation challenges and differences in interpretation persist, making operational clarity harder to achieve in some areas. Furthermore, the slow rollout of EUDAMED delayed the intended transparency goals. Without the fully mandatory database in place, manufacturers continued to grapple with fragmented national registration systems.

The Threat To Orphan Devices

The assessment explicitly noted the threat to niche and orphan devices. Because these products serve small patient populations, they generate lower revenue. The high cost of gathering new clinical data under the MDR led some manufacturers to discontinue these essential devices, posing a direct risk to vulnerable patient groups.

RELATED: LEX Diagnostics Boosts Efficiency by Modernizing its Requirements Tool with Jama Connect^®

The Push For Simplifying The EU MDR

Acknowledging these significant challenges, the European Commission concluded that the regulatory framework requires targeted adjustments. The upcoming simplification revision of the EU MDR, proposed in December 2025, aims to restore European competitiveness and support innovation without sacrificing patient safety.

The simplification effort focuses on reducing unnecessary administrative complexity and creating a more proportionate system. Regulatory bodies plan to streamline reporting obligations and eliminate overlapping assessments. This includes creating tailored requirements for low-risk devices and well-established technologies, which currently face burdens disproportionate to their actual risk profiles.

For niche and orphan devices, the European Commission intends to develop flexible regulatory pathways. These specialized routes will ensure that patients with rare conditions maintain access to life-saving treatments.

Another major component of the simplification is the centralization and harmonization of notified body oversight. By standardizing practices across Member States and moving away from slow, consensus-based decision making, the European Union hopes to improve predictability and reduce certification timelines. The simplification also embraces digital transformation, permanently expanding the use of electronic instructions for use and paving the way for efficient electronic submission systems.

How To Prepare For Upcoming Regulatory Changes

Preparing for regulatory shifts requires a proactive strategy. Quality and regulatory teams should take steps now to ensure a smooth transition when the simplified rules take effect.

• Audit your existing product portfolio: Identify devices that might qualify as well-established technologies or orphan devices. These products may soon benefit from streamlined regulatory pathways, saving your team significant time and resources.
• Prepare your data for EUDAMED: Although the full system experienced delays, several modules will become mandatory by May 2026. Transitioning from fragmented national databases to a centralized European system requires clean, organized, and highly accurate data.
• Establish early dialogue with your notified body: Clear communication helps you understand specific expectations and prevents misinterpretations that cause certification delays.
• Streamline your clinical evidence pipelines: Ensure your clinical evaluation reports and post-market surveillance plans are up to date. Robust data remains the foundation of compliance, even under a simplified framework.
• Upgrade your internal documentation systems: Manual documentation methods simply cannot keep pace with dynamic regulatory landscapes. Moving away from static documents is essential for maintaining compliance.

Position Your Team For Success With Jama Connect

For teams facing high process complexity and strict regulatory demands, Jama Connect offers a scalable, automated solution. Our platform streamlines traceability, enhances collaboration, and ensures compliance across global markets.

Jama Connect automates traceability and documentation processes, reducing manual effort by up to 50%. By replacing manual spreadsheets with a centralized digital platform, your team can improve risk analysis and maintain a clear line of sight from initial design requirements to final validation. This level of organization proves critical during notified body audits and helps you bring safe, compliant devices to market faster.

Whether you are a startup launching a novel device or an enterprise managing a massive global portfolio, Jama Connect accommodates your growth. The platform integrates seamlessly with your existing tools, allowing your team to focus on strategic innovation rather than administrative overhead. By modernizing your requirements management today, you position your company to navigate the simplification of the EU MDR with total confidence.

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Tom Rish and Victoria Bruno.

The post The Simplification of the EU MDR: What MedTech Needs to Know appeared first on Jama Software.

To watch this Features in Five demonstration of our Automotive Solution, click HERE.

Jama Connect Features in Five: Automotive Solution

In this Features in Five session, Grant Rhodes, Senior Solutions Consultant at Jama Software, explores how Jama Connect’s Automotive Solution empowers teams to streamline compliance and accelerate development in the automotive industry.

Key highlights include:

• Purpose-built support for automotive systems and components, ensuring compliance with ISO 26262, ISO 21434, ASPICE, and other critical industry standards.
• Centralized platform for managing requirements, tests, risks, and traceability with end-to-end visibility.
• Tools for improving productivity, reducing defects, and ensuring seamless traceability to meet safety and security standards.

With Jama Connect, automotive teams can reduce rework, prevent recalls, and bring products to market faster while staying audit-ready.

Plus, leverage pre-configured frameworks and work with Jama Connect consultants to customize the solution to your exact business needs.

Ready to transform your automotive development process? Explore how Jama Connect can help.

TRANSCRIPT BELOW

Exploring the Jama Connect Automotive Solution

Grant Rhodes: Hello, and welcome to the Jama Connect Features in Five series. My name is Grant Rhodes, and I’m a Senior Solutions Consultant here at Jama Software.

Today, we’ll be walking through the automotive solution. Jama Software provides robust tools and solutions to help automotive developers streamline compliance with ISO 26262, ISO 21434, ASPICE, and other critical industry standards.

Centralized Management with Jama Connect

Through Jama Connect, teams can manage requirements, tests, risks, and traceability in a centralized platform, ensuring end-to-end visibility across the development cycle.

This level of traceability is crucial for demonstrating adherence to safety and security standards. It enables significant productivity and quality improvements, dramatically reduces the risk of product delays, cost overruns, defects, rework, and recalls, and ultimately results in faster time to market.

The Jama Connect automotive solution is a complete set of frameworks, example projects, and procedural documentation intended to accelerate the implementation of Jama Connect for organizations developing automotive systems and components. The foundation of our automotive solution is Jama Connect, our industry-leading, best-in-breed requirements management solution.

Purpose-Built for Automotive Development

Purpose-built to track the requirements of complex systems and reduce risk and inefficiencies of document-based legacy systems, the automotive solution allows teams to start working in Jama Connect with zero setup and configuration time. Alternatively, teams can work with a Jama Connect consultant to customize the solution to meet their company’s exact business needs.

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

Automotive Solution Frameworks

Rhodes: The automotive solution frameworks come in the form of projects in Jama Connect. These include definitions of item types and relationships as well as example project hierarchies that are aligned to key industry regulations. Here, I have the base automotive framework project open.

This image represents the traceability information model applied within this project and visualizes the allowable data types and relationship rules. Requirements are covered by lower-level requirements or design elements and are related to test case items to prove compliance. In addition to the item types and relationships, each framework also contains a project structure designed to highlight important sets of data.

These models and hierarchies have been designed using input from industry best practices and are usable out of the box. However, Jama Connect is configurable and can be customized to meet any needs specific to your organization or product development cycle.

Sample Projects for Hands-On Experience

In the project tree, we can see that in addition to the framework projects, the solution also delivers sample projects.

These utilize a framework but are populated with sample data. In these projects, teams can get hands-on experience with the defined item types and relationships. For example, opening the automotive safety and security sample set project, we can see an example of a hazard analysis and risk assessment (HARA).

RELATED: Bringing AI to the Road Safely: Insights from Gokul Krithivasan

Export Templates and Reports

Rhodes: The automotive solution also includes many export templates and reports for generating HTML, PDF, Word, and Excel outputs from the system.

Some reports are generic and included in all Jama Connect instances. Others are targeted for automotive customers, providing content and formatting specific to industry needs. For example, the HARA and TARA reports give the ability to export safety and security items from a project. Since the sample set project is populated with data, we can use it to better understand the outputs that these reports deliver.

Conclusion

Thank you for watching this Features in Five session on the automotive solution for Jama Connect. Existing customers, if you want to learn more, please reach out to your Customer Success Manager or Consultant. New customers, if you are not yet a client, please visit our website at JamaSoftware.com to learn more about the platform and how we can help you optimize your development process.

Watch the Jama Connect Features in Five: Automotive Solution HERE

To view more Jama Connect Features in Five topics, visit:
Jama Connect Features in Five Video Series

The post Jama Connect® Features in Five: Automotive Solution appeared first on Jama Software.

What is ISO 13485? A Simple Guide for Medical Device Professionals

Introduction

If you’re a medical device professional, you’ve very likely heard of ISO 13485. But reading the standard can feel like diving into a boring, theoretical document that seems designed to slow you down. You have products to develop and deadlines to meet. You need a straightforward explanation of what it is, why it matters, and how to comply without getting bogged down.

This guide is for you. We’ll break down ISO 13485 in simple terms, explain its growing importance with the FDA’s new Quality Management System Regulation (QMSR), and provide practical steps to help you comply efficiently.

TL;DR: ISO 13485 is the internationally recognized standard for a medical device Quality Management System (QMS). It provides a framework to ensure you consistently design, produce, and deliver safe and effective medical devices. This guide explains its core principles and offers practical steps for compliance.

The Challenge: Why ISO 13485 Matters Now More Than Ever

For years, many in the U.S. viewed ISO 13485 as a standard primarily for medical devices sold in Europe or Canada. The FDA had its own set of rules, the Quality System Regulation (QSR). However, that’s changing. The FDA is finalizing its Quality Management System Regulation (QMSR), a major project to harmonize the U.S. regulations with ISO 13485.

This means the principles and structure of ISO 13485 are becoming the foundation for compliance in the United States, too. For busy engineering, quality, and regulatory teams, this shift creates a new sense of urgency.

The key takeaway: Relying on old processes is no longer enough. Understanding and aligning with ISO 13485 is now critical for market access, regulatory approval, and maintaining a competitive edge.

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

What is ISO 13485 in Simple Terms?

Think of ISO 13485 as a framework for quality. It doesn’t tell you what specific medical device to create, but it provides the structure of a Quality Management System (QMS). That QMS is a set of business practices that help to consistently deliver safe and effective devices, while also meeting customer and regulatory requirements.

It’s a framework that covers the entire lifecycle of a medical device, from initial concept to post-market surveillance. At its core, the standard is built on a few key principles:

• Management Responsibility: Leadership must be actively involved in establishing and maintaining the QMS. Quality can’t be delegated to a single department; it has to be part of the company culture.
• Resource Management: You must have the right infrastructure, work environment, and competent personnel to produce a quality device.
• Product Realization: This is the largest part of the standard. It covers all the steps involved in actually designing and manufacturing the device, including design controls, purchasing, and production.
• Measurement, Analysis, and Improvement: You must have processes for monitoring your product and processes, handling non-conforming products, analyzing data, and taking corrective and preventive actions (CAPA) to continuously improve.

How to Comply with ISO 13485: 4 Practical Steps

Complying with ISO 13485 doesn’t have to be a burden. By adopting a structured approach, you can build a robust QMS that streamlines development instead of slowing it down.

Step 1: Establish Your Quality Management System (QMS)

The foundation of compliance is a well-defined QMS. This isn’t just a set of documents in a folder; it’s the collection of processes, policies, and procedures that govern how your company operates to ensure quality.

• Benefit: A centralized QMS eliminates confusion and ensures every team, from engineering to manufacturing, follows the same standardized, approved procedures.
• How a Modern Solution Helps: Platforms like Jama Connect^® provide out-of-the-box frameworks and workflows for product realization that are specifically designed for medical device compliance. This allows you to build an audit-ready QMS from day one, guiding teams through the correct processes.

Step 2: Integrate Risk Management Throughout the Lifecycle

ISO 13485 requires that risk management be an integral part of your entire product lifecycle, not an afterthought. You must proactively identify, evaluate, and control risks at every stage.

• Benefit: Integrating risk management from the start helps you build safer products and prevents costly late-stage design changes.
• How a Modern Solution Helps: Jama Connect integrates risk management directly into the development process. You can link potential risks to requirements, design elements, and test cases, creating a clear line of sight and ensuring all hazards are properly mitigated.

Step 3: Implement Robust Design Controls and Traceability

Auditors will want to see proof that your device was designed according to a controlled process. This means demonstrating a clear, unbroken link from your initial user needs and requirements through design, verification, and validation. Manually creating and maintaining these traceability matrices is notoriously difficult and error-prone.

• Benefit: Complete traceability gives you total visibility into your project’s health and allows you to prove compliance to an auditor with just a few clicks.
• How a Modern Solution Helps: Features like Live Traceability™ in Jama Connect automate this process. It creates a dynamic, real-time map of your entire project, instantly showing the impact of any change and ensuring 100% test coverage.

Step 4: Focus on Documentation and Record-Keeping

In the world of medical devices, the rule is simple: if it isn’t documented, it didn’t happen. ISO 13485 places a heavy emphasis on maintaining comprehensive records for everything from design reviews to supplier evaluations.

• Benefit: Meticulous documentation creates an audit-ready trail that proves you followed your processes and met all regulatory requirements.
• How a Modern Solution Helps: Using a centralized platform ensures all documentation is stored in one place, version-controlled, and linked to the relevant parts of the project. This makes it easy to manage your records and export submission-ready documentation.

RELATED: The Complete Guide to ISO 13485 for Medical Devices

FAQs: ISO 13485 and Your QMS

Q: What is the difference between ISO 13485 and the FDA QSR?
A: Historically, the FDA’s Quality System Regulation (QSR) was the mandatory regulation for devices sold in the U.S., while ISO 13485 was the international standard. With the upcoming Quality Management System Regulation (QMSR), the FDA is harmonizing its regulation with ISO 13485. This means the requirements will be nearly identical, making ISO 13485 the de facto model for the U.S. market.

Q: Do we need to be certified in ISO 13485 to sell in the US?
A: The FDA does not require formal certification to ISO 13485. However, you must comply with the new QMSR, which is fundamentally based on ISO 13485. Achieving ISO 13485 certification is often required for other major markets (like Europe and Canada) and is widely considered a best practice that demonstrates a commitment to quality.

Q: How can a tool like Jama Connect help if we already have a QMS in place?
A: Many companies manage their QMS with a mix of documents, spreadsheets, and siloed tools. This approach is inefficient and risky. Jama Connect replaces all processes related to design, risk, and testing with a single, integrated platform. It helps enforce your existing QMS processes, automates critical tasks like traceability, and centralizes documentation, making audits significantly faster and less stressful.

Turn ISO 13485 Compliance into a Competitive Advantage

Stop letting disjointed systems and manual processes hold you back. By embracing a modern, integrated approach to your Quality Management System, you can transform ISO 13485 from a regulatory hurdle into a strategic advantage. Empower your teams to pass audits with confidence, reduce rework, and deliver innovative medical devices to market faster and more safely.

Ready to see how you can build an audit-ready QMS aligned with ISO 13485? Request a personalized demo of Jama Connect today.

The post What is ISO 13485? A Simple Guide for Medical Device Professionals appeared first on Jama Software.

This blog overviews a section of our recent Whitepaper. To download it in its entirety, visit “Jama Connect Supports Restricted and ITAR Use Cases”

Jama Connect^® Supports Export-Restricted and ITAR Use Cases

Organizations operating under export restriction and/or International Traffic in Arms Regulations (ITAR) face unique challenges when selecting collaboration tools for product development. These regulations, designed to control the export of defense-related articles and services, require stringent data handling and access controls that many standard software platforms cannot accommodate.

Jama Connect provides a robust foundation for export-restricted and ITAR regulated environments through its comprehensive security architecture and flexible deployment options. However, successful ITAR-compliant support requires a shared responsibility model between Jama Software and our customers, with each party maintaining specific obligations to maintain regulatory adherence.

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

Shared Responsibility Framework

Customer Responsibilities

Organizations using Jama Connect for ITAR-regulated projects must implement specific deployment and operational practices to maintain compliance.

Deployment Architecture

• Self-Hosting Requirements: Customers must deploy Jama Connect on their own ITAR-compliant infrastructure or utilize specialized partners like Vantage ALM for GovCloud deployments. This ensures the customer’s complete control over data location and access pathways.
• Infrastructure Security: Organizations are responsible for ensuring the security of the underlying infrastructure, including network controls, server hardening, and physical security measures.

Data Handling Protocols

• Information Segregation: Customers must ensure that ITAR data remains isolated within their controlled environment and is never transmitted to Jama Software through support channels or email communications.
• User Access Controls: Organizations must implement and maintain proper user authentication, authorization, and regular access reviews to ensure only qualified personnel can access ITAR-controlled information.

Jama Software Responsibilities

When supporting customers in export-restricted or ITAR-controlled environments, Jama Software maintains specific operational protocols to respect regulatory requirements while providing necessary technical assistance.

Meeting and Communication Protocols

• U.S. Person Verification: For any customer-requested meetings or working sessions involving discussion of ITAR restricted information, Jama Software will confirm that all attending personnel are ITAR Accessible Persons currently located within the United States upon the request of the customer. The customer must give Jama Software prior notice so that we can arrange the proper personnel to attend such calls.
• Documentation Restrictions: No recordings, screenshots, or other documentation will be created during these designated ITAR support sessions to prevent inadvertent data capture or storage.

Figure 1. Shared Responsibility Model

DOWNLOAD THE ENTIRE WHITEPAPER TO LEARN MORE,
INCLUDING IMPLEMENTATION BEST PRACTICES:
Jama Connect® Supports Export-Restricted and ITAR Use Cases

The post Jama Connect® Supports Export-Restricted and ITAR Use Cases appeared first on Jama Software.

This blog recaps our recent webinar, to watch the entire presentation, visit “How to Write Unambiguous Design and Development Inputs and Meet ISO 13485 Requirements”

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.

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

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.

TO WATCH THE ENTIRE WEBINAR, VISIT:
How to Write Unambiguous Design and Development Inputs and Meet ISO 13485 Requirements

The post [Webinar Recap] How to Write Unambiguous Design and Development Inputs and Meet ISO 13485 Requirements appeared first on Jama Software.

This blog recaps a section of our recent webinar, to watch the entire presentation, visit Techniques to Manage Work Breakdown Structures.

Streamline Your Program Management: Techniques to Manage Work Breakdown Structures (WBS)

In aerospace and defense program management, success hinges on coordinating complex, interconnected projects while maintaining clear visibility across your entire program. When managing multiple systems and stakeholders, your work breakdown structure becomes the foundation that either strengthens or undermines your project’s success.

In this webinar, Cary Bryczek, Director of Aerospace & Defense Solutions at Jama Software, demonstrates how to incorporate MIL-STD-881F work breakdown structures into Jama Connect^® as part of your systems engineering processes.

Whether you’re managing space systems, information systems, or strategic missile programs, this webinar will show you how to streamline your program management with techniques to manage your WBS.

Key Takeaways:

• MIL-STD-881F fundamentals: Understanding the Department of Defense Standard Practice and how it improves acquisition communication
• Real-world implementation: See how MIL-STD-881F work breakdown structures can be incorporated into Jama Connect, including a live demonstration.
• Cross-functional alignment: Strategies to coordinate teams and manage interdependencies across complex defense programs
• Commodity-specific insights: How WBS elements apply to space systems, information systems, launch systems, and strategic missile systems
• Communication enhancement: Best practices for developing uniform WBS processes that improve stakeholder alignment and regulatory compliance.

Webinar Preview, Click HERE to Watch The Entire Presentation

TRANSCRIPT PREVIEW

Cary Bryczek: So, here’s a quick look at what we will cover today, and in the end we’ll have a Q&A of course. So, we’ll talk about some strategies for a work breakdown structure construction, obviously we’ll talk about what WBS is used for, we’ll look at a WBS hierarchy, and the product breakdown structure, talk about the differences, we’ll see a live example in Jama Connect, and we’ll finish up with maybe some possible extensions that you might use in Jama Connect through integration. So, what is a work breakdown structure? I went out there and did some research. Project management institute talks about a work breakdown structure being, that it defines a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the objectives.

Really, when you see these kinds of definitions, the important parts are the deliverable-oriented and the work. So, it’s not like a task list, it’s what you’re doing to produce the product or the system that you’re building. The Defense Acquisition University defines a WBS as a product-oriented family tree of hardware, software, services, data, and facilities. So, the theme really is this product-oriented and a tree composition of the work breakdown structures. And it’s not only composed of the product pieces itself, but the services and the data and the facilities and the results of the systems engineering efforts. So, it’s the effort plus the product itself. Who uses work breakdown structures? Really, they’re required or strongly recommended in various industries and government sectors, especially where project management, cost control, and systems engineering are critical.

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

Bryczek: With aerospace and defense contractors, they are required to submit a WBS as part of their proposals and their contracts. They are used for cost estimation, scheduling, and risk management. Construction and engineering firms, WBS is essential for managing large infrastructure projects. It’s often required by clients or even regulatory bodies. IT software development, project management professionals, so there’s a lot of people that are project management professionals that are using a WBS as part of their repertoire to deliver good projects, or even consult with organizations to deliver good project management practices.

WBS has lots of standards and guidelines to assist practitioners. So, in many cases, following the specific guidance within the documents is mandatory. Here I’ve just highlighted some notable guidelines, MIL-STD-881 is required for all ACAT programs, NASA also has a very prescriptive method to implement WBS, PMI has published books, and has lots of references available online for practitioners. The European, I didn’t capture this one, but the European Cooperation for Space Standardization, the ECSS group, in Europe, they provide detailed guidance as well on work breakdown structures through their management standards. And they reference principles from ISO 9000, and it really aligns their standards and their product assurance through a harmonized way to do work breakdown structures.

So, what’s the purpose of a WBS? It’s an assistant mechanism for any stakeholder really, in the development of a clear vision of the end products, or the outcomes to be produced by the product. So, it’s a framework for all of the deliverables throughout the life cycle. So, the WBS extends the product breakdown structure because it’s capturing all of the work that’s necessary for the project by adding in the non-product work. So, if you’re constructing a bicycle, well, I have to draft the CAD model, I have to review it, I have to do a lot of these things that are not necessarily part of the bicycle, a component, but these are part of the engineering activities. So, a work breakdown structure is not a to-do list, it’s not a schedule or an estimate, and it’s not really a tool to even make your life harder.

RELATED: Cybersecurity in the Air: Addressing Modern Threats with DO-326A

Bryczek: So, it supports very large projects so that you can eliminate risk, and also it will help you with the scope creep as well. So, you don’t want to do more work than what’s on that WBS, so it really helps people understand the scope of the kinds of activities that they’re producing because it is deliverable based. So, the benefits, it helps prevent work from slipping through the cracks, it helps people understand where the pieces fit into the overall project management plan. So, if you’re a software developer and you’re writing this one piece of the software requirement spec, or the software system spec, now you know why your deliverable is due, when, and how it fits in with the overall structure. It facilitates that communication and cooperation across the whole team, it also helps you prevent changes, that WBS is kind of like, this is the guide path for everything that you do. And it helps get team buy-in and helps build the team. it helps people get their mind around the project itself.

So, what do we have to do to create the statement of the work breakdown structure? So, a work breakdown structure is, first, you go through this process of identifying the system or the project end item to be structured. So, you’re trying to understand that scope, what is it that we’re building? And then, you take that product and you successively subdivide it into increasingly detailed and manageable subsidiary work products or elements. So, you’re taking this product, this bicycle, and you’re decomposing it. I have a frame, I have the front wheel, I have the rear wheel, I have the brakes… And then, what you’re going to do is take that product breakdown structure that’s been subdivided, and now use that to determine what the work breakdown structure is. So, you’re going to focus on these outcomes and identify these deliverables. So, the focus is supposed to be on the outcomes, not the activities needed to reach them.

TO WATCH THE ENTIRE WEBINAR, VISIT:
Techniques to Manage Work Breakdown Structures

The post [Webinar Recap] Streamline Your Program Management: Techniques to Manage Work Breakdown Structures (WBS) appeared first on Jama Software.

In this blog, we recap a preview of our recent webinar. Click HERE to watch it in its entirety.

Making Sense of ASQMS: A New Standard for Automotive Software Quality

The Next Automotive Software Standard Is Here. Are You Ready for ASQMS?

The shift toward software-defined, new energy, and intelligent vehicles is transforming the automotive industry. As vehicles become more reliant on complex software to power advanced features, autonomy, and connectivity, the need for robust quality management has never been greater. To meet this challenge, China’s CACPQSP introduced the Automotive Software Quality Management System (ASQMS).

In this blog, we recap a preview of our recent webinar in which hosts Sathihya Ramamoorthy (Jama Software) and Ronald Melster (Melster Consulting GmbH) discuss how ASQMS fits into the standards landscape and why it matters for your teams.

What You’ll Learn:

• An overview of ASQMS, who published it, and why it matters
• Key differences between ASQMS, ASPICE, and IATF, including new lifecycle requirements
• Why ASQMS complements, rather than replaces, ASPICE
• Practical tips for risk-based software classification and lifecycle coverage
• Actionable next steps to strengthen software quality and efficiency

The Above Video Is A Preview – Click HERE To Watch The Entire Webinar

VIDEO TRANSCRIPT PREVIEW

Ronald Melster: Thank you very much for the warm introduction and thank you very much also for inviting me to today’s webinar. I am excited to be here with all of you and to share with you the information about this new standard ASQMS. So let’s get started and explore what the standard means for the automotive world and how we can best adapt to it. For those of you who don’t know me yet, my name is Ronald Melster. In the automotive world, I’m simply known as Ron. As one of Europe’s most experienced Automotive SPICE principal assessors, I have spent nearly three decades helping organizations transform their development processes. Since 2005, I’ve been guiding teams not just to achieve higher capability levels, but to truly understand the why behind effective processes. My journey began in the 1990s when I studied computer science in Berlin and Edinburgh, but I quickly discovered my passion for software engineering and processes. What started as a love for coding evolved into a mission to help teams balance structure with pragmatism.

Over the years, I have had the privilege of working with industry leaders like Bosch, Audi, Porsche, and Here Technologies. One of my biggest achievements was leading a Bosch development division with 7,000 engineers worldwide to capability level 3, proving that even larger teams can embrace systematic improvements. But here’s what I’ve learned. Assessments are not just about ratings. They’re about empowering people, building confidence, and creating sustainable change. Whether it’s functional safety according to ISO 26262, cybersecurity, or process improvement initiatives, I’m here as your mentor, coach, and sparring partner. Maybe you have heard the rumors about this new China standard and you want to learn more about it. You have come to the right place. Let’s start with the name of ASQMS, Automotive Software Quality Management System. That’s the full name of the standard, and yes, it’s a Chinese standard.

We will take that apart piece by piece in this webinar. So the first question is which body exactly published this ASQMS standard? And the answer is the Chinese Association of Consumer Products Quality and Safety Promotion, short CACPQSP. Say this three times. This body is dedicated to consumer rights and their safety and regulates consumer products, including cars. To promote this, they created the ASQMS standard and demand that each OEM selling cars in China needs to be certified according to the standard. So naturally, it applies to Chinese OEMs selling in China, and it also applies to European OEMs wanting to sell cars in China as well. And there’s more. The OEMs are required to request the certificate from their suppliers as well, so it also applies to any supplier tier two or tier one if they want to be part of the supply chain for cars sold in China.

Let’s have a look at why they created the standard and why we need another standard if we have Automotive SPICE or ASPICE. The reason for that is the dependency on software in the car. The complexity is growing rapidly. The number of technical and organizational interfaces gets bigger every day, and the cars increasingly rely on data coming from the outside. Let me share an observation with companies trying to reach capability level 2, according to Automotive SPICE. At the beginning of the project, the capability level is at a stable level 0. Then it takes one, or two, or even three years to get to level 1 and then to level 2. Then the project delivers the result and is finished. And the next project start again at level 0. I call this cycle the chainsaw or zigzag, up and down and up and down. It’s a huge waste of time and effort, and might have led to the ASPICE frustration, which we observed in networks like LinkedIn.

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

Melster: Why is that? Because the knowledge is not captured after the project in the company, nor is it standardized or rolled out. Only few companies have managed to establish a stable level 3 with a standard process according to ASPICE. Why can a project not start in a systematic way, aka level 2 or level 3, from the start of the project? This will also reduce the technical debt, which is built up every time a project starts from level 0. There are some of the reasons why this new standard was developed. We need a strong focus on software development. We need to include the software outside the vehicle, and we need to focus on the organization to provide standard process which is applied in each and every project in a similar way. And I might add that we need to take care of the software long after the initial development phase. In a world with rising cybersecurity issues, the software must be maintained and updated if new threats become known. Therefore, ASQMS includes the entire life cycle, including the termination of the software with a systematic deletion of all personal data.

Let’s talk about what’s inside the standard ASQMS and how it’s structured. The standard contains three kinds of requirements, which must be implemented by a company which wants to be certified according to ASQMS. The first one are basic practices, not base practices, but basic practices. They’re mandatory for all automotive development. The second kind of practices are advanced practices. They must be implemented by products which are safety or cybersecurity relevant. And the third type of requirements are recommended practices. They should be implemented by all software projects. The ASQMS standard follows a risk-based approach, which means that not all requirements, which are defined by the standard need to be implemented in each development program. For that, a classification is introduced, the two classes or types of software.

Type II is a software that carries a risk related to safety or cybersecurity, and type I is the rest of the software, which is not related to safety or cybersecurity. For type II software, the cybersecurity or safety-related, the basic practices are mandatory, and the advanced practices are mandatory. The recommended practices are recommended. For type I software, which are not as critical, only the basic practices are mandatory, and advanced and recommended practices are optional. ASQMS clusters the processes into three groups: operational processes, supporting processes, and system management processes. The operational processes include project management and the entire V-model with requirements engineering, architectural design, detailed design and implementation, unit verification, integration, and verification testing.

Apart from these well-known engineering processes, the following processes are defined as part of the operational processes: supplier management, software release, software deployment, software maintenance, user information management, and software termination. So there’s some overlap and some new processes. The supporting processes include some which we already know from Automotive SPICE like configuration management, problem resolution management, change request management, and of course, quality assurance. They even have the same process names. The basic practices may differ in some aspects. And some new supporting processes are introduced like documentation management, equipment and facilities, knowledge management, revenue management, and externally supplied products and services, which includes the management of free and open-source software.

RELATED: Jama Connect^® for Automotive

Melster: With the system management processes, something completely new is introduced. They’re not to be confused with the system development processes, which we know from ASPICE. System here refers to the quality management system in the name of ASQMS. So it’s similar to ISO 9001, or ITF 16949, or an information security management system, which gets certified by TSACS. These processes include the scope and the context of the organization, the quality management system fundamentals like quality policies and roles, personnel management, performance evaluation, and the continuous improvement process. In this next section, I will highlight some of the key changes when we compare Automotive SPICE with ASQMS. The first one is the software, which is in the scope of the standard ASQMS. The requirements are not only mandatory for in-vehicle software, which many of us have known for a long time, but also for software outside the vehicle is in scope.

This includes any software in the cloud providing data to the vehicle or to an entire fleet. It furthermore includes any system along the roads, so-called roadside systems. Again, exchanging information with the car or even controlling the behavior of the vehicle. And it applies to the software tool chains which are used for software development and maintenance. The next important change is the lifecycle. Automotive SPICE development projects typically stop with the release of the finished software, whatever this means. The maintenance phase is usually left out or ignored, and really no one thinks about the termination of the software in an ASPICE project. This will change with ASQMS. The entire lifecycle of the software must be covered. This only starts with the initial development phase and must be continued with the ongoing maintenance of the software until the termination of the software. You might want to know, what is the termination more than switching off the software? Well, many software instances store data, oftentimes personal data, and this information must be securely deleted as part of the termination.

Many companies claim that they are ASPICE level 2 certified. However, this is not true. There is no such certification. What they have reached in most cases is a level 2 in one project at a certain time. So this does not apply to any other project in the same company without performing additional assessments, nor is the claim true in the future or after the assessment for the same project. So here’s the last key change I will talk about. ASPICE assessments are statements about projects at a certain point in time. This statement cannot be carried over to any other project in the company, nor is it valid in the future. ASQMS, on the other hand, focuses on the organization. This means that the organization must establish processes to fulfill the requirements and maintain them in each and every development project. This also includes internal auditing activities to make sure that all projects follow the defined rules and methods. And as I’ve mentioned earlier, it also includes processes to provide competence staff to the project. Only then will the company get the ASQMS certificate, which is published by an external auditor.

So what have we learned today about how ASPICE and ASQMS can work together? First, ASPICE integration. ASQMS will not replace Automotive SPICE. Instead, ASPICE can be used to show the conformance with the overall standard processes. And if you are already using ASPICE at the project level, these methods can be scaled to the entire organization using the approach of ASQMS. Second, both standards have shared goals. They’re built on the same fundamental principles, traceability, clear structure, and well-defined roles. Whether you’re working on a senior development project or managing quality across multiple teams, these core elements remain the same. And finally, ASQMS is extending the scope. Here’s where ASQMS goes beyond traditional ASPICE scopes. It adds organizational elements like leadership development, culture building, and personnel focus. The reality, ASPICE and ASQMS work as a partner, not competitors. Automotive SPICE gives you project-level excellence while ASQMS builds the organizational capability to sustain that excellence across all your software activities. Together, they create a comprehensive quality approach that works at every level.

This Has Been A Preview of Our Webinar, To Watch the Full Webinar, Visit:
Making Sense of ASQMS: A New Standard for Automotive Software Quality

The post [Webinar Recap] Making Sense of ASQMS: A New Standard for Automotive Software Quality appeared first on Jama Software.

AI in MedTech: Transforming Device Innovation and Quality

No matter where you turn these days, it is nearly impossible to escape the influence of AI. The MedTech industry is no different and stands at the brink of an AI revolution. From smarter devices to streamlined quality systems and even regulatory reviews, AI is poised to become a powerful tool across the product lifecycle.

Despite the potential, MedTech companies are lagging a little behind other industries when it comes to the use of AI. Recent industry surveys reveal that while 51% of high-tech companies have successfully integrated AI into their operations, only 24% of medical device organizations have achieved similar adoption rates. This gap represents an unprecedented opportunity for forward-thinking MedTech companies to gain competitive advantage through responsible, intelligent use of AI.

The FDA’s recent appointment of Jeremy Walsh as Chief AI Officer signals a clear regulatory shift toward embracing AI technologies that can accelerate device development while maintaining rigorous safety standards. Organizations that strategically implement AI across their device development, quality management systems, and regulatory processes will be positioned to deliver safer products faster while reducing operational costs.

AI-Enabled Medical Devices: The Next Generation

AI is increasingly embedded directly into medical devices, enabling real-time diagnostics, predictive analytics, and enhanced imaging. In fact, the FDA authorized 235 AI-enabled devices in 2024 alone, the most in its history.

Despite the success of an increasing number of devices being launched, much still needs to be done to ensure the devices are safe and meet their intended purposes.

The Validation Imperative

Recent research published in JAMA Health Forum analyzed 950 AI-enabled medical devices and found a concerning trend; devices without proper clinical validation were significantly more likely to be recalled. The study revealed that 43% of all recalls occurred within one year of FDA authorization, with diagnostic errors and functionality delays being the most common causes.

This data highlights a critical responsibility for manufacturers; robust clinical validation must be built into your AI device development process from day one. Companies that prioritize validation studies demonstrate measurably better post-market performance and reduced recall risk.

Practical Implementation Strategies for AI-enabled Devices

• Start with Data Quality: AI algorithms require clean, structured datasets to function effectively. Implement data governance protocols that ensure your training data meets the highest quality standards.
• Design for Continuous Learning: Modern AI-enabled devices benefit from continuous monitoring and improvement. Build infrastructure that supports ongoing data collection and algorithm refinement while maintaining regulatory compliance.
• Plan for Regulatory Pathways: The FDA’s 510(k) process for AI devices is evolving rapidly. Stay informed about emerging guidance documents and consider engaging with FDA early in your development process through pre-submission meetings.
• Implement Robust Testing: Beyond clinical validation, establish comprehensive testing protocols that evaluate your AI systems under real-world conditions, including edge cases and unexpected inputs.

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

AI in Quality Management Systems: Efficiency Through Intelligence

AI is not just for use within a device; it can transform operations too. From document generation to requirements management to supplier evaluation, AI can dramatically reduce manual effort and improve accuracy. Yet, only 10% of Medtech companies report measurable value from AI so far, compared to 24% across other industries. Quality management represents one of the most promising applications for AI in MedTech, where document-intensive processes create natural opportunities for automation and optimization.

Document Intelligence and Process Automation

AI-powered quality management systems can transform time-consuming manual processes into streamlined, automated workflows. Leading organizations report 60-70% reductions in initial document drafting time and weeks of improvement in overall review cycles when implementing AI solutions for regulatory document generation.

The key to success lies in establishing proper document management infrastructure before deploying AI tools. When quality teams maintain organized, structured document systems, AI can effectively analyze historical deviation reports to identify emerging patterns, generate compliance documentation that aligns with current specifications, and automate routine quality review processes.

Strategic Implementation Approach

• Assess Your Document Infrastructure: Evaluate whether your team can rapidly locate current versions of critical documents and whether workflows are standardized across departments. These capabilities directly determine AI implementation success.
• Start with High-Volume, Low-Risk Processes: Begin AI implementation with routine documentation tasks like generating standard operating procedures or compiling reports. This approach allows teams to build confidence while minimizing regulatory risk.
• Maintain Human Oversight: Position AI as a capability enhancement rather than human replacement. Quality professionals should conduct comprehensive reviews and maintain final approval authority for all AI-generated content.
• Establish Clear Governance: Create company-wide guidelines that specify which quality processes can utilize AI assistance, and which require traditional human-driven approaches. This clarity ensures regulatory compliance while capturing efficiency gains.

Regulatory Bodies Embrace AI: The FDA’s Digital Transformation

The regulatory landscape is rapidly evolving to accommodate AI technologies. In a major shift, the FDA announced it will use AI to assist with scientific reviews across all centers by mid-2025. Following a successful pilot, the agency is deploying generative AI tools to reduce review times and eliminate repetitive tasks.

What This Means for MedTech Companies

The FDA’s AI implementation aims to reduce non-productive busywork and accelerate review times for new therapies and devices. This regulatory modernization creates opportunities for companies that align their submission strategies with the FDA’s digital capabilities.

• Prepare for AI-Assisted Reviews: Structure your regulatory submissions to work effectively with AI-powered analysis tools. This includes using standardized formats, clear section headings, and consistent terminology throughout your documentation.
• Leverage Data-Driven Insights: The FDA’s AI systems will likely identify patterns across submissions that can inform your development strategy. Companies that maintain robust data collection and analysis capabilities will be better positioned to benefit from these insights.
• Stay Informed on Evolving Guidance: The FDA has indicated that more details on their AI initiative will continue to be released. Monitor these developments closely and consider how they might impact your regulatory strategy.

Building Regulatory-Ready AI Systems

When developing AI-enabled devices, design your systems to generate the comprehensive documentation that regulatory bodies require. This includes maintaining detailed training data records, algorithm performance metrics, and clinical validation evidence that demonstrates real-world effectiveness.

How Jama Connect^® Can Accelerate Your AI Journey

Requirements management plays a critical role in successful AI implementation for MedTech companies. Jama Connect provides the structured foundation necessary for AI-enabled development processes.

Jama Connect Advisor™ leverages natural language processing to help teams author requirements quickly and accurately, ensuring that AI system specifications meet the highest quality standards from the outset. This AI-powered feature analyzes requirements against industry best practices such as INCOSE and EARS, providing immediate feedback that improves requirement quality and reduces development risks.

The platform’s comprehensive Live Traceability™ capabilities ensure that AI system requirements remain connected to design decisions, test results, and regulatory submissions throughout the development lifecycle. This end-to-end visibility is essential for demonstrating compliance and supporting regulatory submissions for AI-enabled devices.

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

Your Next Steps Forward

The intersection of AI and MedTech presents unprecedented opportunities for organizations willing to invest in the proper foundation and strategic approach. Companies that begin building their AI capabilities now will be positioned to lead the industry as regulatory frameworks mature and competitive pressures intensify.

The key to success lies not just in adopting AI technology, but in implementing it thoughtfully within robust quality management and regulatory compliance frameworks. Organizations that prioritize data quality, maintain human oversight, and align their AI strategies with evolving regulatory expectations will realize the greatest benefits from this transformational technology.

Ready to explore how AI can enhance your MedTech development processes? Book a demo with Jama Software to discover how our AI-powered requirements management solutions can help you build safer, more effective medical devices while streamlining your path to market.

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Tom Rish.

The post AI in MedTech: Transforming Device Innovation and Quality appeared first on Jama Software.