What Software Teams Can Learn from ISO 13485 (the QMS Behind Medical Devices)

Steve Wong — Thu, 22 Oct 2026 02:01:26 +0000

Software ships bugs and patches them. A catheter that ships a defect can ship an injury. That asymmetry is why medical device manufacturing runs on ISO 13485 — a quality management system that looks, at first glance, like bureaucracy. Look closer and it's a set of engineering disciplines that most software teams adopt only after their first big outage.

I work around this industry, and every time I map 13485 concepts onto software practice, the mapping is uncomfortably exact. Here's the tour.

Design controls = your SDLC, with receipts ISO 13485 clause 7.3 (design & development) requires, in essence:

Design inputs → requirements (but traceable, signed, versioned)
Design outputs → the spec that manufacturing actually builds against
Design review → gate reviews with named approvers, not a thumbs-up emoji
Verification → "did we build it right?" (your test suite)
Validation → "did we build the right thing?" (your UAT — except here it's sometimes a cadaver lab)
Design transfer → the handover from prototype to production, with a process, not a Slack message
The uncomfortable part: in 13485 land, every one of those steps produces a record. Not "we discussed it in standup" — a dated, attributable artifact. When something fails in the field, you can reconstruct exactly what was known, decided, and approved at every point in time.

Software teams usually build this only after the postmortem that demands it.

The DHF/DMR/DHR trio = three repos, not one Medical devices keep three living records:

DHF (Design History File) — why the product is what it is. Like your ADRs + RFCs + decision logs, forever.
DMR (Device Master Record) — the build recipe. Like your infra-as-code repo: the single source of truth for manufacturing.
DHR (Device History Record) — proof that this specific unit was built per the DMR. Like your per-release build logs, except it's per-unit, permanent, and auditable.
Most software orgs have (1) partially and (2) sometimes. Almost nobody has (3) at unit granularity — but if you've ever run a recall, you've wished for it.

CAPA = incident management that actually closes the loop CAPA (Corrective and Preventive Action) is postmortem culture with teeth:

Contain (stop shipping the bad thing)
Root cause (documented, not vibes)
Corrective action (fix this batch)
Preventive action (fix the class of bugs, not the instance)
Effectiveness check — scheduled, dated, assigned: "did the fix actually prevent recurrence?"
Step 5 is where most software postmortem processes quietly die. 13485 makes it a tracked obligation with an owner and a due date. If your "action items" from postmortems live in a doc nobody opens, that's the gap.

Risk management runs parallel, not sequential Devices pair 13485 with ISO 14971 risk management: hazards are identified, scored (severity × probability), and mitigated by design first, then by protective measures, then by information for use. Mitigations are traced to the hazard they address.

It's threat modeling — except the threat model is a living document with sign-offs, and "we'll add it to the backlog" is not an acceptable mitigation state for high-severity items.

Process validation: you can't test quality in For anything you can't fully verify by inspection (a molded part, an extruded tube, a weld), 13485 requires process validation: demonstrate that the process itself reliably produces good output — IQ/OQ/PQ (installation, operational, performance qualification).

Software equivalent: you don't just test the artifact; you prove the pipeline is capable. Think: build reproducibility, flaky-test elimination, deployment process capability. The mindset is "stable process → stable output", not "inspect harder".

What this looks like in practice
These disciplines sound abstract until you see them attached to real parts. A vascular access sheath, for example, has tolerances where "nominal spec" and "consistently delivered dimension" are different engineering claims — the same lesson as flaky tests: a passing build is not a stable pipeline.(If you're curious what that looks like for real hardware, we wrote a cath-lab-facing guide on the sizing logic behind one product family: Radial Artery Spasm: Causes and Prevention.)

The takeaway
ISO 13485 isn't magic — it's the engineering discipline of traceability, gate reviews, closed-loop corrective action, and process capability, enforced by regulation because the cost of failure is measured in patients. Software teams can steal all of it without the regulation. The parts worth stealing first:

Records with owners and dates (not chat history)
Per-release history at unit granularity
Effectiveness checks on every postmortem action
Risk mitigations traced to hazards, not to a backlog
About the author context: this perspective comes from working with SCW Medicath Ltd., a Shenzhen-based, ISO 13485:2016-certified manufacturer of single-use medical devices (vascular access, urology, hemodialysis, orthopedics consumables) with OEM/ODM programs for global distributors — scwmed.com. The views here are about the discipline, not a product pitch.

DEV Community: Steve Wong

What Software Teams Can Learn from ISO 13485 (the QMS Behind Medical Devices)