Medical Device Design Control Software: Why Is Your Design History File Still Rebuilt by Hand Before Every Audit?

Why trace matrix week exists in almost every device company

Three weeks before a notified body audit, a quality engineer opens a spreadsheet called Trace Matrix and starts checking. User needs are in a Word document at revision F. Design inputs are in a requirements document at revision K, which references user needs by a numbering scheme that changed at revision H. Verification protocols are PDFs in a controlled document system. Test reports are in a shared folder, some as scanned signatures. Software requirements live in Jira, because that is where the software team actually works, and the mapping from Jira issue keys to requirement identifiers is maintained by one engineer in a second spreadsheet. She will spend most of three weeks confirming that a matrix which was true at design freeze is still true after eleven change orders.

The products in this space are real and several are good. Greenlight Guru is built for exactly this and works well for small and mid sized device companies. Jama Connect and Siemens Polarion are strong requirements platforms with proper traceability. Matrix Requirements is well suited to lean teams. Ketryx exists specifically because software teams working in modern tooling could not be reconciled with document driven quality systems.

What drives companies to build is usually one of two things. Either the portfolio spans device types whose design records genuinely differ, such as an implant, a piece of capital equipment, and a mobile application that is itself a regulated device, or the engineering organisation has moved to a delivery cadence that a document centric system cannot follow without either slowing engineering down or producing records nobody believes. Across design control projects we have delivered, the recurring number is two to four weeks of senior quality and engineering time consumed per audit or submission simply assembling traceability that ought to be a query.

Problem 1: requirements in documents mean traceability is archaeology

21 CFR 820.30 and ISO 13485 clause 7.3 both require traceability from user needs through design inputs to outputs, verification, and validation, in both directions. Bidirectional matters. Forward tells you every requirement is verified. Backward tells you no test exists without a reason and no output exists without a requirement, which is how you find scope that crept in without assessment.

In a document world, neither direction exists as data. Both are reconstructed by a person reading revisions. The failure mode is not that the matrix is wrong on the day it is signed, it is that it decays silently. A requirement is amended in revision K and the verification protocol written against revision J is never revisited, because nothing told anyone to look.

What a custom build does: make each requirement a versioned record with a stable identifier and typed relationships to parents, children, risk controls, verification activities, and design outputs. When a requirement changes, everything linked to it is marked as needing review, immediately and visibly, with an owner. Trace matrices are generated views rather than maintained artefacts. This single change is what removes trace matrix week, and it is why companies who make it never go back.

Problem 2: software as a medical device broke the document model outright

IEC 62304 expects a software development lifecycle with software requirements, architecture, unit level detail proportionate to safety class, integration and system testing, an anomaly process, and configuration management including software of unknown provenance. Your software team works in a git repository, an issue tracker, and a continuous integration pipeline, and produces a hundred meaningful changes in the time a document control system processes one approval.

The common workarounds are both bad. Either the software team writes documents describing what they already built, which is expensive fiction, or quality accepts a Jira export as evidence and hopes the auditor does not probe the link between an issue key and a requirement.

What a custom build does: treat the engineering toolchain as the source and the quality record as a projection of it. Commits reference requirement identifiers, so the link from requirement to code to test to build is generated rather than asserted. Test results from the pipeline attach as verification evidence with the exact build identity, the environment, and the timestamp. Releases produce a record naming the requirements included, the anomalies open and their justification, the software bill of materials, and the risk assessment of what changed. Section 524B of the Federal Food, Drug, and Cosmetic Act made a software bill of materials and vulnerability management an explicit premarket expectation for cyber devices, which is far easier to satisfy when your build pipeline produces it automatically than when a person compiles it before each submission.

Problem 3: the risk file drifts away from the design

ISO 14971 asks for a risk management process where hazards, hazardous situations, and harms lead to risk controls, and where the effectiveness of each control is verified and residual risk evaluated. In practice the risk file is a large spreadsheet owned by one person, and design requirements are somewhere else. A risk control is implemented as a design requirement, but nothing enforces that the requirement still exists, still says what the control assumed, and has been verified.

What a custom build does: make risk controls point at the actual requirements that implement them, so removing or amending a requirement that implements a control raises an alarm rather than passing silently. Verification of control effectiveness links to the same evidence used for design verification, without duplicate records. When post market data shows a failure mode occurring more often than the risk analysis anticipated, the path from complaint code back to the hazard and its controls already exists. That loop from post market back into risk is the one auditors probe hardest and the one spreadsheets serve worst.

