FDA eSTAR 7.0 for 510(k) and De Novo: QA Guide

FDA eSTAR 7.0 is the current non-In Vitro Diagnostic (nIVD) and In Vitro Diagnostic (IVD) electronic Submission Template and Resource, while PreSTAR 3.0 is the current template for early submission requests. FDA says the nIVD and IVD templates incorporate its Human Factors Content Guidance published on May 29, 2026, and effective on August 1, 2026 (^[1]). Use of eSTAR is mandatory, absent an exemption, for medical-device 510(k) and De Novo submissions to the Center for Devices and Radiological Health (CDRH) or Center for Biologics Evaluation and Research (CBER), while PreSTAR use for Q-Submissions, Investigational Device Exemptions, and section 513(g) requests is voluntary (^[2]).

Before filing, assess whether a major-version change affects the device. After acknowledgment, the submission is grandfathered to its original eSTAR version (^[3]). An Additional Information (AI) or Technical Screening (TS) response should update that original file, keep unaffected content unchanged, and avoid migration to a newer template.

eSTAR is a dynamic PDF whose branching logic exposes requests according to prior answers and supports only sequential editing. Technical screening checks that each applicable attachment question has at least one relevant attachment (^[4]). Release readiness requires both mechanical completeness and independent evidence-relevance review; neither alone is an adequate control. A complete operating model therefore uses a single editor, controlled handoffs, a prompt-to-evidence map, independent branch review, and a frozen final file whose integrity is recorded.

The Portal caps a submission at 4 GB and an attachment embedded in a PDF at 1 GB (^[5]). A TS deficiency may put a submission on hold for up to 180 days, after which an uncorrected file is treated as withdrawn (^[6]). FDA's preliminary FY2026 data through June 30, 2026 reported first-cycle not-accepted or failed-TS rates of 8.67% for 510(k)s and 6.52% for De Novo requests (^[7]); these are portfolio measures, not a sponsor benchmark.

eSTAR is not simply a cover form placed ahead of a conventional dossier. FDA describes it as questions, text, logic, and prompts that guide construction of a complete submission (^[8]). It combines form data with attachment evidence, and its content follows the review structure. This architecture makes answers, branching, and attachment placement part of submission quality, rather than clerical packaging.

The legal foundation is broader than the template. Section 745A(b) requires covered device presubmissions, submissions, and supplements to include an electronic copy after implementing final guidance (^[9]). It also authorizes waiver and exemption criteria (^[10]). The FDA Reauthorization Act of 2017 authorized specified device submissions to be required solely in an electronic format (^[11]). FDA implemented the 510(k) eSTAR requirement after October 1, 2023, and the De Novo requirement after October 1, 2025, unless exempted (^[12]) (^[13]).

For an adjacent adviser such as IntuitionLabs, the appropriate contribution is process design, evidence governance, and controlled technology integration, not a claim to supply or replace FDA's template. Its stated operating model connects governed information to authoritative sources with permissions, citations, evaluation, and accountable operation (^[14]). That perspective is relevant to evidence mapping and QA, while FDA materials remain controlling.

Current templates and pathway coverage

As of September 19, 2026, FDA lists nIVD eSTAR 7.0, IVD eSTAR 7.0, and PreSTAR 3.0 on the same program page (^[15]). The decisive distinction is submission purpose, not a team's preferred form.

Table 1 summarizes the current routing decision.

Submission purpose	Template and status	Operating implication
510(k), nIVD or IVD	eSTAR 7.0, mandatory unless exempted	Select nIVD or IVD before evidence mapping. The statute requires a report at least 90 days before commercial distribution ([16]).
De Novo, nIVD or IVD	eSTAR 7.0, mandatory unless exempted	The direct route applies when there is no legally marketed device on which to base substantial equivalence ([17]).
Q-Submission, IDE, or 513(g) request	PreSTAR 3.0, voluntary	Use it to structure an early request, but treat it as a separate transaction and controlled artifact ([18]).
Original PMA and specified PMA supplements	eSTAR, voluntary for listed types	Confirm the exact supplement type before adopting the template ([19]).

The table shows why a generic “use eSTAR 7.0” instruction is insufficient. A controlled intake record should capture lead center, device type, pathway, transaction type, IVD status, and exemption status before anyone answers the first branching question.

Human factors content changes

Version 7.0 incorporates FDA's 2026 Human Factors (HF) content framework. The agency says eSTAR walks the sponsor through decision points for selecting an HF Submission Category (^[20]). Teams should therefore review user interfaces, use-related risk analysis, training, labeling, and validation evidence against the new branch structure before reusing a prior dossier index. This is a content and routing change, not merely a renamed attachment slot.

