Hattrick IT

A question for engineering leads and founders building medical device software: At what stage does your team introduce formal ISO 14971 risk management? ➡️ Before architecture is designed ➡️During development (as features are built) ➡️ In a pre-submission sprint ➡️ We haven't formalized it yet — The answer predicts a lot. Teams that introduce risk management before architecture tend to build isolation between safety-critical and non-critical components naturally. Teams that introduce it during development retrofit it — which works, but generates traceability gaps that take weeks to close. Teams that do it pre-submission are writing history, not managing risk. We're curious to konw where teams land on this! #MedTech #ISO14971 #IEC62304 #MedicalDeviceSoftware #RegulatoryAffairs

Unpopular opinion: choosing your 510(k) predicate isn't a regulatory task. It's a product strategy decision. And most founders hand it off to the wrong person. Here's what your predicate actually determines: → Feature ceiling Your device needs to be substantially equivalent to the predicate. Features that diverge significantly require a different pathway or a stronger argument. Your predicate sets the ceiling before your product team even starts roadmapping. → Software safety class The predicate's intended use shapes your risk profile. A predicate with Class B software doesn't automatically make yours Class B — but it anchors the analysis. → Testing standard What the predicate used for V&V becomes the de facto benchmark for what FDA expects from you. → Architecture constraints If your predicate was a standalone device and yours connects to a network, you're not just adding a feature. You're changing the risk profile. That change starts in architecture, not documentation. The teams that choose predicates well treat it like a technical decision: they map predicate features to their intended architecture before committing. Your predicate is not just what you compare to in your submission. It's the lens FDA will use to evaluate every decision you made. Choose it early. Choose it deliberately. Own it as a founder. #510k #FDAClearance #MedTech #SaMD #MedicalDevices

Most FDA software review problems don't start at submission. They start months earlier. A stale Software Development Plan. Requirements written after the code. Safety classifications applied at the system level instead of the software item level. Test evidence that exists but can't be traced. By the time a team is preparing a 510(k), the real issue is often that the development process never generated the evidence regulators expect to see. That's why IEC 62304 Clause 5 matters. It's not a documentation exercise. It's the framework that determines whether your development process naturally produces submission-ready evidence—or leaves you scrambling to reconstruct it later. In our latest article, we break down all eight Clause 5 sub-processes, the most common mistakes we see medtech teams make, and the practices that consistently hold up during FDA review. What's the biggest IEC 62304 challenge you've encountered: requirements, traceability, testing, or risk management? https://lnkd.in/ei2ssiD6

How to structure your IEC 62304 software development plan before sprint 1

Software maintenance under IEC 62304 §6 Most engineers reading IEC 62304 stop at clause 5 — the development process. That's where the framework is exciting. Architecture. Verification. Traceability. Clause 6 is where the framework gets uncomfortable. §6 is the 𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐦𝐚𝐢𝐧𝐭𝐞𝐧𝐚𝐧𝐜𝐞 𝐩𝐫𝐨𝐜𝐞𝐬𝐬, and it's the part of 62304 that bites teams hardest post-clearance — because it's the part that turns every git commit into a regulated event. Here's what §6 actually requires, in engineer terms: 𝟔.𝟏 — 𝐄𝐬𝐭𝐚𝐛𝐥𝐢𝐬𝐡 𝐚 𝐦𝐚𝐢𝐧𝐭𝐞𝐧𝐚𝐧𝐜𝐞 𝐩𝐥𝐚𝐧. Before you ship, you need a documented plan for how you'll handle problem reports, modifications, and releases throughout the product lifecycle. Most teams write this once and never look at it again. Auditors will look at it. 𝟔.𝟐 — 𝐏𝐫𝐨𝐛𝐥𝐞𝐦 𝐚𝐧𝐝 𝐦𝐨𝐝𝐢𝐟𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐚𝐧𝐚𝐥𝐲𝐬𝐢𝐬. Every reported problem (internal bug, customer complaint, CVE in a dependency, regulatory change) gets formally analyzed. Is it a defect? A risk? Does it require a corrective action? Does it require an MDR? Does it require an FDA notification? This is not "JIRA triage." This is a documented evaluation with traceable outputs. 𝟔.𝟑 — 𝐌𝐨𝐝𝐢𝐟𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐢𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧. If you decide to change the software, you re-enter the development process from the appropriate point. A change to a Class C component may require you to redo unit tests, integration tests, system tests, and risk analysis. The implication: your CI/CD has to be designed to generate the evidence, not just run the tests. What this means in practice: → Your bug tracker is a regulatory artifact. Treat it like one.  → "Just patching dependencies" is not a thing. Every dependency update flows through §6.2.  → Your branching strategy needs to support reproducible, traceable maintenance releases.  → Your release notes are technical documentation that auditors will read.  → You need a documented criterion for when a maintenance change becomes a significant change requiring an FDA notification — and that criterion needs to exist before you need to apply it. The teams that ship updates smoothly post-clearance have one thing in common: they designed for §6 during development. The teams that struggle treated maintenance as an ops problem and discovered, around month 4, that it's a regulatory one. Clause 5 gets the attention. Clause 6 is where your second year lives. What's your team's approach? Is §6 part of your dev process, or has it been parked as a problem for later?

