Tag Archive for: Requirements & Requirements Management

This image shows two speakers who are hosting a webinar on the topic of MBSE and how Jama Connect integrates with Catia Magic.

In this blog, we’ll recap our recent webinar, “Elevating MBSE with SysML: Jama Connect® and CATIA Magic in Action” – Click HERE to watch it in its entirety.

Elevating MBSE with SysML: Jama Connect® and CATIA Magic in Action

What happens when Jama Software®’s Traceable MBSE™ combines with Dassault Systèmes’ enterprise and system architecture modeling expertise in systems engineering?
This powerful and intuitive integration between CATIA/Cameo Systems Modeler and Jama Connect® aligns business and engineering, bridging the gap between requirements management, system architecture, design, and product management.

This engaging webinar features Cary Bryczek – Jama Software and Saulius Pavalkis – Dassault Systèmes as they discuss the intersection of this technology and give a live demonstration.

What you’ll gain:

  • Key trends shaping the future of MBSE across the aerospace & defense industry
  • Challenges keeping Systems Engineers up at night
  • The impact of Jama Connect Traceable MBSE in defense applications
  • How Cameo Systems Engineering enhances system architecture
  • A live demonstration of Cameo DataHub’s integration with Jama Connect

Don’t miss this opportunity to see how this integration can transform your MBSE approach, driving success from concept to deployment.

Below is an abbreviated transcript of our webinar.

Cary Bryczek: To kick things off, I want to set the stage with some trends across the aerospace and defense industry that we’re seeing. I’ll talk about how those trends are creating challenges for chief engineers and describing what keeps them up at night, then I’ll set the stage for Saulius’s presentation by showing you what Jama Connect’s Traceable MBSE looks like and how it’s designed to solve those challenges. Saulius is going to take you on a deeper dive to show you how system models and Jama Connect interoperate.

So in the aerospace and defense industry, we are developing a new system that has complexity that far exceeds commercial product development. For example, the FAA’s program to develop the Unmanned Aircraft Traffic Management system involves not just a pilot and drone, but is designed to enable autonomous and semi-autonomous operation of multiple air systems, including the passenger and cargo delivery, in a really tightly integrated civil airspace. The elements in blue on the diagram are all distinct systems of their own, and the new traffic management system needs to integrate communications and data across all of those systems to provide this new capability.

In the highly constrained environment of outer space, for example, NASA’s Cislunar and I’m pretty sure the Artemis programs are focusing on the operation and survivability of autonomous systems. To develop a space system, NASA doesn’t do this in their own silo, but they have lots and lots of contracts and companies that they work with deliver parts of the system, just like in the DoD. For example, you have Blue Origin. They are developing a friction stir additive manufacturing part of the system in partnership with Langley, right? You have Redwire out of Erie, Colorado. They are developing another in-space manufacturing system. You have Canopy out of Denver. Colorado seems to be a popular place for space. They’re developing low-cost reusable thermal protection systems, right? And there’s really dozens more. The Cislunar and the Artemis programs are developing ecosystems and the ecosystems of those partners, right?

In the government agencies and aerospace and defense companies, they’re always evolving their strategies to be able to deal with this high degree of complexity to help streamline their engineering processes. For example, the DoD, they have published a new adaptive acquisition framework. So even not just in the engineering parts of it but the acquisition parts of it as well, there’s a new framework. This particular pathway is intended for large-scale traditional hardware acquisitions to help facilitate rapid and iterative delivery, like what the software capability programs are doing.

In 2018, we had the Digital Engineering Strategy outlining a vision to modernize how DoD designs develops, delivers, operates, and even sustains systems, right? By connecting people and process and data and developing these end-to-end digital enterprises.

The International Council on Systems Engineering, their Vision 2035 is intended to guide and inspire the strategic direction of systems engineering for the global systems engineering community, right?

The DoD’s Systems Engineering and Architecture group within the DoD itself is focusing on modernizing the systems engineering practice and they’re leveraging the capabilities coming out of SERC and MOSA to build systems that can be upgraded to incorporate new technology and respond to emerging threats, right?

With this new modernization of the SE approach, and now I know this is sort of an eye chart, you guys can look at it after the fact, the DoD has moved away from visualizing its process using that shape of the V model in favor of what more realistically takes place from a process standpoint, which is that modern systems engineering is highly cyclic in nature. Now, the outermost ring is as close to what the old V model, where concept definition is in the upper left, moves to system definition through architecture and design, over to V&V, and back around to start the next cycle. What’s important is that there’s a strong emphasis on measuring not just the system being built, but the process to build that system and that data and models are at the heart of it all. To the fullest extent, models should be used in favor of documents and data should inform the decision-making.

There really is a challenge to using a data-driven approach in the models. The DoD, I love this quote, “There’s a lack of an integrated approach to implementing systems engineering focus areas that’s creating a delay in implementing the digital transformation, which is necessary to ensure relevant guidance, skills, and training are available to deliver a disciplined approach to acquiring a weapon system.” Continuing to use legacy tools and approaches is what making integrated approaches gravely difficult. What’s necessary is to take a federated approach to data across the tool ecosystem and use tools with robust APIs, modern architectures that are standards-based. An MBSE approach requires an integrated approach to connect that system model’s architecture and requirements to program teams and software and hardware teams. It doesn’t mean using a siloed system modeling tool and expect those teams to be able to consume and understand that model. In fact, kind of what I hear a lot is, “How do I achieve the benefits of MBSE when no other engineers can access model parameters they need to use to make downstream decision-making, and how do I make decisions on tests and other things that’s downstream from the system model?” I hear that quite a lot.


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


Bryczek: Those with technical oversight and responsibility for program success who are executing MBSE or even just traditional systems engineering commonly raise these following questions. This is what I think keeps chief engineers up at night. “How do I know if the architecture and system requirements are satisfying all the needs?” “How do I know if a change in the architecture will impact those needs?” “How do I know if a change in the architecture will impact hardware or software teams?” And, “How do I streamline model design reviews?” I have a fourth one, too, “How do I detect unallocated systems architecture and requirements that sort of transcends the system model area and goes into the software models and the hardware models?” So that’s another favorite that I have.

So these questions really, we think, can be answered using what we term Traceable MBSE. The reality at most companies is that the end-to-end systems development processes is fragmented into domain-specific tools and spreadsheets that really don’t have a lot of collaboration or any, and this leads to fragmented requirements traceability and requires significant manual effort through emails and meetings and maybe even luck to try and prevent delays, defects, rework, cost overruns, right? Most companies have come to accept this situation as an unchangeable reality given the lack of a single platform to enable this entire process, nor a method to integrate spreadsheets and desktop tools. Using Traceable MBSE, the system model in the modeling tool is joined with the Jama Connect model. Jama [Connect] is continually calculating traceability and coverage and provides scores that can be used to identify high-risk areas that can be drilled into to determine corrective actions, the system model can detect those changes, and the modeling engineers can take corrective action.

Keep in mind that model-based systems engineering is more than using the power of SysML. It is powerful. Systems engineering’s superpower to enable digital transformation comes when it’s able to connect to the entire development effort and facilitate software and mechanical teams with the ability to align their efforts to the system model, systems engineers being able to manage the state of development across the disciplines and automatically identifying risks through all stages of development.

So let’s maybe see what this looks like in Jama [Connect.] This is Jama Connect in a web browser. I’m showing a Traceable MBSE project for development of a cube set. In it, I’m managing the end-to-end development of the program mission goals and objectives, stakeholder needs, concept of operations, system requirements, subsystems, software and hardware requirements, architecture, safety risks, verification and validation, and even user stories from Jira. Jama [Connect] is going to provide that measurable end-to-end traceability for all of their elements. Their version control and baselines provide design, review, and approval, plus make the data visible onto a series of dashboards.

All the interactions with Jama [Connect] are done in this web browser. Just to give you a little bit of navigation overview, if you’ve never seen Jama [Connect], you can see the data. You can organize the data pretty much however you want. You’re not constrained to how you want to call the data. Want to look inside stuff, you can open up and look inside the dashboards. The series of dashboards can be laid out however you want. You can have multiple dashboards. So this is my main one. I want to see a trace exception dashboard, I’m able to just organize them how I want, surface up that information. And they’re live too, so if I wanted to go and look at what any of these are, show me my objectives, needs, or goals, I can just click on them and it takes me pretty much right to where I want to be.

One of the things that makes Jama [Connect] special is the ability to define a data model for the information that you’re going to be managing in the model or the Jama [Connect] project and define how the traces are related together. And then our Live Trace Explorer™ is used to show real-time progress against expected traceability. So I open up my Live Trace Explorer for this particular project. The Live Trace Explorer is used to show the real-time state of progress of all of the items that are being managed in the system against the expected traceability according to those rule sets. When integrated with system modeling tools, like managing architecture, Jira managing the flow of tasks, using Live Trace Explorer, you can obtain this holistic view of quality across your entire system development and software factory process.

