This is part two of a two-part series on software validation and computer software assurance in the medical device industry.

Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part 2

In our previous blog post, we reviewed the top things to know about software validation and computer software assurance in the medical device industry. In this installment, we’ll take a closer look at computer software validation and provide tips and tools to manage your software in a compliant and efficient manner.

Main points

The FDA Draft Guidance on Computer Software Assurance

In September, 2022, the FDA released its draft guidance “Computer Software Assurance for Production and Quality System Software.” While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance on Software Validation, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). In this guidance the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”

There are many types of software used and developed by medical device companies, including those listed below. The scope of the 2022 draft guidance is on software used in production and quality systems software, as highlighted below.

• Software in a Medical Device (SiMD) – Software used as a component, part, or accessory of a medical device;
• Software as a Medical Device (SaMD) – Software that is itself a medical device (e.g., blood establishment software);
• Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment);
• Software in computers and automated data processing systems used as part of medical device production (e.g., software intended for automating production processes, inspection, testing, or the collection and processing of production data);
• Software used in implementation of the device manufacturer’s quality system (e.g., software that records and maintains the device history record);
• Software in the form of websites for electronic Instructions for Use (eIFUs) and other information (labeling) for the user.

RELATED: Understanding Integrated Risk Management for Medical Devices

Understanding Your Software’s Intended Use and Risk-Based Approach

Defining the software’s intended use is an important aspect of managing your organization’s computer software assurance activities.

This then allows you to analyze and document the impact to safety risk if the software failed to perform to meet its intended use. One aspect that I appreciate the FDA adopting is the concept of ‘high process risk,’ when the failure of the software to perform as intended may result in a quality problem that foreseeably compromises safety and an increased medical device risk. The guidance has a number of examples to illustrate examples of high process risk and not high process risk. Previously, risk that purely a high risk to compliance only (i.e., no process risk) was essentially treated the same as risk that could compromise safety.

Commensurate with the level of process risk, guidance, and examples are presented to outline expected computer assurance activities, including various levels of testing, and level of documentation. Computer assurance activities for software that poses a high level of process risk include documentation of the intended use, risk determination, detailed test protocol, detailed report of the testing performed, pass/fail results for each test case, any issues found and their disposition, among others.

In contrast, guidance is provided that computer software assurance activities that pose no level of process risk can consist of lower level of testing, such as unscripted ad-hoc or error guessing testing. Prior to this guidance, the expectation was fully scripted protocols and documented results for each test case, which felt burdensome. For example, having to script out protocol steps to include user log-in steps for an electronic QMS module that facilitated the nonconformance process, which did not have a high level of process risk. The usage of the concept of high process risk and acknowledging that unscripted testing can be appropriate in times of low risk, will certainly help lessen the burden of compliance, without compromising safety.

Managing Your Software Efficiently

For those that think analytically like me, once can easily see the value of a Trace Matrix to keep my organization’s software organized and ensure the intended use, risk assessment, planned computer software assurance activities, and outcomes documented.

Similar to how it efficiently traces your medical device design inputs to outputs and links to your risk management, Jama Connect^® is a great tool to also trace and manage all your software and software validation and computer software assurance activities. This includes documentation of the intended use, risk determination, and test protocols and reports performed. With its new validated cloud offering, SOC2 certification, and available Jama Connect Validation Kit, Jama Software also provides the tools and evidence you need to meet your organization’s computer software assurance activities.

RELATED: Jama Connect^® for Medical Device Development Datasheet

Closing

Developing a risk-based process for software management, including software validation and computer software assurance, is key to staying compliant. Staying organized and using a tool like Jama Connect helps you do so efficiently.

To read part one of this blog, click HERE.

Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part I

Intro

This is Part 1 of a 2-part series on software validation and computer software assurance in the medical device industry.

While it is clear that software validation is required by regulation in the US and elsewhere (e.g., the EU (European Union)), as regulated by the MDR and IVDR), how to execute continues to cause challenges, both for established medical device companies, and those just entering the medical device industry.

Between the different types of software, variations in terminology, type, and source of software (developed in-house, or purchased OTS, customized OTS (COTS), SOUP, etc.) advances in software technology, and evolving guidance of the FDA (Food and Drug Administration) and other regulatory bodies, it’s no wonder that implementation of software validation practices and procedures causes confusion.

This blog outlines the top things to know about software validation and computer software assurance as you implement practices and procedures for your organization in a way that is compliant and brings value.

Are you building or updating your software validation practices and procedures? If so, read on!

Top Things to Know About Software Validation and Computer Software Assurance

#1. Yes, there are different terms, methods, and definitions for software validation.

For the purposes of this blog, we’ll use the FDA’s definition of software validation, from their 2002 guidance. The FDA considers software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”

At a high level, this makes sense. The confusion starts when folks try to define how that confirmation is performed and documented. How do I determine and document the requirements? How detailed do I need to go to my user needs and intended uses? For each feature? What kind of objective evidence? What if I’m using software to automate test scripts? Do I have to qualify the testing software? Turning to guidance and standards for a “standard” set of practices can add to the confusion. Even within just the medical device industry, there are multiple regulations and standards that use similar and at the same time, slightly different concepts and terminology. Examples include the IQ/OQ/PQ (Installation Qualification / Operational Qualification / Performance Qualification) analogy from process validation, black box testing, unit testing, just to name a few.

Before getting overwhelmed, take a breath and read on to point #2.

RELATED: How to Use Requirements Management as an Anchor to Establish Live Traceability in Systems Engineering

#2. Start with the regulations and standards.

