Tag Archive for: Product Development & Management

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.

This image depicts a medical professional using the benefits of IEC 62304 implementation.

In this blog, we recap our eBook, “An In-Depth Guide to IEC 62304: Software Lifecycle Processes for Medical Devices” – Download the entire thing HERE.

An In-Depth Guide to IEC 62304: Software Lifecycle Processes for Medical Devices

In the world of modern medicine and healthcare, software plays an integral role in the functionality, monitoring, and management of medical devices. These software components can range from simple interfaces to complex algorithms that drive critical medical decisions.

Ensuring the safety and effectiveness of these software components is of paramount importance, leading to the creation of standards such as IEC 62304, which defines lifecycle requirements for medical device software.

Understanding the Importance of Software in Medical Devices

Medical devices have evolved significantly, integrating software into their core functionality. From pacemakers to diagnostic equipment and even mobile health applications, software contributes to accurate diagnoses, patient monitoring, and treatment delivery. This integration enhances the capabilities of medical devices but also introduces potential risks if not developed and maintained properly.

Overview of IEC 62304

IEC 62304, titled “Medical device software – Software lifecycle processes,” is an international standard that provides a framework for the development of quality medical device software. It establishes standards for managing software development, verification, validation, and maintenance within the context of medical device development.

This eBook delves into IEC 62304, its components, implementation strategies, and benefits, equipping readers with a comprehensive understanding of how to develop medical device software that adheres to rigorous quality and safety standards.

Scope and 2 Application of IEC 62304

What Medical Devices are Covered?

IEC 62304 applies to a wide range of medical devices that incorporate software – software that is a medical device on its own (SaMD) or an integral part of another medical device (SiMD). This includes both standalone software devices and software that is part of a larger medical device. These devices encompass everything from simple mobile health apps to complex medical imaging systems.

Examples include clinical decision support software, manufacturing software used to test the delivery volume of an insulin pump, software used to analyze genetic data, software in pacemaker, etc.

What Types of Software are Included?

The standard encompasses software used for medical device design, development, production, installation, and servicing. This encompasses not only the software that directly interfaces with the patient or provides a medical function but also the supporting software used in manufacturing and quality control.

Key Concepts and Terminology

Software Safety Classes

IEC 62304 introduces a classification system based on the potential harm caused by software failures. The requirements vary depending on the software safety classification There are three classes:

  • Class A: No injury or damage
  • Class B: Non-serious injury
  • Class C: Serious injury

These classes help determine the level of rigor required in the software development process.

Software Lifecycle Processes

The standard outlines processes that span the entire software lifecycle, including planning, requirements analysis, design, implementation, verification, validation, and maintenance. Requirements vary depending on the software safety classification.

Software Safety Requirements

Ensuring the safety of medical device software involves identifying and addressing potential hazards. IEC 62304 mandates an increase in rigor of design control processes and documentation based on the software safety classification.

Software Items

Software items are software components that make up medical device software. By decomposing software into discrete software items, the manufacturer can analyze
failure points and interfaces. It also allows the manufacturer to independently classify and document these subcomponents, thus facilitating the possibility of
reusing these subcomponents in future products.Properly managing these items ensures traceability and facilitates risk management.

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

Benefits of IEC 62304 Implementation

Improved Software Quality

Complying with IEC 62304 significantly enhances software quality by providing a
comprehensive framework that guides the development, maintenance, and validation of medical device software. By adhering to its guidelines, teams are compelled to follow a structured approach, resulting in improved software quality. The standard mandates clear documentation of requirements, architecture, design, and verification activities, which in turn fosters transparency and traceability throughout the software development lifecycle.

This meticulous documentation ensures that potential issues and deviations are identified and addressed early, reducing the likelihood of defects and vulnerabilities making their way into the final product. The standard forces manufacturers to consider not only how they will develop the software, but also considerations for maintenance and the end of life of the software. Consequently, software that complies with IEC 62304 exhibits higher reliability, safety, and overall quality, which are very important in the context of medical devices where patient safety is paramount.

Furthermore, IEC 62304 references rigorous risk management practices (such as ISO
14971 principles), leading to the identification and mitigation of potential hazards associated with the software. IEC 62304 concentrates on the software development lifecycle, process, and documentation. The standard necessitates the classification of software components based on their potential risks, facilitating a targeted approach to testing and validation efforts. This risk-driven approach helps allocate resources effectively, concentrating efforts on the most critical aspects of the software.

Additionally, IEC 62304 requires you to have a plan for verification and validation of software. Different regions may have slightly different requirements. For instance, FDA has published “General Principles of Software Validation” Guidance.” These verification and validation activities are vital for identifying and rectifying bugs, security vulnerabilities, and functional issues. By conducting thorough testing and verification activities, software developers can enhance the performance, reliability, and stability of their products, contributing to an overall elevation in software quality.

Enhanced Patient Safety

Compliance with IEC 62304 plays a pivotal role in elevating patient safety thanks to the rigorous guidelines that mandate a systematic and controlled approach to software development, emphasizing risk management and mitigation strategies. By requiring thorough assessment of potential hazards associated
with medical device software, IEC 62304 ensures that developers identify and address safety risks early in the development process. This proactive approach results in the implementation of appropriate controls and safeguards, minimizing the chances of software-related failures that could jeopardize patient well-being.