So this left-hand side shows requirements coverage and the right-hand side of the Live Trace Explorer shows test coverage, similar to a V model. Here you can see the program system-level requirements. So here we scroll down, we have the program system level requirements and all of the relationships established for traceability. This is based on the project’s traceability rule set, remember? Your project might use different names than what you see here. You’re not really constrained to using what comes out-of-the-box Jama [Connect] at all.


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


Bryczek: The Trace Explorer in the upper right, this Trace Score™ shows an overall traceability score for your project that you can use to gauge how quality changes, hopefully improves over time. So all of these metrics are real-time from what’s happening right now, and so 64% traceability, this is probably maybe early to midstream in development. We’re still seeing people still establishing traceability, right? But by increasing your traceability score, we really hope to reduce the risk of defects, cost overruns, and delays.

So what about some of those questions that keep chief engineers and program managers up at night? What about the ones that we were asked about? So question one is, “How do I know if architecture and system requirements are satisfying all the needs?” This is tracked in our Live Trace Explorer as a percentage of coverage between the linkages. So here we see a 55% coverage between these stakeholder expectations, which we have 36 stakeholder expectations, so 55% traceability established so far between those. And we only have, and if you scroll down, if you want to see what the architecture is, the architecture, we only have 50% coverage between the architecture and requirements.

So what about, “How do I know if a change in architecture is going to impact testing”? You can really easily see that here, the changes between what’s happening to testing. You can even see a percentage of the suspect changes. So right now, I might’ve already changed some of the requirements of your architecture. 11% is showing suspect. Right now, I don’t have a lot of test plan coverage. Still kind of in the early phases as well.

What about the third question, “How do I know if a change in architecture will impact hardware or software teams?” Right? Again, you can easily see any of the downstream traces to different things. And this is live, too, so if I wanted to see exactly, show me those objects, I can just click, it’s all interactive, and see exactly what the traceability between architecture and system requirements look like. I want to add more information to the view, maybe I want to see what the rationale is or the status, I can add that kind of view really super easily to my view. Jama [Connect] is really designed to make it easy for anyone to come in, understand what’s going on in the program, click and see instant traceability based on what you’re looking at.

So another question is, “How do I detect unallocated system architecture and requirements?” Unallocated activity can be used by running a query. So I have a filter that says, “Show me all of the unallocated architecture.” So I have four architectural elements that have no traces for requirements, and if I turn my trace view on, you can see these are just standalone objects. There’s no traceability either up or downstream to requirements of any kind. We really want to make this as easy as possible, as powerful as possible for people to measure in real time what does their traceability look like, how do I use traceability to effectively enhance the process and remediate actions before they might possibly happen.

So in summary, as systems development continues to increase in velocity, engineering leaders and program managers really need answers to those really tough questions. System modeling tools alone don’t easily provide that. With Jama [Connect]’s Live Trace Explorer, this is providing that real-time traceability score. Our approach for managing and controlling process is using actual data. Jama [Connect] is really the only one that can provide that holistic view. Very exciting.

And now, Saulius would love to show us how Dassault is connecting Jama [Connect] and CATIA Magic.


RELATED: Jama Connect® for Traceable MBSE™


Saulius Pavalkis: So you saw the Jama [Connect]site. Now we’ll talk about the integration part with CATIA Magic leading SysML and MBSE solution for system architecture. So what is the reason, what is the differentiator, why it is the leading solution? So this was first product to support SysML v1, and pretty much all the versions from that was supported with the complete standard, following already for almost 20 years, as we can see, of the SysML appearance. Now we’ll be working on SysML v2, which will be another evolution and, again, the same goals. We became de facto standard for the many different project types in the industry, and pretty much the quality and scalability of the product and strict following of the standard enabled that. You can’t support all the big clients with the custom solutions unless you will follow some standard approach which allows to customize for each specific one later on.

And that brings us to our core values. So it is completely open. Also, as we will see here also from OpenAPI side, because that enabled us integrate in the proper way with the requirement management solution, Jama Software.

Standard compliance, another big deal because if you support the standard, maybe it is a bit harder than to integrate specifically for specific needs, right? But once you follow that, it’ll apply for all the different purposes, plus it will be clear which part of the integration needs to be updated with the standard update and with the tool development, which is not the case when you don’t follow the standards, right?

Efficiency and user-friendliness, ability to customize, and that’s like one of the most significant values because again, if you follow the standard, you get the 90% for the industry needs, but then you need to customize for specific industry, like what type of the data you want, as you saw in the Jama [Connect], you can select data set, what’s needed for specific project, have ability to create your own data set and then synchronize only on that data set and work on that model.

We support mostly system engineering community needs, and that is pretty much 90% or something of the product, because standard compliance is one thing, but then actually system engineering to enable better results with the model than PowerPoint, better tables and data management, and Excel is the key differentiator when you want to work with the model sufficiently.

The big part is continuity to disciplines. As you saw, traceability is big part of the Jama Software solution. Same for us, we dedicate most the attention for these integrations with the rest of the ecosystem. This is perhaps one of the most popular integrations, maybe the most popular integrations which we have. But in general, these are disciplines in engineering and analysis.

And also system engineering life cycle, as Cary mentioned, design reviews, this is very important process. Every organization goes through it and also in collaboration with suppliers, and that’s technically insight but also other processes which requires formal process with the approvals and baselines.

So talking about this integration specifically, we are using DataHub as integration framework. What are the highlights? It comes as a plugin actually for CATIA Magic. It’s built in in CATIA Magic. And this integration is also not an exception. It’s using this major integration framework, which is mostly for requirement tools integration. One of the most used integrations which we have is actually requirement management tools, and the most useful integration, used integration likely will be Jama Software integration from requirements management side. It provides similar experience for all the integrations and already set up operations which are common for the users, not to expect some surprises, but it is also redesigned to be more optimal, more user-friendly, and supports the standards like OSLC v2, but in our case, we are using direct API to Jama Connect, which is always the best case when you have ability to leverage that, and that shows again the openness of Jama Software and CATIA Magic.


RELATED: Empowering Efficiency: Parry Labs Selects Jama Connect®< for Seamless Use, Unparalleled Traceability, and Streamlined Review Cycles


Pavalkis: The workflow is very simple, so pretty much you connect the data source to Jama [Connect]. Jama [Connect] can be on the cloud, on premises. You select the scope for the synchronization. We support only one operation, copy and synchronize, which is by far the most popular one from all the experience we have. We then select the mapping based on the data sets selected, you know, could be new requirement types, could be new relations and so, and then we synchronize, first of all, by copying the data, but later on by checking changes, seeing the changes available and acting on those changes, synchronizing and acting on those changes with suspect links in our site. And also, on top of that, we support diagrams as an image interchange, which is a big deal because then you can actually work independently without all these requiring to see another solution for the part of the data.

Now, when we work together, what are the key connection highlights? So we support advanced authentication methods, simple authentication, and OAuth 2.0. On project selection, we select the data which will be available, what type of data will be available, and that data will allow us to map just to those elements from Jama Software type and see them synchronized to CATIA Magic using DataHub. As you can see here, we have this Cameo DataHub view in CATIA Magic, Cameo, and it is based on the same selected data in Jama Software for the project, right? And then you can see it with the icons with the exact representation that allows you to have the seamless interface.

The leverage, the same dedicated UI for identifying changes, what’s new, what is modified, move, delete it out of scope, and this allows us to see the change before synchronizing, so you can even apply element-by-element synchronization and, based on the direction of synchronization, you can choose one or another way to synchronize, which is always good to choose in advance not to have the conflicts on the authoritative source of truth.

We have number of items, type of elements in Jama Software which we synchronize. You can see the full list. It’s far more than just requirement, the different other types of attachments and so on. We allow, as I said before, to import the images to CATIA Magic and from CATIA Magic export diagrams as images to Jama, which allows you to review the diagrams in Jama Software and also see the architecture views from Jama Software and CATIA Magic and act on them.

To watch the webinar and see the demonstration of this integration, please visit:
Elevating MBSE with SysML: Jama Connect® and CATIA Magic in Action

The Jama Software® Discovery Center: Learn the Value of Jama Connect® for Complex Development

Welcome to the Jama Software® Discovery Center — a dynamic resource designed to guide you on your journey with Jama Connect®. Whether you’re just beginning to explore modern requirements management or you’re an experienced user looking to optimize your processes, the Discovery Center provides everything you need— right at your fingertips. Learn about Jama Connect and grow your knowledge at your own pace with this comprehensive resource.


RELATED: Best Practices Guide to Requirements & Requirements Management


Explore the Four Key Areas of the Discovery Center

