Background: The Case of A Customer
A company recently reached out because they received a nonconformity from their competent authority regarding a medical device accessory. Specifically, the company has two mobile apps in the market: one is not declared as a medical device, as it only collects data from end users (I’m simplifying here). The other app is a medical device, as it takes that data and generates some magic with it 🪄
The auditors were suspicious about app 1 (the one that was not declared as a medical device). If app 1 was intended to be used for collecting input for app 2, it should have been declared as an ‘accessory’. It should also be investigated if app 1 wasn’t a medical device as well. Petrificus totalus! 🪄 The company was not amused, as they had planned on carefully separating the two apps, in order to keep their regulatory efforts to a minimum.
What Is A Medical Device Accessory? 👜
Let’s start with the basics. The European MDR defines accessories in Article 2 (2) as follows:
‘Accessory’ means an article which, whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several medical device(s) to enable the medical device(s) to be used in accordance with their intended purpose(s) or to specifically and directly assist the medical functionality in terms of their intended purpose(s).
I’ll pick out and simplify two aspects: an accessory is intended to be used together with a medical device in order to achieve the intended purpose of that device. Just to give you some hardware and software examples I could think of:
- Classic examples from the hardware world: charging cables, adapters, remote controls.
- A smart watch, a diabetes sensor or a blood pressure monitor might come with a smartphone and a smartphone app for visualization.
- A pressure plate for running analysis may come with a video camera for additional data input.
- An algorithm model for image analysis needs to come with a general user interface (GUI) / DICOM viewer software which it is integrated in.
- Any medical device software needs a computer operating system to run on.
Back to the customer case from the beginning, the crucial questions are therefore: what benefits does app 1 provide for app 2? And are those functions relevant for the intended purpose and the medical functions of app 2? This is how they could argue that app 1 is not an accessory for their medical device: app 1 can technically be used, but it isn’t intended to be used, to collect data for app 2; other ways of data input are intended to be used instead.
Unfortunately, the customer had mentioned the app as the main source of data input in their clinical evaluation. What’s more: the app was described in the app store as the “indispensable” companion for app 2. Avada Kedavra! 🪄
(Side note: keep in mind that your intended use is not only evaluated by a file in your technical documentation that is titled ‘Intended Use Statement’. Auditors might as well consult your marketing material or your software specifications to determine the intended use of a device.)
Accessory = Medical Device?
You will have noticed in MDR Art. 2 (2): not every accessory for a medical device is necessarily a medical device itself. Let’s take a quick look at our list of examples: not every OS is classified as medical device, only because medical device software runs on it. Smartphone apps which only visualize sensor data are neither.
Again, it must be determined if the accessory has its own medical intended use or not. Does the smartphone app not only visualize data, but process it to provide medical recommendations?
Then it also meets the definition of a medical device.
Closing the customer case from above: app 1 was certainly an accessory. It could still be debated if it’s also a medical device of its own. Get prepared for another certification process or for merging both apps: reductio! 🪄
Required Documentation For Medical Device Accessories
Let’s finally look at what information needs to be documented for your accessories.
Medical Device Description
First off: do yourself a service and clarify from the beginning if you think your device comes with any accessories. The best place for such a clarification is your Intended Use Statement.
You should also make it clear to your end users what accessories they need to use and how. Such information belongs best in the Instructions for Use / User Manual.
Does your medical device provide interfaces to its accessories? Then you should also describe those in the technical specifications for your product – for example, your list of software requirements or (hardware) design inputs.
Verification & Validation
All product requirements should be tested. For example, let’s say you specified interfaces for data exchange between your medical device software and its accessories. Then your software testing should include tests for those interfaces, to make sure data exchange really works as planned. Usability testing should also include tests with your accessories to validate if they can be used as intended.
Assessment of Medical Device Accessories
Are you the manufacturer of your own accessories? Then you probably don’t want to find yourself in a situation like the company we looked at before. Take a step back from your medical device and only focus on your accessories. Could it be argued that they have their own medical intended use, and that they meet the definition of a medical device? Perhaps write a notes document with all your thoughts, which you can pull out of the drawer just in case auditors might ask some questions in the future.
As another side note, if you reach the conclusion that an accessory might be a medical device of its own, take into account the implementing rules of Annex VIII MDR: para. 3.2 states that accessories and devices “intended to be used in combination with another device” shall be classified separately. Only “software which drives or influences the use of a device” shall fall into the same class as that device (para. 3.3).