Tag Archive for: Product Development & Management

Understanding IATF 16949: A Quick Guide to Automotive Quality Management

In the ever-evolving landscape of the automotive industry, ensuring product quality and safety is paramount. One key standard that plays a crucial role in this pursuit is IATF 16949. In this article, we will delve into the intricacies of IATF 16949, exploring its significance, key elements, and benefits.

What is IATF 16949? IATF 16949, or the International Automotive Task Force 16949, is a globally recognized quality management standard specifically designed for the automotive sector. This standard is based on ISO 9001 and incorporates additional requirements tailored to the automotive industry. IATF 16949 was developed by the International Automotive Task Force (IATF) to promote quality, consistency, and continual improvement throughout the automotive supply chain.

This image portrays some of the automotive elements involved in the IATF 16949 regulation.

Key Elements of IATF 16949:

  • Customer Focus: IATF 16949 places a strong emphasis on meeting and exceeding customer requirements. This includes understanding customer needs, providing defect-free products, and consistently delivering high-quality services.
  • Process Approach: The standard adopts a process-oriented approach to quality management. Organizations are encouraged to identify, manage, and optimize key processes to enhance efficiency and effectiveness in meeting objectives.
  • Risk Management: IATF 16949 requires organizations to identify and address potential risks within their processes. This proactive approach helps in preventing issues, ensuring product safety, and maintaining a robust quality management system.
  • Supplier Quality Management: Recognizing the interconnected nature of the automotive supply chain, IATF 16949 places a significant focus on supplier quality management. Companies must work closely with their suppliers to ensure that quality standards are consistently met throughout the supply chain.
  • Continuous Improvement: The standard promotes a culture of continual improvement, urging organizations to regularly assess and enhance their processes. This commitment to ongoing refinement helps companies stay ahead in a competitive market.

Benefits of Implementing IATF 16949:

  • Global Recognition: Achieving IATF 16949 certification provides organizations with global recognition, enhancing their credibility and opening doors to new business opportunities.
  • Improved Efficiency: By adopting the standard’s process-oriented approach, organizations can streamline their operations, reduce waste, and enhance overall efficiency.
  • Enhanced Customer Satisfaction: Meeting IATF 16949 requirements ensures that products and services consistently meet or exceed customer expectations, leading to higher satisfaction levels.
  • Risk Mitigation: The focus on risk management helps organizations identify potential issues before they escalate, reducing the likelihood of defects and recalls.
  • Competitive Advantage: IATF 16949 certification provides a competitive edge in the automotive industry. Many OEMs (Original Equipment Manufacturers) prefer working with suppliers who adhere to this globally recognized standard – and many companies are required to comply.

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

Who is required to comply with IATF 16949?

Companies that are part of the automotive supply chain, including manufacturers, suppliers, and service providers, may be required to comply with IATF 16949. This includes organizations involved in the production of automotive parts, components, and assemblies.

Key stakeholders in the automotive industry, such as original equipment manufacturers (OEMs) and their suppliers, often seek IATF 16949 certification to demonstrate their commitment to quality and compliance with industry standards. Certification to this standard is often a prerequisite for becoming a supplier to major automotive companies.

It’s important for organizations in the automotive sector to assess their specific contractual requirements and the expectations of their customers to determine whether compliance with IATF 16949 is necessary for their business. Certification to IATF 16949 is typically achieved through a third-party audit process conducted by accredited certification bodies.

What is a Quality Management System?

A Quality Management System (QMS) is a comprehensive framework of policies, processes, procedures, and records that an organization establishes and maintains to ensure its products or services consistently meet or exceed customer expectations. The primary goal of a QMS is to enhance customer satisfaction by consistently delivering high-quality products or services while also meeting regulatory requirements. It encompasses various elements such as quality planning, control, assurance, and improvement. A well-implemented QMS helps organizations identify and document their processes, set quality objectives, and monitor performance against these objectives. It often involves the use of standardized methodologies, documentation, and quality tools to foster a systematic approach to quality management, ensuring that every stage of the product or service lifecycle is controlled, measured, and continually improved upon. Certification to internationally recognized QMS standards, such as IATF 16946 and ISO 9001, provides external validation of an organization’s commitment to quality and can enhance its credibility in the marketplace.

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

How can Jama Connect® help?

Jama Connect® is a powerful tool that plays a pivotal role in assisting teams in meeting the requirements of a QMS within various industries, particularly those with stringent regulatory standards.

Here are several ways in which Jama Connect facilitates compliance with QMS requirements:

  • Documenting and Managing Requirements: Jama Connect provides a centralized platform for documenting and managing requirements throughout the product development lifecycle. It allows teams to create, review, and collaborate on requirements, ensuring clarity and consistency. This centralized approach enhances communication among team members, reducing the risk of misunderstandings and improving overall requirement management efficiency.
  • Enabling Risk-Based Thinking: The platform supports risk-based thinking by providing tools to identify, assess, and mitigate risks associated with product development. Teams can systematically evaluate potential risks, assign risk levels, and implement mitigation strategies. This proactive approach aligns with the risk management requirements of QMS standards, contributing to safer and more reliable product development.
  • Assisting with Change Management Processes: Change management is a critical aspect of QMS, and Jama Connect streamlines this process. Teams can efficiently capture and evaluate proposed changes, assess their impact on requirements and other project elements, and implement changes in a controlled manner. This ensures that changes are documented, reviewed, and tracked, promoting transparency and accountability in the change management process.
  • Enabling Traceability of Processes and Products: Jama Connect offers robust traceability features, allowing teams to establish and visualize relationships between requirements, tests, and other project artifacts. This traceability is crucial for demonstrating compliance with QMS standards, as it provides a clear linkage between various stages of the development process, from initial requirements to final product validation.
  • Easy Documentation for Evidence for Audits: Jama Connect simplifies the documentation process required for audits. The platform enables teams to generate comprehensive reports, traceability matrices, and documentation trails that serve as evidence of compliance with QMS standards. This facilitates smoother and more successful audits, as auditors can easily review and verify the necessary documentation.
  • Supporting a Continuous Improvement Process: Continuous improvement is a fundamental principle of QMS, and Jama Connect supports this by providing analytics and insights into project performance. Teams can analyze data on requirements, testing, and other project metrics to identify areas for improvement. This data-driven approach fosters a culture of continuous improvement, aligning with the principles of QMS standards.
  • Supporting a Customer Focus with Traceability to Customer Needs: Jama Connect helps maintain a strong customer focus by establishing clear traceability from requirements to customer needs. This ensures that the final product aligns with customer expectations and requirements. The platform’s traceability features provide a visual representation of how each requirement contributes to meeting customer needs, strengthening the customer-centric approach advocated by QMS standards.

IATF 16949 is a critical standard for the automotive industry, emphasizing quality management, risk mitigation, and continuous improvement. Organizations that invest in achieving and maintaining IATF 16949 certification position themselves as reliable partners in a highly competitive and demanding market, ensuring the production of high-quality automotive products.

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Matt Mickle and McKenzie Jonsson.

Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from Med Device Online, titled “Decoding The FDA’s Draft Guidance On Computer Software Assurance For Medical Devices & Bio/Pharma” – written by Hemadri Doma, Tolmar Inc. and originally published on February 6, 2024.

Decoding The FDA’s Draft Guidance On Computer Software Assurance For Medical Devices & Bio/Pharma

The current state of validation is seen as a hindrance to quicker deployments, with an emphasis on adhering to thorough documentation practices instead of building systems that align effectively with their intended use.

A risk-based approach to validation has been around for some time. However, life sciences companies have been challenged with identifying software risks and the desired level of validation effort. Simultaneously, medical device manufacturers have expressed a desire for greater clarity regarding the FDA’s expectations for software validation.

In a rapidly evolving landscape of technology and regulation, the FDA released a draft guidance on computer software assurance in 2022 that promises to reshape the validation of automated data processing system and quality system software in the pharma/medical device industry and to enhance the quality, availability, and safety of medical devices. In this article, I will walk you through the key elements of the guidance, providing valuable insights for professionals navigating the complexities of automated processes and quality system software.

Guidance Supersedes Section 6 Of Software Validation Guidance Of 2002