While the multiple regulations and standards around software validation cause confusion, they are also a good place to start. I say that because at a high level they are trying to achieve the same thing- software that meets its intended use and maintains a validated state. Keeping the intent in mind can make it easier (at least it does for me) to see the similarities in the lower-level requirements between any terminology differences and not be as focused on making all the terminology match.

To start, select those regulations and guidance from one of your primary regulatory jurisdictions (like the FDA for the US). In the US, three main FDA guidance documents to incorporate are 1) General Principles of Software Validation; Final Guidance for Industry and FDA Staff, issued in 2002; 2) Part 11, Electronic Records; Electronic Signatures – Scope and Application, issued in 2003.

The 3rd guidance is relatively new, a draft guidance released in September, 2022, Computer Software Assurance for Production and Quality System Software. While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). It is also in this guidance that the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”

Once you’ve grounded yourself in one set, then you can compare and add on, as necessary, requirements for other regulatory jurisdictions. Again, focus on specific requirements that are different and where the high-level intent is similar. For example, in the EU, Regulation (EU) 2021/2226 outlines when instructions for use (IFUs) may be presented in electronic format and the requirements for the website and eIFUs presented.

#3. Start on the intended use and make your software validation and computer software assurance activities risk based.

Start with documenting the intended use of the software and associated safety risk if it were to fail. Then define the level of effort and combination of various software validation activities commensurate with the risk. Software and software features that would result in severe safety risk if it fails are to be validated more rigorously and have more software assurance activities than software that poses no safety risk.

Here are some examples of intended use and the associated safety risk.

Example 1: Jama Connect®, Requirements Management Software

Intended Use: The intended use of Jama Connect is to manage requirements and the corresponding traceability. The following design control aspects are managed within Jama Connect, user needs, design inputs, and traceability to design outputs, verification and validation activities. Risk analysis is also managed in Jama Connect.

Feature 1 Intended Use: Jama Connect provides visual indicators to highlight breaks in traceability. For example, when a user need is not linked to a design input, or vice versa.

Risk-based analysis of Feature 1: Failure of the visual indicator would result in the possibility of not establishing full traceability or missing establishment of a design control element like a design input. This risk is considered moderate as manual review of the traceability matrix is also performed as required by the Design Control SOP. Reports are exported from Jama Connect as pdfs, reviewed externally to the software, and then approved per the document control SOP.

RELATED: Traceability Score™ – An Empirical Way to Reduce the Risk of Late Requirements

Example 2: Imbedded software in automated production equipment

Intended use: The intended use of the software is to control production equipment designed to pick in place two components and weld them together.

Risk-based analysis: This is a critical weld that affects patient safety if not performed to specification. Thus, the software is considered high risk.

#4. Software Validation and computer software assurance is just one part of the software life cycle… you need to be concerned about the whole lifecycle.

There is more to software development and management than just the validation. Incorporate how custom software will be developed, how purchased software will be assessed to determine the appropriate controls based on risk, including verification and validation activities, and revision controlled.

#5. Have different procedures and practices for the different types of software.

This is a good time to consider how different types of software in your organization will be managed, and it’s not a one-size fits all approach. A best practice is to have separate practices and procedures; one for software in a medical device (SiMD) and software as a medical device (SaMD) and at least one other procedure and set of practices for other software, like software used in the production of a device, software in computers and automated data processing systems used as part of medical device production, or software used in implementation of the device manufacturer’s quality system.

Closing

Stay tuned for Part 2 of this 2-part blog series, where we’ll dive deeper into computer software assurance, highlight the risk-based approach, and provide tips and tools to manage your software in a compliant and efficient manner.

In this blog, we recap our eBook, “An Introduction to Research Use Only (RUO)” – Click HERE to download the entire publication.

An Introduction to Research Use Only (RUO)

Learn how it differs from adjacent labels, the FDA and EU guidance, its appropriate use, and the consequences of mislabeling products RUO.

Introduction

In the complex world of medical device development, regulation, and distribution, finding the appropriate label to put on a device may not be simple. When is one label appropriate over another?
Does a device need to go through additional testing, verification, or validation? And what are the consequences of using the wrong label? In this eBook, we’ll cover the differences between Research
Use Only (RUO) and a medical device – although, it’s generally a very clear distinction.

Using the right language and label is critical to complying with best practices. This is why Regulatory Affairs works with the regulatory bodies to ensure that the limitations of the product are properly documented. In a rush to get products to market, it may be tempting to use a Research Use Only (RUO) label to avoid additional regulatory processes while still empowering other researchers and developers. However, there are risks to using the RUO label inappropriately that can have serious consequences for developers, users, and patients. In fact, mislabeling a product is illegal, and punishable. You can see an example warning letter the FDA sent to Carolina Liquid Chemistries Corp after finding intentional mislabeling in 2019 here.

This introduction will provide an overview of the Research Use Only label, how it differs from similar, adjacent labels, its appropriate use, and the consequences of mislabeling products RUO.

What is Research Use Only (RUO)?

The label Research Use Only (RUO) is generally used to indicate products that are intended for scientific research only. They cannot be used for diagnostic or medical purposes. However, there is no standard definition of “research use only,” and the label has slightly different meanings in the European Union and the United States. With the IVDR regulations, RUO products that are being used in
the LDT space are going to be revisited and potentially reclassified as a medical device. With this new classification, teams will likely need to follow design controls, best practices, and industry standards.

What is the FDA guidance on Research Use Only products?

Under the FDA’s guidance issued in 2013, a product labeled Research Use Only is an In Vitro Diagnostic (IVD) product “that is in the laboratory research phase of development and is being shipped
or delivered for an investigation that is not subject to part 812.” The agency includes in this category:

