COMBINATION CORNER - Keys to Avoiding Common Pitfalls in the Development of Product Requirements for Drug Combination Products

INTRODUCTION

In combination product development, creating a Product Requirements Document (PRD) that serves FDA Design Control (DC) regulatory needs is more complex than traditional medical device development. The increased complexity stems from the need to account for the interdependencies between the drug and device. The pitfalls commonly observed within PRD’s at Combination Product organizations are:

Poor Use Case Modeling: Teams do not use systematic approaches when defining the diverse use cases applicable for the combination product.
Incomplete User Needs: Teams do not involve a complete array of perspectives that support a full set of user needs.
Lack of Cross-Functional Team Input: Inadequate identification and integration of requirements from both drug and device development teams.

The aforementioned pitfalls can have significant ramifications on combination product programs and are usually uncovered late in the development timeline, ie, during validation or commercialization. It goes without saying that a delayed market launch or a slow commercial adoption rate due to unsuccessful market fit are costly penalties. Tips on how to build a robust combination product PRD from the beginning of a project are further explored.

WHAT IS A PRD, USE CASE & USER NEED, & HOW DO THEY CONNECT TO EACH OTHER?

In order to understand how to build a robust PRD, one needs to understand the key terminology being utilized throughout the document. Figure 1 provides definitions and visualization of how the terms are connected to each other.

The PRD sets the stage for the entire development program and serves as a foundation for all activities and documentation that need to be generated to show support for satisfying the requirements. A well-structured PRD sets clear guard rails for what the device needs to be, what it needs to do, and describes what the intended use for the device is. The importance of this document reinforces the need for all functional roles to invest an appropriate amount of time on this critical activity.

DEVELOPING DIFFERENT USER CASES STARTS BY DEFINING USER POPULATIONS

When developing a combination product, it is useful to distinguish two populations of users: the “direct user” and the “indirect user” (also referred to as stakeholder).

The direct user includes the patient, the person using the product (eg, nurse, caregiver, and/or patient), the person preparing the product for use, and sometimes, the person(s) transporting or storing the device prior to use (eg, a drug that is shipped in frozen state). It is critical to recognize that a single device may have multiple direct users, especially as you start looking at what the user may say they need. For example, most users will say that a device should be easy to use, safe to use, and not take too much time to use. But considering an elderly patient and a 20-year old patient, what constitutes “easy to use” for doing something as simple as opening a pill bottle for the 20-year-old may be significantly different for the elderly patient. Similarly, a high-school educated patient and a physician may have very different assumptions and methods on how to interface with a product containing a software interface, and it is important to consider both users throughout the design. If the team misses identifying the right users up front, it is very likely that there will be costly redesigns at a later point in time.

Indirect users, or Stakeholders, are those individuals whose work focuses on different aspects of developing or commercializing the product. These include but are not limited to distributor, marketing, sales, regulatory, finance, etc. Typically, drug development scientists have had minimal consideration for device development, as their primary focus is on the drug therapy. However, the new FDA combination product regulations require the consideration of the interaction between the drug and device. Therefore, the scientists are indirect users (stakeholders) and they will define key needs for the successful delivery of the therapy via the delivery system.

Traditional device development emphasizes researching the needs of the direct user(s) when defining product requirements. However, from a project management perspective, by researching stakeholder needs at the same time as user needs, a combination product project team can potentially reduce the total cost of development by avoiding problems of re-work or other delay-inducing steps. For example, by accounting for input from individuals who manage different aspects of commercializing a medical device product, the project can avoid a situation in which design inputs steer product development to a device that is ultimately too costly for the company to distribute at competitive prices.

DEFINE USER NEEDS BY ASKING HOW THE USERS WILL ACTUALLY USE THE PRODUCT

Once the users and stakeholders have been defined, the next critical step for the team is to “walk the path” of each user by deploying use-case modeling tools early in the requirements building process. Use-case modeling tools enable you to systematically look at each step of how a product is used across each user type, and ask the question, at a very basic level: “A this step, what does the user need the device to do, and what does the user need the drug to do?” That leads to two follow-on questions: “If the user needs the drug to do “X,” then how is the device going to allow or enable the drug do that? If the user needs the device to do “Y,” then how can the drug support that, or at minimum, not impede that from happening?”

These questions about the interconnections between the drug and the device will help with the identification of needs that will ultimately translate into detailed requirements. Going through this exercise will also help the project team reach a consensus on whether the drug or device is the primary mode of action from a development perspective.

