Shipping software under IEC 62304

At Doktor24 I owned the triage module: a critical part of the platform that spanned the frontend, internal services and integrations with external partners. I also contributed to the platform's IEC 62304 certification. It changed how I think about shipping software, including in projects that have nothing to do with healthcare.

What IEC 62304 is, in plain terms

IEC 62304 is an international standard for the software lifecycle of medical device software. It doesn't tell you which language or framework to use. It asks you to run a disciplined process and to be able to show that you did. In broad terms, that means:

• Planning how the software is developed and maintained.
• Requirements that are written down.
• Risk management: understanding how the software could contribute to harm, and controlling it.
• Traceability between requirements, design, code, tests and risks.
• Verification: evidence that the software does what the requirements say.
• Change and configuration management: knowing exactly what changed, why, and in which version.
• Problem resolution: a defined way to handle defects.

The level of rigor depends on the software's safety classification. I'm describing the general shape of the standard here, not a compliance guide.

Why triage raised the stakes

A triage flow helps decide what kind of care a patient needs. It touches the patient-facing UI, internal logic and partners outside the company. A mistake in any of those parts matters more than a broken layout. Owning it meant thinking about the whole path, not just my part of the stack.

How it changed the way I ship

Every change has a reason you can point to

Under a regulated process, "I refactored some things" isn't a change description. A change links to a requirement or a problem report, and you can follow it from the ticket to the code to the test. After working this way, I write smaller, better-described pull requests everywhere.

Tests are evidence, not a formality

Verification means showing that a requirement is met. That pushes you to write tests that map to behavior someone asked for, not just to lines of code.

Risk is a design input

Instead of asking "does it work?", you also ask "how could this fail, and what happens to the user if it does?" Then you design a control: validation, a safer default, a clearer message, a human check. That habit carried straight into how I later designed LLM features, where the answer to "what if the model is wrong?" has to be designed, not hoped for. I wrote about that in LLMs in production.

Integrations deserve the same rigor as your own code

When partners are part of a critical flow, their contracts, failure modes and changes are part of your risk picture. Clear interfaces and explicit error handling aren't nice-to-haves.

What I kept after healthcare

You don't need a certification to benefit from these habits:

1. Link changes to reasons: a ticket, a requirement, a bug.
2. Write tests against requirements, so they explain what the system must do.
3. Ask how each feature can fail and design the control before shipping.
4. Know exactly what is in each release, and be able to roll back.
5. Treat external integrations as part of your system.

Regulated software has a reputation for being slow. What I took from it is different: it makes you deliberate. That's useful anywhere the software matters to the people using it.