Regulatory Information Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the product hierarchy get underestimated so consistently?

Because everyone in the room believes they already know what a product is, and no two of them agree. Commercial thinks of the brand. Manufacturing thinks of the formulation and the pack. Regulatory affairs thinks of the medicinal product as a specific market defines it, with its own name, strength, dosage form and presentations. Supply chain thinks of the material code. All four are correct within their own function, and a data model has to hold every one of them without collapsing them together.

This is where RIM programmes lose their calendar. A workable model separates a small number of things cleanly. The internal product concept as your organisation thinks about it. The medicinal product as a market defines it. The presentations and packs. The licence or authorisation, which is what a health authority actually granted, with a number, a date, a holder and a status. And the registered detail, meaning the manufacturing and testing sites, specifications, shelf life, storage conditions and approved labelling version that a specific authority approved.

Packaged systems arrive with an opinionated hierarchy, so implementation becomes the exercise of forcing your reality into theirs, and that exercise is why implementations routinely take longer than the software evaluation suggested. A custom build removes the forcing but not the thinking. Do the modelling on a whiteboard with your most awkward product in front of you, the one that is the same molecule under three names at different strengths in different markets, before anyone writes code. If that product does not fit the model, nothing else will either.

What goes wrong extracting registered detail from legacy dossiers?

The information you need lives inside approved dossiers, approval letters, cover letters and variation correspondence accumulated over decades, in several languages, held by market affiliates who each organised their files their own way. Extracting it is manual work performed by people who understand regulatory content, and for a portfolio of any size it is measured in person months. It is also the majority of the effort in any RIM programme regardless of whether you buy or build.

Three specific failures recur. Affiliates report from memory rather than from the approval document, because reading the dossier takes longer than answering the email, and the resulting record looks authoritative while being an assertion. Variation histories are incomplete, so the current registered detail cannot be reconstructed by replaying changes and has to be taken from the most recent approval instead. And approved labelling versions are recorded as a reference to a document that has since been superseded in the document system, which means the link resolves to the wrong text.

The fix is to make provenance a required field. Every registered detail record carries the document it came from and whether it was read from the approval or asserted by a person, and reports show the mix. Set a defined granularity target and stop at it rather than trying to capture everything a dossier contains. Sequence collection by revenue and by risk, not alphabetically. And accept that partial coverage with honest provenance is far more useful than complete coverage you cannot trust, because the first time someone acts on an asserted value that turns out to be wrong, adoption of the whole system stops.

Why do document and enterprise system integrations break after launch?

A licence record is only useful if it links to the actual approval letter rather than to a reference to one, which makes the document management connection load bearing rather than convenient. It breaks in ordinary ways. Documents are moved or reclassified during a housekeeping exercise and links resolve to nothing. A document is superseded by a new version and the licence now points at text that was never approved. A migration between document platforms renumbers everything.

The enterprise resource planning (ERP) connection has a different failure. It holds manufacturing sites, material specifications and pack configurations, which is exactly the data that registered detail has to be compared against for impact analysis. Master data changes there constantly, and a site renamed or a specification revised in ERP with no corresponding event in the regulatory record produces impact analysis that quietly stops matching reality.

The fix is to link by stable identifier and version rather than by location or by name, and to validate links on a schedule so a broken or superseded reference raises an alert rather than waiting to be discovered by an inspector. On the ERP side, subscribe to master data change events and route anything touching a registered site or specification into a regulatory review queue. That queue is the mechanism that turns impact analysis from a report into a control, and it is the piece most often left out of the first release and most missed afterwards.

What happens when commitments and renewal lead times are not covered?

Renewals rarely fail because someone forgot them outright. They fail because the work started too late. A required document such as a certificate of pharmaceutical product or a legalised copy takes weeks to obtain, the submission needs it, and nobody worked backwards from the deadline through the lead time of every dependent artefact. So the submission goes in under pressure or the licence lapses, and a lapsed licence means supply to that market stops.

Commitments have the same shape and are missed more often, because they have no calendar of their own. A commitment made at approval to submit a study by a given date, or to report on a specified schedule, lives in a letter in a folder. It is discovered late, sometimes by the authority rather than by you, and it damages a relationship that takes years to rebuild.

The fix is one obligation register covering variations, renewals and commitments together, each with an owner, a due date, a linked deliverable and a defined consequence. Plan backwards from the deadline through every dependent artefact's lead time, and escalate at the point where recovery is still possible rather than when the date arrives. Model market specific variation classifications and their notification or approval pathways as data with effective dates, because the classifications change and a file for an earlier year has to reflect the rules that applied then.

Should you build custom or configure what you already own?

Buy Veeva Vault RIM if you already run Vault for regulatory documents. The integration between registrations and the documents that support them is genuine value and rebuilding it is not sensible. ArisGlobal LifeSphere RIMS and Ennov RIM are credible alternatives where their model fits your portfolio shape and you want an established answer, and Amplexor has real depth in regulatory content. If you hold one product in a handful of markets, a well governed spreadsheet is honestly sufficient and you should not spend the money on either path.

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 already attempted an implementation and it stalled on data modelling, which happens often enough to deserve naming. Change impact analysis is the capability you actually need and no demonstration has convinced you theirs works on your data. Your registrations must integrate tightly with systems you already own. Or licence cost across a large regulatory affairs population is out of proportion to how many people genuinely need write access.

Whichever path you choose, the data collection effort is the same. It is not a reason to prefer one over the other, and any comparison that treats it as a build cost only is misleading you.

How do hidden costs get into the quote?

A first release covering the product and licence model, registration status and variation and renewal tracking runs $130,000 to $280,000 over 16 to 24 weeks in our delivery experience. A full platform adding commitments, labelling version control, change impact analysis and submission planning runs $350,000 to $900,000 over 12 to 22 months. The dominant hidden cost in this category is not engineering.

• Data collection from legacy dossiers, which is regulatory staff time measured in person months. Any proposal without an explicit line for it is either naive or hiding it, and this is the single most useful thing to check in a quotation.
• Market count and framework diversity. Each distinct regulatory framework brings its own variation classifications, renewal cycles and document requirements to model.
• Document management integration, which is straightforward in principle and consumes real time in practice because it depends on how disciplined your document metadata already is.
• Legal entity and licence holder complexity. Groups that market through several holders in the same region carry more structure than the org chart suggests.
• Electronic product information obligations, where alignment to the international standard for identification of medicinal products demands granularity you may not yet hold and turns into its own data programme.

What separates a build that works from one that fails here?

Ask a prospective developer to model your portfolio on a whiteboard before you sign anything, using your most awkward product. 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 anyone who promises it without raising that dependency is selling 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 and the schedule will slip on the hard one.

Model what you can actually populate and design so granularity can increase later without restructuring. A model that is elegant and empty helps nobody, and teams that try to be fully standard compliant on day one commonly stall before delivering anything useful. Start with your top markets by revenue and current registrations rather than full history, because early wins fund the appetite for wider coverage.

Settle code ownership in writing before kickoff, and agree an export format for the registration data itself on day one. 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. This record outlives any particular system, and you will almost certainly migrate it again within a decade.