Medical Device Design Control Software Problems: The 7 That Fail an Audit, and How to Avoid Them

Why does a design control build end up as another document repository?

Because the requirement everybody writes down is document control, and document control is a solved, comfortable problem. A team scopes revision handling, approval routing and electronic signature, delivers all of it competently, and ships a system that stores the same Word files in a better cabinet. Traceability is then added as a table with a parent identifier column, which is a picture of the links rather than the links themselves.

The tell is what happens on change. In a document repository, amending a requirement produces a new revision and nothing else moves. Everything downstream that depended on the old wording carries on as though nothing happened, and the only mechanism that catches it is a human remembering. That is the exact failure the system was bought to prevent.

The fix is a scope decision made before development starts. Each requirement is 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 immediately marked as needing review, with a named owner and a date, and trace matrices become generated views rather than maintained artefacts. Documents still exist, because submissions need them, but they are rendered from the graph rather than being the graph.

Ask any developer to model a requirement change on a whiteboard before you sign. If the answer describes a table with a parent column and a report, they have understood the reporting problem and missed the point, which is entirely about what happens when something moves.

What goes wrong when you migrate legacy design history files?

Most of the pain here is self inflicted, because the instinct is to bring everything and the right answer is usually not to. Legacy files for products already on the market were assembled under a document model, their links exist only as text references, and reconstructing a typed graph from them means a person reading revisions and making judgement calls about what was intended. That is expensive, slow, and produces a record that is an interpretation rather than the original.

The specific danger is creating a second version of history. If the migrated graph disagrees in any detail with the controlled document that was actually approved, you now hold two accounts of the same design decision, and you will be asked which one governs.

Decide scope early and deliberately. Historical products generally stay where they are, under their existing controls, with the new system holding a reference rather than a copy. Products in active development migrate properly, with requirements re entered as records and links established by the engineers who own them rather than by a data conversion. Anything on a market that is being actively changed sits in the middle and needs a per product decision.

Where you do migrate, migrate forward from a defined baseline rather than replaying history. Take the current approved state as version one in the new system, record the reference to the legacy file, and let the new graph accumulate from there. Trying to reconstruct twelve years of design evolution as versioned records is months of work that answers a question nobody will ask.

Why do the git, Jira and product lifecycle integrations break after launch?

They break on identifiers. The link from a commit to a requirement depends on engineers referencing an identifier in a commit message, and the failure mode is not that they refuse. It is that they typo it, reference a requirement that was later superseded, or reference the issue key instead. Nothing errors. The link is simply absent, and it is absent from exactly the records you will be asked about.

The second cause is renaming. Issue trackers let people change keys during project restructuring, product lifecycle systems let part numbers be revised, and a mapping built on names rather than on stable internal identifiers quietly detaches.

The third is pipeline drift. Test results attach as verification evidence with a build identity, and then someone changes the build agent, the reporting format or the artefact retention window. Evidence keeps arriving, in a shape your parser no longer fully understands, and the gaps show up as verification activities with no evidence attached.

Build three defences. Validate references at commit time so an unknown or superseded identifier fails the check while the engineer is still in context, rather than being discovered a year later. Key everything on stable internal identifiers and treat display names as labels. And run a standing completeness report that lists every requirement without linked verification and every verification without evidence, reviewed weekly by a named person. That report is the health check for the whole system, and a build that does not produce it is asking you to trust integrations you cannot see.

What happens when platform validation and signature controls are not covered?

This is the gap that turns a good system into an audit finding. The platform holds quality records, so it is part of your quality system and will be examined during audits of it. That means it needs its own requirements, its own risk assessment, its own traceability, executed test evidence, and electronic signature controls consistent with 21 CFR Part 11 expectations covering signature manifestation, record linking and audit trail integrity.