We're halfway through 2026. Time for an honest read on what's actually changed for medical device software teams, and what hasn't. 𝐖𝐡𝐚𝐭 𝐜𝐡𝐚𝐧𝐠𝐞𝐝: ✅ 𝐐𝐌𝐒𝐑 𝐢𝐬 𝐥𝐢𝐯𝐞. As of February 2, 2026, the FDA's Quality System Regulation is officially aligned with ISO 13485:2016. Teams operating under mature ISO 13485 QMSs barely felt it. Teams that built U.S.-only QSR systems are mid-transition. If you haven't mapped your existing QMS to the new structure yet, you're behind. ✅ 𝐏𝐂𝐂𝐏 𝐠𝐮𝐢𝐝𝐚𝐧𝐜𝐞 𝐢𝐬 𝐟𝐢𝐧𝐚𝐥 for AI-enabled device software functions. This is the most important regulatory development in years for AI/ML medtech. The framework is now real, the international principles are aligned (FDA + Health Canada + MHRA), and the teams who understand it are building submissions that will move materially faster post-clearance. ✅ 𝐀𝐈-𝐞𝐧𝐚𝐛𝐥𝐞𝐝 𝐝𝐞𝐯𝐢𝐜𝐞 𝐚𝐮𝐭𝐡𝐨𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧𝐬 𝐜𝐫𝐨𝐬𝐬𝐞𝐝 𝟏,𝟑𝟓𝟎. Roughly double where the number was in 2022. The FDA has cleared more AI devices in the last 18 months than in the previous five years combined. The pipeline is real, and the regulatory framework is mostly catching up. 𝐖𝐡𝐚𝐭 𝐝𝐢𝐝𝐧'𝐭 𝐜𝐡𝐚𝐧𝐠𝐞: ❌ Most early-stage teams still underestimate IEC 62304 documentation depth by 50%+  ❌ "We'll figure out FDA later" still kills more medtech startups than running out of money 𝐖𝐡𝐚𝐭 𝐭𝐨 𝐝𝐨 𝐢𝐧 𝐇𝟐: If you have a device in development:  → Lock your software safety classification (don't assume Class A)  → Decide whether your roadmap needs a PCCP — and start writing the protocol if it does  → Stress-test your post-market plan before submission, not after If you're already cleared:  → Audit your QMS against QMSR  → Validate your post-market surveillance is actually generating usable data  → Review your change-control SOP for when a patch crosses the "new submission" line #MedTech #FDA #QMSR #PCCP #SaMD #MedicalDevices #DigitalHealth

📊 Quick poll for medical device teams: Most of the medtech conversation focuses on getting to clearance. We've been writing this month about what happens after. No wrong answer — wherever you are, you're not alone.

