Frame the problem
Describe who experiences the problem, in which workflow, how it is managed today and what harm or cost follows. Separate the user from the beneficiary and decision-maker.
A narrow intended use creates a testable product hypothesis and reduces unsafe feature expansion.
Design evidence with the product
Map every planned claim to a measurement. Medical, technical and operational outcomes may require different studies. If the software influences clinical decisions, regulatory and quality requirements should be considered early.
Data access, consent, security and human oversight are product requirements, not paperwork added after a prototype.
Pilot in a real workflow
A useful pilot specifies entry criteria, users, training, fallback procedures, success metrics and stopping rules. It should capture unintended consequences and burden on staff.
Scale only after the team understands who benefits, where performance fails and what resources are needed to maintain the service.
Quick answers
Frequently asked questions
When should regulation be considered?
At the intended-use stage. Claims and how outputs affect decisions can change the applicable path.
Is a prototype a medical product?
Not necessarily. A prototype may test usability or workflow hypotheses, but it should not make unvalidated medical claims.
Evidence base
Primary and authoritative sources
Use the linked source documents for professional or current interpretation.