Low-code apps on a GMP shop floor: qualify the platform once, assure every app by its risk

The request reached the automation team in a corridor, not through the ticket system. A process engineer on a tablet compression line had built, over two afternoons, a screen that pulled weight and hardness readings from the press, plotted them against the in-process limits and turned a tile red after three drifting values. The operators liked it. Within a month the supervisor used it to decide when to call the technician, and someone had added a field for the hourly check, because it was quicker than the paper form.

Nobody had written a line of code. Nobody had written a requirement either. When the quality reviewer later asked which version of the screen had been running during a batch with an out-of-trend result, nobody could say. On the sites we assess, this is how most low-code apps enter good manufacturing practice (GMP) territory: through usefulness, one feature at a time.

Low-code tools take the code out of sight. They do not take the logic out of scope. A GMP site can live with them comfortably on three conditions: it qualifies the platform once, it assures each app according to what that app does, and it keeps a register of the apps that exist.

What the tools promise, and what they leave to you

Screen builders in supervisory control and data acquisition (SCADA) packages, app studios in manufacturing execution systems (MES), flow editors on gateways, dashboard tools fed by the historian: all let a person who knows the process assemble an application from ready-made blocks, without a developer and often without IT.

A vendor feature in AUTOMATION’s July 2023 trends report urged end users to ask their integrators for no- or low-code solutions they can maintain themselves, and argued that testing is “both minimized and simplified” because applications are assembled from existing features. The May 2023 issue noted that implementers expect integration without writing custom code.

Half of that is true. The building blocks are tested by the platform supplier, once, for every customer. The arrangement of the blocks is yours: which tag feeds the tile, which limit turns it red, what the screen shows when the connection to the press drops. That arrangement is exactly what validation looks at. A wrong limit is wrong whether it was typed into a script or picked from a drop-down list.

No code is not the same as no logic

GAMP 5 (Good Automated Manufacturing Practice), second edition, published by ISPE, the International Society for Pharmaceutical Engineering, in July 2022, keeps the software categories of 2008: 1 for infrastructure, 3 for software used as supplied, 4 for configured products, 5 for custom software. ISPE’s own summary of the edition adds two readings that matter here: computerised systems are generally made of components from different categories, and categories 3 to 5 “should be viewed as a continuum”. The category is one factor; GxP impact, complexity and novelty scale the work.

Applied to a low-code app, that gives three layers. The operating system and database underneath are infrastructure. The platform itself is a configurable product, category 4. The app is configuration of that product as long as it only selects options and binds tags. The moment someone types an expression, a condition, a script or a custom block, that piece is custom logic. The Pharmaceutical Inspection Co-operation Scheme (PIC/S) guide PI 011-3 (2007), §15.1, says it in one line: “Manage any custom (bespoke) programming as Category 5.” A three-line formula counts.

A quick field test settles most arguments. Open the app in its editor and find every field where someone typed more than a tag name or a colour: a formula, a threshold rule, a script. Each one is reviewed like code, however short; the rest is documented as configuration. The draft revision of EU GMP Annex 11, put out for consultation on 7 July 2025, asks the same in §6.6: configuration documented in a controlled configuration specification.

What the FDA’s software assurance guidance adds

On 24 September 2025 the US Food and Drug Administration (FDA) issued its final guidance Computer Software Assurance for Production and Quality System Software, three years after the draft. It is written for medical device manufacturers, under 21 CFR 820.70(i), and a drug manufacturer is not bound by it. It remains the clearest statement of how the FDA thinks about proportionate assurance, and GAMP 5’s second edition discusses the approach.

The guidance works in four steps: the intended use of each feature, function or operation; whether its failure poses a high process risk; assurance activities to match; a record. Collecting process data for monitoring, managing data, automating an existing calculation or raising alerts are generally not high process risk. Maintaining process parameters, or judging product acceptable with limited or no human review, generally is.

For features that are not high process risk the guidance names unscripted methods: scenario testing, error-guessing, exploratory testing. For high process risk it points to scripted testing or a hybrid. The record keeps the intended use, the risk result, what was tested, the issues, a conclusion, who and when, and the FDA prefers system logs and audit trails to screenshots.

One example in the guidance should hang above the desk of anyone who governs these apps. A spreadsheet that documents time and temperature readings is low risk; installation and a vendor assessment may be enough. The same spreadsheet with a custom formula computing statistics to monitor the process may need more validation. Replace “spreadsheet” with “dashboard” and nothing else changes.

On a drug site, translate the device anchor into Annex 11 §1 terms: patient safety, data integrity and product quality. The US drug rule underneath, 21 CFR 211.68(b), wants changes to records made only by authorised personnel and input and output checked for accuracy.

The European texts are stricter on evidence

EU GMP Annex 11, in operation since 30 June 2011, already asks for most of what a low-code programme needs: risk-based validation (§1), an inventory of systems (§4.3), evidence of test methods and scenarios (§4.7), audit trails (§9), controlled change including configuration (§10) and the identity of whoever changes data, with date and time (§12.4).

The draft revision pulls the other way from the FDA on evidence. Its §9.4 expects “executed test scripts, and where relevant, screen dumps”, and §9.5 rejects test cases that are not traceable to requirements. The consultation closes on 7 October 2025 and the text may change. A site that answers to both sides of the Atlantic should not read the FDA guidance as permission to stop writing things down.

