What is DevSecOps? A Guide to Building Secure Software
DevSecOps has gained popularity as a secure and dependable software development methodology in the fast-paced world of software development. But what is DevSecOps really, and why is it so crucial?
DevOps is a set of techniques that stresses collaboration and automation between development and operations teams. DevSecOps is the integration of security practices into this methodology. DevSecOps seeks to establish a security culture that guarantees the software is secure and complies with compliance standards by integrating security into every phase of the software development lifecycle, from planning through deployment.
The ability to identify and address security risks earlier in the development process is one of the main advantages of DevSecOps. This means that security is incorporated into the software at the outset instead of being added later, which can be expensive and time-consuming. Also, DevSecOps plays a big role in decreased risk of security breaches and data leaks by identifying vulnerabilities earlier.
The fact that DevSecOps helps to ensure compliance with laws and standards is another crucial feature of the practice. In many businesses, especially those that deal with sensitive or private data, including healthcare and banking, compliance is becoming more and more crucial. DevSecOps aids in ensuring that the software complies with requirements by incorporating compliance into the development process.
How does DevSecOps work?
What does DevSecOps look like in practice? DevSecOps is fundamentally about cooperation and communication between teams working on development, security, and operations. This implies that everyone bears some kind of responsibility for security, not just the security team. Instead of adding security features later, development teams collaborate with security and operations teams to incorporate security into the software from the start.
The automation of DevSecOps is a crucial element. Automation makes the development process more efficient, reduces errors, and ensures consistency. DevSecOps can aid in the quicker and more precise detection of vulnerabilities and threats by automating security testing and other security operations.
Continuous monitoring is a key component of DevSecOps. This means that maintaining security involves ongoing monitoring and improvement rather than being a one-time action. DevSecOps can assist in identifying and mitigating risks before they turn into significant concerns by continuously monitoring the program for security threats and vulnerabilities.
DevSecOps also depends on a culture that values security. As a result, security is more than just a collection of guidelines; it’s also a way of thinking and conducting business. Organizations may ensure that security is always a top priority and that everyone is aware of the significance of security in their work by developing a culture of security.
DevSecOps is a vital method of software development that places an emphasis on teamwork, automation, and constant monitoring. DevSecOps contributes to the creation of a security culture that guarantees the software is secure and complies with regulatory standards by integrating security into every phase of the software development lifecycle. Organizations that implement DevSecOps are well-positioned to produce secure and dependable software that satisfies the needs of their stakeholders and customers given the growing relevance of security in today’s society.
There are numerous online resources, like blogs, podcasts, and online courses, that you may use to learn more about DevSecOps. In the world of DevSecOps, there is something for everyone, whether you are a developer, security expert, or operations specialist.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson.
ARP4754A / ED-79A: Enhancing Safety in Aviation Development
Safety is always put first in the aviation sector. Strict adherence to rules and demanding standards helps to preserve this commitment to safety. This is where ARP4754A, a significant standard, comes into play. In this blog post, we will discuss the importance and function of ARP4754A (and its EASA equivalent ED-79A, henceforth ARP4754A) and how it impacts the design of civil aircraft and systems.
Understanding ARP4754
ARP4754A, commonly known as “Guidelines for Development of Civil Aircraft and Systems,” is an industry standard published by SAE International. Its goal is to create a structured procedure for the development and certification of aircraft and related equipment in order to guarantee adherence to safety rules. From initial concept to final certification, these rules are intended to serve as a reference for engineers, designers, and manufacturers. ARP4754A is recognized as an appropriate standard for aircraft system development and certification. The corresponding EASA Acceptable Means of Compliance AMC 25.1309 (included as a section of CS-25) does recognize ARP4754/ED–79 as well.
ARP4754A’s main goal is to increase aviation safety by encouraging a methodical and uniform approach to designing and developing aircraft and systems. It aims to reduce risks and dangers related to aircraft operations by resolving potential flaws and vulnerabilities. The standard’s goals consist of:
Safety Assessment: ARP4754A stresses performing in-depth safety evaluations to pinpoint dangers, weigh the risks, and put in place the right countermeasures. Revision A, specifically addresses functional safety and the design assurance process.
System Development: It offers recommendations for the development of aviation systems, including requirements management, verification and validation, and configuration management.
Considerations for Certification: ARP4754A guarantees that systems and aircraft adhere to legal criteria and certification procedures, supporting their secure integration into the aviation industry.
Development Lifecycle
The development lifecycle outlined by ARP4754A recommends adherence to established systems engineering principles and emphasizes the significance of iterative and incremental procedures, stakeholder collaboration, and requirement traceability throughout the lifecycle stages. The typical key processes covered by ARP4754A are well-defined:
Planning Process: This stage defines the means of producing an aircraft or system which will satisfy the aircraft/system requirements and provide the level of confidence which is consistent with airworthiness requirements.
Safety Assessment Process: Prescribes close interactions between the safety assessment process and system development process to capture safety requirements imposed on the design.
Architecture Planning and Development: The system architecture is established, including hardware, software, and interfaces
Requirements Process: Detailed system requirements are defined, considering functional, performance, security, and safety aspects.
Design Process: Detailed hardware and software item requirements are defined and allocated to system requirements.
Implementation Process: The system components are developed, integrated, and tested according to the defined design requirements.
Verification and Validation Process: This includes the activities necessary to demonstrate that the item requirements are complete, correct, and consistent with the system needs and architecture.
Integral Processes: ARP4754A describes additional processes that are applicable across all of the above processes. They are: Safety Assessment; Development Assurance Level Assignment; Requirements Capture; Requirements Validation; Configuration Management; Process Assurance; Certification & Regulatory Authority Coordination
The policy related to ARP4754A plays a crucial role in ensuring safety in the aviation industry. It employs a step-by-step approach to identify and address potential hazards and risks during the early stages of development. This policy prioritizes safety assessments, risk reduction, and thorough testing, ultimately minimizing the chances of any mishaps or incidents in practical scenarios.
Moreover, ARP4754A promotes a culture of collaboration where stakeholders can effectively share knowledge and communicate throughout the development process. This ensures that safety concerns are addressed, and all parties involved have a clear understanding of their respective roles and responsibilities. The result is a coordinated effort that leads to a successful outcome.
Conclusion
The aviation industry relies heavily on ARP4754A as a fundamental benchmark and acceptable means of compliance for the development of civil aircraft and systems. By adhering to a structured approach to development, it ensures aviation safety and minimizes possible risks. Its systematic lifecycle stages, emphasis on safety assessments, and compliance with certification requirements significantly contribute to the overall reliability and integrity of aviation products. Even as the aviation industry progresses, ARP4754A remains a critical reference point, promoting a safety-first mindset and reinforcing the industry’s dedication to passenger safety.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Decoteau Wilkerson and Cary Bryczek.
Learn about the critical role of benefit-risk analysis in the development of safe and effective medical devices, including the use of ISO 14971, regulatory requirements, and optimizing for patient needs and healthcare costs.
The Importance of Benefit-Risk Analysis in Medical Device Development
Benefit-risk analysis is a crucial stage in the creation of medical devices. It entails evaluating the device’s possible benefits as well as drawbacks and deciding if the advantages outweigh the disadvantages. This examination aids in ensuring that medical devices are reliable, safe, and capable of being used by patients without harm.
The global standard for risk management of medical devices is ISO 14971. It offers a framework for recognizing, assessing, and managing hazards related to medical devices. Manufacturers must follow the standard and conduct a benefit-risk analysis as part of the risk management procedure. To ensure that the level of risk connected with a medical device are acceptable and that the benefits outweigh the risks, this analysis is crucial.
To start a benefit-risk analysis, it is important to first determine the device’s intended use(s). The device’s intended use should be defined in detail and contain information on the patient group it is meant for, the medical problem it is intended to support, and the clinical environment in which it will be used.
Finding the potential advantages of the device is the next step after defining its intended usage. Benefits could include better health outcomes, more comfortable patients, and lower healthcare expenses. These advantages should be measured and contrasted with any possible risks connected to using the technology.
A medical device’s dangers may include physical harm to the patient, adverse events, and device failure, according to the definition of harm within ISO 14971. The possibility and seriousness of each risk should be evaluated, and these risks should be identified and quantified.
Even after risks have been lowered as far as possible with risk controls, there may still be some unacceptable level of risks. This is why a benefit-risk analysis is so important in medical device development.
The following stage is to assess the benefit-risk balance after the potential advantages and risks have been determined. This entails weighing the device’s possible advantages and disadvantages to decide whether the benefits outweigh the risks.
If the benefits outweigh the risks, the device may be considered safe and effective for use in the intended patient population. However, if the risks outweigh the benefits, the device may not be considered safe or effective and may need to be redesigned or modified to reduce the risks, a medical device manufacturer might also make the decision not to launch the product to market.
Benefit-risk analysis must be optimized to guarantee the safety and efficacy of medical devices.
The benefit-risk analysis should be an ongoing process throughout the development and life cycle of the device. As new information becomes available, the analysis should be updated to ensure that the benefits still outweigh the risks, as prescribed in various regulations and standards such as 14971:2019, and EU MDR/IVDR.
Regulatory standards for medical devices should also be considered in the benefit-risk analysis. The Food and Drug Administration (FDA), which oversees medical device regulation in the US, requires manufacturers to prove their devices are safe and effective before they can be marketed or sold.
The FDA requires med device manufacturers to perform a benefit-risk analysis as part of the product development process. This analysis is used to determine whether the benefits of the device outweigh the risks and whether the device is safe and effective for use in the intended patient population.
Conducting a benefit-risk analysis is a critical step in the development of med devices. It involves identifying and evaluating potential benefits and risks and determining whether the benefits outweigh the risks. ISO 14971 provides a framework for performing a benefit-risk analysis as part of the risk management process.
Optimizing benefit-risk analysis is important for ensuring that medical devices are safe and effective, meet regulatory requirements, and are reimbursed by healthcare payers. A systematic approach that considers all relevant factors, including patient needs and preferences, and clinical outcomes.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson and Vincent Balgos.
Digital Transformation and the Importance of Requirements Management Within the DoD
Looking back on a technology career that started nearly 45 years ago gives me an opportunity to reflect on the evolution of technology trends. Most notably, for me, the usability and interfaces to that technology. Let me explain…
I started out as a young man in the Marines repairing and calibrating avionics equipment, and general test instrumentation. After boot camp (basic training) the Marines saw fit to send me to a half dozen electronic schools to learn my craft. Every piece of equipment I touched had a physical reference, and user’s manual, but for the most part, if you knew what function a piece of gear was supposed to provide, you probably didn’t need a manual very often. For example, if I knew how to use a Tektronix oscilloscope, I probably didn’t need any instruction on how to use an o-scope from Hewlett Packard or Phillips. Just about everything I needed to know was obvious and accessible on the front panel (the user interface).
Over the next 15 years that paradigm stayed relatively consistent. I would see different types of equipment, work on different ‘things,’ but it was rare that training or anything other than an occasional manual was needed to be productive. Physical interfaces tended to ‘tell all’ about what I could do, or what I needed to do with a piece of electronic equipment.
It was about this time that I made a mid-career switch. It had become obvious (to me, at least) that software was going to be in EVERYTHING. Consequently, I went back to school for a Computer Science (CS) degree to help in gaining access to that world. With CS degree in hand, I took a position writing test software on a classified program for an aerospace giant. It was interesting at one level when I could see the end results of my efforts, but it could be laborious at times. I shared a large cubicle with two teammates, and we were heads down grinding on code for most of the day. I know some find this immensely rewarding, but I was not one of them.
Whilst I knew this wasn’t my calling in life, the introduction to a software development organization gave me exposure to tools supporting the software development lifecycle (SDLC). Disciplines like requirements management, configuration & change management, and architectural modeling. Plus, the software development process itself: Waterfall, Spiral, Iterative, Agile to name a few. The code may be the ultimate deliverable, but there are a lot of moving parts to get the code out the door. Of course, not every team believed in all of those ‘other’ disciplines: I had one teammate that had a sign over his desk that read, “Documentation is for wimps!” I also remember a cartoon at that time that read something like (manager speaking to developers): “You start writing the code while I go upstairs and see if they have any requirements.”
I’ve spent the bulk of the past 20 years of my work life supporting and working with Federal DoD programs – the large System Integrators, and direct with programs at military installations around the country. In that time, I’ve seen the transformation of segments of programs/projects being focused on a singular discipline (e.g., requirements, code, test, etc.) to the point where they are taking the big picture view; that systems and software development is really a team sport. Instead of each discipline developing their own assets/artifacts and ‘throwing them over the wall’ the work is now being attacked in a cohesive and coordinated fashion. Essentially, a digital transformation where we’ve gone from just ensuring that each discipline has tooling to support their own work, to the point where each segment of the development lifecycle prioritizes the ability to link and trace to the upstream and downstream activities.
In the earliest of days of tracing assets across all disciplines the tool vendor who could supply an environment that supported all facets of development, and link those assets together had an advantage. However, over time, the end user became more sophisticated. They did not want to lock themselves into a single vendor with tools that were ‘good enough,’ they wanted a best-of-breed product for each of those disciplines.
I think that’s the primary reason that I’m excited to be part of the team at Jama Software®. I spent 16+ years being that single vendor with tools that were integrated and were ‘good enough.’ Now, I have a product that arguably is the centerpiece of the most important of disciplines, requirements management. For without accurate requirements, on time, on budget, and meeting the needs of the end user (or warfighter) is a difficult undertaking.
At Jama Software®, we support Live Traceability™ – the ability to link and trace outside our domain of requirements, to the other best-of-breed tools that support things like coding, change management, architectural modeling, testing, etc. Jama Connect® does not lock you into a single vendor but gives you the ability to continue to use the products you currently have in your arsenal. Live Traceability gives your team the ability to see the most up to date and complete up and downstream information for any requirement, no matter what state of development it is in or how many siloed tools and teams it spans.
Being a part of the Jama Connect team has allowed me to work with the most intuitive of all tools in my career. When I say intuitive, I mean I didn’t need any training to get up and running to be productive. Additionally, Jama Connect is a cloud-based product (self-hosted is also available), so no need to worry about getting your IT team engaged. If a Jama Connect project is properly set up, it should expose the bulk of the functions needed for a person working in the requirements discipline. Notice I did not say ‘requirements manager.’ Systems/Software development is a team sport, and more roles than just a requirements manager/SME will need access to the requirements. It is rather easy for a non-requirements person to access the tool, explore its functions, and be productive with limited or no training.
I continue to support Aerospace & Defense programs in my role at Jama Software. In addition to Jama Software offering a great requirements management tool, they are industry experts, and provide expert thought leadership and best practice guidance to their clients. This level of knowledge is a key distinguishing factor when searching for a requirements management tool. I am very happy to be part of this extremely energetic, client-focused company and truly looking forward to this next phase of my career.
A Nod To MOSA: Deeper Documenting of Architectures May Have Prevented Proposal Loss
On April 6th the GAO handed down a denial to Sikorsky-Boeing proposal protest of the Army tiltrotor award to Textron Bell team. This program is called the Future Long Range Assault Aircraft (FLRAA) which is supposed to be a replacement for the Blackhawk helicopter. In reading the Decision from the GAO, it is apparent that there was a high degree of importance placed on using a Modular Open Systems Approach (MOSA) as an architecture technique for the design and development. For example, the protest adjudication decision reveals, “…[o]ne of the methods used to ensure the offeror’s proposed approach to the Future Long-Range Assault Aircraft (FLRAA) weapon system meets the Army’s MOSA objectives was to evaluate the offeror’s functional architecture.” Sikorsky failed to “allocate system functions to functional areas of the system” in enough detail as recommended by the MOSA standard down to the subsystem level which is why they were given an Unacceptable in the engineering part of their proposal response.
MOSA will enable aerospace products and systems providers to not only demonstrate conformance to MOSA standards for their products but allow them to deliver additional MOSA-conformant products and variants more rapidly. By designing for open standards from the start, organizations can create best-in-class solutions while allowing the acquirer to enable cost savings and avoidance through reuse of technology, modules, or elements from any supplier via the acquisition lifecycle.
Examining MOSA
What is a Modular Open Systems Approach (MOSA)?
A Modular Open Systems Approach (MOSA) is a business and technical framework that is used to develop and acquire complex systems. MOSA emphasizes the use of modules that are designed to work together to create a system that is interoperable, flexible, and upgradeable. To do this MOSA’s key focus is designing modular interface commonality with the intent to reduce costs and enhance sustainability efforts.
More specifically, according to the National Defense Industrial Association (NDIA), “MOSA is seen as a technical design and business strategy used to apply open system concepts to the maximum extent possible, enabling incremental development, enhanced competition, innovation, and interoperability.”
Further, on January 7, 2019, the U.S. Department of Defense (DoD) issued a memo, signed by the Secretaries of the Army, Air Force, and Navy, mandating the use of the Modular Open Systems Approach (MOSA). The memo states that “MOSA supporting standards should be included in all requirements, programming and development activities for future weapon system modifications and new start development programs to the maximum extent possible.”
In fact, this mandate for MOSA is even codified into a United States law (Title 10 U.S.C. 2446a.(b), Sec 805) that states all major defense acquisition programs (MDAP) are to be designed and developed using a MOSA open architecture.
MOSA has become increasingly important to the DoD where complex systems such as weapons platforms and communication systems require a high level of interoperability and flexibility. Their main objective is to ensure systems are designed with highly cohesive, loosely coupled, and severable modules that can be competed separately and acquired from independent vendors. This allows the DoD to acquire systems, subsystems, and capabilities with increased level of flexibility of competition over previous proprietary programs. However, MOSA can also be applied to other industries, such as healthcare and transportation, where interoperability and flexibility are also important considerations.
The basic idea behind MOSA is to define architectures that are composed of more, more manageable modules that can be developed, tested, and integrated independently. Each module is designed to operate within a standard interface, allowing it to work with other modules and be easily replaced or upgraded.
The DOD requires the following to be met to satisfy a MOSA architecture:
Characterize the modularity of every weapons system — this means identifying, defining, and documenting system models and architectures so suppliers will know where to integrate their modules.
Define software interfaces between systems and modules.
Deliver the interfaces and associated documentation to a government repository.
And, according to the National Defense Authorization Act for Fiscal Year 2021, “the 2021 NDAA and forthcoming guidance will require program officers to identify, define, and document every model, require interfaces for systems and the components they use, and deliver these modular system interfaces and associated documentation to a specific repository.”
Modularize the system
Specify what each component does and how it communicates
Create interfaces for each system and component
Document and share interface information with suppliers
MOSA implies the use of open standards and architectures, which are publicly available and can be used by anyone. This helps to reduce costs, increase competition, and encourage innovation.
Why is MOSA important to complex systems development?
MOSA, an important element of the national defense strategy, is important for complex systems development because it provides a framework for developing systems that are modular, interoperable, and upgradeable. Here are some reasons why MOSA is important:
Interoperability: MOSA allows different components of a system to work together seamlessly, even if they are developed by different vendors or organizations. This means that the system can be upgraded or enhanced without having to replace the entire system.
Flexibility: MOSA promotes the use of open standards and architectures, which allows for greater flexibility in system development. It also allows for more competition among vendors, which can lead to lower costs and better innovation.
Cost-effectiveness: MOSA can reduce costs by allowing organizations to reuse existing components or develop new components that can be integrated into existing systems. It can also reduce the cost of maintenance and upgrades over the lifecycle of the system.
Futureproofing: MOSA allows for systems to be upgraded or modified over time, as new technology becomes available. This helps to future-proof the system, ensuring that it can adapt to changing needs and requirements.
How can Live Traceability™ in Jama Connect® help with a MOSA?
Live Traceability™ in Jama Connect® can help with MOSA by providing mechanisms to establish traces between MOSA architecture elements and interfaces, and the requirements and verification & validation data that support them. Live Traceability is the ability to track and record changes to data elements and their relationships in real-time. This information can be used to improve documenting system design, identify potential issues, and track changes over time.
Here are some specific ways that Live Traceability can help with MOSA:
Status monitoring: Live Traceability allows systems engineers to monitor the progress of architecture definition in real-time, identifying issues from a requirements perspective as they arise. This can help to increase efficiency and ensure that the stakeholders are aware of changes as they occur.
Digital Engineering: Live Traceability can help with digital engineering by providing mechanisms to capture architectures, requirements, risks, and tests including the traceability between individual elements.
Configuration and Change Management: Live Traceability can help with change management by tracking changes to system architectures and interfaces including requirements that are allocated to them. This can help to ensure that changes are properly documented and that they do not impact other parts of the system. Baselining and automatic versioning enable snapshots in time that represent an agreed-upon, reviewed, and approved set of data that have been committed to a specific milestone, phase, or release.
Testing and Validation: Live Traceability can help with verification and validation to ensure that system meets specified requirements and needs. This can help reduce risk by identifying issues early in the development process and ensuring that the system meets its requirements.
Future-proofing: Live Traceability can help to future-proof the system by providing a record of system changes and modifications over time. This can help to ensure that the system remains flexible and adaptable to changing needs and requirements.
In summary, Live Traceability in Jama Connect can help with MOSA by providing real-time visibility into the traceability between architectures, interfaces, and requirements. It can help to improve documenting the system design, identify potential issues, and track changes over time, which are all important considerations for MOSA.
What is a Trial Master File in the Medical Device Industry?
A Trial Master File, also known as a TMF, is a collection of records and documentation about the creation, evaluation, and regulatory approval of a medical device. It shows the quality control procedures used in the device’s design, production, and testing to make sure it meets all applicable regulations. Regulators look at the TMF during inspections and audits to see if the device is in compliance.
How is a Clinical Trial Master File (TMF) similar to a Trial Master File?
A Clinical Trial Master File (TMF) is similar to a Trial Master File in that they are both collections of documents and records related to a specific project. However, while a Trial Master File pertains to the development, testing, and regulatory approval of a medical device, a Clinical Trial Master File pertains to the clinical trials conducted to evaluate the safety and efficacy of a medical device, pharmaceutical product, or treatment.
Both types of TMFs provide evidence of the processes and procedures used during the development and testing phases, and both are subject to review by regulatory agencies during inspections and audits.
What is an Electronic Trial Master File?
An Electronic Trial Master File (eTMF) is an electronic version of TMF that stores documents and records generated during the clinical trial process. eTMFs can replace paper-based TMFs and provide a more efficient and effective way to manage the vast amount of information generated during a clinical trial. Using an eTMF is becoming more common in the clinical trial industry due to its many benefits over paper-based TMFs, including improved efficiency, increased security and accessibility, and enhanced regulatory compliance.
To achieve compliance, organizations need defined processes for development and production and detailed traceability, from the high-level user needs through to test management. Documentation is a large part of proving compliance, and Jama Connect® makes it easy to compile the necessary documentation, like eTMFs. By automating the process, teams can focus on what’s important and avoid potential errors.
What types of regulations are TMFs or eTMFs expected to meet?
Both Clinical Trial Master File (TMF) and Electronic Trial Master File (eTMF) must adhere to various regulatory requirements depending on the jurisdiction in which the clinical trial is conducted. Some of the common regulations that a TMF or eTMF must comply with include:
International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) guidelines: This is a set of global guidelines for the development, registration, and post-approval of pharmaceuticals.
Good Clinical Practice (GCP) guidelines: This is an international ethical and scientific quality standard for designing, conducting, recording, and reporting clinical trials that involve the participation of human subjects.
The Food and Drug Administration (FDA) 21 CFR Part 11: This is a regulation that establishes the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records.
Health Insurance Portability and Accountability Act (HIPAA): This is a US federal law that requires the protection and confidential handling of personal health information (PHI) stored in electronic form.
European Union Clinical Trials Regulation (EU CTR): This is a regulation that governs the conduct of clinical trials in the European Union and aims to harmonize the regulatory requirements across EU Member States.
How can a TMF help an organization with successful product development and management?
It is important for the trial sponsor, sponsor’s representative or the CRO to ensure that the TMF or eTMF meets all relevant regulatory requirements to ensure the integrity and quality of the clinical trial data.
A Clinical Trial Master File (TMF) can help an organization with successful product management by providing a centralized repository of all the relevant documentation and information related to the development and testing of a product. The TMF helps to ensure that all necessary documentation is captured and easily accessible, which can help to:
Overall, a well-managed TMF can play a critical role in the successful development, testing, and management of a product, by providing a comprehensive and centralized record of all relevant information and documentation.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Decoteau Wilkerson, McKenzie Jonsson, and Vincent Balgos.
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.
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.
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.
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.
![[Webinar Recap] An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR)](https://www.jamasoftware.com/media/2023/04/BLOG-RECAP-Medical-Device-Webinar-Social-Image.png "[Webinar Recap] An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR)")
