The most common usability failure in connected medical devices is the quiet assumption that "the app part is obvious". An app that an engineering team can download, configure, pair, and operate in ninety seconds is not the same app when the intended user is eighty years old, tired, and in a poorly lit kitchen. MDR and EN 62366-1 treat the app as part of the device. Skipping app usability is skipping device usability.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Mobile medical apps are part of the medical device under MDR and must be covered by the EN 62366-1:2015+A1:2020 usability engineering process, not treated as a supporting tool.
  • The eighty-year-old user is the standing test case: if the intended user population includes older adults with limited smartphone experience, the app must be evaluated with that population.
  • Connected devices with an app plus hardware combination fail usability most often on onboarding, pairing, and alert interpretation.
  • The summative evaluation must happen with recruited users in a realistic environment, not with the founding team in the office.
  • MDR Annex I §5 requires manufacturers to consider the technical knowledge, experience, education, and training of the intended users; this is not optional for consumer-facing apps.
  • The use specification must decompose every real-world procedure, including download, permission grants, pairing, updates, and loss-of-connection behaviour.

Why app usability is the most-skipped step in connected MedTech

Tibor sees a recurring pattern in connected medical devices. The hardware team pours engineering effort into sensor accuracy, enclosure quality, and electrical safety. The software team builds a competent app. Somewhere between the two, usability engineering gets quietly rescoped to "the hardware bits", because "the app is just an app and everyone knows how to use apps".

That assumption is the most expensive silent decision in a connected MedTech file.

In one of Tibor's most direct stories from the audit floor, the intended user population for a connected device included adults up to and beyond age eighty. The device hardware was well-designed. The app was built for a first-time user with a current smartphone, recent operating system, and the ability to navigate permission dialogs, Bluetooth settings, and app store authentication. When the notified body asked for the summative evaluation evidence, there was no evidence that the app had been tested with users resembling the actual intended population. That gap is not a paperwork issue. It is a clinical risk issue. An eighty-year-old user who cannot download, configure, and pair the app safely produces exactly the same clinical consequence as a physical misuse of the hardware.

Felix has coached founders through exactly this trap. The founding team, almost always young and technically fluent, tests the app on themselves. It works. They ship. The first real user cannot complete pairing. The first week of post-market surveillance data shows dozens of failed setups. Change control follows.

What MDR and EN 62366-1 actually say about apps

There is no separate lighter regime for mobile medical apps inside EN 62366-1:2015+A1:2020. The standard applies to any user interface on a medical device, regardless of whether that interface is a physical button, a touchscreen on a piece of hardware, or a screen on a consumer smartphone running the manufacturer's app. If the app is part of the device, the app is inside the usability engineering process.

MDR Annex I §5 requires manufacturers to reduce risks related to the ergonomic features of the device and the environment in which it is intended to be used, taking into account the technical knowledge, experience, education, training, use environment, and medical and physical conditions of the intended users. For a consumer-facing connected device, the intended user population is often broad and skews older than the team that built the product. Reading Annex I §5 literally: if eighty-year-olds are in the user population, the ergonomic and cognitive characteristics of eighty-year-olds must inform design and evaluation.

MDR Annex I §22 applies to devices that incorporate electronic programmable systems and to software that is itself a device. Both cover the app layer.

MDR Annex I §23 governs information supplied to the user. For a connected device, that information is often delivered through the app itself: onboarding screens, tooltips, permission explanations, pairing instructions. The app is delivering labelling, and the labelling must be understandable to the intended user.

MDR Annex VIII Rule 11, interpreted through MDCG 2019-11 Rev.1, frequently pulls the software part of a connected device into Class IIa or higher, which means notified body review of the technical documentation. Inside that review sits the usability engineering file for the whole device, including the app.

A worked example: a connected patch plus mobile app for a broad adult population

A connected skin patch measures a physiological parameter and transmits data to a smartphone app, which displays trends and triggers alerts. Intended users: adults with the target condition, including users aged sixty-five and older. Intended environment: at home, any time of day, variable lighting, variable smartphone models and operating system versions.

A competent usability engineering process for this product looks like this.

Use specification, decomposed. Not "the user uses the app". Instead: user receives the device, opens the box, downloads the app from their app store, creates an account, grants location permission, grants Bluetooth permission, pairs the patch, applies the patch correctly, understands the meaning of each screen, reacts correctly to an alert, handles a low-battery state, handles a loss-of-connection state, handles an operating system update that resets Bluetooth permissions, handles replacing the patch, handles uninstalling and reinstalling the app, handles a new phone.

