---
title: MDR Use Specification: Users, Environments, Profiles
description: The MDR use specification under IEC 62366 is the most-skipped document. Decompose every procedure to make use-related hazards visible.
authors: Tibor Zechmeister, Felix Lenhard
category: Electrical Safety & Systems Engineering
primary_keyword: MDR use specification IEC 62366
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-use-specification-iec-62366
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Use Specification: Users, Environments, Profiles

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The use specification is the foundation document of the MDR usability process under EN 62366-1:2015+A1:2020. It is also the document startups skip most often. Done well, it decomposes every real-world procedure into concrete steps, user groups, and environments, and makes use-related hazards visible before any interface is drawn. Done badly, or not at all, it hides exactly the hazards that EN 62366-1 and MDR Annex I GSPR §5 and §22 require you to address.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- The use specification is clause 5.1 of EN 62366-1:2015+A1:2020 and the first deliverable of the usability engineering process.
- It documents the intended medical indication, intended patient population, intended part of the body or type of tissue, intended user profiles, intended use environments, and the operating principle.
- Under MDR Annex I GSPR §5 it supports the obligation to take user training, experience, education, and environment into account when controlling use-related risk.
- The single most common notified body finding on usability is that the use specification is either missing, generic, or does not decompose real-world procedures into concrete tasks.
- Divide and conquer is the only approach Tibor has seen work at scale. Split operation, cleaning, transport, installation, disposal, and edge cases into separate procedures, each with its own user, environment, and hazard profile.
- A complete use specification drives the rest of the usability file. A weak one poisons it.

## Why the use specification matters (Hook)

In Tibor's experience as a notified body lead auditor, the use specification is the document that reveals whether a startup understands usability engineering at all. A thin, generic use specification almost always predicts a thin, generic summative evaluation and a risk management file that missed entire hazard categories.

The pattern Tibor sees across audits is uncomfortably consistent. A founder arrives at the usability review holding a one-page document that reads roughly as follows: "Intended user: clinician. Intended environment: clinical setting. Intended use: measure X in patient Y." That is not a use specification. That is a label. When the auditor asks what happens when the device is cleaned, who cleans it, where, with what product, and whether the cleaner is the same person who operates the device, the founder has no documented answer. When the auditor asks about transport between rooms, about initial installation by a service engineer, about the user who unboxes the device for the first time, the silence is the finding.

The reason this matters for safety and not only for compliance: every real-world procedure is an opportunity for a use-related hazard. The operator who carries the device from one room to another is exposed to drop hazards, trip hazards, and the risk of placing the device on an unstable surface. The cleaner is exposed to chemical incompatibility between a disinfectant and the housing, or to residual contamination. The service engineer is exposed to installation errors that a clinician will later inherit. If none of these users, environments, and procedures live in the use specification, none of the resulting hazards live in the risk analysis. The usability file will look complete and the device will still surprise its manufacturer after market entry.

Felix has seen the startup version of the same story many times. A team builds a beautiful device, runs a usability review with two friendly clinicians, and declares the use specification complete in an afternoon. Six months later the notified body rejects the technical file and demands a rebuild. The cost is not the few days of rework on the document itself. The cost is re-running formative and summative evaluations against the new scope, because the tests were built on a use specification that did not reflect reality.

## What MDR actually says (Surface)

MDR does not use the term "use specification" directly. The regulation speaks in the language of intended purpose and of ergonomic design, and leaves the process detail to the harmonised usability standard.

**MDR Article 2(12)** defines intended purpose as "the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation". The intended purpose is the regulatory anchor. The use specification is the engineering decomposition of that intended purpose into users, environments, and procedures concrete enough to drive design and risk analysis.

**MDR Annex I GSPR §5** addresses the ergonomic features of a device and the environment in which it is intended to be used. The GSPR explicitly requires manufacturers to take into account the technical knowledge, experience, education, training, and the use environment, and the medical and physical conditions of intended users. Each of those five factors is a direct input to the use specification.

**MDR Annex I GSPR §22** requires that devices intended to be used by lay persons be designed and manufactured to perform appropriately given the skills and means available to lay users, and to minimise the risk of incorrect handling. For any lay-user device, GSPR §22 cannot be closed out without a use specification that names lay users as a distinct user group and describes their real environment.

