Articles Getting Started

Updated March 16, 2023

Writing An Intended Use for Software as a Medical Device

Dr. Oliver Eidel

The Intended Use is the most important document, ever, if you want to certify your software as a medical device. Why? It states what your software does and in which context it is used.

Why Your Intended Use Is Important

Why is that so important? Because it decides whether you are a medical device in the first place, and if so, what class of medical device (I through III) it is. The lower your class is, the less effort and cost is involved in getting it certified.

Content of an Intended Use Document

So how do you write an intended use? Easy. These are the sections you should typically cover:

  • Medical Purpose: What makes this a medical device (as per the MDR definition)? E.g. how does this software diagnose / treat / monitor disease?
  • Users: Characterize the users who will be using your software, e.g. by age, knowledge (education), language.
  • Usage Context: Describe in which setting your software is used. E.g. on a hospital ward? In an emergency room? On workstations? Is it pre-installed on those workstations or is it a web-based application? Is it an app? If so, how and when is this app typically used? Are any specific lighting conditions necessary, like for looking at x-ray images (in dark rooms)?

And then there’s another, rather unlikely scenario. If you’re developing something like a lab test or software which operates not on patients, but on lab samples (tissue samples etc.), then you’re not a medical device, but an In-Vitro Diagnostic Device (IVD). Then, in your intended use, you additionally have to specify from where the analyzed samples originate (e.g. tissue samples from a specific organ) and describe your test principle and method of data analysis (what do you do with those samples?). But again, it’s highly likely that your software is “only” a medical device, not an IVD.

Importance of Your Intended Use

The importance of your intended use can not be overstated. It ultimately decides whether you have a medical device in the first place and what your next steps are based on its classification.

And maybe you’ll notice that it’s not even a medical device at all?

Is It Even a Medical Device?

Most consultants won’t tell you this: The best way to achieve regulatory compliance is to not have a medical device in the first place. Facebook was (and is) not a medical device - that’s why they could get away with “moving fast and breaking things”. That’s hardly possible when developing software as a medical device.

Your main goal should be developing your product, getting customer feedback and gathering revenue. Regulatory compliance and patient safety are very important, but shouldn’t detract you from those goals. If your company fails, you don’t have to bother with regulatory compliance anyway.

To get an idea for the differences between medical vs. non-medical software, check out my answer for the question “Is our software a medical device”?

Intended Use: Write It Now

Writing your intended use is important. As soon as you have a rough idea of what you want to develop, write it down. Then you’ll know what your next regulatory steps should be.

Hopefully I’ll have a template for this in the future :)

On a slighty different note: You want to get your medical software certified under MDR but don't know where to start? No worries! That's why we built the Wizard. It's a self-guided software which helps you create your documentation yourself, for only 149€ / month. No prior knowledge required. You should check it out.

Or, if you're looking for some human help, did you know that we also provide consulting, often guiding startups from start to finish in their medical device compliance?

And there's so much more: If you're looking for the best QMS software ever, look no further. We've built Formwork, and it's free!

Congratulations! You read this far.

Get notified when we post something new.

Sign up for our free newsletter.

Dr. Oliver Eidel

I'm a medical doctor, software engineer and regulatory dude. I've helped 50+ companies with their medical device compliance. I mainly work as a regulatory consultant, but my goal is to make consulting unnecessary by publishing all of our articles and templates for free :)

If you're still lost and have further questions, just send me an email. Read more about me here.

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