Design Controls For Drug Delivery Devices, Part 2: A Practical Perspective

By Fran DeGrazio, executive editor, Drug Delivery Leader

Welcome to (or, back to) my two-part article series on Design Controls. In the previous installment, “Design Controls For Drug Delivery Devices, Part 1: A Process Primer,” I laid out foundational concepts, such as design inputs and outputs, as well as a simplified version of fundamental process steps, including design verification and validation, design review, and change controls. For the uninitiated or for those in need of a refresher, I certainly invite you to start with or return to that piece.

In this second and final installment, I offer, as promised, practical tips and solutions for the successful implementation of Design Controls in building a device or combination product that delivers a drug or biologic to a patient.

Getting Design Controls Underway

The first step is determining when to commence  Design Controls in your product development process and timeline. Before initiating Design Controls, it is essential to assess the feasibility of integrating a device with a drug or biologic. In that early stage, identifying basic functionality and assessing the economic viability of a finished product are obvious, must-do activities. Only after this initial proof-of-concept stage, when a decision is made to proceed with actual execution on product development, should Design Controls be implemented.

Given that a drug-device combination product, both conceptually and practically, aligns the world of drug/biopharmaceutical formulation with the world of delivery systems, the process must start with a well-qualified and well-rounded project team. Who should be on it? Frankly, a strong team would  include formulation development scientists, packaging engineers, device engineers, process engineers, medical experts, manufacturing personnel, and other stakeholders.

Documenting Design Controls

Within the cross-functional team, the design engineering organization typically owns the Design History File (DHF). The DHF is a complete record of the design and development process, proving that Design Controls were diligently embedded in the process and that all associated regulatory requirements have been addressed.

To enable this cross-functionality, I recommend leveraging software specifically designed for documenting R&D activities and related data collection for medical devices, drugs, and combination products. Using general software tools such as homegrown databases or Excel to capture data and hold reports will likely be cumbersome at best.

Frankly, managing knowledge is critical for execution due to the importance of capturing, integrating, and leveraging information not only within individual development programs but also across various programs, teams, and functions. The optimal system will bring together not only Design controls but Quality by Design (QbD), Human Factors Engineering (HFE), and Risk Management. Utilizing purpose-built software will ensure the use of structured data, which, based on my experience, is essential for facilitating the digital sharing of information.

Now that we know when to start, who to involve, and how to document the cross-functional work around Design Controls, I will add perspective on three critical, related elements of a well-thought-out and well-controlled design and development process. Those include risk management, compatibility, and compliance. It is my feeling that you cannot achieve a successful design control program without having these three factors interacting throughout the planning and framework.

Performing Risk Management Along With Design Controls

Risk management is essential in pharmaceutical and device development. The process begins with understanding risks, which should inform the formal design control process, as outlined in FDA 21 CFR 820 and ISO 13485:2016, both now composing the Quality Management System Regulation (QMSR) for devices and combination products.

A part of the design control process includes planning. This includes defining your technical requirements and approach but also building a risk management plan. The formal, documented Risk Management Plan (RMP) is used to help identify and control risks throughout the process.

Design control and risk management processes depend on each other as part of identifying initial technical design requirements. In those efforts, a cross-functional team must begin to conduct hazard analysis, which is part of risk management activities. The hazard analysis involves evaluating hazards from product failure or misuse in different scenarios. The analysis includes the general hazard, hazardous situation, harm, severity, and probability of occurrence. Risks are classified by the level of harm to patients or users. Risk priority levels depend on severity and probability of harm.

An example I have seen of a combination product hazard is failure of the delivery system to provide an accurate dose due to misuse. The best remedy to mitigate a hazard such as this is to not only provide clear instructions for use (IFU), but also, and even better, to actually design out of the device any possibility of making the error. This degree of design mitigation is often the preference of regulatory agencies.

