LIMS Master Data Under Change Control: Keeping Specifications, Methods, and Units in Step

Why LIMS Master Data Drifts From the Approved Record

A laboratory information management system (LIMS) is the software a QC lab uses to register samples, assign tests, capture results, compare them with acceptance criteria, and produce the records that support batch disposition. To do that, it holds a set of reference records that most users never see directly. These records are the LIMS master data: product and material codes, specifications and their limits, test methods and their versions, calculations, units of measure, sampling plans, stability protocols, and the links among them.

Master data is different from result data. A result belongs to one sample. A specification record in LIMS is applied to every sample of that product until someone changes it. That makes it one of the most consequential records in the whole quality system: one error repeats on every batch until someone finds it.

One Specification, Three Copies

In most regulated companies, the same specification exists in at least three places. There is the specification as filed with regulators, in the application or marketing authorization. There is the internal controlled document, approved through the document management system and signed by the quality unit. And there is the LIMS configuration that the lab uses day to day. Some companies add a fourth copy in the ERP system, which uses material codes and units to manage inventory status, and a fifth in a manufacturing execution system that holds in-process limits.

The copies do not update each other. When the controlled document changes, a person has to open the LIMS configuration screens and rebuild the specification: new version, new limits, new effective date, new links to methods and products. That manual step is where drift starts. The document management system knows the new version is effective. The LIMS knows only what someone typed.

Why Change Control Misses It

Most change control records are written around documents. The change request names the specification number, the old and new revision, the justification, the impact assessment, and the approvals. The action list often includes a line such as “update LIMS.” That line is where the evidence usually stops. It gets closed with a note that the update was made, sometimes with a screenshot, rarely with a field-by-field comparison against the approved document.

A 2025 post on ISPE’s Pharmaceutical Engineering blog, written by a LIMS vendor’s strategy lead, described lab master data as data “which must be kept perfectly in sync, a difficult activity in an environment constantly executing change control.”¹ The same post noted that keeping master data across several separate systems can disrupt integration and weaken data integrity. That matches what practitioners see. Specifications change often, for good reasons: new impurity limits, a method update, a compendial revision, a new site, a new pack size. Each change is a chance for the configured record and the approved record to part ways.

What Drift Looks Like in Practice

Drift is rarely dramatic. It looks like a limit of NMT 0.15% in the approved document and NMT 0.2% in LIMS, because someone entered one decimal place fewer. It looks like a new impurity test added to the specification but missing from the LIMS test list, so analysts never get asked to run it. It looks like a stability protocol still pointing to the retired specification version eighteen months after the release specification changed. None of these trips an alarm. The system does exactly what it was configured to do.

What Regulators Expect When a Specification Changes

No regulation uses the phrase “LIMS master data.” The expectations still apply to it directly, because regulators care about the specification the lab uses, not only the one stored in the document system. It helps to separate the expectations into four layers: who approves specification changes, what “conformance” means, when a change needs a regulatory filing, and how computerized systems must handle changes and manual entry.

The Quality Unit Approves Every Specification Change

In the United States, 21 CFR 211.160(a) is direct on this point. It states that the establishment of any specifications, standards, sampling plans, test procedures, or other laboratory control mechanisms, “including any change in such specifications, standards, sampling plans, test procedures, or other laboratory control mechanisms, shall be drafted by the appropriate organizational unit and reviewed and approved by the quality control unit.”² The regulation does not say “the document containing the specification.” If the LIMS record is the specification the lab tests against, then a change to that record is a change to a laboratory control mechanism. A limit edited in LIMS without quality unit approval is an unapproved specification change, even when the paper version is correct.

The release requirement follows from this. Under 21 CFR 211.165(a), each batch needs “appropriate laboratory determination of satisfactory conformance to final specifications for the drug product” before release.³ If LIMS compares results with the wrong limits, the lab has not shown conformance to final specifications. It has shown conformance to something else.

What a Specification Contains

