Use-related risk analysis is the bridge between EN 62366-1:2015+A1:2020 and EN ISO 14971:2019+A11:2021. It takes the use specification and the hazard-related use scenarios from the usability engineering process and converts them into risks that feed the risk management file. When the use specification is narrow, the risk analysis misses scenarios. When the use specification is broad and honest, the hazards surface early, where they are cheap to control.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Use-related risk analysis, sometimes shortened to URRA, is the part of the risk management process that deals with hazards arising from user interaction with the device. It is required under MDR Annex I §5 and §22 and operationalised through EN 62366-1:2015+A1:2020 and EN ISO 14971:2019+A11:2021.
  • The process flows from the use specification (who, where, how, under what conditions) into hazard-related use scenarios, into the risk analysis, and back into design controls. None of these steps can be skipped.
  • The most common failure is a narrow use specification. If the use specification only covers ideal indoor conditions with trained users, the hazard-related use scenarios never appear, and the risk analysis comes back clean when the real world is dangerous.
  • Tibor's tongue-controlled wheelchair story (a mouthpiece colour that attracted bees when used outdoors) is the canonical example of what a narrow use specification misses.
  • Use-related risk analysis is not usability testing. Testing comes later. Analysis happens on paper, based on the use specification and expert foresight.

Why this matters

Tibor has a story that founders remember after the rest of a training session has faded. A company built a tongue-and-mouth controlled wheelchair for quadriplegic patients. The mouthpiece sat at the user's face, operated by tongue and breath. During design, the team chose a colour for the mouthpiece. It tested fine indoors in the lab and in the clinical validation sessions. The device passed its internal reviews.

Then the auditors asked a question the team had not asked themselves: what happens outdoors? The team did not have an answer. They had only tested indoors. An outdoor review revealed that the chosen mouthpiece colour was a colour bees are strongly attracted to. A user could have a bee fly into the mouthpiece area and be stung on the face. The clinical consequence was clear and serious.

The fix was a colour change and a documented outdoor use scenario. The lesson was not that the team should have chosen a different colour. The lesson was that the use specification had only covered indoor environments. With a narrow use specification, the hazard-related use scenario for "outdoor use, insect encounter" did not exist. Without the scenario, use-related risk analysis could not surface the hazard. The gap was upstream of the analysis, in the scoping.

Felix coaches startups who treat use-related risk analysis as a technical exercise carried out by one engineer on one afternoon. That approach cannot catch a bee. Use-related risk analysis is only as good as the use specification it sits on, and the use specification is only as good as the multidisciplinary imagination that went into writing it.

What MDR actually says

The MDR obligation for use-related risks is direct and strong, even though the regulation does not use the phrase "use-related risk analysis" itself. The phrase comes from the standards.

MDR Annex I Chapter I, General Safety and Performance Requirements. Manufacturers must eliminate or reduce risks as far as possible through safe design and manufacture. The "as far as possible" ratchet applies to use-related risks exactly as it applies to electrical, mechanical, or biological risks.

MDR Annex I §5. Devices shall be designed and manufactured so that risks linked to ergonomic features of the device and the environment in which the device is intended to be used are reduced as far as possible. The text explicitly lists technical knowledge, experience, education, training, use environment, and medical and physical condition of intended users as factors that must be considered.

MDR Annex I §22. Devices for lay users must be designed to cope with variation in the lay user's technique and environment. The article is written with home-use and consumer-facing devices in mind but the principle applies to any device where user variability is a meaningful source of hazards.

EN 62366-1:2015+A1:2020, clause 3. Defines the core vocabulary: use specification, hazard-related use scenario, use error, abnormal use, and user interface. Clause 5.3 requires the identification of hazards and hazardous situations related to the user interface. Clause 5.5 requires the identification of hazard-related use scenarios. These scenarios are the input to the risk analysis.

EN ISO 14971:2019+A11:2021. Defines the risk management process. Use errors are a source of hazardous situations, and therefore every hazard-related use scenario from EN 62366-1 is an input to the EN ISO 14971 risk analysis. Clause 5 of the standard requires the manufacturer to identify hazards and hazardous situations. Clause 6 requires risk estimation. Clause 7 requires risk evaluation and control.

Plain-language translation: the MDR does not let manufacturers write off use errors as training problems or user problems. Use errors are hazards, and hazards must be analysed and controlled. EN 62366-1 supplies the discovery method. EN ISO 14971 supplies the analysis and control method. The bridge is the hazard-related use scenario.

A worked example

A Class IIa wearable device for continuous glucose monitoring, intended for adult patients with diabetes, used at home and outside the home, replaced by the user every fourteen days.

The team starts by writing the use specification. First draft, narrow:

"Intended users: adults with type 1 or type 2 diabetes. Intended environment: at home. Operating principle: sensor applied to upper arm, data transmitted to smartphone app."

This is the draft that would miss the bee. Tibor walks the team through a scope expansion. The real use specification has to cover:

  • Intended users: not just "adults with diabetes" but the full distribution. Some have reduced vision from diabetic retinopathy. Some have reduced fine motor control. Some are elderly and technology-averse. Some are adolescents.
  • Intended environment: home, but also office, school, gym, swimming pool, sauna, aeroplane, outdoor hiking, cold weather, hot weather.
  • Operating principle: sensor application (the user does this, not a clinician), sensor replacement, pairing with phone, reading alerts at night, reacting to low-battery warnings.