• “Tests that are in development to identify test kit methodology, necessary components, and analytes to be measured.
• “Instrumentation, software, or other electrical/mechanical components under development to determine correct settings, subcomponents, subassemblies, basic operational characteristics, and possible use methods.
• “Reagents under development to determine production methods, purification levels, packaging needs, shelf life, storage conditions, etc.”

The European guidance document MEDDEV 2.14/2 states that a product categorized as an RUO product “must have no intended medical purpose or objective.” The guidance does exempt some tests developed for in-house use as long as the products are not sold to other companies. Some examples of items that can be classified as “research use only” under this exemption include PCR enzymes, gel
component agars, and primers.

RELATED: FDA released new draft guidance of premarket submissions for medical devices – are you ready?

What is the difference between RUO and IVD?

An IVD is an “In Vitro Diagnostic Medical Device,” and the general term applies to any device or product that either alone or with other products is intended to be used for diagnostic, monitoring, or compatibility purposes. There are four different regulatory levels for IVDs:

• Research Use Only (RUO)
• General Laboratory Use (GLU)
• For Performance Studies Only (PSO)
• In Vitro Diagnostic Medical Device (IVD)

The simplest explanation for these different levels is that each increasing level requires more testing and oversight. Research Use Only products are at the lowest level of regulation, and In Vitro Diagnostic Medical Devices are at the highest level. Occasionally in the US, products will be labeled as “RUO IVD,” which means an in vitro device that is intended for research use only.

Products labeled with the “CE-IVD” label indicate that they have progressed through the applicable regulatory process and standards (such as IVDD or IVDR). These products are approved for diagnostic use and must include the IVD symbol to be used for medical purposes.

In the EU, as of May 2022, IVDs must comply with Regulation (EU) 2017/746 (IVDR). The IVDR defines IVDs as follows:

“‘in vitro diagnostic medical device’ means any medical device which is a reagent, reagent product, calibrator,
control material, kit, instrument, apparatus, piece of equipment, software or system, whether used alone or in
combination, intended by the manufacturer to be used in vitro for the examination of specimens, including blood
and tissue donations, derived from the human body, solely or principally for the purpose of providing information
on one or more of the following:

(a) concerning a physiological or pathological process or state;
(b) concerning congenital physical or mental impairments;
(c) concerning the predisposition to a medical condition or a disease;
(d) to determine the safety and compatibility with potential recipients;
(e) to predict treatment response or reactions;
(f) to define or monitoring therapeutic measures.”

All IVDs that comply with the IVDR must carry the CE Mark if marketed in the EU.

Research Use Only products are not subject to regulatory requirements in either the US or the EU, but because they don’t meet the same compliance standards as IVDs, they must be clearly labeled as RUO products and cannot be used for medical purposes.

A known exception is the lab developed test (LDT) pathway for clinical purposes.

What are the requirements for an RUO product?

In the US, RUO products are basically unregulated and do not need to meet any specific requirements to carry the RUO label. The FDA does not specify any restrictions or limitations on RUO products, provided they are clearly labeled “For Research Use Only. Not for use in diagnostic procedures.” For this reason, RUO products can be an excellent solution for laboratories that need research materials for testing and research purposes. Because products with the RUO label do not require extensive testing, verification, and validation, they tend to be more cost-effective for research purposes.

The EU rules are similar. Because RUO products do not have clinical applications, they are not considered medical devices, and there are no requirements for RUO products defined by either the IVDD or the IVDR. These products should not be marked with the IVD mark, and they should be clearly labeled as “Research Use Only.”

RELATED: See how Jama Software^® helped Össur improve the mobility of millions by replacing process rigidity with speed and agility.

Are there alternatives to RUO labels?

Given the significant differences between labeling a product as RUO and labeling a product as IVD, manufacturers and users can’t be too careful when it comes to assigning labels or using products for
specific purposes. If there is a risk to using products labeled as RUO, manufacturers and users should opt for products that have attained a higher compliance level. For example, for a doctor’s office or home use, IVD is the right path. For clinical purposes or hospital labs, RUO could be used as LDT as long as they are CAP/CLIA certified, such was the case with COVID-19 testing kits when the pandemic first hit.

For products that meet a higher degree of compliance, it is possible to assign General Laboratory Use (GLU), Performance Studies Only (PSO), or even In Vitro Diagnostic Medical Device (IVD) labels. However, depending on the intended use for the Research Use Only products, pursuing these additional levels of compliance may or may not make sense.

What is CLIA certification?

CLIA stands for Clinical Laboratory Improvement Amendments. The Centers for Medicare & Medicaid Services (CMS) regulates all clinical laboratory testing performed on humans in the United States
through CLIA.

What is a CAP accreditation?

CAP stands for The College of American Pathologists (CAP). The purpose of CAP laboratory accreditation is to ensure laboratories provide precise test results for accurate patient diagnoses, meet CLIA and CAP requirements, and demonstrate compliance with professionally and scientifically sound and approved laboratory operating standards.

What are RUO products used for?

As the name implies, RUO projects should be used for research purposes only. They may be used for basic research, pharmaceutical research, or in-house manufacturing of “home brew kits” for research purposes and potentially for clinical applications via the LDT pathway. RUO products are specifically not to be used to make diagnoses, conduct performance studies, or as a substitute or comparator for a CE-IVD device. They may also not be used for market or feasibility studies. Raw ingredients labeled as RUO products may not be incorporated into a finished IVD product.

Learn more about the advantages and disadvantages of the RUO label (and more) by downloading the entire eBook HERE.

Common Pitfalls in Change Control Traceability and How to Compensate

Intro

Change is constant, especially in the medical device lifecycle. These changes can be initiated by a manufacturer voluntarily, such as exchanging a component to decrease overall COGS or improve reliability. Or occur involuntarily, like when a supplier discontinues a component or regulations are revised. No matter the reason for the change, manufacturers must be able to assess and document the impact of the change.