ICH Q6A gives the definition most regulators use. A specification is “a list of tests, references to analytical procedures, and appropriate acceptance criteria, which are numerical limits, ranges, or other criteria for the tests described.”⁴ Q6A also states that specifications are critical quality standards that are proposed and justified by the manufacturer and approved by regulatory authorities as conditions of approval.

That definition matters for master data design. A specification is not only a set of numbers. It is three linked things: the test, the procedure reference, and the acceptance criterion. A LIMS record that has the right limit but points to the wrong method version is still a wrong specification. So is a record with the right method and limit but a test missing from the list.

When the Change Needs a Filing

For approved products, many specification changes also need a regulatory submission before they can be used. Under 21 CFR 314.70(b)(2)(i), changes in the specifications provided in the approved NDA are listed among the major changes that require a supplement and FDA approval before distribution, except for those described in paragraphs (c) and (d) of that section.⁵ FDA’s 2004 guidance on changes to an approved NDA or ANDA puts it more plainly: “All changes in specifications from those in the approved application must be submitted in a prior approval supplement unless otherwise exempted by regulation or guidance.”⁶ The same guidance lists relaxing an acceptance criterion and deleting any part of a specification among its examples of major changes, subject to the exceptions it describes.

This creates a timing problem that LIMS master data teams need to understand. The internal document may be approved weeks or months before the regulatory approval arrives. If the LIMS record is updated when the document is approved, the lab may start testing to a specification that is not yet approved by the regulator. If the LIMS record waits for regulatory approval, someone has to remember to activate it. Both paths depend on a clear effective date that the LIMS team can see and trust.

ICH Q12 adds a useful frame. It defines established conditions (ECs) as “legally binding information considered necessary to assure product quality,” and states that any change to ECs needs a submission to the regulatory authority.⁷ Specifications and analytical procedures are among the dossier elements Q12 addresses when identifying ECs. The guideline’s appendix on change management also lists this principle for an effective change management system: “Verifies, post-implementation, that relevant changes have been effective in achieving the desired outcome with no unintended consequences for product quality.” For a specification change, one direct test of “effective” is whether the configured LIMS record matches what was approved.

ICH Q14 applies the same thinking to analytical procedures. It notes that the Q12 tools apply to analytical procedures, and it lists the PQS (the pharmaceutical quality system) as the place for “documentation of all changes including those not requiring regulatory submission.”⁸ A method version change that never needs a filing still needs to reach the LIMS method record through a documented change.

What EU GMP and WHO Expect From the Lab

EU GMP Chapter 6 on quality control says the QC department should have specifications readily available, and that “All testing operations described in the marketing authorisation or technical dossier should be carried out according to the approved methods.”⁹ It also requires test records to include references to the relevant specifications and testing procedures, and it states that “Any calculations should be critically examined.” In a LIMS, the calculations and the specification references are master data. They are exactly what an inspector will trace when a result is questioned.

The WHO good practices for pharmaceutical quality control laboratories, revised in 2024, are even closer to the problem. They expect labs to “maintain an up-to-date collection of all specifications and related documents (paper or electronic) used in the laboratory,” and to remove any invalid document and replace it with the authorized revised document with immediate effect.¹⁰ The same guideline calls for a change control procedure that includes assessment of impact, gaps, and risks, and states that “The quality manager should ensure that changes are documented, assessed for impact, approved, planned, implemented and reviewed.” It names LIMS as an example of the data and information management system labs should apply for traceability.

What Computerized System Rules Add

Annex 11, as adopted by Health Canada in GUI-0050, adds three expectations that apply directly to LIMS master data.¹¹ First: “Any changes to a computerized system including system configurations should only be made in a controlled manner in accordance with a defined procedure.” Specification records are configuration in this sense. Second: “For critical data entered manually, there should be an additional check on the accuracy of the data.” Acceptance criteria typed into a LIMS configuration screen are critical data entered manually. Third: “Computerized systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP.” A periodic review that checks access lists and audit trail settings but never compares configured specifications with approved ones leaves out the part of the system that decides batch outcomes.

