Teams building their first connected medical device often treat regulatory work as a downstream step — something for the quality department to handle once the product mostly works. That ordering causes real problems. Regulatory frameworks for medical device software don't just ask "does it work," they ask "can you prove, with a documented process, that you built it deliberately and can trace every requirement to a verified implementation." That requirement changes how the software gets built, not just what gets filed at the end. This isn't legal or regulatory advice — it's a description of the structural realities an engineering team should expect to plan around, and every specific requirement needs to be worked through with regulatory and quality counsel who know the applicable jurisdiction and device classification.
A documented software development lifecycle isn't optional
IEC 62304 is the internationally recognized standard governing the software development lifecycle for medical device software — it defines process expectations around planning, requirements, architecture, implementation, verification, and maintenance, with the rigor scaled to the safety classification of the software. The practical implication for an engineering team is that "we built it and it works" isn't sufficient; the process by which it was built has to be documented and traceable. Retrofitting that documentation onto an already-built codebase is far more expensive than establishing the practice from the first commit — requirements need to be written down and linked to design decisions, design decisions linked to code, and code linked to verification evidence, as the project proceeds rather than reconstructed after the fact.
Risk management runs alongside development, not after it
ISO 14971 is the standard most commonly referenced for medical device risk management — the general discipline of identifying hazards a device could contribute to, estimating and evaluating the associated risk, and implementing and verifying risk controls. For a connected device, this expands beyond the mechanical or electrical failure modes a traditional device team might already know well: it also has to account for firmware bugs, connectivity loss, cloud-side outages, and cybersecurity threats, since any of those can translate into a patient-facing hazard. Risk management, done properly, isn't a document produced at the end of a project — it's a living analysis that informs architecture decisions (redundancy, fail-safe behavior, alerting) as they're being made.
Why regulatory strategy has to precede architecture
The classification a device is expected to receive, and the regulatory pathway that classification implies, changes fundamental architecture questions: what has to run with deterministic, verifiable behavior versus what can be more flexible; where the boundary sits between the regulated device and unregulated accessory software (a mobile app, a cloud dashboard); how much of the AI/ML components, if any, needs to be locked at submission versus designed for controlled updates. Deciding these questions after the architecture is already built usually means rearchitecting, not adjusting. Getting a rough regulatory strategy in place — even informally, well before a formal submission is being prepared — gives engineering the constraints it needs to make good decisions the first time.
Practical takeaway
None of this replaces a regulatory and quality function with real expertise in the applicable jurisdiction and device class — that expertise has to be involved early, not brought in to review a finished product. What an engineering team can control is building with the discipline these frameworks expect from the outset: traceable requirements, documented design rationale, and risk analysis that actually shapes the architecture. We build firmware and embedded systems with that discipline in mind from day one — see our firmware work and embedded hardware work for how this fits into a full engagement.