1.0. When the Regulatory Form Cannot Be Created

Regulatory data quality is no longer simply a documentation concern. It is becoming an operational compliance control.

Imagine a submission team preparing an application against a regulatory deadline. The dossier is complete. The scientific content has been reviewed. The internal approvals are in place.

But the web-based electronic Application Form, or eAF, will not generate correctly.

A product record in the Product Management Service (PMS) is incomplete. A migrated legacy record contains an inconsistency. A product is grouped differently from the way the form-generation logic expects. Or an internal mapping has not kept pace with a change in the regulatory data model.

The immediate problem is not a scientific deficiency. It is not even necessarily a visible application failure.

It is that the regulatory process cannot proceed because the data and configuration supporting the form are not in a usable state.

That is the operational significance of the European Medicines Agency’s digital regulatory transformation. The move toward the IRIS EPIC 3 programme, the Product Lifecycle Management (PLM) Portal, PMS, web-based eAF, electronic Product Information (ePI), and electronic Common Technical Document (eCTD) 4.0 is changing more than the format of regulatory submissions.

It is changing where compliance risk appears.

In Part 1 of this series “EMA AI Roadmap: 61 Use Cases, Continuous Monitoring, and GxP Compliance”, we argued that artificial intelligence cannot be treated as a point-in-time deployment. Models, prompts, retrieval sources, vendors, workflows, and data can change after release. Static validation evidence may therefore become an incomplete representation of the system in operation.

The same principle now applies beyond AI. As regulatory processes become more connected and data-driven, pharmaceutical companies must demonstrate not only that individual applications were validated at implementation, but that the connected data, interfaces, configurations, and processes supporting regulatory outcomes remain controlled over time.

That is the broader case for Continuous Intelligence.

“The question is no longer only whether a system was validated. It is whether the connected regulatory ecosystem remains fit for purpose.”

2.0. From AI Lifecycle Risk to Regulatory Infrastructure

The EMA’s transformation is not a single technology programme. It is a set of connected changes that are moving regulatory operations away from document-centric workflows and toward information that can be created once, governed, reused, and consumed across multiple processes.

EPIC 3 is the third major phase of the IRIS Regulatory Procedure Management roadmap. Earlier phases moved a range of procedures onto IRIS, including variations, Article 61.3 notifications, transfers, periodic safety update reports, renewals, and referrals. EPIC 3 extends that direction into areas such as initial marketing authorisation applications, fee processes, eligibility and pre-submission activities, accelerated assessment requests, advanced therapy medicinal product certification, and clinical-data publication.

The eAF transition is part of the same architectural movement. The traditional interactive PDF is being supplemented and, in relevant workflows, replaced by a web-based form hosted through the PLM Portal. The important distinction is not simply that users interact with a browser rather than a PDF.

The web-based eAF retrieves product information from PMS.

That means the form is no longer only a document that a user completes. It is an operational view generated from underlying regulatory data. The quality of the submission therefore depends on the quality, structure, grouping, and availability of the information behind it.

This creates efficiency. It also moves the control point.

Under a document-centric model, an upstream discrepancy might remain hidden until a later review. Under a connected data model, the same discrepancy may prevent the form from being generated or validated at the start of the process.

The failure has moved upstream. When structured master data drives a regulatory form, data integrity becomes part of submission readiness.

3.0. The New Regulatory System of Record Is an Ecosystem

For many years, regulatory processes were organized around documents. Forms were populated, dossiers were assembled, and information was reviewed downstream. That sequence created a degree of operational tolerance: an error in an upstream system could sometimes be corrected before it affected the submission.

The emerging EMA architecture is different. Regulatory information is increasingly treated as reusable data rather than as isolated content embedded in individual documents. PMS is being developed as a source of medicinal product master data, supported by interfaces and ongoing data-quality activities.

This changes the role of regulatory data. It is no longer merely supporting the submission. It is becoming part of the submission infrastructure.

Once a product record is reused across multiple regulatory processes, a single inaccurate element can have consequences beyond the original record. An incorrect identifier, an incomplete strength, an unsuitable product grouping, or a migration discrepancy may affect form generation, publishing, product information, or downstream submission activities.

The benefit of reuse is consistency and efficiency when the underlying information is correct. The risk is propagation when it is not.

That is why master data can no longer be treated as a static administrative asset. It must be governed as a controlled component of the regulated process, with clear ownership, traceability, reconciliation, and change visibility.

4.0. Why the eAF Transition Matters for Regulatory Data Quality

The practical lesson from the web-based eAF is simple but consequential.

A regulatory data problem that once might have been discovered during document review can now become an immediate operational failure.

