Need further help? We have limited capacity for consulting again. With predictable results and fixed-price offers.

Updated December 8, 2021

Do We Need a User Manual for Our Software as a Medical Device?

Dr. Oliver Eidel
Getting Started

Question

We’re developing a mobile app which will be a medical device. We’re wondering whether we have to provide a user manual for it, keeping in mind that most (non - medical device) apps on the market don’t have user manuals and nobody reads user manuals anyway. Some consultants even told us we need a user manual printed on paper which we send to users. What the hell?

Short Answer

It’s unclear, it’s a mess and we don’t know. But we have a common-sense strategy.

Our suggested strategy for MDR class I and IIa would be this:

  • Have an electronic user manual which is accessible in your app by e.g. linking to your website which hosts an up-to-date (html / pdf) user manual.
  • Do a thorough Usability test whether users can actually use your software without reading the manual beforehand and document that well.
  • Add an entry to your risk analysis that users will likely use your software without reading the manual and list your usability test as risk control measure with (hopefully) great effectiveness, based on the (hopefully positive) outcome of that test. Also document a risk assessment for why an electronic provision of your instructions for use is sufficient compared to a paper-based version (yes, sorry for that).

Long Answer

In a nutshell, there are conflicting regulations / guidance documents at the moment. There is:

  1. The old EU regulation 207/2012 on instructions for use for medical devices which refers to the MDD while still being applicable,
  2. A draft for a new EU regulation on instructions for use for medical devices that was published in spring 2021 for public consultation and is not applicable yet,
  3. The new MDR (regulation 2017/745) and its provisions on instructions for use,
  4. The much newer guidance document MDCG 2021-24 which actually deals with classification of medical devices under the MDR but also mentions instructions for use.

Old Regulation: Paper Is a Must.

In greatly simplified terms and ignoring a ton of important details, according to 207/2012, you always need a paper-based user manual by default, especially if your device is used by patients. The old 2012 regulation only allowed electronic manuals where used by “professionals”, and manufacturers had to create a ton of documentation.

The New Draft: Paperless But Still a Headache.

It’s been a long time coming: Finally, there’s a number of exceptions from the rule and software is generally exempt from the paper form.

Article 3, Para. 3:

For software covered by Regulation (EU) 2017/745, manufacturers may provide instructions for use in electronic form by means of the software itself instead of in paper form.

That means: Arguing for paperless will be easier, but the burden of documentation remains. Manufacturers are required to conduct a thorough risk assessment regarding the electronic user manual, considering the knowledge of their users, characteristics of the use environment, impact of unavailability of a user manual, etc.

And nevertheless, manufacturers will be required to provide users with a paper copy if requested (Art. 5, Para. 3). That sounds ridiculous and let’s hope that nobody will ever use your contact form for such a request.

MDR and MDCG 2021-24: Do We Need a Manual At All?

The General Safety and Performance Requirements (Annex I) of the MDR state in Chapter 3:

By way of exception, instructions for use shall not be required for class I and class IIa devices if such devices can be used safely without any such instructions and unless otherwise provided for elsewhere in this section.

Similarly, MDCG 2021-24 Para. 2.6 states:

Generally, instructions for use must be supplied together with the device. By way of exception, class I and IIa devices may be supplied without instructions for use if such devices can safely be used without the instructions and no other provisions of Annex I Section 23 state otherwise.

Does that mean the days of 100 pages of user manual work are numbered?

Let’s not get ahead of ourselves. First, the MDCG states “supplied together with”, essentially saying “even if you write a manual, you may not have to ship it alongside your device”. This is already cool as, for class I and IIa devices, you can opt to not supply instructions for use with the device but instead make them available somewhere in case users actually want to read them.

Now, let’s not forget: Instructions for use may help manufacturers as a (legal) safety net and as part of device risk mitigation measures. In order to omit instruction for use altogether you will probably need to implement a bunch of warnings and notifications in your software. Depending on your device, it might be easier to throw all these legal and regulatory disclaimers into one document that is easier to maintain than dozens of different features. And then keep in mind that both MDR and MDCG reference the old regulation 207/2012 with its stricter provisions and which is (yet) still applicable.

The decision is ultimately up to you. Our initially suggested approach goes again as follows: Have an electronic user manual and create some solid proof that your device can be used by users who haven’t read it (= usability tests). Again, assuming you’re MDR class I or IIa. In any case and as always, you will need to document a reasoning to show to your auditor if they ever ask about your instructions for use. Good luck! :)

Congratulations! You read this far.

Get notified when I post something new.

Sign up for my free newsletter.

I work as a regulatory consultant for Healthcare software startups. I try to publish all my knowledge here so that startups can certify their medical devices themselves in the future.

If you're still lost and have further questions, just send me an email and I'll be happy to answer them for free. More about me

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.