A good part of our work starts a few months before an FDA or MDR submission, with an email and a folder. The device is built, the submission date is set, and someone has realised that the software part of the file is not ready.
What arrives
The folder is rarely empty. In the last year three requests showed the range.
In the first, an engineering firm had built a device for a client and was asked for a subset of the software documentation in the client's templates, among them the SOUP list, the threat model and the cybersecurity report. The firmware was finished. There was a system flow diagram, a risk file and no structured list of software requirements.
In the second, a team had a laboratory device used in clinical trials, a desktop application and controller firmware, and almost no documentation. The validation plan, the requirements, the verification plan, the test report and the traceability matrix all had to be written, and there was not a single automated test.
In the third, a full documentation set had already been submitted to the FDA. The question was whether the legacy embedded code still did what those several hundred pages said.
Three very different starting points, and the same handful of problems in each.
The gaps we find
The documents describe the software someone intended to build. This is the most serious one and the hardest to see from the inside. In the third case the comparison of documents and code found security and safety functions the design described but the code did not implement, logic that differed from the documented behaviour, and code left over from earlier hardware versions. None of these were visible from the documents alone.
There are no software requirements, only a product description. Test cases need something to trace back to. When the requirements live in a flow diagram or in people's heads, the first real task is to extract them into testable statements and get them confirmed, before anyone writes a test.
The SOUP list is a guess. An RTOS, a vendor SDK, a bootloader, a protocol stack, a file system: modern firmware pulls in many third party components, and the list in the file was written from memory. It has to come from the build environment, with exact versions, and each item needs a look at its published known issues.
The code cannot be tested without the hardware. In the second case nothing could be verified automatically until the desktop application was refactored so the hardware could be simulated. Documentation projects turn into small engineering projects at this point, and the plan has to allow for it.
The templates were written for a different product. Client templates for cybersecurity reports and threat models were written for a cloud platform with a mobile app, and arrive half full of sections that do not apply to a standalone device. Filling every section produces a long document that a reviewer will question. Agreeing early which sections are in scope, and saying why the others are not applicable, saves weeks.
The questions that come up every time
These were open in all three cases above, and each one changes the size of the work.
What is the software safety class? Without it nobody can say how detailed the design description, the unit level verification and the SOUP analysis must be. It has to come from the risk analysis, with the reasoning written down, and it is the first thing we settle.
What is the submission date, really? A date that is three months away and a date that is "probably November" lead to different plans. If it is fixed, the work is split so documents can be written in parallel.
What counts as the baseline? Documentation describes one version of the code. If development continues, every change after the agreed commit needs to be tracked into the documents, or the file is out of date on the day it is submitted.
Are we writing documents, or also fixing code? We are also a development team, so when the documents reveal a defect in the code, we can fix it right away. What gets fixed and when is agreed with the client, and every change is assessed for whether it counts as a significant or a minor change for the notified body or the FDA. Patient safety comes first in that discussion: when a defect touches a risk control, we flag it straight away and propose how to handle it, and the manufacturer decides.
Who runs the tests? Writing test cases and executing them are two different jobs. Execution needs the hardware, the test environment and someone who signs the records, and whether that is the client's team or ours changes the plan and the schedule.
Is this a cyber device? For the FDA, a device with software that can connect, through any channel including Bluetooth or USB, needs an SBOM, a threat model and a plan for vulnerabilities after release.
Where we help
We start with the folder: read the code, the documents and the risk file, and answer the open questions above in a short written report, with an agreed scope. For some clients that report is the deliverable, and their own team does the rest. For others we write the missing documents in their templates, generate the SOUP list and SBOM from the build, write the threat model, the test cases or the full verification package, and fix the code where the documents show it needs fixing. An FDA specialist works with us on these projects, and the work runs inside the client's ISO 13485 quality system.
My advice for anyone a few months from a submission: send the folder early. The gaps above take weeks to close, and most of them can be found in the first few days of reading. Write to me at tamas.fodor@silurus-software.com.