This blog will focus on common pitfalls associated with change assessment, specifically the traceability from risk assessments and the design, and how to compensate.

Pitfall number 1: Memories are fleeting

Team members come and go. Whether it’s the design engineers that have moved on to the next development project, or folks have left the company, it’s expected that team members will change. Thus, companies can’t rely on having infinite access to the ‘historic knowledge’ stored in someone’s memories to assess a change. Even if team members do remain, over time they won’t remember, or won’t remember correctly, all the details associated with a particular design decision or associated risk. This tacit knowledge is hard not only to retain, but also to transfer to others at the right time. Thus, documentation is key in retaining and transferring this information.

Pitfall number 2: Improper assessment of the risk of a change

For many reasons, manufacturers don’t fully assess the risk of a change. When a change is proposed, the risk assessments for that device and manufacturing process should be reviewed to understand the impact; impact to safety and effectiveness of the users, first and foremost, and also impact to the organization and business.

For example, a manufacturer is notified by its supplier that a cooling fan is coming to its end of life and a different fan is suggested as the replacement. While the manufacturer does assess that the physical dimensions and power requirements of the new fan work, the manufacturer fails to review their risk assessment files, and proceeds with the change. Unfortunately, they miss that the lifetime reliability of the fan is important to the overall lifetime of the device. The new fan had a lower lifetime that was half than the lifetime specified as a design input to the overall device. The change is implemented and some time later, the manufacturer then began seeing device failures earlier than expected in the field.

RELATED: Carnegie Mellon University Software Engineering Program Teaches Modern Software Engineering Using Jama Connect^®

Pitfall number 3: Incomplete and hard to use design and risk documentation and traceability matrices

Many organizations view their medical device design history and risk management files as a check-the-box activity and don’t fully embody it as practical tools and methods to design, build, and maintain medical devices with the appropriate level of safety. As a result, content is often lacking in context and is hard to cross reference and search when needed, such as to assess the impact of changes. I often remind folks that while the engineering and design work is important, the documentation is just as, if not more important than, the end product. The documentation takes a substantial amount of time and must be planned in as part of the engineering effort and not started after the product is finalized. See below where we reference establishing design controls proactively!

Even those manufacturers that do understand the value of these activities and documents beyond its purpose to fulfill regulatory compliance, their documents are often disparate and separate, resulting in manual or near-manual searching when the need to understand the impact of a change arises.

Compensating for these Pitfalls

Being able to perform a strong change control assessment and compensating for these pitfalls starts with establishing a strong foundation of traceability from design through manufacturing. These include 1) traceability of design inputs to design outputs by establishing design controls proactively; 2) traceability of design to manufacturing requirements, and 3) traceability of risk assessments through the design inputs and manufacturing requirements.

And just as important is keeping all this traceability and requirements organized and easy to reference.

Jama Connect^® is a great tool for traceability and requirements management. Having one place where risk and requirements and inputs are linked avoid the need to manually cross-reference across separate documents. Its visual mapping makes it easier to find how a particular component is linked to a particular design input, manufacturing requirement, and risk assessment line item. The effort can then more quickly focus on the change itself, instead of time spent trying to find all the connections to design inputs, risk, and manufacturing requirements.

A robust change control process and procedures also is necessary. A comprehensive set of questions, such as the ones below, can prompt folks to consider and consult their various traceability tools. Here are some sample product design and manufacturing questions:

• Is the change associated with a critical output or essential output?
• How is the risk impacted? Consider risk from the use, design, and process perspectives.
• What design input(s) is associated with the change? What is the impact to design verification or design validation?
• What manufacturing requirement(s) is associated with the change? What is the impact to process validation?
• How is sterilization impacted by the change? What about other areas such as packaging, serviceability, maintenance?

RELATED: Requirements Traceability Benchmark

Closing

Avoid the risk associated with making incomplete assessments of product and process changes. Ensure your traceability is complete and kept up to date, in a manner that is both compliant and practical for your team to use and ensure your change control procedures incorporates a robust risk analysis.

Jama Connect^® for Robotics

Jama Connect^® for Robotics provides a single platform for development teams to manage requirements, test, and functional safety throughout the product development lifecycle in the robotics industry.
The Jama Connect Robotics Solution is a complete set of frameworks, example projects, and procedural, export, and configuration documentation intended to accelerate the implementation of Jama Connect for organizations developing robotics systems and components.

The license model is fully scalable, ensuring rapid deployment and easy adoption of the solution across your product development team. The base product includes the full breadth of Jama Connect’s core capabilities with access for up to 10 named Creators, and site licenses for Stakeholders and Reviewers — enough to get your product organization up and running with our industry-leading solution.

Updates to these features are included as part of the subscription package.

The application of the base product can easily be expanded to allow access to the entire enterprise. Jama Connect for Robotics is available as either a cloud or self-hosted deployment option and
is based on an annual subscription. It does not require client-side software to be installed.

RELATED: 2023 Predictions for Industrial and Consumer Electronics Product Development

Includes:

• Minimum of 10 Named Creators
• Unlimited number of licenses for Stakeholders and Reviewers
• Secure SaaS hosting and on-premises deployment options
• 24 x 7 critical issue support
• Non-production-hosted sandbox
• Robotics framework aligned with systems engineering best practices and standards including IEC 61508 (functional safety) and IEC 60812 (FMEA)
• Procedure, export, and configuration guides for robotics developers
• Export templates
• Training and consulting designed for automotive manufacturing

Benefits:

• Increase confidence and decrease time to value with an established scope and direct alignment of requirements
• Reduce deployment time for new clients with defined and justified configuration, export templates, and reports
• Meet functional safety certification up to safety integrity level (SIL) 4 with an eased path to compliance
• Centralize robotics development, testing, and risk processes with Live Traceability™ proven to enable better product quality outcomes

The following report/export templates are provided as part of the solution to support alignment with robotics industry standards and regulations.

RELATED: ISO 26262 Second Edition Introduces Updates to Functional Safety in Road Vehicles

Because everyone requires clarity on what your teams are building and why, Jama Connect for Robotics offers four unique license types to suit different user needs and promote deep collaboration and alignment across your organization. The table below summarizes these available license types.

The solution allows flexibility to customize the configuration of your Creator licenses, for example:

• 1 named and 3 floating licenses
• 4 named and 2 floating licenses
• 7 named and 1 floating license
• 10 named licenses

To learn more about Jama Connect licensing options visit: jamasoftware.com/platform/licensing

In this blog, we’ll break down key elements of our Jama Connect for Automotive Solution. To read the entire solution overview, click HERE. 

Jama Connect^® for Automotive

Accelerate requirements management for safety- and cybersecurity-critical systems

Jama Connect^® for Automotive provides a single platform for development teams to build safety-critical and cybersecurity-critical products, while accelerating time to market with frameworks and templates aligned to industry standards of Automotive SPICE (ASPICE), ISO 26262:2018, and ISO 21434:2021.

Accelerate Your Automotive Development

Jama Connect for Automotive is designed to help you get ramped up quickly with a single platform, training, and documentation aligned to industry standards and regulations, including ASPICE, ISO 26262:2018, and ISO 21434:2021, while applying a proven systems engineering approach to product development.

What’s Included:

• Frameworks aligned to key industry regulations
• Procedure and configuration guides specific to automotive development activities
• Functional Safety Kit reduces time required for software tool qualification
• Consulting and training customized to your teams’ automotive product development processes
• Exports and reports aligned with industry needs along with a detailed reporting guide

RELATED: Jama Connect^® for Automotive Development Datasheet

A Single Platform for Building Safety-Critical Products

Requirements Management

Manage and validate complex systems requirements while eliminating the risks and inefficiencies associated with documents-based and legacy systems.

Hazard Analysis & Risk Assessment

Meet functional safety standards and identify and mitigate hazards earlier in development, helping teams avoid frustrating and costly late-stage design changes.

Procedure and Configuration Guides

Accelerate adoption and improve functional safety compliance using procedure and configuration guides developed for the automotive industry.

Standard Frameworks

Accelerate adoption and improve compliance using frameworks aligned to key industry regulations: Automotive SPICE (ASPICE), ISO 26262:2018, and ISO 21434:2021.

Test Management

Align tests and requirements, run test cases, and instantly log connected defects when tests fail.

Export Templates

Support the automotive product development process with export templates developed for the automotive industry.

Ease the Challenges of Validating your Product Development Platform

Functional Safety Kit for Automotive Development Teams

ISO 26262 stipulates that automotive developers must validate their software tools to ensure that they are suitable for use in developing safety-related items. The Functional Safety Kit for Jama Connect is designed to reduce the time required for validation by providing a complete list of Jama Software’s internal mechanisms, workflows, and usage scenarios that we have certified by the internationally recognized testing body, TÜV SÜD, for every product release. The Functional Safety Kit comes with process documentation, critical workflows/safety manual, and a TÜV SÜD certificate and report indicating that Jama Connect is suitable for use in the development of safety-related software according to ISO 26262 up to ASIL D.

Exchange Requirements Seamlessly

Supply Chain Collaboration

Data Exchange for Jama Connect is used to import, export, and update data to create an ongoing exchange of requirements throughout the product development process. This solution is designed
to process data according to Requirements Interchange Format (ReqIF) standards as published by the Object Management Group. These services provide Jama Connect with the ability to import and exchange data with IBM^® DOORS^® and other ReqIF-supported products.

Key Solution Benefits

With Jama Connect for Automotive, you can:

• Increase confidence and decrease time to value with an established scope and direct alignment of requirements
• Reduce deployment time with defined and justified configuration and export templates
• Adapt Jama Connect to meet the unique needs of your organization with flexible system and template modifications
• Drive adoption and reduce the impact of change to your teams, with training aligned to your people, processes, and data

RELATED: A Guide to Road Vehicle Cybersecurity According to ISO 21434

Optimize Success for Your Organization

When you purchase Jama Connect for Automotive Development, our consultants partner with you to adapt the solution to fit your product delivery process and drive adoption of Jama Connect within your organization.

Alignment Phase

The alignment phase aims to determine and implement the best use of Jama Connect for your organization based on an understanding of your product development process, business objectives, and desired team workflow.

This phase includes:

• Preliminary project planning and discovery sessions to understand your people, processes, and data as it pertains to requirements management, and verification and validation for automotive development
• Onsite workshop or remote working sessions focused on alignment of processes to governing standards Automotive SPICE (ASPICE), ISO 26262:2018, and ISO 21434:2021
• Consultants partner with you to setup templates or utilize standard reports to produce the following document exports: checklist baseline, hazard analysis and risk assessment baseline, test results, detailed Review Center stats report, baseline export to Word, and default export to Word
• Your Jama Software^® consultant will work with your core implementation team to prepare Jama Connect for use by end users, in remote working sessions if needed

Launch Phase

Once it’s ready to use, your Jama Software consultant will lead a remote or onsite training to show your teams how to use Jama Connect. Following the training, your consultant will be available remotely to provide assistance as needed to support your initial implementation.

Download the entire Jama Connect for Automotive Solution Overview eBook HERE.

What is the Department of Energy National Cyber-Informed Engineering Strategy (CIE) Framework?

