In a previous article, we described how pharmaceutical companies can develop and/or select a drug delivery device that meets users’ needs. Specifically, we discussed the importance of considering users’ impairments, drug administration attributes (e.g., administration frequency and urgency), and device characteristics that might facilitate or hinder safe and effective combination product use.

Although some pharmaceutical companies develop their own drug delivery devices, it’s quite common for others to use, and perhaps customize, a “platform” device developed by a drug delivery device developer. Pharmaceutical companies might select an existing platform device because they lack device development capabilities and/or wish to reduce development cost, time and risk. There are several companies that develop such platform devices, which may be used to administer medication subcutaneously, transdermally, or via inhalation. Some of the dominant players in the injection device business are BD, Haselmeier, Owen Mumford, SHL Group and Ypsomed.

Read Part I: Select a Drug Delivery Device that Meets User Needs Pharmaceutical companies will consider many factors when selecting a platform device, including the device’s manufacturability, biocompatibility, robustness, shelf life and volume. An equally important consideration is the device’s usability and whether the developer applied human factors engineering (HFE) in the course of development to arrive at an optimized device design. The balance of this article describes the steps we recommend pharmaceutical companies perform to evaluate the rigor of a platform device developer’s HFE process.

HFE Assessment Considerations

Some pharmaceutical companies are initially surprised to learn that, in addition to marketing the drug, they, and not the platform device developer, have ultimate responsibility for developing a safe and effective device with a design history file that meets regulators’ expectations. As such, pharmaceutical companies leveraging a platform device need to embrace their responsibility for performing various device development activities, including HFE.

From an HFE standpoint, to reduce the time and cost associated with transforming a platform device to a commercialized product, pharmaceutical companies are well served to do the following:

1. Assess whether the developer applied HFE comprehensively during device development.
2. Request documentation of the activities that could serve as a starting point for the new combination product’s documentation and design history file.
3. Confirm that the HFE data indicates that the device can be used safely and effectively. Notably, such a conclusion ultimately depends on the results of later HFE activities involving the final combination product, as well as the intended end-users.

Below, we describe HFE activities that a platform device developer should have (ideally) completed as part of their device development process.

• User research. The device developer should have conducted user research such as observations, interviews, focus groups, and/or surveys to identify and understand user needs. If the developer conducted such research, ask about participants’ demographics (e.g., ages, medical conditions, impairments) so that you (the pharmaceutical company developing the combination product) can assess how applicable the findings are to your product’s intended users. Many platform device developers include impaired individuals in user research, as well as usability tests, to demonstrate that a given device can be used by a broad user population, including those with compromised dexterity. But, user research findings from one user population, even if considered a “worst-case” sample, might not be transferrable to another user group. For example, user interface requirements derived from research involving seniors with arthritis-related dexterity impairments might not align with the needs of children with growth hormone deficiency.
• Use-related risk analysis. Combination product manufacturers must conduct a comprehensive use-related risk analysis (URRA), such as a Use Failure Modes and Effects Analysis (uFMEA), to ensure that all use-related risks have been mitigated and reduced to an acceptable level. Having access to the platform device’s URRA enables you to determine whether use-related risks were mitigated through device and/or labeling changes, the latter being considerably less effective and less acceptable to regulators. When scanning through the URRA, look for any substantial gaps (e.g., missing use steps, omission of pre-mitigation risk ratings) that will need to be filled to produce a thorough, complete analysis. Unfortunately, despite regulators’ focus on HFE and potential user interaction issues, some device developers still exclude use-related risks from their risk analysis efforts, typically due to naivety rather than negligence.
• Known use-related problems analysis and post-market surveillance. Assess whether the device developer documented adverse events that have occurred with marketed versions of the platform device or similar combination products. If the developer has not closely monitored commercialized versions of the platform device, perform your own search for adverse events in public databases such as FDA’s Manufacturer and User Facility Device Experience (MAUDE) database. Confirming that the developer identified and mitigated known use problems (ideally by modifying the device design) will help ensure that your combination product will not be prone to the same user interaction issues upon commercialization.
• Usability testing. If the device developer conducted one or more usability tests, review the usability testing approach, including each test’s goals, participant sample (e.g., sample size, medical conditions, impairments), and the activities performed by test participants. Also review each test’s results for specific, actionable findings. Overly general findings are far less enlightening and telling of the device’s interaction qualities than patterns of use difficulties or detailed task performance data. For example, explaining that several participants administered expired medication because they overlooked the relatively small expiration date is more informative than reporting that all participants rated the device’s use-safety as a three or higher on a five-point scale.
  Consider how the developer responded to each test’s results; ideally, the device’s design was modified to address user interaction difficulties that participants encountered. Such design changes could have included shape-coding components to facilitate correct assembly or reducing the device actuation force to accommodate elderly users with reduced hand strength. It is a red flag if the developer didn’t conduct any usability testing during device development. A lack of such testing suggests that the device design might not reflect users’ needs, and might hinder safe and effective use. Although it is unreasonable to expect the developer to have conducted a usability test with your specific intended users, some testing with end-users (e.g., laypeople, healthcare professionals) reflects good HFE process. If usability testing data is unavailable, consider conducting a usability test as part of your due diligence efforts to assess the platform device’s interaction strengths and, most importantly, shortcomings that might warrant design modifications.