The forthcoming guidance is set to supersede Section 6 of the general principles of software validation guidance from 2002, signaling a paradigm shift in the approach to validating automated data processing system and quality system software. This guidance provides crucial recommendations applicable to the requirements of 21 CFR 820.70(i), focusing on automated processes integral to production and quality systems.

Understanding The Regulatory Scope

The guidance emphasizes the necessity for manufacturers to validate software used in production or the quality system for its intended use. However, it explicitly excludes software as a medical device (SaMD) or software in a medical device (SiMD) from its scope. The document prompts manufacturers to thoroughly assess whether the regulatory requirement applies to their specific software.

A central theme revolves around a risk-based approach, urging manufacturers to delve into the intended use of individual features, functions, and operations within their software. The guidance recognizes the complexity of software used in production or the quality system, often comprising multiple intended uses. It encourages manufacturers to conduct different assurance activities tailored to these specific elements based on a meticulous risk assessment.

The guidance outlines the components of a robust record of assurance activities, stressing the need for objective evidence. It recommends capturing the intended use, risk determination, details of assurance activities conducted, issues found, and a conclusion statement declaring the acceptability of results.

The guidance distinguishes between process risks and medical device risks. Process risks pertain to potential compromises in production or the quality system, while medical device risks focus on the potential harm to patients or users. The document emphasizes the FDA’s concern for software features, functions, and operations that pose both high process risk and a consequential medical device risk, aligning assurance activities with the severity of potential issues.

Manufacturers are encouraged to leverage existing process controls throughout production, particularly for lower-risk software features. The guidance emphasizes the importance of data and information collected by the software for continuous monitoring and issue detection post-implementation. It highlights the use of computer system validation tools, iterative testing cycles, and continuous monitoring as integral elements of a comprehensive assurance approach.

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

Establishing The Appropriate Testing Methods5

FDA always recommended leveraging all the vendor documentation when we were using computer system validation (CSV); now, in computer software assurance (CSA), FDA is strongly recommending leveraging all the vendor documentation and performing the remaining portion of testing in scripted and unscripted testing that is not covered in vendor testing.

FDA introduced new nomenclature for testing methods in CSA, scripted testing and unscripted testing, which are adopted from EC/IEEE/ISO 29119-1 First edition 2013-09-01: Software and systems engineering – Software testing – Part 1: Concepts and definitions, Section 4.94 to stay aligned with current practices and standards from IEEE for software testing.

The terms IQ, OQ, PQ relate to the original general principles of software validation guidance. The discussion at that time emphasized that IQ, OQ, and PQ, while relevant from a process standpoint and process-validation perspective, may not be directly applicable when dealing with software validation cases. It’s not a situation where these terms are irrelevant or inapplicable. Manufacturers always have had the freedom to structure their processes to meet the requirements of their quality system or business objectives. The use of these terms is optional, and if they provide clarity for the organization, they are free to adopt them. However, it hasn’t been explicitly stated before that these terms are crucial or necessary in the context of software validation.

Now, let’s dive into what unscripted testing and scripted testing are in terms of current software testing and how we can adapt to CSA activities.

Unscripted Testing

Unscripted testing is a software testing approach characterized by the absence of predefined test scripts or detailed test cases.

For context, current software testing practices say we don’t need any documentation, but in regulated companies we need to have minimum documentation. You are still laying out some objectives that need to be exercised, accomplished, or captured in some way, shape, or form. And within that context, there is a lot of flexibility with regard to developing a protocol established in 21 CFR 820.70(i), which states, “When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol.”

Unscripted testing is divided into three types:

  1. Ad hoc testing: Ad hoc testing2 is an informal and unstructured software testing type aimed at disrupting the testing process to identify potential defects or errors in the early stages. This type of testing is typically unplanned in that it does not follow any documentation or test design techniques to formulate test cases. This type of testing tests features and functions with no test plan.
  2. Error guessing: Error guessing3 is a testing technique based on the tester’s experience, where they use their expertise to speculate or guess about potential problem areas within the application. This method requires a skilled and experienced tester. This type of testing tests failure modes with no test plan.
  3. Exploratory testing: Exploratory testing4 is a manual software testing technique conducted without a formal plan, allowing testers to deviate from scripted routines (repetitive and monotonous). It empowers testers to apply their skills creatively. Successful exploratory testers need critical thinking, creativity, and strong domain and technical knowledge.

While exploratory testing may seem unplanned, it isn’t random. It involves applying knowledge and expertise. Deep knowledge of the system under test is crucial for effective exploratory testing.

Establish high-level test plan objectives (no step-by-step procedure is necessary). Benefits of exploratory testing include:

  • Identifying edge cases and unexpected defects that scripted testing might overlook.
  • Testing from a user perspective to enhance user experience and usability.
  • Encouraging critical thinking among testers, preventing monotony, and improving software quality.
  • Increasing test coverage by exploring various scenarios and uncovering new defects.
  • Testing software in its early development stages to catch bugs early, even without formalized, scripted tests.
  • Providing flexibility to try new testing techniques, contributing to overall testing improvement.

Scripted Testing

Scripted testing refers to a software testing approach where the tester follows a predefined set of written instructions or scripts during the execution of test cases. Scripted testing includes both robust and limited scripted testing.

1: Robust scripted testing

This method of testing emphasizes ensuring that the testing process is not only thorough but also capable of being repeated consistently, traces back to defined requirements, and can be audited for transparency and accountability. The focus is on establishing a strong and reliable testing framework that contributes to the overall quality and reliability of the computer system or automation under examination. The test script should contain the following at a minimum:

  • test objectives
  • test cases (step-by-step procedure) ·
  • expected results
  • independent review and approval of test cases

2: Limited scripted testing

This method of testing customizes the testing strategy based on the risk profile, utilizing scripted testing for high-risk features or operations, while employing unscripted testing for low- to medium-risk elements. The goal is to create a balanced assurance effort that addresses varying levels of risk within the computer system or automation, optimizing testing resources accordingly. The test script should contain the following at a minimum:

  • test cases (step-by step procedure) identified
  • expected results for the test cases
  • Identification of the unscripted testing applied
  • independent review and approval of test plan

Leverage Technological Advances For Automated Traceability Testing

The guidance acknowledges the advancements in digital technology, advocating for electronic records over manual or paper-based documentation for efficiency. Delve into the meticulous documentation requirements outlined in the draft guidance. Discover how advances in digital technology can streamline the documentation process. Explore the FDA’s recommendation to leverage automated traceability testing and electronic records, reducing reliance on manual or paper-based documentation.

Embrace A Risk-Based Approach

The FDA’s draft guidance on computer software assurance is a call for a risk-based approach to instill confidence in automation used for production or quality systems. The four-step approach involves identifying the intended use, determining a risk-based strategy, selecting appropriate assurance activities, and establishing a comprehensive record. The guidance also invited manufacturers to actively engage, provide comments, and seek clarity on this transformative document that aims to harmonize technology and regulatory expectations in the ever-evolving medical device industry.

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

Key Takeaways From The Draft Guidance

  • Is the draft guidance only for medical device companies that use software as a part of medical device production? No, it also applies to any other software applications. This draft guidance was prepared by the CDRH, CBER in consultation with CDER, Office of Combination Products, and Office of Regulatory Affairs. Specifically, this draft guidance provides recommendations regarding the requirements outlined in 21 CFR 820.70(i).5
  • This will supersede Section 6, “Validation of Automated Process Equipment and Quality System Software”, of the FDA’s software validation guidance, but it doesn’t replace “General Principles of Software Validation.”
  • Leverage the testing that is already completed by vendors or any testing that was done as part of your SDLC; don’t repeat the testing and always take credit for whatever is already completed.
  • CSA does not replace the existing computer system validation (CSV); instead, CSA is the lean approach of doing CSV by leveraging/using the existing vendor documentation.6
  • Using screenshots to establish the record associated with the assurance activities is not necessary, as you can use any system logs, audit trails, and any other electronic sources of data generated by the system.
  • Regulated companies don’t have to wait until this CSA draft guidance becomes effective; they can start implementing CSA immediately, as per the FDA.

Conclusion

If implemented correctly, CSA has the potential to significantly impact the industry and business operations. It can lead to a substantial return on investments, reducing costs by 50% (in my experiences) and saving both time and resources. Moreover, CSA contributes to enhancing the overall quality process through the application of critical thinking.

