End-of-Synthesis Time

This glossary term is part of the SG Systems Global regulatory & operations guide library.

Updated January 2026 • 21 CFR Part 212 PET drug cGMP, EOS time anchor governance, decay timing and activity statements, QC sample timing, beyond-use time logic, release sequencing, chain-of-custody, audit-ready records • Primarily PET & radiopharmaceutical operations (cyclotron sites, radiochemistry labs, nuclear pharmacies, hospital PET production)

End-of-Synthesis Time (commonly abbreviated as EOS) is the controlled timestamp that marks when the synthesis step for a PET drug batch is considered complete. It is the clock-start event that anchors multiple downstream controls: activity decay calculations, labeling statements, QC sample timing, release sequencing, and Beyond-Use Time (BUT) logic. In a PET drug environment governed by 21 CFR Part 212, EOS is not “about documentation.” It is a primary time reference that has to be defined, captured consistently, and protected from casual reinterpretation.

The business value is blunt: EOS discipline prevents dose scheduling chaos, reduces expired product, and keeps activity statements consistent across handoffs. The compliance value is equally blunt: if EOS is ambiguous or editable without control, your time-based controls become inconsistent, and your records become reconstructive. Inspectors do not accept “around that time.” They expect a controlled definition of EOS, evidence of capture, and clear linkage from EOS to every time-sensitive decision.

Tell it like it is: most EOS failures are not technical—they’re definitional. One team treats EOS as “end of synthesis module,” another treats it as “end of purification,” another treats it as “when the vial is finished,” and under pressure people pick the definition that makes the product look better. That is how a time anchor turns into a loophole. A controlled EOS program prevents that by defining the event unambiguously, embedding EOS capture into the workflow as a hard step, and preventing backdating or “corrections” without documented reason-for-change and review.

“EOS is the time anchor that keeps radiopharma honest. If EOS floats, everything floats.”

1) What EOS is (and what it is not)

EOS is the time stamp that marks “synthesis complete” according to your defined operating model. It is the anchor time used to standardize downstream calculations and timing decisions. EOS should be captured once, linked to the batch identity, and treated as a controlled datum—not a narrative detail.

It is not a flexible idea you can shift to rescue a late shipment. It is not “end of day.” And it is not a time that can be chosen differently by different teams. If EOS is flexible, it is not EOS—it is a workaround.

2) Why EOS is the critical time anchor in PET production

PET drugs are short-lived. Time affects activity and usability continuously. EOS is the reference point that keeps time math consistent: it gives you a stable “start point” for decay and a stable anchor for calculating use windows. Without EOS discipline, two people can calculate two different answers from the same batch because they started the clock at different moments.

Tell it like it is: when you audit a PET operation, time anchors are where records fall apart. EOS is the anchor that prevents that collapse.

3) Defining EOS: the event you choose and why it matters

EOS must be tied to a specific operational event. Examples include completion of a defined synthesis module step, completion of purification, or completion of transfer into a final container. The exact definition depends on your process and validated model, but the definition must be:

• unambiguous (one event, one time),
• observable (not guesswork),
• repeatable across batches and shifts,
• linked to the batch record and downstream calculations.

Tell it like it is: the wrong definition doesn’t just create paperwork differences—it changes how much usable time you believe you have. That affects dispatch decisions and compliance posture.

4) Workflow capture: where EOS is recorded in the batch record

EOS should be captured as a hard workflow step in your execution record. Practical controls include:

• system-captured time when the synthesis step transitions to “complete,”
• operator confirmation where required (with e-signature),
• single source of truth (no duplicate EOS fields across documents),
• automatic propagation to dose records and labels when needed.

Tell it like it is: if EOS is written on a whiteboard first and typed later, you have created a reconstruction pathway. Capture EOS where the work happens, not where the paperwork happens.

5) Activity statements and decay math: EOS as the reference time

EOS is commonly used as an anchor for decay calculations and activity statements, especially when lot-level activity at a reference time is used for subsequent dose calculations. If you use EOS as an anchor, the record set should show:

• reference activity and units tied to EOS,
• calculation method and correction rules,
• instrument credibility where activity measurement is involved (see Dose Calibrator Checks),
• linkage from EOS to downstream dose calibration times where applicable.

Tell it like it is: if EOS is inconsistent, decay math becomes inconsistent, and the organization starts “rounding” to make things work. That’s how time-based noncompliance begins.

