The short answer: start both clocks on the same day
Accelerated aging answers the question "can we get to a usable conclusion now". Real-time aging answers the question "does that conclusion ultimately count". Under the ISO 11607 framework for packaging systems for terminally sterilized medical devices, stability evidence may initially be supplied by accelerated aging, but the final confirmation of a shelf-life claim has to be supported by real-time data. The two are not alternatives to choose between; they are two parallel tracks inside a single file.
On scheduling there is only one version that does not cost you later: on the day the protocol is frozen, the accelerated group and the real-time group go into storage together and start counting together. Holding the real-time group back until "we see the accelerated report and then decide whether to commit samples" pushes the completion date of the final confirmation out by an entire aging period. Get this step wrong and no amount of budget buys it back, because the one thing aging cannot compress is time itself.
When accelerated data can carry the file on its own
Assess the product status and the nature of the change first; only then decide how to organize the evidence.
| Situation | Can accelerated data carry it initially? | What has to be scheduled in parallel |
|---|---|---|
| First submission, packaging structure and materials already frozen | Yes, as preliminary stability evidence | Commit the real-time group from the same batch and record the start of the clock in the file |
| Packaging material supplier change, structure unchanged | Depends on the conclusion of the change assessment | Run a material equivalence assessment first, then decide between a full repeat and testing only the affected items |
| Structural change (seal type, opening feature, new size added to the range) | Cannot be carried over directly | Open a new aging file for the new structure |
| Sterilization method or process parameters adjusted | Cannot be carried over directly | Handle together with sterilization validation; see the project notes under sterilization validation |
| Label or printed content only, no contact with the sterile barrier | Usually carried over | Keep the change assessment record and the rationale behind the decision |
| Transport conditions or packaging levels adjusted | No direct correspondence with aging | Schedule transport simulation separately; do not fold it into the aging file |
The working rule is plain enough: aging data belongs to one specific combination — this material set, this seal, this sterilization method. Swap any element of that combination and you first have to demonstrate equivalence; if you cannot demonstrate it, you repeat. Plenty of teams write the change assessment as a single line saying "the impact is minor", which rarely survives a later review, because what is being assessed is not subjective impact but whether the failure modes could change.
Setting the aging conditions: three things the protocol must state
YY/T 0681.1 provides a framework for accelerated aging test methods. It is not a template that fills in the conditions for you. Three things have to be written out at protocol stage, and leaving any one of them out will draw questions later.
First, the basis for the accelerated temperature selected. You need to state that the chosen aging temperature does not introduce failure modes that would not occur in real storage — that is, it is not high enough to push the material past a phase transition, or to change the adhesive system in ways that real use would never produce. This calls for supporting justification from the materials side, not a line saying "selected on the basis of experience".
Second, the derivation of the acceleration relationship. The relationship used to convert the selected temperature into an equivalent storage duration belongs in the protocol, including the rationale for the temperature acceleration factor applied. Reviewers are not interested in the number you arrive at; they are interested in whether the relationship was argued through and whether it errs on the conservative side. An aggressive factor with no material basis behind it is the element most frequently challenged.
Third, the test item set and the acceptance criteria. What gets tested after aging, what the acceptance criterion is for each item, and where each criterion comes from all have to be locked down in the protocol. Adding items after testing has started invalidates every sample already in storage, because the new items have no aging history from the same start point.
Organizing the file: four threads that have to line up
Most rework is not caused by bad data. It is caused by evidence that does not line up. An aging file has to tell four stories at once.
| Evidence module | What it must contain | Typical consequence if missing |
|---|---|---|
| Identity thread | Material grades, seal parameter records, and the mapping between sterilization lot and aging group | No way to show the tested samples share an origin with the submitted product; the whole data set falls |
| Condition thread | Basis for the aging temperature, the conversion relationship, the equivalent storage duration claimed | Further justification requested; the file sits on hold |
| Test item thread | Sterile barrier integrity, seal strength, material properties and any necessary functional items, plus the source of each criterion | Missing items have to be tested later, and the added samples must match the original lot |
| Timeline thread | Storage start dates for both groups, sampling points, report issue and update plan | Real-time data cannot be tied back to the accelerated conclusion, and final confirmation fails |
Of these four, the identity thread breaks most often. The accelerated group is packaged by hand from engineering samples while the real-time group comes off the production line with different seal parameters — once that happens the two data sets cannot corroborate each other and the work is wasted. The remedy is crude but effective: every aging sample comes from one packaging run and one sterilization run, and the group identifiers are applied before sterilization.
The other frequent break is the timeline thread. Real-time aging runs long. Project owners change, systems change, and the original record of the start date goes missing. The start of the clock has to live in a controlled document and has to reconcile with the sterilization release record — not only in the project team's chat history.
Sample allocation: allocate in full once, do not plan to top up
Sample allocation is where cost concentrates in an aging project, and it is the step most often underestimated. Estimate it as sampling points multiplied by test items multiplied by the sample quantity each item consumes, multiplied by the two groups, accelerated and real-time, and then add a retest reserve on top.
One common way this goes wrong is copying the accelerated group's sample count across to the real-time group. The real-time group normally has more sampling points, because intermediate points are needed to support any trend judgement. Leave only an end-point sampling and there is nothing to fall back on if something drifts along the way; you start over.
A second is leaving no retest samples. One item comes back sitting right at the edge of its criterion, you want to retest, and there are no samples from the same lot left. The only route open is a fresh run through packaging, sterilization and aging.
A third is letting the samples get separated at the sterilization step. The accelerated and real-time groups are sterilized separately and booked against different lots, and when the data are later correlated the sterilization records do not match. That gap then has to be papered over with narrative, and narrative carries little weight.
The cost curve here is steep: changing it at protocol stage is free, changing it once samples have arrived means rescheduling, and changing it after aging has started means writing off the round.
The accelerated group fails mid-stream — does the real-time group stop?
The accelerated group reports first. If it fails, work through the following order rather than reaching straight for the acceptance criteria.
Confirm first whether this is a packaging failure or a failure introduced by the test method. Seal strength items are sensitive to grip arrangement and specimen location; the same lot sampled from a different location can give a different conclusion. Next, separate material aging from an unstable sealing process by looking at the spread in the un-aged control group from the same lot: if the control group is already scattered, the problem lives in the sealing process, not in aging. Only after those two should you consider changes to packaging structure or materials.
The real decision point is whether the real-time group stops with it, and that turns on the nature of the failure mode. For a structural failure — a leaking seal, material embrittlement — there is no point in letting the real-time group run on; stop it early, cut the loss, and move the resources to the new structure. For a marginal deviation where the test method is under suspicion, keep the real-time group running and re-run the accelerated group on fresh samples to check the method. Stopping wrongly wastes the time already invested; failing to stop wastes further samples and storage capacity. Either way, write the reasoning into the decision record.
Pre-delivery self-check
- Does the protocol give a material basis for the accelerated temperature, rather than just a set point
- Is the derivation of the conversion relationship consistent between protocol and report, with no drift in wording
- Do the accelerated and real-time samples share an origin, seal parameters and sterilization lot
- Do the sampling points cover intermediate points rather than the end point alone
- Is the test item set aligned with what packaging validation requires — see packaging validation
- Do the change assessment record and the aging file cross-reference each other's numbers, so the trail runs both ways
- Is the real-time update plan written into the quality system documentation rather than left in project email
- Are transport simulation conclusions and aging conclusions filed separately, with neither standing in for the other
The full logic chain behind a shelf-life claim also has to line up with the transport conclusions; for how shelf-life projects are combined, see shelf life and aging. For sample quantities, sample sealing arrangements and preparation before shipping, start with sample requirements.
Turning the aging schedule into a concrete plan
If you are currently stuck on whether to run accelerated first, when to commit the real-time group, and how many samples to prepare, send over the packaging structure, the material list, the sterilization method and the shelf-life claim you are aiming for. We will lay out the protocol skeleton along the four threads above and come back with a test and scheduling proposal. SUNGO Lab (Shanghai Shage Medical Technology Co., Ltd.) is a medical device testing laboratory accredited by CNAS, CMA and IAS (USA), with laboratories in Shanghai and Hefei. Please note that accreditation marks only demonstrate that the laboratory holds the relevant technical competence within its accredited scope; they do not constitute a commitment regarding market access in the target market, and the final conclusion still rests on the test data and the review requirements of that market. To discuss a protocol, call +86 132 4819 8029 or submit your product documentation through request a quote.