FDA’s own inspection program points the same way. Compliance Program 7356.002, which guides drug manufacturing inspections, lists among the laboratory control system areas “Specifications, standards, and representative sampling plans,” “Validation and security of computerized or automated processes,” and “Control system for implementing changes in laboratory operations.”¹² An inspector following those lines will naturally ask to see how a specification change reached the system that applies it.

Six Failure Modes That Keep Showing Up

The failure modes below are patterns we see across QC labs of different sizes and LIMS platforms. They are not drawn from a single inspection report or a single company. Each one has the same root: the configured record and the approved record are managed as two separate things, with a manual step between them and no check that the step was done right.

1. Spec Change Approved but Not Configured

This is the most common and the most dangerous pattern. The change control record is approved, the new specification document is effective, the training is done, and the LIMS update is still sitting in someone’s queue. Sometimes the action item was assigned to a team that did not know it was assigned. Sometimes the change control closed because the action was marked “done” when the LIMS request was raised, not when it was completed.

If the change tightened a limit, the lab can pass batches that would fail the approved specification. If the change added a test, the test is never assigned. If the change widened a limit (with regulatory approval), the lab may reject or investigate batches that are acceptable, which wastes investigation effort and can delay supply. In every case, batch records say the product met specification, and they point to a specification number that does not match the limits the system used.

2. Configured Before It Was Approved

The opposite pattern happens when a LIMS administrator is given the new document early, often as a draft, so the configuration can be ready on time. The configuration gets built, and then it gets activated too soon. The lab starts testing to limits that the quality unit has not yet approved, or that the regulator has not yet approved. Under 211.160(a) that is an unapproved specification change. For a relaxed limit that needs a prior approval supplement, it can also mean testing to a specification that is not part of the approved application.

The fix is not to stop building early. Building early is sensible. The fix is to separate “configured” from “active,” and to make activation depend on the effective date recorded in the change control, with the quality unit’s approval visible in the LIMS audit trail.

3. Partial Propagation

A single specification change can touch many LIMS records: release specification, shelf-life specification, stability protocols for ongoing studies, in-process specifications, specifications for each site that tests the product, and specifications for each presentation or strength. Change control usually lists the document. It does not always list every configured record that depends on it.

The result is a change that is correct in one place and wrong in another. Release testing uses the new impurity limit. The ongoing stability study still uses the old one, so a stability result that should trigger an out-of-specification investigation does not. A second testing site, or a contract lab, keeps the old version because nobody sent them the change. ICH Q12 makes the point about supply chains in general: changes to established conditions should be communicated in a timely fashion across the manufacturing chain, and the organization responsible for batch release should be aware of all relevant changes.⁷

4. Transcription Errors

Most LIMS specification records are still built by hand. Someone reads the approved document and types limits into configuration screens. Errors are predictable: a missing decimal place, “less than” instead of “not more than,” a lower limit left blank, a limit entered against the wrong test, a text specification (“clear, colorless solution”) replaced by a free-text field with no pass or fail logic at all.

These errors can persist for years, because most results sit well inside their limits. A limit entered as 2.0 instead of 0.2 will never trigger a failure on a product that runs at 0.05. It only matters on the one batch that drifts, which is exactly the batch the specification exists to catch. This is why Annex 11’s call for an additional accuracy check on critical data entered manually applies so directly to specification configuration.¹¹

5. Method Version Drift

Specifications reference analytical procedures, and procedures change on their own schedule. A method revision might change a calculation, a response factor, a dilution, a system suitability criterion, or the reporting threshold for impurities. The specification document still lists the same test and the same limit, so nobody thinks to reopen the specification record. Meanwhile, the LIMS calculation, which is also master data, still uses the old formula.

EU GMP Chapter 6 asks for testing according to approved methods and for calculations to be critically examined.⁹ In a LIMS, the method record, the calculation, and the specification are linked. A change to any one of them should prompt a check of the others.

6. Orphaned and Duplicate Records

Over years of changes, many LIMS instances collect old specification versions that were never retired, or two active versions for the same product. Which one gets applied depends on how sample login works: a default, a user choice, a link from the product code, or the most recent version. When users can choose, some will choose the one they know. WHO’s expectation that an invalid document is removed and replaced with the authorized revised document “with immediate effect” is a good standard for LIMS versions too.¹⁰ A superseded specification should not be selectable after its end date.