The Discovery Center is organized into four main areas, each designed to meet you wherever you are on your journey with Jama Connect or simply better understanding how to optimize complex product, systems, and software development.

Here’s an overview of what you can expect:

  • Discover – Just starting out? Begin your journey in the Discover section, where you’ll find a wealth of resources to help you grasp the fundamentals of modern requirements management. This area is equipped with a comprehensive buyer’s guide, best practices for requirements management (RM), and insights on how centralizing your RM can mitigate risks in product development. Whether you’re evaluating RM tools or seeking to refine your current processes, this is the ideal starting point.
  • Explore – Curious about how Jama Connect can address your development challenges? The Explore section is for you. Here, you can delve into how Jama Connect® can cater to your specific product, systems, or software development needs. Access curated resources, including customer stories, a complimentary 30-day trial of Jama Connect, and our Get Started video series. This section is designed to facilitate informed decision-making by demonstrating why industry-leading organizations worldwide, choose Jama Connect.
  • Align & Launch – Ready to implement Jama Connect or better understand what that might look like? The Align & Launch area serves as your go-to resource for successful installation and adoption of Jama Connect within your organization. This section provides key resources to support implementation planning, including FAQs, installation tips, and an in-depth examination of the platform’s features and functionality. It encompasses everything you need to ensure a seamless transition and effective rollout.
  • Optimize – Already using Jama Connect and seeking to maximize its potential? The Optimize section is tailored for users who want to enhance their environment and ensure long-term success. Here, you’ll find comprehensive information on the REST API, optimization videos, workshops, tutorials, and other tips and tricks to help you fully harness the power of Jama Connect’s robust capabilities.

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


Start Your Journey Today

The Jama Software Discovery Center is more than just a resource collection — it’s a comprehensive guide that empowers you to take control of your knowledge journey with Jama Connect. Whether you’re discovering, exploring, aligning, launching, or optimizing, the Discovery Center is here to support your success every step of the way.

Click here to visit the Discovery Center!

 


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

This image shows two hosts of a webinar outlining success tips for energy storage.

In this blog, we’ll recap our recent webinar, “Achieving Success in Energy Storage Development: Tips & Best Practices” – Click HERE to watch it in its entirety.

Achieving Success in Energy Storage Development: Tips & Best Practices

Are you prioritizing the safety and success of your energy storage systems (ESS) development?

Teams developing ESS must prioritize product safety and effectively navigate the certification process. By learning best practices and gaining insights into Underwriter Laboratories (UL) standards, they can enhance safety and ensure compliance with industry regulations.

In this webinar, Christopher Flueckiger, Consulting Engineer at Key Renewables, and Steven Meadows, Principal Solutions Lead at Jama Software®, explore how a modern requirements management solution can help your development efforts, reduce risk, and provide a predefined framework tailored for energy storage systems.

You’ll gain a thorough understanding of these topics and more:

  • Proven best practices for energy storage system development
  • Key tips for achieving certification to UL standards
  • How Jama Connect®‘s pre-defined framework supports successful energy storage systems development and ensures compliance

Don’t miss this opportunity to gain valuable insights and learn how a modern requirements management solution can streamline your energy storage development efforts.

Below is an abbreviated transcript of our webinar.

Steven Meadows: Welcome to today’s webinar on achieving success, as well as energy storage development tips and best practices. So for today’s webinar, we’re going to dive into some essential topics that are going to be very important for successful and safe energy storage system development and successful certification. So our agenda really is going to cover a few areas, including key tips for achieving certification with UL standards and development best practices, Jama Software’s perspective on development challenges, and the effective use of Jama Connect for managing the development of energy storage systems, as well as a sneak peek into our new energy storage development framework.

Now, before we get started, I’d like to briefly introduce myself and my background. My name is Steven Meadows and I’m a principal solutions lead here at Jama Software. With a pretty robust background in requirements management, I bring around about 10 years of experience in implementing software and working with hardware and software teams across a broad spectrum of industries, helping important market game changers really succeed in their development efforts. Now, throughout my career, I’ve had the privilege of working closely with many, many incredibly innovative and life-changing organizations, helping them navigate the intricate landscape of engineering. So Jama Software, my focus has been on empowering teams to achieve their project goals efficiently and with precision. Whether it’s harnessing the full capabilities of Jama connect the platform or strategizing for complex project scenarios and engineering scenarios. My passion really lies in delivering tangible results that drive innovation and enhance operational excellence. Today I’m excited to be joined by Chris Flueckiger who will be talking about energy storage development best practices and certification tips. He’s a bit of a guru in the space. Would you like to introduce yourself, Chris?

Christopher Flueckiger: Sure. Thank you. It’s nice to meet everybody. I’ve spent about the first half of my career working with the design phase of electrical equipment and then the past almost 30 years in the certification of renewable energy systems including battery energy storage systems. So I’ve been working with large companies. I work with all the certifiers currently and represent companies as they look towards certification, all the way from the concept and design of a product through the final certification in marketing and installation. So I look forward to talking with everybody.


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


Flueckiger: This is going to be interesting. In a half hour, we’re going to try to cover the complexity of certification, but to do so in a way that’ll provide efficient moving from the development of a product to the marketplace. And this is an image of that process when we talk about certification. It starts with a list of documentation, knowledge, and an understanding of what applies to your product. And to go back just one step, it’s understanding what your standards and codes are that are driving that certification of your device. You’ll see the blue text here that represents work that you can do ahead of time to ease the process of certification when you actually present your product to the certifier. And this blue information here is a collection of documentation and evidence, if you will, that your product indeed complies with whatever standards might apply.

When we’re talking about energy storage systems, we’re looking primarily at UL9540 and UL9540A. And the code that drives that is going to be the NFPA 855. And so all these little blue boxes are critical as we prepare for our submission for certification. I will say that not having this information as you enter into certification results in significant time delays, and resource costs as far as samples needed, retesting, redesign, etc. And so what we’re going to do is go through some of these critical points here and discuss how we can make it easier, what we can do to prepare better so that we can be as efficient as possible. Just an example of how efficiency can help you, a typical certification of an energy storage system is going to take about … Well, it could be anywhere from 14 to 16 weeks. We’ve had some certifications that have taken more than a year to complete when they haven’t been prepared properly or they’ve had to be redesigned or test results have come back that have shown a lack of compliance with the UL9540 standard. So it’s critical that we move forward in a smart, organized, and efficient manner.

Talking about the beginning of this whole process is a knowledge of all of your codes and standards that apply to your energy storage system. It’s more than just a marketing scheme. It’s a legal requirement that devices are certified or proven safe to the authorities having jurisdictions or AHJs that approve those installations in one of the many, many, approximately 3000 different jurisdictions across the United States. Those codes are called out by the building codes. From there it calls out specific codes for electrical and fire safety. And those codes are adopted by local jurisdictions giving them some teeth. They’re legislated into effect, which gives them the legal basis as a requirement in order to install an energy storage system within a particular jurisdiction. And that legal basis is important. When we talk about certification, often companies see it as a necessary step, maybe even an obstacle that they have to achieve just to get their product to market, but it has more meaning than that.

It basically establishes a bar of entry for electrical devices that are suitable and acceptable for installation in specific jurisdictions. Now in the United States, we fortunately have the NFPA 70 or National Electrical Code that drives those requirements for safe electrical equipment, and that follows through along with the fire codes. So there is a legal basis for doing this. And yes, it can be time-consuming and it can be costly to go for certification, but it’s a necessary step in order to demonstrate that our products meet the industry standards for a level of safety. We do that basically as a consensus agreement within the industry on the requirements that are established both in the codes and in the standards. So it’s not simply a checkoff, it is an integral part of the safety of our electrical systems in the United States.


RELATED: Power Efficiency and Innovation Across Your Development Process with Jama Connect® for Energy Storage Systems


Meadows: Have you worked with teams in the past, maybe missed the upfront research around codes and standard requirements, and any examples of some of the impacts of that?

Flueckiger: Oh, absolutely. And oftentimes, as I say, they’re looked at as a necessary evil and bypassed, if you will, during the design phases. And then they come back later with those requirements and try to implement them at the last minute. And that often requires redesign of electrical circuits, repackaging of the product, et cetera. So it can be rather detrimental and costly to wait until the end. Good question.

So when we look at typical requirements that are included in the standards and the codes, we’ll be referencing UL9540 quite often here. They’re broken down into three major categories. We have your general construction requirements, and this is your design, right? These are the components that you’re putting together into a package that provides whatever functionality you are advertising or you’re stating that your energy storage system will provide. For example, you may have an input voltage of 480 volts. You might have an output voltage of 120 volts, whatever the case might be. You may have a certain amount of energy storage and, a number of batteries in your system that operates in a certain way to provide either backup power or to even maybe clean up a microgrid someplace in an industry, for example. But all of those general requirements for ratings rely on construction. Everything from the wire nuts holding two wires together or the connectors, all the way to the batteries and through the whole system with cooling systems potentially, and other systems that make up a part of the whole system that you’re looking to market.