• Instructions for use. At least some device developers prepare a generic template of the instructions for use that cover the primary device use steps. Determine the extent to which you can leverage these instructions for your combination product, modifying and/or improving upon them to suit your specific product and its intended use. Instructions comprised of concise, active-voice text instructions and informative graphics often facilitate correct use more than lengthy, text-heavy documents. If you are disappointed by the quality of the developer’s instructions, you will be best served to develop your own from scratch rather than trying to fine-tune fundamentally flawed labeling.

In addition to assessing whether the above HFE activities were completed, inquire about the extent to which the platform device can be customized to meet your intended users’ needs. During the combination product’s development, you might identify design flaws that need to be remedied to ensure safe and effective use. As such, it is important to understand upfront whether the platform device developer will accommodate device changes. If design changes are not feasible, your mitigation options will be limited to labeling changes, which are suboptimal and often ineffective. At a minimum, most platform device developers invite you to select your preferred color for certain device components, such as the cap, actuation button(s), or outer trim. There might be further opportunities to change the device to improve usability and use-safety, such as adding a rubberized grip or enlarging an auto-injector’s medication viewing window. Although customizing the platform device will likely increase manufacturing time and cost, it is likely a worthwhile tradeoff, noting that a basic platform device is not a “one size fits all” solution.

How to Perform HFE Due Diligence

So, how do you gather all of this information from the platform device developer? We recommend meeting in person to learn more about the general HFE process and activities performed, and to understand which HFE end products the developer will allow you to leverage for your combination product. Based on our experience, the extent to which device developers share their development documentation can vary widely. Ensure the developer has a robust quality management system (QMS), and ask how HFE fits in. A well-established QMS should include one or more standard operating procedures that outline HFE activities. Meetings with the device developer will undoubtedly include discussions of other important topics, including cost, timeline and device customization opportunities. But, it’s important not to overlook HFE, noting HFE’s central role in ensuring safe, effective and satisfying device use.

If you do not have sufficient HFE expertise to drive the discussion, engage a consultant with deep experience applying HFE to combination product development to support your due diligence efforts. This subject matter expert can facilitate discussions about HFE and rigorously assess how well the platform device developer’s HFE end products satisfy FDA’s HFE expectations and IEC 62366 requirements.

If the developer’s HFE documentation is sparse, you and/or an HFE expert can still assess whether a given platform device reflects strong HFE. For example, you can research known problems with a given device, or review and critique of one or more candidate platform devices, considering the intended users, drug administration frequency, and other factors described in our previous article. If the platform device is already marketed for one or more indications, you could interview device users with similar characteristics of your intended users, inquiring about the device’s ease of use, perceived safety, and the user’s satisfaction. Whether you assess HFE via your own efforts or by reviewing the device developer’s documentation, doing so early on will reduce the business risk of working with a suboptimal platform device.

Conclusion

If a platform device developer hesitates to describe their HFE process and/or share sample end products, it’s an indication that the developer might not have developed the device to optimize its usability and use safety. Furthermore, a developer that shies away from open dialogue during due diligence may not be a valuable, highly collaborative partner after you purchase their device and embark on your combination product development efforts. If you conclude that the developer’s HFE work is inadequate, select a different platform device developer whose device reflects good HFE and the benefits of user-centered design. If an alternative developer is not an option, ensure your project timelines and budget account for performing various HFE activities and perhaps needing to modify or fully redesign the device to ensure safe use and meet regulators’ expectations.

We know that some platform device developers boast about their HFE work as a key differentiator and an essential factor that led to an optimized device design. Selecting a developer that has embraced HFE, rather than neglected it, can yield substantial development benefits, including decreased development time and cost due to fewer late-stage redesign “emergencies,” as well as increased likelihood of validation usability test success. Leveraging a platform drug delivery device that reflects robust HFE—and, perhaps, is already marketed and proven effective for other indications—reduces business risk. Furthermore, end-users will value a combination product that enables safe, effective and satisfying use, which will lead to greater customer satisfaction, increased compliance to a prescribed medication regimen, and fewer adverse events upon commercialization.