Units, Rounding, and Product Codes: The Mismatches Nobody Reviews

Limits get attention because they are numbers on a page. The things that give those numbers meaning get far less. Units of measure, rounding and reporting rules, and product codes are all master data. A mismatch in any of them changes the specification as much as a wrong limit does, and they are much harder to spot on a screen.

Unit Mismatches

Unit problems in QC labs usually fall into a few types:

• Same quantity, different unit. The specification says ppm; the LIMS test reports µg/g. Numerically these can be equal, but only if everyone agrees they are, and only if no conversion factor gets applied along the way.
• Different basis. Assay as percent of label claim versus percent of theoretical; impurities as percent of the active versus percent w/w of the product; content on an as-is basis versus a dried or anhydrous basis. The unit symbol can be the same while the meaning is different.
• Per-unit versus per-mass. mg per tablet versus mg per gram, or units per vial versus units per mL. Common in content uniformity and biologics potency.
• Symbol ambiguity. “mcg” versus “µg,” “IU” versus “U,” “cfu/g” versus “CFU/g,” and free-text units that a downstream system cannot interpret.
• System-to-system conversion. ERP stores a material quantity in kg; LIMS stores a potency in percent; the interface or a certificate of analysis template converts one to the other with a factor that nobody validated.

The Unified Code for Units of Measure (UCUM) was created to solve exactly this problem for electronic data. Its stated purpose “is to facilitate unambiguous electronic communication of quantities together with their units.” The specification also makes a point every LIMS team should keep in mind: “In communication it is not only important that all communicating parties have the same repertoire of symbols, but also that all attach the same meaning to the symbols they exchange.”¹³ FDA uses UCUM codes in the units of measure list it publishes for structured product labeling.¹⁴ A LIMS unit table does not need to adopt UCUM in full, but it should be a controlled list, with one agreed symbol per unit and a defined basis for each result, rather than free text typed at configuration time.

Rounding and Reporting Rules

An acceptance criterion of “NMT 0.5%” is not complete until you know how many decimal places the result is reported to, and whether it is rounded before or after comparison with the limit. If the approved specification or the governing pharmacopoeia expects results rounded to the number of places in the limit, and the LIMS compares the unrounded value, a result of 0.54% could fail in LIMS and pass on the certificate, or the other way around, depending on how each step is set up.

Rounding rules are master data, even when they live in a system-wide setting rather than on the specification record. They need to be written into the specification document or a referenced procedure, configured to match, and tested. When a method revision changes the reporting threshold or the number of reported places, the LIMS setting has to change with it.

Product and Material Codes

LIMS usually receives product and material codes from ERP. The code decides which specification a sample gets. When a new product code, pack size, strength, or supplier is created in ERP, the LIMS needs a matching record linked to the correct specification. When the mapping is wrong or missing, one of three things happens: the sample cannot be logged in, a user picks the closest-looking record by hand, or the sample is linked by default to a generic or legacy specification. The first is annoying and visible. The other two are neither.

Code mapping gets worse after mergers, site transfers, and ERP upgrades, when codes are renamed or restructured. It is also where the boundary between IT and quality is least clear. The ERP team owns the code; the QC team owns the specification; the LIMS team owns the link between them; and each assumes one of the others checks it.

Change Control That Closes on the Configured Record

The fix for most of these failures is not a new system. It is a change control design that treats the configured LIMS record as a deliverable of the change, with its own verification, rather than as a follow-up task. The sequence below is the one we recommend. It works with any LIMS, and it does not require integration between the document system and LIMS, although integration helps.

Why Second-Person Verification Is Worth the Effort

Teams sometimes push back on a field-by-field check because it takes time. It does, but much less than an investigation into batches released against the wrong limit. It is also the most direct way to meet the Annex 11 expectation of an additional accuracy check for critical data entered manually.¹¹ The check should be done by someone who understands the specification, usually a QC reviewer or QA specialist, not only by the LIMS administrator’s peer.

