Regulatory data and reporting systems for MedTech, built so a submission is generated from governed data rather than assembled by hand and then forgotten.
Ask a regulatory affairs team to reproduce a submission filed eighteen months ago, exactly as filed, from the systems rather than from the archive copy, and the answer is almost always that it cannot be done. The figures came from four systems. Some were transcribed. Several were reconciled by somebody applying judgement to a discrepancy. A few were corrected after review. What was filed existed in a template and nowhere else, and the moment it was sent, the only record of what the organization told a regulator became a document rather than data.
Almost nothing a regulator receives originates in a regulatory system. Device identifiers and specifications come from PLM. Catalogue descriptions, packaging configurations and distribution records come from ERP. Complaints and field actions come from the service or quality system. Clinical evidence sits with clinical. Labelling content sits with a labelling tool or, frequently, with a person. Regulatory affairs owns the submission and owns almost none of the data inside it.
The consequence is a quiet and specific failure mode. An engineer updates a field in PLM for a perfectly good engineering reason. A product manager rationalises a catalogue description in ERP. Neither of them is doing anything wrong, neither has any way of knowing that the field they changed appears in a published registration in three markets, and nothing in either system tells them. The published data is now inconsistent with the source and nobody will discover it until a notified body, an auditor or a customer notices first. The data did not degrade through carelessness. It degraded because the systems that hold it were never told what it was for.
Submissions are assembled, not generated
So what was filed exists only as a document and cannot be reproduced from the systems that fed it.
Upstream changes propagate silently
A field edited in PLM or ERP can invalidate a published registration without any signal reaching regulatory.
The same product is a different product in each market
Different identifiers, classifications and data requirements, reconciled by people who remember the mapping.
Reporting is a deadline business with no slack
Unlike most data work, late is a consequence rather than an inconvenience, so teams build buffers out of overtime.
Data integrity is asserted, not demonstrated
Everyone believes the figures are right and nobody can show the path from source to submitted value.
Registration data became a feed and the operating model did not change
Obligations that were once a filing are now maintained records, still resourced as projects with end dates.
Pick one submitted figure and trace it backwards. Choose a single number from a recent submission or published registration and establish, without asking the person who prepared it, which system it came from, what it was called there, what transformation produced the submitted value, who approved it, and whether that source value has changed since. Most organizations cannot complete this exercise for most figures, and the exercise is useful precisely because it is so specific. It converts data integrity from a principle everyone agrees with into a concrete, measurable property of one number, and the result tends to settle internal debate about whether this work is necessary.
The objective throughout is that a submission, a registration update or a periodic report becomes something the system produces from data under governance, with the lineage retained, rather than something a team builds from exports. Everything below serves that one shift, and the order is not negotiable: automating report generation on top of inconsistent identifiers and unclear ownership does not fix anything, it produces incorrect reports faster and with more confidence than the manual process it replaced.
Step 1
Inventory what is actually reported and to whom
Step 2
Trace each element back to a source system
Step 3
Find the elements with no system of origin
Step 4
Establish the product identity spine
Step 5
Agree definitions with regulatory, not around them
Step 6
Build the regulatory data layer
Step 7
Instrument change detection upstream
Step 8
Generate reports and submission datasets from that layer
Step 9
Preserve the submitted state
Step 10
Monitor, reconcile and govern continuously
The reportability decision is the regulated act. The report is paperwork. Whether an event is reportable, in which markets, within what timeframe, is a determination made by qualified people against criteria and precedent, and it is the part a regulator will actually examine. Everything downstream of that decision, which is assembly, formatting, validation, submission and acknowledgement tracking, is clerical work that automates cleanly and is where the hours currently go. Separating the two sharply has a useful secondary effect: it makes the decision visible as a decision, with its reasoning recorded, rather than something implicit in the fact that a report was eventually filed.
We are not a regulatory consultancy and this page does not pretend otherwise. We do not make determinations, write submission strategy or advise on classification. We build the data systems that make those activities cheaper, faster and demonstrably correct, working to the definitions your regulatory function sets.
Regulatory data management
Regulatory data inventory and source mapping, element by element, including the elements with no system of origin
A product identity spine, so one product means one thing internally regardless of how many market identities it carries
Market registration data held as structured attributes rather than as documents and institutional memory
UDI and device identification data management, with the relationship to source records maintained rather than copied
Data definitions, derivation rules and change criteria, documented and owned by your regulatory function
Master data governance across the systems the regulatory data actually originates in
Integration and automation
Integration with eQMS, PLM, ERP, MES, clinical, labelling and service systems
Change detection upstream, so an edit to a reported element raises a signal rather than a later discovery
Automated generation of periodic reports, registration updates and submission datasets from governed data
Validation applied before output, against both format requirements and your own consistency rules
Exception routing, so missing or ambiguous values are surfaced and assigned rather than silently defaulted
Submission and acknowledgement tracking, including what was sent, when, and what came back
Preservation of submitted state as queryable data, so any filing can be reproduced and compared
Reporting, analytics and evidence
Regulatory reporting and dashboards covering obligations, status, exceptions and upcoming commitments
Lineage from source value to submitted figure, retained and inspectable
Reconciliation between what the source systems say today and what was most recently published
Data quality monitoring against the elements that are actually reported, rather than against the database generally
Implementation on your platform, including Microsoft Fabric and Power BI where that is the environment
Validation of what we build, scoped with your quality function and delivered alongside the engineering
The obligations differ by product and market, and so does the place the work becomes unmanageable. The third column is where the manual effort concentrates, which is the sensible place to start.
| Organization type | Reporting character | Where the effort concentrates |
|---|---|---|
| Multi-market device manufacturer | Many products, many registrations, many formats | Keeping published records current as products and specifications change |
| SaMD company | Frequent product change against change-notification expectations | Deciding which software changes are reportable, repeatedly and quickly |
| Digital health platform | Scope boundaries that moved as the product grew | Establishing which parts of the product are in scope and from when |
| Connected device manufacturer | Field data available continuously, reporting episodic | Separating a signal worth reporting from ordinary fleet noise |
| Contract manufacturer or supplier | Supplying data into other organizations’ submissions | Producing the same evidence repeatedly in each customer’s format |
The architecture is not complicated and it is frequently absent. Source systems hold the data. A governed regulatory data layer assembles, reconciles, validates and preserves it. Outputs are generated from that layer rather than from the sources directly. The value is entirely in the middle, because that is where lineage, definition and the submitted state live.
| Source | What it contributes | Why it resists |
|---|---|---|
| PLM | Device identity, specifications, configurations, design records | Engineering revisions do not map cleanly to regulatory versions |
| ERP | Catalogue, packaging, distribution, markets served | Commercial data model, changed by people with no regulatory context |
| eQMS | Complaints, CAPA, field actions, change control | Free text where structure is needed, and classifications that vary by site |
| Clinical and evidence | Study data, literature, evaluation records | Often outside any system, held as documents by individuals |
| Labelling | Content, translations, symbols, market variants | Frequently a document process, with the content not held as data at all |
| Device cloud | Field behaviour, versions, usage, errors | Volume, and no established route into the regulatory function |
The reconciliation should run continuously, not before an audit. The single most useful thing this architecture produces is a standing comparison between what the source systems say today and what was most recently published or filed. Differences are either expected, because a change is in progress, or they are findings, and the organization should know which within days rather than discovering it when somebody external notices. This requires no new data and no new process, only the layer and the retained submitted state, and it converts regulatory data integrity from something asserted in a procedure into a number somebody looks at on a Monday morning.
This boundary matters more on this page than on any other we publish. We do not determine classification, scope, reportability, submission strategy, equivalence or which obligations apply in which market. Those are regulatory determinations belonging to your designated regulatory, clinical and legal functions, and an engineering supplier offering them is selling you exposure. What we do is build systems that make the data behind those determinations accurate, traceable and reproducible, and generate the outputs your determinations require.
Frameworks the controls may need to support
- FDA requirements applicable to the device and its reporting obligations, as your regulatory function determines them
- EU MDR obligations, including the data elements and maintenance expectations that follow from them where applicable
- EUDAMED and UDI data, treated as maintained published records rather than as completed submissions
- ISO 13485 and 21 CFR Part 11 where the records and signatures fall within scope
Data integrity
- Attributable, legible, contemporaneous, original and accurate applied to the whole path, from source field to submitted value
- Lineage retained through every transformation, so the origin of any figure is inspectable rather than remembered
- Controlled correction, where changing a value after filing creates a record of what changed and why
- Reconciliation between source and published state, run on a schedule rather than before an event
Audit trails and records
- Audit trails covering the data, the transformations and the generation of outputs, not only user sessions
- Upstream change control, since an audit trail in the reporting system does not compensate for uncontrolled edits in the source
- Preserved submitted state, queryable, so what was filed can be reproduced exactly
- Approval and release records for generated outputs, with the approver and the basis recorded
- Retention and retrieval that remain workable across a platform migration
Validation and ownership
- Computer system validation of the reporting path, scoped with your quality function and proportionate to risk
- Validation of the rules themselves, since an incorrect derivation rule produces confidently wrong submissions
- Documented ownership of every data element, in the source system and in the regulatory layer
- Supplier assessment of hosted platform components under your existing process
A missed deadline is visible immediately and recoverable. An inaccuracy filed on time is invisible, propagates into every subsequent submission that references it, and is usually discovered by somebody outside the organization. The monitoring work exists for the second category, and the failure modes below are the ones that recur.
| Failure | How it presents |
|---|---|
| An upstream field changes after filing | The published record silently stops matching the source, with no signal anywhere |
| A derivation rule encodes a misunderstanding | Every output is consistently wrong, which is harder to spot than intermittent error |
| Markets drift apart | The same product is described differently in two registrations and nobody compares them |
| A feed stops and nobody notices | Missing records look like an absence of events, so the report is complete and wrong |
| A pipeline completes but omits records | The job reports success and the dataset is short, which no status page will show |
| A report uses the wrong effective date | Information from two product versions is combined into one figure that describes neither |
| A migration reattaches records to the wrong product | Counts reconcile and the relationships underneath are wrong |
| An extracted value is accepted without checking | A figure lifted from a document by a tool enters the workflow unverified |
| A reporting rule changes without assessment | Previously correct outputs quietly start producing different results |
| An element has no owner | A spreadsheet-maintained value goes stale when one person changes role |
| A correction is applied to the source only | The filed record is never updated, and the two versions diverge permanently |
| Reference data changes beneath you | A code list, classification or vocabulary is revised externally and mappings silently expire |
| Submitted state exists only as a document | Any comparison with what was filed requires a person to read it |
Regulatory data programmes get reported as integrations built and reports automated. The outcomes that matter are whether the organization knows the state of its regulatory data without going to look, and whether it can reproduce and defend anything it has filed.
| Category | What we measure | Why it matters |
|---|---|---|
| Source to published divergence | Reported elements where the source no longer matches what was filed | The closest thing to a single number for regulatory data health |
| Elements without an owner or origin | Reported values maintained in a spreadsheet or a person | Where the next inaccuracy is forming, and the fastest thing to fix |
| Time to reproduce a past filing | Hours to regenerate a submission as filed, from systems rather than archive | Tests the whole chain: lineage, preserved state and governance together |
| Cross-market consistency | Products whose registrations disagree on an attribute that should match | Usually unmeasured, and the discrepancies are usually real |
| Submission preparation effort | Hours spent establishing the data versus assembling and reviewing it | Separates the discovery work that should disappear from the work that remains |
| Change signal lead time | Interval between an upstream edit and the regulatory function knowing | The measure of whether silent propagation has actually been closed |
We will inventory what you report and trace each element to its source, find the ones with no system of origin, model the product identity spine with your regulatory function, build the governed layer that generates outputs and preserves what was filed, and run the reconciliation that tells you when any of it stops being true.
CaliberFocus is a MedTech engineering partner delivering regulatory data and reporting systems that generate submissions from governed data rather than reconstructing them by hand. From element-by-element source mapping and a product identity spine across markets, to upstream change detection, automated report generation, preserved submitted state and continuous reconciliation, we build the data systems while every regulatory determination stays with your teams.
- Submissions generated from governed data, not assembled from exports
- Lineage retained from every source field to the submitted value
- Upstream changes detected before published records drift
- Any past filing reproducible from systems rather than the archive
Security & Compliance