This article reflects the author’s viewpoints, opinions, and personal experience, and does not necessarily reflect those of his company or shareholders.

About The Author:

Hemadri Doma is a seasoned life sciences professional with more than nine years of expertise in the pharmaceutical and medical device industry. He is a subject matter expert in computer systems validation (CSV), computer software assurance (CSA), data integrity, equipment validation, process automation, artificial intelligence, pattern recognition techniques, and facilities validation. He has served in roles spanning engineering, facilities, information technology (IT), QC laboratory systems, process automation, validation, and quality processes. Doma currently holds the position of QA computer system validation engineer III at Tolmar Inc.

In this blog, we recap our webinar, “Key Systems Engineering Skills: Critical Thinking and Problem Framing” – Click HERE to watch it in its entirety.

Key Systems Engineering Skills: Critical Thinking and Problem Framing

Elevate your team’s success by exploring the role of critical thinking in a system engineering competency model.

In this insightful session, Chris Unger, Retired GE Healthcare Chief Systems Engineering Officer and Principal at PracticalSE LLC, and Vincent Balgos, Director of Medical Device Solutions at Jama Software®, discuss how critical thinking and decision-making skills are integral to systems engineering.

In this insightful session, you will learn:

  • Explore the vital role of critical thinking and decision-making in systems engineering.
  • Learn practical techniques for decision framing and closure.
  • Gain insight on how systems engineers should manage design decisions on a project.
  • See a simple model of how and when to engage with stakeholders in design decisions.

Below is an abbreviated transcript of our webinar.

Chris Unger: We’re going to talk today about a follow-up to the last webinar, where I’m going to talk about some of the most important systems engineering skills, critical thinking, and problem framing. So, how do skills in general, and soft skills, fit into improving systems engineering? So, in prior talks, I’ve suggested you keep your processes very simple but make them effective, and that’s easy to say but hard to do. That means you have to understand the system of the SE processes, how they connect, and where the diminishing value of the processes, the source process heading off, happens. As an example, a topic could be a technical risk, or it could be a trade-off between different possible solutions. So, we want to understand how those to the risk management and the decision process interact.

In order to do that, the best systems engineers have to have really good judgment. In addition, we have to influence people. Being simplistic, hardware and software engineers design things, things do what they’re told. I know it’s oversimplified, but our deliverables are instructions on how the software and hardware engineers do things. So, the best systems engineers here have an area of depth that they’re experts in, so they bring some technical credibility. They have systems of breadth, they understand all the systems processes and how they interact, and they have great interpersonal skills. Today I’m going to focus on how you achieve a balanced and optimized design, how you focus on your cost versus risk, and doing that through basically decision making.

So, first I want to talk about the Helix Model. So, the Helix Project was a project funded by the government and, the US government, and their concern was for big aerospace and NASA projects you tend to produce a major, billion-dollar development every 10 years, and then you do 10 years of support. So, people often move on. They were worried about how you create the truly brilliant leader systems engineers from a team that may be a little bit sparse. They developed this model up here in the front and simplistically, you start with things you learn in school, how to do good mechanical engineering, electrical engineering, and software engineering techniques. You then go into an organization, and so you spend the first five years learning about your company. Things like, well, if you’re going to be doing a say glucose monitor, what does blood chemistry look like? What does a sensor look like? What’s a workflow? So, you become a good organization-specific mechanical engineer.

Then you learn about lifecycle. How do you go from womb to tomb, from customer needs to disposal and disposition with all the regulations across the world in terms of chemical safety? So, after five, maybe 10 years, you understand your domain, you understand the lifecycle and you understand your technology. What differentiates after that? What they found was the skills on the bottom half of this page, the Systems Mindset, so big picture thinking, and paradoxical mindset. You’ve all heard that joke about fast, good and cheap, pick two of the three. Well, that’s the world in which systems engineers live. We make trade-offs between things that are inherently conflicting. The other thing is, we’ve got to make decisions quickly, so you’ve got to have a flexible comfort zone. You’ve got to be willing to wait till you have the critical information but make a decision without all the information you want.

RELATED: A Path to Model-Based Systems Engineering (MBSE) with Jama Connect®

Unger: In terms of the middle column, Interpersonal Skills, just the obvious stuff as I mentioned. You’ve got to influence the other engineers to make a good decision. Then finally here in Technical Leadership, balanced decision-making, and risk-taking. So, I had a general manager one time say, “We’re in the business of managing risks, not avoiding risks.” The least-risk program is also a boring one, but you also don’t want to take moonshots and everything. So, you really want to balance. It’s another case of a paradoxical mindset. Balance risk-taking with hitting a schedule predictably. So, these are the kinds of skills that really differentiate as systems engineering leaders, 10 to 15 years into your career. I’m going to talk more about these, decision-making, stakeholder management, and barrier-breaking.

So, I put together a very simple Systems Engineering Competency Model. I started with the NASA handbook and the NASA lifecycle. I simplified it, into that they had scope and requirements management separated, and I actually agree with those being different. But in reality, on the size of programs that we typically implemented, the people who did one typically did the other. Same thing, the architecture and the design, those were typically the same people. So, you have the upfront design, you have implementation. So, managing the subsystems actually do the implementation of what the design asks them to do, and you integrate it, such that you find your defects early. Then you manage all the lifecycle, the serviceability, manufacturability, disposability, and all the “ilities.”

Then leadership, obviously, there the interpersonal skills. This was developed for GE Healthcare, so I just picked it from our existing leadership skillset and I simplified it. What you’ll notice here is I put down at the bottom, critical thinking, as a technical skill. For many executives, and for other functional engineers, critical thinking is important, but as I mentioned, since we deliver instructions and designs to other engineers, framing decisions, taking vague things from product management and marketing, and turning them into clearer problems or functions to solve, I consider that a core technical excellence of systems engineering. But that’s vague. How do I actually measure that? So, I came up with this fairly simple set of observable behaviors. So, first of all, framing problems takes an ambiguous problem identifies the critical stakeholders, and turns them into a clear problem a more junior engineer can solve.

So, first, let’s talk about framing the problem. Even an entry-level person has to be able to understand a problem that’s been framed for them. But as you get to more senior people, the 10 to 15-year level, you have to be able to frame a complex problem, see around corners, use foresight to sort out essentials from the detail, and identify risks and emergent behavior that need to be incorporated in the decision, that other engineers might not see. Even at the strategist level, you can take a complex and ambiguous problem clarify the ambiguity, and turn it into simply just a complex and interconnected problem.

So, if we’re talking about maybe the 10 to 15-year-old person, not the most senior executives, you’ll be able to take a complex problem, identify ahead of time problems other people don’t see, and capture that. Balance cost, schedule, technical risk, and team capabilities, and make a trade-off based on sound evidence and data. Balance your intuition, when you don’t have all the data with waiting and gathering data where you need it. Then finally, making the decision is maybe the easy part. You have to make sure the team follows your leadership. Take accountability for making the right decisions, delegate where you can, and then ensure that the entire team buys into the decisions that the team or you have made. So, that’s the theory.

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

Unger: Let’s talk about how we manage design decisions. First of all, why? Why is this a critical skill? By identifying the critical design decisions, it allows the team to focus on the most important thing, and separate out the core from the distractions. It helps teams identify work items. So, for example, one time when I was working with the ultrasound team in Japan, we had a bunch of really experienced engineers and they were working on a new ultrasound probe. It had moved an active component into the probe and there was a thermal issue. They were talking in Japanese for about five, 10 minutes when I was asked to frame the problem and I said, “Yeah, you’re talking too fast and too much. This is not that easy. Come back to me and tell me what you’re actually doing.”

They were figuring out how to measure the thermal properties in the lab. I said, “Well, imagine you had a probe that was safe, with maybe 39°C, but that was uncomfortable to handle. Have you worked with the application people on how much value? If you spent $50 more and took the temperature down by 1°C, would that be worth a trade-off? The team, “Oh, that’s interesting.” They were actually focused on the technical feasibility, not the real market and customer acceptance problem. So, by doing this upfront, you can make sure that you have a complete work process for the team. Then once you’ve made the decision, it minimizes rework by making sure the decisions stay closed.

