FDA Moving Ahead with Rulemaking On Lab Developed Tests Without Waiting for Congress: BioWorld
Dive Brief:
The U.S. Food and Drug Administration is “moving forward with rulemaking” on laboratory developed tests (LDTs) without waiting for new powers from Congress, a senior FDA official said at an industry conference.
Elizabeth Hillebrenner said on a panel Wednesday that the agency cannot “just stand by” given the perceived public health problem created by LDTs and the failure of Congress to pass legislation.
The FDA has yet to set a timeline for LDT rulemaking or provide a close look at its plans, Hillebrenner said, noting that the agency will follow a three-tier risk framework, but giving few other details.
Lawmakers have been trying to pass LDT legislation for years. An earlier form of the Verifying Accurate Leading-Edge IVCT Development (VALID) Act was introduced to Congress in 2018. Key aspects of the draft advanced as part of the FDA’s user fee package last year, only to be cut from the final version. A push to pass the VALID Act as standalone law fell short late last year.
The FDA identified a need to reconsider its policy of enforcement discretion for LDTs in 2010, reflecting the increasing complexity and risks of the tests, and shared a discussion paper in 2017. However, the paper is not enforceable.
Legislation would clarify the FDA’s authority to regulate LDTs and give the agency new powers, but in the ongoing absence of action from Congress, work is now advancing under the current statutory authority. Hillebrenner, associate director for scientific and regulatory programs at the FDA’s Center for Devices and Radiological Health, outlined the situation at an American Clinical Laboratory Association event.
In comments reported by BioWorld, Hillebrenner noted that FDA Commissioner Robert Califf “has already said all options are on the table, including rulemaking, and we are moving forward.” The FDA continues to support legislation such as the VALID Act that provides a regulatory framework in line with modern diagnostics but is no longer willing to wait on Congress to address the problems posed by LDTs, she said.
https://www.jamasoftware.com/media/2023/04/BioWorld-1.png5121024Jama Software/media/jama-logo-primary.svgJama Software2023-04-26 03:00:592024-01-18 00:25:46FDA Moving Ahead with Rulemaking On Lab Developed Tests Without Waiting for Congress: BioWorld
In this blog, we recap the “An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Diagnostics Regulation (IVDR)” webinar.
Looking to stay ahead of ever-evolving regulations governing medical devices?
In this webinar, we discuss the continual rollout of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR) and the impact they’re having on the medical device industry.
Vincent Balgos, Director of Medical Device Solutions at Jama Software and Saby Agai, Sr. Consultant at Jama Software, provide a high-level overview of the new regulations, along with general industry observations and future considerations for organizations with medical products marketed in the EU market area, including:
New classifications, grandfathering clause, and risk management requirements
The number of notified bodies, backlog, and remediation efforts for placed products
Future considerations regarding the compliance compatibility of IVDR & FDA and traceability
Finally, learn how the Medical Device Framework in Jama Connect® can help streamline your compliance efforts and ensure your products meet all the necessary regulatory requirements.
Below is an abbreviated transcript and a recording of our webinar.
Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System
Saby Agai: So, in the first part of the webinar we will talk about the EU medical device regulations. There is a small agenda to that. Basically, we would like to show the key changes and challenges that the MDR means compared to the MDD. We would also like to talk a little bit about what we see as the challenges for the process transformation of the medical device developers and also a bit of discussions with the race on the timeline for the MDR. The second section is on the MDR for the MedDev engineering. So basically, how the engineering teams can do anything with the MDR. We’ll talk about harmonized standardization. How does that fit in the concept of the MDR? And some of the medical device best practices that we would recommend. So the medical device regulations now has quite a bit of history because the MDR is valued also for existing [inaudible 00:04:15] devices and also for all the new devices.
The medical device regulations entered into force historically in May 2017, and there was a bit of extension period in 2020 that the certificates issued under the MDD before the MDR remained valid up to four additional years. So it was a bit of a time extension for manufacturers to migrate the legacy devices to the MDR. Recently 2023, the EU commission had the new rule based on 607 was the number of it on the time extension for the medical device regulations. So there are two-time extension now in force for December 2027 and 2028 for all devices. As part of this modification, the commission removed the sale of period from the original context of the Medicaid device regulation.
Three key area that we would mention that we see as key challenges with the MDR is first is the technical documentation. So because of the legacy medical devices has to be reclassified in a context of the new MDR, those manufacturers highly likely will face it extended set of documentation for market clearances in the EU. It’s particularly true for software as a medical device because, basically the class one level has removed by legislation for all software as a medical device. The other thing on the technical documentation is that the MDR is far more prescriptive about the requirement content of the technical documentation, and it’s particularly true and there are more detailed requirements needed for the quality management system. So the manufacturer will have to ensure that they not only have full access and control for the documentation of the device, but also they should keep the eye on the market and the vigilance market, post-market vigilance area, as well as publication or new common specifications.
Agai: So there is a bit of higher focus on the post-market activities in the context of the MDR. And the technical documentation basically has two key parts in Annex II, annex III it’s detailed. Annex II there is a list of requirements for the technical documentation itself for the device design, and also, in Annex III, we see details or requirements for technical documentation post-market surveillance. So nothing particularly new, only an extended set of expectation and requirements for all these contents. Little note something on the technical documentation. So historically, the technical documentation has a tradition to be seen as a burden on the med tech developers and additional administrative work. And quite often, at the end of the development cycle, there is a massive effort made to make what is documentation available for regulators and also for market clearance. It definitely could require very intense administrative work from the engineering sometimes stress involved and also, the content creation has not much help or not much support for the regional engineering activities, which is the development.
So these content created purely to support the market access activities and it should not necessarily should be a case, though. So, for example, we in Jama has a medical solution. It’s a example proven a tool actually can support both med tech developers to enhance the development efficiency as they develop a new device as well as to support these technical documentation needs at the same time. So it’s a opportunity also for organizations to get most out of using a tool when they thinking about to ease the burden of the medical device regulation technical documentation part.
Agai: Thirdly but not lastly, there was a new, particularly in EU requirements for the unique device identifier. So basically, 2021 was a deadline to register an MDR UD MDR devices with the UDI in the [inaudible 00:09:02] framework, and for the IVDR, it’s 2022. Looking into purely on the numbers, we could say that the content of the MDR compared to the MDD is actually four time heavier. So the extent and the legal tax basically is four time more. There are five plus on axis that we can see, and there is a special attention on safety and patient safety particularly because 293 times mentioned the safety word in MDR where in the MDD was the 24. All these numbers also telling that the regulators in EU want to have higher scrutiny compared to the MDD, and they also have more details on that level of expectation that they would like to see from manufacturer. And there is a definite focus on patient safety that we can see.
Two more things to mention is that quite often, in the context of the MDR, the legacy devices should be reclassified into a higher level class. So it means that the quality management process support is more intense, and more support expected. More activities and works are expected from the manufacturer to keep the same device basically on the market. It also could mean that companies should take a step for high-level maturity as an organization and it’s true also for the design and device development activities. So one of the challenge with that is that if we talk about the same device with higher regulatory scrutiny, how do we retain and enhance profitability? Because the administrative burden is definitely something that goes towards the cost part of the profitability. So the design and development goes under higher level of process expectation in that sense, and it goes higher level of design documentation needs as well. So one of the advantages using the tool in general medical device environment that the medical solution can ease actually this work and enable a bit quicker, and the developers can leverage a little bit more help on these challenges.
https://www.jamasoftware.com/media/2023/04/BLOG-RECAP-Medical-Device-Webinar-Social-Image.png5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2023-04-20 03:00:122024-01-18 00:27:52[Webinar Recap] An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR)
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 Class I Recalls Hit 15-year High in 2022” – originally authored by Nick Paul Taylor and published on March 3, 2023.
FDA Class I Recalls Hit 15-year High in 2022
Dive Brief:
The number of Class I medical device recalls by the U.S. Food and Drug Administration hit a 15-year high in 2022, according to a report by Sedgwick.
In 2022, the FDA oversaw 70 Class I recalls, its highest risk classification, compared to an average of 47 over the previous five years. Eighteen of the Class I recalls happened in the fourth quarter.
Mislabeling was the most common reason for recalls in three of the past five quarters.
Last year, companies including Abbott, Baxter, GE HealthCare, Medtronic and Philips were the subject of Class I recalls, a category that the FDA reserves for problems with the potential to cause serious injury or death. The activity added up to a record year for Class I recalls.
Sedgwick reported the 15-year high for Class I recalls after tallying up the data for the fourth quarter. Over the final three months of the year, the total number of recalls of any type rose 8.1% sequentially, and the number of recalled units increased by around 10 million to 61.98 million.
Mislabeling was again the most common cause of recalls in the fourth quarter, as it has been for three of the past five quarters, followed by quality. There was a decline in the number of recalls related to software, the most common cause of recalls in the third quarter. Having been responsible for 46 events over that prior period, software accounted for 15 recalls in the final three months of the year.
Based on data for January, the increase in recalls between the third and fourth quarter may continue in 2023, the report said. Sedgwick counted 135 recalls in January, compared to a monthly average of 80 in the fourth quarter. The number of recalled units is also tracking above the rate seen in the fourth quarter.
Sedgwick identified the FDA’s use of Section 518 authority, which allows it to order manufacturers to notify patients and providers of risks, as one of the most significant developments in medical device recalls. The FDA used the power one year ago to order Philips to tell patients about its respiratory device recall because the company’s efforts to that point had been “inadequate,” the agency said.
https://www.jamasoftware.com/media/2023/04/FDA-Recalls-1.png5121024Jama Software/media/jama-logo-primary.svgJama Software2023-04-13 03:00:262024-01-18 00:31:35FDA Class I Recalls Hit 15-year High in 2022
Digital Transformation of Verification Process for Faster Aircraft Certification
The certification of new aircraft programs is expensive. Whether it is an advanced air mobility system, a (hybrid-) electric aircraft or a military aircraft with new weapon systems, new and innovative aircraft programs are very complex. The application of new materials, additive-manufactured structures, electrical propulsion systems and an increase in onboard software requires extensive virtual and physical testing to verify whether the aircraft is safe, reliable and cost-effective to fly.
Managing verification from the start of the program, as soon as the requirements have been defined and validated, is a good practice. As the verification job is huge, especially for start-up programs, a digital verification management platform can significantly reduce the risk and related over-budget costs of aircraft certification.
Challenge – Aircraft Complexity
There’s a reason why airplanes are the safest mode of transportation: certification. For aerospace manufacturers, aircraft certification is everything. No certificate means no product to market.
In addition to already strict EASA, FAA, and other regulations, companies face additional demands for advancements, including – but not limited to – sustainability targets and the ambition to fly autonomously, which require more integrated systems driven by software and electronics.
New technologies like this are exponentially complex. They impact all aspects of product development, including design, validation, and testing. Instead of a few components and hundreds of interfaces, there are now thousands of components with tens of thousands of interfaces. More and more functions are implemented through software.
Therefore, it’s no surprise that today, aircraft certification is more costly than design. This is a huge challenge. Many companies have great ambitions with new aircraft configurations. It is now technologically and financially feasible to build and fly prototypes and validate concepts. The big financial challenge and risks that a company faces are the costs of aircraft certification and industrialization. Indeed, Porsche Consulting estimated in 2018 that the series development and type certification of an eVTOL urban air mobility aircraft would cost between $500 million and $1 billion1, and Archer Aviation CEO Adam Goldstein says, “the price-tag for one aircraft design to reach certification could be up to $1 billion”.2
This represents a serious risk to many companies. As an aeronautical engineer, I cannot be more delighted when I see all the initiatives taken to exploit the possibilities of new propulsion systems into radical new aircraft configurations. In that sense, the last 5 to 10 years are comparable to the 1950s, when a lot of new aircraft configurations were explored. However, I’m worried that many companies with exciting new ideas will financially fail before getting aircraft certification.
One should not forget that many of these companies have to build the elements for proof of compliance from a blank sheet. They cannot count on data from previous programs to alleviate the verification process by comparison. This puts them at a competitive disadvantage against legacy companies, which might be less innovative but have an abundance of verification data at hand.
Because of the above, new organizations tend to postpone addressing the verification and certification aspects.
Opportunity – Certify During Development
Digitalization environments offer a lot of capabilities to pre-empt the aircraft certification aspects and associated risks.
Process-wise, companies should consider including the verification and certification process within the aircraft design, development production and quality process from the start of the program.
Different digital platform pillars are key in this.
It Starts with the Digital Twin
Throughout the development of aircraft, digital twin capabilities make it possible to design, engineer and optimize the aircraft and its systems. They provide engineering insight into how the aircraft is built and how it performs behaviorally. The use of a digital twin model enables manufacturers to become exponentially more accurate in all aircraft domains, covering all “engineering physics,” which define how well it operates.
Given good management and validation of the modeling assumptions, these digital twin models can be further exploited to verify the behavior of electro-mechanical systems, coupled to the software-based control functions. Indeed, once one gets confidence in how well the models represent reality, these models can be used to perform virtual testing and alleviate the burden and costs of physical testing.
The ability to author these virtual test models is dependent on having the necessary skill tools for generating the engineering analysis data.
An additional benefit of digital twin models is that they not only help with accelerating the verification based on virtual testing, but they also have an under-recognized value in preparing and de-risking the physical tests, which will be needed anyway.
Indeed, as long as innovation continues to occur in this industry, it will be necessary for companies to prove the accuracy of their modeling assumptions, methods, and processes to aircraft certification authorities and organizations.
Digital twin technology is essential when programs want to reduce the risks related to aircraft certification. However, there is a closed-loop process needed between virtual and physical testing in order to make this a viable strategy.
The amount of engineering analysis data a digital twin generates is enormous and requires a digital data and process management backbone to control it, keep it in configuration, manage the processes and make sure all data is traceable.
This backbone is also very important for the next programs. Indeed, stored data does not only serve current programs, but also can be reused in future programs to avoid verifying aspects multiple times on different programs. This drastically reduces verification costs of future programs, whether by simply re-using data or proving digital twin modeling assumptions were right and avoids physical verification on these aspects on the next program.
Digital Thread
The generation of engineering data using digital twin technology along with excellent data management is a start, but to be truly effective, the digital platform needs to keep all data generated and managed in the context of the aircraft program, as it assures the digital continuity of engineering data with the engineering decisions taken. As part of a model-based systems engineering (MBSE) approach, a verification management digital thread can provide a traceable link between the requirements and the artifacts that lead to the proof of compliance of that requirement, including all its intermediate data like the eBOM, test-BOM, etc.
Solution – Verification Management
A verification management digital thread should be a vital part of the digitalization strategy of all aerospace and/or defense companies. It can help make certification an integral part of the overall product development process and enable companies to have a robust certification execution plan and incorporates all the needed certification activities within the overall program plan.
It is vital that companies embrace not only a verification management digital thread, but also a full digitalization strategy. Digitalization enables aerospace manufacturers and their supply chain partners to make better-informed decisions based on extensive data and analysis as well as full traceability. It is the only way to turn the increased level of complexity and integration inherent in new programs into a competitive advantage.
The aerospace and defense industry is going through a time of immense innovation, and I’m excited to see what the future holds as A&D companies and teams of all sizes adopt digitalization to deliver on the promise of this innovation.
References
1. The Future of Vertical Mobility, Sizing the market for passenger, inspection, and goods services until 2035, A Porsche Consulting study, 2018
2. Can UAM developers turn their electric dreams into a reality? Pilar Wolfsteller, 2022
About the Author
Thierry Olbrechts is the Director of Simcenter Aerospace Industries Solutions, Siemens Digital Industries Software. In 1996, he joined Siemens Digital Industries Software. Since 2000, Thierry has been responsible for Siemens simulation and test business development and go-to-market strategies for the aviation, space and defense industry segments.
https://www.jamasoftware.com/media/2023/03/Digital-Transformation-of-Verification-Process-for-Faster-Aircraft-Certification.png5121024Jama Software/media/jama-logo-primary.svgJama Software2023-04-04 03:00:212024-01-18 00:35:25Digital Transformation of Verification Process for Faster Aircraft Certification
In this blog, we recap the “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System” webinar.
In this webinar, “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System”, learn about the implementation of the Threat and Risk Analysis (TARA), the centerpiece of the new Automotive Cybersecurity standard ISO 21434.
Many companies currently use spreadsheets to develop TARAs, which can be challenging when managing large sets of requirements across distributed teams and car line variants. In this webinar, we’ll examine why a requirement management system (RMS) is well-suited to manage the TARA work product and can make a significant impact on managing this data across teams, supporting compliance audits, and assessments.
Attendees will gain insights into TARA’s complexities and how the right tooling solution can make a difference in managing this data across teams, supporting compliance audits and assessments.
Key Takeaways:
The Threat and Risk Analysis or TARA is the centerpiece of the ISO 21434 Automotive Cybersecurity standard
Overview of TARA
ISO 21434 compliance requirements when implementing TARAs
Why an RMS is well-suited to manage TARAs
Below is an abbreviated transcript and a recording of our webinar.
Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System
Kevin Dibble: Thanks, Juliet. Okay. I’m going to just go through the agenda and then get right into 21434. I’ll start with a high-level introduction and then get into the focus of our topic today, which is the threat and risk analysis, which is a centerpiece of 21434, also known as the TARA. And then make an argument for the management of a TARA using an RMS or a requirement management tool. And then Steve will take over and talk about what that would look like in Jama software and summarize with some key points of managing TARAs in Jama versus some traditional methods. And then we’ll have time for some questions.
So with that, again, this is going to be a very high-level overview of 21434. I have a feeling that some of you have worked in cybersecurity for some time, others are just brand new to the term. And so, I want to touch on this as a basis for the rest of the discussion.
And so, first, what is 21434? It is the automotive industry standard for developing cyber secure systems. After several years of review, it was approved in August of 2021 as the method for developing cyber secure systems. In terms of the standard itself, it’s structured and uses a lot of the same terminology as the functional safety standard called ISO 26262. So if you’re familiar with functional safety, then this standard will make a lot of sense the way that it’s organized. Some of the terms such as an item definition, a concept phase, a cybersecurity goal, even TARA parallels functional safety terms like functional safety concept, functional safety goals, or the HARA, Hazard and Risk Analysis. And so, that’s just a reference point as you’re learning about this new standard. Now as far as its scope, it covers or it applies to passenger vehicles and cargo vehicles.
So just a little bit different than ISO 262 there, passengers would include buses, commercial or non-commercial. I think even tripods and some of those other types of motorcycle hybrid type of devices are in or vehicles are in scope as well. It applies to series production and it uses a lifecycle that starts at the request for a quotation for an item. And I’ll define that in a little bit and goes all the way through to the end of cybersecurity support. So like functional safety, we’re not talking about supporting the risks and the hazards associated in this case with threats from attackers leading up to SOP, but it extends far past that. In fact, in 21434, instead of using the term SOP or start of production, which is a critical milestone in any automotive product development program, they call that milestone the release to post-development.
Dibble: And I want to camp on that for just a second because it raises a really important point and it’s very relevant to what we’re going to talk about regarding the TARA. Release to post-development. So the automotive industry is under a lot of change and OEMs want to be or are becoming mobility providers and services will be sold after the car is released. And some of those services weren’t even imagined at the time the car was sold. That’s so different than where the automotive industry was even five years ago. And this standard recognizes that and embraces it along with another important concept, which is that the world of cybersecurity and the landscape for threats and the technologies and the tools that are used to attack vehicles is constantly changing. And so, at the release to production, what is assumed to be protected in terms of say a set of cryptographic keys or a communication bus might be more vulnerable in five years than it was when the car was released because of new techniques, new methods, new tricks, new hacks, and other things that have been discovered.
And so, that’s an important concept because it feeds to our idea that we’re going to get into about the TARA as a living document, as a living asset that begins all the way at the concept phase at the beginning of the high-level architectures of the item or the system in the car. And extends all the way until the end of life for cybersecurity support, which is 10, 15 years down the road. Now, the 21434 has both requirements for developing cyber secure systems, is kind of what I’m showing you on the right, but it also has process requirements. And to that end, there is an audit of the process and an assessment of the results of your project according to 21434. That assessment piece is important for our discussion because when we think about the TARA and the pieces of it or the items of the TARA, then we have to think in terms of what are the evidences we need to leave behind and produce in order to pass an assessment, very important consideration.
Dibble: And so, we have audits for the processes and then assessments for the end result. So that’s very brief overview of 21434. I want to make sure I leave you with the… If you remember anything about 21434 besides the TARA, you’ll hopefully remember this, is to manage unreasonable risk of damage to road users due to a malicious attack to a vehicle or a vehicle data, confidentiality, integrity and availability. Let me unpack that for just a second. Unreasonable risk, this is when you get into a car, when you operate a vehicle, you assume some risk. But that risk doesn’t include driving down the highway at 70 miles an hour, turning right and the car going left or the headlights going off while you’re on the highway at night. It applies to road users. That’s the people that use the road, the driver, the passengers, and the people surrounding it.
All of that is our scope for how we’re going to define threats according to 262 and then mitigate them against malicious attack due to… That’s the cyber aspect of this. And then what’s being attacked and what are we protecting? We’re protecting vehicle systems, functions, data, et cetera. We call them assets according to their properties, confidentiality, integrity and availability. There could be more properties, that’s the CIA that we’re protecting. Why is cyber such a hot topic? Well, I would say there’s several reasons, but here’s two of the big ones. On the left of my slide, the advent of the connected car coupled with the automated driving functions. I’m not going to read through all the stats here, but the connected car is here. It’s 2 billion in terms of the market in 2021 to grow to $5.3 billion in 2026. And the connected car is accessible via the internet, accessible via Bluetooth and other network interfaces, which all result in attack services. It also has a lot more software.
https://www.jamasoftware.com/media/2023/03/Cybersecurity-Risk-RM-.png5121024Steve Rush/media/jama-logo-primary.svgSteve Rush2023-03-30 03:00:042024-04-05 13:27:22[Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System
This is part two of a two-part series on software validation and computer software assurance in the medical device industry.
Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part 2
In our previous blog post, we reviewed the top things to know about software validation and computer software assurance in the medical device industry. In this installment, we’ll take a closer look at computer software validation and provide tips and tools to manage your software in a compliant and efficient manner.
Main points
The FDA Draft Guidance on Computer Software Assurance
In September, 2022, the FDA released its draft guidance “Computer Software Assurance for Production and Quality System Software.” While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance on Software Validation, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). In this guidance the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”
There are many types of software used and developed by medical device companies, including those listed below. The scope of the 2022 draft guidance is on software used in production and quality systems software, as highlighted below.
Software in a Medical Device (SiMD) – Software used as a component, part, or accessory of a medical device;
Software as a Medical Device (SaMD) – Software that is itself a medical device (e.g., blood establishment software);
Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment);
Software in computers and automated data processing systems used as part of medical device production (e.g., software intended for automating production processes, inspection, testing, or the collection and processing of production data);
Software used in implementation of the device manufacturer’s quality system (e.g., software that records and maintains the device history record);
Software in the form of websites for electronic Instructions for Use (eIFUs) and other information (labeling) for the user.
Understanding Your Software’s Intended Use and Risk-Based Approach
Defining the software’s intended use is an important aspect of managing your organization’s computer software assurance activities.
This then allows you to analyze and document the impact to safety risk if the software failed to perform to meet its intended use. One aspect that I appreciate the FDA adopting is the concept of ‘high process risk,’ when the failure of the software to perform as intended may result in a quality problem that foreseeably compromises safety and an increased medical device risk. The guidance has a number of examples to illustrate examples of high process risk and not high process risk. Previously, risk that purely a high risk to compliance only (i.e., no process risk) was essentially treated the same as risk that could compromise safety.
Commensurate with the level of process risk, guidance, and examples are presented to outline expected computer assurance activities, including various levels of testing, and level of documentation. Computer assurance activities for software that poses a high level of process risk include documentation of the intended use, risk determination, detailed test protocol, detailed report of the testing performed, pass/fail results for each test case, any issues found and their disposition, among others.
In contrast, guidance is provided that computer software assurance activities that pose no level of process risk can consist of lower level of testing, such as unscripted ad-hoc or error guessing testing. Prior to this guidance, the expectation was fully scripted protocols and documented results for each test case, which felt burdensome. For example, having to script out protocol steps to include user log-in steps for an electronic QMS module that facilitated the nonconformance process, which did not have a high level of process risk. The usage of the concept of high process risk and acknowledging that unscripted testing can be appropriate in times of low risk, will certainly help lessen the burden of compliance, without compromising safety.
Managing Your Software Efficiently
For those that think analytically like me, once can easily see the value of a Trace Matrix to keep my organization’s software organized and ensure the intended use, risk assessment, planned computer software assurance activities, and outcomes documented.
Similar to how it efficiently traces your medical device design inputs to outputs and links to your risk management, Jama Connect® is a great tool to also trace and manage all your software and software validation and computer software assurance activities. This includes documentation of the intended use, risk determination, and test protocols and reports performed. With its new validated cloud offering, SOC2 certification, and available Jama Connect Validation Kit, Jama Software also provides the tools and evidence you need to meet your organization’s computer software assurance activities.
Developing a risk-based process for software management, including software validation and computer software assurance, is key to staying compliant. Staying organized and using a tool like Jama Connect helps you do so efficiently.
https://www.jamasoftware.com/media/2023/03/2023-03-28-practical-guide-software-validation-part-2-1.jpg5121024Michelle Wu/media/jama-logo-primary.svgMichelle Wu2023-03-28 03:00:512024-01-18 00:42:15Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part 2
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 “Medtech industry relieved as Europe’s MDR extension nears final approval” – originally authored by Susan Kelly and published on March 6, 2023.
Medtech Industry Relieved as Europe’s MDR Extension Nears Final Approval
The Council of the EU is expected to vote Tuesday on an extension of deadlines for complying with Europe’s Medical Device Regulation (MDR), in a move to keep critical treatments on the market during the transition period.
The revised timeline would give notified bodies that certify devices in the European Union longer to prepare for the new regulatory framework.
Companies that operate in the European market were expected to have devices recertified by May 2024 under the regulation, but with the deadline approaching, notified bodies faced a backlog, prompting the European Commission to propose extending the time frame.
“Industry is relieved that these amendments have been introduced – they are the culmination of many warning signs about a potential shortage of medical devices in the EU,” Brussels-based life sciences lawyer Josefine Sommer, a partner at Sidley Austin, wrote in an email.
The extension would stagger deadlines until 2027 or 2028, based on device risk classification, allowing manufacturers and notified bodies more time to complete conformity assessments. Products placed on the market under the predecessor Medical Devices Directive (MDD) could remain, under certain conditions.
“Once the amendments have been adopted, it will be interesting to see how the conditions for benefiting from the additional transitional periods are to be interpreted and implemented in practice,” Sommer said.
The upcoming European Council vote follows the European Parliament’s approval last month of the new timetable. EU procedure calls for both branches of the legislature to approve the plan.
“This will be the final step in the process,” an EU official said in an email.
Member state health ministers in the EU’s Employment, Social Policy, Health and Consumer Affairs Council backed the plan in December, after European medical societies called for urgent action to address device supply shortages reported by physicians.
“The Health Council supported the European Commission’s proposal to delay the transitional deadlines to avoid causing harm to EU health systems and, most critically, patient care,” London-based attorney Lincoln Tsang, partner and head of Ropes & Gray’s European life sciences practice, wrote in an email.
The MDR was adopted in 2017 following the recalls of breast implants and metal hip replacements due to safety problems. The regulation tightens controls for the safety and performance of medical devices and includes stricter monitoring and certification procedures to ensure compliance and traceability. The new rules also are intended to reflect technological and scientific advancements in the sector.
With the extended deadlines, higher-risk devices such as implants must transition to the new requirements by December 2027, and medium- to lower-risk devices such as syringes or reusable surgical instruments have until December 2028.
But Erik Vollebregt, a founding partner of Axon Lawyers in Amsterdam, said the timeline still requires manufacturers to be MDR-ready, “with an MDR application in the door at a notified body” no later than May 26, 2024.
“The current state of the market is that everybody is still figuring out what the proposal will mean for them specifically, both industry and notified bodies. Some manufacturers have seen 2027 and 2028 as dates and do not understand that these are dates for notified bodies and not for manufacturers,” Vollebregt said in an email.
Reuters reported in December that medical device manufacturers were dropping products from their European portfolios because of the cost of complying with the new regulations.
Although six new notified bodies received MDR designation in the second half of last year, it created a pool of 36 organizations to process around 23,000 certificates of current devices on the market, prompting EU Health Commissioner Stella Kyriakides to propose delaying enforcement of the MDR.
https://www.jamasoftware.com/media/2023/03/new-new-medtech-1.png5121024Jama Software/media/jama-logo-primary.svgJama Software2023-03-23 03:00:592024-01-18 00:44:49Medtech Industry Relieved as Europe’s MDR Extension Nears Final Approval
Functional Safety (FuSA) Explained: The Vital Role of Standards and Compliance in Ensuring Critical Systems’ Safety
Have you heard of FuSA? It stands for Functional Safety, and it is a vital part of any system that requires safety assurance. FuSA was designed to reduce the risk of physical injury or damage due to malfunctioning equipment. This guide will provide an overview of the subject, including the standards, compliance requirements, and the different types of systems where FuSA is used.
What Is Functional Safety?
At its core, Functional Safety (FuSa) is a set of measures taken to ensure that a system meets certain safety requirements. In other words, it’s a way to make sure that any system can operate safely without causing physical injury or damage. This includes both hardware and software components within the system.
The goal behind FuSa is to reduce the risk associated with a product’s failure as much as possible through the use of safety systems that are designed to detect any potential hazards and then take corrective action if necessary. To do this, developers must consider both hardware-based solutions such as monitoring devices or sensors, as well as software-based solutions such as algorithms or machine learning models that can detect potential faults before they occur. Once all potential risks have been identified and addressed, designers must then create a comprehensive test plan to validate all safety system components before the product is released into production.
FuSa Standards and Compliance Requirements
Several international standards have been established to help guide organizations in their implementation of FuSa. These standards include ISO 26262 for the automotive industry and IEC 61508 for industrial manufacturing and consumer electronics sector. Both these standards establish minimum requirements for safety-critical functions within a system. Additionally, each standard specifies certain testing procedures that must be followed in order to demonstrate compliance with the standard.
Typical Applications of FuSa
FuSa is commonly used in aerospace and defense applications as well as road vehicles, industrial machinery, medical devices, consumer products, and more. It can also be applied in critical systems such as those involving control functions or power generation/distribution systems. In all cases, the goal is to reduce the risk of unacceptable physical harm or damage due to malfunctioning systems or components.
When creating a safety system using FuSa principles, engineers typically use several tools such as FMEA (Failure Modes Effects Analysis), FMEDA (Failure Modes Effects & Diagnostic Analysis), FHA (Functional Hazard Analysis) etc., which are all based on the IEC EN 62304 standard for software development processes in medical devices; Road Vehicles Functional Safety Standard (ISO 26262); IEC 61508 for industrial automation; etc., all depending on what type of product/system one has in mind when developing a safety critical E/E/PS (Electronic / Electrical / Power Supply). All these rules vary depending on what type of product is being developed but usually involve assessing potential risks from different scenarios and establishing suitable safeguards against them so that they meet certain Safety Integrity Level requirements laid out by ISO/IEC 61508 standard.
Functional Safety is an important consideration for any organization dealing with safety-critical systems or components involving significant risks from potential malfunctioning equipment or software failure leading to unacceptable physical harm or damage caused by the equipment itself. Engineers must use proper tools like FMEA & FMEDA during development process while ensuring adherence to standards such as ISO 26262 & IEC 61508 while developing their products meeting necessary Safety Integrity Level requirements laid out by these standards. As long as organizations are aware of these requirements and take steps towards implementing them properly into their products & services they should be able to develop reliable & safe products meeting customer expectations!
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson and Steve Rush.
https://www.jamasoftware.com/media/2023/03/2023-03-21-fusa-ai-blog-1.jpg5121024Steve Rush/media/jama-logo-primary.svgSteve Rush2023-03-21 03:00:522024-02-16 15:59:28Functional Safety (FuSA) Explained: The Vital Role of Standards and Compliance in Ensuring Critical Systems’ Safety
In this blog, we recap the “Launch Your Aerospace & Defense Product Development Processes with Jama Connect®” webinar.
In this webinar, we discuss exciting new features in our updated Jama Connect® for Aerospace & Defense framework. These updates include refreshed solutions for cybersecurity, the DoD Range Safety Requirements Library, and other libraries of standards.
Also, Cary Bryczek, Solutions Director for Aerospace & Defense at Jama Software®, shares best practices in the Jama Connect platform and demonstrates significant new features that can help you further enhance your aerospace and defense product development processes, including:
ARP 4761A – Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment
DO-326A – Airworthiness Security Process Specification
US CFR Parts 21-57 Pre-imported Libraries and Usage
Defense MBSE and Digital Engineering Guidance
NASA and Air Force Range Safety Requirements
European Cooperate with Space Standards (ECSS) Pre-Imported Libraries
Below is an abbreviated transcript and a recording of our webinar.
Launch Your Aerospace & Defense Product Development Processes with Jama Connect®
Cary Bryczek: Let’s get started. So the Airborne Systems Solution. So when we say solution, it’s really a complete set of frameworks, example projects and the procedural documentation that goes along with that. It’s really intended to accelerate your implementation of Jama Connect, especially those that are developing Airborne Systems and the Airborne Systems components that are going to live on these aircraft. When you utilize these frameworks, you can either have zero set up time, so we’re developed the solution to align with the standards and you can also tailor it. So your consultant who does team with you could help you tailor it to meet your very specific business needs as well. So it’s really designed for any organization, whether you’re a startup in the Airborne Systems world or whether you’re a longtime developer of aircraft.
The Airborne Systems Solution is really designed to help you ease the path to regulatory compliance, to help the engineers produce the evidence and collect that evidence in coordination with the regulatory requirements and the industry standards that are used that are requiring the acceptable means of compliance. Today’s. In today’s world, there is a lot of new engineers that are being employed in Airborne Systems development. And really this particular template is helpful to them because it really gets them to understand “How am supposed to do development?” We all know that Airborne Systems development has the most onerous and rigorous standards of any industry. And teaching our new engineers is very time-consuming. So having this template with all of the guidance built into it and the procedure guide really helps our new engineers to get started.
So there’s three components to the Airborne Systems Solution that what we call the data set, a procedure guide, and the success program. The data set essentially is what you get when you install Jama and it has the templates, it has a ready to use configuration that matches those regulations. It has all of the item types, all of the reports, all of the best practices built right in. And then the procedure guides and the documentation of the reports essentially show you how the Airborne Systems template is meeting the industry standards. So how does it meet ARP4754, how do you use the solution to meet DO-178. That’s sort of a thing.
Bryczek: And then we also pair our solution with specific consulting. So our consultants already are very familiar with the regulations with working with our customers that have been delivering and developing Airborne Systems already, as well as systems engineering best practices. Some of our customers have interesting supply chain needs. And so they might want to use an additional tool that we package called data exchange. That’s just an add-on to the solution.
So when we look at the framework itself, there are a lot of industry standards that we support. These industry standards are the acceptable means of compliance that the FAA and EASA recognize in order to meet type certifications. So we have those processes that come right out of those standards built right in to the framework. So that framework consists of specially configured item types, pick lists and views of that information. Our relationship rules are aligned to the types of trace matrices these particular standards are calling for. We have workflows and guidance for how you conduct reviews of information as well. We have the libraries of standards, so if you need to comply with the different CFR parts, we actually have those pre imported. This is something new that we’ve added and we’ll talk about that a little bit more. The framework includes these document export templates as well as risk templates and analysis templates and more.
Now this is a company with a procedure guide. So along with not only just the template itself in Jama, we give you the procedure guide. You can take this guide and tailor it to meet your specific needs as well. This procedures guide is updated. So as a subscriber to the Airborne Systems Solution, any updates we make or new releases like what we have right now is included with your subscription. It just makes it easy for everyone to kind of understand “How do I use Jama if I need to meet these industry standards?”
Bryczek: Also with this particular release is the configuration and update guide. So this is new this time around. This particular guide gives a very detailed description of the entire dataset. It includes all of the types that we’ve defined, all of the pick lists that are defined, all of the relationship rules, all of the workflows. So if you need to update from your existing Airborne Systems Solution and take in aspects of the new release, it makes it really easy for you guys to update as well. This might be something as well… So if you tailor from your existing Jama solution and you want to keep track of that, something like this might be a really great way for you to document your own implementation of Jama itself.
So exciting. This is one of the new things. So we have for cybersecurity, DO-326A is an acceptable means of compliance for doing security analyses. There are a significant number of new item types that have been added to the solution that comprise our cybersecurity solution as well as how do you really do the airworthiness security analysis. Essentially there are seven steps to do this particular type of analysis. This really starts with developing your PSecAC. And for those of you who are maybe new to Airborne Systems development or are not familiar with DO-326 or cybersecurity, it is a process that’s sort of done in tandem with both the system development and safety. But this is different in that this is analyzing the intentional unauthorized electronic interaction. So it’s really designed to find ways that hackers or bad actors might be accessing parts of the Airborne Systems that you don’t want them to.
https://www.jamasoftware.com/media/2023/03/BLOG-RECAP-Launch-Your-AD-Product-Development-Processes-with-Jama-1-1.png5121024Cary Bryczek/media/jama-logo-primary.svgCary Bryczek2023-03-09 03:00:092024-01-18 00:50:15[Webinar Recap] Launch Your Aerospace & Defense Product Development Processes with Jama Connect®
Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part I
Intro
This is Part 1 of a 2-part series on software validation and computer software assurance in the medical device industry.
While it is clear that software validation is required by regulation in the US and elsewhere (e.g., the EU (European Union)), as regulated by the MDR and IVDR), how to execute continues to cause challenges, both for established medical device companies, and those just entering the medical device industry.
Between the different types of software, variations in terminology, type, and source of software (developed in-house, or purchased OTS, customized OTS (COTS), SOUP, etc.) advances in software technology, and evolving guidance of the FDA (Food and Drug Administration) and other regulatory bodies, it’s no wonder that implementation of software validation practices and procedures causes confusion.
This blog outlines the top things to know about software validation and computer software assurance as you implement practices and procedures for your organization in a way that is compliant and brings value.
Are you building or updating your software validation practices and procedures? If so, read on!
Top Things to Know About Software Validation and Computer Software Assurance
#1. Yes, there are different terms, methods, and definitions for software validation.
For the purposes of this blog, we’ll use the FDA’s definition of software validation, from their 2002 guidance. The FDA considers software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”
At a high level, this makes sense. The confusion starts when folks try to define how that confirmation is performed and documented. How do I determine and document the requirements? How detailed do I need to go to my user needs and intended uses? For each feature? What kind of objective evidence? What if I’m using software to automate test scripts? Do I have to qualify the testing software? Turning to guidance and standards for a “standard” set of practices can add to the confusion. Even within just the medical device industry, there are multiple regulations and standards that use similar and at the same time, slightly different concepts and terminology. Examples include the IQ/OQ/PQ (Installation Qualification / Operational Qualification / Performance Qualification) analogy from process validation, black box testing, unit testing, just to name a few.
Before getting overwhelmed, take a breath and read on to point #2.
While the multiple regulations and standards around software validation cause confusion, they are also a good place to start. I say that because at a high level they are trying to achieve the same thing- software that meets its intended use and maintains a validated state. Keeping the intent in mind can make it easier (at least it does for me) to see the similarities in the lower-level requirements between any terminology differences and not be as focused on making all the terminology match.
The 3rd guidance is relatively new, a draft guidance released in September, 2022, Computer Software Assurance for Production and Quality System Software. While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). It is also in this guidance that the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”
Once you’ve grounded yourself in one set, then you can compare and add on, as necessary, requirements for other regulatory jurisdictions. Again, focus on specific requirements that are different and where the high-level intent is similar. For example, in the EU, Regulation (EU) 2021/2226 outlines when instructions for use (IFUs) may be presented in electronic format and the requirements for the website and eIFUs presented.
#3. Start on the intended use and make your software validation and computer software assurance activities risk based.
Start with documenting the intended use of the software and associated safety risk if it were to fail. Then define the level of effort and combination of various software validation activities commensurate with the risk. Software and software features that would result in severe safety risk if it fails are to be validated more rigorously and have more software assurance activities than software that poses no safety risk.
Here are some examples of intended use and the associated safety risk.
Example 1: Jama Connect®, Requirements Management Software
Intended Use: The intended use of Jama Connect is to manage requirements and the corresponding traceability. The following design control aspects are managed within Jama Connect, user needs, design inputs, and traceability to design outputs, verification and validation activities. Risk analysis is also managed in Jama Connect.
Feature 1 Intended Use: Jama Connect provides visual indicators to highlight breaks in traceability. For example, when a user need is not linked to a design input, or vice versa.
Risk-based analysis of Feature 1: Failure of the visual indicator would result in the possibility of not establishing full traceability or missing establishment of a design control element like a design input. This risk is considered moderate as manual review of the traceability matrix is also performed as required by the Design Control SOP. Reports are exported from Jama Connect as pdfs, reviewed externally to the software, and then approved per the document control SOP.
Example 2: Imbedded software in automated production equipment
Intended use: The intended use of the software is to control production equipment designed to pick in place two components and weld them together.
Risk-based analysis: This is a critical weld that affects patient safety if not performed to specification. Thus, the software is considered high risk.
#4. Software Validation and computer software assurance is just one part of the software life cycle… you need to be concerned about the whole lifecycle.
There is more to software development and management than just the validation. Incorporate how custom software will be developed, how purchased software will be assessed to determine the appropriate controls based on risk, including verification and validation activities, and revision controlled.
#5. Have different procedures and practices for the different types of software.
This is a good time to consider how different types of software in your organization will be managed, and it’s not a one-size fits all approach. A best practice is to have separate practices and procedures; one for software in a medical device (SiMD) and software as a medical device (SaMD) and at least one other procedure and set of practices for other software, like software used in the production of a device, software in computers and automated data processing systems used as part of medical device production, or software used in implementation of the device manufacturer’s quality system.
Closing
Stay tuned for Part 2 of this 2-part blog series, where we’ll dive deeper into computer software assurance, highlight the risk-based approach, and provide tips and tools to manage your software in a compliant and efficient manner.
https://www.jamasoftware.com/media/2023/03/2023-03-07-practical-guide-software-validation-part-1-1.jpg5121024Michelle Wu/media/jama-logo-primary.svgMichelle Wu2023-03-07 03:00:302024-01-18 00:51:35Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part I