If a project team does not deploy use-case modeling tools in developing a PRD, they could miss a step in the process, or miss a particular user or stakeholder need, which may appear minor, but leaves a gap in product requirements. This missing requirement gap carries over into missing a performance evaluation or a safety test, or a specific human factor consideration. The impact of gaps in requirements will also occur in subsequent phases of the project when the team conducts risk analysis, as the risk analysis will be based on an incomplete set of use case steps and requirements. While a product development team cannot expect to identify every requirement early in the project definition phase, using these tools will help capture and document many requirement details that the team may otherwise not uncover until validation testing, during submission, or during an audit. Better to find these missed requirements late in development than after the product is launched into the market and customer complaints or adverse event start coming in.

An example of missing user needs when performing a use-case map is for a drug delivery device that requires both left- and right-hand usage based on who will be administering the medication. The requirement to allow the device to be used in either hand is one that could easily be missed by teams not digging deep into who the user will be and how they use the product. If this type of requirement is missed, the rework and remediation to accommodate both handed users will likely lead to significant design changes, additional costs, and project delays.

INVOLVE THE CROSS-FUNCTIONAL TEAM MEMBERS FROM BOTH DRUG & DEVICE TEAMS

Historically, drug development, device engineering, and R&D professionals specialized in either drug or device development, but not both. This caused an “over-the-wall” approach to development and often resulted in re-do design cycles, missed design features, and in some instances, a “not my problem” attitude when issues would arise. At the onset of a project, bringing in a broad cross-functional team when user needs and product requirements are being developed results in a much stronger and comprehensive PRD.

A well-designed cross-functional working group must involve representatives from both device and drug development teams and should include participation from R&D, engineering, marketing, manufacturing, regulatory, clinical, quality, supply chain, software development and IT (assuming the device has software components), legal, and other commercialization functions. Having someone with clinical experience who also understands and knows the patient will add valuable perspective, while having input from actual patients or users can add significantly to the dialogue while also reducing the time and effort necessary for summative or formative studies. With patient (ie, end-user) input, the development team can better understand the answers to questions such as: “in order for therapy to work better for you, what does the product need to do?” or “how does the device work for you if this or that feature or step was eliminated?” The discussions among the various cross-functional team participants in response to this user input will determine what requirements are ultimately captured in the PRD.

While it may seem excessive to pull such a large group into the discussions on users and use cases so early in a program, the cost of missing key needs and translating these into requirements becomes so much higher than the up-front time investment. While the input of some functions will be less than others, the likelihood of getting design inputs “right the first time” increases substantially through such a cross-functional approach. In the absence of cross-functional input, captured in an effective manner, a project team might find themselves having designed a novel device. For example, a team can develop a drug delivery drug pump that works perfectly to administer the therapy, but only realize after the pump has been launched into the market how negatively customers react to the loudness of the pump notifications and brightness of the user interface screen when using the pump at night and trying to sleep.

It is also important to note that as a development program continues through subsequent phases, issues will arise that will require a requirement to be revisited, renegotiated, and/or a new requirement be created. In these instances, a cross-functional team will more effectively deal with these situations if they also collectively worked together early in the project to create the PRD. More importantly, they will also be able to understand the background/origin of the product requirement to understand why it was identified in the first place.

SUMMARY

Product users not only demand the product to do what it is meant to do, but they also demand it meet their expectations for ease of use. Businesses, on the other hand, focus on minimizing project costs and develop products faster. With this divergent focus, it is more important than ever to bring the right team together early in a project to capture product requirements correctly. The cost of missing needs or requirements goes up exponentially as development proceeds, and many of these requirements can be identified early in the project if the right individuals are at the table.

As previously summarized, the three key steps to capturing the right product requirements include the following: 1) define the users and stakeholders and understand the product use case, 2) identify the user needs by “walking the path” of each use case for each user and ask what the user will need from the product, and 3) have the right cross-functional team members from the start of the project to leverage their broad perspective.

To view this issue and all back issues online, please visit www.drug-dev.com.

Jerzy Wojcik is Senior Director of Regulatory Affairs & Quality Assurance at EdgeOne Medical Inc, an ISO 13485-certified medical device testing firm and consultancy focused on supporting combination products through the device development (design control) process. Prior to EdgeOne Medical, he was responsible for the regulatory oversight of combination and Class III devices at Baxter’s BioScience division (now Baxalta, part of Shire plc). He earned his triple BA in Biology, Medical Technology, and Cytotechnology from Augustana College and is currently an Adjunct Professor in the School of Law at Northwestern University.