The standard that translates these requirements into a process is **EN 62366-1:2015+A1:2020, clause 5.1**. Clause 5.1 requires the manufacturer to prepare a use specification that includes:

- the intended medical indication
- the intended patient population
- the intended part of the body or type of tissue applied to or interacted with
- the intended user profile
- the intended use environment
- the operating principle of the device

The standard is explicit that this specification drives the rest of the usability engineering file. Clause 5.2 on hazard-related use scenarios and clause 5.3 on the user interface specification both feed from clause 5.1. If clause 5.1 is thin, everything downstream is thin by construction.

## A worked example (Test)

Consider a handheld battery-powered device intended to measure a physiological parameter at the bedside in a hospital, and optionally at home by the patient or a family caregiver.

A generic use specification would read: "Users: clinicians and patients. Environment: hospital and home. Indication: measurement of parameter X."

A divide-and-conquer use specification decomposes the same device into at least the following procedures, each with its own user profile and environment.

**Procedure 1: Initial installation and commissioning.** User: a biomedical engineer on site. Environment: storage room or clinical technical area. Hazards surfaced: incorrect firmware version, incorrect pairing with a hospital network, damage during unboxing, missing calibration step.

**Procedure 2: Routine bedside measurement by a clinician.** User: nurse with ward experience, under time pressure, gloved hands, ambient noise. Environment: patient room with variable lighting, possibly at night. Hazards surfaced: misreading of display, cross-contamination between patients, activation of wrong measurement mode.

**Procedure 3: Cleaning and disinfection between patients.** User: ward nurse or dedicated cleaning staff. Environment: utility room or bedside, short time window. Hazards surfaced: chemical incompatibility between disinfectant and housing, water ingress into a battery compartment, residual contamination due to missed surfaces.

**Procedure 4: Transport between rooms.** User: clinician or porter. Environment: corridors, lifts, occasionally outdoor courtyard in transfer. Hazards surfaced: drop, shock, temperature change, battery cold-soak in winter.

**Procedure 5: Home use by patient or family caregiver.** User: lay person, potentially 70-plus years old, potentially with impaired vision or dexterity. Environment: kitchen table, sofa, bedroom, variable lighting, pets, children. Hazards surfaced: misinterpretation of result, forgotten battery charging, device left where a child can reach it, misuse of the charger.

**Procedure 6: Battery replacement and charging.** User: patient or clinician. Environment: wall socket with unknown quality. Hazards surfaced: use of a non-approved charger, deep discharge, mechanical damage to battery door.

**Procedure 7: End of life and disposal.** User: clinical engineering or patient. Environment: clinical waste or municipal waste. Hazards surfaced: data residue on internal storage, battery thermal event in waste stream.

Seven procedures from one device. Each one has a user profile, an environment, and a hazard profile that the generic version did not surface. The risk management file built from the second use specification will be richer. The formative evaluations will be targeted. The summative evaluation will test the tasks that actually matter.

This is what Tibor means by divide and conquer.

## The Subtract to Ship playbook (Ship)

A lean team cannot spend a quarter drafting a use specification. The Subtract to Ship playbook for this document fits in a week of concentrated work and traces every step to EN 62366-1 clause 5.1 and MDR Annex I GSPR §5 and §22.

**Step 1. Start from the intended purpose.** Write the one-paragraph intended purpose statement first, aligned with MDR Article 2(12). This is the regulatory anchor. Every user, environment, and procedure downstream must connect back to this paragraph.

**Step 2. List every real-world procedure, not only "operation".** Operation is only one procedure. Add installation, commissioning, calibration, routine use, cleaning, disinfection, sterilisation if relevant, battery management, transport, storage, software update, troubleshooting, and end of life. If the device is a connected device, add account setup, app installation, and unpairing.

**Step 3. For each procedure, name the user explicitly.** Do not write "clinician". Write "nurse, 3 to 5 years of ward experience, gloved hands, English as a second language, working a night shift". The more concrete the profile, the more hazards you will see.

