A reading path through SaMD architecture
The posts here were written one at a time, but they build on each other. This is the order I would read them in. Diagrams enlarge when you click them, and every post links on to related ones.
The framework
Four principles for platforms that keep working when it matters most.
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.
Foundations
How to think before the first box is drawn, and where to draw the lines.
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 as architecture
Each standard is a design requirement in disguise.
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 and the DHF
Evidence is a chain, and gaps hide where standards meet.
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.
Patterns for connected systems
Messaging, modernization and trust, in a regulated setting.
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.
"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.
Production and self-check
Post-market readiness is decided at design time. Then test yourself.
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.
Looking for the principles behind all of it? Read the Resilient MedTech Architecture Framework.
Question about something here?
Questions, corrections and counterexamples are welcome. Send a note or message me on LinkedIn.