With this broader use specification, the team writes hazard-related use scenarios. Each scenario is a specific user, in a specific environment, attempting a specific task, with a specific foreseeable deviation. Examples:

  1. Elderly user with reduced vision applies sensor to the wrong body location because the IFU pictogram is not visible under kitchen lighting.
  2. Adolescent user detaches sensor during contact sport without realising, because the alert is a gentle vibration that is masked by physical activity.
  3. User showers with the sensor and the adhesive weakens earlier than expected, so the sensor detaches mid-cycle and the user does not notice until the next scheduled reading.
  4. User at an airport with phone in airplane mode misses a critical low-glucose alert because the alert is cloud-mediated.
  5. User at night silences the alert and falls asleep before responding.

The team takes each scenario into EN ISO 14971 risk analysis. For each, they estimate severity and probability, identify hazards, decide control strategies, and reduce residual risk as far as possible. Control strategies include: larger and higher-contrast pictograms in the IFU, a local-only critical alert that bypasses cloud latency, a dual-channel alert (vibration plus audio) for critical events, and a default night mode with non-dismissible critical alerts.

None of those controls would have existed with the narrow first-draft use specification. Every one of them exists because the use-related risk analysis was driven by a realistic, broad, honest scoping of who uses the device and where.

The Subtract to Ship playbook

Felix's approach to use-related risk analysis is built around one principle: the scope has to be brutally honest before any analysis is worth doing.

  1. Write the use specification broad first, then justify narrowing. Start with every foreseeable user, environment, and condition. If the team wants to narrow the scope (say, to exclude outdoor use or exclude paediatric users), the narrowing must be a documented decision with a rationale, not a default.

  2. Decompose the tasks by hazard-relevance. Unboxing, initial setup, routine use, recovery from error, cleaning, transport, storage, disposal. Each is a task. Each task has foreseeable deviations. Tibor's rule is that if a task has no foreseeable deviations documented, the analysis has not actually been done yet.

  3. Run the hazard-related use scenario workshop with a multidisciplinary team. Tibor insists on the full team: engineering, clinical, regulatory, risk, quality, and where possible, a real representative user. One person cannot catch bees alone. Different disciplines surface different hazards.

  4. Feed the hazard-related use scenarios directly into the EN ISO 14971 risk analysis. No translation step. The scenario is the hazard input. Use a traceable link (scenario ID referenced in the risk table) so auditors can walk the chain in either direction.

  5. Apply the control hierarchy in order, always. Inherent safety by design first. Protective measures second. Information for safety last. Tibor's line is that information for safety is a legitimate control but rarely the most efficient one, and notified bodies flag control strategies that skipped straight to warnings and labels when design changes were available.

  6. Reduce risk as far as possible, not as low as reasonably practicable. EN ISO 14971 clause 8 historically allowed "as low as reasonably practicable" (ALARP). MDR requires "as far as possible". The difference matters. A control that is feasible but inconvenient is still required. Budget is not a valid reason to skip it.

  7. Update the analysis after every design change and after every post-market signal. Use-related risks shift as the real user population interacts with the device. A signal from post-market surveillance that an unforeseen use is happening is an immediate trigger to revisit the use specification, regenerate scenarios, and update the analysis.

Reality Check

  1. Does the use specification cover the full foreseeable range of users, environments, and conditions, or does it read like a description of the ideal case?
  2. For each task in the use specification, has the team written down at least three foreseeable deviations?
  3. Does every hazard-related use scenario have a traceable link into the EN ISO 14971:2019+A11:2021 risk management file?
  4. Was the use-related risk analysis run as a workshop with a multidisciplinary team, or as an individual exercise by one engineer?
  5. For every use-related hazard with a control strategy of "information for safety", has the team documented why inherent safety and protective measures were not feasible?
  6. When was the last time the use specification was reviewed against actual post-market data from real users?
  7. Could the team trace a single use error finding from the field back to a hazard-related use scenario, a risk analysis entry, and a control decision?
  8. Does the residual risk after controls meet the "as far as possible" bar, or only the "as low as reasonably practicable" bar from older ISO 14971 versions?

Frequently Asked Questions

Is use-related risk analysis a separate document from the risk management file? Not usually. Most manufacturers handle it as a structured section inside the EN ISO 14971:2019+A11:2021 risk management file, cross-referenced to the usability engineering file for EN 62366-1:2015+A1:2020 compliance. The content must be complete and traceable regardless of how it is formatted.

When in development should use-related risk analysis start? As soon as there is a use specification. Waiting until a prototype exists is too late, because the prototype locks in design decisions that the analysis should have influenced. Tibor's rule: the first use-related risk analysis happens on paper, before any hardware or software is committed.

Does use-related risk analysis replace usability testing? No. Analysis and testing are different steps. Analysis is done by the team using foresight, the use specification, and expert knowledge. Testing (formative and summative) is done with representative users interacting with prototypes or real devices. Both are required. One predicts, the other validates.

How does the MDR "as far as possible" standard differ from the older "ALARP" language? ALARP (as low as reasonably practicable) allows a trade-off against cost and effort. MDR requires "as far as possible", which removes cost as a justification for leaving a controllable risk in place. Risk controls that are technically feasible are required even if inconvenient.

Who signs off use-related risk analysis? The risk management owner and the usability engineering owner jointly, under the quality management system. Under EN ISO 13485:2016+A11:2021, sign-off authority is defined in the quality manual. Notified body auditors will check both the content and the authorisation trail.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter I, Annex I §5, Annex I §22.
  2. EN 62366-1:2015+A1:2020, Medical devices – Application of usability engineering to medical devices. Clauses 3, 5.3, 5.5, 5.7.
  3. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices. Clauses 5, 6, 7, 8.
  4. EN ISO 13485:2016+A11:2021, Medical devices – Quality management systems – Requirements for regulatory purposes.