Most SaMD teams are running two separate worlds. Engineers build in Jira, GitHub, and CI/CD pipelines. Compliance documentation lives somewhere else, assembled manually, usually by QA cleaning up what development left behind. The two worlds rarely touch until a submission or audit forces a reckoning.
That reckoning is expensive. And it is largely avoidable.
IEC 62304, the international standard for medical device software lifecycle processes, does not require a parallel documentation universe. What it requires is traceability: a clear, maintained connection from user needs through software requirements, risk controls, and test evidence. The standard says nothing about how that traceability must be stored. Most SaMD teams have been solving the wrong problem.
The standard defines lifecycle processes for software development, maintenance, risk management, configuration management, and problem resolution. Its scope is narrower than many assume.
IEC 62304 applies to medical device software, covering both software as a medical device (SaMD) and software embedded in a hardware device (SiMD). Compliance requirements scale with software safety class:
BONUS RESOURCE: Download the free 3-in-1 SaMD Gap Assessment Tool
The common mistake is treating Class C requirements as universal defaults. Teams building Class A or B software end up building documentation structures that match Class C, not because the standard requires it, but because they modeled their IEC 62304 compliance approach on the most stringent case. The result is documentation overhead that adds no regulatory value and slows engineers down for no reason.
Correctly classifying your software, and building your DHF to match that classification, is the first step toward a documentation approach that is both compliant and sustainable.
IEC 62304 does not define the design history file (DHF). That comes from FDA 21 CFR 820 (now QMSR) and ISO 13485. But the two concepts are deeply connected for SaMD teams: the DHF is where you demonstrate IEC 62304 compliance in practice.
For hardware-centric teams, a DHF is often a structured folder of documents: requirements specs, design reviews, test reports, verification and validation records. That model works reasonably well for hardware, where design changes are infrequent and documentation is naturally episodic.
For software teams, that model breaks down fast. Software changes continuously, requirements evolve, and risk relationships shift with them. If the DHF is a static document collection assembled at project milestones, it will always be out of date, and the gaps will surface at the worst possible time, usually during a 510(k) review or a notified body audit.
The real problem is not that software teams fail to document. Most document extensively, in Jira, in GitHub commits, in test run reports, in code review threads. The problem is that none of that documentation is connected to the compliance structure the DHF requires. Traceability from user needs to software requirements to risk controls to test evidence does not emerge automatically from development tooling. Someone has to create it. And in most teams, that someone is QA, after the fact, working from engineering artifacts that were never designed to support regulatory traceability.
That is the doc sprint before submission that most SaMD teams know well. It is not a planning failure. It is a structural problem.
The alternative is a software DHF that is a living structure rather than a point-in-time document: requirements that are maintained as software evolves, risk controls that are linked to specific design decisions, test evidence that maps directly back to those controls, and design reviews that happen in the workflow rather than as separate milestones.
Getting there requires rethinking where compliance documentation lives. Three principles matter:
If your engineers are managing requirements in Jira and your QA team is maintaining a separate requirements document in the QMS, you have two sources that will diverge. Every requirement update now has to happen twice. Every test result has to be reconciled between systems. The overhead compounds with every sprint. A software DHF built on a single source of truth means that when an engineer closes a Jira ticket linked to a software requirement, the compliance record reflects it.
When requirements, risk controls, and test cases are connected inside a single system, traceability is maintained continuously. No manual mapping spreadsheets. No pre-submission reconciliation. The traceability matrix is built as the team works, not assembled after the fact.
IEC 62304 requires that you identify, document, and test software items (units, integrations, and the full system) according to your architecture. That architecture should determine how you structure your DHF, not the other way around. A modular codebase should have a modular documentation structure. Teams that force their software architecture into a generic template end up with documentation that describes a system that does not actually exist.
Class C requirements, applied to Class A or B software, are the most common source of unnecessary DHF weight, but over-engineering shows up in other places too. Teams often create documentation layers that no regulation requires: separate software development plans that mirror QMS procedures, architecture documents that duplicate what is already in code, formal design reviews held as standalone events rather than integrated into sprint cycles. Each layer adds time without adding traceability.
Common audit findings for software DHFs are not usually about missing documentation. They are about missing connections: requirements that exist in the QMS but are not linked to test evidence, risk controls that reference a software item but cannot be traced to a specific design decision, verification records that cover functions but leave gaps in the requirements mapping.
The question to ask when evaluating your DHF structure is not "do we have a document for this?" but "can we trace this requirement from its origin to its test evidence without leaving the system?" If the answer requires copying data between tools, the structure has a gap.
Traditional document-management QMS tools were not designed for software development workflows. They store documents and manage approvals, but they do not connect to the tooling where software actually gets built. That means the integration between development work and compliance documentation has to happen manually, and manual integration does not scale.
Software teams that have moved from document-centric QMS approaches to platforms built for SaMD development consistently report the same outcome: documentation that used to require a dedicated sprint before submission now builds continuously as a byproduct of development. The DHF is current because it is connected to the systems that engineers are already maintaining.
For SaMD and SiMD teams, Ultralight provides native integrations to Jira and GitHub, automated traceability across design controls and risk management, and an IEC 62304-aligned structure built for software development workflows. The goal is IEC 62304 compliance as a property of the development process, not a separate workstream added on top of it.
IEC 62304 defines the lifecycle processes your software development must follow. It does not define how your design history file is structured or where it lives. The DHF requirement comes from QMSR and ISO 13485. Most software DHFs fail audits not because documentation is missing but because traceability connections are missing: the line from a user need to a software requirement to a risk control to a test result cannot be followed without manual reconstruction. The solution is not more documentation. It is documentation that is generated as a byproduct of the development process rather than assembled separately after it.
Watch the on-demand recording: IEC 62304 and the software DHF