Now, this decision list and prioritization should start early. It would be comfortable to wait until you know everything, but that’s too late. So, it’s a living document. Don’t wait to get started until you have enough information to make a good plan. Start with what you know, and then build out as you continue. So, one of the first things I talk about is, what is a decision? As an example, I’ve had teams come to me saying, “The operating system selection is a decision.” It’s like, “No. It’s actually not typical. It’s typically a collection of decisions.” So, I draw this little arrow here. It’s basically a decision is a point in which you select between different paths going forward and you pick one way versus another. So, deciding whether to include a stretch item in scope or not is a decision. Deciding between very specific designs and implementing a feature is a decision. Setting a critical to-quality parameter or balancing between different parameters, so cost versus reliability or cost versus performance, is a decision.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Key Systems Engineering Skills: Critical Thinking and Problem Framing

Jama Connect® Features in Five: Jira Integration

Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of the powerful features in Jama Connect®… in about five minutes.

In this Features in Five Integration Series video, Mario Maldari – Director, Solutions Architecture at Jama Software® – will demonstrate the Jama Connect® to Jira® integration.


VIDEO TRANSCRIPT

Mario Maldari: Hello and welcome to the Features in Five Integration Series. My name is Mario Maldari and I’m the Director of Solution Architecture here at Jama Software. Today, we’ll be walking through the Jama Connect to Jira integration. We make it possible for you to integrate Jama Connect with preferred best-of-breed software to achieve Live Traceability™ across the end-to-end development cycle. Live requirements traceability is the ability for any engineer at any time to see the most up-to-date and complete upstream and downstream information for any requirement, no matter the stage of systems development or how many siloed tools and teams it spans. This 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. Let’s get started.

The Jama Connect to Jira integration allows for bidirectional synchronization of data between requirements and tasks. This allows for teams such as software developers to stay in their tool of choice and enjoy the benefit of real-time updates between the two applications. Today, we’ll be covering two core use cases for the integration. We’ll be creating a defect in Jama Connect that will synchronize to Jira, and then we’ll be creating an epic in Jira that’ll synchronize over to Jama Connect. Let’s start by executing a test case at Jama Connect’s Test Center. Let’s start our test run here and we can go through and pass or fail steps accordingly. We get to an issue, we can log a defect right from the test, and we can set things like priority. Go ahead and save that defect. And we can go ahead and save and close this test.

RELATED: How to Achieve Live Traceability™ with Jira® for Software Development Teams

Maldari: Then we can open up the test record here and we can take a look at the relationships. And as expected, we will see a link to a downstream defect that we just created. Let’s take a look and open up that defect. And we can see there’s an integration URL to the corresponding defect over in Jira that was just created. And as a developer, I can see a new defect came in and I can start to work on this defect. I can also change things like priority. I can also add a comment. Any field that’s set up to participate in the integration, such as name, description, comments, priority, all of these things can be modified from Jira and that will be synchronized over into Jama Connect. And now you’ll see that there’s a Jama Connect URL here, and this will take us back to the defect that we just created in Jama Connect.

And we can see that the priority has been set below. We can see that there’s a comment that’s been added to add an attachment, and we can actually go ahead and add an attachment here, a picture of our cracked camera. And we’ll attach that to the item. So conversely, anything in Jama Connect that’s participating in the integration, any field, name, description, priority, all of these changes from the Jama Connect side will also be reflected over on the Jira side. And so if we navigate back over into the Jira defect, we’ll do that by following this URL here, we can see that our attachment came over onto the Jira defect.

Similarly, if we’re in Jira now, we’re working and we want to create an epic, we can go ahead and create an epic. Usability improvement, we can go ahead and create that. And then let’s take a look at that epic that we just created here. Similar to the defect scenario, any field that’s set up and configured in the integration will synchronize between the two applications, and that includes the name, description again, comments, and priority. Any field that’s configured will sync over. Then if I refresh this epic that I just created, you can see now that there’s a Jama Connect URL to the correspondent epic that’s just been created in Jama Connect. So I can go here into Jama Connect and I can add things like tables and further elaborate the description, and ask the development team to fill out the table for me.

RELATED: FORT Robotics Selects Jama Connect® to Replace Google Sheets for Product Development

Maldari: But more importantly, what I can do is start to establish traceability within Jama Connect now. Assuming maybe this usability improvement request came from a particular customer, I can link it to an upstream requirement, or initiative, in this case, usability improvement from the customer. And so I can start to establish traceability now, now that it’s in Jama Connect. All the work is being done in Jira on this epic, but the traceability is being established within Jama Connect. So I’m always getting the latest changes over from the Jira side participating in my traceability within Jama Connect. Let’s take a look back over to the epic in Jira, and we can see the table that I just added from Jama Connect showing up here. You can even see that there’s now an upstream link reference that gives me a reference to the traceability that I just created on the Jama Connect side.

So as you can see, the integration allows teams such as software developers to work in Jira while allowing for real-time status updates to flow over to Jama Connect and be reflected in various traceability views. This way, teams are guaranteed to have the latest status on their projects. Thank you for watching this Future in Five session on the Jira integration for Jama Connect. If you’re an existing customer and want to learn more, please reach out to your customer success manager or consultant. If you’re not yet a client, please go to our website at jamasoftware.com to learn more about the platform and how we can help optimize your development process.

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

The ‘Square Root’-Process Model for System Engineering

In the rapidly evolving field of systems engineering, the traditional V-model has served as the cornerstone for development, defining system requirements and verification processes. However, the demands of modern engineering necessitate an extension of the V-Model to reduce time-to-market and elevate customer satisfaction. This article introduces the ‘square root’ model that extends the V-model that embeds continuous feedback and integration throughout the product lifecycle. By considering production, operation, support, and end-of-life sustainability from inception, the ‘square root’ model, visually represented in the accompanying diagram, ensures that engineering efforts align with practical constraints and market needs.

Leveraging Jama Connect®‘s advanced features, we will explore how this model fosters collaboration, efficiency, and strategic foresight, setting a new standard for systems engineering excellence.

Throughout this article, when ‘product’ is mentioned, understand that it can also refer to a service, software, or system.


There are aspects in engineering and feedback loops that the V-model implies to improve the engineering assets (mainly Verification and Validation focused) at the same information abstraction level; This article will describe the need to extend the traditional V-model to ensure the estimated time-to-market can be met with ease, customer satisfaction improves each product iteration and create a better tomorrow, using Jama Connect unique features to support your engineering teams to achieve these results.

Where the traditional V-model, starting at ‘Stakeholder Requirements’ and ending at ‘Acceptance Tests’ (or ‘Validation’), describes the engineering’s team involvement in the product being engineered, it is important to understand that this is only a small part in the entire lifecycle of a product. It’s the repeatable part for that product’s new releases and it’s the part that can be used to analyze the impact of changes before that change gets implemented in production.

RELATED: A Path to Model-Based Systems Engineering (MBSE) with Jama Connect®

Design Constraints

The word “constraint” has a negative connotation; Design constraints are limitations on what designers can do with a design. These limitations are usually byproducts of having deadlines, budgets, brand guidelines (and similar guidelines, see below), laws and regulations, finite resources, and limited decision power in terms of tools and processes.

Some product engineers view design constraints in a bad light because they feel like they’re being boxed in by a brick wall, while others embrace design constraints as directional guidelines that open the doors to creativity and strategic problem-solving.

On the surface, having design constraints can indeed feel like a bad thing; however, they can be extremely useful. Being limited to certain choices doesn’t necessarily mean being limited to certain outcomes. Often enough there are alternative options that are, at least, almost as good as what you originally envisioned.

Design constraints can come from various sources, in this article we’ll talk about the constraints that focus on time-to-market, customer satisfaction, and zero waste. In other words, design guidelines come from:

  • Production;
  • Operation and Support;
  • (Ecological) Sustainability; the recycling of your product’s used materials.

These design constraints facilitate engineering with the end in mind. Your team’s early decisions during product definition must include upgradability, serviceability, and for sure: disposal, and sustainability.

Please Note: As these are complex topics by themself and not part of the core business of Jama Software, this article will only emphasize the need for feedback from these product lifecycle phases into the product definition as design constraints. Design constraints might also be known and used as Non-functional Requirements (i.e., the different ‘-bilities’, like producibility, serviceability, etc.)

Production and Manufacturing

