When Your Ops System Became a Validated System

A manufacturer customer kicked off a formal QMS validation of Deviceflow this month. Pulling the package together was an extension of our existing quality story, not a new program — testing, traceability, and access controls have been part of how we build software since the beginning. The QMSR-specific work was about formalizing what we already do for an auditor’s eyes, not building it from scratch.

Their quality team came back from the QMSR transition and said the quiet part out loud: the software handling charge sheets, consignment, and order-to-cash now sits inside the audit scope, and inspectors are going to ask for documented validation.

Ops teams across the industry have been having that conversation for ten months. Most still haven’t caught up.

Three things changed

The regulatory picture around operations software shifted three times in under a year:

July 2025 — ISPE published the GAMP AI Guide, 290 pages specifically about how to validate software with AI and machine-learning components. It didn’t invent a new rule. It told everyone that GAMP 5’s existing risk-based framework already applied to AI-driven systems, and it showed what the documentation trail needs to look like.

September 2025 — FDA finalized Computer Software Assurance. The CSA guidance had been in draft since 2022. The final version explicitly covered AI and machine-learning tools used in production and quality systems. That’s the regulatory anchor pulling operations software into the same validated-system conversation that QMS software has been in since 1996.

February 2, 2026 — QSR became QMSR. FDA harmonized 21 CFR Part 820 with ISO 13485:2016. Same underlying obligations for production and service software, but delivered through a broader set of requirements — design transfer, outsourced activities, risk-based processes, and critically, the expectation that everything from design through post-market connects as one system.

None of these made operations software regulated for the first time. Section 820.70(i) has required validation of software used as part of production or the quality system since the original QSR in 1996. What changed is scope and scrutiny. The inspection surface widened, and the inspectors got better tools to walk it.

The QMSR expansions most ops teams missed

The software validation story gets most of the attention. But the expansions underneath it are tripping companies up faster.

The QMS is now one connected system. Under QSR, a lot of manufacturers ran design controls somewhat separately from quality operations — different teams, different systems, different document repositories. QMSR treats all of it as one system and expects to see the connection. Engineering changes link to risk files, risk files link to CAPA, CAPA links to complaints, complaints link back to design. Inspectors will trace one change all the way through the chain. The companies struggling most are running separate systems for PLM and QMS with no good link between them.

Management review has teeth. ISO 13485 Clause 5.6 says leadership has to review the quality system on a defined cadence, using defined inputs, and take documented action. QMSR pulled that in. A quick quarterly sign-off won’t hold up. Inspectors want to see leadership actually working the quality decisions — which trends they’re watching, which risks they’re escalating, which actions they actually closed.

Outsourced activities come inside your QMS. If contract manufacturers or contract labs touch design-related or production work, your QMS has to cover those relationships explicitly. Quality agreements, audit rights, documented oversight. ISO 13485 Clause 7.4 on purchasing kicks in here — and it’s new ground for some teams.

Audit access reaches into operations systems. This is the one that connects straight to the software question. Inspectors can now ask for access to the systems producing the records — not just the records themselves. That means role-based access control, approval workflows, tamper-evident audit trails, exportable logs. The Part 11 and Annex 11 bar that used to live with QMS software now applies to any operations system inside the scope — order processing, charge sheet capture, consignment tracking, anything touching a record that contributes to device release or post-market obligations.

The last one matters most for operations. A PO entry tool that nobody outside the ops team ever looked at now carries the same access, trail, and retention expectations as the CAPA system.

The vibe-coded ops system is a Category 5 system

Here’s where the regulatory picture meets a specific engineering decision a lot of companies are about to make, or have already made.

GAMP 5 classifies software by risk to product quality and patient safety. Category 1 is infrastructure. Category 3 is non-configured commercial software. Category 4 is configured commercial software. Category 5 is custom-developed software, and it carries the highest validation burden by a wide margin — typically 50 to 100 percent more effort than a comparable Category 4 system.