Risk mitigation can even be applied to the design control process itself. One risk in the practical execution of a design process is, when defining user needs, starting with a group consisting only of internal people. If they are incorrect in their assumptions, the product may ultimately not meet its design validation requirements at the end of the development program. To mitigate that possible risk, it is critical that, early in the process, real research with actual potential users is conducted. That way, the identified user needs can be translated to design inputs ahead of later activities such as design outputs identification, design review, design verification, and so on.

Once there is an understanding of the risks defined in the hazard analysis, the developers will need to build their risk assessment documentation. This is all part of the actual design and development process and quite often takes the form of leveraging Failure Modes & Effects Analysis (FMEA). These are specific documents used to evaluate various aspects of risk. They are typically documented in the form of a Design FMEA (dFMEA), Process FMEA (pFMEA), User FMEA ( uFMEA), and others.

Additionally, there should be similar risk documents, such as those generated by FMEA activities, assembled and leveraged as input into the combination product documentation. These would be completed on the container closure primary packaging system or on the device constituent parts, as examples of application. These additional approaches to documentation help to assess risks and put controls in place throughout the design and development process.

Applying Risk-Level Ratings To Device Design

Another practical challenge is accurately and consistently defining and applying degrees of risk. Frankly, you must avoid scenarios where all risks are perceived as high risk. During an FMEA session with a cross-functional team, for example, some members may tend to view all risks conservatively and rate them most/all as high. This practice would likely cause a lack of prioritization in addressing the true high risks and, as a result, utilize energy and expertise in areas where attention is just not needed. If everything is critical then nothing is critical, from my perspective.

For reference, an example of high risk would be a scenario associated with improper delivery leading to a dosing error. This can have a significant impact on patient safety. By contrast, an example of low risk could be a minor mistake with the printing of a label placed on the product.

Even with diligent attention to identifying, ranking, and mitigating risk, the reality is that no product is 100% risk-free. Acknowledging that reality, a company should have a Risk Management Policy that defines an acceptable level of risk.

Any remaining risk is categorized as residual risk, defined as the risk that remains after all risk control measures have been taken. Typically, there are pre-established criteria defined to decide if the medical benefit outweighs the risk. This residual risk review is normally  handled using medical experts who are independent of the product development team and who can objectively evaluate the total risk of the  combination product and decide if it can and should be placed on the market

Having adequately trained individuals and an objective person leading the FMEA process can help support the goal of rating risk levels accurately. Make sure that personnel involved in these efforts have been trained to understand what constitutes a true high risk. Case studies can help elucidate this for those learning. Additionally, using an experienced person, for instance an R&D program manager, to lead the effort while having team members challenge, when appropriate, facilitates the process.

Ideally, the reason for doing all of this risk management is to identify and mitigate risks during the development process so the output is a combination product or other delivery device that is safe for its intended use.

Conducting Milestone Design Reviews

Another key activity related to design control and risk mitigation processes is Design Review. Prior to moving to each next phase in development, there should be a formalized project review that includes review of the device design. These milestone events provide additional opportunities to mitigate risks within the development process itself ― which is a much more cost-effective approach than adjusting downstream after approval.

Several representatives of key areas may be involved in the design review process, including those who may be independent of the development team. A project manager may organize and manage the event and may choose to involve subject matter experts familiar with the development and regulatory process, along with ―  to help align the design with the intended market ― a marketing representative, as well as potential end users.

Key Takeaway #1: Risk assessments should be conducted, as initial input, prior to development, then updated on an ongoing basis.

Ensuring Drug And Device Compatibility

During the development phase, it is important to identify challenges that could impact drug or biopharmaceutical stability, as well as the stability of the device being used to deliver the drug. Most pharmaceutical companies are familiar with assuring drug stability over shelf life. The most fundamental, additional challenge, however, is to understand the shelf life of the device and the interaction of all individual components and constituent parts once they are together.

Without walking through the steps of the design control or general development process again, I will highlight key areas for awareness. Compatibility can mean various things. For scientists, it often means chemical compatibility. For engineers, it often means functional compatibility. Given the range of potential stakeholders and their varied expertise and focus areas, I encourage thinking broadly about the term.