Hot take on PCCP PCCPs are not a license to "move fast." The way PCCPs get talked about lately, you'd think the FDA just legalized continuous deployment for AI devices. The marketing version sounds like: "Submit once, update forever." The reality is closer to the opposite. A real PCCP is disciplined upfront work. You're not avoiding regulatory work — you're front-loading it. Aggressively. You're committing, in writing, to:  → The exact modifications you'll make over the device's lifetime  → The exact methodology you'll use to validate each one  → The exact performance acceptance criteria  → The exact data infrastructure you'll need to generate evidence PCCP doesn't reward speed. It rewards foresight. The hardest part of a PCCP isn't writing the document. It's accurately predicting, today, what your AI device will need to become two years from now, and committing to validate every step of that path with the rigor of a fresh submission. What's been your experience with PCCPs so far — game-changer or paper tiger?

𝐅𝐃𝐀 𝐂𝐥𝐞𝐚𝐫𝐚𝐧𝐜𝐞 𝐂𝐡𝐚𝐧𝐠𝐞𝐬 𝐖𝐡𝐚𝐭 𝐘𝐨𝐮𝐫 𝐂𝐨𝐝𝐞𝐛𝐚𝐬𝐞 𝐍𝐞𝐞𝐝𝐬 𝐭𝐨 𝐃𝐨 Before clearance, the technical goal is building to specification and generating verification evidence. After clearance, the goal changes: maintaining compliance as the software evolves. These require different things from your architecture — and most teams don't design for the post-clearance state until they're already in it. Three things that become significantly harder to manage post-clearance if you didn't plan for them: 𝐂𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭-𝐥𝐞𝐯𝐞𝐥 𝐜𝐡𝐚𝐧𝐠𝐞 𝐢𝐦𝐩𝐚𝐜𝐭 𝐚𝐬𝐬𝐞𝐬𝐬𝐦𝐞𝐧𝐭 When a developer changes a function in a safety-critical module, someone needs to determine: does this require re-verification? Does it require a new 510(k)? If your architecture documentation isn't current, if your traceability matrix hasn't been maintained, and if your component boundaries aren't clearly defined — that assessment becomes unreliable. You're making regulatory judgments about code whose compliance scope you don't fully understand. 𝐑𝐞𝐠𝐫𝐞𝐬𝐬𝐢𝐨𝐧 𝐭𝐞𝐬𝐭𝐢𝐧𝐠 𝐮𝐧𝐝𝐞𝐫 𝐜𝐡𝐚𝐧𝐠𝐞 𝐜𝐨𝐧𝐭𝐫𝐨𝐥 Every significant post-clearance change that touches verified functionality should trigger regression testing and an update to your verification records. If your test suite wasn't built to run incrementally against specific requirement IDs, post-market regression testing defaults to a full re-execution. That creates real pressure to skip it. Teams under commercial delivery pressure after clearance will find reasons to defer re-verification. The test infrastructure you built during development is the thing that makes doing it right tractable. 𝐕𝐞𝐫𝐬𝐢𝐨𝐧 𝐜𝐨𝐧𝐭𝐫𝐨𝐥 𝐚𝐬 𝐩𝐚𝐫𝐭 𝐨𝐟 𝐭𝐡𝐞 𝐜𝐨𝐦𝐩𝐥𝐢𝐚𝐧𝐜𝐞 𝐫𝐞𝐜𝐨𝐫𝐝 Your commit history, branching strategy, and release tagging are part of the technical substrate of your change management process post-clearance. "We made a fix in v2.1.3" needs to trace to a documented change request, a risk impact assessment, and updated verification records. This isn't a process you retrofit onto existing development practices. It's a convention you establish at the start of the project and maintain throughout. It should be part of the regulatory strategy and requieres constant communication between RA and QA. The architecture decisions you make in sprint 1 are the ones you manage under change control in year 2. #IEC62304 #MedicalDeviceSoftware #MedTech #SoftwareEngineering #FDA #PostMarketSurveillance