Problem 4: verification evidence lives in five places and none of them is the DHF

Bench testing produces data on laboratory systems. Biocompatibility and sterilisation come from external laboratories as PDF reports. Electrical safety and electromagnetic compatibility come from a test house. Usability validation under IEC 62366-1 produces session records and formative and summative reports. Software testing produces machine output. Clinical evaluation produces its own documentation. The design history file is expected to demonstrate that design controls were followed, and today it is assembled by pointing at all of these from an index.

What a custom build does: attach evidence to the verification activity it satisfies, with its own metadata: what was tested, which revision, which sample or build, who performed it, and what the acceptance criteria were. External laboratory reports arrive as PDFs and get parsed for the identifying fields and attached, with the original always retained. The design history file becomes a generated package with links resolved, produced in a day rather than a fortnight, and it is complete because the system knows which verification activities have no evidence attached.

Problem 5: change impact and the handoff to manufacturing

An engineering change to a component looks small until you ask which requirements it touches, which risk controls depend on it, which verification must be repeated, whether the change affects the device master record, and whether it changes anything in a registered dossier in any market. That analysis is done manually, and its quality depends on who did it.

What a custom build does: generate the impact set from the graph the system already holds. A proposed change names the outputs it touches and the system returns the affected requirements, risk controls, verification activities, and downstream manufacturing records, so the change board argues about the right things instead of assembling the list. Design transfer becomes traceable rather than ceremonial, since each design output maps to the manufacturing specification that realises it, and a change to one flags the other.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the shape for design control platforms. A first release covering versioned requirements with typed bidirectional links, design review records with compliant electronic approval, and generated trace views runs $85,000 to $175,000 and ships in 14 to 20 weeks. A full platform adding risk management integration, verification and validation evidence capture including automated test ingestion, software lifecycle records with build and bill of materials generation, change impact analysis, and design history file package generation runs $230,000 to $550,000 phased over 9 to 16 months.

• Whether software as a medical device is in scope. Connecting the engineering toolchain properly is the most valuable part of the build and also the part that requires the most agreement between quality and engineering.
• Portfolio breadth, since an implant, a capital instrument, and a mobile application have genuinely different record structures and squeezing them into one template serves none of them.
• Whether you integrate a product lifecycle management system for parts and drawings, which you usually should rather than rebuilding it.
• Validation of the platform itself, because it holds quality records and will be examined during audits of your quality system.
• Migration of legacy design history files, which is frequently underestimated. Historical products often stay where they are, and that is usually the right decision.

Build versus buy, and when buying is right

Buy if you are a single product company with a mechanical or electromechanical device and little or no embedded software. Greenlight Guru is built for you and will be running in weeks. Buy Jama Connect or Polarion if your problem is genuinely requirements management at scale and your quality processes already work, since rebuilding a mature requirements engine is a poor use of capital. Buy Ketryx if your specific gap is reconciling a modern software toolchain with a quality system and its model fits how you work.

Build when two or more of these are true. Your portfolio spans device categories whose design records genuinely differ. Your software organisation ships on a cadence that document driven quality has become a brake on, and the workarounds have started producing records you would not want examined closely. You need design control joined to post market data, manufacturing records, and registrations in ways a point product will not do. You are preparing submissions in several markets and assembling each dossier from the same underlying evidence by hand. Or trace matrix week is now a recurring multi week cost and it recurs before every audit and every release.

How to choose a developer for design control software

Ask them to model a requirement change before you sign anything. A developer who has done this describes versioned records, typed links, and automatic flagging of everything downstream that now needs review. A developer who describes a requirements table with a parent identifier column has not understood that the value is entirely in what happens when something changes.

Ask how they would link a git commit to a requirement and what evidence that produces. If the answer is a manual mapping spreadsheet, they have rebuilt the problem you are paying to remove.

Ask what they will hand your quality unit for validating the platform itself, and whether they have worked under 21 CFR Part 11 expectations for electronic signatures. This system will be examined during audits of your quality system.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. A design history file must remain retrievable for the lifetime of the device and beyond, which outlasts any software vendor relationship you will sign.