Three examples, one from each area I work in. Names and identifying details are left out; I'm happy to talk through any of them on a call.
Software quality & V&V
Restarting releases on an implantable neuromodulation system with an Agile SDLC
Client
Neuromodulation device company
My role
Verification and validation lead; redesigned the SDLC and QMS for Agile
Standards
IEC 62304:2006/AMD1:2015 · ISO 14971:2019 · AAMI TIR45 (Agile)
The situation
The company's implantable neuromodulation system hadn't made it through design transfer and release in over two years. Changes were piling up, and the verification and validation evidence needed to release them wasn't getting produced. Much of the system could only be exercised by hand, so the manual test program was the bottleneck.
What I did
Redeveloped the entire software development lifecycle and the supporting QMS procedures so the team could work Agile and still produce compliant design-control evidence every release.
Took ownership of manual verification and validation testing.
Wrote test protocols traced to requirements and to the risk controls in the risk file.
Ran execution, recorded objective evidence, and managed anomalies through formal problem resolution.
Wrote the V&V summary reports that design transfer and release depended on.
The result
Design transfer and release went back onto a regular cadence, roughly quarterly, after more than two years without one.
What other teams can take from it
Agile and IEC 62304 aren't in conflict. When the lifecycle is designed so each increment produces its own traced evidence, releases become routine instead of a once-in-years event.
Answering an FDA cybersecurity request for additional information
Client
Connected-device manufacturer
My role
Threat modeling and security risk assessment
Standards
FDA premarket cybersecurity guidance · FD&C Act section 524B · AAMI SW96 / TIR57 · ISO 14971:2019
Length
8 weeks
The situation
During premarket review, FDA sent a request for additional information focused on cybersecurity. The existing documentation didn't give the reviewer a security risk assessment or a clear picture of the system's attack surface.
What I did
Built the threat assessment and risk analysis (TARA) using STRIDE threat modeling.
Built the security risk register and connected it to the safety risk file.
Documented the system's security footprint: components, interfaces, trust boundaries and data flows.
Advised the team building the SBOM on using the NTIA minimum elements.
Assembled the response to FDA's questions.
The result
FDA accepted the response.
What other teams can take from it
A cybersecurity request is rarely about a single missing document. FDA wants to see that you understand the attack surface and have tied each threat to a control and to the safety risk file.
Launching a new interventional laser system and its EU MDR file at the same time
Client
Global medical technology company
My role
Owner of system-level quality, human factors, risk management and the DHF
Standards
ISO 14971:2019 · IEC 62366-1:2015/AMD1:2020 · IEC 60601-1 · IEC 60825-1 · EU MDR (2017/745) · ISO 13485:2016
Length
About a year
The situation
A global medical technology company was developing a next-generation interventional laser therapy system while bringing its technical documentation up to EU MDR. Rather than run two programs back to back, it ran MDR remediation alongside new product development, so the same design, risk and usability work had to satisfy both FDA and a notified body.
What I did
Owned system-level quality from design inputs through design transfer.
Owned the risk management file: plan, hazard analysis, FMEAs (including the software FMEA, built on the company's own method), benefit-risk and the risk management report.
When FDA asked whether the software added risk to the device, I led a five-person team through a fault tree analysis built on actual component failure data from reliability engineering.
Owned human factors: use specification, use-related risk analysis, critical tasks, and formative and summative evaluation under IEC 62366-1.
Owned the design history file and completed the risk management sections of the notified body submission.
The result
The fault tree showed empirically that the software didn't add risk to the device, answering FDA's question with data instead of argument.
The new system was released, and the EU MDR technical documentation was delivered shortly after launch, ahead of the regulatory deadline.
One connected set of design, risk and usability evidence served both the US launch and the MDR file.
What other teams can take from it
If MDR remediation and new product work overlap, run them as one program. And when a reviewer asks whether software adds risk, a fault tree grounded in real reliability data beats a qualitative argument.
