Choosing between a hospital channel and a direct-to-patient channel is not a marketing decision. It rewrites your intended purpose, changes who your IFU is written for, pulls distance selling rules under MDR Article 6 into scope, changes your usability engineering file, and moves reimbursement from the hospital's budget to the patient's wallet or an insurer's formulary. Pick the channel before you write the clinical evaluation plan.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • B2B hospital sales and direct-to-patient MedTech are not two variations of the same device. Under MDR they are two different regulatory pathways driven by who the intended user is.
  • If the intended user is a lay person, MDR Annex I Chapter III §23 triggers a set of IFU and labelling duties that a professional-user device does not face.
  • MDR Article 6 brings devices sold at a distance, for example through a website, into full MDR scope regardless of where the seller sits.
  • Usability engineering under EN 62366-1:2015+A1:2020 and risk management under EN ISO 14971:2019+A11:2021 scale with the foreseeable user, not with the manufacturer's wish.
  • Reimbursement economics differ by an order of magnitude between the two channels, and the clinical evidence a payer demands is different from the evidence a hospital procurement committee accepts.

Why this matters

We have watched at least a dozen founders lose twelve months by starting in a hospital channel, hitting procurement friction, and deciding to pivot to direct-to-patient as a rescue strategy. The pivot is almost never free. The intended purpose changes. The intended user changes. The IFU has to be rewritten. The usability engineering file has to be redone with lay users in the formative and summative studies. The clinical evaluation has to be reframed around patient outcomes rather than clinician workflow. And the cybersecurity and data protection story changes because you are now handling consumer devices on consumer networks under GDPR Article 9.

The alternative pivot, from direct-to-patient to hospital, is slightly less painful on the file but murderous on the business model. A device priced at EUR 89 for the consumer cannot suddenly cost EUR 3,400 for a hospital without new clinical evidence justifying the price.

The lesson is not that one channel is better. It is that the channel choice has to be made, consciously, at the start of the regulatory path, and stuck to through at least the first CE cycle.

What MDR actually says

Two articles and one annex section do most of the work.

Article 2(12) again: intended purpose is whatever the manufacturer claims in the label, IFU, promotional material, and clinical evaluation. Changing channel changes who you are talking to, which changes claims, which changes intended purpose.

Annex I Chapter III §23 governs information supplied with the device. §23.4 specifically states that the information in the IFU "shall be written in terms readily understood by the intended user and, where appropriate, supplemented with drawings and diagrams". For a device intended to be used by lay persons, §23.4 and §23.1(d) together require the information to be understandable to a person who has no medical training, may have impaired vision or dexterity, may be stressed, and may be using the device for the first time under suboptimal conditions. That is a far higher bar than an IFU written for a trained anaesthesiologist.

Article 6 closes the loophole that direct-to-patient sellers might otherwise exploit by shipping from outside the EU. Article 6(1) applies MDR to devices offered by means of information society services (i.e. websites) to a natural or legal person established in the Union. Article 6(2) extends it further: even a device used for a commercial activity in the course of providing a health service to a natural person in the Union brings MDR into scope. Practically, this means that a direct-to-patient MedTech business targeting EU residents cannot dodge MDR by setting up its webshop outside the EU.

Article 7 prohibits misleading claims. A direct-to-patient channel is a minefield here because consumer marketing copy gravitates toward claims that a professional-channel brochure would never make. A single over-reaching line in a Meta ad is a non-conformance under Article 7.

EN 62366-1:2015+A1:2020 on usability engineering scales with user characteristics. A lay-user device needs formative and summative usability studies that include actual lay users, not convenience samples of company employees. Notified bodies scrutinise lay-user usability files more aggressively than professional-user files, because the consequence of a use error is that an untrained person hurts themselves.

EN ISO 14971:2019+A11:2021 risk management treats foreseeable misuse differently depending on the intended user. A hospital device can assume a trained clinician will not drop it in the bathtub. A consumer device cannot.

A worked example

Consider a continuous glucose monitoring patch. Same sensor, same algorithm, two different intended purposes:

Version A — hospital channel. Intended for use by healthcare professionals in an acute care setting to monitor glucose in hospitalised patients. Intended user: trained nursing staff. IFU: professional language, assumes clinical context, assumes integration with hospital monitoring systems. Usability file: formative and summative studies with nurses. Clinical evaluation: endpoints around clinical decision impact. Reimbursement: part of the hospital's DRG bundle. Price per unit: high, service component bundled.

Version B — direct-to-patient. Intended for use by diabetic adults at home to self-monitor glucose levels. Intended user: a lay person, possibly newly diagnosed, possibly elderly, possibly with impaired dexterity or vision. IFU: must be understandable without medical training, with diagrams, with a troubleshooting section, with emergency guidance. Usability file: formative and summative studies with actual patients in home environments, including edge cases like low-light and wet conditions. Clinical evaluation: endpoints around accuracy, but also around behaviour and adherence in unsupervised use. Distance selling under Article 6 applies the moment the webshop goes live. Reimbursement: national insurer formulary (e.g. DiGA in Germany for digital components, or specific aids lists for devices), or out-of-pocket consumer.