Consider a product record migrated from a legacy regulatory system into PMS. One field is incomplete, or the record is associated with the wrong product grouping. Historically, a reviewer might have identified the discrepancy while checking the completed form or supporting documentation.

In the new workflow, the form depends on the PMS record before that review can occur. If the data does not support the expected form logic, the eAF may not generate correctly or may fail validation.

The organization has not merely found a data quality issue. It has lost the ability to complete the submission through the intended process.

This is why migration from legacy sources such as xEVMPD and SIAMED requires particular attention where applicable. Historical records may exist successfully in a new system without having been reconciled or verified for the new digital workflow. A record can be present, searchable, and technically available while still being unsuitable for submission use.

The relevant chain is therefore broader than the form itself.

A check at only one point in the chain cannot provide assurance across the whole process.

“A record can be technically available and still be operationally unfit for regulatory use.”

5.0. What the EMA Digital Shift Changes for GxP Validation

The key question for Quality and computerized-system validation teams is no longer simply whether an application was validated when it was implemented.

The more important question is whether the end-to-end regulatory ecosystem remains controlled as its components change.

That ecosystem includes EMA-managed platforms such as IRIS, the PLM Portal, and PMS. Marketing authorization holders do not validate those platforms as if they owned their development lifecycle. They do, however, need to understand their intended use, dependencies, service assumptions, user responsibilities, and available compensating controls. Submission dry runs, independent reconciliation, controlled access, and documented procedures for managing platform changes may all form part of that assurance model.

The second layer consists of the organization’s own regulatory information management and eSubmission systems. These systems may send data to, receive data from, map information for, or transform information between internal and external platforms. A change to an interface, automated form-population rule, scheduled job, or transformation mapping may affect the regulated process even when the core application has not changed.

The third layer which includes migration, reconciliation, deduplication, mapping, and verification processes, is often less visible but equally important. These activities establish whether legacy information can be relied upon in the new workflow. If they are automated or used to support GxP decisions, they may themselves require a documented assessment of their intended use, controls, and validation status.

The validation boundary is therefore expanding.

It no longer stops at the application. It includes the connected ecosystem that supplies, transforms, governs, and consumes the information used to produce a regulatory outcome.

6.0. Regulatory Readiness Is an Operating Capability

Readiness for the eAF and related EMA changes should not be reduced to installing a new release or downloading a new form. It begins with reconciliation. Organizations need to compare relevant PMS records with their internal regulatory source of truth and resolve discrepancies before a deadline-critical submission depends on them. Where legacy data has been migrated from sources such as xEVMPD or SIAMED, verification should establish whether the records are complete, correctly mapped, appropriately grouped, and suitable for the intended workflow.

Operational readiness also depends on conditions that are easy to overlook. Product grouping must support the logic used to generate the form. Users must have the appropriate PLM Portal roles. Submission teams should conduct dry runs before relying on the web-based process for a critical deadline. Standard operating procedures (SOP) and Work Instructions (WI) need to reflect the new workflow rather than reproduce the assumptions of the PDF process. Release and version management should account for changes to eAF functionality and related platforms. Where a technical exception permits use of a PDF route for a centralized procedure, the organization should have clear governance for determining and documenting when that exception is justified.

These activities should be connected to a documented, risk-based GxP impact assessment. The assessment should identify affected systems, interfaces, data flows, configurations, procedures, and validation evidence, then determine what targeted testing or other assurance is proportionate. The objective is not to create a large validation project for every change. It is to ensure that material changes are visible, assessed, and supported by appropriate evidence.

7.0. Availability Is Not Regulatory Assurance

One of the most misleading signals in a connected regulatory environment is that a system remains technically available.

An interface may be running. Messages may still be transmitted. Jobs may complete without errors. Yet the mapping behind the interface may no longer be suitable after a change to the data model or platform behavior.

For example, an internal RIM system may continue sending product information successfully while a field has acquired a new meaning in the receiving environment. The connection is operational, but the information is no longer being interpreted as intended.

This is the difference between availability and continued suitability.

A migrated record can exist in PMS without being reliable. An eAF can open in a browser while failing to generate the expected content. A workflow can complete while bypassing a control that was assumed to be present. A user can have access to a platform without having the correct role for the submission activity.

Technical uptime is therefore only one part of the assurance picture. The organization also needs to know whether the data, mappings, configurations, access conditions, and procedures remain aligned with the regulated purpose of the process.

8.0. The Wider Digital Regulatory Ecosystem

The eAF is only one expression of this change.

The EMA’s work on ePI, PMS, and eCTD 4.0 points toward a broader regulatory environment in which information is increasingly structured, reusable, and exchanged across systems. ePI is moving product information toward structured Fast Healthcare Interoperability Resources-based XML. eCTD 4.0 is replacing the legacy version 3.2.2 standard.

