Skip to content
Yujan Shrestha, MDApr 27, 2024 3:18:30 PM3 min read

User Needs vs. Requirements for Software as a Medical Device

User Needs vs. Requirements for Software as a Medical Device
4:25

I often get questions about the difference between user needs and requirements. Understanding this distinction is crucial for successfully bringing a software as a medical device (SaMD) to market. In this article, we'll dive into frequently asked questions, best practices, and examples to clarify the concepts of user needs and requirements.

 

Frequently Asked Questions

Q: What's the difference between a user need and a requirement?

A: While related, user needs and requirements serve different purposes:

  • User needs describe what the user wants to achieve with the software, focusing on the problem to be solved. They are written from the user's perspective, typically starting with "User needs to..."
  • Requirements specify what the software must do to meet the user needs. They are written from a technical viewpoint, usually beginning with "Software must..."

while there are a ton of nuances a simple rule of thumb is requirements must start with “software must” and user needs must start with “user needs to”

Q: Why is it important to distinguish between user needs and requirements?

A: Separating user needs from requirements allows you to:

  • Ensure the software will actually solve the users' problems and meet their goals
  • Avoid overengineering the solution by focusing only on what's needed
  • Create a clear, verifiable set of specifications for the software
  • Facilitate clearer communication between stakeholders

Q: Who is responsible for defining user needs and requirements?

A: Defining user needs often involves input from end-users, clinical stakeholders, and the marketing team. Requirements are typically written by the product managers and engineers responsible for development, with input from clinical experts to ensure medical relevance and regulatory compliance.

Best Practices & Examples

Consider this scenario: You're developing an AI-based tool to automatically detect lung nodules on CT scans. Let's look at some best practices for defining user needs and requirements.

Capturing User Needs

Start by understanding the problem from the users' perspective:

  • Radiologist needs to accurately identify lung nodules on CT scans
  • Radiologist needs to efficiently review a large volume of CT scans
  • Radiologist needs to prioritize scans with potentially malignant nodules
  • Radiologist needs to integrate AI results into their workflow

Notice each statement focuses on the user's goals, not the technical implementation.

Defining Requirements

Note that while the rest of the industry uses “shall”, I prefer “must” because it is clearer and more modern language.

Next, translate the user needs into clear, verifiable requirements:

  • Software must detect lung nodules on CT scans with a sensitivity of 95%
  • Software must process a CT scan in under 30 seconds
  • Software must assign a malignancy risk score to each detected nodule
  • Software must integrate with popular PACS systems via the DICOM protocol

Each requirement is specific, measurable, and linked to a user need.

Some other tips:

  • Involve diverse stakeholders early to capture all relevant needs
  • Use clear, concise language in user needs and requirements
  • Ensure requirements are feasible given technical, regulatory, and resource constraints
  • Regularly review and refine user needs and requirements throughout development

Bringing It All Together

Defining clear user needs and requirements is a critical first step in developing successful AI/ML software for healthcare. User needs keep your efforts laser-focused on solving real problems for your clinical users. Requirements ensure you build a product that meets those needs in a robust, verifiable way. By understanding the distinction and interplay between the two, you'll be well on your way to creating SaMD that make a real difference in the practice of medicine.

Of course, this is just the tip of the iceberg when it comes to building SaMD that's clinically valuable and regulatory compliant. From data management to algorithm design to quality assurance, there are many other factors to consider. If you need expert guidance navigating the complex landscape of SaMD feel free to reach out. I'm always happy to share my experience and insights to help bring these transformative technologies to patients and providers.

 

avatar

Yujan Shrestha, MD

My first SaMD FDA submission took me over a year with 3 FDA hold letters. 5 years and 10+ submission later, I can do them in 3 months or less. I made a lot of mistakes along the way. Help me help you avoid those. I have over 10 years of experience in the SaMD space as an engineer. I am a practicing AI/ML engineer and regulatory consultant with a clinical background so I can bridge knowledge gaps to help get AI/ML from concept to bedside. I enjoy working with people bringing AI/ML SaMD to market. Are you one of those people? I would love to hear your story!

COMMENTS

RELATED ARTICLES