When production and manufacturing aren’t involved from the start, your engineering team might waste valuable engineering time and effort on a product that cannot be manufactured with the means your production facilities have at their disposal. This means that the product’s entire time-to-market will need to be extended to re-engineer the product to your current production capabilities; wasting precious time and putting your competitive edge at an unnecessary risk.

As an example, a Printed Circuit Board (PCB) might require that a set of components must be aligned in the same direction and at a specified distance when wave soldered to avoid short-circuits in operation. These wave soldering characteristics can be recorded and maintained in Jama Connect as Design Constraints. Source: https://www.mclpcb.com/blog/wave-soldering-issues/

The other side of this same coin; By knowing what your production facilities can and cannot do at the start of the product definition, your teams are capable of estimating when the new bleeding-/leading-edge product they are developing needs new production means.

These insights, when considered at the beginning of the product definition, will allow your teams to research, develop, and implement the required new production techniques and have them ready when the product hits the factory shop floor. This includes having purchasing ready with new suppliers, their delivery times, required stock levels, and other input required for your factory shop floor to hit the ground running producing your new product when it completes its V-cycle.

Operation and Support

The full value of a system or product is realized in its use and operation during the expected product lifespan. Your customers want to receive a product that meets their expectations, but those expectations extend beyond a product that works on day one. Customer Satisfaction, and thus Customer Lifetime Value, is heavily influenced by the ease and availability of maintenance, servicing, and upgrades that will extend the product’s lifespan. When a customer calculates Return on Investment (ROI), they are not only considering receiving a working product, but they are also factoring in;

  • Mean Time Between Failures (MTBF, a metric for failures in repairable systems);
  • Mean Time to Failure (MTTF, a failures that require system replacement);
  • Mean Time to Repair/Recovery/Respond/Resolve (MTTR, is the average time it takes to repair/recover/respond/resolve a failure in a product, service or system, usually technical or mechanical. It includes both the repair time and any testing time. The clock doesn’t stop on this metric until the system is fully functional again); and
  • Mean Time to Acknowledge (MTTA, a metric useful for tracking your team’s responsiveness and your alert system’s effectiveness).

Reliability represent a series of metrics designed to help customers understand how often incidents occur and how quickly they, in collaboration with your Operation and Support, bounces back from those incidents. Valuable indicators to determine if their investment, and any additional investment to keep it operational, is effective.

Analysis of these reliability, MBTF, MTTF, MTTR and MTTA metrics focused on means to reduce these indicators, lead to product enhancements that improve customer satisfaction for both users (better uptime, improved performance, etc.) and decision makers (value on their investment).

E.g., the accessibility of a repairable component, to improve the MBTF, can be recorded and maintained in Jama Connect as a design constraint.

Sustainability

For sustainability, it all starts with the design. The design decisions for the product contribute 80% to the carbon footprint of the solution! How to make your products and systems ‘green’ from the start, a topic most companies struggle with.

Once your teams start to include sustainability in your product’s mission, you’ll need a structured approach, as several factors will push for different considerations. The most obvious considerations are the choice of materials and the optimizing the production process (reducing carbon emissions).

However, the repairability/serviceability of the product should be considered with a more extended lifetime vision, just like upgradeability and reusing components.

Techniques like Lifecycle Analysis (LCA, shows how much influence a product has on the environment during its entire life cycle: from raw material extraction to waste processing) exist to determine the Design Constraints necessary for the sustainability of the product being developed.

The (material) considerations that come out of an LCA (e.g. switch from fossil fuels to hydrogen) can be recorded and maintained in Jama Connect as a design constraints.

Jama Connect supports the ‘square root’-model

Collaborate with stakeholders from Production, Operation & Support and Environment, Health & Safety

Recording design constraints is not unique to a (Requirements Management, or Product Definition) application like Jama Connect; The ability to collaborate with colleagues in reviews, from the respective product lifecycle phases that normally don’t have to deal with the product definition phase (and thus don’t work in Jama Connect) is unique.

This unique feature allows your teams to engineer your products with the end result in mind, by involving the stakeholders from beyond their own engineering reach, to collaborate and achieve the optimum time-to-market, best customer satisfaction and create a better tomorrow for ourselves and future generations.

These stakeholders don’t require to be Jama Connect users to be invited and collaborate in a review within Jama Connect. Involving those stakeholders into the review process allows these stakeholders to verify their design constraints are adequately and sufficiently addressed by the requirements of your product definition.

RELATED: The Benefits of Jama Connect®: Supercharge Your Systems Development and Engineering Process

First step in sustainability; reuse as much as possible

Not only does reusing and synchronizing requirements reduce your time-to-market and improve quality, but it is also a key strategy for getting your products sustainable. Jama Connect can help reducing the struggle to build on existing work when requirements, and their corresponding test cases, are spread across documents and systems, missing Live Traceability™. Your teams must manually identify and copy related content increasing the risk of rework and gaps. Additionally, teams tend to lack visibility across efforts, causing necessary changes to not propagate across reused content, potentially impacting quality and disconnected product design efforts.

Jama Connect simplifies and enhances the process of reusing requirements and verifications by allowing you to copy selected content with its container and its traced items. Synchronization ensures visibility and enables key use cases such as parallel product definitions, common content libraries (i.e. reusable component libraries) and product variants.

Further reading
  • INCOSE (International Council on Systems Engineering): INCOSE is a professional organization dedicated to promoting and advancing the field of systems engineering. Their website (www.incose.org) offers a wealth of resources, including publications, articles, and conferences, that cover various topics in systems engineering, including the V-Model.
Other sources used

SOC2 Type2

Streamlining SOC2 Type 2 Compliance: How Jama Connect® Can Help Enable Audit Success

In today’s business landscape, technology and data play a crucial role. Therefore, it is of utmost importance to prioritize the security and privacy of sensitive information. One way to do this is by undergoing a SOC2 Type 2 audit.

A SOC2 audit provides an independent, third-party validation that a service organization’s information security practices meet industry standards stipulated by the AICPA (American Institute of Certified Public Accountants.) During the audit process, a service organization’s non-financial reporting controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system are tested.

This audit provides customers and partners with trust and assurance regarding an organization’s data security practices. It also helps businesses in regulated industries meet compliance requirements, manage risks by identifying and mitigating security threats, and gain a competitive edge by demonstrating a strong commitment to security. Furthermore, it can drive internal improvements by enhancing policies and procedures related to data protection.

Jama Software® is the only vendor in the requirements management and traceability space that is SOC2 Type 2 compliant both on the application layer and the data center offerings. In this blog post, we’ve invited Jama Software team members Sarah Voget – Team Lead, Project Manager, Jennifer Esposti – Project Manager, and Cooper Graham – Compliance Analyst, to detail their experiences preparing for and passing the SOC2 Type 2 audit and how they will use Jama Connect® to improve future audits.

Preparing for the audit process

Tell us about your experience with SOC2 audits in the past. What tools have you used at other companies? What were some of the challenges or drawbacks to those solutions?

Sarah Voget: The biggest challenge I ran into at previous companies was that no one tool could easily compile and track evidence for recurring audits. Passing an audit requires a company to compile substantial evidence from a variety of sources in a variety of formats. For example, we upload free text answers from subject matter experts (SMEs) to specific audit questions along with supporting screenshots, policy documents, PDF reports, etc. While tools like OneDrive or Excel could keep such information somewhat organized, it was incredibly difficult to have a holistic picture of audit evidence over time. Each year during audit prep, I felt like I had to reinvent the wheel by tracking down audit evidence from a variety of systems and SMEs all over again.

Tell us how you came up with the idea of using Jama Connect® for SOC2 compliance.

Voget: When I first joined Jama Software, I attended an internal presentation about Jama Connect, where I learned about our product’s strength in end-to-end requirements tracking. A lightbulb went off in my head because that’s really what audit prep is all about. An audit is like a list of requirements that we must prove we’re meeting, and each year, we reevaluate our effectiveness at meeting those requirements. It’s critical for us to understand how we met certain requirements in the past and to continuously iterate on our security policies and procedures as they relate to those requirements. Once I made that connection, I realized the potential power of Jama Connect as an internal audit preparation and readiness tool.

Can you provide any information about how you formatted Jama Connect initially to prepare for the audit?

Voget: My first attempt at using Jama Connect for audit prep focused on the big problem I mentioned earlier: compiling huge amounts of evidence in one place where I could easily access it over time.

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