Same hardware. Two completely different technical files, two completely different clinical evaluations, two completely different post-market surveillance plans.

A founder who started on Version A and pivots to Version B after twelve months of work does not reuse the CE file. They rebuild most of it. The only artefacts that carry over cleanly are the core bench testing, the electrical safety certifications, and the software unit tests.

The Subtract to Ship playbook

Pick the channel before the clinical evaluation plan. The single most expensive decision you can defer is which user the device is for. Make it at intended purpose time, not at go-to-market time.

If you must serve both, declare it explicitly and build for the harder one. A device with two intended users is legal under MDR, but the usability file, IFU, and clinical evaluation must cover both, and the harder case dominates. In practice, building for the lay user and then additionally validating for the professional user is cheaper than the reverse pivot.

Treat Article 6 as a hard gate on every direct-to-patient channel. If you are selling through a website, Amazon, or any information society service to EU residents, Article 6 puts you fully under MDR. You cannot geofence your way out if any part of the supply chain touches the EU.

Build the lay-user IFU with a lay user in the room. Not as a focus group. As a co-author. Annex I Chapter III §23 compliance is best demonstrated by the actual understandability of the document, which you test in formative usability studies under EN 62366-1.

Map reimbursement on day one. For hospital channels, you are selling into a DRG or a direct budget line. For direct-to-patient, you are either selling out of pocket (hard, because MedTech is a trust purchase) or into a national aids list or digital health formulary (hard, because each country is different). Neither path is easier than the other; they are differently hard. What matters is that you know which one you are on before you write the clinical evaluation plan, because the evidence payers want is not the evidence clinicians want.

Guard the promotional copy under Article 7. Direct-to-patient marketing is where Article 7 non-conformities are born. Create a simple internal process: every consumer-facing claim is reviewed against the intended purpose and clinical evaluation before it goes live. This does not need to be bureaucratic. It needs to exist.

Anticipate the cybersecurity delta. A hospital device sits on a hospital network behind hospital firewalls with a trained IT team. A consumer device sits on home Wi-Fi behind a router with default credentials. Your threat model under EN IEC 81001-5-1:2022 is completely different, and so are the controls.

Reality Check

  1. Is your intended purpose currently written for a professional user, a lay user, or both? Do you know which?
  2. If it says "lay user", have you run a formative usability study with actual lay users in a realistic environment under EN 62366-1?
  3. If you are planning a website-based sale, have you mapped Article 6 obligations for every EU country you intend to reach?
  4. Is your IFU readable by someone with no medical training, impaired vision, and a stressful first-use context?
  5. Have you mapped reimbursement in at least three target markets for the channel you have chosen?
  6. Does your Article 7 promotional review process exist on paper, and does marketing know it exists?
  7. Have you modelled the cost of a forced channel pivot into your regulatory budget, or is your plan to absorb it from runway?
  8. If your device will be used in both hospital and home settings, does your risk management file under EN ISO 14971 explicitly cover the harder user environment?

Frequently Asked Questions

Can one CE certificate cover both a hospital and a direct-to-patient version of my device? Only if the intended purpose, intended user, and IFU cover both cases explicitly, and the usability engineering file and clinical evaluation demonstrate adequacy for both. Most startups find it cheaper to certify the lay-user version and extend it to professionals than to do the reverse.

Does selling from outside the EU exempt me from MDR? No. MDR Article 6 brings devices offered at a distance to EU residents into MDR scope regardless of the seller's location. A webshop hosted in Singapore that ships to Germany is fully under MDR.

What counts as a lay user under MDR? A lay user is an individual who does not have formal training in a relevant field of healthcare or medical discipline. Annex I Chapter III §23 imposes elevated information and understandability duties when lay users are intended users.

Is a direct-to-patient MedTech business cheaper to run than a hospital channel? Different-cheaper, not cheaper. You skip procurement tenders but you take on consumer acquisition costs, consumer support, and the full weight of lay-user usability and IFU obligations. The total cost is similar; the cashflow shape is different.

If I pivot from hospital to direct-to-patient mid-CE cycle, what carries over? Bench testing, electrical safety, EMC, most of the software unit tests, and the core risk management framework. What does not carry over: IFU, clinical evaluation, usability engineering file, PMS plan, and much of the labelling. Budget for a second cycle of all of those.

Does GDPR apply differently to direct-to-patient MedTech? GDPR applies to both channels, but a consumer channel puts you in direct controller position for sensitive health data under Article 9, with no hospital data protection officer to share the burden. Factor this into your cybersecurity budget.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2(12), Article 6 (devices offered at a distance), Article 7 (claims), Annex I Chapter III §23 (information supplied with the device).
  2. EN 62366-1:2015+A1:2020, usability engineering for medical devices.
  3. EN ISO 14971:2019+A11:2021, risk management for medical devices.