These initiatives should not be treated as unrelated technology projects. They depend on common foundations: reliable product data, controlled mappings, stable interfaces, clear ownership, and the ability to understand the impact of change.

The same inaccurate product attribute may affect more than one process. The same migration discrepancy may surface in more than one output. The same obsolete mapping may create problems across multiple regulatory channels.

This is why a program focused on regulatory master-data integrity can support several transformation initiatives at once. The goal is not to centralize every activity into one system. It is to understand the data and dependencies that connect them.

9.0. Continuous Intelligence Beyond AI

This brings the series back to its central theme.

In Part 1, the challenge was that AI systems can change after deployment. The model may change. The prompt may change. The retrieval source may change. The vendor, workflow, or data may change.

The EMA’s digital regulatory transformation shows that the same lifecycle problem exists in more traditional systems.

PMS records can change. eAF versions can change. External platform behavior can change. Interfaces and mappings can change. User access and workflow configurations can change. Internal RIM systems can change independently of the platforms with which they interact.

Static validation evidence cannot, by itself, demonstrate that the resulting ecosystem remains controlled.

Continuous validation does not mean revalidating everything continuously. It means detecting relevant change, assessing its GxP impact proportionately, reconciling critical data, triggering targeted regression testing where needed, preserving traceable evidence, and maintaining a current view of whether the process remains suitable for its intended use.

That is the practical meaning of Continuous Intelligence in regulatory operations.

“Continuous validation is not continuous revalidation. It is continuous awareness of change, impact, risk, and evidence.”

10.0. Where Continuous Intelligent Validation Fits

Continuous Intelligent Validation (cIV), can be understood as an operating model for connecting these activities. It brings together change detection, data-integrity monitoring, impact analysis, risk assessment, targeted validation activity, and evidence generation.

cIV does not replace risk assessment, validation planning, testing, Quality oversight, or human accountability. Its purpose is to help organizations identify relevant changes earlier and direct attention where the potential GxP impact is greatest.

In one case, a change to a low-risk configuration may require documentation but no extensive regression program. In another, a change to a product-data mapping may affect form generation, publishing, and submission readiness, requiring targeted testing and reconciliation. The value of cIV is helping distinguish between those situations with better visibility and more current evidence.

Applied to the EMA ecosystem, that capability could include monitoring critical product records, detecting changes to interfaces and mappings, identifying affected requirements and controls, prioritizing discrepancies, triggering focused testing, and preserving a traceable record of decisions and outcomes.

The objective is not automation for its own sake. It is proportionate assurance in an environment where change is continuous and dependencies are distributed.

The future of regulatory compliance will not be defined by proving that individual systems were validated once. It will be defined by demonstrating that the connected data, systems, interfaces, configurations, and processes that create regulatory outcomes remain controlled over time. That is the shift from digital transformation to Continuous Intelligence and from static validation evidence to Continuous Intelligent Validation.

11.0. References

1. EMA Digital Transformation: PMS, eAF, ePI and eCTD 4.0
2. ‍Regulatory Procedure Management in IRIS roadmap (Epic 3)
3. #123: EMA AI Roadmap: 61 Use Cases, Continuous Monitoring, and GxP Compliance

‍

About the authors

Nagesh Nama
CEO, xLM Continuous Intelligence | Founder, ValiMation

Nagesh is a pioneer in AI/ML-driven GxP compliance with nearly three decades of experience helping pharmaceutical, biotech, and medical device companies navigate validation, data integrity, and regulatory compliance. He is the founder and CEO of both ValiMation (founded 1996) and xLM Continuous Intelligence, the company that first introduced a Continuous Validation platform supporting IaaS/PaaS/SaaS environments compliant with 21 CFR Part 11 and Annex 11. Today, xLM offers a comprehensive suite of continuously validated AI/ML managed services spanning intelligent validation (cIV), predictive maintenance, temperature mapping, and GxP AI agents. Nagesh is a member of the Forbes Technology Council and the Fast Company Executive Board, a contributor to Forbes and Fast Company, and has been featured on Microsoft's AI Agents Vlog. He holds an M.S. in Manufacturing Engineering from the University of Massachusetts, Amherst.

Kashyap Joshi
Program Manager, AI/ML ContinuousOS Apps | xLM Continuous Intelligence

Kashyap Joshi is a Program Manager at xLM, where he leads the implementation of complex AI systems for life sciences organizations by aligning stringent GxP regulatory requirements with next‑generation technology and xLM’s ContinuousOS Suite of Apps to deliver measurable ROI, continuous compliance, and long‑term transformation for clients across pharma, biotech, and medical devices.