Device Positioning Tool

What is the device?

The physical form and software architecture are the two most consequential classification inputs — they determine which standards apply and how regulators will initially categorise your product.

Does it have a physical hardware component? select one

How the device contacts or interacts with the body is a primary classification driver in most frameworks. Duration and nature of body contact determines risk tier before anything else.

No physical hardware

Continuously worn / wearable

Handheld / intermittently applied

Implantable

Drug delivery

Combination product

Device name or brief description optional

What is the device designed to do?

How you describe what your device does is the single most consequential positioning decision you will make. It determines whether you are a medical device at all — and if so, at what regulatory risk tier.

Is the device intended to do any of the following to or for a human being?

Under EU MDR, UK MDR, and FDA definitions, a product is a medical device if it is intended to: diagnose, prevent, monitor, predict, treat, or alleviate a disease or condition; compensate for an injury or disability; or investigate, replace, or modify the anatomy or a physiological process. If your product does any of these things — even partially — it is likely regulated as a medical device in at least one jurisdiction.

Yes

No — it is a wellness or lifestyle product

Primary intended function select all that apply

Prevent

Screen or detect

Diagnose or aid in diagnosis

Monitor

Predict or calculate risk of

Treat

Relieve symptoms or compensate for

Disease, condition, or physiological parameter

What is the clinical purpose — the "so that…"? optional but important

This separates what is measured from why it is measured. "Monitors HRV" is a mechanism; "so that clinicians can detect early signs of infection" is a clinical purpose. This distinction affects both your evidence requirements and your regulatory risk tier.

How does the device work? mechanism of action — optional

The operating principle explains how the device achieves its function — e.g. via algorithm, biosensor, electrical stimulation. Required for many regulatory submissions and risk management documentation.

Output type select all that apply

Whether your output is a recommendation vs. a measurement fundamentally changes your evidence requirements.

Qualitative (yes/no)

Quantitative measurement

Risk score / probability

Treatment recommendation

Alert / notification

Trend / longitudinal data

Who is the device used on?

The patient population defines the scope of your clinical evidence. Regulators assume the broadest possible population if you don't specify one.

Target patient population

Be specific: age range, sex, disease stage, relevant comorbidities. Vague populations expand your evidence burden.

Contraindicated / excluded populations optional but strongly recommended

Explicitly stating who is excluded contains your evidence requirements and protects against off-label use claims.

Who operates it, and where?

The intended user and use environment drive usability requirements, labelling, and risk management scope.

Intended operator select one

Whether a clinician or a lay user operates the device is the primary driver of usability requirements. A device used without clinical supervision carries a higher burden to be safe and understandable in untrained hands.

Healthcare professional

Patient / lay user

Both

Use environment select one

Home and community use introduces variables that clinical settings do not — power reliability, user distraction, absence of backup — and triggers additional usability and risk management requirements under IEC 62366 and most regulatory frameworks.

Clinical setting

Home / community

Both

Anything else you want reflected in the statement? optional

Drafting your statement…