Category 5 covers in-house custom code, outsourced bespoke applications, and significantly modified open-source frameworks. It doesn’t matter what language it’s in, what framework it uses, or how fast you shipped it. The moment you build it yourself for your specific process, it’s Category 5.

That includes the “quick tool we built in-house.” That includes the AI-assisted prototype your ops team stitched together over a weekend. That includes the Airtable base with custom scripts that runs half the order desk. If you built it, if it touches records that contribute to production or quality, and if it falls inside the scope QMSR just widened — it’s a Category 5 validated system.

The validation package looks about like you’d expect from the highest category: user requirements, functional and design specs, full IQ/OQ/PQ test coverage, traceability matrices, change control, training records, release notes, data integrity and access controls to Part 11 grade, and documented vendor oversight. If you built the system, you’re the vendor — for your own system. The regulatory framework doesn’t split “internal developer” from “external vendor.” You carry both sides of the obligation.

That’s the uncomfortable part of the “just vibe-code it” instinct. A prototype that took a week creates a documentation and lifecycle debt that takes months to retire — and you have to work that debt down before the system can legitimately operate in regulatory scope.

What we’re doing about it

The customer validation we kicked off this month runs the full path: URS signed by their ops and quality leads, functional specs against our charge sheet, consignment, and order-to-cash modules, a risk assessment scoped to their process, IQ/OQ/PQ test protocols, a traceability matrix back to their requirements, and a vendor audit of us as the software provider. Access controls, role-based permissions, and audit-trail exports sit inside the package because QMSR assumes they’ll be there.

The reason that work moves quickly is that we built validation into our software development lifecycle, not bolted on after. Every release runs the full test suite — URS coverage, role-based access checks, data integrity, Part 11 audit trail verification — and produces a validation packet stamped with the release date and the version identifier that produced it. Test videos. Screenshots. Captured emails per test. Audit logs per test. The packet ships with the release, not after the customer asks for it.

The infrastructure side runs in the same posture. Customer-data infrastructure: read replicas, multi-AZ failover, documented backup policy. The data we hold for our customers stays available even if we don’t.

We hold the line at GAMP Category 4. Customers configure us — they don’t customize us into Category 5 territory. That decision is deliberate, and it’s the most important architectural choice we’ve made for this regulatory environment. A commercial vendor carrying the vendor-side burden — design controls, verification, release management, vendor audits — lands in a very different category than the same functionality built in-house. Category 4 when we provide it and you configure it. Category 5 when you build the same thing yourself, with all the documentation weight that implies.

Customers running their own validation cycles get one more piece of leverage: feature flags. New capabilities ship when we ship, but activation for a given customer waits for that customer’s own validation work to close. The release cadence stays fast on our side. The activation cadence respects the audit posture on theirs.

Neither path is wrong. The cost profile is different, the reversibility is different, and the risk ownership lives in different places. Teams making this call in the next twelve months should see the full picture before they commit.

What to do on Monday

If you run operations at a medical device manufacturer, three things to do this week.

First, list every piece of software that touches a production record, a case, a lot number, a consignment location, or a customer order. Include the spreadsheets, the in-house tools, and the AI prototypes — especially the AI prototypes. That list is the scope of what QMSR just pulled into audit range.

Second, for each one, ask who built it and who validates it. Commercial system with vendor-provided design controls and IQ/OQ? Category 3 or 4, and the vendor carries most of the lifecycle burden. Built in-house, configured by someone who left, or generated with a coding assistant? Category 5, and your quality team owns the full validation package.

Third, ask the access-provisions question most ops teams never had to answer. Can you show role-based access, approval workflows, and tamper-evident audit trails for every system on the list? If the honest answer is “not yet, but we could,” that’s the work. If the honest answer is “no, and we can’t get there on this platform,” that’s a build-vs-buy decision hiding in plain sight.

The inspection pressure isn’t coming from a hostile place. It’s coming from the fact that the quality system is finally one system, and the operations layer is finally inside it.