When creating a device in Tento+, one of the first things you’ll have to do is enter a device description. And there’s a great reason for this –  one of the first questions any regulatory consultant, investor, or potential customer will ask you is “So what is your device”.  This is especially important if you want to utilise Tento+’s  AI assitant, GeMa, which will use your device description to generate content and guidance tailored to you. This will speed up your compliance journey by identifying elements such as requirements and test plans. 

To help you with this, we’ve put together the top things to keep in mind  

What is your device for, and how does it accomplish that? 

This is the simplest thing to remember (what else is a device description after all!) but when you’re describing your device, it helps to be specific about how your device operates, and why it’s doing that. For example, take a look at this description 

autoMed is a surgical planning tool, with options to track pre-operation checks, suggest possible risks and predict post surgery recovery times. 

This is a pretty good elevator pitch for the device, but there’s quite a bit missing. The reader, or GeMA, will know it’s a piece of software, but is that running in the cloud, or on a computer in the surgeons office? It’s also unclear if this device is used during or before an operation – any device that is used in the middle of surgery to guide the surgical team is going to have a far higher element of risk than a pre-operative planning tool that only makes suggestions in conjunction with an experienced team of professionals. Let’s have another try: 

autoMed is a Preoperative surgical planning software tool. It is provided as a cloud-based service, accessible by subscription, with a secure login system. It utilises a proprietary Artificial Intelligence Expert system to suggest pre-operative check, associated risks with the procedure, and post-surgery recovery times.  

We’ve cleared up exactly how the system works – it’s a piece of software running in the cloud. We’ve also said it’s preoperative, so should only be used before surgery, but we could be clearer about this. We’ve also made some claims about the system- its login system is secure, and it uses an AI system. 

You’ll also notice that the format is quite repetitive “it does this. It does that. It has X system”. Descriptions might not be much fun to read, but that’s not the purpose of this description. We want to explicitly state what the system does, not write a best-selling novel. 

Be clear about what the device isn’t 

The other option to being clear about what your device is, is to describe what it isn’t. This is particularly useful when your device might operate on the edge between two classes of device. If you can make it clear that your device doesn’t fall into the higher rated device class, you can save yourself a huge amount of time and regulatory headache. 

With our previous autoMed device we could have stated that the device is not to be used in an operating theatre or that the device is a planning aid only, and should not be relied upon entirely for surgical operation decisions. This may be covered more thoroughly in your “intended-use” documents, but it’s useful to get this down.  

This can also be useful when the device is or has an associated peripheral. For example, a software application that reads data from a glucose implant is not itself an implant –  an implant is going to a different level of regulatory compliance than a phone app. 

GeMa can be very sensitive to negatives, so make sure that when you’re describing what something isn’t, you’re very clear. Try and use a list of “it is not X. It is Not Y. It is Z” rather than “it is not X.. nor is it Y.. but it is Z” . 

Keywords are… key 

Especially for GeMa, the specific inclusion of keywords can have a huge impact on what it is able to understand. You could state that a heart rate monitor uses “Photoplethysmography”. But by describing specifically that it uses “light emitted and detected in the Infrared and a visible light spectrum” GeMa can pick up that there are two levels of light that will need to both be emitted and detected. This then implies that you will need a set of requirements and tests for the emission and for the detection of light in both of those wavelength. 

How does your device interact with users? 

Obviously your device will have users and/or patients who will have to interact with it in some capacity, or benefit from the device. It is this interaction or benefit that can be a big decider on how your device is classed. The main factor is the physical interaction between device and user. Does the device touch the user’s skin? Is it invasive like an implant? Does it sit entirely separate from the user, but transmits energy into them through the use of radio waves or radiation?  Describe these in your description so it is clear who is using the device, and what the benefit is. 

Additionally, you might want to consider mentioning any user interface your device has. Are there buttons or a screen? Is it a piece of software with a graphical user interface? Is it utilizing a cutting-edge VR headset? All of these are worth mentioning and including in your description as they’ll have an impact on the testing that you’ll need to undertake. 

Break the system down 

Your device is likely comprised of several different parts whether it be digital or mechanical, or materials . A software device will likely have a user interface, data storage, or authentication components. A physical device might have buttons, power supplies, or medicine delivery components. Breaking your device down into these components is a step you’ll have to do as part of your requirement identification, so you can get a head start by breaking it down now, and including them in your description. 

Our autoMed example from earlier can be broken down into at least the following: 

• Authentication system 
• Subscription and billing  
• Front end interface 
• Database 
• AI system 
• Backend system 

You need to strike a balance between high level enough to cover everything, but not too low level that it starts to become bogged down in technical details which will be covered later when identifying your component requirements 

If you get stuck – Tento+ device properties

If you’ve experimented with the Standards section of Tento, you’ll be familiar with the properties selector. Here you’ll find several common properties about medical devices that you can include in your description. These cover much of the advice given here- you’ll find a section on what the device is for, how it works, who the user is, where it’s used etc. This can be a great way to start thinking about what your device is, and who your end users really are. And while you’re there, the next step of the standards section will also allow you to find your applicable standards and regulations, and the earlier you start thinking of these, the less time you’ll have to spend getting your device compliant.  

Put it all together 

So with all of that advice together, we can finally write a full device description: 

autoMed is a Preoperative surgical planning software tool. It is provided as a cloud-based service, accessible by subscription, with a secure login system. It utilises a proprietary Artificial Intelligence Expert system to suggest pre-operative check, associated risks with the procedure, and post-surgery recovery times. It is only used preoperatively. It is not used during surgery. It is Software AS a device. It relies on IT. It is used by medical professionals that have been medically trained. It is not physically invasive. It comprises of the following system components: 

• Authentication system 
• Subscription and billing system 
• Front end interface 
• Database 
• AI system 
• Backend system 

Why not try it out now, and start capturing your device description.