Cybersecurity incidents have become significant in recent years, causing ripple effects across countries and communities. Regulating cybersecurity has often fallen to private entities. However, with recent cyberattacks causing large-scale impacts, government agencies are now setting forth new actions and regulations.

The US Department of Energy recently released the National Cyber-Informed Engineering Strategy (CIE) Framework to address mounting cybersecurity concerns. In this blog, we will overview this newly released framework and briefly discuss how risk management can help energy companies by making them better positioned to manufacture and maintain the tools that help prevent and quickly recover from cyberattacks.

RELATED: 5 FBI Recommendations for Medical Device Cybersecurity

Department of Energy National Cyber-Informed Engineering Strategy (CIE) Framework

The U.S. energy sector faces continuous and ever-evolving cybersecurity threats, among various other industries. According to the 2022 Office of the Director of National Intelligence (DNI) Annual Threat Assessment, “our adversaries maintain capabilities to launch cyberattacks that could disrupt critical infrastructure, including industrial control systems in the U.S. energy sector. Cybersecurity attacks on critical infrastructure are particularly consequential and ensuring the security, reliability, and resilience of these systems is a top priority for the U.S. Department of Energy’s (DOE) Office of Cybersecurity, Energy Security, and Emergency Response (CESER) and its partners in government and the private sector”

The CIE framework, grown from earlier Congressional direction regarding threats to the nation’s energy sector, advocates for an evolutionary shift across the energy industry and related institutions, including researchers, standards bodies, Federal partners, and others. Its recommendations reflect expertise and insight from energy companies, energy systems and cybersecurity manufacturers, standards bodies, researchers, DOE National Laboratories, and Federal partners in the cybersecurity and engineering mission space.

It encourages the adoption of a “security-by-design” mindset within the Energy Sector Industrial Base, which refers to building cybersecurity into our energy systems at the earliest possible stages rather than trying to secure these critical systems after deployment.

Principles of Cyber-Informed Engineering (CIE): A Five-Pillar Approach

The CIE Strategy is built upon five pillars. When united, CIE’s pillars create an overall approach that enables “a body of knowledge, a diverse and expanded workforce, and the engineering and manufacturing capacity to apply CIE to today’s energy infrastructure and to engineer future energy systems to eliminate or reduce the ability of a cyber-enabled attack to generate significant impact.”

These five pillars are:

• Awareness
• Education
• Development
• Current infrastructure
• Future Infrastructure

Image from CIE Strategy

RELATED: What is the Urgency Behind Automotive Cybersecurity?

Using CIE As a Model for Other Critical Infrastructure Sectors

While this National Cyber-Informed Engineering Strategy has been developed for energy sector systems, the strategy can serve as a guide for other critical infrastructure sectors to adopt.

CIE concepts and strategies to apply various types of engineering. It represents foundational engineering principles that apply similarly to all other critical sectors—such as water, transportation, telecommunications, manufacturing, and more.

Risk Management Agencies, other federal agencies, and critical infrastructure partners and stakeholders “can leverage the National CIE Strategy as a model to implement CIE principles broadly to all U.S. infrastructure systems that operate critical functions for the nation,” U.S. Department of Energy.

How Jama Connect Can Enable Cybersecurity with Our Risk Module Framework

Jama Connect enables organizations to identify and manage cyber-related risks with cybersecurity requirement management, test case and test execution management, work product verification management, software tool qualification support, configuration management, change control, and tool ecosystem integration.

To learn more, download our Jama Connect Datasheet.

Application lifecycle management (ALM) tools enable efficient, standardized communication and collaboration between teams in application development, testing, and other business departments. The benefits of a top ALM platforms include less risk from manual and siloed application lifecycle management processes, plus superior confidence in the outcome of compliance and product quality.

What is application lifecycle management?

ALM itself is a broad term. It encompasses key activities across requirements management, quality assurance (QA), IT service delivery, and project management. By spanning all of these diverse activities, ALM may include every workflow from mapping out a preliminary route to regulatory approval for a software-driven medical device, to the testing of that same product in alignment with its requirements and its eventual post-release maintenance.

The exact structure of ALM, and the particular solutions selected to support it, will vary based on the software development practices in use at an organization. For example,  ALM can support Agile methodologies as well as DevOps automation processes built around continuous integration and deployment pipelines. In these instances, an integrated ALM process, backed by the right ALM platform, helps bring teams together and ensures all requirements are met for each application.

Application lifecycle management tools can also work within Waterfall methodologies in which activities are broken down into discrete stages instead of approached continuously. Process-agnostic ALM platforms may be configured to support a variety of software projects and extended to support hardware initiatives that revolve around product lifecycle management (PLM), too.

In fact, ALM first emerged as a software-specific evolution of PLM, which applies to physical products such as automobiles. Organizations may seek integration between their ALM and PLM process and technologies to maximize the efficiency of their development processes, such as in the case of a complex connected device within the Internet of Things (IoT).

What do application lifecycle management tools do?

At a high level, best-of-breed modern ALM platforms may provide tools for:

Requirements management

Traditional processes for managing requirements are outdated, as they often involve maintaining numerous Microsoft Word documents and/or spreadsheets, all of which may need to be developed and reviewed separately. This approach slows down the application lifecycle while increasing costs by introducing unnecessary risk related to human error.

In contrast, an ALM tool form offers a comprehensive solution for requirements management. Teams can define all requirements, risks, and tests, plus create virtual relationships between work items, perform risk analysis, and have easy visibility into the potential impact of making changes. Requirements can be scheduled and managed from one interface.

Essentially, the ALM platform serves as a single source of truth where costly rework and time-consuming reviews of multiple siloed data sources can be avoided. Meanwhile, development processes are typically accelerated through substantial reductions in the time needed to identify and remediate requirements-related defects.

