MDR Article 18: chain of custody for medical device loaners

22 May 2026 · 9 min read

If you run a loaner pool for medical devices in the EU, you've probably heard "MDR Article 18" thrown around in audit conversations. This post is what your regulatory team wishes you knew about it — without the legal jargon — and a practical checklist for making your loaner ops audit-ready.

Disclaimer: This is operational guidance, not legal advice. Always verify with your Notified Body and Person Responsible for Regulatory Compliance (PRRC).

What Article 18 actually says

Regulation (EU) 2017/745 (MDR) Article 18 is titled "Implant card and information to be supplied to the patient with an implanted device." Strictly speaking it applies to implantable devices. But the principles — full traceability of each device unit through its lifecycle — apply by extension and by Notified Body practice to most loaner workflows.

The relevant traceability principle (cross-referenced from Articles 25, 27 — UDI) requires that, for each medical device placed on the market or put into service, the manufacturer (and by delegation, the distributor/dealer):

Maintains identification of each unit (UDI-DI, lot/serial)
Records every transfer of custody (who had it, when, where)
Can reconstruct the device's history on request from the authority
Maintains this record for the lifetime of the device + 10 years

For loaner pools specifically, this means: every time a loaner moves between your depot, the courier, the clinic, the cleaning area, and back, you need a record.

What "chain of custody" means in practice

Chain of custody is a documentation pattern borrowed from forensics and pharmaceuticals. It answers four questions for any unit at any time:

Who has this unit? When did they receive it? What state was it in? Where is it physically located?

For a loaner deployment, that translates to recording:

Out of depot — timestamp, who shipped it, condition (photo), transport box ID, courier reference
Received at customer — timestamp, who received, condition (photo if possible)
Picked up from customer — timestamp, who collected, condition (photo)
Arrived back at depot — timestamp, who received, condition (photo)
Cleaning / sterilization — timestamp, who performed, log of the process used
Back in pool — timestamp, marked ready for next deployment

Each entry must be: tamper-evident, timestamped, attributed (to a specific person or system actor), and retrievable on demand within a reasonable time (often interpreted as 24-48 hours for routine audits, shorter for incident investigations).

Why Excel doesn't cut it

The honest reason most loaner operations rely on Excel: it's good enough for daily use. The Excel breaks down at exactly the moment you need it — during an audit, a recall, or an incident.

Concrete failure modes of Excel-based custody tracking:

No tamper-evidence. Excel files are edited freely. An auditor cannot tell if you backdated an entry.
No actor attribution. "Anna" might be the receptionist who wrote it down or the service tech who actually received it.
No timestamp at the cell level. Only the file's modified date.
Difficult to reconstruct history. Unit was moved 5 times across 3 customers? Good luck filtering.
Hard to retain for 10 years. File corruption, lost shares, "we changed our system."

None of this is hypothetical. I've seen each one happen during MDR audits at distributors I've worked with.

What a compliant loaner system actually does

You don't need an enterprise quality management system (QMS) to be MDR-compliant on loaner traceability. You need:

1. Append-only log

Every state change writes a new row. Nobody can delete or modify past entries. (Loaners.app uses Postgres with row-level security + an append-only audit_log table.)

2. Authenticated actor on every entry

The system knows which user performed the action. Not "the receptionist" — a specific authenticated identity. (Loaners.app ties every state change to a profiles.id, traceable to a real person via email.)

3. Structured state machine

Define the legal transitions: "you cannot mark a loaner returned without first marking it picked up." This prevents accidental skipping of mandatory states. (Loaners.app enforces the 5-stage lifecycle with explicit transitions: in_transit_out → at_customer → in_transit_back → cleaning → closed.)

4. Photo evidence (optional but recommended)

Photos at check-out and return aren't strictly required by MDR but resolve 90% of "it arrived broken" disputes. They become part of the chain of custody record.

5. Reliable export

On request, you must produce a complete history for a specific unit. (Loaners.app supports CSV/JSON export filtered by equipment ID — give it to the auditor.)

6. Backup + retention

10-year retention is the MDR baseline. Your database backups + 1 redundant copy in another region. (Supabase Pro plan provides daily backups + point-in-time recovery; we hold a separate exported snapshot monthly.)

Implementation checklist

Pin this above your service manager's desk:

□ Every loaner unit has a unique identifier (serial number, UDI-DI if applicable)
□ Every state transition logs: timestamp, actor (authenticated), before/after state, optional photo
□ The log is append-only (cannot edit past entries)
□ Photos are stored in EU-hosted storage with access controls
□ Mandatory state transitions are enforced (cannot skip stages)
□ "Needs service" flag prevents re-deployment of damaged units
□ Export by unit / by customer / by date range is one click away
□ 10-year retention policy documented and backup tested annually
□ Authority access procedure documented (who provides the data, in what format)

How Loaners.app implements this

Short version: all of the above, by default. You don't configure it; it's the architecture.

Every loaner_assignment row + every state change writes to audit_log
RLS (row-level security) policies enforce that only your org sees your data
The stage field has a CHECK constraint enforcing the 5 legal values
Photo uploads are filtered through a bucket with org-scoped policies
CSV export available from any list view
EU-hosted (Frankfurt) on Supabase + Netlify

If you're preparing for an MDR audit and your current system is Excel + email, you have a meaningful gap. Start a free 30-day trial to see how much of that gap closes in an afternoon of setup.