---
title: "Technical Documentation and DHF Software for Medical Devices | Qualio"
canonical: "https://www.qualio.com/compliance-platform/product-frameworks"
updatedDate: "2026-10-28T20:23:48.000Z"
description: "Build the 510(k), the EU MDR technical documentation and each market registration from approved documents, one file per product version, with a read-only snapshot in eSTAR or Annex II order on the day you submit."
---

# Technical Documentation and DHF Software for Medical Devices | Qualio

Build the 510(k), the EU MDR technical documentation and each market registration from approved documents, one file per product version, with a read-only snapshot in eSTAR or Annex II order on the day you submit.

## Your technical file is your release

Build the 510(k), the EU MDR technical documentation and each market registration from the documents your approvers signed. One file per product version, frozen the day you submit.

## Your technical documentation compiles from approved documents

Apply the 510(k) framework, the EU MDR framework or one of your own to a product version. Each section lists the document that answers it, at the version your approvers signed.

## What you submitted stays on file while the product moves on

Take a snapshot when you submit: an index PDF and one PDF per document as it stood, read-only, downloadable as one zip. Months later, when the reviewer’s question arrives and the design has moved on, you answer from the snapshot they were sent.

## Version 2.0 starts from the 1.0 baseline

Create 2.0 with 1.0 as its baseline. The documents that run for the product’s life carry across, and the file marks what is new or changed against the baseline. A verification report written for 1.0 stays on 1.0 and its snapshots.

## Submit in multiple markets from the same documents

The 510(k) and EU MDR frameworks share controls, so a document placed once sits under both. Apply each framework to the version you submit in that market, and the same risk management file, verification reports and labelling come out in the eSTAR’s order for one and Annex II’s for the other.

## Platform connections

### Design controls

The package an approved design review generates, trace matrix and risk file included, is placed in the product version as a document, so it sits in the file at the version the approvers signed. See [Design controls](/compliance-platform/design-controls).

### Compliance Frameworks

The 510(k) and EU MDR frameworks come from the same library as ISO 13485 and the FDA QMSR, so the file the reviewer reads and the system the auditor inspects are built the same way. See [Compliance Frameworks](/compliance-platform/frameworks).

### Document control

Every document in the file is a controlled document with its own review, approval and audit trail. See [Document control](/compliance-platform/document-control).

## Frequently Asked Questions

### What is a technical file, and is it the same as a DHF?

The technical file is the set of documents showing a device meets its requirements: design, risk management file, verification and validation, labelling and post-market surveillance. EU MDR Annex II and III set its contents. The FDA’s design history file was the design part of it. The QMSR now points to ISO 13485, which calls it the medical device file.

### Is the export in eSTAR order or Annex II order?

It follows the framework you applied. Under the 510(k) framework the file is laid out in the eSTAR’s sections. Under the EU MDR framework it follows Annex II and Annex III. The download is one zip, index PDF first, or file by file. You still complete the FDA’s eSTAR form itself.

### What does the notified body get, and can it change afterwards?

A snapshot: the file of one product version at the moment you took it, an index PDF listing every section and the document under it, plus one PDF of each document as it stood. It is read-only once generated. The documents inside carry their own approvals. When the file moves on, you take another.

### What happens to the file when we release 2.0?

You create 2.0 with 1.0 as its baseline. Documents that run for the product’s life copy across, and the new file marks what changed against the baseline. Documents written for 1.0 stay on 1.0 and its snapshots, so what was valid for 1.0 is still there when the notified body or the FDA asks for it.

### Do we need one framework per market?

No. The 510(k) and EU MDR frameworks share controls, so a document placed under a shared control appears in both. For a market with no framework in the library, build one in the framework builder from the regulator’s requirements and apply it to the version you register there. Not applicable is allowed on any section.

## What are you submitting, and where?

Bring the submission date and your current file. We will build the product version, place the documents under the 510(k) or Annex II sections, take the snapshot and download it.

Part of Regulated Product Lifecycle. [See everything it does.](/compliance-platform/product-lifecycle)