And so those general construction requirements are basically material type requirements, component requirements, and mechanical requirements, and all of them are specified or delineated in UL9540. From the electrical side, we have a little bit more to deal with as well. For example, there are different circuits in battery energy storage systems. We may have an AC connection, we may have a DC set of batteries, we may have an inverter that is making that DC energy usable to the outside world, etc. All of those different circuits within the system have to be isolated from each other so that we don’t have somebody touching an antenna on a communications device and getting 480 volts at that antenna. We want to make sure they’re safe and that they’re separated. And one of the common things that’s missed along the way is that isolation. Spacing is a word that’s commonly used in electrical to define how we develop that isolation using air, for example, as an insulator.

We also might use materials that we talked about in the general construction requirements that have certain dielectric strengths to them so that we don’t have arc over within electrical circuits going from a high voltage, for example, to low voltage. So that’s an important part that has a huge impact on whether or not design is adequate, the design of your circuit boards, your interconnection of devices, etc. Whether or not they’re adequate to meet the requirements of the standards.

And then that follows by those individual components that we’re interconnecting. Whether it’s the batteries, the interconnection to a battery management system or a charging system to an inverter, to a fan, to a cooling system, or an HVAC system depending on the size of your system. But those components that make up the structure have to be relied upon in order to function safely. Not only to function safely but to produce the desired output that’s required of your energy storage system, whether it’s AC or DC, whether your input is AC or DC. All those components work together and are interconnected to produce the output and the functionality of your system.

To watch the entire webinar, visit:
Achieving Success in Energy Storage Development: Tips & Best Practices​

 


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 MedTech Dive, titled “FDA Seeks Feedback On Health Equity for Medical Devices” – originally published on August 6, 2024, and written by Nick Paul Taylor.

FDA Seeks Feedback On Health Equity for Medical Devices

The agency plans to develop a framework for when devices should be evaluated in diverse populations to support marketing authorization.

Dive Brief:

  • The Food and Drug Administration is seeking feedback on health equity for medical devices to inform a potential regulatory approach to the topic, the agency said Monday. The paper is open for comment until Oct. 4.
  • In the discussion paper, the FDA shared its thinking on how sponsors can select study populations that adequately reflect the intended use for a particular medical device.
  • The discussion paper is part of a broader focus on health equity, one of the Center for Devices and Radiological Health’s strategic priorities, that also includes advice on diversity action plans.

RELATED: Jama Connect® for Medical Device Development


Dive Insight:

The FDA framed the discussion paper as a response to the “urgent public health need for innovative technologies that help to reduce barriers to achieving health equity.” Seeking to address that need, the CDRH has committed to developing “a framework for when a device should be evaluated in diverse populations to support marketing authorization” as part of its strategic focus on health equity.

Running clinical trials that generate results consistent with how a device will perform in the real world is a way to improve health equity. Acknowledging that generating clinical data “can be complex,” the agency said it has focused its discussion paper on “a few important considerations that may be relevant for FDA’s evaluation of clinical evidence.”

The paper outlines factors that may help sponsors and investigators develop study objectives. To inform early trial design, the FDA recommends asking how the burden of disease and how the prognosis of a disease varies across a device’s intended use population. Sponsors can also ask how a device may introduce, exacerbate or mitigate differences in outcomes across the study population.

Another section of the document describes considerations related to the FDA’s evaluation of safety and effectiveness. The FDA reviews marketing authorization filings to determine whether there is reasonable assurance the device will be safe and effective in the intended population. As such, the agency is looking at whether clinical data “are generalizable to, and representative of, the intended use population.”

The FDA said it “considers it important to understand a sponsor’s rationale regarding the relevance of the provided clinical data to the intended use population.” The rationale could cover the processes used to select and enroll study populations, the agency said, or help the FDA understand difficulties a sponsor encountered when trying to obtain data from certain populations.


RELATED: Intelligent Engineering Management with Jama Connect® Live Trace Explorer™


In the final section of the paper, the FDA describes example scenarios intended to prompt feedback on its assessment of the benefits and risks of devices. The section features a table that shows how the FDA may respond depending on whether the evidence suggests there are differences in patient populations and health outcomes, as well as whether the sponsor included specific populations in the clinical study.

In some cases, clinical trial sponsors may choose to design studies with “enriched” populations, meaning they intentionally enroll people from groups where differences are expected. The table suggests sponsors that fail to enrich study populations to reflect the intended use may face difficulties at the FDA if the available information suggests differences in patient populations.

The FDA said the absence of enriched populations may “introduce uncertainty” on the applicability of the data to the intended use population.

Application of Systems Engineering in Healthcare

In this blog, we recap our webinar, “Application of Systems Engineering in Healthcare”. Click HERE to watch the entire webinar.


When it comes to healthcare, the first to market usually gains 80% of the market share, making development speed one of the most crucial aspects of success – or failure. That’s why many organizations are looking at systems engineering as a way of connecting needs to solutions.

In this webinar, Chris Unger of PracticalSE LLC and Vincent Balgos Director, Medical Device Solutions at Jama Software® have partnered up for an engaging webinar on the application of systems engineering in healthcare.

We invite you to join in as we delve into transformative role systems engineering is playing in the healthcare industry.

What to Expect:

1. The Power of Simplicity:

Discover how focusing on the basics, while maintaining world-class performance levels, can yield astonishing returns. We’ll show you how simplicity can be a game-changer in the complex world of healthcare systems engineering.

2. Market-Driven vs. Contract-Driven:

Intrigued by the difference between market-driven and contract-driven industries? We’ll explore how systems engineering varies in these two landscapes. Learn why “Market Driven” industries emphasize competitive value creation and use cases more than traditional requirements, and how this shift can redefine your approach in healthcare.

3. Striking the Perfect Balance:

Explore the ideal state of systems engineering in healthcare, often a harmonious blend of Agile, Lean Startup, and more traditional systems approaches. Uncover strategies to adapt, innovate, and succeed in this dynamic field.

Don’t miss this opportunity to gain a comprehensive understanding of how systems engineering can revolutionize healthcare. Whether you’re a seasoned professional or just beginning your journey in healthcare systems, this webinar promises valuable takeaways for all.

Below is an abbreviated transcript of our webinar.


Application of Systems Engineering in Healthcare

Chris Unger: We’re going to talk today about systems engineering in the medical industry, particularly medical device development. So the medical device industry faces several challenges. There’s clearly constant time pressure in developing and launching safe and effective products. We’ve got to be faster than the competition with better products. And as you can see from the statistics, this is a challenge. Part of the challenges in delivering things on time is the shifting regulatory landscape. I’m sure everyone’s aware of MDR. There’s software for medical devices. The FDA is going to think about redoing design controls next year. When we were at GE Healthcare, there were like 8,000 regulations we had to monitor. So it’s a very challenging and shifting regulatory landscape. Not only do you have to be compliant with regulations, but you have to ensure your device is safe. And so quality issues, safety and just keeping performance are key elements of delivering on time and that’s getting more and more expensive as you can see here, billions of dollars of financial risk of getting this wrong.

So to make all that harder, there’s a constant increase in complexity. When I first started, there were typical software development teams were 20 to 40 people. It’s now hundreds of people and lots of interactions. So additional things like AI, machine learning, or new technologies, really have to manage a lot of complexity inside of your devices. The organizational structure is getting more and more complex. There’s a heavy focus on acquisition, so you’re integrating new teams, new cultures, and geographically distributed development teams. So that makes it all challenging. So we’re going to talk about how systems engineering can help address some of these particular challenges.


RELATED: Intelligent Engineering Management with Jama Connect® Live Trace Explorer™


Unger: As I mentioned, a key differentiator is getting to market faster. So the success of a program in a market-driven environment is basically profits. The first mover tends to collect the lion’s share of the profits. We typically have many customers. You don’t have a single customer marketing and product management tells you roughly what they think the competition will be and what differentiates versus in a contract-driven environment, success is satisfying the contract. So within GE Healthcare, the avionics and oil and gas businesses typically had a single customer. We would produce a floating city block to British Petroleum or Shell, go to the North Sea or the Caribbean and you had a contract and you delivered to that contract versus an engine, an aircraft engine, or a medical device, we deliver to the marketplace. We decide the timing, we decide the features.

So the stakeholders and market-driven are internal to the business and you can negotiate budget and time. If you get a really, really cool feature, you can take an extra month or quarter to develop it, versus in a contract-driven, it’s really fixed. So the challenges of market-driven and contract-driven are different. Contract-driven requirements are a key commitment. You’ve got to negotiate a formal design control versus within a market-driven environment they’re critical. You have to deliver validated requirements, but they’re definitely an internal business tool that helps communication across all the business functions.