Lessons for future audits

Taking lessons from the first SOC2 audit using Jama Connect – what did you think could be improved on? What were the wins?

Jennifer Esposti: For the initial audit, Jama Connect was used primarily as a content management tool, which allowed us to organize and document the required evidence. This year, we wanted to expand our use to include the monthly, quarterly, and annual maintenance we do as a cross-functional team to ensure we are maintaining the necessary processes for SOC2 compliance.

Cooper Graham: In the first year run-through, we stored some critical information, such as the trust criteria and some information around the auditor questions and requests and our responses in Jama Connect, which limited those resources to those involved in the audit. The primary win was seeing the potential of the Jama Connect application for managing and tracking our SOC2 preparation. Having a foundation in the application that we could build on year-to-year rather than starting from scratch for each year’s preparation. Using additional features and elements in the Jama Connect application for collaboration and organization of our preparation.

What changes have you made from the initial SOC2 audit?

Esposti: From a project management perspective, I use the test management functionality within Jama Connect to organize the monthly, quarterly, and annual check-ins. The test cases provide a clear and consistent process for the project team to follow.

Graham: Using the test management functionality, we were able to organize and track recurring check-ins to ensure we were prepared for the upcoming audit. We were able to document more specific questions and responses that were provided during the previous audit to have a better understanding of the auditor’s asks and wants. It also gives our subject matter and individuals involved in the audit the ability to see what was previously asked to prepare for the upcoming audit.

How is Jama Connect well suited to help teams prove SOC2 compliance?

Graham: As a requirements management product, the ability to identify the requirements, track the associated testing, and include evidence or links to key artifact locations really assists in the organization for the audit and ensures nothing slips through the cracks.

How are you leveraging features in Jama Connect for this year’s audit and beyond?

Esposti: My focus this year is on using the test management functionality to organize our evidence and ensure we are performing the required tasks on a monthly, quarterly, and annual basis. For future audits, I’d like to explore ways we can use Jama Connect to track our progress year-over-year.

Graham: We are utilizing Jama Connect’s Test Management functionality in a new way this year. The ability to organize monthly, quarterly, and annual check-ins and create test plans associated with specific teams ensures that all of the pre-audit due diligence is performed. The ability to create test cases that can be reused ensures consistency for every check-in. Having everything laid out in Jama Connect allows us to identify gaps and potential improvements to test cases and collaborate more effectively with key stakeholders. In the future, we plan to use Live Traceability™ to have a better view of the SOC2 process, from requirements to testing to end results. As the Jama Connect application goes through its releases, new features and functionality are being continuously added. We’re constantly looking to see if there are new elements that would aid us in preparation for future SOC2 audits.

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

CONCLUSION

Meeting SOC 2 Type 2 requirements requires careful attention to detail and strong management of organizational processes. A comprehensive solution like Jama Connect can greatly assist teams in navigating this complex terrain. By centralizing and automating requirement management, Jama Connect ensures traceability, transparency, and accountability throughout the development process. Its collaborative features facilitate efficient communication and documentation, which are crucial for meeting SOC 2 Type 2 standards.

Using Jama Connect, engineering organizations can now intelligently manage the development process by leveraging Live Traceability™ across best-of-breed tools to measurably improve outcomes.

Live Traceability enables organizations to meet SOC2 Type 2 standards by effectively tracking data and processes within their systems. By utilizing Live Traceability, companies can demonstrate their compliance with SOC2 Type 2 standards through well-documented information and audit trails. This promotes transparency and accountability. Staying updated with the latest SOC2 Type 2 standards is crucial for maintaining secure operations and reducing risks. Jama Connect remains current by regularly updating its platform to adhere to the latest SOC2 Type 2 standards, ensuring companies remain compliant and secure.

 

 

 

 

 

 

 

 

 

The Seven Steps to Performing FMEA

Welcome to this deep dive into the world of FMEA

Failure Mode and Effects Analysis (FMEA) is a powerful tool used in various industries to identify and mitigate potential failures in a process, product, or system. In this blog, we will take a detailed look at the seven steps involved in performing an FMEA.

RELATED: Jama Connect® FMEA Framework for Automotive

1: Define the scope and team.

  • Clearly define the boundaries of the process, product, or system you are analyzing, assemble a multidisciplinary team consisting of experts from different areas to ensure a comprehensive analysis.

2: Break down the process.

  • Divide the process into manageable steps or components. This helps to identify potential failure modes at each stage.

3: Identify potential failure modes.

  • Brainstorm all potential failure modes for each process step. These are the ways in which the process or component could fail to perform its intended function.

4: Assess the severity.

  • Assign a severity rating to each failure mode based on its potential impact on the customer, product, or process. This helps prioritize which failure modes require immediate attention.

5: Determine the causes.

  • Identify the root causes or factors contributing to each failure mode. This requires conducting thorough analysis and gathering relevant data.

6: Evaluate the current detection controls.

  • Assess the effectiveness of the current controls in place to detect or prevent failure modes from occurring. Identify any gaps or weaknesses that need to be addressed.

7: Calculate the risk priority number RPM.

  • The RPM is a numerical score obtained by multiplying severity, occurrence, and detection ratings. This allows you to prioritize which failure modes require immediate action

RELATED: FMEA Framework for Medical Device Development

By following these seven steps, you can perform a comprehensive FMEA and proactively identify and mitigate potential failures or risks in your process, product, or system. Remember, FMEA is an iterative process that requires continuous improvement. Regularly review and update your analysis as new information becomes available and track the effectiveness of your implemented actions. Thank you for diving deep into the seven steps of performing FMEA. Now you have a better understanding of how to apply this critical process in your industry.

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Karrie Sundbom, McKenzie Jonsson, and Decoteau Wilkerson.

This image displays the title of this blog, focused on Secure by Design for medical device.

Secure by Design: A Crucial Imperative for Medical Device Teams

In today’s healthcare landscape, technology plays a crucial role in patient care. Medical devices have become essential for monitoring vital signs and administering treatments. However, as these devices become more connected and complex, ensuring their security is now more important than ever. This is where the concept of “Secure by Design” comes in, serving as a fundamental principle for medical device teams to navigate the intricate world of healthcare technology. Which begs the question, with the rise in security concerns, do regulations now need to consider whether each device is safe, effective, and secure?

Understanding the Landscape

Medical devices have advanced beyond being simple, independent systems. With the rise of the Internet of Things (IoT), devices are now interconnected, allowing for the exchange of data. While this connectivity has many advantages, it also opens vulnerabilities that could be exploited by malicious entities.

Cybersecurity threats not only put patient data at risk, but also the health of those who rely on these devices. It’s also a costly and time-consuming process for medical device companies to manage, and resolve. According to IBM Security analysis of research data compiled by Ponemon Institute, 83% of organizations have had more than one security breach, and the average cost of each breach averaged $4.3 million globally. That number more than doubles for the average cost of a security breach in the United States – $9.44 million – the highest in the world.

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

The Essence of Secure by Design

Secure by Design is a proactive approach that prioritizes security in the development process. Rather than treating security as an afterthought, it is integrated into the design and development phases. For medical device teams, this means implementing security measures from the start of a project, considering potential threats and vulnerabilities, and implementing safeguards to reduce risks.

Key Principles of Secure by Design:

  • Risk Assessment: Before beginning development, medical device teams must conduct a thorough risk assessment. This involves identifying potential threats, understanding vulnerabilities, and evaluating the potential impact of security breaches on patients and healthcare providers.
  • Data Encryption: Due to the sensitive nature of healthcare data, encryption is a crucial aspect of secure design. Implementing strong encryption protocols ensures that patient information remains confidential and secure during transmission and storage.
  • Access Control: Limiting access to medical devices is crucial. Secure by Design stresses the importance of implementing strict access controls, ensuring that only authorized personnel can interact with the device. This prevents unauthorized users from tampering with critical settings or accessing sensitive patient data.
  • Regular Software Updates: Vulnerabilities in software can leave devices vulnerable to cyber threats. It is essential for medical device teams to prioritize regular software updates and patches to address potential security risks. This ensures that devices can withstand evolving cyber threats.
  • User Education: Even the most secure devices can be compromised if users are not vigilant. Secure by Design also includes educating end-users on cybersecurity best practices. This ensures that individuals using medical devices are aware of potential risks and take necessary precautions.

