Technical and regulatory audit of your medical software
An outside engineer’s look at your software and at its file: what holds, what will not hold in front of the notified body, and in what order to put it right.
What I look at
A useful audit covers three planes at once, because failures in medical device software almost always sit where they meet. The software itself: architecture, breakdown into items, external dependencies and software of unknown provenance, test quality and coverage, build and release pipeline, version management. I read the code. An audit built on interviews alone produces a report that reflects what the team believes it has done, which is almost never what has been shipped. The file next: software development plan, requirements specification, traceability matrix linking requirements, tests and risks, risk analysis in the ISO 14971 sense, software safety classification of the items and its rationale. The question is not whether the documents exist, but whether they describe the software actually shipped or an idealised version that never ran. The organisation last: who decides, who verifies, how a change travels through the process, and whether the quality system is lived or reassembled before each audit. A process deviation can be repaired; a quality system nobody applies is paid for far more dearly, and always at the worst moment.
How the audit runs
The audit starts with scoping: what is in, what is out, and what you actually want to find out. Preparing a first assessment, taking over software inherited from an acquisition, or informing an investor do not call for the same angle of attack, and an audit claiming to answer all three answers none of them well. Then comes access to the material: code repository, documentation, quality system, requirements and defect tracking tools. Then short interviews with the people who do the work — developers, quality, regulatory affairs, product — held separately. The most instructive gaps show up when two people describe the same process differently. I debrief verbally before I write. That avoids the two classic failings of the audit report: the surprise in a board meeting, and the sound finding resting on a false assumption that nobody corrected in time. The written report comes next. It is written to be read by your executive committee as much as by your developers: every gap is named, located, explained in its consequences, and paired with a possible remediation.
What you get out of it
Three things. An honest map of the gaps first, ranked by real severity and not by the order in which they appear in the standard. Not every gap carries the same weight: incomplete traceability blocks an assessment, a debatable naming convention blocks nothing at all, and confusing the two wastes a great deal of time for teams already under pressure. A route next. For each gap, what has to be done, in what order, and what absolutely must be settled before submission. That is the part purely regulatory audits often leave aside: they record the non-conformity without saying what it means in the code, in the tests and in your teams’ schedule. A shared language last. After the audit, your leadership, your quality function and your developers talk about the same product with the same words and the same order of priorities. It is less spectacular than a list of gaps, and it is often what actually unblocks the situation. I issue no certification and I stand in for no notified body: I tell you what I see, with the reading of an engineer who has already taken medical software all the way to market.
What an audit does not replace
An audit is not a remediation. It gives you a picture and a trajectory; the rework itself remains whole, and it is counted in engineering, not in documentary corrections. Saying so up front avoids the classic disappointment of the report filed in a shared drive and never opened again. Nor does an audit replace your quality management system, your clinical evaluation, or the work of your notified body. It sheds light on the software side, which is where gaps are discovered latest and cost most, because it is the only part whose claims nobody at the table can verify without opening the code. Finally, an audit is only worth something if you are willing to hear what is wrong. I do not write accommodating reports: if the finding is that the architecture will not carry the software safety class you are aiming at, that is what will be written, along with what it implies. If the rework interests you, it falls under the interim engagement or under product delivery. The audit stays independent of that sequel: nothing obliges you to entrust it to me.
Let’s talk about your product
A credible peer, in the boardroom and in the operating theatre.