Pharma Engineering Insights

MES and Historian Architecture in GMP Manufacturing: Data Ownership, Records and System Boundaries

Define MES and historian ownership, batch context, data completeness, review by exception, retention and recovery across manufacturing systems.

G GuideGxP 9 min read
✓ Official sources and references ✓ Practical approach ✓ For pharmaceutical professionals
GUIDEGXP · PRACTICAL GMP INSIGHTS
Manufacturing execution and historian workstations supporting pharmaceutical production

A batch report displays complete production results while the historian contains a gap during a critical operation. MES has accepted the completion message, but no system owns the decision about whether the missing observations are recoverable. The applications are connected; the record architecture is incomplete. This failure becomes easier to prevent when data ownership and record boundaries are defined before interface configuration.

A historian and a manufacturing execution system can complement each other, but neither product name establishes what constitutes the GMP record. The architecture must explain acquisition, context, approved workflow, review, retention and recovery for the site's intended use.

Give each application a defined operational role

A historian typically collects and retrieves time-related process observations, events and associated metadata. MES typically supports manufacturing execution, production context, material genealogy and electronic workflows. Either platform may offer functions associated with the other, including calculations, reports and review tools. Assess the configured capabilities rather than relying on these general labels.

Start from operational questions. What happened to the process? Which equipment and material were involved? Which approved instruction was executed? Who performed an action? Which exceptions require review before disposition? Assign each question to controlled data sources and a responsible process owner. Avoid creating parallel answers in different applications without a defined reconciliation rule.

[STANDARD] ISA-95 provides models and terminology for enterprise-control integration; the publisher catalogue identifies Part 1 as ISA-95.00.01-2025. It supports functional discussion, not a mandatory software purchasing list. A facility can satisfy its intended use through different combinations of applications if ownership, interfaces and evidence are adequately controlled.

Distinguish data ownership from record ownership

The owner of a data source maintains its meaning and configuration. The owner of a record defines its intended use, completeness, review and retention. These responsibilities can belong to different functions and must cooperate. Automation may maintain an acquisition tag while production and quality define how its observations support batch review.

For every relevant data object, identify the authoritative source, permitted transformations and downstream consumers. Include identifiers, units, time basis, quality status and configuration version where needed. For every record, identify the required components and the condition that makes the record complete. A batch record can reference distributed source records, but the references must remain resolvable and meaningful throughout the required retention period.

[GUIDEGXP RECOMMENDATION] Maintain a record ownership matrix as a design deliverable. Use it to resolve disagreements about whether MES, historian, controller or another application retains the authoritative information. Do not let the answer emerge accidentally from whichever report is easiest to print.

Map acquisition, context and review separately

InformationTypical sourceContext requiredOwnership decision
Process observationInstrument and control system through acquisition servicesUnit, time, quality, equipment and relevant phaseWhere original observations and necessary metadata are retained
Material consumptionExecution workflow or verified equipment transactionMaterial identity, lot, quantity, unit and operationWho confirms consumption and resolves discrepancies
Recipe executionBatch or control applicationApproved version, executed parameters and changesWhich record demonstrates the actual executed instruction
Review exceptionDefined evaluation of source recordsRule version, source scope and reviewer dispositionWho owns completeness and closure of the review

The “typical source” column is illustrative. Actual allocation depends on the installed architecture. Confirm it with process, production, automation, IT and quality representatives before implementing interfaces or retention rules.

Preserve the meaning of historian observations

Acquisition settings determine what is retained. Sampling, exception reporting, compression, aggregation and interpolation are different operations with different effects. Define which are applied, where they occur and whether their effect is acceptable for the intended use. A visually smooth trend cannot establish that every relevant event was captured.

Retain sufficient metadata to interpret values: engineering units, source identity, timestamps, quality indicators and relevant configuration context. Plan how changes to tag names, scaling or equipment assignments are represented. Reusing a tag identifier for a different physical function can make historical interpretation unreliable if the change is not preserved.

[QRM] Derive acquisition settings from process dynamics and the decisions supported by the data. Challenge the configuration with known events, including short changes and communication loss. There is no universal GMP sampling interval. The justification should explain why the retained evidence is sufficient for this process and what limitations remain.

Attach manufacturing context without rewriting history

Context links observations to orders, batches, phases, equipment and material. Decide which system creates each identifier and how uniqueness is maintained. A batch number typed manually in several applications creates opportunities for mismatch. Where manual entry remains necessary, define verification and discrepancy handling.

Late context requires explicit treatment. A historian may collect values before MES supplies the batch association, or an operation may cross a shift or calendar boundary. Define how context is added, corrected and audited without concealing the original association. Preserve the distinction between when a process event occurred and when a contextual correction was made.

Material genealogy also needs transaction semantics. Record whether material was reserved, issued, actually consumed, returned or rejected. These states are not synonyms. A successful interface delivery cannot prove that the physical material movement was correct. Coordinate electronic confirmations with the actual manufacturing workflow and its verification controls.

Define the electronic batch record as a complete evidence set

An electronic batch record can contain instructions, execution confirmations, measured results, calculated values, attachments, deviations and references to external records. Define which components are required for the particular operation and how missing components are detected. A final PDF may be a useful presentation, but it may not preserve all necessary dynamic information or metadata.

Identify records supporting decisions and the means to reconstruct those decisions. If a calculated result is used, retain or reference the inputs, calculation logic and relevant version as needed. If a reviewer follows a link into a historian, establish that the link retrieves the intended equipment, period and data version rather than an editable default view.

Determine how record status progresses: in execution, awaiting data, awaiting review, under investigation, approved or archived. These states should have defined entry conditions. Do not allow completion of a production workflow to imply completeness of all supporting records unless the architecture has actually checked that condition.