6) QC sampling and test timing: how EOS affects lab controls

Many QC activities are time-sensitive. EOS helps standardize when samples are taken and how test results are interpreted in time context. A controlled program defines:

• sample timing windows relative to EOS,
• sample IDs tied to the batch and timestamped,
• test status states and review expectations,
• release rules that depend on which tests must be complete vs pending.

Tell it like it is: if QC timing floats, it becomes impossible to compare results, and it becomes easy to “choose the best timing” after the fact. EOS turns timing into a standard.

7) Beyond-use time logic: EOS-to-use window governance

BUT is the operational hard stop for use. Many programs derive BUT from EOS plus a defined window. If you do this, the system must:

• calculate BUT consistently using EOS as the anchor,
• display and label BUT clearly on units of use,
• hard-gate use beyond BUT (warnings are not enough),
• record decisions for expired units (disposition and waste handling links).

Tell it like it is: if BUT is derived from EOS, any EOS ambiguity becomes a BUT ambiguity. That’s why EOS must be controlled with the same seriousness as release decisions.

8) Release sequencing: how EOS interacts with holds and pending release

Release states often depend on time. EOS influences whether there is enough time to complete testing before the product becomes unusable. Where conditional models exist (e.g., Sterility Release Pending), EOS still matters because it drives time eligibility. The system must evaluate:

• quality eligibility (release status, holds, pending results), and
• time eligibility (BUT and dispatch margin),
• scope constraints for conditional distribution.

Tell it like it is: conditional release is where time anchors are most likely to be abused. EOS keeps conditional release honest by making time math explicit and auditable.

9) Labeling: showing EOS-derived times clearly and consistently

Labels should communicate EOS-related times in a way that prevents confusion:

• clear time format and time zone discipline,
• explicit anchor labeling (“EOS” vs “Cal Time”),
• derived fields (BUT, calibration time activity) shown with clarity,
• status cues for expiring soon and expired units.

Tell it like it is: label ambiguity is a real operational risk. If a tech reads the wrong time, the system must still hard-gate expired use. Labels are communication; gates are control. You need both.

10) Handoffs and transport: EOS as a chain-of-custody reference

EOS is not just internal. It affects delivery and use windows across custody. A disciplined chain-of-custody model uses EOS to calculate remaining margin at dispatch and receipt, and to trigger escalation when delays threaten usability. Record:

• dispatch time relative to EOS,
• route margin expectations,
• handoff confirmations and receipt time where feasible,
• exceptions for delays and missed windows.

Tell it like it is: if you don’t measure margin, you will ship optimism. EOS-based margin is how you ship reality.

11) Edits and corrections: controlled changes only

EOS should not be casually editable. If corrections are necessary, they must be controlled:

• reason-for-change required for any edit,
• review/approval required for corrections,
• audit trail capturing old/new values and timestamps,
• impact assessment because EOS changes affect BUT and labeling.

Tell it like it is: changing EOS changes downstream truth. Treat EOS like a critical record field with strict governance.

12) Data integrity: audit trails and time governance

EOS is a high-value data point. Integrity controls should include:

• unique user identities (no shared logins),
• system time governance (no local clock hacks),
• audit trails for all changes,
• controlled permissions for capturing and editing EOS,
• late-entry flags and exception workflows when timing capture is delayed.

Tell it like it is: if time can be manipulated, time-based compliance is fiction. Protect system time and record capture pathways.

13) Exceptions: late runs, rework, and abnormal synthesis endings

Not every run is clean. EOS governance must define how exceptions are handled:

• aborted runs and when EOS applies (or does not),
• rework/reprocessing and whether a new EOS is created,
• interruptions and how completion is determined,
• unplanned interventions and deviation linkage.

Tell it like it is: if exceptions are handled informally, EOS becomes variable exactly when controls matter most. Define exception rules and stick to them.

14) Records package: what you must be able to show on demand

Inspection readiness requires that EOS is visible and connected in the record set:

• EOS definition in procedures and batch record template,
• EOS value captured in the execution record with timestamp and user/system source,
• linkage to activity statements and decay calculations,
• linkage to BUT derivation and gating evidence,
• exceptions with deviation linkages and approvals.

Tell it like it is: if EOS is present but not linked, you’re forcing an auditor to do mental math and inference. Don’t. Make the linkage explicit.

15) KPIs: proving EOS discipline is stable

EOS discipline can drift quietly. KPIs that expose drift:

Tell it like it is: rising EOS edits or late-entry flags are early indicators of record stress and schedule pressure. Fix the workflow before it turns into a compliance event.

16) Copy/paste readiness scorecard

Use this to test whether your EOS definition and capture are truly controlled.

17) Failure patterns: how EOS programs collapse in real life

• Multiple definitions. Different teams use different EOS meaning. Fix: one definition, one event, one capture step.
• Manual transcription. EOS written then typed later. Fix: system capture at the time of work.
• Editable anchors. EOS adjusted to rescue schedules. Fix: strict edit controls and impact assessment.
• No linkage. EOS exists but doesn’t drive calculations/gates. Fix: explicit linkage to decay, BUT, release rules.
• Time zone confusion. Multi-site time drift. Fix: time zone discipline and standardized display.
• Late entry normalized. Time captured after the fact. Fix: workflow gating and late-entry exceptions.
• Exceptions improvised. Aborts and rework handled ad hoc. Fix: defined exception rules and deviations.

Tell it like it is: EOS collapses when time is treated as flexible. In radiopharma, time is a quality attribute. Keep it rigid and auditable.

18) Change control: redefining EOS and version continuity

If you change your EOS definition, you are changing your time anchor. That requires change control:

• change request with rationale and risk assessment,
• impact analysis on BUT rules, labeling, and scheduling,
• effective date/time and version transition rules,
• training updates and updated work instructions,
• historical continuity so past records remain interpretable.

Tell it like it is: changing EOS without change control will destroy trend comparability and audit defensibility. Treat EOS definition as a controlled configuration item.

19) Training and competency: making EOS non-negotiable

EOS discipline must survive schedule pressure. Role-based training should cover:

• operators: when EOS occurs and how it is captured,
• dispatch/pickers: how EOS drives time margin and BUT gating,
• QC staff: how sampling and test timing relate to EOS,
• QA/reviewers: what evidence must exist and how edits are governed.

Tell it like it is: if people think EOS is “just paperwork,” they will treat it like paperwork. Train that EOS is the time anchor that keeps patient dose decisions consistent and defensible.

20) How this maps to V5 by SG Systems Global

V5 supports EOS governance by capturing time anchors in execution workflows and propagating them into quality, warehouse, and integration processes so time rules are enforced end-to-end:

• V5 MES captures EOS as a controlled execution event, ties it to the batch identity, and uses it to drive downstream timing logic and readiness gates.
• V5 QMS governs holds, pending release states, deviations, and audit trails so EOS-linked decisions remain consistent and reviewable.
• V5 WMS supports scan-verified picking, dispatch margin checks, and disposition-based blocks so expired or ineligible units cannot move forward.
• V5 Solution Overview explains how MES + QMS + WMS act as one control layer so EOS is not trapped in one department’s records.
• V5 Connect API enables integration of schedules, test status, and partner handoffs so EOS-driven time windows and alerts can synchronize across systems in near real time.

Operationally, this enables: consistent EOS capture, consistent BUT derivation, real-time margin visibility, and hard gates that prevent “release first, prove later” time behavior.

21) Extended FAQ

Q1. Why is EOS so important in PET operations?
Because it anchors time-based controls: decay calculations, activity statements, QC timing, release sequencing, and beyond-use time. Without a stable EOS, every time-dependent decision becomes inconsistent.

Q2. What’s the biggest EOS failure pattern?
Multiple definitions. Different teams treat different events as EOS, then choose whichever one helps in the moment. Fix EOS as one event and capture it as a hard workflow step.

Q3. Can EOS be corrected if it was captured incorrectly?
Yes, but only under controlled rules: reason-for-change, audit trail, review/approval, and impact assessment because EOS changes affect labeling and time eligibility.

Q4. Does EOS define beyond-use time automatically?
Only if your operating model defines BUT as EOS plus a rule. The point is consistency: whichever rule you use, it must be defined, versioned, and enforced with hard gates.

Q5. What should records show to be inspection-ready?
EOS definition in procedures, EOS captured in the execution record with timestamp/source, linkage to decay and labeling, linkage to BUT derivation, and controlled handling of exceptions and edits.

Related Reading (keep it practical)
EOS anchors the time story; enforce the rest with gates: use Decay-Corrected Activity with verified measurement systems (see Dose Calibrator Checks), control eligibility with Beyond-Use Time, and keep conditional workflows honest under Sterility Release Pending without shifting anchors to rescue schedules.