Implant-card platform scope: patient information, delivery and exemptions
MDR Article 18 describes implant-card and patient-information tasks, including information updates, rapid access, understandable language and a stated exemption list. These tasks are different from electronic-instructions-for-use eligibility. Use this page to scope the implant-information workflow; assess eIFU separately against its current specific rules.
Evidence retrieved 2026-10-06. 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
Which implant and exemption facts matter?
Article 18(3) lists exempt implant types and permits amendments to that list. [1]
Compare the actual implant and current exemption list before commissioning an implant-card implementation; an EMDN name is not the determination.
Which device information is on the card?
Article 18(1)(a) lists identifiers, UDI/model and manufacturer information; the article separately requires this information on the delivered implant card. [1]
Map each identifier from controlled device records into card templates and check version/portfolio relationships.
What patient information and updates are delivered?
Article 18(1) describes warnings/interference, expected lifetime/follow-up and safe-use information, rapid access, lay-understandable language and website updates. [1]
Define approved patient content, languages, availability, update ownership and how patients find the current version; the platform cannot create validated lifetime claims from a product name.
How does the institution complete the handoff?
Article 18(2) addresses making information available to implanted patients and a card bearing their identity. [1]
Document institution/patient handoff and privacy controls; assess eIFU eligibility in a separate work package without assuming a shared platform settles it.
Implant status/exemption, approved patient content and Member State language facts remain incomplete. Current eIFU eligibility is outside this implant-card comparison and needs separately acquired, reviewed rules.
A scoped evidence and handoff plan
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.
Which implant and exemption facts matter?
Compare the actual implant and current exemption list before commissioning an implant-card implementation; an EMDN name is not the determination.
Useful evidence: Implant design/type, classification context and dated exemption review.
Which device information is on the card?
Map each identifier from controlled device records into card templates and check version/portfolio relationships.
Useful evidence: Device/lot/serial/UDI/model data and manufacturer-controlled card template.
What patient information and updates are delivered?
Define approved patient content, languages, availability, update ownership and how patients find the current version; the platform cannot create validated lifetime claims from a product name.
Useful evidence: Approved patient information, justified lifetime/follow-up facts, languages and delivery/update plan.
How does the institution complete the handoff?
Document institution/patient handoff and privacy controls; assess eIFU eligibility in a separate work package without assuming a shared platform settles it.
Useful evidence: Institution workflow, patient identity/privacy handling and separate eIFU applicability assessment if proposed.
Work packages and dependencies
Conditional: Implant-card and controlled patient-information workflow — For this work package, agree the supported criteria, evidence access, covered entities/products and unresolved facts in the table above. Additional services require their own justified scope.
Questions for providers
Which exact actor, product or processing facts support the quoted scope, and what is still unresolved?
How will the listed records reach the responsible people, and who owns each change or authority request?
Which tasks and entities are excluded from the agreement, and which additional services need a separate assessment?
Sources and data dates
Read the official document in context. The audit details identify the precise locators and preserved versions used for this page.