The check is faster and more reliable when it uses a standard specification printout from LIMS that shows every field on one page. If your LIMS cannot produce that report, building it is one of the best small investments a lab can make. It supports change verification, periodic review, and inspection requests with the same output.

Validation Scope for Master Data Changes

A new specification version in a validated LIMS is normally a configuration change, not a software change. It does not usually need re-running the system’s validation tests. It does need a documented verification that the configuration is correct, which is what step 4 provides. Where a change adds a new calculation, a new rounding rule, or a new type of limit logic that the system has not handled before, a small targeted test of that logic is sensible before activation. Keeping this distinction clear avoids two opposite mistakes: treating every limit change as a full validation project, or treating a new calculation as a simple data entry.

Reconciliation Checks That Catch Drift

Change control prevents new drift. It does not find drift that already exists, and it will not catch every miss. A lab also needs regular reconciliation: checks that compare the configured records with the approved records, independent of any single change. The four checks below cover most of the risk.

Making the Effective-Date Reconciliation Work

The monthly check is the cheapest and one of the most useful. It needs two lists: one from the document management system (specification documents that became effective, with dates) and one from LIMS (specification versions activated, with dates). The comparison can be done in a validated report, a controlled spreadsheet, or a simple query. Every mismatch should have a reason: the regulatory approval is pending, the change affects only a site that is not yet live, the specification applies to a product not yet made. Mismatches without a reason become deviations.

The value of this check grows over time. After a few months, the team learns which kinds of changes tend to be missed, and can fix the change control template for those types. That turns the reconciliation from a detection tool into a way to improve the process.

Periodic Review Should Include Master Data

Most LIMS periodic reviews focus on system-level controls: user access, audit trail settings, backup and restore, incidents, and open changes. Those matter. But Annex 11 asks for periodic evaluation to confirm that systems “remain in a valid state and are compliant with GMP,” and a system applying wrong specifications is not in that state, however good its access controls.¹¹ We recommend adding three items to the periodic review: the results of the monthly effective-date reconciliations, the results of the most recent full content reconciliation, and the structural exception reports.

Link Reconciliation to Product Quality Review

The annual product review is another natural point to check. FDA’s compliance program describes product reviews as a place to assess risk and determine the need for changes, such as changes in drug product specifications.¹² If the review is going to consider whether a specification should change, it is a sensible moment to confirm that the current one is configured correctly. A short statement in each product review, “LIMS specification version X verified against approved specification Y on date Z,” completes that check with almost no extra effort.

What to Do When You Find Drift

When a reconciliation finds a mismatch, treat it as a deviation, not as a data correction. The questions are the same as for any deviation: how long has the mismatch existed, which batches and samples were evaluated against the wrong record, does any result change its pass or fail status under the correct record, and was any affected batch released. The LIMS audit trail and result history should answer the first two questions quickly. The last two may need a formal impact assessment and, where results change status, an out-of-specification investigation and a batch disposition review.

Correcting the record without that assessment is the worst outcome. It fixes the future and hides the past, and it removes the chance to learn how the error got in.

Who Owns LIMS Master Data

Ownership is where most master data programs stall. Everyone agrees the data matters. Nobody is sure who is accountable when it is wrong. The LIMS team says they configure what they are given. QC says they write the specification, not the configuration. QA says they approve the document. Regulatory says they file what is sent to them. Each statement is true, and drift starts in the gap between them.

A workable model separates the content of the specification from the configured record, and names one accountable owner for each.

The Quality Unit Owns the Decision, Not the Keystrokes

Under 211.160(a), the quality control unit reviews and approves specification changes.² That does not mean QA has to type the limits. It does mean QA should approve the configured record, not only the document, and that approval should be traceable in the system. The simplest way is to make the verification in step 4 a QA or QA-delegated activity, and to require a quality approval on activation.

The LIMS Master Data Admin Is a Named Role

In many labs, master data configuration is done by whoever has the access and the time: a senior analyst, a LIMS superuser, an IT analyst. A better model names a small group of trained master data administrators, with a written procedure, a standard build checklist, and segregation from the people who verify their work. Their job is to build accurately and to keep the list of affected records complete, not to decide what the specification should say.