When validation is treated as a phase two activity, two things go wrong. The obvious one is that you go live holding controlled records in an unvalidated system. The less obvious and more expensive one is that validating retrospectively means writing requirements for software that already exists and testing against them, which is both unconvincing and considerably more work than doing it in order.

Plan it from the first requirement. Your quality unit should be receiving a validation package as a deliverable, not asking for one at the end, and the developer should raise this before you do. Ask a candidate directly what that package contains and who authors each part, because a team that has worked under these expectations will describe the split between their evidence and your quality unit's approval without hesitating.

Include the audit trail design in that conversation. An audit trail that records writes but not reads, or that can be edited by an administrator, is a finding waiting to be written, and it is far cheaper to design correctly than to retrofit under an observation.

Should you build custom or configure what you already own?

If you are a single product company with a class II mechanical or electromechanical device and little or no embedded software, do not build. Greenlight Guru is built for exactly this and will have you audit ready faster and cheaper than anything bespoke, and there is no prize for reproducing it. If your real problem is requirements management at scale and your quality processes already work, Jama Connect or Siemens Polarion will do that job well and rebuilding a mature requirements engine is a poor use of capital.

Before concluding a tool has failed you, check whether the failure is configuration. Many companies run capable platforms with link types unconfigured, review workflows unused and the change impact features never enabled, then conclude the product cannot do what it demonstrably can. That investigation costs weeks of a quality engineer's time rather than a capital programme.

Build when two or more of these hold. Your portfolio spans device categories whose design records genuinely differ, such as an implant, a piece of capital equipment and a mobile application that is itself regulated, and forcing one template on all three serves none of them. Your software organisation ships at a cadence document driven quality has become a brake on, and the workarounds are producing records you would not want examined closely. Or you need design control joined to post market data, manufacturing records and registrations in a way no point product will do.

How do hidden costs get into the quote?

Platform validation is the most commonly omitted line, and it is not small. Requirements, risk assessment, traceability, executed testing and the signature controls for the system itself are a workstream, and a quote that does not name it is quoting half the job.

The second is the negotiation between quality and engineering. Deciding what evidence the build pipeline should produce and what a release record must contain is a genuine negotiation between two functions with different incentives, not a requirements interview, and it is the single most common cause of schedule slip in this category. Budget calendar time for it explicitly.

Then four more. Portfolio breadth, because each additional device category is a record structure rather than a configuration option. Product lifecycle integration for parts and drawings, which you generally should do rather than rebuilding and which is priced separately. Migration decisions, which look cheap until someone proposes reconstructing legacy files. And the second and third development site if your engineering is distributed, because identifier conventions and review practices are rarely consistent across them.

Ask for the price of device category two in writing at the start. It is the number most likely to arrive later as a change request.

What separates a design control build that works from one that fails?

Change behaviour designed first. Everything valuable in this system is what happens when a requirement moves, so build that path before building the pleasant screens. If amending a requirement flags its linked risk controls, verification activities and design outputs for review with named owners on day one of the pilot, the rest follows. If it does not, no amount of reporting will save it.

The toolchain treated as the source and the quality record as a projection of it. Commits reference requirement identifiers, pipeline results attach as evidence with the exact build identity, and each release produces a record naming included requirements, open anomalies with justification, the software bill of materials and the 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, and that is far easier to satisfy from a pipeline that generates it than from a person assembling it before each submission.

Risk controls pointing at the specific requirements that implement them, so amending or deleting such a requirement raises an alarm rather than passing silently, and so the path from a post market complaint code back to the hazard and its controls already exists. That loop is what inspectors probe hardest and what spreadsheets serve worst.

A pilot on one real product rather than a rollout across the portfolio. One device, end to end, through a real change and a real design review, will teach you more than six months of configuration and costs a fraction of a failed rollout.

And ownership in writing before kickoff: the repository, the infrastructure accounts and the unrestricted right to hire anyone else. A design history file must remain retrievable for the lifetime of the device and beyond, which outlasts any software vendor relationship you will sign.