Each of these is a procedure. Each procedure has hazard-related use scenarios. Each scenario may have a use error with a clinical consequence.

Formative evaluation. Small samples, early prototypes, including users from the older end of the intended population. Tibor's rule: do not formative-test only on the engineering team. That tells you the app is good for engineers.

Summative evaluation. Recruited users representative of the full intended population. For a device whose users include people aged eighty, the summative sample must include people aged eighty. The evaluation happens in a realistic environment, not in a usability lab that resembles nothing the user will ever experience.

Connected-device specific hazards. Alert misinterpretation, pairing loss during an alert condition, notification delivery delays from the operating system, battery optimisation behaviour that kills background processes. Each one is a use scenario the usability engineering file must address.

Felix's observation from coaching connected-device founders: teams that run summative evaluation with the real user population almost always discover at least one blocking usability issue that no member of the team had anticipated. That is exactly the point of the evaluation.

The Subtract to Ship playbook for mobile medical app usability

Step 1. Treat the app as part of the device, always. Every artefact that exists for the hardware exists for the app: use specification, user interface specification, hazard-related use scenarios, formative evaluation, summative evaluation, usability engineering file.

Step 2. Define the intended user profile honestly. If the product is a consumer device, the intended user population is not the founding team. If the target condition skews older, the user profile is older. If the user may be tired, stressed, in pain, or distracted, the profile must say so.

Step 3. Decompose every procedure. Download, install, permissions, pairing, first use, normal use, error recovery, handover, alert response, phone change, operating system update. Each is a procedure. Each is a hazard source.

Step 4. Run summative with the real population in the real environment. No shortcuts. Not the team. Not friendly customers. Not KOLs. Recruited users from the intended population, in a realistic environment, with no coaching.

Step 5. Build an alert strategy the user can actually handle. Notifications that compete with every other notification on the phone are a hazard category. The usability engineering file must analyse how alerts behave inside the user's real phone environment.

Step 6. Plan for post-market usability feedback from day one. Mobile medical apps generate usability data continuously. Funnel that data into the post-market surveillance system and back into the risk and usability engineering files. Do not wait for the next surveillance audit to notice a pattern.

Reality Check

  1. Does the summative evaluation sample match the intended user population, including age, technical comfort, and environment?
  2. Has the team tried to complete every procedure, including phone change and operating system update, without coaching?
  3. Are alerts analysed as hazards inside the ISO 14971 risk file, not just as product decisions?
  4. Is the app inside the usability engineering file, or is it "covered separately"?
  5. Have the onboarding, permissions, and pairing flows been tested with users who have never used an app like this before?
  6. Does the use specification include "loss of connection", "low battery", and "background kill" as procedures?
  7. Is the team prepared to handle usability findings from post-market data through a proper change-control loop?

Frequently Asked Questions

Is a mobile medical app really part of the medical device for MDR purposes? Yes, if the app is intended by the manufacturer to be used for a medical purpose as part of the device. In that case, the app is inside the scope of MDR and must be covered by the usability engineering process under EN 62366-1.

Our app is simple. Does it still need formal usability engineering? If the app qualifies as a medical device or part of one, the obligations under EN 62366-1 apply regardless of perceived simplicity. What looks simple to the developer often looks complex to an older or first-time user.

Can we exclude older users from the intended user population to avoid testing with them? Only if the intended purpose genuinely excludes them and the exclusion is documented and defensible in the clinical evaluation. Writing "intended for adults who are technically comfortable" does not usually survive notified body scrutiny if the target condition is common among older adults.

Does formative evaluation with our team count as evidence? No. Formative evaluation with internal users is useful for learning but is not summative evidence. Summative evaluation requires recruited users representative of the intended population.

What happens when the operating system or phone changes after release? The usability engineering file must plan for lifecycle events. Operating system updates, permission-model changes, and phone replacements are foreseeable and must be addressed in the use specification and in post-market surveillance.

How does this connect to instructions for use? For a connected device, much of the instructional content lives inside the app. That content is labelling under MDR Annex I §23 and must be understandable to the intended user.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §5, §22, §23. Annex VIII Rule 11.
  2. EN 62366-1:2015+A1:2020, Medical devices. Part 1: Application of usability engineering to medical devices.
  3. EN 62304:2006+A1:2015, Medical device software. Software life cycle processes.
  4. EN ISO 14971:2019+A11:2021, Medical devices. Application of risk management to medical devices.
  5. MDCG 2019-11 Rev.1 (June 2025), Guidance on qualification and classification of software in Regulation (EU) 2017/745 MDR and Regulation (EU) 2017/746 IVDR.