The honest answer to whether your quality system is ready for the FDA's new Quality Management System Regulation is sitting in your supplier certificates of analysis, not in your validation scripts. Computer Software Assurance under QMSR is being talked about as if it were a tooling problem. It is a data hygiene problem wearing a tooling costume.
Here is the hot take from a contract manufacturer's floor: the bottleneck for CMA readiness is not your mapper, your test runner, or your assurance case template. It is whether the values entering your system are structured, traceable, and defended at the point of capture. If they are not, no amount of script cleverness downstream will save you when an auditor walks in and asks why two records of the same batch disagree by a factor of three.
What CMA actually changes
The FDA's draft guidance on Computer Software Assurance, now widely cited alongside the harmonised QMSR, makes one ask of regulated software users: produce a risk-based, critically reasoned assurance record for the tools that touch product quality. Less scripted test theatre, more documented judgement about what could go wrong, what would happen if it did, and what evidence is sufficient.
For an OEM that builds its own software, this is largely an internal exercise. For a CMO like ours, with forty-plus material and component suppliers feeding into inspection, kitting, and assembly, CMA readiness is an exercise in contract and supplier data discipline. The script we run against a COA is the easy part. Getting the COA into a shape that the script can trust is the work.
What I have actually seen go wrong
Three patterns repeat on our floor:
- Free-text lot numbers from suppliers that do not match the purchase order line. They look identical to a human, fail a join downstream, and force a manual reconciliation that is hard to defend retrospectively.
- COAs delivered as scanned PDFs with no embedded text. The values are visible. They are not extractable. They are not in the audit trail. They exist, in regulatory terms, only as paper.
- Measurement results reported to one decimal when the method specifies three. The rounding was done at the supplier, not at the instrument. We inherited an opinion, not a measurement.
Each of these is a data quality failure. Each one would survive a beautifully written assurance case, because the assurance case describes the software that processes the value. It says nothing about whether the value is real.
Where the mapper cannot help
A good mapper will reconcile field names, units, and code lists. It will not fix a lot number that was transcribed by hand at a supplier's desk. It will not recover a digit that was rounded at the bench. It will not make a scanned PDF auditable.
I have watched teams spend weeks polishing a mapping layer between an incoming inspection register and an ERP, then discover that the real source of disagreement was upstream of the mapper entirely. The mapper made the problem visible. It did not cause it. Fixing the mapper did not fix the problem.
This is the part of CMA that the gadget conversation tends to skip: the assurance argument you owe a notified body or an FDA investigator runs through your data, not past it. If your incoming data is dirty, your assurance case is decoration.
What clean inputs actually look like
In practice, for a CMO with our supplier spread, the discipline that mattered was unglamorous:
- Supplier COAs arrive in a controlled template with named fields, not free-text cells. We agreed the template in the supplier quality agreement and refused PDFs that did not conform.
- Lot identifiers come from the purchase order and are echoed back by the supplier without manual re-keying. The PO line is the canonical reference.
- Decimal precision is specified by test method, and the system flags values that arrive under-spec rather than silently rounding.
- Every value carries a method reference, a calibration reference, and an analyst identifier. If any of the three is missing, the record is incomplete by design, not by policy alone.
None of this is novel. All of it is the work that has to happen before any CMA argument carries weight.
What I would do differently if I were starting now
I would push the data quality conversation into the supplier audit checklist rather than treating it as an internal IT problem. I would make the supplier quality agreement the place where field-level expectations are written, not the place where they are gestured at. I would treat a non-conforming COA as a supplier non-conformance, not as an internal data entry exception.
And I would stop writing assurance cases against software that handles values I cannot defend. The script will not save you. The data will.
A practical sequence for CMOs approaching QMSR
If you are a CMO trying to think about CMA readiness against QMSR honestly, the sequence I would suggest is:
- Audit three months of incoming inspection records. Count the manual reconciliations. That count is your data quality problem, expressed in hours.
- For each top cause, ask whether the failure originated at the supplier or downstream. The answer drives whether your fix is contractual or technical.
- For each supplier-side cause, raise it as a supplier non-conformance with a CAPA expectation. The supplier sees it first; the CMO inherits it second. Treat it accordingly.
- Only then, with the input side under some control, write the assurance case for the software that processes the data. The case will be shorter, clearer, and far easier to defend.
The honest test
The question I now ask when someone tells me their CMA approach is ready is simple: show me the last supplier non-conformance you raised about data format. If the answer is none, or if the answer is "we fixed it on our side," the assurance case is built on sand. The mapper will not save you. The discipline upstream will.
How does your team separate data quality work from software assurance work in practice? I am curious whether the split is as clean for you as it has had to become for us.
Top comments (0)