25.24 — Regulatory Affairs as a Working Job

A company wants to change the supplier of a filter used in one purification step of a biologic sold in forty-two countries.

Technically it is a small change. Regulatorily, it is: an assessment of whether the change affects product quality; a comparability exercise if it might; a decision, per country, about whether this needs prior approval, notification, or only a note in the next annual report; forty-two separate regulatory transactions in the right formats and languages; tracking of which countries have approved so the factory knows when it may use the new filter where; and a plan for the period during which some markets are supplied from the old process and some from the new.

That is regulatory affairs. It is not paperwork about science — it is the operational discipline of keeping a product legally sellable in every market, permanently, while it keeps changing.

What the function is responsible for

Four responsibilities cover almost everything a regulatory group does.

Strategy. Which markets, in which order, by which pathway, with which designations (Chapter 25.8), and what evidence each regulator will demand. Getting this wrong costs years, and the largest single lever is agreeing the Phase III design with the agency in advance at the end-of-Phase-2 meeting.

Submissions. Assembling and filing everything: the original application, and then everything afterwards.

Labelling. Owning the approved text of what the product is and how it is used, in every market.

And lifecycle management. Every change, every renewal, every commitment, forever.

The last one is the largest by volume and the least understood from outside. A company's regulatory department spends far more of its time on products already approved than on new ones.

Meetings with the agency, which are the real work

A great deal of regulatory success is decided in structured meetings before anything is submitted, and each type has a purpose.

Pre-IND — is the nonclinical package adequate, and is the first study design acceptable?

End of Phase 2 — the most important meeting in development, where the pivotal trial design, the primary endpoint, the analysis and the safety database size are discussed. Agreement here removes the largest risk in the programme, and disagreement discovered here is far cheaper than disagreement discovered after a three-year trial.

Pre-submission — what will the application contain, in what format, and what does the agency expect to see?

And various scientific advice procedures in Europe and other regions with similar intent.

The mechanics matter because they explain how clients behave. A meeting is requested with a package of questions and the company's own positions. The agency often provides written responses in advance, and sometimes those responses answer everything, and the meeting is cancelled by agreement — which is a good outcome, not a snub. Everything discussed is minuted, and those minutes become the reference point for years.

Submissions: the mechanics of eCTD

Chapter 25.14 covered the Common Technical Document's five modules. The operational reality of maintaining one deserves its own explanation, because it is where regulatory operations teams live.

An eCTD submission is not a document — it is a structured set of files with an XML backbone describing each file's position in the module hierarchy and its relationship to what was submitted before: new, replacing an earlier file, or removing one from the current view.

Every submission for a product goes into the same growing structure, called a lifecycle. Sequence 0000 is the original application; every subsequent transaction gets the next number, and the current state of the dossier is the result of applying all sequences in order. A product on the market for fifteen years may be at sequence 0400, and reviewers can view the current version of any document or its whole history.

Which produces the operational constraints that dominate regulatory operations work. Sequences must be submitted in order and cannot be revised once sent. Files must meet strict technical requirements — searchable text, bookmarks, working internal links, size limits, no security settings blocking the reviewer. And validation software checks the whole submission before sending, because a technical rejection wastes days at exactly the moment they matter.

Publishing teams do this work, and the tooling around it — document assembly, hyperlinking, validation, dispatch through regulatory gateways, and archiving — is a well-defined outsourcing market with clear quality metrics.

Labelling, and why it is harder than it sounds

The label is the legal statement of what the product is (Chapter 25.13). The complication is that a global product has many labels, and they must stay related to each other in a controlled way.

The structure most companies use is a hierarchy. A core company data sheet holds the company's own position on the product's safety and efficacy information. From it, regional and national labels are derived, each shaped by local requirements, local approvals and local language.

Then a safety signal produces a change to the core document, and the change must propagate. Every affected market needs a submission, each in its own format and language, each with its own approval timeline — so for a period, the same product legally carries different warnings in different countries. Managing that gap, and knowing exactly which version is approved where on any given day, is the job.

And the label reaches into operations everywhere. Packaging artwork must match the approved text. Patient information leaflets must match. Training materials, medical information responses and promotional materials all derive from it. A label change is therefore a coordinated release across regulatory, packaging, supply chain, medical and commercial — which is why labelling systems, artwork management and change control are usually linked, and why they are so often not.