RELATED: How Better Requirements Management — and Requirements Management Tools — Can Improve Your Product Development Process

End-to-end activity traceability

With applications being developed on increasingly fast timelines and in accordance with a growing array of requirements and regulations, traceability is crucial.

Are development and testing activities adequately fulfilling all defined requirements (on both general and granular subsystem levels)? Are there any gaps in test coverage? Can proof of requirements fulfillment easily be reviewed, signed, and used to demonstrate compliance?

Getting reliable answers to these questions and others requires a capable ALM platform. The right ALM platform provides solutions for creating virtual trace relationships between requirements, risk, tests, and other development activities. More flexible ALM platforms can be extended through toolchain integrations (see below) to capture activity traces across teams and platforms. Virtual traces also tie electronic signatures to any defined milestones and released documents, as well as provide a way to see and analyze the potential impact of making changes. Proof of requirements fulfillment (i.e. trace views and matrixes) should be easy to monitor and export to demonstrate compliance.

RELATED: How Adopting Modern Traceability Leads to Better Products

Software testing and QA

Testing is an important part of ALM. More specifically, test results will need to be continually updated to accurately reflect the progress of an application’s lifecycle.

Keeping track of these details is more practical with a modern ALM platform that makes it easy to see the status of existing test results, add new tests as needed, and perform time-saving batch updates that capture or change the status of multiple test executions, all in one repository

With the right application lifecycle management tools, these testing and QA processes can be greatly streamlined by providing teams greater visibility into the requirements that inform their work. Accordingly, teams can get the most from their Agile processes and deliver the highest quality software to market as quickly as possible.

Real-time team collaboration

ALM is a fundamentally collaborative endeavor, as it spans a wide range of activities from project management to QA. But efficient collaboration can’t be taken for granted – teams need intuitive collaboration technologies to keep their work aligned and on track.

The real-time collaboration capabilities in an ALM or ALM-adjacent tools enable productive reviews and approvals. Features such as virtual reviews and electronic signatures containing a complete timestamp provide structured solutions for distributed/remote teams to streamline collaboration and ensure compliance with regulatory standards.

Feedback can be captured in one place, allowing for items to be quickly and efficiently categorized as approved or in need of work. Centralizing collaboration features with requirements management provides a solution to track which stakeholders are involved so that follow-up actions can be appropriately assigned as necessary. Moreover, it reduces the risks associated with protracted project times and personnel churn, as knowledge it retained in the system itself rather than in individual minds, making key insights readily available down the line.

RELATED: Innovation Can’t Happen Without Collaboration

Toolchain integration

Multiple platforms may be combined to handle all of the different aspects of ALM-PLM. Platform extensions are typically constructed through built-in integrations or through the use of open APIs that support custom work.

The integration of platforms is important to keep activities, such as software development, properly aligned with requirements. An ideal integration allows for essential information to synchronize between platforms, facilitating collaboration, and improving visibility across otherwise siloed teams and/or technologies. In many cases, a toolchain integration offers a solution for improved traceability to demonstrate compliance.

Testing tools, task, and bug tracking software, and automation servers have great potential for integration with application lifecycle management platforms. Overall, an integrated ALM toolchain will lower risk and lead to better quality and compliance. The integration between Jama Connect and Jira is a prime example of how pairing different best-in-class platforms can increase visibility and support the work of global teams.

To learn more about Jama Connect, visit the main product development page, or get in touch with a member of our team.

To learn more on the topic of requirements management, we’ve compiled a handy list of valuable resources for you!

SEE MORE RESOURCES

Editor’s Note:

Getting Past Legacy Software Pains in Requirements Management

If you feel like you have outgrown your requirements management (RM) software, you are far from alone. From complex systems, such as IBM Doors, to document-based tracking through Microsoft Office, legacy RM tools are having a hard time catching up to the innovation occurring in highly-regulated industries. As we see the line between hardware and software become increasingly blurred, development methodologies are evolving faster than ever before. Sometimes, these changes happen day-to-day or even hour-to-hour, making project traceability feel impossible.

No matter how complex the software or notable the reputation, RM providers don’t always deliver a system that matches the goals of teams that need to quickly adapt, innovate, and grow. This misalignment can create several pain points that interfere with productivity. While some can be attributed to shifts in the marketplace, others are directly rooted in the software tools you are using to meet compliance.

Here are some common snafus and how to work your way out of them.

Multiple Stakeholders, Multiple Problems

From avionics to automotive to Medtech, highly-regulated industries see many different stakeholders and players, and that is a good thing. In order to reach peak public and functional safety, it’s crucial to value the input of multiple roles and skillsets. But, what happens if one or some of these folks don’t know how to use your RM software? At best it’s a shame that they can provide their two cents and at worst this begins a recipe for compliance disaster. To sidestep this conundrum, opt for software that seamlessly flows with multiple roles. More so, make sure whatever software you choose integrates user-friendly traceability. It’s crucial that each and every individual on the project be able to see the progress made from beginning to end.

So, You Missed a Deadline…

It happens to the best of us. You were asked to provide feedback on a requirement and you missed your shot to chime in. Whether a colleague left a comment for you in a Word or Google Doc or shot over an email to glean your opinion, the mode of collaboration you have in place failed you. That’s right, this isn’t all your fault. Review processes are too complex these days and they require collaboration software that sets the intentions of the users clearly. This requires real-time editing and notifications to help keep you and your team on track. To prevent falling into this trap, look for an RM tool that prompts the next steps, and sends timely notifications with clear instructions. Conversations about “who dropped the ball” aren’t productive or fair, the RM software you integrate should fill this gap in human error.

