medicaldeviceslegal

Many companies developing medical software, especially the smaller app developers, have difficulties applying the EN62304 standard. For that reason a number of experts under the auspices of Team NB started work on an FAQ document shedding more light on how this standard works, as to enable companies to conduct more productive discussions with their notified body and assess their own software better. The document has been reviewed by a voluntary team consisting of a few notified bodies as well as the ISO group that is responsible for the ISO 62304 standard. The document’s aim is that it is used by all notified bodues as a reference document to ensure more consistent application of the standard. It answers 73 unique questions, divided into 7 categories. See for more background on this Eisner Safety Co.’s summary and the FAQ document here. The document is a living document and its authors invite comments on the email address in the document.

The document produced is I think a great help in understanding the EN62304 standard, because it is based on actual realistic questions that the market could send in as response to the consultation for the FAQ document. If you want a nice rundown of what is in the document, Leo Eisner is your man with his post here. Because that rundown is very complete, I’d like to focus on some points that I found particularly interesting myself. And I’d like to complement the authors on the playful inclusion of pictures in the document – e.g. a picture of soup in the section discussing SOUP – pretty unique for technical guidance documents.

SaaS

Software as a Service (SaaS) is something we’ll see more and more with apps being run partly on a handheld and partly on a remote server, or maybe completely from a remote server. In this respect the FAQ document provides that “[The] [medical devices directives, “MDD”] does not cover the overall service provided. MDD only covers design, manufacturing and regulatory post market activities of the medical devices. Nevertheless, it is the responsibility of the MD legal manufacturer of the software intended to be used as part of a wider service to manage the specific risks related to the use of the software itself under the service environment.” This is in line with the modularisation thinking set out in the standalone software MEDDEV 2.1/6: if you have a bigger suite of applications or elements, identify the medical functionality (which must be CE marked) and manage the dependencies with the rest of the software it works with.

Definition of software under MEDDEV 2.1/6

Even Excel macros can be ‘software’ in the meaning of MEDDEV 2.1/6 :

“Excel macros sold with an intended medical use fall under the MDD and must be created according to EN 62304.”

That is only logical if they go beyond “an action on data, or performs an action limited to storage, archival, communication, ‘simple search’ or lossless compression” in the meaning of step 3 of the flowchart on p. 9 of that MEDDEV. It just underlines that ‘software’ in the meaning of the MEDDEV can also be what many people refer to as a document.

Network devices

The FAQ document says:

“An internet based, server based or cloud based software that meets the definition of the MDD is a medical device. Any general purpose operating system or network software is a SOUP. Any general purpose commercially available hardware devices such as network or storage capability that does not meet the definition of an accessory according MDD are only non-medical components. Nevertheless, risk associated with such HW architecture has to be managed in the medical device risk management file.”

That is fine and good for the moment, but don’t forget that the new Medical Devices Regulation and IVD Regulation proposals include a definition of accessory that is much wider than currently set out in the MDD, because it also will include devices that “assist” (and not only enable, as currently drafted), so it is not excluded that the scope of the definition of accessory will come to include more network devices.

Is compliance with EN62304 sufficient for placing on the market?

The FAQ document answers this common misunderstanding with a clear

“No. Compliance with EN 62304 does not provide a presumption of conformity with all applicable essential requirements of Annex I of the MEDICAL DEVICE Directive. EN 63204 for instance does not cover usability aspects, clinical evaluation, and the final validation of the software product or the need for accompanying documents such as user instructions. Therefore, other standards and procedures need to be considered to show complete fulfillment of all applicable essential requirements. (If harmonized standards are not applied, the manufacturer has to justify and explicitly state the selected equivalent alternative methods)”

SOUP selection, assessment & qualification

I really like flowcharts because they’re helpful to analyse problems and fit them in procedures, so I was happy with the nice flowchart for SOUP selection, assessment & qualification in Annex 2 of the document, because what company still writes all of its code itself these days? If you don’t, like basically everyone else, you have to  have a process for dealing with integration of external software in yours. Annex 2 provides a nice example of a process for the selection, assessment and qualification of SOUP suppliers. It shows the degree of control you have to implement over your software supplier. What is doesn’t say is how to implement that in your agreement with your supplier. Fortunately I have had plenty to say about that, like for example here, here and here. With the software supplier often being critical, you even have to plan and contract for surprise audits of your software supplier by your notified body.

Direct diagnosis

The document raises the issue of direct diagnosis as a classification criterion and incorporates the COCIR’s Position paper on direct diagnosis from 2011 for good measure in annex 4. That paper concludes that any software that provides for direct diagnosis, as in “without the necessity to acquire or take into account additional information” by the user, regardless of whether the diagnose is made by the device or the user him- or herself. That means that a lot of software would fall within the definition of direct diagnosis and be bumped up to risk class IIa (and as a result be subject to notified body scrutiny), were it not for the fact that direct diagnosing software also has to diagnose “vital physiological processes” in the meaning of rule 10 of Annex IX MDD to fall in class IIa, which, according to the MEDDEV on classification,  “include, for example respiration, heart rate, cerebral functions, blood gases, blood pressure and body temperature”. “Vital physiological processes” is a term that itself is not always as clear as it can be. It does however show that direct diagnosis can also concern at least three other categories without falling in class IIa:

1. non-vital physiological processes (I could imagine ovulation cycle, nail growth, etc.);
2. physiological states (You fell on your head? You have a headache? You saw a flash of light? Congratulations: you have a concussion.); and
3. other diagnoses that relate to the human organism (for example, everything non-physiological, so mental disorder diagnosis)

 All in all

A must read if you already develop medical software (or have it developed for you), or are planning to. A very useful document and big kudos to the team behind it:

• Jomuna Choudhuri, VDE Test and Certification Institute
• Koen Cobbaert, Quality, Regulatory and Risk Management, Agfa Healthcare
• Georg Heidenreich, Quality & Technology, Siemens AG – Healthcare Sector
• Frans Jacobs, Regulatory Affairs manager X-ray products, Philips Healthcare
• Gerd Neumann, Software Standardization Expert, Siemens AG – Healthcare Sector
• Michael Bothe, Head of Medical devices/Processes/Systems, VDE Test & Certification Institute
• Peter Linders, Chair Technical & Regulatory Affairs Committee, COCIR