So what’s the value of systems engineering in a market-driven industry? We basically turn the ambiguous needs that we get from product marketing or product management and turn them into clear and feasible solutions to be implemented by the hardware and software teams. The key value we produce is that those implementations seamlessly integrate into the customer’s workflow and work systems. So they work really well from day one, they reliably meet their needs. They work really well after five years and not just meet their needs, they delight the customer. We really want to deliver something that the customer enjoys using. So we have to make it work day one, we need to make it work day 50. We need to make it work for every single customer. So you have to deal with all the known variability of hardware and process. Every installation and every service event has to produce a uniform, high-quality, high-performing product.

So with those constraints, we want to optimize the business value. So when we have multiple options, marketing will tell us the customer value of these options. The implementation teams will tell us the delivery and product cost of those functions. The role of systems engineering is to make trade-offs between those and really optimize the business impact based on the cost of implementation. So we want to make sure the work done by those implementation teams is tied to the maximum market impact. And associated with that is managing technical risks. If you go down a path and it turns out to be infeasible, while it might’ve been nice if it worked, you just wasted a lot of that work. So that cost has to be scaled by risk.

In doing all those first four bullets, our key value is making sure design decisions are identified and closed predictably, and that the team acts with one voice. So decisions are framed, the options are agreed to, the decision criteria are agreed to and the final decision is closed and stays closed as stakeholders change. So once you have a frozen design, do you want to make sure that actually integrates easily and when you have integration or quality problems, they’re found early and resolved early. When you have time to react, it’s a lot easier to adjust your design in the first half of your program. It’s really hard when you find severe quality issues with a month left before shipping.


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


Unger: And so really winning products happen when systems thinkers are effective. So clearly there’s going to be a need for some systems engineering process thinkers, but they’re system thinkers across the entire program. And so we want to make sure that everybody’s involved in systems and that the creativity of the entire program is maximized. So getting specific to GE Healthcare, what is systems engineering at GE Healthcare? Well, we have the essential customer-perceived performance. So a lot of our programs are imaging, so we have the image quality. Still, we also have things like maternal-infant care where we deliver the right humidity and temperature around the neonate. In delivering that essential performance, you’ve got to make sure it’s safe and you’ve got to make sure you have regulatory compliance. And I mentioned we really want products that are easy to use and delight the customer. So usability is a critical part of systems engineering. In doing that, we make sure we define the right implementation requirements and the right reliability strategy, and that it can be installed and serviced properly.

So with that being the overall goal, how do we organize? Well, there are a lot of things that are common across all of our product teams. We do have common program milestones. We do have a common systems’ lifecycle. It’s basically the V-cycle with iteration and agile built in. What differs is that different product teams at GE Healthcare have different levels of safety hazards, so FDA risk. We go from anesthesia where you can easily kill somebody down to ultrasound, where it’s non-ionizing equipment, that’s the light handheld probes. You can’t pinch or crush anybody to even service software that has zero patient impact. There are also almost no risks for anybody and we respond to that by adjusting the process rigor so that the higher-risk safety risk modalities have higher process rigor.

Additionally, things vary across the world or we have different locations with different cultures and different sizes of organizations. We have many systems engineers across the company, but the SE team sizes vary from less than 10. In fact, we had some sites with maybe 10 engineers and the systems engineer was half a person to teams that had over a hundred systems engineers. The scale of the programs we work on is less than 10 engineers and months-long programs to many hundred as engineers applied to a program that might last three years and were based on technology developed over the prior decade. And you want some systems engineering thinking even during that basic research decade.


RELATED: Understanding Integrated Risk Management for Medical Devices


Unger: The organization goes from product centralized, it’s like the SE GM for that hundred engineering group where they all reported to a dotted or solid line, to decentralized in where that team of 10 with one or half a systems engineer, there the manager was a general engineering manager and did not have a lot of systems engineering experience. So I joke that if there is a way of organizing systems engineering, we have one of those within our group somewhere.

But how did we think about tailoring? And so this is a page I put together that was generalized that you might be able to use. Obviously, as I mentioned, higher technical risks including safety risks. One way of measuring that is how many risks there are in your hazard analysis. For things that are a higher risk we looked for a higher level of functional excellence, more process documentation, more process compliance, and higher rigor of the technical design reviews, and maybe more independent reviewers. Team experience. This is subjective to measure, but Joel Goldstein did a very nice study, from Carnegie Mellon, that the value of systems engineering increases with program complexity, but it decreases with a more experienced team if you have a small team that is experiencing the technology and the application, they can get by with less process rigor and while systems engineering excellence delivers some value, it delivers less value.

To watch the entire webinar, visit:
Application of Systems Engineering in Healthcare

This image portrays a person unlocking their product development with Traceability vs Excel

Proactive and Live Traceability™ in Jama Connect® vs. Retroactive and Lagging Traceability in Excel

Incremental increases in product development complexity can lead to an exponential increase in the effort required from Engineering and Research and Development teams to keep up in a document-based (Word/Excel) environment.

PROBLEM

Our medical device & life sciences team has thousands of conversations per year with people interested in product and systems development improvements.

When we look at customer data over the two years prior to adopting Jama Connect, 83% of these organizations had their traceability maintained in an Excel-based matrix.

In this environment, all of the traceability components are maintained in a separate system (in other documents or tools). What we found was that this led to traceability being disconnected from the actual design. And in these cases, this delta was maintained and updated manually.

Updating the Excel-based traceability matrix to reflect changes or new artifacts is always a manual process.

Because this process is not automated, it takes a significant effort and is also highly error-prone. On a small scale, it can be manageable. But once a change is made, managing it effectively in this way becomes a significantly greater problem. We found that these events can exponentially increase both the level of effort needed to maintain traceability and the risk of a negative outcome or occurrence. We’ll provide some examples of this shortly.

As organizations make incremental improvements and changes, or grow and scale the company further, the manual, Excel-based process can become a major bottleneck. Because the level of effort associated with changing this workflow can seem too big of a task to complete, process improvements are de-prioritized. We see an exponential scale difference between an increase in complexity and the difficulty in managing traceability in Excel manually – tightening this bottleneck. Even a slight increase in complexity can lead to a high-severity issue/business impact/time waste.

As an example, let’s take a simpler medical device (a single-use catheter). Here are a few examples of how you could have the traceability schema established:

  • 1-2 levels of requirements traceability (e.g., User Need > Product Requirement > Verification, or User Need > Validation)
  • Few items per level at each level in the hierarchy (e.g., 5 User Needs, 10 Product Requirements, and 1-2 Verifications/Validations)

As described in the example below, this means for simple products like a single-use catheter, there are roughly 225-440 possible trace relationships:

Let’s now imagine that we want to make a seemingly simple change and additional functionality to the device. We want to connect the catheter to a mobile application, so it can monitor its usage and analyze it for diagnostics purposes.

As this device is now part of a “system” with two major sub-system components, we break down the “product requirements” into two separate levels: “system” and “sub-system” requirements.

The complexity associated with managing requirements and maintaining traceability increases exponentially. For example, we’ve outlined a common example of a Class II system, where you can see that a 4x – 10x increase in the number of User Needs translates to a 15x – 24x increase in the total number of trace relationships that need to be managed.

An increase of 4x-10x in the number of User Needs translates to a 15-24x increase in the total number of trace relationships that need to be managed.


Here are a few common real-world scenarios where we see this complexity change occurring; A couple of examples of other complexity increases for a medical device organization:

  • A medical device with a newly added component and functionality (software, electrical, mechanical, hardware, etc.)
  • A research use application (RUO) that is reclassified as an IVD – becoming a diagnostic device
  • A medical device startup going from an R&D phase into having a product out in the market
  • A medical device being implemented into a larger system
  • Expanding into different markets and adhering to new regulations (US FDA, EU MDR, etc.)
  • Introducing product families, product lines, and variations to more effectively reuse existing components

The more this process/tool improvement is delayed, the higher the risk to the business.

We see this happening to medical device companies both big and small. Here are a few of our customers describing the problem.


RELATED: The Strategic Transition: From Word and Excel to Modern Requirements Management


Microsure

“With Word and Excel, if something is changed and a link is broken, that document is gone and it’s literally floating around somewhere in the cloud without linkage to anything. This makes it very scary, especially from a quality or regulatory perspective. Our Word and Excel process evolved with the organization and therefore it was put together layer by layer, making it really hard to have the full depth of knowledge about how the quality system works.” – Rene Wenmekers, Director of Quality & Regulatory, Microsure

