EU variation classification: IA, IB, II or extension?

Start with the approved dossier and the exact proposed change

Classification starts with a precise present-versus-proposed comparison. Record the affected marketing authorisation, procedure, dossier sections, product information and implementation date before searching for a variation code.

Do not classify from a short change title alone. Conditions, documentation requirements and the potential impact on quality, safety or efficacy can change the applicable category.

Use the legal and classification sources in order

First screen the proposed change against Annex I of the Variations Regulation, because listed changes are extensions rather than ordinary variations. Then use the current Classification Guideline to locate the relevant scope, conditions and supporting documentation.

If a Type IA condition is not met, the change may fall to Type IB by default unless it is specifically a Type II variation, an extension, or the holder considers that it may significantly affect quality, safety or efficacy. Unclassified changes and Article 5 recommendations need specific review.

• Confirm the current approved state and every dossier section affected.
• Screen for an extension before selecting an IA, IB or II code.
• Check every condition and documentation requirement attached to the code.
• Assess consequential product-information and Module 2 changes.
• Check current EMA or CMDh procedural guidance for the authorisation route.

Reading the conditions properly

Most misclassifications are not disagreements about which code describes the change. They are a code selected correctly and then applied without meeting every condition attached to it.

The conditions are cumulative. A Type IA entry typically lists several, and all of them must hold — not most. The moment one fails, the change is no longer that Type IA; it usually falls to Type IB unless the guideline directs otherwise. This is where the difference between a clean 30-day notification and an unexpected assessment procedure is decided, and it is decided by reading a numbered list carefully rather than by regulatory judgement.

Two conditions are misread often enough to be worth naming. Conditions that require something to remain unchanged mean unchanged in the approved dossier, not unchanged in practice — an undeclared drift does not satisfy them. And conditions referring to an approved specification or method mean the currently approved version, which may not be the version your site is running if an earlier variation is still under assessment.

Where a condition cannot be met and no other code fits, the change is unclassified. That is a defined route with its own handling, not a licence to pick the nearest code and hope the assessor agrees.

• List every condition for the chosen code and mark each met, not met, or unverifiable.
• Confirm 'unchanged' conditions against the approved dossier, not current practice.
• Check whether a pending variation changes what 'currently approved' means.
• Where a condition fails, re-classify rather than reinterpret the condition.

When nothing in the guideline fits

A change with no matching entry is an unclassified change, and the framework provides a route for it: a recommendation can be requested on how such a change should be classified and handled. That route exists precisely because the guideline cannot enumerate every change a real product will need.

The failure mode is treating an imperfect match as a match. Selecting the nearest code for a change that does not satisfy its scope produces an application an assessor has to reclassify, which costs more time than asking would have. If the scope statement does not describe your change, the code does not apply to your change, however close the wording looks.

Plan for the lead time. A recommendation is a step before the submission, not a parallel activity, and it belongs in the timetable as soon as the classification review flags that nothing fits.

IA versus IA-IN, and why the timing matters

Type IA variations split into those that may be notified within twelve months of implementation and those requiring immediate notification. The distinction is set by the guideline entry, not by how urgent the change feels.

The practical consequence is a housekeeping obligation rather than a scientific one. Annual-notification changes accumulate, and the twelve-month clock runs from implementation of each individual change, not from a convenient reporting date. Products with several sites and frequent minor changes are where this quietly slips, and a missed notification window is visible to an inspector long after the change itself has become routine.

Immediate-notification entries usually reflect something an authority needs to know before it matters — a change affecting the manufacturing or control arrangements they would otherwise rely on. Treat the classification as the deadline, and record the implementation date with the classification decision so the two never drift apart.

Grouping, worksharing and consequential changes

Changes rarely arrive alone. A single site change can pull an updated specification, a revised method, new stability data and a product-information change behind it, and each of those may carry its own code.

Grouping submits several changes to one authorisation in a single application. Worksharing handles the same change across several authorisations. They solve different problems and are not interchangeable, and there are rules on which combinations are permitted — a group is not simply whatever the applicant would prefer to submit together.

The classification of a group follows its most demanding member: adding a Type II to a set of Type IAs makes the whole application a Type II with that timetable and that assessment. That is often still the right choice, because splitting genuinely linked changes across separate procedures creates inconsistency between what different assessors see. Decide deliberately and record why.

The trap is the consequential change nobody classified. A method change that alters a specification, a specification change that alters the product information, an excipient change that touches the elemental impurity or nitrosamine assessment — each has to be identified and classified rather than absorbed into the parent change's paperwork.

• Map consequential changes before choosing the application shape.
• Confirm the intended grouping is permitted, not merely convenient.
• Classify the group by its most demanding member and plan that timetable.
• Check whether the same change across other authorisations qualifies for worksharing.

Where the route changes the answer

The classification framework is common across the EU, but the handling is not. A centrally authorised product follows EMA post-authorisation procedures; an MRP or DCP product runs through the Reference Member State with Concerned Member State involvement and CMDh operational guidance; a purely national authorisation follows that authority's own requirements.

The classification code usually does not change between these routes. What changes is who assesses it, what the timetable looks like, which forms and administrative documents are needed, whether national translations are in scope, and what happens if the procedure raises questions. A classification note that stops at the code is only half a plan.

This is also where fees, national administrative requirements and language obligations sit — outside the classification guideline entirely, and easy to discover late.

Record the reasoning, not only the code

A review-ready classification note should cite the code and source version, map each condition to evidence, list assumptions, and identify any linked or consequential changes. It should also state whether grouping or worksharing is being considered.

Write down what would change the answer. A classification that depends on a supplier confirmation not yet received, or on a pending variation being approved first, should say so — that sentence is what stops the decision being silently invalidated three weeks later when the underlying fact arrives.

Cite the source version and the date you read it. The Classification Guideline and the procedural guidance behind it are revised, and a note that cites "the classification guideline" without a version cannot be re-checked by the reviewer who inherits it.

Classification is a regulatory judgement. A qualified professional should confirm the current source version, product facts and procedure before the application is prepared or submitted.