As just one example of common causes of compatibility issues, medical device failures are frequently related to materials. So, demonstrating that the delivery device is composed of a material that will be compatible with a) the drug product, b) the manufacturing process, and c) the sterilization process is just one key step that should be confirmed or resolved before going too far down the development path. Also instrumental during development is understanding the compatibility of the drug product with anticipated environmental storage conditions over the shelf life of the combination product or device.

As with any development program, conducting a literature search, acquiring technical data from the supplier, and performing  internal testing should  all be utilized to provide substance behind any compatibility-related decisions. All of these decisions should be documented for future reference.

Another unique consideration is how the primary package that contains the drug product connects with the delivery device. Quite often these products are not developed together, so you could be taking two separately developed products and hoping they will work together. I once helped resolve  a glass breakage issue that had arisen because of an oversight in the area of compatibility: During the development of a prefilled syringe for an autoinjector, a missed risk later emerged because the syringe's critical dimensions had been assumed to be appropriate for the autoinjector but had not undergone critical verification steps.

A lesson learned from that scenario is that relying solely on supplier specifications proved to be inadequate. What was needed earlier in the development process is a team member who understands the syringe-autoinjector interaction. This role typically falls between packaging and device engineers. As the Market Authorization Holder, you must ensure that these kinds of compatibility requirements are met early in development.

Key Takeaway #2: Compatibility has a broad meaning and must be understood throughout product shelf life.

Designing For Regulatory Compliance

Lastly, as with any medical device, getting a drug-device combination product to market (and, ultimately, to patients) brings particular regulatory approval challenges. For developers of such products, having to comply with both pharma and device regulations can be new, adding additional requirements. And for those companies preparing products for global markets, there are distinctly different regulatory stakeholders to engage with. In Europe, for example, engaging with Notified Bodies, as well as with regulatory agencies, is crucial to approval. So is compliance with the EU’s new Medical Device Regulation (MDR), particularly Annex 1's General Safety and Performance Requirements (GSPRs).

In general, alignment with all pertinent FDA, MDR, and ISO standards is necessary. Plus, there remains the additional challenge of keeping up with constant updates to the various standards.

In the US, one example of a compliance issue that can arise from unawareness is when a drug and device are used together in a kit, which the FDA considers to be a combination product. If the device team overseeing this assembly for clinical studies does not have a team member experienced with clinical operations practices, the lack of that experience could lead to compliance problems. This is a compliance miss I have witnessed occurring for various companies.

Melding All The Parts Of Drug-Device Combinations

Not only is compliance necessary for gaining market approvals from regulatory agencies, but it is also simply good practice in ensuring product safety, efficacy, and quality. In the case of a combination product, it is essential that development procedures and processes reflect the unique nature of combination products and aren’t simply generic overlays. In any development process, there are (or should be) Standard Operating Procedures (SOPs) or similar documents that provide a framework for a pharma company or a device company. The coming together of these entities or components — pharma/drug with device — and the risk management required for involving them in one combined program must be implemented procedurally. Educating staff working on these combination product programs is a must so that they understand why documentation and change management are so important.

Staying informed also applies to relationships with suppliers for product development and design. For instance, if you’re relying on a supplier of a platform delivery system, you’ll want to diligently work to understand and confirm the supplier’s knowledge of and capability for applying change controls during the development process. If design changes are not appropriately documented by the supplier of a platform that is being purchased and employed as part of your combination product, regulatory approvals could be delayed. Remember, your supplier is (or should be) a collaborative part of your development team and, therefore, has a significant potential impact (positively or negatively) on your organization’s ability to apply Design Controls effectively.

Key Takeaway #3: Even great scientists and technologists face delays if processes aren't executed or documented properly.

Frankly, risk management, chemical and functional compatibility, and regulatory compliance form the cornerstones for successful Design Controls. Executed properly, they can substantially increase the likelihood of regulatory approval and market acceptance.