Notes on medical device software architecture
Short diagrams and longer pieces on boundaries, safety classification, connected devices, delivery and post-market readiness. New writing most weeks. New here? Try the reading path.
"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.
The Resilient MedTech Architecture Framework
Four principles for healthcare platforms that keep working when it matters most. Resilience and speed of innovation are not a trade-off.
The Blast Radius Principle
Architect your systems so any failure, breach or disruption is contained to the smallest possible surface area.
Designing for the "Dark Day"
ECRI ranked digital darkness a top health technology hazard for 2026. Resilience is architectural, and it starts with isolation, not redundancy.
Intentional Modernization
In MedTech, a cloud-native monolith is a legacy problem with a higher monthly bill. Modernization is a decoupling, and the best time to build in resilience.
From healthcare software to medical device software
The engineering isn't harder. The stakes attached to it are different. What changes when your software becomes part of the clinical decision.
Five questions before I draw a single box
Not about technology. Not about frameworks. About the system. The questions I ask before any whiteboard session.
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.
Decompose by safety classification
Draw service boundaries around clinical risk, not team preference. A mixed-class service puts Class C verification on every change.
Scaling a SaMD platform is not scaling SaaS
Splitting a service, adding a vendor, moving to events or adding a cache each carry a regulatory consequence that SaaS teams never see.
Starting a SaMD from scratch: six decisions most teams make too late
The hard part isn't knowing what to do. It's having the mandate to do it before the pressure to ship takes over.
Standards are architectural requirements in disguise
A map of the core MedTech standards stack and why architects should care about each layer. Compliance is a Day 1 design decision.
ISO 13485 is the house. IEC 62304 is what lives inside it.
ISO 13485 governs the whole development process. IEC 62304 is the execution engine for software inside it. One without the other is an auditable gap.
Risk management is not a document. It is a design input.
ISO 14971 asks what happens to a patient when your system fails. Your architecture has to answer it, before you write code.
Cybersecurity is not a phase. It is a design requirement.
If your security architecture isn't documented in the DHF, then under SW96 it doesn't exist. What the standard asks of architects.
The interface is not a design layer. It is a safety boundary.
Good UX makes an interface intuitive. Regulatory usability engineering proves it is safe. They are not the same thing.
SOUP is an architecture decision
To engineers it is a dependency list. To a regulator it is a risk artifact. What stalls submissions and what good looks like.
Your pipeline is your change control process
Build, test, board approval, deploy, verify. Evidence should be a by-product of the pipeline, not a documentation task.
Traceability is not a matrix. It is a chain, and it must never break.
A broken chain doesn't mean the engineering was wrong. It means the evidence that it was right doesn't exist.
The gaps are not inside one standard. They live at the intersections.
A DHF gap assessment asks one question per artifact: can you trace it back to the standard that requires it, and forward to the decision it justifies?
The hardest gaps are not incomplete. They do not exist at all.
When foundational artifacts are missing entirely, the order of remediation is everything. Fix it in the wrong order and you rewrite everything.
Same pattern. Different contract.
In a clinical SaMD an event is not a notification. It is a clinical state transition: traceable, auditable and safe to replay.
In a medical device platform, modernization is a regulatory strategy
Not just a technical one. Every module you replace is a change control event under IEC 62304.
Zero Trust is an architectural principle. In a clinical platform it is also a regulatory one.
Never trust implicitly. Verify continuously. Enforce least privilege at every boundary, and document all of it in your DHF.
RabbitMQ is not a queue. It is a routing engine with queues attached.
Most production failures come from treating it as a black box and discovering its failure modes under load.
When something goes wrong in production, can your architecture respond?
Signal detection, an audit trail, isolation and an update pathway decide whether an anomaly becomes a recall risk.
Is your SaMD platform audit-ready?
Five questions to answer honestly. The gap between what was built and what was documented is usually wider than anyone realised.
Question about something here?
Questions, corrections and counterexamples are welcome. Send a note or message me on LinkedIn.