Medical Device Regulatory Information Management Problems: The 7 That Cost You a Market, and How to Avoid Them

Why does the product list with a country column keep getting built?

Because it is the shape of every product database anyone has seen, and for the first fifty registrations it holds. Then reality arrives. The same physical item is an accessory registered separately in one market, part of a kit registered as a single unit in another, sold under a partner's name in a third, and classified in a different risk class by a fourth authority. A registration attaches to some combination of family, model, configuration and accessory, and the combination differs per market.

What people do next is entirely rational and entirely fatal to the project. They stop trying to find one hierarchy and make regional lists instead, which is why your current workbook has a tab per region. The same physical product now exists many times with no link between the copies, so any question that crosses regions requires a person to interpret rather than a system to answer.

The fix is to separate the technical identity of a thing from the commercial and regulatory identities it takes in each market. One physical item exists once, with market specific classifications, names, identifiers and unique device identifier records attached to it. Registrations then reference items rather than duplicating them, and the cross region questions become queries.

This is a modelling problem rather than a technology problem, and it is the single most common reason these projects disappoint. Ask any developer to model a kit before you sign: a kit containing three items, two of which are separately registered in one market and none of which are separately registered in another. If the proposal is a product table with a country column, stop the meeting there.

What goes wrong when the registration spreadsheet is migrated as truth?

Importing it takes an afternoon and it is the wrong first move. Your workbook is maintained by two people, colour coded by an undocumented convention, and was last fully reconciled during a reorganisation. It contains registrations that lapsed and were never removed, registrations that were renewed under a slightly different product name and now appear twice, and holders who changed when a distributor agreement was reassigned.

Load that unchallenged and you have built a fast, confident system full of wrong answers, which is materially worse than the spreadsheet because your commercial team will now trust it. The change impact query that used to be qualified with caution comes back clean and definitive, and it is wrong.

Treat migration as a reconciliation with a defined owner, scoped in weeks with your regulatory team rather than as a data load. Rebuild the picture from primary evidence: certificates you hold, approval letters, distributor confirmations, authority databases where they are public. Compare that against the spreadsheet and give every difference a decision, an author and a date. Do the highest value markets first, because that is where a wrong answer costs most.

The output before go live is not a clean import. It is a list of every row the spreadsheet asserts that you cannot evidence, with a named person's judgement recorded against each. That list is uncomfortable and it is the most valuable thing the project produces, because it is the first honest picture your business has had of what it is actually allowed to sell and where.

Why do the product lifecycle and change control integrations break after launch?

They break on identity, because the engineering system and the regulatory system disagree about what a product is. Engineering thinks in parts and assemblies with revisions. Regulatory thinks in registered items and configurations. A mapping built between them on names or on descriptions detaches the first time a part is renamed, a revision supersedes another, or an assembly is restructured.

The second cause is change types that were never mapped. The integration is built around design changes because those are the ones everyone discussed, and then a supplier change, a sterilisation provider change, a manufacturing site addition or a label update arrives through the same change control process and falls through, because nobody wrote a rule for it. Nothing errors. Those changes simply do not raise a regulatory assessment, which is the exact scenario the integration existed to prevent.

The third is silence. Change control systems generally do not tell you when they stop sending, so an integration that quietly fails leaves regulatory unaware for weeks.

Defend it in three ways. Map on stable internal identifiers, never on names or descriptions, and treat display text as a label. Require a change type on every incoming record and route unmapped types to an exception queue that a named person clears, rather than discarding them. And alert on absence, meaning a rule that raises a ticket when no change records have arrived from a source within its expected window. Ask your developer what happens when engineering restructures an assembly, and expect a specific answer rather than reassurance.

What happens when distributor holdings and certificate dependencies are not modelled?

These are the two gaps that convert an administrative inconvenience into a commercial event, and both are routinely pushed to a later phase.

