How to ensure you're building the right product in MedTech (free tool)

Jul 14

Perhaps the most important stage in developing a MedTech device or Combination Product is in requirements definition. This may sound unusual to those of us used to just getting on and building things, but most approval and adoption failures happen either because the wrong product was developed, or the product requirements and design justification were not sufficiently well considered and documented, making it impossible to demonstrate safety and efficacy to regulators.

We often call this stage of development "stage 0" - the phase where you are working out what it is, exactly, you need to do

This early stage in shaping a product is also one of the most challenging, a 'blank sheet of paper' problem full of uncertainties and unknowns. It's often easy for us to talk at a broad brush level about what we're trying to develop, but much harder in detail. How do we move from the ‘feel’ of what’s needed to something concrete, whilst maintaining a creative approach? How do we ensure everyone is aligned around the same mission, though they come at it from different directions? Moreover, how do we ensure that what we deliver meets the customer need, and not simply our perception of it?

If this is a challenge you are facing, the key is to get structured in how you are identifying and documenting your stakeholders, their requirements, which ones your system will address, and the design features that best meet them. Doing this well means that you have a well-positioned and compliant device - ready to be approved and used by providers, practitioners, and patients.

Where to start - the Target Product Profile

The first step in your journey from abstract idea to well defined product is your Target Product Profile (TPP). This sounds complicated, but on its face is a simple; a structured document that identifies the key stakeholders for your product and their needs at the highest level. Key is to understand what it is that will make your product a success in the eyes of each stakeholder, in their terms. There's no need to get too technical at this point, and it can be easier not to be, but feel free to put in any deeper detail you have.

A typical MedTech TPP would include a range of stakeholders, for example:

Patients - the people who must safely benefit from the diagnostic or therapeutic performance of your product, and whose broader needs must be accommodated
Users - the people who will handle and apply your device, this may be a patient, a practitioner or a carer. But it's best to understand their needs separate from the needs of the patient themselves
Regulators - those responsible for approving your device, who need to see that the device has been validated against key performance, safety, and quality standards
Payers - those who will pay for your device, typically health systems or insurers, who have expectations around cost efficacy, total price, and value for money against competitors in the space
Practitioners - doctors, nurses, or any other healthcare professional who may prescribe or come into contact with your device. They may have concerns that go beyond the benefit for the patient including ease of training, familiarity of use, and economy of their time
Providers - essentially the health system(s) your device will exist within, an important stakeholder as these are the ones who most commonly make purchasing decisions. Typically concerned with value for money, fit with existing systems and processes, use of wider clinical resources, and storage and distribution aspects
Your Company (Manufacturer) - Lastly, don't forget that the device also needs to work for you. Do you have cost of goods and revenue expectations? Are you seeking to be differentiated against competitors? If so, how? What is your target time to market and can the envisioned device reasonably achieve that? All of elements can be captured in a TPP