Regulatory Affairs Owns the Filing Status

The LIMS team should never have to guess whether a specification change needs regulatory approval before use. Regulatory affairs should state it in the change record, with the expected or actual approval date. This single field removes most of failure mode 2.

The System Owner Owns the Structure

The LIMS system owner, usually in IT or in a lab systems group, owns the structure that makes the rest possible: the controlled unit list, the product code interface with ERP, the specification version logic, the exception reports, and the standard specification printout. Those are system design questions, and they belong with the person accountable for the system’s validated state. ASTM E1578, the standard guide for laboratory informatics, covers the life cycle of lab informatics tools such as LIMS from inception to retirement, and is a useful reference when defining these structural requirements for a new system or an upgrade.¹⁵

Contract Labs and Second Sites

When a product is tested at more than one site or at a contract lab, each site’s LIMS holds its own copy of the specification. The owner of the specification, usually the marketing authorization holder’s QC or QA group, is responsible for making sure every copy is updated. That needs a written communication step in the change control, an acknowledgment from each site, and evidence of each site’s own verification. Quality agreements should say so explicitly. ICH Q12 notes that the communication mechanisms for changes and GMP issues should be defined in relevant documentation, including contracts with contract manufacturing organizations.⁷ The same logic applies to contract testing labs.

Where to Start: The First Reconciliation Pass

If you suspect drift in your LIMS today, the first step is to find out how much there is, without turning it into a year-long program. A focused first pass can be done by a small team in a few weeks.

Step 1: Pull the Two Lists

Export every active specification version from LIMS, with product, test, method version, limits, units, reporting precision, and effective date. Export every current approved specification document from the document management system, with its version and effective date. Match them at the header level first: product and specification version. Mismatches at this level (active LIMS versions with no current document, or current documents with no active LIMS version) are the first findings.

Step 2: Risk-Rank the Products

You do not need to compare every field of every product in the first pass. Start with products that are on the market, that had a specification change in the last two to three years, that are tested at more than one site, or that have results that run close to their limits. These are where drift is most likely and where it matters most.

Step 3: Compare Content for the Top Group

For the highest-risk products, compare every test, method reference, limit, operator, unit, basis, and rounding rule between the approved document and the LIMS record. Include stability protocols and second sites. Record each mismatch with its likely start date, found from the LIMS audit trail.

Step 4: Assess Impact Before Correcting

For each real mismatch, open a deviation and assess affected results before changing anything. Then correct the record through change control, using the same verification steps described above, so the correction itself is clean.

Step 5: Fix the Process That Allowed It

Look across the findings for the common cause. Did most mismatches come from one type of change, one site, one period, or one gap in the change control template? That answer tells you which of the controls in this article to put in place first. For many labs, it is the closure rule: change control records that closed on “LIMS request raised.” For others, it is partial propagation to stability or to contract labs.

The findings from this pass are also the best input for a business case. A count of mismatches, with their age and the number of affected batches, is far more persuasive to leadership than a general argument about data quality. If the pass finds very little, that is good evidence for inspection readiness, and the reconciliation controls can be scaled to match.

Conclusion

LIMS master data is where approved specifications turn into daily decisions. Every result is judged against a configured record, and that record is only as good as the step that copied the approved document into it. Regulations already expect the quality unit to approve specification changes, the lab to test against current approved methods and limits, and computerized system changes to be controlled and checked. What most labs lack is not a rule but a design that treats the configured record as part of the change: listed at impact assessment, built in draft, verified by a second person, activated on the effective date, checked at first use, and reconciled on a schedule. Units, rounding rules, method versions, and product codes belong in that same scope, because they define what the limit means.

Sakara Digital works with pharma and biotech quality and lab systems teams on exactly this kind of problem: finding where configured records and approved records have drifted, designing change control that closes on the configured record, and setting up reconciliation and ownership that hold up in an inspection. If you are looking at your own LIMS master data and want an independent view of where to start, we are happy to have that conversation.

For Further Reading