Connected medical devices: securing the whole ecosystem
How dependencies, trust boundaries and compromised networks should shape threat modelling and penetration testing for connected medical devices.
When medical software fails quietly
How stale data, incorrect units, patient mismatches and misleading displays can produce plausible but wrong outputs—and how to detect and control these quiet failures.
The algorithm is not the product
Why successful medical software requires evidence for the complete clinical product and workflow—not only the performance of its algorithm.
CSA, Part 11 and QMSR: building a coherent software assurance approach
A practical approach to shared software assurance evidence, with clear regulatory boundaries and a worked calibration-system example.
Which standards apply to an IVD medical device?
Why standards selection for an IVD must follow the complete system, its intended purpose and the consequences of an incorrect result.
Which standards does your medical device actually need?
Why a long standards list is not enough—and how intended purpose, harmonisation and product-specific evidence shape a defensible standards assessment.
AI! AI! Oh?
A playful but serious reflection on AI as assistant, reviewer and decision-maker—and why fluent answers still need evidence, judgement and accountability.
AI has accelerated medical-device development—but not manufacturer responsibility
AI changes the speed and economics of medical-device development, but it does not remove the need for product definition, objective evidence, competent review or manufacturer accountability.
You outsourced the development—not the accountability
Why outsourcing medical-device development increases the need for intelligent manufacturer oversight—and what must be controlled before an audit or submission exposes the gaps.
From IV to subcutaneous to oral: is this the natural evolution of a medicine?
Does treatment naturally progress from infusion to injection and finally to a tablet—or can digitally supported subcutaneous delivery be the better destination?
Who is responsible for medical-device development? From startup founder to corporate leadership
How the responsibilities of startup founders, SME management and corporate leaders differ—and why qualified external advice is most valuable before major development commitments are made.
Can an unregistered digital health technology be used in a clinical trial?
Why absence of commercial registration does not automatically prevent a digital health technology from being used in a clinical trial—and the questions sponsors should ask instead.
When dose delivery becomes Essential Performance
A practical interpretation of Essential Performance for electronically driven injection systems, and what engineers should specify, trace and verify.
The practical guide to developing a medical device
An end-to-end view of medical-device development, from intended purpose and user needs through verification, validation, transfer and maintenance.
Design controls: from user need to objective evidence
How user needs, requirements, design outputs, risk controls, verification and validation form a coherent evidence chain.
Why an FMEA is not a complete product risk analysis
Understand where FMEA helps, what it misses and how to integrate it into a complete medical-device risk-management process.
IEC 62304 and the medical-device software lifecycle
A practical introduction to IEC 62304, software safety classification and the evidence created across development and maintenance.
Medical-device cybersecurity: an integrated lifecycle approach
How to integrate cybersecurity governance and evidence across the complete medical-device lifecycle.
Verification and validation: what is the difference?
A clear explanation of verification, validation and how both connect to user needs, design inputs and objective evidence.
Primary functions, essential performance and safety-related requirements
A practical framework for distinguishing device functions, essential performance, safety-related requirements and supporting quality attributes.
Building an audit-ready design history file
What makes development evidence coherent, reviewable and defensible before an audit or submission.