In a significant number of countries the licence is held by a local distributor or an in country representative, which means your access to that market depends on a commercial relationship rather than on a document you own. If the relationship ends, the registration may not transfer easily and your market access becomes a negotiation conducted from a weak position. Correspondence with the authority happens through them, in their language, and lives in an individual's email thread rather than in a record. When the relationship changes, you frequently cannot establish what evidence you actually hold.

The certificate cascade is the other. Dependency is not a date, it is a graph, and lead times belong on the dependency rather than on a global reminder threshold. A market that needs nine months of authority processing must appear on someone's board a year ahead, not at the same ninety day trigger as everything else.

Model both explicitly in the first release. The holder relationship carries the contract, its term, its transfer provisions and every affected registration. Certificates carry the registrations that rest on them, with market specific lead times as attributes. Alerts escalate to a named person with a defined chain rather than landing in a shared inbox. This is the least interesting feature you will build and it prevents the most expensive routine failure in the discipline, which is a product quietly falling out of a market because a document behind it expired.

Should you build custom or configure what you already own?

If you hold fewer than roughly fifty registrations across a handful of markets with a stable product family, do not build. A disciplined spreadsheet with a named calendar owner is honestly enough, and the failure at that scale is ownership rather than tooling.

If you are past that, buy before you build. Rimsys is built specifically for medical device regulatory information and understands device product hierarchies in a way pharmaceutically derived systems do not, and it will be running long before any build could be. Veeva Vault RIM is a serious platform and makes sense if you are already a Vault estate and can work with its model, whose origins are pharmaceutical rather than device. Ennov is a credible alternative. For many mid sized manufacturers one of these is the correct answer and the honest recommendation.

Build when configuring a product means describing your portfolio in a vocabulary your own team does not use. That happens when kits, configurations, private label variants and separately registered accessories genuinely do not fit, when a large share of your registrations are distributor held and you need contractual data alongside regulatory data, when change impact has to wire directly into engineering change control rather than being answered by email, or when you already lost market access to a lapse that a dependency model would have caught. In that last case the business case has been made for you.

How do hidden costs get into the quote?

Data reconciliation is the largest omission and it is consistently priced as a data load. Establishing which rows in your current spreadsheet are actually true is weeks of your regulatory team's time working alongside the build, and skipping it produces confident wrong answers rather than saving money. Get it in the plan as its own line with its own owner.

The second is portfolio complexity. Kits, configurations, private label variants and separately registered accessories are the single biggest driver of build cost, and a quote priced against your simplest product family is not a quote for the rest of it. Ask for the price of your most complicated product line specifically.

Then four more. Each distributor held market roughly doubles the commercial data you carry for it, so a quote priced on registration count alone will be short. Integration with product lifecycle and change control, which is where most of the value sits and most of the political work too. Electronic signature and validation scope, if the system holds controlled records. And translation and local language handling for correspondence, which is easy to leave out of a specification and hard to add later.

What separates a regulatory information build that works from one that fails?

The identity model settled before any screens are designed. Everything else in this system is a query over that model, so a week spent whiteboarding kits, accessories, private label variants and market specific classifications with your regulatory team pays for itself many times over. Teams that start with the user interface end up bending the model to fit screens, and the model is the product.

Assessment rules held as configuration your regulatory team maintains, indexed by change type and market. If a rule change requires a developer, the system will be out of date within a year, and your team will keep the real answers in a personal file again.

Output framed as a work list rather than a determination. The system produces the complete, correct list of affected registrations with holders, renewal dates and the applicable rule. A qualified person still makes the call, and the value is that judgement happens on day one instead of day five. Every assessment retained with its rationale and its author is what lets you answer the same question consistently when it recurs in two years with different people in the room.

Reuse tracking for dossier content, with realistic expectations. Managing evidence as versioned components with a record of every dossier and market referencing them turns supersession into a work list. Full automated assembly is oversold, and a developer who promises it has not done this.

And ownership settled before kickoff: the repository, the infrastructure accounts and the unrestricted right to hire anyone else. Your registration history is the record of your right to sell in every market you operate in, and it must never sit behind a vendor relationship you cannot exit.