5 Secrets to Actionable User Needs in Medtech

User Needs (UNs) are the foundational component of your Design History File (DHF). This single document should be the one that feeds design requirements, risk management, and the V&V process. It’s the trunk of the tree.

And yet, so often, UNs are captured poorly or not captured at all. This brief article aims to demystify the process of capturing and documenting actionable user needs.

1. Draft User Needs during discovery (not development)

First, what is “discovery”? It’s the time you spend evaluating the disease state fundamentals, standards of care, populations, outcomes, existing solutions, clinical workflows, healthcare economics, and more. This is the information that should drive user requirements. Defining user requirements before development will ensure that you are focused on the true needs and opportunities rather than crafting user requirements to support a pre-conceived device concept.

If you have already landed on a design concept, it’s not too late. Just be willing to put this concept aside from your mental space when heading back into discovery mode. If a device concept is on-the-mind during this process, you may be susceptible to confirmation bias – hearing the things that support what you have developed rather than true needs of patients, providers, and other stakeholders.

2. Don't describe the device when describing User Needs

Users don't need a device. They need a therapy, restored function, diagnosis, medical information, safety, etc. When creating UNs, write in terms of what users actually need, and completely remove the term "device" or any related synonym. For example, a UN in violation of this concept would be “The device shall monitor core body temperature within +/- 1.0 degrees Celsius.” Instead, change this UN to state, “Patients shall be capable of monitoring their core body temperatures within +/- 1.0 degrees Celsius.”

Why is this important? It gets back to the main point – users don't need a device – they need the benefit that the device aims to achieve. Focus your UNs on the benefits and the avoidance of specific hazards. Moreover, UNs should define the success criteria by which potential solutions are evaluated. If you embed your solution in the need statements, then you are presupposing that your solution is the right one. It’s circular reasoning.

3. Name the user in User Needs

The term “user” in “user needs” is a bit confusing. “Users” can mean patients, physicians, nurses, technicians, maintenance personnel, home caregivers, family members, and/or others that may affect or be affected by a medical intervention.

Be specific in your UNs by naming the user. Avoid "The User shall...", and instead specify the user group that relates to the requirement. "Patients shall.." or "Health care providers shall.." Doing so will improve the specificity around the UN, streamline the validation process, and make linked design inputs more direct and actionable (more on that next).

4. Separate User Needs from Design Inputs

Don’t lump User Needs and Design Inputs in the same category - so many organizations do, and it just makes organization complex and messy. While there is no regulatory requirement to separate UNs and DIs in your DHF, there is a practical reason to do so - UNs define what patients, operators, and other stakeholders need, whereas DIs define how a medical device accomplishes those needs. They are not the same! Since UNs and DIs capture very different requirements, they deserve unique fields in design control documentation that distinguish them.

Moreover, there is an important flow from UNs to DIs that should be captured in design control documentation. When UNs are set up properly, they should drive DIs. For instance, a UN may be created that requires single-handed use in delivering a therapy. This UN may drive DIs related to the device weight and gripping elements. With this same logic in-mind, lone DIs should not exist. The only reason for a DI to exist is to fulfill a UN. There may be other attributes of a design that are necessary for functional, aesthetic, or other reasons, but unless they are fulfilling a specific UN, they should not be considered a DI. Following this logic will remove unnecessary UNs and DIs and will streamline related verification and validation activities.

Often, a traceability matrix is useful in showing the linkages between UNs and DIs. While many eQMS systems can be used to connect UNs and DIs, Word/Excel traceability matrices can be equally effective. (We prefer Word due to change tracking benefits – you can download our Trace Matrix through link below if interested.)

5. Ask "How would I validate this?" to all User Needs

Sometimes, UNs are written in overly broad terms. For instance, one may write, "The patient shall not be exposed to undue risk." In this example, how would the UN be validated? There is no practical way to accomplish this validation. Therefore, the UN must be broken down into more discrete requirements that can be validated through practical methods.

It is also important to understand that some UNs (e.g. efficacy related UNs) may require clinical validation, whereas other UNs (e.g. training, usability) may require human factors validations. Process validations (e.g. sterilization, biocompatibility) may also be required to validate hazards related to infectious disease or toxicity. For each UN, it is important to question the validation process that will be utilized. Again, a traceability matrix to link validation activities to UNs is a useful organizational and planning tool, and it will pull together many elements of your Design History File (DHF).

Summary

If you have captured the right user needs and documented them clearly, you will be creating a reliable foundation for your DHF, which will pay dividends during your design, documentation, testing, and regulatory filing processes. Take the time to get this right – you and your team will be thankful down the road.