Device translation fails for administrative reasons far more often than scientific ones, and almost all of those reasons come down to sequencing. Nearly everything a device company must eventually produce is straightforward if begun at the right moment and ruinous if begun late.
This session lays out the sequence: when to open the risk file, when the quality system needs to be operating rather than drafted, when usability work is cheap and when it becomes a change request, and how long governance approvals actually take as opposed to how long project plans assume.
It is deliberately not a training course. It is ninety minutes intended to reorder your development plan, delivered by someone who spent eleven years assessing submissions and has watched the same avoidable failures several hundred times.
There is a segment on software as a medical device, where development teams accustomed to continuous deployment meet a framework expecting a defined intended use and controlled change. Both positions are reasonable and reconciling them is work.
Running order
Approximate, and kept to.
- 00:00Why device programmes fail administratively rather than technically
- 00:15The sequence: risk file, quality system, usability, clinical evidence
- 00:40How long approvals actually take
- 00:55Software as a medical device: change control and intended use
- 01:15Questions, answered plainly
Who this is for
- Device and diagnostic startups before their design freeze
- Engineering teams who have just been told they need a quality system
- Investors trying to assess a device company's regulatory timeline
- Academic groups considering a spin-out around a clinical device
