Regulation as a Design Input for Medical Software

Regulation becomes a useful medical-software design input when a team translates a proposed clinical claim into product requirements, evidence, and lifecycle controls before choosing features. The first artifact is not a submission document. It is a precise statement of who will use the product, for which people, in what setting, using which inputs, to support which decision.

Actual classification, submissions, quality systems, and market access require jurisdiction-specific professional analysis.

Key points#

• Write the intended purpose and clinical claim before the feature list.
• Translate each part of the claim into design inputs, hazards, evidence, and monitoring.
• FDA and EU MDR pathways overlap in scientific questions but differ in legal structure, classification, and review.
• Evidence should be proportionate to risk and claim, while still covering analytical validity, clinical association, and real-world performance where relevant.
• Compliance does not guarantee trust; usability, transparency, equity, security, and accountable fallback must also be designed.

The claim-to-specification workflow#

A practical intended-use sentence answers:

1. Who is the intended user?
2. Which patient or population is included?
3. What input does the software analyze?
4. What output does it produce?
5. Which decision or action does the output influence?
6. In which setting and workflow?
7. Which limitations or exclusions bound the use?

Each phrase creates a specification. If a product claims to prioritize adult chest images for urgent radiologist review, it needs adult data, the named image types, a defined urgent finding, a worklist integration, latency limits, human oversight, and safeguards for images it cannot process. A generic benchmark on curated images does not prove safe prioritization in a live queue.

The workflow can be written as:

claim -> regulatory scope -> risk -> requirements -> verification -> clinical evidence -> labeling -> monitoring

Traceability links each claim to one or more requirements, each requirement to a test, and each residual risk to information or surveillance. If a claim has no evidence row, it is unsupported. If a hazard has no control or evaluation, the design is incomplete.

Intended purpose changes the product category#

Two applications can use the same algorithm and fall into different regulatory positions because their intended purposes differ. Software that displays general educational information does not make the same claim as software that diagnoses a condition, directs treatment, or prioritizes urgent care.

Wording is not a loophole. Regulators can consider labeling, interface, instructions, promotion, and actual functionality when evaluating intended use. Calling a diagnostic output “wellness insight” while designing it to trigger clinical action does not remove the underlying function or risk.

The claim also defines the comparator. A model claimed to identify disease must be evaluated against a valid reference standard, and a tool claimed to improve triage should be evaluated in the workflow, against current triage, using outcomes relevant to delays and false prioritization. Clinical utility requires a different study from analytical accuracy.

Turn risk management into product behavior#

Risk management should change what the product does. Begin with foreseeable sequences that could cause harm:

• missing or corrupted input produces a confident output;
• a user mistakes decision support for a final diagnosis;
• performance falls in a subgroup underrepresented in validation;
• an alert is delayed or hidden by workflow integration;
• an update changes a threshold without adequate validation;
• cybersecurity compromise changes data or availability.

Then apply a control hierarchy. Design out a hazardous function where you can, add protective controls such as input validation, abstention, redundancy, access limits, or a human confirmation requirement, and communicate whatever residual risk remains through clear labeling and training. A warning is weaker than preventing the hazardous state.

Controls become design inputs with acceptance criteria. “The system should be robust” is not testable. “The system rejects images below defined quality thresholds and records the reason” can be verified. The risk file, software requirements, and interface specification should describe the same product. So should usability work, the cybersecurity plan, and clinical evaluation.

FDA and EU MDR ask related questions through different systems#

In the United States, device status and classification depend on intended use and technological characteristics. They depend on risk and applicable statutes and regulations. A sponsor may pursue a 510(k), De Novo, or premarket approval pathway depending on classification and predicate context; some software functions are excluded from the device definition or fall within enforcement policies, but those distinctions require precise analysis.

FDA's Quality Management System Regulation became effective February 2, 2026 and incorporates ISO 13485:2016 by reference with FDA-specific provisions. It applies to finished device manufacturers within scope. The transition makes quality-system planning a current operational requirement, not a future harmonization proposal.

