When I moved from healthcare software into medical device software I expected the technical challenges to be familiar. Most of them were.
What I did not expect was how different the relationship between engineering and accountability feels.
In healthcare software you build systems that support clinical decisions. In medical device software you build systems that are part of the clinical decision. That distinction sounds subtle. It changes everything about how you design, document and think about failure.
In healthcare software a bug is a bug. In medical device software a bug is a potential hazard, with a severity, a probability and a risk control that must be documented before the fix can ship.
In healthcare software, architecture decisions serve the product. In medical device software they serve the product and the evidence chain that proves it is safe.
The engineering is not harder. The stakes attached to it are different.
What surprised me most was how much the regulatory framework (IEC 62304, ISO 14971, the DHF) is not bureaucracy. It is a structured way of asking the question engineers should be asking anyway: what happens when this fails, and can you prove you thought about it before you shipped?
What I brought with me was years of building distributed systems, clinical platforms and regulated software. It turns out to be what this space needs.
That reframe, compliance as structured engineering rigor rather than documentation overhead, changed how I approach every system I design now.
Seen this differently?
Questions, corrections and counterexamples are welcome.