“We work in a highly regulated environment, and Microsure’s product has hundreds of requirements on system, subsystem unit, and component levels. And from a regulatory documentation standpoint, information is scattered.” – Robin Brounds, Software Team Lead, Microsure

“When we make changes in medical device development, they need to be reported to the notified body. And when that change hits the level of ‘significant change,’ the whole documentation set needs to be provided to the notified body to be reassessed on safety and efficacy. Every time a requirement changed, it needed to be updated across the whole documentation path. This was not sustainable using Word and Excel, and it was risky.” – Rene Wenmekers, Director of Quality & Regulatory, Microsure

Convergent Dental

While using Word and Excel, Convergent Dental found themselves tracking across multiple documents, all with their own trace matrix tables relating to different requirements. The fallout from this process is that even a single word or letter change in a low-level subsystem requirement led to updating corresponding requirements documents in their trace matrix tables. So, a single letter turns into not one change but potentially six changes across five different documents.

“We have a small team with a large amount of features and updates to perform on an ongoing basis. We all work really hard here, and there’s no option to be dead weight. Getting rid of that wasted time in Word and Excel and getting our test engineers back to work is the ultimate goal.” – Craig Woodmansee, Electrical Systems Engineer, Convergent Dental

NEGATIVE BUSINESS IMPACTS – of not changing

Wasted Time and Inefficient Processes

  1. In a complex setting (working with a complex product, highly regulated environment, high-risk product, cross-functional teams working together, lots of different product variations, target customers/markets, etc.), this can be a person or a team’s full-time effort to keep up to date.
  2. Time is being spent on people trying to find the right and most up-to-date documents
  3. Sitting through review and alignment meetings with all stakeholders

Increased Risk of Negative Outcomes
This process relies on people constantly monitoring and updating each change. If a change goes unnoticed or people forget to update traceability, this gap is difficult to notice. If traceability gaps are noticed later during the product development lifecycle, there is a significant increase in the risk of one of the following negative events happening:

  1. Releasing a faulty & untested product, quality compromise, product callbacks
  2. Forcing organizations into late-stage changes that are costly to implement
  3. Regulatory issues and audit findings (non-conformities, FDA warning letters, etc.)
  4. Product not meeting the original requirements and customer/stakeholder needs

The expected outcome – backfilling documentation and traceability at the very end of the project.

Real outcome – Many issues/gaps went under the radar, leading to project delays, missed deadlines, or regulatory/quality issues:

Decreased Organization Maturity, Disconnected and Siloed Teams

  1. Enforce the defined process – In a document-based environment, it’s close to impossible to monitor and enforce the defined process
  2. Impact on employee tenure – Engineering and R&D are forced into manual documentation instead of actual design & development
  3. Impact on talent acquisition – High-quality talent is more attracted to companies with proper tooling and processes in place
  4. Communication and Transparency – Audit trails and change logs are often lost, hard to keep people accountable for changes

RELATED: Loram Rides the Fast Track to Software Safety with Jama Connect®


SOLUTION

The solution to this problem is having integrated risk management with Live Traceability™ in Jama Connect®. Jama Connect will be the overarching system across all product development initiatives, bringing together all disciplines, making it significantly easier to visualize complex traceability hierarchies, replacing the manual effort needed to keep the documentation up to date, etc.

Jama Connect® brings comprehensive and detailed insights into your complex product, systems, and software development processes – automating the measurement of requirements traceability and coverage across disciplines and your organization’s toolchain.

This level of visibility helps eliminate rework due to out-of-date information; and the biggest fear for engineering leadership – that the greatest risks to a project are unseen until it is too late.


Understanding UN155 and Its Impact on Cybersecurity Management

In the ever-evolving landscape of cybersecurity, staying ahead of emerging threats and regulations is crucial for organizations worldwide. One such regulatory framework making waves in the cybersecurity community is UN155. This post aims to shed light on UN155 and its significance in cybersecurity management.

What is UN155?

UN155 is a regulatory framework established by the United Nations to enhance cybersecurity practices across various sectors. The framework sets forth comprehensive guidelines and standards for organizations to protect their information systems, data, and infrastructure from cyber threats. It emphasizes a proactive approach to cybersecurity, encouraging organizations to implement robust security measures and continuously monitor and adapt to the evolving threat landscape.


RELATED: Jama Connect® for Automotive


Key Components of UN155

UN155 encompasses several critical components designed to strengthen cybersecurity management:

  1. Risk Assessment and Management: Organizations are required to conduct regular risk assessments to identify potential vulnerabilities and threats. This involves evaluating the likelihood and impact of various cyber risks and implementing appropriate mitigation strategies.
  2. Incident Response and Reporting: UN155 mandates the establishment of incident response plans to swiftly address and mitigate cybersecurity incidents. Organizations must also report significant incidents to relevant authorities, ensuring transparency and accountability.
  3. Data Protection and Privacy: Protecting sensitive data is a cornerstone of UN155. Organizations must implement stringent data protection measures, including encryption, access controls, and data minimization, to safeguard personal and sensitive information.
  4. Continuous Monitoring and Improvement: UN155 emphasizes the importance of continuous monitoring and improvement of cybersecurity practices. Organizations are encouraged to regularly review and update their security measures in response to new threats and vulnerabilities.
  5. Training and Awareness: Educating employees about cybersecurity risks and best practices is crucial. UN155 requires organizations to conduct regular training and awareness programs to ensure that staff members are equipped to recognize and respond to cyber threats.

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


The Impact of UN155 on Cybersecurity Management

The implementation of UN155 has significant implications for cybersecurity management:

  1. Enhanced Security Posture: By adhering to the guidelines set forth by UN155, organizations can significantly enhance their security posture. Proactive risk assessments, robust incident response plans, and continuous monitoring contribute to a more resilient cybersecurity framework.
  2. Regulatory Compliance: Compliance with UN155 is not just a best practice; it is often a legal requirement. Organizations that fail to comply with the framework may face legal penalties, reputational damage, and financial losses.
  3. Improved Incident Response: With established incident response plans, organizations can respond more effectively to cybersecurity incidents. This minimizes the impact of breaches and ensures a quicker recovery, reducing downtime and financial losses.
  4. Increased Stakeholder Confidence: Demonstrating compliance with UN155 can enhance stakeholder confidence. Clients, partners, and investors are more likely to trust organizations that prioritize cybersecurity and adhere to recognized standards.
  5. Global Harmonization: UN155 promotes a standardized approach to cybersecurity, fostering global harmonization of security practices. This is particularly important for multinational organizations operating in diverse regulatory environments.

UN155 represents a significant step forward in the global effort to enhance cybersecurity management. By adopting the framework’s guidelines and principles, organizations can bolster their defenses against cyber threats, ensure regulatory compliance, and build trust with stakeholders. As the cybersecurity landscape continues to evolve, frameworks like UN155 play a pivotal role in shaping a secure and resilient digital future.

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

 

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 “What You Should Know About The FDA’s New Final Rule On LDTs” – originally published on May 14, 2024, and written by Mahnu V. Davar, Philip R. Desjardins, Abeba Habtemariam, and Phillip V. DeFedele, Arnold & Porter.

What You Should Know About The FDA’s New Final Rule On LDTs

On May 6, 2024, the U.S. Food and Drug Administration (FDA or the agency) published its highly anticipated final rule, which was formally published in the Federal Register on May 6, revising the regulatory definition of an in vitro diagnostic (IVD) product to explicitly capture IVDs manufactured by laboratories.

This follows the absence of proposed congressional action and the FDA’s review and consideration of comments to the October 2023 proposed rule (described in our prior Advisory on this subject) resulting in modifications to its phaseout policy and continued exercise of enforcement discretion for certain tests. In connection with the final rule, the FDA also issued two draft enforcement policies for certain tests offered in response to emergent situations or public health emergencies (PHEs). Despite the potential for legal challenges to the final rule, clinical laboratories should begin thinking about strategies for evaluating whether their laboratory-developed tests (LDTs) are subject to the FDA’s phaseout policy, determining the extent of FDA requirements that apply to such LDTs, and engaging with the FDA.

What Did the Final Rule Do?

The final rule amended the definition of an IVD in 21 C.F.R. § 809.3 to make clear that these products are devices as defined under the Federal Food, Drug and Cosmetic Act (FDCA), and may also be biological products under the U.S. Public Health Service Act, “including when the manufacturer of these products is a laboratory.” Although not a substantial rewrite of the IVD definition, this added phrase makes FDA’s position clear that LDTs are subject to regulation as, at a minimum, devices.

Why Does This Matter?