Variations: the machinery of change

Once a product is approved, every change to it must be handled through a defined route, and the routes differ by region in ways your systems must model.

In Europe, changes are classified as variations. Type IA are minor changes that may be implemented immediately and notified afterwards, some within twelve months. Type IB are minor changes notified before implementation, with the authority having a short period to object. Type II are major changes requiring assessment and approval before implementation. And extensions — a new strength, a new route of administration — are treated almost as new applications.

In the United States, the categories are different but the logic is the same. A prior approval supplement must be approved before the change is made. A "changes being effected in 30 days" submission allows implementation thirty days after filing unless the agency objects. A "changes being effected" submission allows immediate implementation on filing. And minor changes are simply described in the annual report.

The classification decision is the crux, and it is a real risk point. Implementing a change that required prior approval, without it, means the product made afterwards does not conform to its approved application — with consequences up to recall. So the assessment is documented, conservative, and made by regulatory rather than by the engineer who wants the change.

And there is a mechanism designed to reduce this friction, worth knowing because clients are actively adopting it. A post-approval change management protocol, formalised in ICH Q12, lets a company agree with the regulator in advance how a specific future change will be made and evaluated — so that when it happens, it can be handled through a lower-reporting route. It is the regulatory equivalent of the predetermined change control plan for AI devices in Chapter 25.16, and the same principle underlies both: agree the rules for change in advance rather than negotiating each instance.

The other continuous obligations

Beyond variations, several duties run permanently and generate steady work.

Renewals. Many markets require periodic renewal of a marketing authorisation, with a defined data package and a hard deadline. Missing one can mean the product is no longer legally marketable, which is an entirely avoidable and occasionally real disaster.

Commitments. Post-approval studies required at approval must be tracked, completed and reported, and their status is public in some regions.

Annual reports summarising the year's changes, safety information and manufacturing activity.

Promotional review. In the United States, promotional materials must be submitted to the agency's promotional advertising office at the time of first use, and companies operate an internal review committee — medical, legal and regulatory — that approves every piece before it goes out. This committee is a chokepoint that most commercial projects underestimate, and building the workflow that runs it is a common and valuable engagement.

And regulatory intelligence — monitoring what regulators publish, because requirements change constantly and a client that finds out late about a new format requirement or a new deadline pays for it.

The systems, and the one that is usually broken

Regulatory information management — RIM — is the system that holds the answers to questions a regulatory department must be able to answer instantly.

Which products are registered in which countries, in which strengths and forms. What the approved label says in each. Which submissions are in progress and at what stage. Which commitments are outstanding and when they are due. Which manufacturing sites are registered for which product in which market. And when each renewal falls due.

In a great many companies this information lives across several systems, a shared drive and a handful of spreadsheets maintained by people who have been there a long time. That is not a caricature; it is the normal state, and it is why RIM implementations are a large and recurring category of project.

Two related pieces of infrastructure are worth knowing by name. Regulatory gateways transmit submissions electronically to agencies with acknowledgements. And the identification of medicinal products standards — the IDMP family, implemented in Europe through the substance, product, organisation and referential data services — define a common way to identify a medicine unambiguously across systems and jurisdictions. This is a genuinely hard master data problem: the same product has different names, different codes, different pack sizes and different holders in different markets, and making it all resolve to one identity is exactly the kind of work an engineer can do well and a regulatory specialist cannot do alone.

What makes someone good at this job

Worth stating, because it tells you what your counterpart is optimising for and how to be useful to them.

A good regulatory professional is accurate rather than fast, because a wrong submission is worse than a late one. They know what the regulator will ask before the regulator asks it. They say no clearly and early, with a reason, rather than late. And they maintain the relationship with the agency, because a company that is trusted gets the benefit of the doubt on a borderline question and one that is not, does not.

The practical implication for you is direct. Bring regulatory into a project at the design stage, not at the end. A system designed without them will fail its assessment; a system designed with them usually sails through, because the person who will be asked to defend it helped decide what it does.

Next: Chapter 25.25, patient support programmes — the part of the industry that touches actual patients directly, and the tangle of privacy, reimbursement and safety rules that comes with it.