At Hattrick IT, we have taken over mid-development of medical device software projects. The most complex involved a project where a previous vendor had failed to deliver, leaving a partially built codebase with significant compliance gaps. We completed the project and supported the FDA submission.
That experience taught us that a failing medical device software project is not automatically a lost project. But recovering it requires a methodical approach,as well as the discipline to make hard remediation decisions early.
Before You Begin: Understanding What You Are Actually Inheriting
The instinct when taking over a distressed project is to assess the software first. Functionality, architecture, code quality, test coverage. These are important — but they are the second thing to assess, not the first.
The first thing to assess is the compliance posture.
A medical device software project can have a reasonably functional codebase and still be months from FDA-ready, because the gap is not in the technology — it is in the evidence trail. And it can also have a compliance posture that looks superficially acceptable on paper while the actual development artifacts are so incomplete that no amount of documentation cleanup will make them credible to a reviewer.
Understanding which situation you are in determines everything about what comes next. Misread this assessment and you will either over-invest in remediating a codebase that needs to be rewritten, or under-invest in documentation remediation you could have addressed without touching the code.
Knowing which mode you are in (or what proportion of each) is the entire purpose of Phase 1.
Phase 1: The Technical and Compliance Audit
A proper audit of an inherited medical device software project has two parallel tracks that need to be run simultaneously: the technical assessment and the compliance assessment. They are related but distinct, and conflating them leads to either missing critical compliance gaps or over-engineering technical solutions to problems that could be solved at the documentation layer.
Budget two to three weeks for a thorough audit. Shortcutting this step is the most expensive mistake teams make when inheriting a distressed project.
Track 1: Technical Assessment
Architecture and safety-critical component isolation
The first question to answer is whether the software architecture makes IEC 62304 compliance achievable at all. Specifically: can you draw a clear, defensible boundary around safety-critical software items?
IEC 62304 requires development rigor proportional to the software safety class of each component. If safety-critical and non-critical code is structurally entangled — through shared modules, unclear dependencies, or no architectural separation — you cannot write an honest software architecture description. The compliance artifacts you build on top of it will not hold up to scrutiny.
Assess: Which components interact directly with patient data or therapy delivery? Are those components architecturally isolated, or are safety-critical functions spread across the codebase without clear boundaries?
Traceability coverage
Determine what percentage of the existing codebase has traceable, documented requirements. Do not assess this from documentation alone — go through the actual tickets, the commit history, the test cases.
Pay particular attention to which parts of the codebase are untraceable. In our experience, the untraceable portions are almost always the most complex, highest-risk components — the parts developers found hardest to specify. A project with 60% traceability coverage that is missing the safety-critical modules is in a materially different position from one that is missing lower-risk utility functions.
Verification coverage versus code coverage
These are not the same thing. Code coverage (the percentage of code executed by automated tests) is a useful engineering metric. Verification coverage — the percentage of documented software requirements with corresponding, executable test cases and execution records — is what FDA cares about.
Documentation-to-code drift
Compare the existing documentation against the current implementation systematically. Do the architecture diagrams reflect the actual system? Are interface specifications current? Have design changes been documented as they were made, or was documentation written before development and never updated?
This drift is almost always more extensive than teams expect when they first encounter it. The discovery is painful. It is far less painful to surface it now than during FDA review.
Anomaly backlog
Review every tracked defect. Is the severity classification defensible under ISO 14971 risk analysis? Are any open anomalies in safety-critical components? Are deferred defects documented with rationale that would withstand reviewer scrutiny?
Track 2: Compliance Assessment
Software safety class determination
Verify that the project's declared IEC 62304 software safety class is accurate for the current intended use and feature set. Projects frequently drift — a feature expansion changes the intended use, and suddenly the device belongs in Class C where the development process assumed Class B. Check this explicitly. The rest of the compliance assessment depends on it.
Design controls documentation
Assess the state of the design history file against the FDA's design controls requirements and IEC 62304 requirements for the declared safety class. What exists? What was created after the fact? How can you tell?
Retroactively created documentation is not inherently disqualifying, but it needs to be credibly defensible — written at a level of specificity consistent with the stage of development it purports to document. Requirements written after the code that are vague enough to apply to any implementation are not credible.
Risk management file
Assess the ISO 14971 risk management documentation. The critical question is not whether the documents exist, but whether the risk management process has visibly influenced design decisions. Are architectural controls traceable to identified hazards? Are software requirements connected to risk control measures? Is there evidence that hazard analysis shaped feature development, or does it read as a compliance exercise conducted separately from engineering?
Submission readiness gap analysis
Map the current documentation state against the FDA's Software in a Medical Device (SiMD) guidance requirements. For a 510(k) submission, identify every deliverable that is missing, incomplete, or that you assess as not credibly defensible. This becomes the input to Phase 2.
Phase 2: Triage and Remediation Strategy
The most important principle of Phase 2: scope remediation decisions before you begin executing them.
Teams that skip proper scoping jump into remediation work and discover mid-execution that what looked like a documentation task is actually an architectural one, or that a component they planned to remediate needs to be rewritten. Scoping errors that surface mid-execution compress the timeline, force rushed decisions, and often produce remediation artifacts that are themselves not credible.
Step 1: Prioritize by Regulatory Criticality, Not Technical Familiarity
The instinct of engineering teams taking over a project is to address the technical debt that is most visible or most familiar, but this isn’t always what’s best right off the bat.
Teams should prioritize based on regulatory criticality: which gaps, if left unaddressed, will generate deficiency letters or cause FDA to question the integrity of the submission? These are not always the most technically interesting problems. Sometimes the most critical gap is a traceability matrix that exists but has multiple disconnected requirements — an apparently minor documentation issue that signals to a reviewer that requirements were written after the code.
Step 2: Separate Remediation from New Development
One of the structural challenges of inheriting a mid-project is that new feature development and remediation are often in competition for the same engineering resources. This needs to be resolved explicitly, not managed ad hoc.
We recommend a dedicated remediation track, separate from feature development sprints, for the first remediation phase. This is not always commercially palatable — clients want to see forward momentum on features. But mixing compliance remediation into ongoing development sprints consistently produces incomplete remediation of the existing codebase while also accumulating new compliance debt.
Step 3: Build the Remediation Roadmap
The remediation roadmap is a sequenced plan that addresses Category C gaps first (architecture), then Category B (code-dependent documentation), then Category A (documentation-only). This sequence is not negotiable because documentation built on top of unresolved architectural issues is at best wasted effort.
Step 4: Establish a Baseline for What You Are Not Fixing
Not everything in an inherited codebase can be remediated within the constraints of the project. The discipline of Phase 2 includes explicitly deciding what you are not going to fix, and documenting that decision with rationale.
For technical debt that does not affect regulatory compliance or patient safety, documented deferral with rationale is a legitimate disposition. What you cannot do is leave compliance gaps in safety-critical components undocumented and undispositioned. Known anomalies in the safety-critical path need either resolution or a defensible written rationale for why the anomaly does not create unacceptable patient risk.
Every disposition needs to be documented. The anomaly log that goes into your submission needs to show that the team understood the issues that exist, made deliberate decisions about them, and can defend those decisions against the worst-case patient harm scenarios a reviewer will consider.
Phase 3: From Mid-Project to FDA Submission
Phase 3 is where the remediation plan meets real project delivery.
Rebuild the Compliance Infrastructure in Parallel with Development
The core discipline of Phase 3 is that from the moment remediation begins, every development activity needs to generate compliance artifacts as it happens. The window for retroactive compliance documentation is closed. Going forward, requirements come before code, risk analysis happens at sprint planning, and verification evidence is captured at the time of testing.
This is harder than it sounds on a team that did not build these habits during the original development phase. Budget time for the process change, not just the technical work.
IEC 62304 definition of done for remediation sprints:
- Requirement documented with unique ID before implementation
- Risk analysis updated for new or modified functionality
- Traceability matrix entries created at the time of coding
- Unit tests written to the requirement, not to the implementation
- Verification evidence captured at execution, not reconstructed afterward
Treat the Submission Package as a Living Document
One of the structural advantages of inheriting a project that is mid-development rather than starting from scratch is that you have a concrete picture of what the submission needs to look like from day one. Use it.
Build the submission package as a living document from the start of Phase 3. Every sprint should advance both the software and the submission documentation in tandem. When you reach submission readiness, the document should not need to be assembled, it should need to be reviewed and finalized.
This approach also surfaces submission gaps earlier. When the submission package is a living document, a missing traceability entry is visible in the next sprint review. When it is assembled at the end, missing entries surface during submission preparation at the worst possible moment.
Managing the 510(k) Review Process from a Rescue Position
If your project is pursuing 510(k) clearance, there are specific considerations that apply when the software has a complex development history.
Be transparent about the development history in the submission.
FDA reviewers are experienced enough to identify inconsistencies in documentation timelines. A submission that appears to present a seamlessly compliant development history when the actual history was more complex creates credibility problems that can extend the review process significantly. The better approach is to document the project accurately — including what changed, when it changed, and why — and to demonstrate that the process from the point of handover forward was conducted in compliance with IEC 62304 requirements.
Prepare for a more thorough software documentation review.
Projects with complex development histories tend to receive more thorough review of their software documentation than straightforward first-submissions. Prepare for it. Review your submission package specifically looking for the patterns that generate deficiency letters: vague or retroactively obvious requirements, traceability matrices with gaps in the safety-critical path, risk management documentation that reads as disconnected from design decisions.
Do not rush the anomaly review.
The anomaly review is one of the most scrutinized sections of software submissions for projects with complex development histories. Every open anomaly needs a disposition, and every disposition needs to connect explicitly to the risk management file. Rushed anomaly dispositions that use generic language — 'not safety-relevant' without connecting to a specific hazard analysis finding — are one of the most consistent sources of deficiency letters.
The Five Mistakes That Derail Medical Device Software Rescues
1. Skipping or compressing the audit.
The audit is not overhead. It is the foundation of every subsequent decision. Teams that compress Phase 1 to save time consistently make scoping errors in Phase 2 that surface as crises in Phase 3.
2. Starting remediation before completing the gap map.
Beginning remediation work before the full gap map is complete means making allocation decisions without knowing the full scope. It also creates the appearance of progress before you know whether you are working on the right things.
3. Treating documentation remediation as a writing task.
Documentation remediation in a regulated environment is an engineering task. Writing requirements documents that describe software that already exists is harder than writing requirements before the software exists — the discipline required to make those documents specific, traceable, and credibly pre-implementation is significant. Assign it to engineers who understand the system, not to technical writers who do not.
4. Attempting to continue new feature development at full velocity during remediation.
New feature development during remediation consistently produces new compliance debt. The team is not building new habits yet. The processes are not established. Reducing new feature velocity during the initial remediation phase is a defensible tradeoff — both for the quality of the remediation work and for the sustainability of the team doing it.
5. Presenting a submission that misrepresents the development history.
FDA reviewers have reviewed hundreds of submissions. Inconsistencies in documentation timelines, vague retroactive requirements, and risk management documentation with no visible connection to design decisions are recognizable patterns. Transparency about a complex development history, paired with a clear demonstration that the process improved, is a stronger submission posture than a submission that appears too clean.