Engineer review by exception carefully

Review by exception depends on trustworthy rules and a complete population of data. Define which conditions create exceptions, how rules are versioned and how changes are approved. An absence of displayed exceptions means little if an acquisition outage prevented the rule engine from seeing the relevant event.

Include data completeness and rule execution status in the review design. Identify conditions requiring manual review, such as missing observations, unresolved interface errors, changed configuration or unavailable evaluation services. The system should distinguish “evaluated with no exception” from “not evaluated.”

Verify the workflow with known positive and negative cases, including boundary conditions and incomplete inputs. Retain reviewer identity, disposition and links to investigations where applicable. [GUIDEGXP RECOMMENDATION] Assess whether reviewers can explain why a record was considered complete and acceptable without relying on undocumented knowledge of the application.

Specify retention, archive and retrieval as one lifecycle

Determine retention from applicable requirements, record type and the site's approved policy. Do not assign one generic retention period to all historian data merely because storage is inexpensive. Conversely, do not remove source observations needed to interpret a retained batch record while keeping only its report.

Design archive retrieval before decommissioning becomes urgent. Identify required software, schemas, viewers, metadata, keys and context. Verify that archived records remain readable and interpretable, and that access and changes are controlled. A file export is not sufficient evidence of a viable archive if relationships, audit information or units are lost.

Keep backup and archive purposes distinct. Backups support restoration after failures; archives support retained access over the defined lifecycle. A successful backup job does not demonstrate either a complete restore or a usable long-term archive. Test representative retrieval and reconstruction, including records spanning configuration or software changes.

Control reports and derived results

A report should state which source population, time interval and calculation rules it uses. Define treatment of missing values, excluded observations, rounding and units. If a report calculates a maximum or duration, verify its result against a known data set and include cases where gaps or bad-quality values occur. A calculation that silently ignores unavailable data can produce a plausible but misleading result.

Control report templates and query logic with the same attention given to other decision-supporting configuration. A revised query may change which records are included without changing the visible page layout. Retain the relevant version and ensure reviewers can identify the basis of a previously issued result.

Where business dashboards reuse manufacturing data, define their status clearly. An exploratory dashboard can help identify patterns, but a decision requiring a controlled GMP record must use information with the necessary completeness, context and governance. Avoid allowing a convenient visualization to become an undocumented substitute for the approved review process.

Design failure scenarios across both systems

List interruptions separately: acquisition service unavailable, historian storage full, MES unavailable, identity service unavailable, interface queue stalled and time synchronization degraded. For each, define what production may continue, what must stop or hold, what buffers information and who is notified. The operational response depends on the process and record consequences.

Specify store-and-forward behaviour, capacity limits and detection of overflow. Retain source time and quality where needed, and prevent recovered data from silently overwriting existing records. Define reconciliation of late or duplicate transactions. Recovery should produce an explainable record of what was recovered, what remains missing and how discrepancies were resolved.

Derive recovery objectives from assessed needs. Redundant infrastructure can support availability but may share corruption or configuration failures. Demonstrate restoration of the complete service, including context and interfaces, rather than showing that a database can be opened independently.

Worked example: historian outage during a manufacturing operation

An illustrative manufacturing operation uses local control, historian collection and an MES execution record. During a planned acceptance test, the historian connection is interrupted. Local control continues according to its approved strategy, and the acquisition layer buffers the required observations within its assessed capacity.

MES receives the operation-complete message but marks the supporting data as pending. When communications return, buffered observations retain their original time and quality information. A reconciliation service checks the expected interval and identifies any unresolved gaps. The reviewer sees both the process result and the status of its supporting evidence.

The test does not merely confirm that values eventually appear on a trend. It compares the recovered observations with the known test sequence, verifies duplicate handling and confirms that record approval cannot bypass unresolved completeness conditions without the site's authorized exception process. Buffer capacity and recovery timing are specific project decisions, justified by this operation's risk and continuity needs.

Release and maintain the ownership model

Before release, reconcile the ownership matrix with the actual configuration and procedures. Assign responsibility for tag changes, master data, interface errors, review rules and archive retrieval. Train support teams on cross-system faults; an issue can fall between teams if each monitors only its own application health.

Assess changes for their effect on historical interpretation. A revised MES workflow, historian compression setting or report calculation can alter the evidence used for decisions. Preserve configuration identity and verify affected functions. Periodic review should consider operational experience, incidents, support status and the continued suitability of the architecture, with timing justified by the site.

  • Authoritative sources and record owners are identified.
  • Batch context and material states have controlled meanings.
  • Completeness is distinguishable from workflow completion.
  • Review rules detect missing or unevaluated information.
  • Recovery includes reconciliation and discrepancy disposition.
  • Retained records remain retrievable with necessary context.

Continue with GMP system integration and data integrity by design. For process applications, see Single-Use & Bioprocess Systems and the Automation & Digital Systems hub.

Regulatory context and primary references

Reviewed 23 September 2026. [REGULATORY REQUIREMENT] Apply the relevant electronic-record, documentation and computerized-system controls through EU GMP EudraLex Volume 4 and, where applicable, 21 CFR Part 11. Operative EU Annex 11 and Chapter 4 remained the 2011 texts; consultation proposals were not replacements. [GUIDANCE] See FDA drug CGMP data integrity guidance. [STANDARD] See the ISA catalogue for ISA-95. The ownership matrix and worked example are original GuideGxP engineering recommendations.

THE PRAGMATIC GMP · EVERY MONDAY

The GMP topics that matter, in 7 minutes.

One GMP topic, one real-world example and one practical action, based on official sources and inspection trends.
Discover The Pragmatic GMP