IEC 62304’s emphasis on documentation and traceability further bolsters patient safety. The standard mandates comprehensive documentation of software requirements, design specifications, and verification and validation activities. This level of transparency enables regulatory bodies, medical professionals, and device users to thoroughly assess the software’s functionality and safety features. In the event of an issue or concern,
standardized documentation facilitates swift identification of the problem’s root cause, enabling prompt resolution to prevent potential harm.

Additionally, by adhering to IEC 62304, developers create a foundation for ongoing software maintenance and updates, ensuring that any changes are managed
systematically and with patient safety in mind. Overall, IEC 62304’s structured approach to software development and its focus on risk management and
documentation significantly enhance patient safety by reducing software-related risks and facilitating effective issue resolution in medical device software.

Regulatory Compliance

Regulatory authorities worldwide, including the FDA and the European Medicines
Agency, recognize IEC 62304 as a reliable framework for the development of safe
and effective medical device software. By adhering to its standards, developers
align their practices with established industry standards, which simplifies the
process of obtaining regulatory approvals.

One of the key ways IEC 62304 aids regulatory compliance is through its emphasis
on risk- based development and design controls. The level of rigor depends on the
safety classification of the software. This aligns well with regulatory expectations, as authorities often require comprehensive risk analyses to assess the potential impact of software-related hazards on patient safety. IEC 62304’s risk-driven approach not only helps in identifying and mitigating risks but also provides the necessary documentation for regulatory submissions, demonstrating that thorough risk evaluations have been conducted and appropriate controls are in place.

IEC 62304’s structured development lifecycle, which includes phases for software
planning, development, verification, validation, and maintenance, aids regulatory
compliance by providing a clear and consistent roadmap. This ensures that essential development steps are followed and documented appropriately. Regulatory agencies often scrutinize these aspects during the approval process, and adherence to IEC 62304 greatly assists in demonstrating that all necessary
processes have been carried out systematically.

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

IEC 62304 Lifecycle Process Phases

  1. Software Development Planning: This phase involves creating a comprehensive plan for software development that outlines roles, responsibilities, and the overall approach.
  2. Software Requirements Analysis: Identifying and documenting software requirements, including functional and non-functional aspects, lays the
    foundation for development.
  3. Software Architectural Design: Designing the software architecture defines
    how components will interact and ensures that the software can meet its
    intended purpose.
  4. Software Detailed Design: In this phase, detailed design specifications are
    created based on the architectural design, providing a roadmap for
    implementation.
  5. Software Unit Implementation and Verification: Developers write and test
    individual software units, verifying that they meet the defined requirements.
  6. Software Integration and Integration Testing: Units are integrated into a
    cohesive whole, followed by testing to ensure they work together seamlessly.
  7. Software System Testing: The entire software system undergoes rigorous
    testing to identify and rectify defects.
  8. Software Release: The software is prepared for release, including packaging,
    documentation, and any necessary regulatory submissions.

Software Safety Classification

  • Class A: No Injury or Damage Class – A software failures are unlikely to cause any injury or damage to the patient or user. An example might be a display error that does not affect the device’s functionality.
  • Class B: Non-Serious Injury – Class B failures could potentially lead to non-serious injuries, discomfort, or inconvenience to the patient or user. An example
    could be an incorrect alarm sound that causes temporary stress.
  • Class C: Serious Injury – Class C failures have the potential to cause serious injuries to patients or users. For instance, incorrect dosage calculations by a medical infusion pump fall under this class.

Download the entire eBook HERE:
An In-Depth Guide to IEC 62304: Software Lifecycle Processes for Medical Devices

G2® Once Again Names Jama Connect® the Overall Leader for Requirements Management Software

Jama Connect® was again named far and away the overall leader in the Winter 2024 G2 Grid® Report for Requirements Management Software!

In addition to the honor of being named the leader in requirements management software, we are proud to showcase that we were awarded several additional medals for Winter 2024 in requirements management, including:

  • Leader
  • Enterprise Leader
  • Momentum Leader
  • EMEA Leader
  • Small-Business Leader
  • Mid-Market Leader
  • Users Love Us

Download the full report to see why customers love using Jama Connect for product, systems, and software development.

Learn More About the Winter 2024 G2 Grid for the top Requirements Management Software products HERE!

DOWNLOAD

Jama Software® is honored to be acknowledged as the top requirements management solution. We’re grateful to our customers for sharing their valuable feedback on their experiences using Jama Connect. The “Users Love Us” category, in particular, is a testament to the value our industry-leading requirements management software brings to our customers, and especially for customers who have moved from a document-based approach to complex product, systems, or software developement.

“Product Design teams need a requirements management tool like Jama [Connect.] Using Jama Connect allows our software development team to have a well-organized and well-written set of requirements. It allows us to more easily maintain a baseline of features in our continuously evolving software.”

-From review collected and hosted on G2.com, Mark M. — Mid-Market

We strive to provide our customers with the best experience while using our platform. Being named as Leader in particular shows how much our users enjoy working within Jama Connect.

“Jama [Connect] is the final death blow to your grandfathers way of managing text based requirements.”

-From review collected and hosted on G2.com, Mark M. — Mid-Market

Read Jama Connect reviews on G2

From all of us at Jama Software to all of you, thank you!

G2 scores products and sellers based on reviews, gathered from their user community, as well as data aggregated from online sources and social networks. Together, these scores are mapped on their proprietary G2 Grid®, which can be used to compare products, streamline the buying process, and quickly identify the best products based on the experiences of your peers.