eIFU platform selection: user eligibility, paper fallback and version controls
Replacing a paper IFU requires more than a document portal. The acquired 2025 consolidation separates professional-user and foreseeable lay-user facts, a documented risk assessment, paper fulfilment, validated delivery and website controls. Use the demonstration tests below to compare a platform and its operating service. Implant cards are a separate workflow.
Evidence retrieved 2026-10-10. Source versions and topic-specific limits are listed below.
Sourced criteria · EU
What changes the service scope?
Decision or task
What the source describes
What to prepare
Is this replacement or an additional electronic copy?
What the source describesArticle 3 distinguishes the professional-user context, foreseeable lay use requiring paper instructions for lay persons, and instructions provided through MDR software itself. Article 9 separately addresses electronic instructions supplied in addition to complete paper instructions. [1][6]
What to prepareCreate a device/user matrix: intended professional users, reasonably foreseeable lay users, software delivery and whether complete paper instructions remain supplied. Record a reviewed eligibility conclusion for each configuration.
Can users reach the right instructions when access fails?
What the source describesArticle 4 lists user experience, use environment, electronic resources, tampering safeguards, hardware/software failures, emergencies, internet unavailability, compatibility and version management within the documented risk assessment. [2]
What to prepareDemonstrate the intended clinic/device/browser setup, an unavailable website, unavailable internet and an urgent information request. Record the actual fallback and risk rationale for each; these are proposed procurement tests, not statutory test protocols.
Who fulfils a paper request?
What the source describesArticle 5(3) describes paper instructions at no additional user cost within the risk-assessed period, at the latest seven calendar days after a request, or at device delivery when requested at order. [3]
What to prepareTrace an example request from receipt to dispatch/delivery evidence, including an order-time request. Name the fulfilment owner and escalation route; distinguish platform ticketing from the actual paper service.
Does the correct device/version remain identifiable?
What the source describesArticles 5 and 6 cover verification/validation, revisions, safety-related user notification, device identifiers, access instructions and text content. Article 5 distinguishes retention periods and access to issued versions according to the stated device conditions. [3][4]
What to prepareDemonstrate lookup with the actual Basic UDI-DI/UDI-DI and model, publication of a revised approved IFU, a safety-related revision notice and retrieval of an obsolete version. Agree the applicable retention rule after the device facts are reviewed.
Is the website an operated service rather than a file link?
What the source describesArticle 7 addresses readable formats, protection against unauthorised access/tampering, reduced downtime/display errors, GDPR, a stable directly accessible address and a separate UDI-database address handoff condition. [5]
What to prepareDemonstrate stable links, access with freely available viewing software, controlled publishing, downtime handling and data collection. Assign address/registration handoff ownership separately; no current module deadline is inferred here.
This guide uses the acquired English 16 July 2025 consolidation of Regulation 2021/2226, with original and 2025/1234 amending acts retained separately. It does not determine a particular device’s eligibility, validate a platform, settle national language requirements or establish current registration timing. Authentic acts and any later changes govern.
Use this evidence and handoff matrix
Use this checklist to gather your business or product details before speaking with a specialist. The items below explain what to record and suggest useful supporting documents. You can add your own answers in the editable project brief.
Is this replacement or an additional electronic copy?
Create a device/user matrix: intended professional users, reasonably foreseeable lay users, software delivery and whether complete paper instructions remain supplied. Record a reviewed eligibility conclusion for each configuration.
Useful evidence: Device intended-use and user descriptions, configurations, distribution model and an eligibility/replacement decision record.
Can users reach the right instructions when access fails?
Demonstrate the intended clinic/device/browser setup, an unavailable website, unavailable internet and an urgent information request. Record the actual fallback and risk rationale for each; these are proposed procurement tests, not statutory test protocols.
Useful evidence: An access/failure demonstration matrix, documented risk assessment and post-market update owner.
Who fulfils a paper request?
Trace an example request from receipt to dispatch/delivery evidence, including an order-time request. Name the fulfilment owner and escalation route; distinguish platform ticketing from the actual paper service.
Useful evidence: A request/fulfilment log, service agreement, delivery evidence and risk-assessed response period.
Does the correct device/version remain identifiable?
Demonstrate lookup with the actual Basic UDI-DI/UDI-DI and model, publication of a revised approved IFU, a safety-related revision notice and retrieval of an obsolete version. Agree the applicable retention rule after the device facts are reviewed.
Is the website an operated service rather than a file link?
Demonstrate stable links, access with freely available viewing software, controlled publishing, downtime handling and data collection. Assign address/registration handoff ownership separately; no current module deadline is inferred here.
Useful evidence: A platform demonstration record, access/publishing controls, availability procedure, privacy/data map and address-handoff owner.
Work packages and dependencies
Conditional: eIFU platform selection: user eligibility, paper fallback and version controls — Review the stated source/task matrix, actual deciding facts and evidence gaps. Agree the covered entities, products, deliverables, owners and exclusions before engagement.
Questions for providers
Which actual users and delivery configurations support replacement, and which still receive paper instructions?
What evidence supports each fallback, and how will post-market experience change the assessment?
Does your quote include fulfilment or only ticketing, and how is the stated paper-request condition evidenced?
How do you prevent a wrong-model or wrong-version result and prove safety-related revision communications?
Which controls, monitoring, export and exit arrangements are included, and who maintains the stable public address?
Sources and data dates
Read the official document in context. The audit details identify the precise locators and preserved versions used for this page.