A practical HF delta review should record:

• Category decision: the chosen HF submission category and its rationale.

• Branch answers: each response that makes a downstream HF request appear or disappear.

• Evidence owner: the human factors, risk, clinical, labeling, or engineering owner for each requested artifact.

• Reuse decision: whether legacy evidence answers the current prompt, requires an explanatory bridge, or must be replaced.

• Effective-date check: confirmation that the August 1, 2026 content is applied to the working template.

Major versions, minor versions, and grandfathering

FDA distinguishes major and minor updates. A major update reflects significant revisions, while the agency says a submitter may continue with the previous major version when the changes do not affect the device (^[21]). Its minor-version policy supports risk-based continuity, but not casual version choice.

Use this decision logic:

1. No template started: download the current applicable template and record its version, retrieval date, and checksum.

2. Draft on an older major version: compare release changes with device characteristics and pathway; document whether any change applies.

3. Draft on an older minor version: assess the minor change, then decide whether migration risk exceeds its relevance.

4. Submission acknowledged: freeze the acknowledged version as the response baseline.

5. AI or TS response requested: revise the original template only, with a controlled copy and a defect-to-change log.

This avoids introducing new branches while answering a bounded deficiency and preserves the acknowledged file as the response baseline.

A controlled single-editor workflow

Concurrent co-authoring in the dynamic PDF is not supported. The operating design should separate content development from template assembly. Contributors draft and approve evidence in their source systems; one designated editor inserts approved answers and attachments into the eSTAR. A check-out system should create a visible ownership state, while its history records the handoff reason (^[22]).

Table 2 defines a sequential handoff matrix.

Role	May change eSTAR?	Required handoff evidence	Primary QA question
Submission manager	Yes, as designated editor	Check-out record, version identifier, change log, checksum; the check-in comment can become part of version history ([22])	Is this the only writable master?
Regulatory pathway lead	No, review/comment copy	Approved pathway and branch-answer sheet	Do the answers expose the correct requests?
Evidence owner	No	Approved attachment, title, revision, and prompt mapping aligned with an orderly file structure ([23])	Does the file answer this exact question?
Quality reviewer	No, unless formally reassigned	Defect log and disposition, consistent with revision and change control ([24])	Are all applicable prompts answered and supported?
Signatory	Signature action only	Approval record and final readiness statement	Has attachment editing ended before signature?
Portal submitter	No content edits	Upload package hash, size check, timestamp, receipt; message digests detect changed content ([25])	Does the uploaded file equal the approved file?

SharePoint can preserve a check-in comment as part of version history (^[22]). That record should identify the editor and reason for change, consistent with the broader requirement for revision and change-control procedures in regulated electronic records (^[24]). Box likewise advises locking files before opening them in Box Edit and can retain prior versions (^[26]) (^[27]). These features can support the workflow, but the sponsor must define which repository is authoritative and prevent parallel writable copies.

Branching logic and attachment relevance

Because later content depends on prior answers, one wrong branch can hide a required evidence request. Health Canada's comparable enrolment process documents the same dependency pattern: prior field selections tailor later picklists (^[28]). Its template also surfaces validation errors near the top, showing why both branch state and machine errors belong in the review record (^[29]). Branch QA must therefore test both the answer and the resulting form state.

For each applicable prompt, the evidence map should include:

• Prompt ID: stable internal identifier plus the visible eSTAR section and question text.

• Branch basis: upstream answers that caused the prompt to appear.

• Evidence claim: the proposition the attachment must establish.

• Attachment: exact filename, revision, owner, approval state, and source-system record.

• Locator: page, section, bookmark, table, or figure where the answer is found.

• Relevance rationale: one sentence connecting the evidence to the question.

• Reviewer result: pass, defect, not applicable, or pending, with rationale.

FDA warns that TS can occur when none of a question's attachments is relevant to that question (^[30]). More attachments are not automatically safer. Health Canada's eSTAR pilot similarly recommends combining files with similar content and adding bookmarks or a table of contents to combined documents (^[31]) (^[32]). IMDRF's submission guidance also calls for harmonized folder structures and file formats, reinforcing the value of orderly, navigable evidence (^[23]).

Pathway-specific evidence mapping