EU MDR classifies devices through its rules, including Rule 11 for software, and many software functions that inform diagnostic or therapeutic decisions fall into class IIa or higher depending on the possible consequence of a wrong decision. Conformity assessment commonly involves a notified body. Manufacturers must address general safety and performance requirements, risk management, and technical documentation. They must address clinical evaluation and postmarket surveillance.

The EU “intended purpose” and US “intended use” concepts overlap but are not interchangeable legal terms. A US clearance does not create an EU CE mark, and an EU conformity assessment does not create FDA marketing authorization. Evidence may be reusable when claims and product versions align, but submission structures and legal findings differ.

Designing for both does not mean applying whichever rule seems stricter. It means building a jurisdiction matrix: scope, classification, and essential or general requirements. The matrix covers standards, evidence, and labeling. It covers registration, surveillance, and change obligations for every market you intend to enter.

Match evidence to claim and consequence#

IMDRF's clinical-evaluation framework for Software as a Medical Device separates three linked questions:

• Is there a valid clinical association between the software output and the clinical condition?
• Does the software process inputs correctly and produce accurate, reliable outputs?
• Does it achieve clinically meaningful performance in the target population and context?

The exact terminology and evidence depend on the product, but the chain is useful. A literature review can support an established association. Verification and validation can show correct implementation. A retrospective dataset may estimate technical performance. A prospective workflow study may be needed when user response, timing, or clinical impact is part of the claim.

Evidence should be proportionate, not minimal. A low-risk function with a narrow descriptive claim should not need the same program as autonomous treatment selection, and a high-consequence decision tool cannot rely on an accuracy metric detached from workflow and patient outcomes.

Build an evidence table with claim, endpoint, and comparator. Include population, setting, and sample size rationale. Include acceptance criterion, analysis, and residual uncertainty. Include unfavorable and failed tests. EU MDR explicitly calls for a clinical evaluation that is thorough and objective and includes both favorable and unfavorable data.

Use early regulator interaction to reduce uncertainty#

When a classification, predicate, endpoint, study population, or change plan is uncertain, early interaction can test the proposed approach. FDA's 2025 Q-Submission guidance describes mechanisms for feedback on future device submissions; a focused request gives the agency your product context, your prior evidence, a specific proposal, and questions that can actually be answered.

The meeting is not a substitute for internal decision-making. “Does FDA agree with our strategy?” is less useful than a bounded question about a comparator, endpoint, or validation set with alternatives and rationale. Agency feedback is based on the information available and does not guarantee a later authorization. Record questions, written feedback, and meeting discussion. Record decisions, open issues, owners, and due dates. Then update requirements and evidence plans so advice becomes controlled product memory rather than notes in an inbox.

Limits of compliance and the trust gap#

A product can satisfy formal requirements and still fail users. Trust depends on whether performance is relevant to their setting, limitations are understandable, and data are handled responsibly. It depends on whether failures are recoverable and someone is accountable when the system is wrong.

Design questions beyond the submission checklist include:

• Can users tell what the output means and does not mean?
• Does the interface show uncertainty without inviting automation bias?
• Can the system abstain safely?
• Are subgroup limitations visible and monitored?
• Does use add workload, delay, or inequitable access?
• Can a user contest or override an output, and is that feedback reviewed?
• Is there a safe manual pathway during downtime?
• Are privacy and security controls proportionate to clinical consequence?

These are not decorative ethics statements. They create requirements, hazards, usability tasks, monitoring metrics, and governance roles.

A regulatory-first product brief#

Before major development, produce a concise controlled brief containing:

1. intended purpose and explicit exclusions;
2. user, patient, setting, input, output, and decision;
3. US and EU scope and classification hypotheses;
4. claim-to-requirement traceability;
5. preliminary hazard analysis and safe fallback;
6. analytical and clinical evidence plan;
7. human-factors, security, privacy, and equity questions;
8. product-version and change-control strategy;
9. postmarket metrics and action thresholds;
10. unresolved questions for qualified advisers or regulators.

This brief does not freeze innovation. It makes change visible. A broader population, new output, autonomous action, or altered model may expand the claim and require new evidence, and controlled change is faster to defend because you know which assumptions moved.