Annex XIV Part B names registries as a valid post-market clinical follow-up method. Two routes lead there: an established national registry, or a sponsor-owned registry built for your device. We scope both against your residual clinical risk, then run the one that answers the question.
The people who build your evidence have sat on the other side of the table.
Dr Mark Da CostaChief Operating Officer and Head of CardiovascularFormer TÜV SÜD Team Leader
Dr Nikhil KhadabadiChief Medical Officer, Orthopedics and SpineFormer TÜV SÜD senior reviewer
Sebastien Meier PiantanidaChief Data OfficerData management and EDC
Annex XIV Part B names registries as a valid post-market clinical follow-up method. Two routes lead there: an established national registry, or a sponsor-owned registry built for your device. We scope both against your residual clinical risk, then run the one that answers the question.
Leading manufacturers rely on Eclevar for registry-based PMCF and real-world evidence. Read all the client success stories.
Most registry deficiencies we see are not data problems. They are scoping problems. The registry was built before anyone wrote down which residual clinical risk it had to close, so the endpoints float, the device cannot be isolated in the dataset, and the PMCF evaluation report has nothing to conclude from.
We start from the clinical evaluation report, name the gap in one sentence, and only then decide whether an existing registry can carry it or whether a sponsor-owned registry is the only honest route. That order is what makes the file defensible when a reviewer opens it.
Under Regulation (EU) 2017/745, manufacturers of higher-risk devices have to gather real-world safety and performance data throughout the post-market phase. Annex XIV Part B explicitly identifies participation in, or creation of, a medical device registry as a valid method for post-market clinical follow-up. That places registry evidence inside the clinical evaluation cycle rather than beside it.
Two pathways satisfy the requirement. A manufacturer can use an established third-party public or national registry, or build a company-sponsored registry architecture. They carry different costs, different levels of control and different audit exposure. This page sets out both, and where each one holds. The wider practice sits on our registry under the EU MDR page.
Established clinical registries carry credible, independent real-world data. In cardiovascular work, SWEDEHEART and its SCAAR sub-registry, and the German Aortic Valve Registry, are widely accepted by notified bodies for long-term safety. SWEDEHEART cross-checks a large majority of its data entry fields against national electronic health records, which is why its data hold up under scrutiny.
Contracting directly with the registry's governing steering committee, for example the Uppsala Clinical Research Center for SWEDEHEART, to run a manufacturer-sponsored, protocol-driven data module that tracks your specific device through nested fields.
Requesting custom, pseudonymized data extracts covering defined patient cohorts, lesion sub-groups or long-term clinical endpoints such as MACE and target lesion revascularization, tied to the target device identifier.
The registry has to capture the exact brand name, model number or Unique Device Identifier. Data aggregated by general device class, for example all drug-eluting stents, is not compliant and will be read as such.
A formal PMCF plan on the MDCG 2020-7 template, authored before data extraction, defining primary endpoints, sample size justification and statistical power. Writing it afterward is visible, and it is the single most common finding.
The indications, patient demographics and deployment techniques tracked in the registry have to align with the device's cleared European instructions for use. A registry that covers a different population answers a different question.
When a device carries unique design elements, or when public registries do not hold the variables your endpoints depend on, a proprietary registry focused on your product family is the right answer. It is also the more demanding one.
An electronic data capture and data management system validated under 21 CFR Part 11 and GDPR. Disease-specific case report forms kept lean, because coordinator fatigue is the quiet cause of missing data in year two.
The database maps catalog numbers, lot and batch records and UDIs, so data can be aggregated across a whole product family or isolated down to a single sizing configuration.
The protocol requires every participating site to register every consecutive eligible patient treated with the device. This is what removes selection bias, and it is what a reviewer will look for first.
Demographics, comorbidities, target anatomy, and immediate procedural success or acute complications.
Post-procedural adverse events and mandatory pharmaceutical regimens, for example dual antiplatelet therapy thresholds.
Site visits or structured telephone interviews at 30 days, one year, three years and five years, tracking survival, late device degradation and major safety endpoints such as target vessel failure or thrombosis.
A registry is not a pre-market trial and should not be monitored like one. Source data verification runs on a pre-determined, randomized subset of records, typically a defined annual percentage, to prove registry data match the hospital chart. Programmatic edit checks catch missing entries, biological impossibilities and scheduling logic errors at the point of entry. How that plan is written and defended is set out in registry data quality and monitoring.
Five dimensions decide this choice in practice. The right answer is the one that matches your residual risk and your evidence question, not the cheaper one.
| Dimension | Sponsor-owned registry | Established national registry |
|---|---|---|
| Data ownership | Full control over raw exports and direct querying. | Restricted to aggregate reports or controlled, blinded datasets. |
| Variable customization | High. Proprietary parameters can be added to match device nuances. | Static. Constrained to the variables the system already collects. |
| Burden on clinical centers | High. Hospital teams need motivation and fees to support a second system. | Minimal. Clinicians enter data as part of standard care. |
| Regulatory acceptance | High, provided consecutive enrollment and auditing are demonstrated. | Very high. Manufacturer selection bias is structurally removed. |
| Investment | Significant up front: validated software, contracts, site fees. | Low infrastructure overhead, limited to access and query fees. |
The two routes are not exclusive. An established registry can supply the population and the benchmark while a defined add-on module carries the variables it does not hold. Watch Article 74 while designing the add-on: the moment the module asks a site to do something that would not have happened in routine care, the project changes regime, timeline and budget. The full cost comparison is on registry cost and timeline.
The order matters more than the content. Every step depends on the one before it, and the deficiencies we are asked to repair almost always come from a step that was skipped or run out of sequence.
Isolate the residual clinical risks inside the clinical evaluation report, focusing on long-term safety endpoints and specific patient sub-groups. This is the sentence everything else is built on.
Cross-reference the required endpoints against the variables an existing registry actually holds, or finalize the custom case report form fields. Method described on registry feasibility and site selection.
A localized informed consent form and submission through the ethics committee or institutional review board route in each target country, so GDPR compliance is established rather than assumed.
The protocol compiled into an MDCG 2020-7 compliant template and submitted to the manufacturer's notified body, before data extraction starts.
After database lock or registry export, the statistical analysis plan is executed and the findings written into a PMCF evaluation report on the MDCG 2020-8 template, which then updates the technical documentation.
One accountable team, in house, across the whole route. Nothing is lost in a handover between the protocol, the sites and the evidence package.
Reading the clinical evaluation report and the risk file, naming the evidence gap, then a costed recommendation on which registry route can close it.
Contracting with registry custodians and scientific committees, including the access request, the publication rules and the data governance conditions attached to each.
Endpoints mapped to the General Safety and Performance Requirements and to device-specific frameworks, with the biostatistics team on the analysis plan from version one.
In-house clinical research associates rather than subcontractors, running initiation, ethics submissions and on-site and remote monitoring to a single standard across countries.
eCRF design, validation and cohort build on our own EDC, built for EU MDR work and compliant with 21 CFR Part 11, ICH-GCP and GDPR.
Statistical analysis, safety signal review and the MDCG 2020-8 report, written to update the technical documentation rather than to sit beside it.
This page covers the PMCF use case for registries. The practice itself is on registry under the EU MDR, the choice between a registry and a study is on registry versus clinical investigation, and the therapeutic application is on cardiovascular PMCF registry studies. All of it sits inside the wider medical device CRO offer.
Whitepapers, client voices and publications produced by our teams and our partners (BSI, TÜV SÜD, RegenLab).
Annex XIV Part B names participation in, or creation of, a device registry as a PMCF method. It is not supporting material. What decides whether it is accepted in your case is not the method but the fit: whether the registry answers the residual clinical risk identified in your clinical evaluation, whether your device is identifiable at patient level, and whether the plan was written before the data were extracted.
Often yes, and it is usually cheaper and better accepted, because manufacturer selection bias is removed structurally. The conditions are strict: the registry has to capture your brand, model or UDI rather than a device class, your endpoints have to already exist in its data dictionary and be defined the way you need them, and the custodian has to grant access on terms you can accept. We test all three before recommending the route.
Aggregation. A registry that reports outcomes by device class rather than by specific device cannot support a device-specific conclusion, and the deficiency is usually raised late, once the data have already been collected. The second most common is a statistical protocol written after the extraction, which is visible in the file and hard to defend.
Far less than a pre-market trial, and it has to be justified rather than assumed. Verification runs on a pre-determined randomized subset of records, with the percentage and the selection method written into the plan in advance. Everything else is carried by edit checks and central review. The reasoning is set out in registry data quality and monitoring.
Yes, and it is the cheapest point at which to intervene. We read the plan against the residual risks in your clinical evaluation report, check that the endpoints are reachable in the data source you intend to use, and flag what a reviewer is likely to question. Send it to our registry team.
Annex XIV Part B names participation in, or creation of, a device registry as a PMCF method. It is not supporting material. What decides whether it is accepted in your case is not the method but the fit: whether the registry answers the residual clinical risk identified in your clinical evaluation, whether your device is identifiable at patient level, and whether the plan was written before the data were extracted.
Often yes, and it is usually cheaper and better accepted, because manufacturer selection bias is removed structurally. The conditions are strict: the registry has to capture your brand, model or UDI rather than a device class, your endpoints have to already exist in its data dictionary and be defined the way you need them, and the custodian has to grant access on terms you can accept. We test all three before recommending the route.
Aggregation. A registry that reports outcomes by device class rather than by specific device cannot support a device-specific conclusion, and the deficiency is usually raised late, once the data have already been collected. The second most common is a statistical protocol written after the extraction, which is visible in the file and hard to defend.
Far less than a pre-market trial, and it has to be justified rather than assumed. Verification runs on a pre-determined randomized subset of records, with the percentage and the selection method written into the plan in advance. Everything else is carried by edit checks and central review. The reasoning is set out in registry data quality and monitoring.
Yes, and it is the cheapest point at which to intervene. We read the plan against the residual risks in your clinical evaluation report, check that the endpoints are reachable in the data source you intend to use, and flag what a reviewer is likely to question. Send it to our registry team.
Whitepapers and publications produced by our teams with our notified body partners.
Written with Notified Body BSI: a practical reading of the clinical evidence expectations under EU MDR 2017/745, the same evidence your file has to support.
The services and topics connected to this page.
Send us the device, the claim and the deadline. You get a written answer within 24 hours.
Your documents are reviewed confidentially. An NDA can be signed before we receive any technical or clinical information.
