Medical device consulting services, what companies should look for in a regulatory partner
What should a company actually expect from medical device consulting services before signing a contract? A regulatory partner should function like a qualified supplier, not a report vendor: clear deliverables, traceable evidence, a documented approach to post-market changes, and work that fits inside the manufacturer’s own quality system — not just templates and general MDR/IVDR advice.
That expectation only becomes useful once it is broken into criteria you can actually test before signing anything. This piece works through four capability checks — evidence architecture, Notified Body readiness, QMS integration, and post-market governance — and ties each one to a specific, contractable deliverable, so the evaluation produces something you can put in a scope of work rather than a general impression of competence.
What medical device consulting services should mean in 2026 (and what they should not)
In many cases, gaps surface not because nobody read the Regulation, but because the technical file cannot answer a simple question: where does this claim come from, and who approved it. That gap often traces back to an engagement that treated regulatory consulting as advisory-only — a set of recommendations handed over, with no accountability for how they were implemented inside the manufacturer’s own quality system.
Manufacturers get burned in three recurring ways: template-driven outputs that look complete but do not match the device’s actual design history, unclear ownership of who signs off on technical content, and evidence that cannot be traced back to its source once a reviewer asks a follow-up question. None of these are regulatory failures in the strict sense. They tend to be governance failures dressed up as compliance gaps.
A useful baseline for a regulatory partner working under EU MDR or IVDR is narrower and more concrete than compliance support in general terms. It means the ability to translate a legal requirement into a controlled deliverable — a document with an owner, a version history, an approval record, and a defined place inside the manufacturer’s document control system. Anything short of that is advice, not partnership.
Start with your intended use and market pathway: the partner must fit the route, not the other way around
Regulation (EU) 2017/745 on medical devices and Regulation (EU) 2017/746 on in vitro diagnostic medical devices were both adopted on 5 April 2017, but they impose different evidentiary burdens. The European Commission has confirmed that the MDR has applied since 26 May 2021 and the IVDR since 26 May 2022, with transitional arrangements that vary by risk class — MDR devices under Article 120 running through 31 December 2027 or 2028 depending on classification, and a staggered IVDR transition ranging from 26 May 2025 for high-risk IVDs to 26 May 2027 for lower-risk IVDs, with certain health-institution provisions extending to 26 May 2028. A partner who does not ask early which transitional bucket your device falls into is likely not yet in a position to scope the work properly.
Classification, intended use, clinical or performance claims, and QMS maturity are the actual inputs that determine how much consulting effort a file needs — not the manufacturer’s revenue or headcount. A Class IIa implant with a well-documented predicate history needs a different kind of support than a novel IVD assay. In practice, most IVD manufacturers should expect their technical documentation to be assessed by a notified body before EU market placement, which changes both the timeline and the depth of evidence a consulting engagement needs to produce.
One practical red flag is worth naming directly: a consultant who proposes a fixed timeline and price before reviewing your classification rationale and existing evidence base is guessing. Scope should follow a gap assessment, not precede it.
Supplier-qualification mindset: evaluate a regulatory partner like a critical supplier
Most quality management systems already contain a framework for this. Suppliers who influence product conformity get qualified, monitored, and re-evaluated — not hired on trust. A regulatory consultant touching your technical documentation, clinical evaluation, or PMS system fits that same category, and can reasonably go through comparable due diligence.
A reasonable minimum due-diligence package includes CVs and defined roles for the people who will actually do the work — not just the ones who sell it — redacted sample deliverables, a description of their internal review process, and evidence of quality controls on their own output: version control, peer review, sign-off records. Ask whether a partner can cover EU, Swiss, and UK representation roles alongside U.S. Agent coordination under one governance model, without splitting your file across disconnected contracts. Firms offering medical device consulting across several jurisdictions should be able to show how that coordination actually works in practice — ALTRION states it provides EU Authorized Representative, Swiss Authorized Representative, UK Responsible Person and U.S. Agent services alongside MDR/IVDR consulting, drawing on more than 15 years in the medical device industry. If a partner cannot show how its own deliverables are controlled, it is fair to question how well it will control yours.
Acceptance criteria matter as much as the package itself. Define in advance what a good outcome looks like for a clinical evaluation report, a PMS plan, or a risk management file: does it reference source data, does it use consistent terminology across sections, does it include a rationale for judgment calls rather than a bare conclusion. Vague acceptance criteria tend to produce vague deliverables.
Capability check #1 — Evidence architecture: can they build a traceable story across the whole file?
MDR Annex II requires technical documentation to be presented in a clear, organised, readily searchable and unambiguous manner, covering elements including the device description and intended purpose, the risk class and its classification justification under Annex VIII, and — once identification is based on a UDI system — the Basic UDI-DI referred to in Part C of Annex VI, or otherwise a clear identification allowing traceability. It also requires documentation of the intended patient population and medical conditions to be diagnosed, treated or monitored, and a complete set of labels and instructions for use in the languages accepted in the relevant Member States.
None of these elements sit in isolation. A classification justification should be consistent with the intended purpose statement; the risk file should reference the same clinical claims as the labeling; the PMS plan should monitor the same risks identified in the risk management file. Consider a common scenario: a labeling claim promises a shorter procedure time, but the clinical evaluation report never quantifies it and the risk file has no corresponding entry for the hazard that would follow if the device underperformed. A capable partner would flag this as a traceability gap, open a change control record that either ties the claim to a specific evidence source or removes it, and document the rationale for whichever fix is chosen — rather than letting the inconsistency sit until someone else finds it.
A practical way to test competence here is to ask how a candidate partner approaches traceability across GSPRs, risk management, clinical evidence, and labeling, and how they manage change impact when one document changes. A recurring failure mode worth probing for is disconnected documents — a clinical evaluation report that uses different terminology than the risk file, or a labeling claim with no supporting rationale anywhere else in the technical documentation.
Capability check #2 — Notified Body readiness: understanding IVDR scope and additional annexes
For IVDs, most manufacturers should expect their technical documentation to be assessed by a notified body before placing devices on the EU market. Annexes II and III of the IVDR set the general technical documentation requirements, but additional annexes often need to be referenced depending on the device: Annex I for general safety and performance requirements, Annex VI for UDI-related documentation, and Annex XIII for performance evaluation. A partner with genuine notified body experience should be able to identify, early on, which of these additional annexes apply to your specific device and why — rather than treating Annex II and III as the whole picture.
It can be useful to ask a candidate partner to walk through how they structure a pre-submission review, and how their clinical or performance evidence rationale connects each claim on file back to a specific data source rather than a general statement of confidence. It is also reasonable to ask, as an operational matter, who within the firm would actually draft responses to notified body questions and what turnaround manufacturers can realistically expect — the specifics of that answer tend to say more about day-to-day capability than a general list of credentials.
Capability check #3 — QMS integration: can they work inside your processes without breaking them?
Regulatory deliverables do not exist independently of the manufacturer’s quality management system. A clinical evaluation report has to live inside document control, referenced from the design history file, tied to the same design controls that produced the device requirements it evaluates. Consulting output that arrives outside your controlled templates, without a document history or approval trail, creates a parallel and ungoverned version of your technical file — a mismatch that is likely to surface during an internal audit if not sooner.
The practical interface points are design inputs and outputs, verification and validation records, supplier controls, and CAPA. A partner who understands this will ask how your document control system works before drafting anything, and will aim to produce content that fits your numbering, your approval workflow, and your change control process rather than a parallel structure that someone internally has to reconcile later.
Capability check #4 — Post-market reality: PMS, PMCF and vigilance are where partnerships prove their value
Pre-market documentation gets most of the attention during a selection process, but post-market performance is often where a regulatory relationship is genuinely tested. A post-market-capable partner should be able to describe a repeatable method for PMS reporting and trend analysis, a defined process for handling vigilance reports, and a way to keep PMS documentation current as new field data comes in.
A useful diagnostic question concerns change management: does the partner apply a repeatable, documented method to assess whether a design or process change affects classification, clinical claims, or existing conformity evidence — or does each change get an informal opinion with no record of the reasoning behind it. A one-off judgment call is not a process, and it is unlikely to hold up well if an auditor later asks to see how a similar change was assessed some months earlier.
Engagement model and governance: define roles before work starts
Some responsibilities cannot be delegated regardless of how capable the consulting partner is. The legal manufacturer retains ultimate responsibility for conformity, for the technical documentation’s accuracy, and for decisions on market placement. What can typically be delegated is the execution work: drafting, gap analysis, evidence compilation, notified body liaison support, and PMS operations. Writing this division down as a RACI before the engagement starts helps avoid the ambiguity that can surface later, when it matters who actually approved a given document.
Governance around in-country representation deserves the same rigor. In the UK, the MHRA is responsible for regulating the medical devices market and requires all medical devices, including IVDs, to be registered before they are placed on the Great Britain market; a manufacturer based outside the UK must appoint a single UK Responsible Person to carry out tasks such as that registration. Where a manufacturer needs Authorized Representative or Responsible Person coverage across several markets at once — the EU, Switzerland, the UK, and the US, each with its own registration and appointment logic — that representation function should sit inside the same governance structure as the technical documentation work, not as a separate, disconnected contract with its own reporting line.
A regular meeting cadence, a documented issue log, and written records of key decisions can support audit readiness by preserving a traceable history of how choices were made during the engagement. It is also worth asking how a partner avoids a single-expert bottleneck: what happens if the one person who understands your file is unavailable during a critical review window. Team depth and a defined handover protocol are reasonable continuity questions to raise before signing, not just proposal-stage detail.
Contractable deliverables: specify outcomes so they are measurable
Supporting MDR compliance is not a deliverable; it is a mission statement. A contractable deliverable specifies its purpose, its acceptance criteria, and who owns the source file once the engagement ends. For a gap analysis against MDR Annex II or IVDR Annex II/III, that means defining which annex-level requirements are in scope, what output format is expected, and what counts as complete versus preliminary.
Versioning and review cycles should be explicit — how many review rounds are included, what the response time commitment is for urgent notified body questions, and who retains editable ownership of the source documents after the contract ends. Confidentiality and data protection terms for technical documentation and any clinical data need the same specificity as the technical scope itself.
Commercial structure should follow the nature of the work rather than habit. Fixed-scope pricing tends to fit a defined gap analysis or a one-time technical file review; a retainer fits ongoing PMS and vigilance support where volume is unpredictable; milestone-based structures fit conformity assessment preparation, where payment tied to submission readiness helps keep incentives aligned between manufacturer and consultant.
Questions to ask in the first call
Scoping questions should surface quickly whether the consultant understands your actual situation: your device’s classification rationale, the strength of your existing clinical or performance evidence, target markets, and the internal resources you can commit to the project. Method questions test process maturity — how they structure a gap analysis, how they build traceability across a technical file, how they manage a notified body question-and-answer cycle, and how they document a change-impact assessment. Proof questions close the loop: anonymized examples relevant to your device type, and a plain description of how they measure whether an engagement succeeded, beyond noting that a file was submitted.
A partner unwilling to answer any of these three categories concretely is not yet ready to be evaluated as a supplier, regardless of how confident the initial pitch sounds.
Choosing the right partner: a decision framework by company stage
A startup with a working prototype typically needs pathway strategy and design control foundations first — classification confirmation, an early clinical or performance evaluation strategy, and a quality management system built to support the file rather than retrofitted around it later. A scale-up approaching conformity assessment needs a different emphasis: notified body readiness and evidence integration across a file that likely already exists but has not been stress-tested against reviewer scrutiny.
An established manufacturer managing a portfolio of devices has a different problem entirely — not building a file, but scaling change control and PMS systemization across multiple products without losing traceability between them. This is also where workload scalability becomes a real selection criterion: can the partner handle simultaneous submissions or post-market cycles across several devices without the single-expert bottleneck described earlier.
Across all three stages, manufacturers who treat consulting selection as a structured qualification process — checking evidence architecture, notified body method, QMS fit, and post-market capability before signing anything — tend to be better positioned when scrutiny actually arrives. That difference rarely shows up in a sales conversation. It shows up in the first notified body deficiency letter, or the first post-market signal that needs a properly documented decision, which is exactly when the due diligence described above earns its cost.
FAQ
What must be included in MDR Annex II technical documentation for a medical device?MDR Annex II requires the documentation to be clear, organised, readily searchable and unambiguous, and to include the device description and intended purpose, the risk class with its classification justification under Annex VIII, the Basic UDI-DI or equivalent traceable identification, the intended patient population and medical conditions addressed, and a complete set of labels and instructions for use in the languages accepted in the target Member States. Testing whether a candidate partner can trace these elements against each other, rather than list them separately, is the core of capability check #1 above.
What must be included in IVDR technical documentation and how should it be structured?IVDR technical documentation follows general requirements set out in Annexes II and III, with additional annexes often needed depending on the device — Annex I for general safety and performance requirements, Annex VI for UDI documentation, and Annex XIII for performance evaluation. Annex II can function as a practical table of contents for structuring the file across the device lifecycle.
Do I need a notified body to assess IVDR technical documentation before placing an IVD on the EU market?In practice, most IVD manufacturers should expect their technical documentation to be assessed by a notified body before placing devices on the EU market, though the specific route depends on the device’s risk classification.
What is the Basic UDI-DI and where is it referenced in MDR technical documentation requirements?The Basic UDI-DI is the primary identifier for a device model, referred to in Part C of Annex VI of the MDR. MDR Annex II requires it to be included in the technical documentation once device identification is based on the UDI system; otherwise a clear traceable identification must be provided instead.
How do I justify device classification and risk class in the technical file?MDR Annex II requires the documentation to state the risk class and the justification for the classification rule or rules applied under Annex VIII, meaning the rationale should reference the specific rule, the device’s intended purpose, and the characteristics that trigger that classification outcome — not just the resulting class.
What labeling and IFU language requirements apply for EU market placement?As part of the technical documentation, MDR Annex II requires a complete set of labels for the device and its packaging, together with instructions for use, provided in the languages accepted in each Member State where the device will be made available.
How do I run a gap analysis against Annex II/Annex I requirements for IVDR compliance?A gap analysis typically uses Annex II as a structural checklist to identify which technical documentation elements exist, which are missing, and which need updates, cross-referencing Annex I’s general safety and performance requirements to confirm supporting evidence is actually present and traceable, not just implied. This is the same traceability standard a partner should apply under capability check #1.
Which additional IVDR annexes should I reference beyond Annex II/III?Depending on the device, manufacturers commonly need to reference Annex I for general safety and performance requirements, Annex VI for UDI system documentation, and Annex XIII for performance evaluation, since Annexes II and III alone set only the general framework for the technical file.