"What happens to a patient when your system fails?" ISO 14971 asks this question. Your architecture must answer it.
Risk is severity multiplied by probability. You either control it or justify it.
What architects must own
- Risk is a Day 1 design input. Hazard identification and risk controls are defined before you write code. Isolation, degraded modes and failure domains are formal risk control measures, traced to the DHF and Risk Management File.
- Cybersecurity risks are patient safety risks. FDA treats cyber vulnerabilities as safety risks, not IT problems. Segmentation, JWT validation and a hardened edge are formal risk controls.
- Every architecture change triggers a risk review. A new microservice, an updated dependency or a new cloud integration each has to be evaluated for new hazards. Without traceability you can't re-run the analysis.
- AI introduces a new category of hazard. A model can produce clinically harmful output without technically failing. Severity times probability still applies, but probability gets harder to estimate once a model drifts after deployment.
Connection to the framework
- Blast Radius: isolating clinical failure domains is a documented risk control under ISO 14971.
- Dark Day: offline-first capability is the hazard mitigation for cloud dependency failure.
The standards and the architecture are saying the same thing. One just happens to be a regulatory requirement.
Seen this differently?
Questions, corrections and counterexamples are welcome.