Regulatory Landscape and Compliance

The healthcare industry must comply with strict regulations to protect the well-being of patients. Regulatory agencies, such as the Food and Drug Administration (FDA), acknowledge the significance of cybersecurity in medical devices. Following regulatory guidelines is not only a legal obligation, but also a dedication to ensuring the utmost safety and security for patients.

Challenges and Solutions

Implementing Secure by Design in the development of medical devices can be challenging. Balancing the need for innovation with strict security measures is complex. Additionally, the ever-changing landscape of cybersecurity threats requires constant attention.

Solutions:

  • Collaboration and Training: It is crucial to foster collaboration between cybersecurity experts and medical device developers. Ongoing training for the development team ensures they are informed about the latest security threats and mitigation strategies.
  • Third-Party Security Assessment: Engaging third-party security experts to regularly assess medical devices can provide an unbiased perspective on their security. This external validation can uncover blind spots that internal teams may miss.
  • Incident Response Planning: Despite preventative measures, security incidents can still occur. A robust incident response plan allows medical device teams to promptly and effectively address breaches, minimizing their impact on patients and healthcare providers.

RELATED: The Complete Guide to ISO 13485 for Medical Devices

The Future of Medical Device Security

As technology continues to advance, the healthcare industry is constantly evolving. Medical device teams must be proactive in anticipating and addressing potential security challenges to stay ahead of the curve. Secure by Design is not a one-time effort, but an ongoing commitment to the safety and well-being of patients.

It is not just best practice, but a moral imperative for medical device teams to integrate security into the DNA of their development process. By doing so, they contribute to a safer and more resilient healthcare ecosystem. The future of healthcare relies on innovation, connectivity, and security, and it is the responsibility of medical device teams to ensure that these pillars remain strong.

Jama Connect® for Medical Device Development

Jama Connect for Medical Device Development helps medical device teams reduce the effort required to achieve regulatory compliance throughout the development process. With this solution, medical device teams can manage design controls for device requirements and related risks, simplifying regulatory submissions and audit preparations while accelerating time to market. Learn more: Solution Overview: Jama Connect Solution for Medical Device Development

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by [Vincent Balgos, McKenzie Jonsson, and Decoteau Wilkerson].

This image depicts our Jama Connect Features in Five video series.

Jama Connect®‘s Features in Five Series:
Your Guide to Streamlining Product Development

Learn how you can supercharge your systems development process! In our Features in Five video series, we pull back the curtains to give you a look at a few of the powerful features in Jama Connect®… in under five minutes.

Topics from this series include:

In this blog, we’ll showcase a selection of topics from our Jama Connect® Features in Five video series, plus preview our upcoming integration video series.

Live Traceabilty™

Would you like to see the most up-to-date and complete upstream and downstream information for any requirement—no matter the stage of systems development or how many siloed tools and teams it spans?

Live Traceability™ in Jama Connect enables you to do just that! Now you can manage requirements with complete traceability across the end-to-end systems development process for proven reduction in cycle time and improved product quality.

This enables the engineering process to be managed through data, and its performance improved in real time; dramatically reducing the risk of product delays, cost overruns, defects, rework, and recalls; and ultimately resulting in faster time to market.

In this video, we demonstrate how Jama Connect helps teams integrate with preferred best-of-breed tools to achieve Live Traceabilty™ across the end-to-end development cycle.

RELATED: The Essential Guide to Requirements Management and Traceability

Reuse & Sync

Struggling with scattered requirements and disconnected systems?

Teams often struggle to build on existing work when requirements and tests are spread across documents and systems. Lacking a live trace, they must manually identify and copy related content, increasing the risk of rework and gaps. Additionally, teams tend to lack visibility across efforts, causing necessary changes to not propagate across reuse content, potentially impacting quality and disconnecting product design efforts.

Jama Connect simplifies and enhances the process of reusing requirements and verifications by allowing you to copy selected content with its containers and its traced items. Synchronization ensures visibility and enables key use cases such as parallel product definition, common content libraries, and product variance.

In this video, we explain how your team can reduce time to market and improve quality by reusing and synchronizing requirements and other content in Jama Connect.

Review Center

Are complex review processes bogging down your development process?

Reviews play a key role in successful product development. Jama Connect’s Review Center streamlines the review process, saving valuable time and making reviews across teams and various stakeholders seamless! In this video, you will learn how to initiate a review, how to invite participants to a review, how users can complete tasks, provide feedback, and finish a review. You also see how moderators can view review activity, interact with feedback, publish revisions, compare review versions, and more.

In this video, we demonstrate a powerful and easy-to-use feature in Jama Connect, the Review Center.

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

Jama Connect Features in Five: Integrations Series

The #1 problem product engineering organizations face is complying with traceability requirements spanning siloed teams and tools. Jama Connect helps teams solve this by offering integrations with various other applications and tools via Jama Connect Interchange™ as well as Jira, Excel, Cameo, and more.

We are excited to announce our upcoming eight-part Jama Connect Features in Five integration video series demonstrating the best-of-breed tools that plug into Jama Connect for Live Traceability!

Integrations shown in this series will include:

  • Jira
  • Excel for Risk Management
  • GitHub
  • API Integration for Automated Tests
  • Test Rail
  • Cameo
  • Azure Dev Ops
  • Enterprise Architect

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

This image portrays an event showcasing pioneering excelling in healthcare.

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

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

The following is the transcript of a Q&A session from this event. Please note that the answers were given verbally and may not be exactly as recorded. Some changes have been made for clarity.

“What are some insights for product development teams to consider when keeping up with the speed of innovation?”

Chris Unger: Separate out research (from development), and spend certain time on long lead items. Typically, our programs are 6 to 18 months. And so, if there is basic research that takes more time, make sure you have a certain amount of your budget – 5, 10% – with risk retiring the initial basic piece of the work, and the handoff between research and [development] programs in where we think we can retire the remaining risks in the 12 months. And then the rest of it has to really focus on what is really core. Eating the elephant one bite at a time. Focus on what’s really innovative. But one of my general managers said, ‘You want your product development to be a wall. Big, small, small, big, small.’ Product development should be a phased approach where you work on various scoped tasks. Focus on the high-risk and most innovative stuff. Low-hanging fruit can wait. Spend the time really on the breakthrough, and then maybe every six months for the next year just do small iterations, maybe some covers, maybe some better user interface and workflow, while you’re buying time for the next major innovation to come through. So, portfolio management.

Bijan Elahi: With respect to risk management, innovation in new technologies is useful for reducing risk to medical devices. You may have seen the definition of “state of the art” in the latest edition of ISO 14971 Standard, which says that the manufacturers are required to consider the consolidated findings of technology research practice to incorporate into the medical devices to reduce risks as much as possible. However, it also says that the latest technology state of the art is not necessarily the latest technology [from all industries]. And medical devices, we are a little slower than other industries like semiconductors. So, for us, state of the art must be generally considered good practice, and then innovations that are proven and accessible to be used to reduce risk.

Chris Unger: The other comment I might make is one of the reasons you slow down is scope creep. For every function, every person is like, “I just need my one. It’s just small.” It’s the straw that breaks the camel’s back. And one of our most successful businesses, the ultrasound team, said that time to market and this time blocks delivery was a team effort. Instead of having one person beating away, that all the functions sort of gang up on each other. It’s like, “Well, I didn’t put my extra in.” We’re all committed to delivering this every year, something important every year. And so rather than having the program manager fighting for scope, it’s the team that says, “Look, I’m willing to commit to this limited scope to get something this year, you help me out.” So, make sure it’s the team’s focus on speed to market.

Vincent Balgos: In this post-pandemic event, collaboration can pose a challenge in working remote, hybrid, onsite, especially for systems engineering and risk management where we need to work across the aisle amongst different types of groups.

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

Vincent Balgos: “So my question to maybe Bijan first, is what are some lessons learned that you’d offer to maintain efficiency and progress, that works better than others? And we are a bunch of engineers here, definitely want to talk about technical, but are there any key soft skills that we may also want to consider as well?”

