Free scoping read. A written assessment of your manuscript in two business days, at no cost.

Start one

Home›Services›Medical device & IVD›Technical file and 510(k)

Medical Device Submissions and Technical Documentation

510(k) Submissions and Technical Documentation for Device Manufacturers

Pubrica writes 510(k) submission content and EU MDR technical documentation for medical device manufacturers. A 510(k) argues that your device is as safe and effective as a legally marketed predicate, and refuse-to-accept decisions and additional information requests often arise when that comparison is asserted rather than demonstrated. Our device regulatory writers prepare the substantial equivalence argument, the GSPR checklist, the IEC 62304 software documentation and the ISO 14971 risk documentation, and assemble them into eSTAR or the technical file structure.

  • Substantial equivalence argued against a named predicate, with every technological difference identified and its impact on safety and effectiveness addressed
  • Written directly into eSTAR, the mandatory 510(k) format, rather than drafted separately and transferred afterwards
  • GSPR checklist completed with specific evidence references that a Notified Body can follow to the supporting document
  • IEC 62304 software documentation to the correct safety class: class A, B or C determines how much documentation is required, and misclassification is costly in either direction
  • ISO 14971 risk file reconciled with the clinical evaluation, because any disagreement between the two is a finding
Scope of Technical Documentation Writing What is included and what is excluded

510(k) submission contentIncluded

Substantial equivalence argumentIncluded

GSPR checklist and technical fileIncluded

IEC 62304 and ISO 14971 documentationIncluded

Testing and verification activitiesYour lab or test house

Predicate → compared → evidenced → assembled → submission

Included in every submission
  • Predicate named and justified
  • Differences addressed in full
  • Evidence references that can be traced
  • Software safety class justified
  • Risk file reconciled with clinical evaluation
Quoted per submissionBased on device class, software content and testing volume
FY2026 510(k) user fee$26,067 standard · $6,517 small business
eSTAR, EU MDR, IEC 62304, ISO 14971ISO 14155:2026 where clinical data applies
ISO 9001:2015Quality management certified · cert. H3CR9TCU20251212INDQM10N

Deliverables

Four Core Elements of Every 510(k) and Technical File Submission

Each submission covers one device, one intended use and one predicate, and the predicate defines what substantial equivalence can be claimed.

A Predicate Selected and Justified The predicate shapes the whole submission. Choosing one with a different intended use, or one that has been recalled, is costly to discover late in the project.

Example from a predicate assessmentWe compare intended use first, then technological characteristics, then the recall and enforcement history of the predicate. A predicate with a Class I recall against the feature you are matching is not suitable.

Technological Differences Addressed in Full We identify every technological difference between your device and the predicate, argue whether each raises different questions of safety or effectiveness, and name the supporting evidence.

Example from a comparison sectionThe subject device is substantially equivalent to the predicate.Seven technological differences identified. Five do not raise new questions of safety or effectiveness, argued individually. Two do, and are supported by bench testing reported in section 15 and biocompatibility in section 16.

A GSPR Checklist With Traceable References We address each general safety and performance requirement with a method of conformity and a specific document reference, rather than citing a standard and a document name.

Example from a GSPR checklistGSPR 14.2: Conforms. See risk management file.GSPR 14.2: Conforms. Method: design verification per DV-2026-014 section 4.3; residual risk assessed in RMF-0091 section 7.2. A reviewer can open both and find the statement.

Software Documented to Its Safety Class IEC 62304 class A, B or C determines how much documentation is required. We justify the class explicitly, because over-classifying is costly and under-classifying is a finding.

Example from a software fileThe class depends on the harm the software could contribute to after external risk control measures are taken into account, which is where most classification disagreements arise.

The samples shown are illustrative and anonymised. Hover over a sample to replay it.

Compliance and Standards

Regulatory Standards for 510(k) Submissions and Technical Files

Where your Notified Body or your FDA pre-submission has given a position, we follow it.

510(k)eSTAR

Premarket notification (21 CFR 807 Subpart E)

Substantial equivalence to a legally marketed predicate, submitted in the mandatory eSTAR format. FY2026 user fee $26,067 standard, $6,517 small business.

MDR2017/745

Technical documentation (Annexes II and III)

The technical documentation and post-market surveillance documentation a device must hold, structured around the GSPR checklist in Annex I.

IEC62304

Medical device software lifecycle (safety classes A, B, C)

The software development and maintenance documentation required, scaled to the safety class assigned to the software.

ISO14971

Risk management for medical devices (with ISO/TR 24971)

The risk management file that the whole submission must reconcile with, including the clinical evaluation, which must address the same residual risks.

Responsible Use of AI

Responsible Use of AI in Regulatory Writing

Regulatory reviewers trace each decision back to its evidence and to a named individual. For this reason, source traceability takes priority over speed in our regulatory writing, and every statement must be traceable to its source.

How We Use AI ToolsWe use AI tools to locate source material across a document set, to check the consistency of terms, figures and cross-references between documents in a submission, and to draft highly templated sections that a writer then verifies line by line against the source.
Where We Do Not Use AIWe do not use AI tools for text that enters a submission as drafted, for clinical or benefit-risk interpretation, safety narratives or literature appraisal for a clinical evaluation, or for any statement an assessor would expect to trace to a named, qualified individual.
What Your AI Declaration Should IncludeYour declaration should name the tool, the stage at which it was used and the human oversight applied. Journals, funders, regulators and the ICMJE January 2026 update now expect this, and an undeclared tool found later is treated as an integrity matter.

Why We Do Not Publish an AI Accuracy Figure

Accuracy figures for AI tools are usually reported by the companies that sell them.