A 510(k) and a De Novo may share device-description, performance, software, biocompatibility, cybersecurity, labeling, and HF evidence, but their regulatory arguments differ. The 510(k) regulation requires proposed labels and labeling sufficient to describe the device and intended use, plus supported comparisons with similar devices (^[33]) (^[34]). A De Novo request must identify proposed Class I or II classification and, for Class II, propose special controls addressing identified risks (^[35]) (^[36]).

An evidence map should make these different jobs visible:

• 510(k) regulatory argument: intended use, technological characteristics, predicate comparison, differences, and data supporting substantial equivalence.

• De Novo regulatory argument: risk identification, benefit-risk evidence, classification rationale, and proposed controls.

• PMA argument: reasonable assurance of safety and effectiveness, using the applicable voluntary eSTAR scope.

• IVD overlay: analytical and clinical performance, specimen and method details, and any dual 510(k)/CLIA waiver logic.

• nIVD overlay: device-specific performance and risk evidence, including software and HF branches where applicable.

If required De Novo information is inapplicable, the regulation requires a separate identification and justification of the omission rather than silent absence (^[37]).

Preflight QA and validation-error controls

The goal is not merely to display eSTAR COMPLETE. Completeness is a necessary machine state; substantive relevance remains a human review task. A separate defect record should preserve what the automated form found, what human review found, and how each item was resolved. NARA's electronic-record criteria use the general control principle that access and record-update changes should be tracked in an audit log (^[38]).

A preflight should classify defects into five groups:

• Template defects: wrong pathway, IVD status, major version, minor version, or corrupted dynamic behavior.

• Branch defects: an answer conflicts with device facts or exposes the wrong downstream requests.

• Prompt defects: an applicable response is missing, inconsistent, or written at the wrong level of detail.

• Attachment defects: irrelevant, obsolete, duplicate, inaccessible, misleadingly named, or not approved.

• Package defects: incomplete status, invalid signature sequence, excessive file size, or upload mismatch.

The release checklist should verify that attachments were inserted from the controlled local source, attachment filenames are concise and descriptive, and the final signature follows all attachment changes. The broader integrity objective is to protect authenticity, integrity, and appropriate confidentiality of the electronic record (^[39]). Health Canada's submission guidance similarly says files should not carry additional security settings that interfere with processing (^[40]). These checks belong in the controlled release process, not in tribal knowledge.

Portal submission and controlled responses

For CDRH-led 510(k) and De Novo files, use the CDRH Portal unless oversized-file instructions apply. The sponsor should archive portal evidence and official correspondence, then retain the exact transmitted file with its metadata. NARA's migration principle is useful here: retain source records and metadata until transfer is complete and the destination is reliable (^[41]).

For a TS or AI response:

1. Duplicate the acknowledged master into a controlled response workspace without altering the archived baseline.

2. Log every deficiency with owner, due date, affected prompt, affected attachments, and closure evidence.

3. Modify only affected sections and preserve all unaffected sections and attachments.

4. Re-run full branch QA because one changed answer can alter downstream visibility.

5. Re-run attachment relevance QA for every changed prompt and any newly exposed prompt.

6. Record final checksum and approval, then compare it with the actual upload artifact.

7. Submit before the operational cutoff, preserving confirmation and official correspondence.

The response clock is consequential. Under 21 CFR 860.250, failure to provide a complete De Novo AI response within 180 days causes withdrawal (^[42]). The internal response plan should reserve time for approval and regression testing rather than target the legal ceiling.

Public metrics provide scale and timing context, but they do not establish a sponsor-specific probability of acceptance. FDA's preliminary FY2026 report, current through June 30, 2026, showed an 8.67% first-cycle 510(k) not-accepted or failed-TS rate, compared with 7.20% in FY2025. For De Novo, the preliminary FY2026 figure was 6.52%, compared with 10.61% in FY2025 (^[43]) (^[44]). Cohort maturity and later updates can change preliminary values.

Table 3 separates regulatory clocks, program goals, observed portfolio metrics, and technical constraints.

Measure	Current value or rule	How to use it
De Novo acceptance notification	Within 15 days under 21 CFR 860.230 ([45])	Plan acceptance-notice monitoring; do not confuse acceptance with a substantive decision.
510(k) statutory notice	At least 90 days before commercial distribution ([16])	This statutory filing provision is not a promise of review completion.
De Novo acceptance notice	Within 15 days after receipt ([45])	Monitor the acceptance notice separately from the substantive review outcome.
De Novo electronic format	One electronic version under the final rule ([46])	Preserve the exact released and transmitted artifact.
Portal technical limit	Validate the approved artifact against the current published Portal limits	Measure the final approved file, not an earlier working copy.
TS or De Novo AI response ceiling	180 days under the De Novo response rule ([42])	Set a much earlier internal due date and reserve time for full regression QA.
FDA burden estimate, eSTAR 510(k)	100 responses at 40 hours, 4,000 hours annually in a 2023 information-collection estimate ([47])	A regulatory estimate, not a project budget or productivity benchmark.
FDA burden estimate, De Novo	79 requests at 182 hours, 14,378 hours annually in a December 2024 estimate ([48])	Use only as public context; device complexity drives actual effort.

