Clear answers.
Practical next steps.

Start with what the product is intended to do, not the technology behind it. Identify the medical purpose, intended users, patient population and decisions supported by the output. An app, an AI model and a physical product can each fall within device regulation. Definitions and exclusions differ by market, so a conclusion in one country does not settle the others.

Official sources: FDA: Medical purpose and software functions; European Commission: MDCG 2019-11 rev.1 software guidance

The label alone does not settle the question. A genuine general-wellness function may be outside the device definition or within a specific low-risk policy, depending on its claims, risks and the applicable jurisdiction. Disease-specific diagnosis or treatment claims need closer scrutiny. FDA’s January 2026 wellness guidance concerns a US policy; it is not a global exemption.

Official sources: FDA: General Wellness guidance (January 2026); FDA: Medical purpose and software functions

Not automatically. A clinician in the workflow is one fact, not a universal exclusion. For US clinical decision support, assess all the applicable statutory non-device CDS criteria using the current FDA guidance. Whether the professional can independently review the basis for a recommendation matters. Do not apply that conclusion automatically in the EU or to software intended for patients.

Official sources: FDA: Clinical Decision Support Software (January 2026); European Commission: MDCG 2019-11 rev.1 software guidance

Bring a concrete product description rather than only a pitch deck. A useful briefing includes the intended purpose, target markets, users, population, workflow, claims, screenshots, architecture and known risks. Separate the version you want to launch from future features. This focuses the discussion on decisions that affect your development plan.

There is no direct conversion. FDA uses Classes I, II and III; the EU MDR uses I, IIa, IIb and III. FDA classification depends on the relevant device type, intended use and applicable controls. EU MDR classification follows Annex VIII rules. Work through both systems independently, using the same precise product description.

Official sources: FDA: Classify Your Medical Device; EU MDR: classification and conformity assessment

No. Under MDR Rule 11, software supporting diagnostic or therapeutic decisions is generally IIa, with higher classes where the potential consequences meet the rule’s thresholds. Physiological-monitoring software has a separate branch, including a higher class for certain vital-parameter monitoring. Other software covered by Rule 11 is Class I. Qualification and other applicable rules still matter. IVD software follows the separate IVDR framework.

Official sources: EU MDR: classification and conformity assessment; European Commission: MDCG 2019-11 rev.1 software guidance

No. An exemption from premarket notification does not remove every applicable requirement. General controls, device-specific conditions and limitations on the exemption still need assessment. Registration, listing, labeling, quality and postmarket obligations may apply depending on the product and your role.

Official sources: FDA: Classify Your Medical Device; FDA: Device Registration and Listing

Use a shared evidence strategy where appropriate, but assess market access separately. Great Britain and Northern Ireland have different arrangements. Do not treat an EU classification, CE mark or UKCA mark as automatic permission for every UK market. Recognition policies are changing; verify current MHRA requirements and applicable law for your product and launch date.

Official sources: MHRA: Regulating medical devices in the UK

They answer different questions. Software verification checks whether the implementation meets its requirements. Clinical evaluation considers whether evidence supports the intended medical purpose and performance. For EU medical software, MDCG 2020-1 discusses clinical association or scientific validity, technical or analytical performance, and clinical performance. A new clinical investigation is not automatically required for every product, but engineering test results alone do not establish clinical benefit.

Official sources: MDCG 2020-1: clinical and performance evaluation of software (PDF)

Start early enough that development decisions and evidence are controlled as they happen. Reconstructing requirements, risk decisions and test records at submission time creates avoidable gaps. In the US, QMSR became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. Applicability and exemptions must be checked for the specific device and manufacturer.

Official sources: FDA: Quality Management System Regulation

Consider early feedback when an unresolved question could materially change your evidence plan, study design or submission strategy. FDA’s Q-Submission Program provides mechanisms for interactions about planned device submissions. Describe your proposed approach, explain the uncertainty and ask focused questions. Feedback is not marketing authorization.

Official sources: FDA: Q-Submission Program guidance

No. Establishment registration and device listing do not, by themselves, mean FDA clearance or approval. They are distinct from a 510(k) clearance, De Novo authorization or PMA approval. Describe the actual regulatory status accurately, including the scope of the authorized intended use.

Official sources: FDA: Device Registration and Listing

Assess each change under the applicable requirements and any FDA-authorized Predetermined Change Control Plan (PCCP). A change within an authorized plan, implemented according to that plan, may proceed without a new marketing submission for that change. An internal roadmap is not an authorized PCCP, and a plan does not cover every future feature or another market’s requirements.

Official sources: FDA: Predetermined Change Control Plans

That is a poor planning assumption for a connected device. Security affects architecture, third-party components, testing and maintenance. FDA’s February 2026 guidance addresses lifecycle considerations and premarket documentation. An SBOM does not replace threat assessment, security testing or a workable vulnerability-response process. Statutory cyber-device requirements need a separate applicability assessment.

Official sources: FDA: Cybersecurity guidance (February 2026)

A credible estimate starts with scope. Separate development, evidence generation, submission preparation, external review and responses to questions. Classification, novelty, data gaps, third-party availability and the market affect the schedule. An advertised review target is not a promise of your total time to market.

“Function 1” is the first software function entered in the check, not a regulatory category. “Borderline” signals that the limited screening cannot reach a sufficiently supported conclusion from the answers and rules. An uncertain answer or a specialist-review gate can cause it. It does not mean your product is halfway between two legal classes.

Device status and classification are separate assessments. A class may remain unassigned when the screened scope, answers or verified category are insufficient. DeviceOrNot’s classification rules remain draft; a conditional candidate is not a validated class assignment. For the US, the relevant FDA classification regulation and product code need a supported assessment.

Yes. The DeviceOrNot software screening check is free to use, with no payment required. It takes about five minutes. The current release is restricted to authorized manual testers.

DeviceOrNot provides a provisional, educational assessment of each software function using your answers about its intended purpose, users and claims. It shows reasoning and source links for the US, European Union and United Kingdom. It does not provide an official determination, legal advice or regulatory approval. Regulatory validation of this release is still pending.

DeviceOrNot currently screens software functions. It is not a general qualification or classification tool for physical medical devices, equipment or accessories. A product containing hardware needs a separate assessment of the full product.

Qualification explores whether a software function may fall within medical-device rules. The separate classification step explores its potential regulatory class or category after qualification. Classification rules in this release remain DRAFT, and all results need expert review before a regulatory decision.

The questionnaire offers separate US FDA, EU MDR or IVDR qualification, and UK MHRA perspectives. The current UK screening is focused on Great Britain; Northern Ireland requires separate consideration. Coverage is a starting point for expert review, not a complete assessment of every applicable law.

DeviceOrNot helps builders explore whether a health-software function may qualify as a medical device, a topic often described as Software as a Medical Device or SaMD. Its questionnaire considers functions separately rather than assuming every feature in a product has the same status.

Prepare a plain-language description of each software function, its intended users, intended purpose and product claims. Contact details are optional; you can use the check without them. Do not enter patient data, medical records or confidential information. Read the privacy notice for storage and deletion details.

No. A deterministic rules engine produces the screening outcome from your answers and the versioned rules. Optional AI assistance can help with wording and explanations when enabled; AI is currently disabled on staging.