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 :)