Regulatory Information Management Software: Why Nobody Can Answer What Is Approved Where Without a Manual Survey

The question nobody in the building can answer quickly

A manufacturing site proposes a change to a supplier of an excipient. Somebody asks the obvious question: which registrations does this affect, and in which markets does it require a variation before we can implement it. In most organisations the answer takes a week. Regulatory affairs emails the market leads, the market leads check their own files, three of them are on holiday, two answer from memory, and the resulting list is assembled in Excel and is probably not complete.

That is the whole problem. Registration status, licence numbers, approved specifications, approved labelling versions, variation histories, renewal dates and commitments made to health authorities exist in the organisation, but they exist as a federation of local spreadsheets, shared drives and people. Nobody holds a single answer to what is approved where, under which version, with which obligations attached.

The consequences are ordinary until they are not. A missed renewal date means a licence lapses and supply to that market stops. An implemented change that required prior approval in a market you overlooked becomes a compliance issue on a product that is already shipping. A commitment made during approval, to submit a study by a certain date, is discovered late because it lived in a letter in a folder.

What Veeva, ArisGlobal, Ennov and Amplexor actually leave to you

Veeva Vault RIM is the market's centre of gravity and integrates registrations with document management, which is a genuine structural advantage. ArisGlobal LifeSphere RIMS and Ennov RIM are credible alternatives, and Amplexor has real depth in regulatory content. These products are not the problem.

The problem is that a regulatory information management system is ninety percent data model and ten percent screens, and the data model has to be yours. What counts as a product in your organisation? Is it the brand, the medicinal product as defined for a market, the presentation, the pack, the formulation, or all of them in a hierarchy? Which of those does a licence attach to? How do you represent a product that is the same formulation but a different strength and a different name in three markets? Every packaged system arrives with an opinionated hierarchy, and implementation is largely the exercise of forcing your reality into it. That exercise is where the cost and the calendar go, and it is why implementations routinely take longer than the software evaluation suggested.

The second gap is the link from a manufacturing or specification change to affected registrations. This is the single most requested capability and the one most likely to be delivered as a report you have to interpret rather than an impact analysis you can trust. It requires that your registrations record what was actually approved at a level of detail most organisations have never captured, which is a data problem no vendor can solve for you.

The third is legacy dossier migration. The information you need is inside approved dossiers, cover letters and approval documents accumulated over decades. Extracting it is manual, expensive and unglamorous, and it is the majority of the effort in any RIM programme regardless of what you buy or build.

The data model is the project

Get this wrong and nothing else matters. A workable model separates a small number of things clearly. There is the product concept as your organisation thinks about it. There is the medicinal product as a market defines it, with its own name, strength, form and pack presentations. There is the licence or authorisation, which is what a health authority actually granted, with a number, a date, a holder and a status. There is the application or submission, which is the event that created or changed a licence. And there is the registered detail: the manufacturing sites, specifications, shelf life and labelling version that a specific authority approved.

The international standard for identification of medicinal products is worth aligning to where it helps, particularly for European obligations, but treat it as a target rather than an initial constraint. Organisations that start by trying to be fully standard compliant on day one usually stall, because the standard demands data granularity they do not yet possess.

The rule we apply on these builds is simple: model what you can actually populate, and design so that granularity can be increased later without restructuring. A model that is beautiful and empty helps nobody.

Variations and renewals are calendar problems with real consequences

Every market has its own variation classification and its own timelines. The European Union has minor and major variation types with different notification and approval pathways, plus a renewal cycle. Other markets have their own equivalents, their own local requirements and in some cases requirements for legalised documents that take weeks to obtain. Renewal dates fall on a market specific calendar with a submission lead time that is longer than most people remember.

The operational failure is not usually forgetting a renewal outright. It is starting it too late, discovering that a required document needs an apostille or a certificate of pharmaceutical product that itself takes six weeks, and then submitting under pressure. A system earns its keep by working backwards from the deadline through the lead time for every dependent artefact, and by owning the escalation before the point at which recovery is still possible.

The same applies to commitments. A commitment made at approval to submit data by a given date belongs in the same obligation register as a renewal, with an owner, a due date and a linked deliverable, rather than in a folder.

What a custom build must include

• A product, medicinal product, presentation and licence hierarchy that matches how your organisation actually operates.
• Registered detail per licence: manufacturing and testing sites, specifications, shelf life and storage, and the approved labelling version.
• Application and submission records linking what was submitted to what was approved and when.
• Variation and renewal tracking with market specific classifications, lead times and backwards planning from the deadline.
• A health authority commitment register with owners and linked deliverables.
• Change impact analysis: given a proposed manufacturing or specification change, the list of affected licences and the required regulatory action per market.
• Labelling version control linking approved text to the licences it applies to, and to affected artwork.
• Integration with your document management system, so a licence links to the actual approval letter rather than a reference to one.
• Reporting that answers the standing questions without a query being written: what is approved where, what is due in ninety days, what is at risk.
• Audit trail and controlled access, because this is the record of your legal permissions to sell.

What it costs and how long it takes

Across the enterprise data platforms Digital Heroes has delivered, a first release covering the product and licence model, registration status and variation and renewal tracking runs $130,000 to $280,000 and ships in 16 to 24 weeks. A full platform adding commitments, labelling version control, change impact analysis and submission planning runs $350,000 to $900,000 across 12 to 22 months.

The dominant cost in this category is not software. It is data. Populating registered detail from legacy dossiers is manual work by people who understand regulatory content, and for a portfolio of any size it is measured in person months. Any proposal that does not carry an explicit line for data collection is either naive or hiding it, and this is the single most useful thing to check in a quotation. Other drivers: the number of markets and the diversity of their regulatory frameworks, document management integration, whether you need to produce data for European electronic submission of product information, and how many legal entities and licence holders you operate through.

What keeps cost down: the top markets by revenue first, current registrations rather than full history, and accepting a defined granularity for registered detail rather than trying to capture everything a dossier contains.

Build versus buy, stated plainly

Buy Veeva Vault RIM if you already run Vault for regulatory documents. The integration between registrations and the documents that support them is real value and rebuilding it is not sensible. Buy Ennov or ArisGlobal if their model fits your portfolio shape and you want an established answer.

Build when two or more of these are true. Your product hierarchy genuinely does not fit a vendor model, which is common for companies with a mixed portfolio of medicines, devices and combination products. You have made an implementation attempt already and it stalled on data modelling, which we see often enough that it deserves naming. Change impact analysis is the capability you actually need and no vendor demonstration has convinced you theirs works on your data. Your registrations must integrate tightly with systems you already own, such as an enterprise resource planning (ERP) system that holds manufacturing sites and specifications. Or licence cost across a large regulatory affairs population is out of proportion to the number of people who genuinely need write access.

How to choose a developer for regulatory information software

Ask them to model your portfolio on a whiteboard before you sign anything, including your most awkward product, the one that is the same molecule under three names with different strengths in different markets. A developer who has done this separates product, medicinal product, presentation and licence without prompting. A developer who draws products and countries is about to learn regulatory affairs on your budget.

Ask how change impact analysis will work, specifically. The honest answer is that it depends entirely on the granularity of registered detail you capture, and a developer who promises it without discussing that dependency is selling you something they cannot deliver.

Ask what their plan is for data collection, because it is most of the programme. If they describe it as your responsibility and move on, they have quoted for the easy half.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the code is yours from the first commit. Also agree an export format for the registration data itself on day one, because this record outlives any system and you will migrate it again in a decade.