You may have more or fewer stakeholders for your individual device (for example, if you're working with a partner, who also have their own needs), but key is to identify those you do have, and what those needs are.

As mentioned, at the TPP level this can be high level and descriptive, if we imagine a simple syringe, we might consider the following TPP elements, for example:

Patient need 1: The materials and dimensions of the device must allow for the drug product to be delivered suitably quickly
User need 5: The device must be of a size and that comfortably fits within the patient hand and enables deliver of the drug product
Regulator need 2: The device must adhere to all relevant regulations around needle safety
Etc.

The point in keeping the needs relatively abstract at this stage is to most effectively set the scene for the product. The aim is to achieve three things:

Agreement - For a product to succeed, there needs to be alignment across the team on what the goals are, including people who may not be technical. Keeping things abstract and high level to begin with helps get everyone on the same page, and helps with discussion
Justification - Each of your needs should be paired with a justification - why is it essential that your system meets this need? - this ensures that you are building the right system, but is also the important first step in your Quality and Regulatory process, where the requirement is to show why your device is designed the way it is
Traceability - Eventually you will add specificity underneath each of these TPP elements, but starting from the top down allows you to trace every requirement to what it delivers for a key stakeholder. Important for managing your requirements internally, and critical for achieving regulatory approval

Putting these pieces together then, we are starting to build the core of a good TPP. A group of identified stakeholders, with their needs described, along with a justification for each need. Don't forget to give each need a unique reference number again to enable traceability, and the basics are all there.

It can often make sense at this stage to break the needs down another level deeper where you have justified sub-elements. For example, perhaps you know that patients won't tolerate a delivery period longer than 20s, or that a maximum plunger length of 15cm keeps things manageable for users. This is also where the TPP aids development, in identifying what details you do know, and which you don't

A final point is that the TPP is a living document. It is your compass for you product, providing the definition of success, but often as projects evolve so does our definition of success, therefore the TPP should be revised regularly to keep it up to date and relevant

If you'd like a place to start you can download our TPP template here

Going further - The TPP Cascade

In practice the TPP is best used as the first element in a cascade of documents that goes from the abstract to the specific, and identifies the key design requirements for your product that you can take forward into formal design development

We've already outlined the Target Product Profile, which is your high level description of what the device needs to do

Next comes one or several Target Performance Specifications (TPS), which is where you define how a TPS may be met. For example, taking our syringe example above, and presuming our TPP requirement is for a delivery time of 20s. A TPS may state:

The syringe must have a needle diameter that allows a 5ml volume of a 50cPs fluid to pass through within 20s, or
The syringe must use the application of force by the user to internally generate a 500N force over a period of 20s, or
The syringe must include a sufficient number of micro-needles to allow 5ml volume of 50cPs fluid to pass through within 20s

Exactly which requirements you use will depend of course on what the innovative element of your device is. It is also an exercise however in balancing your full suite of requirements. For example applying a 500N force may be practical from a patient need point of view, but may damage the drug product of your key development partner. Micro-needles may be an effective solution, but be too costly against the needs of Payers. A single needle solution may be effective, but fail to give you the market differentiation you need.

The core point is that a given solution must be internally consistent, and meet the needs of your stakeholders. Secondarily, there may be elements in the TPP you don't know how to address, and so the TPS makes clear what you need to discover. Thirdly, there may be more combination of design features that delivers to the needs, and so it's important not to go simply for the first idea, but the most optimal.

Assessing your options - Quality Function Deployment

All of which raises the question - how do you know what the most optimal solution is? In practice, this is always a judgement call. We will never have the complete information to hand to know 100% which path forward is most optimal, and, in any case, things change. Competitors come on the market, budgets shrink or grow, performance expectations change

We can give ourselves the best chance in selecting the optimal route however by using a structured analysis such as Quality Function Deployment (QFD). The detail of this are a little outside the scope of this article, but you can read more here, here, and here.

Quality Function Deployment is also not the only approach (but is a favourite of ours), any structured analysis will work. Key is to map which needs are important, and their relative importance, against the feature combination that can be used to address the needs, and how successfully they do that.

Again, there is often a lot of subjectivity here, but the approach is hugely useful in clarifying how different design options (captured in TPSs) stack up. It also, again, provides traceability and design justification against the overall definition of success. Lastly, it is a great tool for when the unexpected happens, to identify what your best backup option is when things change

Getting to the detail - Target Build Specification

Congratulations - you've identified your target needs, you've built potential concepts to meet them, and you've identified the optimal path forward. Now its time to get detailed and roll your optimal TPS into a Technical Build Specification. This level is focused on getting specific and detailed around the design requirement for the system - covering material properties, dimensions, operational performance requirements, etc that come together to give the required functionality as expressed in the TPS. The requirements should all be justified, tangible, measurable, and traceable back through the TPS and TPP to the core needs they address

Summary

The TPP cascade represents a structured approach to the early stages of MedTech and Combination Product development focused on ensuring alignment of the team around a clear and common goal whilst also developing and documenting a justified and traceable set of requirements. In so doing, it supports both the development itself as well as the later regulatory approvals and market adoption. It is a toolkit that not only aids design itself, but in identifying areas of unknown, where research and experimentation needs to be conducted to develop an optimal device design.

As such it remains our tried, true, and recommended method to make sure you're building the right product for a MedTech or Combination Product market

Are you facing challenges in your MedTech or Combination Product development? Feel free to contact us directly here for a no obligation 1-on-1 chat

Want to access our free TPP tool? It's here

Alexander Booth