A medical-device team can arrive at an FDA interaction with extensive documentation and still leave its central engineering uncertainty unresolved. The problem is often not document volume. It is a question that asks for a broad judgment without defining the device, proposed approach or decision the answer must inform.
Pre-Submission planning should turn uncertainty into a focused technical discussion. Instead of asking whether a development plan is acceptable, explain the intended use, identify a consequential evidence question and present a reasoned proposal. This article addresses that engineering preparation, not submission administration or a complete regulatory strategy.
FDA describes mechanisms for written feedback and meetings in its Q-Submission Program guidance. The planning practices below help a multidisciplinary team prepare useful technical content; they are not a substitute for reviewing the applicable guidance.
1. Identify the decision that cannot safely remain open
Begin with the investment or architecture decision that depends on regulatory feedback. A team might need to decide whether to commission a particular test fixture, preserve a hardware option or develop additional evidence for a proposed performance claim.
Write the decision separately from the question. For example: the team needs to select a bench-test architecture before committing to tooling. The related question concerns whether the proposed test conditions adequately address a specified performance concern. Keeping those statements separate prevents a schedule problem from becoming an ambiguous request for FDA to design the test program.
Not every uncertainty belongs in a Pre-Submission. Resolve component selection, routine debugging and internal requirement conflicts through engineering work. Prioritize questions where an unresolved evidence assumption could materially change the development path.
2. Establish a stable device and claim boundary
A test proposal has little meaning without a defined device. Describe the intended users, use environment and function relevant to the question. State what the device measures, controls or delivers, and explain how that output informs an action.
FDA's guide to studying and marketing a device explains that classification and applicable controls shape the pathway, and that necessary testing depends on factors including technological characteristics and labeling. A team should therefore avoid presenting a performance method independently of the claim it supports.
Consider a hypothetical powered instrument with a force-limiting function. A proposal to characterize sensor accuracy alone does not establish the behavior of the complete force limit. The relevant boundary may include sensing, filtering, control latency, actuator response and mechanical compliance. Describe that boundary before asking about evidence.
Connect this definition to the broader medical-device development lifecycle, but keep the Pre-Submission discussion focused on the unresolved decision rather than repeating the entire program plan.
3. Present a proposal rather than an empty question
A useful engineering question contains enough reasoning for another technical team to evaluate it. Assemble a compact question package with the following elements:
- Decision: What development choice depends on the response?
- Concern: Which failure, performance limitation or uncertainty is being addressed?
- Proposal: What evidence does the team intend to generate?
- Rationale: Why should the proposed method represent the intended conditions?
- Requested feedback: Which specific aspect needs discussion?
For the hypothetical force limit, describe a proposed test using defined contact stiffness, commanded motion and initial load conditions. Explain why those conditions challenge the response. Then ask a bounded question about the proposed approach to characterizing peak force and response time, rather than asking whether the device is safe.
Do not describe a future result as established. Distinguish completed measurements from proposed methods and engineering assumptions. If feasibility work is still underway, state what remains unknown.
4. Show why the test configuration is representative
A prototype can be suitable for one question and unsuitable for another. A development board may support algorithm feasibility while failing to represent final acquisition timing, power behavior or signal integrity.
Define the configuration needed for the proposed evidence. Include relevant hardware revisions, firmware behavior, accessories and mechanical interfaces. Explain differences from the planned product and their likely influence on the measured outcome.
For a closed-loop actuator, ask whether the test includes the intended transmission, sensor mounting and control-update timing. A rigid fixture may suppress a compliance-related failure that would appear in the actual mechanism. Conversely, an uncontrolled fixture resonance can create an apparent product problem that belongs to the test system.
List unresolved configuration choices explicitly. If a later change could alter the meaning of the proposed test, identify the assumption now rather than treating representativeness as a label attached to a prototype.
5. Make measurements and acceptance logic inspectable
Explain what will be measured and how the measurement supports the claim. A proposed maximum response time needs defined start and end events. A force-accuracy method needs a reference measurement, loading conditions and an uncertainty assessment.
Include instrument range, acquisition timing and any filtering that can materially change the result. If peak behavior matters, averaged data may hide the event of interest. If channels are sampled asynchronously, an apparent delay may include measurement misalignment.
Separate the proposed acceptance limit from the observed result and from measurement uncertainty. Explain the technical basis for the limit without inventing a universal threshold. Where the basis is unresolved, make that uncertainty part of the discussion.
Also explain how variability will be addressed. Unit selection, component tolerances and repeated-use conditions may affect the conclusion. Do not choose a sample count simply because it is convenient, or imply that FDA endorses a count without a relevant basis.
6. Include failure behavior and interface assumptions
Nominal performance may not answer the most consequential question. Identify credible conditions that could invalidate the proposed evidence: a disconnected sensor, stale feedback, power interruption or an accessory installed incorrectly.
Use the device risk analysis to determine which conditions deserve attention. For each relevant condition, distinguish detection from response. A controller may detect a fault correctly yet react too slowly to prevent an unacceptable mechanical event.
Interface assumptions need equal scrutiny. If another subsystem supplies a validity flag, explain what it means and how long it can remain asserted without updated data. If user action is required after an alarm, bench testing alone may not address whether that action is understood and achievable.
Keep the proposed feedback question bounded. The objective is to discuss the evidence strategy for identified concerns, not to ask FDA to discover every possible failure in an unfinished architecture.
7. Connect the response to controlled development records
Plan how feedback will affect requirements, test protocols and configuration decisions before the interaction occurs. Assign ownership for interpreting each response and recording the resulting action. Separate direct feedback from the team's interpretation and from decisions still requiring investigation.
FDA's QMSR overview explains the current quality-system framework and its incorporation of ISO 13485:2016. Within the applicable quality system, the engineering task is to preserve the relationship between the question asked, the device described and the evidence eventually generated.
Do not treat feedback on a proposed approach as clearance or approval. If intended use, architecture or test conditions change materially, assess whether the original discussion still applies. A response about one configuration should not silently become the rationale for a different product.
8. Review the package from the recipient's perspective
Before submission, ask an engineer outside the immediate workstream to read each question. Can that person identify the proposed method, understand the key assumptions and explain what the team will do differently depending on the response?
Remove background that does not help answer the question. Add missing diagrams or interface definitions where the reasoning depends on them. Check that terminology is consistent across the device description and proposed protocols.
When outside support is needed, define the work package around these deliverables rather than a vague request to prepare a submission. Outer Reef's guide to selecting a medical-device engineering consulting firm explains how to evaluate technical fit and responsibility boundaries.
The useful output is a decision-ready evidence proposal: a defined device, an explicit uncertainty and a test approach whose limitations are visible. That preparation makes the interaction more focused while giving the development team a clearer basis for its next engineering decision.
