Intended Use for Software Medical Devices
The critical first step in the development of healthtech products. A clear intended use prioritises safety and effectiveness and gives clarity on how to position your Software as a Medical Device (SaMD) for success.
When it comes to building medical software, writing a clear and well-thought-out Intended Use Statement will help you determine all the next steps in product development. When itās done properly, itās not just a regulatory document. Itās your productās entire foundation.
The Intended Use Statement is a short document that clearly outlines the deviceās intended purpose under the following headings:
Intended medical indication: what specific medical conditions are you targeting, and what clinical claims are you making?
Intended patient population: what specific patient group will your product benefit?
Intended user groups: who are the key user groups of your SaMD?
Intended part of the body: if your healthtech product has a physical component, does it come into contact with any part of the body?
Use environment: where exactly do you envision your software being used (e.g. on an app, cloud-based etc.)
Operating principle: can you map out a step-by-step process that gives a simple overview of the patient journey (and information flow) when your software is in use? If you are using AI components, can you give a simple diagram of your algorithm architecture or pipeline?
You will also need to think about foreseeable misuse: how could your software be used in ways you donāt intend?
What are the technical risks? Think about cybersecurity, denial of service attacks
What are the clinical risks? Think about the software being used by inappropriate patient groups or for different diseases
Based on the previous steps, we can then work towards determining a risk classification (the next step in the regulatory and clinical journey).
Best Practices
Align with internationally recognised standards
Just so you know that weāre not making this up, the intended purpose is defined in the EU MDR Article 2 (12): āāintended purposeā means the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluationā. It is also a required item in the technical documentation checklist as described in Annex II, 1.1, which states that you must have a āgeneral description of the device including its intended purpose and intended usersā.
Intended use is also defined by the FDA in the Code of Federal Regulations Title 21 and in the UK MDR 2002.
Additionally, the need for an intended use statement is encoded into the International Standards of Usability Engineering - titled IEC/TR 62366. The British version of the standard is BS EN 62366. Both versions clearly outline the best practices for building safe and usable medical devices (including software). If you are looking for a PDF of 62366 free online, you wonāt find one - you need to purchase this standard. But, before you do, why not check with us which other standards you may need, find out how to get bulk discounts or whether your organisation should purchase a subscription through an official supplier to maintain updates.
Intended use is also mandated in Standard 10 of the NICE Evidence Standards Framework, as well as used in several gold-standard academic frameworks regarding the design and reporting of clinical investigations of AI-based medical devices.
The MHRA has released guidance that is applicable to all jurisdictions outlining best practices and common pitfalls in crafting an Intended Use Statement.
Case Study
How Hardian solves the problem
Hardian collaborated with an academic spinout developing machine-learning tools for blood-based cancer diagnostics. By taking the time to craft a well-written Intended Use Statement, we determined the intended populations that the tool should be designed for (e.g. diagnosing symptomatic populations vs. screening asymptomatic populations). This drove the value proposition, helped us design the clinical investigations with appropriate endpoints, and also allowed us to set justifiable performance benchmarks to prove the safety and effectiveness of the new software.
Get in touch
Getting healthtech to market doesnāt have to be difficult.