Historically, the FDA exercised enforcement discretion for LDTs, declining to impose its device authorities over such tests in most instances. For purposes of this enforcement discretion policy, the agency defined LDTs as IVDs intended for clinical use that were designed, manufactured, and used within a single clinical laboratory certified under the Clinical Laboratory Improvement Amendments of 1988 (CLIA) that meets CLIA regulatory requirements to perform high complexity testing. As such, LDT manufacturers that generally operated outside FDA oversight will now be expected to come into compliance with FDA requirements and controls applicable to their tests. In consideration of this substantial operational and compliance burden, the preamble to the final rule details a phaseout policy under which FDA will gradually end its general LDT enforcement discretion policy in five phases over a four-year period.


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


What Tests Are Subject to the Phaseout Policy?

The phaseout policy generally applies to LDTs as defined above, as well as “IVDs offered as LDTs,” meaning tests that are manufactured and offered as LDTs by CLIA-certified laboratories that meet CLIA requirements to perform high complexity testing and that are used within such laboratories, even if they do not fall within FDA’s historical understanding and definition of an LDT because they are not designed, manufactured, and used within a single laboratory. Thus, the policy technically applies to a broader range of tests than those that actually meet the FDA’s definition of an LDT. However, despite this breadth, the final rule makes clear that the phaseout policy does not extend to IVDs manufactured or used outside of a laboratory, including collection devices.

Consistent with the proposed rule, FDA made clear that certain tests would be excluded from the phaseout policy and subject to immediate regulation since they were never eligible for enforcement discretion:

  • Direct-to-consumer tests
  • Tests intended as blood donor screening or human cells, tissues, and cellular and tissue-based products donor screening tests required for infectious disease testing under 21 C.F.R. § 610.40 and 21 C.F.R. § 1271.80(c), respectively, or required for determination of blood group and Rh factors under 21 C.F.R. § 640.5
  • Tests intended for actual or potential emergencies or material threats declared under Section 564 of the FDCA

Further, the final rule confirmed that the FDA would continue exercising enforcement discretion (and thus not apply device requirements) to the following tests originally described in the proposed rule:

  • “1976-Type LDTs” (i.e., tests that use manual techniques without automation performed by laboratory personnel with specialized expertise, use components legally marketed for clinical use, and are designed, manufactured, and used within a single CLIA-certified laboratory meeting CLIA requirements for high complexity testing)
  • Human Leukocyte Antigen (HLA) tests that are designed, manufactured, and used within a single CLIA-certified laboratory meeting CLIA requirements for high complexity histocompatibility testing and used for HLA allele typing in connection with organ, stem cell, and tissue transplantation, HLA antibody screening and monitoring, or conducting real and “virtual” HLA crossmatch tests
  • Tests intended solely for forensic or law enforcement purposes
  • Tests used solely for public health surveillance when intended solely for use on systematically collected samples for analysis and interpretation of health data for disease prevention and control and the test results are not reported to patients or their healthcare providers

Notably, in consideration of comments and other feedback, FDA decided to continue to exercise full or partial enforcement discretion for the following tests:

  • LDTs manufactured and performed within the Veterans Health Administration or the Department of Defense (full enforcement discretion continues)
  • LDTs approved by the New York State Clinical Laboratory Evaluation Program (enforcement discretion continues for premarket review requirements)
  • Non-molecular antisera LDTs for rare red blood cell antigens where such tests are manufactured and performed in blood establishments, including transfusion services and immunohematology laboratories and where there is no alternative available to meet the patient’s need for a compatible blood transfusion (enforcement discretion continues for premarket review requirements and all Quality System (QS) requirements other than the recordkeeping requirements at 21 CFR 820 (Subpart M))
  • Currently marketed IVDs offered as LDTs that were first marketed prior to the date of issuance of the Final Rule (May 6, 2024) and that are not modified or are modified in certain limited ways (enforcement discretion continues for premarket review requirements and all QS requirements other than the recordkeeping requirements at 21 CFR 820 (Subpart M))
  • LDTs manufactured and performed by a laboratory integrated within a healthcare system to meet an unmet need of patients receiving care within the same healthcare system (enforcement discretion continues for premarket review requirements and all QS requirements other than the recordkeeping requirements at 21 CFR 820 (Subpart M))

For those tests subject to only partial enforcement discretion, the final rule makes clear that all other requirements would apply as they are phased-in under the general phaseout policy for all IVDs offered as LDTs.

What Is The Phaseout Policy?

The phaseout policy consists of the following five stages, which start on May 6, 2024:

Stage 1: FDA will end the general enforcement discretion policy as to medical device safety reporting, correction, and removal requirements, and QS complaint file requirements one year after the publication of the final rule. Thus, manufacturers of all IVDs offered as LDTs that are not subject to the FDA’s continued exercise of full enforcement discretion must come into compliance with these requirements by May 6, 2025.

Stage 2: FDA will end the general enforcement discretion policy as to all other medical device requirements, except for QS and premarket review requirements, two years after publication of the final rule. Therefore, manufacturers of all IVDs offered as LDTs that are not subject to the FDA’s continued exercise of full enforcement discretion must come into compliance with these requirements by May 6, 2026.

Stage 3: FDA will end the general enforcement discretion policy as to the following QS requirements three years after the publication of the final rule: (1) design controls (21 C.F.R. § 820.30); (2) purchasing controls (21 C.F.R. § 820.50); (3) acceptance activities (21 C.F.R. §§ 820.80 and 820.86); (4) corrective and preventative actions (21 C.F.R. § 820.100); and (5) records requirements (21 C.F.R. Part 820, Subpart M). As such, manufacturers of all IVDs offered as LDTs that are not subject to the FDA’s continued exercise of full enforcement discretion or partial enforcement discretion as to certain QS requirements must come into compliance with these requirements by May 6, 2027.

Stage 4: The FDA will end the general enforcement discretion policy as to premarket review requirements for high-risk IVDs (i.e., Class III IVDs or IVDs subject to Biologics License Application requirements) three and a half years after publication of the final rule. Manufacturers of all IVDs offered as LDTs that are not subject to the FDA’s continued exercise of full enforcement discretion or partial enforcement discretion as to premarket requirements must come into compliance with these requirements by November 6, 2027. Notably, on its media call regarding the final rule, the FDA stated that it intends to complete the reclassification of certain Class III IVDs to Class II IVDs in advance of this deadline, thus lessening the number of PMAs that will be submitted. We further discuss this initiative and its potential relation to the final rule in our related Advisory on this topic.

Stage 5: The FDA will end the general enforcement discretion policy as to premarket review requirements for all remaining IVDs requiring FDA review unless otherwise noted by the FDA (i.e., some Class I and all Class II IVDs) four years after publication of the final rule. Manufacturers of all IVDs offered as LDTs that are not subject to the FDA’s continued exercise of full enforcement discretion or partial enforcement discretion as to premarket requirements must come into compliance with these requirements by May 6, 2028.

Overview Of Test Types And Status

What About The Draft Public Health Emergency Guidance?

Although the draft PHE policies both address certain tests offered in response to emergent situations or public health emergencies, one relates to tests offered prior to issuance of a declaration under Section 564 of the FDCA while the other relates to tests offered during a declared emergency. These are notable because the FDA explains in the final rule that its general enforcement discretion policy for LDTs never applied to tests intended for emergencies, potential emergencies, or material threats declared under Section 564 because false results can have serious implications for disease progression, public health decision-making, and patient care. Instead, after all previous declarations under Section 564, the FDA has generally expected LDTs to comply with applicable requirements of the FDCA and FDA regulations. However, FDA has adopted, and may continue to adopt, specific enforcement discretion policies for such tests.

FDA’s draft Enforcement Policy for Certain In Vitro Diagnostic Devices for Immediate Public Health Response in the Absence of a Declaration under Section 564 sets forth FDA’s enforcement policy for “immediate response” tests for use in an emergent situation (i.e., the period of time between detection of the exposure or outbreak and either resolution of the exposure or outbreak or issuance of an applicable Section 564 declaration). Notably, the policy only applies to premarket review requirements and does not extend to tests with home specimen collection or at-home tests.

Under the policy, FDA does not intend to object to the offering of “immediate response” tests when:

  • The test is manufactured and offered by laboratory manufacturers meeting certain criteria
  • The test has been appropriately validated
  • FDA is notified
  • Appropriate transparency is provided
  • The test is labeled for prescription use only
  • There is no applicable Section 564 declaration

If no applicable Section 564 declaration is made within 12 months of the start of an emergent situation, FDA anticipates that the public health rationale for the enforcement policy will no longer apply at that time. FDA would then expect the laboratory manufacturer to cease offering the immediate response test or seek approval/clearance/authorization. FDA does not intend to object to the continued offering of an immediate response test while the premarket submission is prepared, submitted, and under FDA review so long as the laboratory manufacturer submits the submission within 12 months from the date of the first offering of the immediate response test.