You’ve Been Blocked

You are frantically trying to enter crucial data into the system but you are somehow locked out. You can’t get a hold of the person who manages access and you are beginning to feel frantic. This isn’t just frustrating for you, it also poses some substantial risks to the company. On top of losing a couple of hours trying to break into the system, this clunky process inevitably chips away at the desire to provide feedback with any regularity or confidence. This goes against the entire purpose of collecting data in the first place. To facilitate continuous growth and data collection, your RM tool should be open, accessible, and intuitive. Only then will you encourage the kind of constant input and collaboration from stakeholders that is necessary to keep up with breakneck innovation.

When an Upgrade Spells Doom

Back in the day, we all used to get skittish when an iPhone software upgrade notification popped up on our screen. Will I lose all my photos and contacts? What about all those passwords I saved to log-in to my favorite apps? With the advent of the Cloud, much of this fear has dissipated. When it comes to your RM software, your team shouldn’t be afraid to upgrade the system to fix issues, improve security, and access the latest features.

Yet, these systems are often so customized or patched-together that an upgrade could mean disaster. Because the products you are building change and improve over time, you should have an RM system that can adapt quickly. When it’s time to purchase legacy software, weigh the opportunity costs of investing in something so stale. Ultimately, is the pain of being locked-out or unsupported on various platforms worth the headache?

Pain points aside, we are living in an age that has bred the most disruptive and creative products to date. From ultra-fast and sleek electric cars to life-like prosthetics to self-piloted spaceships, we have some of the best and brightest minds toiling away on how to propel us into the future. At the same time, the regulatory environment has become even more stringent to meet both the demands of the marketplace and public safety. It is going to take synced and streamlined teams to decrease time-to-market and meet the ever-increasing demands of compliance. To pull this off, you need collaboration infrastructure in place that keeps your team organized and catches mistakes often missed by disconnected individuals.

If you’re interested in learning more about requirements management, we’ve compiled some great resources for you here.

LEARN MORE

TrustRadius Names Jama Connect™ a 2020 Top-Rated Application Lifecycle Management Platform

We are so happy to share that Jama Software has been recognized as a leader among application lifecycle management (ALM) tools for the second year in a row. “We are honored to have received this recognition by TrustRadius. We have the largest team of developers focused on requirements management for safety-critical products,” said Jama Software CEO, Marc Osofsky. “And we’re honored that the most innovative companies in industries such as medical device, automotive, semiconductor, aerospace and defense have chosen to work with us so that together we can shape the future.”

Customer-centric Criteria

With a trScore of 7.9 out of 10] and over 94 verified reviews, Jama Connect™ is proud to be recognized by the TrustRadius community as a valuable player in the Application Lifecycle Management software category.

One of the things we’re most proud of is that our customers selected us—with their excellent satisfaction ratings—as a top-rated ALM tool. This rating was based purely on TrustRadius’ verified customer reviews; there is no paid placement, and analyst opinions do not influence the rankings. To qualify, a product must have 10 or more recent reviews and a trScore of 7.5 or higher, indicating above-average satisfaction for business technology. Read more about the Top Rated criteria.

“Jama Software is one of those rare SaaS companies that has a passionate following among our users,” said Jama Software CEO, Marc Osofsky. “When our users change companies, they bring us with them. Trust Radius focuses on user satisfaction and reflects our pride in the passion of Jama Nation.”

What Our Customers are Saying

Here are just a few quotes from TrustRadius verified users on how they’re using Jama Connect:

“JAMA Connect is used by our Medicaid Pharmacy Solutions Business Analysis Team for managing requirements for our clients. JAMA Connect provides the solution for housing our requirements in a repository to meet the needs of our customers. The review center is great to review requirements electronically instead of sitting in a meeting to review them. Version control creates a great audit trail.“
-Analyst in Information Technology, Hospital & Healthcare

“Jama Connect is the source of truth for requirements. We have used it internally…to communicate between Engineering, Operations, and Scientists, but also to do requirement reviews with external consortia, to get their input. We are also using it for requirement flow-down and traceability and using several report tools. …having an agile way of dealing with requirements helps us.”
-Engineer, Research Company

“We use Jama Connect for requirements management. It’s used across several business units within R&D to manage requirements from initial creation all the way to generating final design traceability matrices. It has been particularly helpful with managing systems with several subsystems that each have sets of requirements. Rather than waste a significant amount of engineering time, Jama allows us to generate requirement documentation (MRS, PRS, SRS, HRS, V&V Plans, and DTMs) with very little effort.”
-Engineer in Research and Development for Medical Device Company

Our Customers’ Success is Our Success

Helping enable our customers’ success is at the core of everything we do. While we take pride in winning this award, our greatest success is watching how our customers use Jama to not only achieve but exceed their business objectives. “Our customer bonds are deeply rooted and personal. We celebrate the product and career successes we help enable and engage deeply on product direction,” said Osofsky.

We continue to innovate, make improvements to our platform, add new features, expand our integrations, and strive to enhance and broaden our service offerings. Our goal is to continue to provide best-in-class requirements, risk, and test management products and outstanding customer service to our customers now and into the future.

At Jama, we’re proud to create products that inspire such gracious feedback in our user community. Thank you for supporting our work, and for sharing your feedback on TrustRadius.

About TrustRadius: TrustRadius is the customer voice and insights platform that helps tech buyers make great decisions, and helps technology vendors acquire and retain great customers. Each month, over half a million B2B technology buyers use over 222,000 verified reviews and ratings on TrustRadius.com to make informed purchasing decisions. Headquartered in Austin, TX, TrustRadius was founded by successful entrepreneurs and is backed by Next Coast Ventures, Mayfield Fund, and LiveOak Venture Partners.