Pubrica therefore does not quote a self-generated accuracy figure, because it would carry the same conflict of interest. Instead, we tell you which tool was used on your project, at which stage, and what a specialist changed afterwards.

Methodology

How Our 510(k) and Technical File Writing Process Works

For a 510(k), we select the predicate first. For the EU, we confirm the classification first, because both decisions shape the rest of the submission.

Step one

Regulatory Route, Predicate Selection or Classification

For the US, we identify and assess the predicate, including its regulatory history. For the EU, we classify the device under the MDR rules, which for software usually means Rule 11 and Notified Body involvement.

Step two

Gap Assessment Against the Regulatory Route

We compare the evidence the chosen route requires, such as bench testing, biocompatibility, software documentation and clinical data, against what exists, and identify gaps before drafting.

Step three

Drafting and Assembly

We write the equivalence argument or GSPR conformity, the software file to its class, the risk documentation and the supporting sections directly into eSTAR or the technical file structure.

Step four

Reconciliation and Submission Support

We verify that cross-references resolve, reconcile the risk file with the clinical evaluation and prepare the submission for your filing.

Our Experts

Your 510(k) and Technical Documentation Team

A named team of regulatory specialists stays with your project from scoping to delivery. Your project coordinator introduces each team member by name before work begins.

Regulatory medical writerAuthors the document to the applicable template and guidance

Writes the document against the governing template and regulatory guidance, keeps every statement traceable to its source data, and maintains the version history and comment log through each review round.

Responsible forDrafting and source traceability
Reviews againstICH, EU MDR/IVDR or FDA guidance, as applicable
OutputSubmission-ready document
Subject matter expertClinical or scientific expert matched to your product area

Reviews the clinical and scientific content for accuracy and confirms that each conclusion is supported by the data. Each expert is matched to your therapeutic or device area.

Responsible forScientific accuracy and interpretation
Reviews againstSource data and the current literature
FieldMatched to your product
BiostatisticianStatistical review where the document reports analysed data

Checks that statistical methods, tables and conclusions are consistent with the analysis plan, and reviews how the data are presented before the document reaches regulatory review.

Responsible forStatistical accuracy
Reviews againstICH E9 and the statistical analysis plan
ToolsR, SAS, Stata
Regulatory QC reviewerIndependent quality check before delivery

Performs an independent check of the final document against source data, the template and the applicable regulatory checklist. Findings are logged and resolved before delivery.

Responsible forIndependent quality control
Reviews againstSource data and regulatory checklists
Signed off byProject lead

Packages

510(k) and Technical File Service Packages

Pricing depends on device class, the amount of software involved, the volume of testing evidence and whether a predicate has already been identified.

510(k)

510(k) submission

For US market entry through premarket notification

Quoted per projectBased on device class, software content and evidence volume

Delivery By scope

  • ✓Predicate assessment including regulatory history
  • ✓Substantial equivalence argument for each difference
  • ✓Written directly into eSTAR
  • ✓Software documentation to IEC 62304 class
  • ✓Risk documentation reconciled with the clinical evaluation
  • ✓Additional information response support

The FY2026 user fee is $26,067 standard and $6,517 for small business, paid to FDA separately from any writing.

Deliverables Request a quote
Technical file

EU technical documentation

For CE marking under MDR

Quoted per projectBased on class, GSPR count and evidence volume

Delivery By scope

  • ✓Classification and route assessment
  • ✓GSPR checklist with traceable references
  • ✓Technical documentation to Annexes II and III
  • ✓Software file to IEC 62304 class
  • ✓Risk management file to ISO 14971
  • ✓Reconciled with the clinical evaluation report

Where clinical evaluation is also in scope, we quote both together, because they share an evidence base and must be consistent.

Deliverables Request a quote

Send the device description and your candidate predicate, and we will assess it at no cost, covering the intended use match, technological differences and the predicate’s recall history. An unsuitable predicate is a costly error in a 510(k) submission.

FAQs

510(k) and Technical File FAQs

If your question is not answered here, ask an expert. No quote is required.

The FDA user fee for FY2026 is $26,067 standard and $6,517 for a qualifying small business, paid to FDA. This is separate from the cost of preparing the submission.

Preparation cost depends mainly on how much testing and software documentation is needed. Where the evidence exists and the predicate is suitable, assembly is the smaller part of the work.

On intended use first, technological characteristics second and the predicate’s own regulatory history third, which is the step most often omitted.

A predicate with a Class I recall against the feature you are matching cannot be used, and discovering this after the submission has been drafted is the most costly error in the process.

It determines how much documentation is required. Class A needs the least and Class C the most, and the class depends on the harm the software could contribute to after external risk controls are taken into account.

Misclassification is costly in both directions: over-classifying creates documentation you did not need, and under-classifying is a finding. The class should be justified explicitly.

No. Bench testing, biocompatibility, electrical safety and validation sit with your laboratory or a test house. We write the documentation and assemble the submission.

Where the gap assessment shows that testing is missing, we state what is needed and why the route requires it, which is usually enough to scope the work with a test house.

Related Services

Related Regulatory Writing Services

The technical file must be consistent with the clinical evidence and the risk file.

Request a Free Predicate Assessment for Your Device

We will assess the predicate at no cost, covering the intended use match, technological differences and the predicate’s recall history. An unsuitable predicate is the most costly error in a 510(k).

Get a free quote

Regulations

Check your project against this rule

  1. 1Your work
  2. 2Your details
  3. 3Send
What do you need?

Material you send is held under signed confidentiality, with access limited to the assigned team and encrypted transfer. It is not used to train anything and is not passed to third-party tools. Ask for the agreement before you send anything you would rather cover first.