**Step 4. For each procedure, describe the environment with the same specificity.** Lighting, noise, temperature, humidity, time pressure, interruptions, other devices nearby, wireless congestion. The environment is never neutral.

**Step 5. Add the lay user if there is any chance the device could be handled by one.** GSPR §22 is triggered by the possibility, not the preference. If a patient could ever unbox, charge, or move the device, lay use belongs in the specification.

**Step 6. Connect each procedure to the risk management file.** The link from the use specification to EN ISO 14971:2019+A11:2021 is the point of the whole exercise. Hazard analysis should be driven by procedures, not by an imagined "normal use".

**Step 7. Version the document and keep it live.** The use specification is not a one-shot deliverable. It is updated when the design changes, when new clinical data arrives from post-market surveillance, and when the intended purpose is refined. Treat it as a controlled record, not a launch document.

## Reality Check

Answer each question honestly. A no is not a failure, it is a backlog item.

1. Does the current use specification name at least five distinct procedures, or only "operation"?
2. For each procedure, is there a named user profile with experience level, physical conditions, and language assumptions?
3. For each procedure, is there a concrete environment description with lighting, noise, time pressure, and other devices present?
4. If the device could ever be handled by a lay person, is that lay user documented as a distinct profile?
5. Is the use specification connected to the risk management file such that every procedure drives a hazard analysis entry?
6. Has the use specification been updated in the last six months, or is it the same document the team wrote before the first prototype?
7. If a notified body auditor asked for the use specification tomorrow, would the answer be one concrete document or a set of overlapping drafts?
8. Does the intended purpose statement in the use specification match the intended purpose statement in the technical file and the instructions for use, word for word?

## Frequently Asked Questions

**Is the use specification the same as the intended purpose?**
No. The intended purpose is a regulatory statement under MDR Article 2(12) that lives on the label, in the instructions for use, and in the clinical evaluation. The use specification is the engineering decomposition of that intended purpose into users, environments, procedures, and the operating principle. Intended purpose is one paragraph. A use specification for a real device is several pages.

**Does EN 62366-1 require a specific template for the use specification?**
No. Clause 5.1 lists the required content elements but does not prescribe a template. Any format that covers intended medical indication, patient population, body site, user profile, use environment, and operating principle is acceptable. A table with procedures as rows and content elements as columns is a common and defensible format.

**Can a startup reuse a use specification from a similar predicate device?**
Reuse is tempting but almost always creates audit findings. A predicate device has its own user profile and environment. Copying its use specification imports assumptions that may not hold for the new device. Reusing the structure is fine. Reusing the content without verification is not.

**Who should write the use specification?**
A cross-functional team. In Tibor's experience, a credible use specification is written jointly by a regulatory lead, a clinical lead, a usability or human factors lead, and at least one engineer who knows the device. A use specification drafted by a single person in an afternoon is the most reliable predictor of a failed summative evaluation.

**How does the use specification relate to the risk management file?**
The use specification is the input. Each procedure, user, and environment feeds hazard identification under EN ISO 14971:2019+A11:2021. Without a decomposed use specification, hazard analysis is based on imagination rather than on concrete tasks. That is the gap where real-world harms hide.

## Related reading
- [MDR Usability for Electrical Devices: IEC 60601-1-6 and IEC 62366](/blog/iec-60601-1-6-usability-cross-reference) explains why the collateral standard points to EN 62366-1 and what that means for electrical devices.
- [MDR Annex I General Safety and Performance Requirements](/blog/mdr-annex-i-gspr) gives the broader GSPR context that §5 and §22 sit inside.
- [Documenting Intended Purpose in the Technical File](/blog/documenting-intended-purpose-technical-file) connects the intended purpose statement that anchors the use specification to the technical documentation.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2(12), Annex I GSPR §5, Annex I GSPR §22.
2. EN 62366-1:2015+A1:2020, Medical devices, Part 1: Application of usability engineering to medical devices. Clauses 5.1, 5.2, 5.3.
3. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.

---

*This post is part of the [Electrical Safety & Systems Engineering](https://zechmeister-solutions.com/en/blog/category/electrical-safety) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*