The workable middle is a test charter. For a low-risk app, the tester writes three lines before starting (what will be explored, against which intended-use statement, for how long), then records what was tried, what failed and the conclusion. That is unscripted testing with a trace to a requirement. Depth follows risk, as in how deep a qualification test should go.

Qualify the platform once

What the apps share is proven once, on the platform: supplier assessment (Annex 11 §3.2, §4.5), installation and configuration, user roles, the audit trail engine, versioning and export of app definitions, connectors, backup and restore (§7.2), and a test environment separate from production. Much of it can come from the supplier once someone has assessed it; what the supplier’s tests can prove for you applies unchanged.

Platform qualification does not validate the apps. The UK Medicines and Healthcare products Regulatory Agency (MHRA) put it plainly in its data integrity guidance of March 2018, §6.19: accepting vendor-supplied validation data “in isolation of system configuration and users intended use is not acceptable”. Whether a given app is fit for its job is asked app by app.

Assure each app by what it does

The tier comes from the function, never from the tool. Four tiers cover almost every app we see on production floors.

Most apps sit in tiers 1 and 2, where the proportionate approach pays: a tier 1 dashboard can go live in days with a page of evidence. Tier 3 deserves a pause. An app that releases material or writes setpoints is usually doing a job that belongs to the MES or the control system, and why MES projects stall at the shop floor interface is often the real problem to solve.

Tiers move. The compression-line screen of the opening started at tier 1 and became tier 2 the day someone added an input field for the hourly check. Under Annex 11 §10 that is a change, and every change should ask whether the tier holds.

Versions and audit trails are the platform’s job

An inspector asks two questions of any app: which version was running on a given date, and who changed what. A platform that cannot answer both should not host GMP apps. That means app definitions versioned and exportable as files that can be compared, and an audit trail that separates changes to the app from changes to its data. Where versions cannot be compared, export the definition at each release and keep the file under document control.

Who holds the keys matters as much. The MHRA guidance, §6.16, keeps system administrator rights, configuration changes included, away from people with a direct interest in the data. The engineer who builds an app for his own line should not also promote it to production. The draft Annex 11, §14.2, wants periodic reviews to find undocumented changes, for example by configuration auditing: compare what runs with the last released export. And an app that captures a reading keeps the metadata that makes the number mean something.

A promotion path that keeps the idea alive

The sandbox stays open, because that is where the ideas come from. The obligation starts when an app is about to touch GMP data or influence a GMP decision. It then enters the register with a named owner, a one-paragraph intended use and a tier agreed with quality: fifteen minutes when the tiers are written down, an afternoon of debate when they are not.

The register is not an invention. Annex 11 §4.3 asks for an inventory of systems, and PI 011-3 §6.3 lists what it holds: ownership, supplier or developer, functionality, links and validation status. Each released app is one more line, and its builders are trained on the procedure as well as the tool (Annex 11 §2).

Five common mistakes

1. “The platform is validated, so the apps are.” Platform qualification proves the building blocks; the MHRA guidance, §6.19, rules out stopping there.
2. Classifying by tool. The same studio produces a tier 1 display and a tier 3 release gate. The function decides the tier.
3. Missing the tier creep. An input field, a new calculation or a write-back moves an app up a tier. Without a trigger in change control nobody notices.
4. Building in production. Without a separate test environment, every edit is tested on live data, and the audit trail mixes trials with records.
5. Reading the FDA guidance as “no evidence needed”. Its record list applies, and the European draft asks for more, not less.

Where to start

1. Count. In one week, list every low-code app that reads or writes GMP data, with a named owner. The list will be incomplete; it is done when quality has seen it.
2. Tier the ten most used. Ask four questions of each: does it only display, does it record, does it calculate, does it act. The first yes from the bottom sets the tier.
3. Run one tier 2 app through a two-page promotion procedure. It is done when you can say, for that app, which version was running on any date quality picks, and who released it.

An inspector asks a low-code app the same three things as any other system: what it does, which version ran, and who decided it was fit. Building it in an afternoon only means the answers have to be ready sooner.

References

• US FDA, Computer Software Assurance for Production and Quality System Software, final guidance, 24 September 2025: notice of availability, federalregister.gov.
• ISPE, *GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems*, Second Edition, July 2022.
• S. Wyn and C. Clark, “What You Need to Know About GAMP 5 Guide, 2nd Edition”, Pharmaceutical Engineering (ISPE), January–February 2023.
• EudraLex Volume 4, EU GMP Annex 11, Computerised Systems, in operation since 30 June 2011: §1, §2, §3.2, §4.3, §4.5, §4.7, §7.2, §9, §10, §12.4.
• European Commission, draft revision of Annex 11, stakeholder consultation opened 7 July 2025: §6.6, §9.4, §9.5, §14.2.
• PIC/S, PI 011-3, Good Practices for Computerised Systems in Regulated “GxP” Environments, 25 September 2007: §6.3, §15.1.
• MHRA, *GXP Data Integrity Guidance and Definitions*, Revision 1, March 2018: §6.16, §6.19.
• US Code of Federal Regulations, 21 CFR 211.68, automatic, mechanical and electronic equipment.
• AUTOMATION 2023: 8th Annual Industrial Automation and Control Trends Report, automation.com, July 2023: feature on no/low-code SCADA (the trade item this article starts from).
• AUTOMATION 2023: IIoT & Industry 4.0, automation.com, May 2023: feature “Unlocking Value in the Digital Era”.