These values show why a dashboard should measure controllable preparation quality rather than promise approval. The regulatory burden estimates are contextual planning inputs, not acceptance-rate predictions, while the statutory and regulatory clocks define external boundaries (^[48]) (^[42]). A reader-supplied completion dashboard can calculate four rates without importing an unsupported benchmark:

• Applicable-prompt completion: answered applicable prompts divided by total applicable prompts.

• Evidence-link coverage: applicable prompts with mapped evidence divided by applicable prompts requiring evidence.

• Attachment-review coverage: independently reviewed attachments divided by total attachments.

• Defect closure: closed defects divided by total defects raised, accompanied by the count of open critical defects.

For example, if a team identifies 240 applicable prompts, answers 228, maps evidence to 150 of 156 evidence-bearing prompts, reviews 72 of 80 attachments, and closes 45 of 50 defects, the dashboard reports 95% prompt completion, 96.2% evidence coverage, 90% attachment review, and 90% defect closure. This is a hypothetical calculation, not an FDA acceptance predictor. The release rule should remain categorical: no open critical defect, correct template and pathway, eSTAR COMPLETE, final size within limits, and approved upload checksum.

The archive should permit an independent reviewer to reconstruct which file was submitted, why each branch was selected, which evidence was approved, and what changed in a response cycle. Where electronic records fall within 21 CFR Part 11 scope, closed-system controls include revision and change-control procedures that maintain an audit trail (^[24]). The regulation describes controls designed to ensure authenticity, integrity, and appropriate confidentiality (^[39]). Applicability must be assessed by the sponsor; merely placing a file in SharePoint or Box does not decide it. ISO 15489's emphasis on assigned responsibilities and monitoring supports an explicit archive owner and periodic control review (^[49]).

A defensible archive package contains:

• Source record: downloaded blank template, version, retrieval date, and source URL.

• Decision record: pathway, IVD status, major/minor-version assessment, and exemption analysis.

• Branch record: approved answer sheet and rendered branch-review evidence.

• Evidence index: prompt-to-attachment map, locators, owners, approvals, and dispositions.

• Change record: check-out, check-in, editor, timestamp, reason, and before/after version.

• Release record: eSTAR COMPLETE evidence, signature state, file size, defect closure, and approval.

• Integrity record: cryptographic digest for approved, uploaded, and archived copies, using a controlled algorithm because digests detect changed messages (^[25]).

• Transmission record: portal timestamp, confirmation, dashboard capture, and official email.

• Response record: original acknowledged file, deficiency log, bounded modifications, and replacement upload evidence, following the general principle that each regulatory transaction gets a new or revised controlled file (^[50]).

NIST explains that cryptographic message digests detect whether content changed, while digital signatures provide assurance that information was not modified after signing (^[25]) (^[51]). Generate the digest after approval, again from the uploaded artifact if retrievable, and again on archival transfer. NARA likewise calls for record and location changes to be documented in an audit log (^[38]). A checksum is useful evidence of file identity, but it does not prove that the submission is substantively correct.

Retention should follow the sponsor's approved policy and applicable obligations. NIST connects audit-record retention to the organization's retention policy (^[52]). NARA's federal-record guidance offers a useful control principle: source records and metadata should remain until migration is complete and the destination is reliable (^[41]). Box's archive model similarly preserves metadata and file versions (^[53]). These are not FDA retention mandates for sponsors, but they illustrate sound preservation patterns.

ISO 15489 identifies policies, assigned responsibilities, monitoring, and training as elements of records management (^[49]). IMDRF likewise provides harmonized guidance for folder structures and file formats in table-of-contents-based medical-device submissions (^[23]). Together, these sources support a governance system that is specific enough to operate and general enough to survive platform changes. The same principles should govern response packages, because a revised transaction needs a new controlled artifact rather than an overwrite of the historical baseline, a pattern also explicit in Health Canada's requirement for a new or revised file for each regulatory transaction (^[50]).

