Medical Device Regulatory Information Management: Which Markets Does This Engineering Change Actually Break?

Why a registration spreadsheet fails at roughly two hundred registrations

A regulatory affairs manager gets an email from engineering on a Tuesday. A supplier is discontinuing a connector on a catheter set, and the replacement is dimensionally identical from a different manufacturer. Engineering wants to know whether they can proceed. The real question is which of the 340 registrations across 41 countries covering this product family are affected, which of those require notification, which require prior approval, which are held in a distributor's name and therefore need the distributor's cooperation, and which have a renewal inside the next six months that would be better used to carry the change.

The answer lives in a workbook with a tab per region, maintained by two people, colour coded by a convention that is not documented, and last fully reconciled during a restructuring. Getting to an answer takes the manager most of a week, and the answer she gives will be qualified because she knows the workbook is not perfectly current.

The products in this space are genuinely useful. Rimsys is built specifically for medical device regulatory information and understands device product hierarchies in a way pharma oriented systems do not. Veeva Vault RIM is a serious platform whose model reflects its pharmaceutical origins, which suits some device companies and fights others. Ennov is a credible alternative. Across regulatory operations projects we have delivered, the recurring pattern is that companies do not build because these products are bad, they build because their product hierarchy, their distributor relationships, and their link into engineering change control are specific enough that configuring a product means describing their business in someone else's vocabulary. The measurable cost today is one to two days per significant change question, and a slower answer than the commercial team needs, on a question that is asked constantly.

Problem 1: a device portfolio is not a product list

Pharmaceutical regulatory systems model a product with strengths and presentations, and that model works for them. A device portfolio does not fit it. You have a device family, models within it, configurations, accessories that are separately registered in some markets and not others, kits that combine items registered individually elsewhere, software versions that are themselves regulated, private label variants sold under a partner's name, and the same physical item classified differently by different authorities.

A registration attaches to some combination of these, and the combination differs per market. That is why the spreadsheet has a tab per region: because there is no single hierarchy that describes all of it, so people stopped trying and made regional lists instead. The consequence is that the same physical product exists many times with no link between the copies, and any question crossing regions requires human interpretation.

What a custom build does: separate the technical identity of a thing from the commercial and regulatory identities it takes in each market. One physical item has one identity, with market specific classifications, names, and identifiers attached to it, including unique device identifiers and their database records. A registration then references items rather than duplicating them. Once that model is right, the questions that used to take a week become queries. Getting it wrong is the most common reason these projects disappoint, and it is a modelling problem rather than a technology problem.

Problem 2: change impact is the question the business actually asks

Regulatory affairs is asked one question far more often than any other: if we do this, what breaks. A supplier change, a design change, a manufacturing site addition, a label update, a software release, a change of sterilisation provider. Each has a different impact profile per market, and the rules for what constitutes a significant change requiring notification or approval differ by authority.

What a custom build does: hold the assessment rules as configuration your regulatory team maintains, indexed by change type and market, and generate an impact set from the product model. The output is not a determination, because that requires professional judgement and always will. The output is the complete, correct list of affected registrations with their renewal dates, their holders, and the rule that applies, so the professional judgement happens on the first day instead of the fifth. Every assessment is retained with its rationale and its author, which is what lets you answer the same question consistently when it recurs in two years with different people in the room.

Problem 3: renewals and certificates cascade

A registration in one market may depend on a certificate from a notified body, an ISO 13485 certificate, a certificate of free sale from a reference market, an authorised representative agreement, or a licence held by a distributor. When the upstream document expires or changes, everything depending on it is affected, sometimes with long lead times. A notified body certificate transition, a change of authorised representative, or a reference market registration lapsing can each cascade into dozens of markets.

Spreadsheets track renewal dates and cannot express dependency, so the cascade is discovered market by market, usually by the distributor who cannot import.

What a custom build does: model dependency explicitly, so a certificate carries the registrations that rest on it. Lead times are attributes, since a market requiring nine months of processing needs to appear on someone's board a year ahead rather than at ninety days like everything else. Alerts go to a named person with escalation, not to a shared inbox. This is the least glamorous feature in the system and the one that prevents the most expensive single failure in the discipline, which is a product falling out of a market because a document behind it expired quietly.