FDA’s draft Consideration of Enforcement Policies for Tests During a Section 564 Declared Emergency, when finalized, will describe the factors FDA plans to assess in deciding whether to issue an enforcement policy regarding test manufacturers’ offering of certain devices (i.e., unapproved tests and unapproved uses of approved tests) for the diagnosis of disease or other conditions during a declared emergency. FDA intends to assess, among other things:

  • The need for accelerated availability of such tests
  • The known or potential risks of such tests
  • The availability of appropriate alternative tests that are authorized or approved
  • The availability of sufficient mitigations to address the risks of false results

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


What’s Next?

FDA intends to conduct webinars, publish guidance documents, provide templates, and participate in conferences to help laboratories understand and comply with applicable devices. We also think it likely that the FDA will increase inspections of laboratories offering IVDs as LDTs where the agency has identified or received concerns regarding their quality or accuracy and will start enforcing the FDCA against laboratories and similar entities perceived to be abusing the agency’s Research Use Only/Investigational Use Only policy or not complying with Investigational Device Exemption (IDE) requirements. As we noted in our Advisory on the October proposed rule, the FDA also has identified a number of test types that the agency believes present a higher risk of patient harm when run as LDTs (according to the agency, these include tests such as non-invasive prenatal screening).

Pre-submission meetings, pre-IDE meetings, and other FDA engagements related to data generation, regulatory pathway clarification, and classification will likely increase. The industry will need to closely watch the steps the FDA takes to lessen the burden of the final rule, such as the noted reclassification process, as well as any potential personnel or structural changes, and future funding requests. As the final rule preamble discussion notes, the alignment of the phaseout policy to coincide with the next round of Medical Device User Fee Amendments reauthorization suggests that the agency understands that it will have to carefully evaluate the burden of this exceptional expansion of FDA authority in terms of protecting the public health while not slowing down the availability of key diagnostic advancements to aid patient care.

We anticipate that laboratories and other affected entities will consider pursuing legal action against the agency, arguing that the FDA lacks authority to regulate LDTs and seeking to enjoin the agency from implementing the final rule. The preamble discussion attempts to anticipate and resolve a number of the key challenges raised in comments to the proposed rule, such as important legal questions about FDA authority under the Federal Food, Drug, and Cosmetic Act, interstate commerce concerns, limits on regulation of state-licensed actors, and many other salient issues. FDA clearly is of the view that public health exigencies outweigh the litigation risks, and the final rule phaseout policy and other enforcement discretion positions are sufficient to balance the interests of industry, patients, and the agency.

It remains to be seen what actions Congress may take now that the FDA has articulated a final position on this topic. Although Congress has taken an interest in the regulation, and lack thereof, of LDTs, including holding a recent hearing, a legislative solution that would potentially supersede the final rule is uncertain, if not unlikely in the near term. Therefore, given the current state of affairs, it is important for laboratories offering LDTs to begin strategizing on how they will address the final rule and FDA’s phaseout policy.

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 Engineering News-Record, titled “ENR 2024 Top 500 Sourcebook: Plant Tests Ocean Carbon Dioxide Removal” – originally published on July 16, 2024, and written by David Godkin.

ENR 2024 Top 500 Sourcebook: Plant Tests Ocean Carbon Dioxide Removal

Arup begins feasibility study of commercial-scale facility set for Canada site

Engineering has begun on a project its developers say could mark a new foray into ocean-based carbon dioxide removal.

The Quebec-based plant would be North America’s first commercial-scale, ocean-based carbon dioxide-removal facility, according to startup developers Equatic Inc., based in Los Angeles, and Deep Sky Inc., a Montreal firm. They say the facility would remove nearly 110,000 tonnes of carbon dioxide from the atmosphere annually—10% of which will be ocean-borne emissions. It also would produce 3,600 tonnes of hydrogen.


RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Oil & Gas


The plant technology uses a seawater electrolysis process developed at the UCLA Samueli School of Engineering’s Institute for Carbon Management. The system draws ocean seawater into an electrolysis chamber where carbon dioxide molecules are separated from the water and its natural acidity is neutralized. “This in turn allows the ocean water to draw down more CO2,” says Phil De Luna, Deep Sky chief carbon scientist and head of engineering. “These carbon emissions are some of the hardest to abate and most difficult to electrify.”

Extracted carbon dioxide is stored in the form of solid calcium and magnesium-based substances that the firm says could be used to produce construction materials.

The technology is based on a $20-million demonstration plant, called Equatic-1, which is set to commission next year in Singapore in collaboration with its national water agency, the developers said.The commercial plant will have easy access to the ocean-connected St. Lawrence River, and could tap into Quebec’s massive hydroelectric grid.


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


The facility would use less than 1.4 MW hours per ton of carbon dioxide, with removal cost estimated at less than $100 per ton by 2030, according to Equatic. Luna estimates the project’s cost at about $366 million. The plant may also be in line for carbon removal credits under a new U.S. Energy Dept. program, Equatic says, noting that such credits, as well as green hydrogen from this plant and future ones “have been pre-sold to companies such as Boeing, and further sales are ongoing.”

Engineering firm Arup has just begun a six-month plant feasibility study that is set to launch front-end engineering design work, environmental assessment and permitting, with a final investment decision estimated at the end of 2026.

If affirmed, construction on a 30-acre site would begin shortly after, with startup set for 2028. Deep Sky is currently exploring a plant location about 900 km northeast of Montreal, with a final site decision to be made by the end of 2024, the firm says.

Jama Connect® Features in Five: Cameo Systems Modeler 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, Gary Hayes, Senior Solutions Architect at Jama Software® – will demonstrate the Cameo Systems Modeler integration with Jama Connect®.

VIDEO TRANSCRIPT

Gary Hayes: Hello, and welcome to the Features in Five Integration series. My name is Gary Hayes, and I am a Senior Solutions Architect at Jama Software. Today, we will be walking through the Cameo Systems Modeler integration for Jama Connect. 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 start off today by looking at the two environments that we’ll be working with, Jama Connect and Cameo Systems Modeler. In Jama Connect, in our project here, we have a folder called swarming along with five requirements we’ve identified that we wanna be using. If we look over the Cameo System Modeler, you notice that we have the same folder, but we only have four requirements listed there.


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


Hayes: We can easily compare the items that exist in both environments, the four that you see here. We go into the plug-in that we’re using, identify the SysML repository, and we drill down on that folder that contains those requirements, and we can do a comparison between the source and the target. The plug-in will do the comparison for us. We don’t have to drill down and do a close examination.

When we get our results, we see that everything is green, indicating to us that the items in the folders that have been synchronized indeed match at this point. We can close this out for the time being, but you’ll keep in mind that we only have four requirements in Cameo, but we have a fifth one that does not exist currently in Cameo that is in Jama Connect. So we want to make sure that both environments do indeed match, and we can do that easily by dragging and dropping using that same plug-in.

We go back into our dashboard. We find our SysML repository, and we find our Jama Connect project that we’re working with. Drill down on that to find those requirements that currently are being synchronized between the two environments. We can easily see that we have the swarming folder along with its five requirements from Jama Connect and four from our Cameo environment. And to match those up, we want to drag and drop this into our Cameo environment.

And you’ll notice over here as it brings that over, you notice in the background, the cameo environment updates automatically to reflect the fact that we’ve brought a new requirement into the cameo environment. We can further confirm that by doing a synchronization check, doing that comparison once again at the folder level, compare our source and target, and hopefully, we’ll get all green one more time to show that the environments do indeed match up. But we don’t always have the luxury of dragging and dropping and never making any changes in any environment, so what we’ll want to do is make a change in one environment and push that from one side to the other. So let’s go into this individual requirement, broadcast to Swarm, and it’s annotated that it is indeed from Jama Connect. So we’re gonna remove that annotation in its title.


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


Hayes: We’ll go ahead and save that in our Jama Connect environment. You’ll notice that’s updated. Now we want to be able to show that same type of update. We’ll do that comparison first to see where we’re at because we never know when changes will occur. We can do our compare, make sure that comparison actually works, and flag us for a change. And indeed, we do. It comes up as pink or red, depending on your monitor, and flags us that there has been a there’s a discrepancy between the two environments. And you’ll notice too that it does the comparison. It doesn’t automatically make the change, and you can see that in the background. And in our Cameo environment, that change has not rolled over from Jama Connect to Cameo. So let’s make that change, permanent now. Let’s go ahead and do that push. We can push from our target to our source.

Keep your eyes on the Cameo environment in the background. As we make that change and it gets pushed over, you’ll notice that the name or the description of the requirement in Cameo indeed has changed, and so that has been updated automatically for us. We can do one last check with our compare tool, comparing source and target. So we get all green just for one additional factor of confidence that we get there, and you can see it there. So that’s one way to keep your Cameo and Jama Connect environments in sync using a plug-in.

Thank you for watching this Features in Five session on the Cameo Systems Modeler 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 visit 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