eSTAR 7.0 shifts submission QA toward state-aware review. Reviewers must examine the visible form, the upstream choices that produced it, and the evidence attached to each question. Health Canada's interdependent-picklist model provides independent confirmation that electronic regulatory forms can change downstream choices based on earlier fields (^[28]). This makes traditional document-level QC necessary but insufficient. Regulatory operations should add branch regression testing, prompt-level traceability, and a single-editor control to their standard operating procedures.

The next implementation priority is a machine-readable evidence inventory outside the PDF. It can store prompt identifiers, claims, owners, attachment revisions, locators, approval states, and defect status without attempting concurrent editing of the eSTAR itself. Human reviewers should approve branch decisions and relevance judgments. Automation can flag missing mappings, duplicate names, stale revisions, size thresholds, or mismatch between approved and upload hashes. Message digests are appropriate for that last comparison because NIST says they detect changed content (^[25]).

International convergence remains useful but incomplete. Health Canada's Regulatory Enrolment Process distinguishes editable working copies from files intended for submission (^[54]). IMDRF provides a harmonized model for submission folder structure and file formats (^[23]). Those parallels support common internal controls, but each authority's current template and transmission rules remain decisive.

From IntuitionLabs' adjacent-adviser perspective, regulated workflow automation should be measured through workflow penetration, time recovered, quality, risk signals, reliability, and support burden before scaling (^[55]). Applied here, that means measuring review coverage and defect closure first, then evaluating whether AI-assisted mapping or document checks reduce cycle time without weakening human accountability.

What are the main FDA eSTAR 7.0 requirements for 510(k) and De Novo?

Yes, for covered medical-device 510(k) and De Novo submissions to CDRH or CBER, unless an exemption applies. The 510(k) requirement dates from October 1, 2023, while the De Novo requirement dates from October 1, 2025 (^[12]) (^[13]). The governing statute also allows criteria for waivers and exemptions (^[10]). Confirm lead center, pathway, IVD status, and any exemption before selecting the file.

Which PDF application should a team use?

FDA recommends Adobe Acrobat Pro and identifies PDF-XChange Editor 10.2.0 or later and Foxit PDF Reader 12.1 or later as supported options (^[56]). Qualify the chosen desktop configuration before production use, and verify that the application can save form changes and attachments.

Can several contributors edit the eSTAR at once?

No. The dynamic PDF does not support concurrent co-authoring. A SharePoint or Box repository can manage sequential access, history, and recovery, but the operating procedure should permit only one designated editor at a time. SharePoint can retain a check-in comment in version history (^[22]), and Box advises locking files before editing (^[26]).

What causes eSTAR technical-screening problems?

High-risk failure modes include an incomplete machine state, an incorrect branch answer, no relevant attachment for an applicable attachment-type question, broken or inaccessible files, and a package that exceeds Portal limits. Teams should separately test mechanical completion and substantive relevance, then retain a defect trail. For regulated electronic records, Part 11 expressly identifies revision and change-control procedures used to maintain an audit trail (^[24]).

How should a team complete FDA eSTAR 7.0 and handle validation errors?

Treat a validation error as a controlled defect: capture the message, identify the responsible prompt or attachment, assign an owner, correct the controlled master, and run regression QA on affected branches. Health Canada's comparable electronic template places validation errors near the top of the form, illustrating the broader pattern of machine-readable form checks (^[29]). The authority-specific instructions still control.

Should an AI or TS response move to the newest eSTAR?

No. Once FDA acknowledges the original, use the grandfathered version, update only affected content, retain unaffected sections and attachments, and document every change. This limits scope while preserving the acknowledged original eSTAR version as the response baseline (^[57]).

The current FDA eSTAR is best governed as an executable submission structure, not a passive PDF. It combines pathway selection, conditional logic, structured answers, unstructured attachments, and transmission constraints. For premarket notification and De Novo work, the most effective control system begins with the correct nIVD or IVD template, records the version decision, serializes editing, and traces every applicable attachment request to approved evidence.

The release threshold should be explicit: correct pathway and version, independently reviewed branches, complete prompt-to-evidence coverage, relevant and accessible attachments, closed critical defects, eSTAR COMPLETE status, valid signature sequence, size compliance, and a checksum matching the uploaded artifact. NIST identifies message digests as a means to detect changed content (^[25]). Portal tracking and correspondence then become part of the permanent submission record.

If FDA issues an AI or TS request, the acknowledged eSTAR remains the baseline. A controlled response changes only what the deficiency requires, preserves unaffected content, repeats branch and attachment QA, and closes well before the regulatory ceiling. This operating discipline turns version control and screening QA into reproducible evidence rather than last-minute inspection.