Bijan Elahi: In one of my classes, I teach that you need to cultivate humility and curiosity. So, what do I mean by that? As I said, risk management is a team sport, and humility does not mean self-deprecation, it means to recognize that the answer is not all within you, it’s within your team. And the curiosity part is that some people are just shy about sharing their thoughts. So, curiosity is to seek it. It doesn’t always just come to you. So, this is a soft skill that I can offer you, to cultivate humility and curiosity.

Chris Unger: This is a good advertisement for the February webinar I am hosting with Jama Software. I was going to plan something on requirements writing techniques, which will probably be later in the year. I’d say a couple of things, make sure that you focus on communication. So, in a crisis, a lot of people just focus on getting their work done. And the first thing that you should maintain, a lesson straight off, is making sure you talk to the team, that you get consistency and use simple forms, and keep publicizing. Example like “What are my decisions? What are the important ones?” Just keep over-communicating, it’s something simple in the survival handbook, “Guys, here’s my list of decisions, here’s my list of risks.” Keep it simple, keep it single reference.

And the other thing I do is, don’t use that to communicate, use that to archive your decisions. I get really annoyed when my team says, “I wrote defects in the tool. Of course, they’re going to respond.” Talk to people, call them up, ask them questions. Do they understand? Do they understand why it’s important to do this? Do they accept that it’s their defect? I had one, my first program at my previous employer, we got to each milestone, we had like a hundred open defects. And people came to me complaining, “Well, I got rid of my defects. I fixed 50 of them and I transitioned 50 to every other defect. But it’s not fair Chris, because everybody else transitioned their defects to me last night. How am I supposed to…” But we’re a team. Don’t reassign the defect in the tool and assume they’ll accept it. Talk to them. Say, “I’m going to reassign these five defects to you. Do you agree that they’re yours?” Talk more than use the tool to communicate. I love Jama Connect. I love the risk management aspect, all the risk files. But if you are going to assign a risk mitigation to somebody, talk to them before you assign them.

Vincent Balgos: “What are some market and technology trends you see coming to the industry in 2024?”

Bijan Elahi: The big ones are Artificial Intelligence (AI) and Machine Learning (ML). A lot of medical devices are now deploying technologies that are based on AI and ML. And this has really created the challenge for risk management. In fact, we don’t know how to really completely answer this yet. This is an unanswered question. And the regulatory agencies, ISO experts, they’re all working on this. So, answering this question of how do we manage the risks of a medical device that is constantly changing? With current medical devices, if you want us to make a change to it, you’re supposed to submit something to the FDA. What about a medical device that is changing by the hour? It’s not really possible to keep making submissions. So, this is one of the challenges that’s happening in 2024.

Chris Unger: Yeah, that’s the obvious thing. I was a skeptic. People a long time ago said, “Are you doing AI machine learning?” And I kept responding with “No, it’s not ready. It’s not ready.” It’s ready. It’s coming. It’s now. It’s 2024. I wouldn’t say it’s a 2024 trend, it’s ongoing and continuing in cybersecurity. I mean, all these things are connected. That we want to network. Radiologists want to work remotely. It was a long time ago that somebody talked to us and said, “Look, this is great. I’m the head of a radiology network in northern Jersey. We’ve got five radiologists. And when people come to my clinic, I’ll do a quick read of every scan in my area, but I’m the liver guy. So, all the liver scans get sent to me. And somebody else is the head guy.

But that means a network, which means you’ve got huge network security. So, cybersecurity is just always going to get more and more critical. And we’ve never been liable. We’ve had hospitals come to us saying, somebody’s stuck a USB stick into your system and you let that virus go and it infected their network, but it went through your product. Why didn’t you protect it? And that was a huge malware. Whatever ransomware hospital costs more money than effective fiber is going to be way more effective.

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

Audience Question: “I was curious, looking at your workflows with the dotted lines, I recently debated whether usability engineering should be its own pillar containing risk, containing system requirements or embedded within the existing infrastructure for those. Do you have any pros or cons or suggestions on whether you should look at usability engineering independently as a whole? Or as part of the risk plan system requirements plan?”

Bijan Elahi: Usability engineering is very well integrated into risk management. It is its own discipline, and it has its own standard IEC 62366:2015. But a lot of its work products are very similar to an actual integration with an ISO 14971 workflow. So, I can’t say that it should be independent, but I say integrated with risk management.

Chris Unger: Yeah, I think it’s both and, not either or. As Bijan said, there’s a use analysis report that is mandated. So, it’s its own discipline and it’s part of everything. It’s part of workflow. Remember I said, “Gee, we want, custom things that are easy to use. No training needed, just use it.” And that’s a customer value. It’s part of marketing. Think about reliability. So, if I take this and I drop it… what are the stresses? How do I test this stuff? It’s part of uses. When we did things, it was probably two-thirds of our reliability issues were unexpected use cases. So, we had this baby warmer, and it was in Philadelphia, so they had cobblestone streets, and they were just transporting it from one wing of the hospital to the other, no baby in it. And there was an infrared warmer, it went over it and the interim warmer fell over to where the baby would be. Because it was doing a shake test going over the cobblestone. And we didn’t think about that.

Another case we had a mobile X-Ray. Takes an X-ray system, moves it into the surgery, into the ICU, the recovery room. And it’s a battery… It was probably 600, 700 pounds. Great when you have this big hulking tester and they move it over this expected ramp, something like this was easy to move it over. You get 110-pound nurse in a hospital with a two-centimeter step going into the elevator and guess what? The only way they could get over the ramp was to take a running start and use the momentum. We had wheels falling off. What was that? So, we went to the hospital and watched them. Oh! We expected like 5 Gs and the upper limit (UL) is like 50 Gs or 10 x factor plus 200 Gs. Once we designed for 200 Gs, wheels stopped falling off. So, usability is part of reliability engineering. So, it’s part of everything and it’s used in analysis report.

Audience Question: This is a more general question, but for companies that have two or more variants of a product, what are your recommendations? And this is to both of you about managing both product development and product assets. So, let’s say 90% of the assets are common across three variants and how to handle risk management when the clinical usage of those three variants could be different?

Bijan Elahi: With respect to risk management. EU MDR allows you to do risk management for a family of projects. So, if this is a family that are very similar, you can do a common risk management and then do differential risk management for the differences between them to submit.

Vincent Balgos: I’ll also add that varying management configuration is a hot topic within the medical, especially as you build family of products and then you build your… Let’s say child products off that. How do you reuse and share some of that information for efficient product development? So, this is where Jama Software is really a great, unique opportunity where we’ve actually learned from other industries, particularly in automotive and in terms of how they deal with those different types of variants. So, we’re incorporating some good practices off the bat and again, happy to talk with each of you, especially if there’s specific questions on how to solve some problems.

Audience Question: My question is about integration. I mean we see more and more devices now have the ability to work together with solutions from other vendors. How can we can be prepared for that? I mean sometimes if your product is on the market, and somebody wants to use it and integrate it with a different solution. How can we be prepared for that from both a system engineer design perspective and for risk management?

Chris Unger: System engineering is kind of simple. Keep a configuration compatibility matrix to ensure that this version of your product is compatible with what version. And then really think through the use cases. The rainy day and sunny day. We had cases where our monitoring central station… So, we built some temperature monitors, fetal monitors, cardiac monitors, but we also then built a central station that have to work with our sensors but anybody’s sensors in the world. And we did pretty good with that.

We had a recall where somebody would plug in a… I forget what it was… temperature monitor? But it was a safety-critical device in the intensive care unit, and we didn’t have a fast enough response that it was plugging in. Usability. So, the nurse pulled it out, put it in again, pulled it out, and put it in again. And finally, the system had a race condition. It said you pulled it out, and when they put it in it tried to reset. So, the nurse had thought that it was plugged in it, and it wasn’t. And so, the nurse was assuming that the patient’s heart rate was monitored when it wasn’t, we had to recall the entire product. So have a standard interface. Have a compatibility matrix and test the unusual customer uses.

Bijan Elahi: With respect to risk management, if you’re making a medical device that is supposed to work with other medical devices together, then the together becomes a system. The patient is experiencing the risks that could come from the integration of all the devices that connect with your device. To manage the risk of that, what you need to know is which devices are going to plug into your device and then you test them to make sure that they’re safe together. And then you make a list of approved compatible devices that could be used with your device and your manufacturer makes another device that wants to be used with yours and you must check that too. Just keep expanding your list of approved devices.