Architecture that holds up in a medical device.
I'm Rakesh Chittineni, a principal software engineer and architect. I write about designing medical device software that stays safe, resilient and explainable under regulatory scrutiny, and where it quietly goes wrong.
Resilient MedTech
Architecture Framework
- The Blast Radius PrincipleClinical operations isolated from corporate IT.
- Designing for the "Dark Day"Safe operation when the cloud is unavailable.
- Intentional ModernizationResilience built in while legacy is modernized.
- Sovereign Systems, Not Silent FleetsHumans keep authority over high-impact decisions.
A reading path through SaMD architecture
New to the site? These six steps take you from where to draw boundaries to how to test your own platform. Each one takes a minute or two.
The framework
Four principles for platforms that keep working when it matters most.
Foundations
How to think before the first box is drawn, and where to draw the lines.
Standards as architecture
Each standard is a design requirement in disguise.
Traceability and the DHF
Evidence is a chain, and gaps hide where standards meet.
Patterns for connected systems
Messaging, modernization and trust, in a regulated setting.
Production and self-check
Post-market readiness is decided at design time. Then test yourself.
Notes from real systems
New writing most weeks. Diagrams you can read in a minute, and longer pieces when a topic needs them.

Security posture is a patch path
A CVE lands in a dependency you ship. How much of the system you must re-verify to fix it is decided by architecture, long before.

"Saved" is not "received"
A cloud app says a record is saved. The device may never have got it. Where delivery guarantees stop on AWS IoT Core, and what to build on top.

Systems don't fail. Boundaries do.
A system that starts with clean boundaries rarely keeps them. Losing them costs more than keeping them ever did.
Question about something here?
Questions, corrections and counterexamples are welcome. Send a note or message me on LinkedIn.