Problem 4: every dossier wants the same content in a different shape

Technical documentation under the European Medical Device Regulation, a submission to another authority, and a distributor's local filing all draw on the same underlying content: the general safety and performance requirements evidence, risk management file, clinical evaluation, biocompatibility, sterilisation validation, labelling, and the declaration of conformity. Each wants that content in its own structure, its own language, and sometimes its own level of detail. So the same evidence is copied into many documents, and when the underlying evidence is revised, nobody knows reliably which submitted dossiers now contain a superseded version.

What a custom build does: manage content as reusable, versioned components with the dossiers that reference them recorded. When a test report is superseded, the system lists every dossier and every market containing the old version, which turns an unanswerable question into a work list. Assembly of a market dossier becomes a structured export against that market's required structure. Full automation of assembly is not realistic and companies that promise it disappoint, but the reuse tracking alone repays the build.

Problem 5: in many markets, your registration is not yours

In a significant number of countries the licence is held by a local distributor or an in country representative. That has commercial consequences most software ignores entirely. If the relationship ends, the registration may not transfer easily, and your access to that market becomes a negotiation. Correspondence with the authority happens through them, in their language, and lands in an email thread rather than a record.

What a custom build does: hold the holder relationship as data, with the contract, its term, its transfer provisions, and the registrations affected. Correspondence and submission history attach to the registration rather than living in an individual's mailbox, so when a relationship changes, you know precisely what is at stake and what evidence you hold. Regulatory teams tend to raise this problem before the software team has thought of it, which is a reliable indicator that it belongs in the first release rather than a later phase.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the shape for device regulatory information systems. A first release covering the product and identity model, registrations with holders and statuses, certificate and renewal dependency tracking with escalating alerts, and change impact queries runs $60,000 to $130,000 and ships in 10 to 16 weeks. A full platform adding dossier content reuse with supersession tracking, submission and correspondence history, distributor and authorised representative management, unique device identifier data management, and integration with engineering change orders runs $150,000 to $350,000 phased over 6 to 12 months.

• Portfolio complexity, meaning kits, configurations, private label variants, and separately registered accessories, which is the single largest driver.
• Number of markets and how many are distributor held, because the commercial data model doubles when holders are third parties.
• Whether you integrate with product lifecycle management and change control, which is where most of the value sits and where most of the political work sits too.
• Data migration and reconciliation. Loading a spreadsheet is trivial. Establishing which of its rows are true is a real project and should be scoped honestly, usually as several weeks with your regulatory team.
• Whether the system holds controlled records requiring electronic signature, which raises validation scope.

Build versus buy, and when buying is right

Buy if you hold a modest number of registrations across a handful of markets with a stable portfolio. Rimsys understands device hierarchies and will be running long before a build could be, and for many mid sized manufacturers it is the correct answer. Buy Vault RIM if you are already a Vault estate and can accept its model.

Build when two or more of these are true. Your product hierarchy genuinely does not fit a product's model, and configuring one means describing your portfolio in a vocabulary your own team does not use. A large share of your registrations are distributor held and you need contractual and commercial data alongside regulatory data. You need change impact wired directly into engineering change control rather than answered by email. You have several thousand registrations where query performance and bulk operations matter. Or you have already had a market interruption from a lapse that a dependency model would have caught, in which case the business case has already been made for you.

How to choose a developer for regulatory information software

Ask them to model a kit before you sign anything. A device kit containing items that are separately registered in some markets and only as a kit in others is the test that separates people who have done this from people who have not. If they propose a product table with a country column, stop the meeting.

Ask how a certificate expiry propagates. If the answer is a date field and a reminder, they have not understood that the value of the system is the dependency graph rather than the calendar.

Ask what they will do about data quality during migration. A developer who assumes your spreadsheet is correct will deliver a fast system full of wrong answers, which is worse than the spreadsheet because people will trust it.

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 the work. At Digital Heroes the client owns the code from the first commit. 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.