Software in Medical Devices, by MD101 Consulting

This page is the Medical Device Directive (MDD) version.
Go to the Medical Device Regulation (MDR) version

Foreword

I used the references below to create this article:

1. Consolidated 93/42 EEC Directive
2. Guidance on medical devices classification: MEDDEV 2.4/1 rev.9
3. Guidelines on the qualification and classification of stand alone software: MEDDEV 2.1/6
4. Manual on borderline and classification in the community regulatory framework for medical devices
5. Recommendation NB-MED/2.2/Rec4 Revision 5, Software and Medical Devices
6. Summary list of titles and references harmonised standards under Directive 93/42/EEC for Medical devices

They're very useful, without them, I wouldn't have been able to write this. I reference them many times in this article.

Qualifying software as medical device

The first question to ask is whether software is a medical device or not.
The answer to this question is all based on its intended use. It shall be for diagnostic or treatment purposes.
The guidelines on the qualification and classification of stand alone software ref. 3 has two decision trees that are an help to qualify software as medical device or in-vitro diagnostic device. The guidance contains also a comprehensive list of examples in annex 1, with types of software which qualify or don't qualify as medical devices.

Not medical devices

To give the most recurring examples of software, which are not medical device, there are:

• Systems managing administrative patient data, like appointment scheduling, billing,
• Prescription Management Systems (but drug dose calculators using patient data like weight or body mass index are medical devices),
• Systems storing patient data, without data processing,
• Radiological Information System (RIS).

Warning: these types of software are not qualified as medical devices in EU. But they may qualify as medical devices in other regions of the world, especially in the US.

Borderline cases

However, even with the help of the guidances, it may be difficult to qualify software as medical device. Borderline cases exist, usually with standalone software, like software that could be used at the same time for general wellness purposes or for treatment purposes. In this case, the qualification of medical device stems from the claims in the intended use.
For example:

• The intended use of a mobile app claims that it records and computes statistics about what the user eats and the quantities of carbs, fat, etc. It is for general wellness purposes, it is not a medical device.
• The intended use of the same mobile app (technically) now claims that it records and computes statistics about what the user eats and the quantities of carbs, fat, for diabetes management. It is for management of diabetes - an aid to the treatment of a disease - it is a medical device.

Medical devices and intended use

The intended use is the responsibility of the manufacturer. Having an intended use in the scope of medical devices or not can also be seen as a top-management decision. Thus same software could be qualified as medical device or not, depending on top-management decision.
However, there are cases when software is medical device given its use or its context of use:

• Software, which is an accessory of a medical device, is a medical device,
• Software, which drives of influence the use of a medical device is a medical device.

And there are case where the manufacturer can't hide behind the intended use they wrote, to escape from the scope of the medical device directive.
Imagine that a manufacturer sells software with an intended use for general wellness. But then promotes its software for diagnostic or treatment purposes or for use combined with a medical device in such a way that it can be seen as an accessory of the device. Then it is by real use a medical device, even if it's not claimed in the intended use.

Qualifying software as a medical device can be a difficult task hence the result has heavy consequences in time and money and in responsibility.

The guidances quoted above may not have enough information for peculiar cases. Thus it's worth contacting a notified body or a competent authority to assess the status of software.

Determining the class of software

Each medical device shall be classified in one class: class I, class IIa, class IIb or class III. It depends on the level of risk generated by the use of the device. Looking at the EEC directive ref.1 , it is very simple to classify software:

• Standalone software: Annex IX, §I.1.4 states that all standalone software are classified as active devices. Therefore, rules 9 to 12 of annex IX §III.3 apply to your software.
• Software, which drives or influences a medical device: Annex IX, §II.2.3 states that such software falls into the same class as the device.

The terms “drives or influence” may be interpreted. Here are some examples:

• Software with functions modifying the state of the device actually drives it,
• Software, which only displays data collected from the device, may not be at first sight seen as “driving” the device. But if the user uses data provided by the software to modify the state of the device, then the software “influences” the device.
• Software, which only stores data for archiving purpose doesn’t influence the medical device and may be classified alone, with rules 9 to 12 of annex IX §III.3 .

Rule 9 to 12 of EC directive

Let’s focus now on these rules 9 to 12. A guidance ref. 2 was written by the EC to apply all rules the right way. It is very well constructed, with schema giving decision trees to follow and explanation text about each rule.

Another recommendation document ref. 5 written by Notified Bodies gives good examples in §3.1 about how to classify software.

The table below gives the interpretations of each rule for software, based on ref. 2 and ref. 3.

Rule #	Text	Software
9	All active therapeutic devices intended to administer or exchange energy	Devices classified by this rule are mostly electrical equipment used in surgery such as lasers and surgical generators. In addition there are devices for specialized treatment such as radiation treatment. Another category consists of stimulation devices, although not all of them can be considered as delivering dangerous levels of energy considering the tissue involved. Standalone software intended to control or monitor such devices, or directly influence their performance, are also classified by this rule.
10	Active device for diagnosis	This primarily covers a whole range of widely used equipment in various fields, e.g. ultrasound diagnosis, capture of physiological signals and therapeutic and diagnostic radiology. Vital physiological processes and parameters include, for example respiration, heart rate, cerebral functions, blood gases, blood pressure and body temperature. Standalone software intended to control or monitor such devices, or directly influence their performance, are also classified by this rule. See also paragraph about PACS below.
11	Active devices to administer or remove medicine	This rule is intended to primarily cover drug delivery systems and anesthesia equipment. Standalone software intended to control or monitor such devices, or directly influence their performance, are also classified by this rule.
12	All other active devices	This is a fallback rule to cover all active devices not covered by the previous rules. Class I stand alone software can also come with a measuring function.

Some examples:
Rule 9:

• Software embarked in a muscle stimulator, an incubator, a laser …
• Software connected through network (wired or wireless) to a therapeutic device. Eg: remotely monitored physiotherapy equipments,
• Radiotherapy planning system used to calculate the dose of ionizing radiation to be administered to the patient, insulin dosage planning stand alone software.

Rule 10:

• Software embarked in any scanner (ultrasound, X-Ray, MRI), an electronic thermometer …
• Software connected through network (wired or wireless) to a diagnostic device. Eg: Picture Archiving and Communication System (PACS),
• Standalone software processing patient data to allow direct diagnostic. Eg: a mobile app used to compute diagnostic data.

Remark: rule 10 is often challenging for standalone software delivering data for diagnostic or treatment purposes.
Rule 11:

• Software embarked in infusion pumps, ventilators, nebulizers, suction pumps, dialysis equipment,
• Software connected through network (wired or wireless) to a device delivering or administering medicine,

Rule 12: Anything else

• Software embarked in an hospital bed
• Software used to monitor or control a class I device
• Standalone software processing patient data as an aid to diagnostic. Eg: a mobile app used to compute a score.
• All other standalone software. Use this rule with economy, when every other rule has been rejected after extensive interpretation. It may be attractive to have software on smartphones or tablets fall in rule 12. This is often not the case.

Remark: It is often difficult to make a black and white issue between rules 10 and 12, for standalone software delivering data for diagnostic purposes.

Special considerations for Picture Archiving and Communication Systems:

Classification rules cannot genuinely cover every case. The working group on “borderline and classification” was created to give recommendations on such cases. It edited a manual (ref. 4) on borderline classification of medical devices, for which there is a difficulty to apply rules of the EC directive. A chapter deals with Picture Archiving and Communication System (PACS). PACS shall be class IIb, IIa or class I, depending on their purpose. Here are some examples. If the PACS:

• Stores images and doesn’t modifies them, then it is class I,
• Is used to monitor and control the scanner, then it has the class of the device,
• Is a post-processing tool used to interpret raw images, then it is class IIa.

Choosing the CE procedure to apply

The EC directive defines several procedures to obtain CE mark on a device. They are described in annexes II of VIII of the directive. The principle of these procedures is to produce a technical file containing data about the medical devices. Each procedure applies to a given step in the lifecycle of a device (design, production, quality tests …) and requires different data. Given the classification of your software, you can choose the CE procedure to apply.

Annex #	Procedure	Explanation
II	EC DECLARATION OF CONFORMITY (Full quality assurance system)	The most “powerful” and the longest procedure. All the relevant processes of the company are certified compliant with ISO 13485 standard. EC is issued by a notified body
III	EC TYPE-EXAMINATION	Verification of technical data about the design of a device. EC Type is issued by a notified body
IV	EC VERIFICATION	Verification of each device or batches of devices produced by the manufacturer. EC is issued by a notified body
V	EC DECLARATION OF CONFORMITY (Production quality assurance)	Verification of the quality system of the manufacturer for production, final inspection and testing. EC is issued by a notified body.
VI	EC DECLARATION OF CONFORMITY (Product quality assurance)	Verification of the quality system of the manufacturer for final inspection and testing. EC is issued by a notified body.
VII	EC DECLARATION OF CONFORMITY	Verification of technical data about the design of a device, specific for class IIa or class I. EC is issued by the manufacturer.
VIII	DEVICES FOR SPECIAL PURPOSES	Verification of technical data about the design of a device, specific for custom-made devices or for devices intended for clinical investigations.

Valid combinations of procedures

These procedures shall be combined to obtain the precious CE mark. Given the classification of the device, here are the possible combinations:

Class#	Procedure	Combined with
III	Annex II, Full quality management System	None
	Annex III, Final design review, with:	Annex IV, Unit or sample Review, Or Annex V, Production quality procedures
IIb	Annex II (w/o 4), Full quality management System, excepted design procedure	None
	Annex III, Final design review, with:	Annex IV, Unit or sample Review, Or Annex V, Production quality procedures, Or Annex VI, Final test quality procedures
IIa	Annex II (w/o 4), Full quality management System, excepted design procedure	None
	Annex VII, Final design review, with:	Annex IV, Unit or sample Review, Or Annex V, Production quality procedures, Or Annex VI, Final test quality procedures
I	Annex VII, Final design review (less comprehensive than other classes)	None

Annex VIII doesn’t appear in the table. Hence it is a kind of “partial” procedure for devices, mainly before clinical investigations. It has no impact on the procedure to choose for final EC mark in the table above.

Procedures applicable to software

Not all of these procedures are applicable to software design. In §3.2 of document (ref. 5), the notified bodies give recommendations about applying procedures to software.
Software is very specific: initial design, bug fixes and enhancements are the main tasks to release software to a customer. The production step is very reduced, compared to other industries.
Based on this consideration: Procedures linked to design are required and/or amplified:

• Annex II, Full quality management system has design control procedures (no change),
• Annex III, EC Type examination is amplified with design control procedures highly recommended
• Annex VII, design review examination is amplified with design control procedures highly recommended

And some procedures are excluded:

• Annex IV, Unit or sample Review is not applicable
• Annex VI, Final product Review is not applicable

Based on these recommendations, the table above can be modified to select procedures applicable to software.

Class#	Procedure	Combined with	Applicable to software?
III	Annex II	None	Yes
	Annex III	Annex IV Annex V	No Yes, with design procedure
IIb	Annex II (w/o 4)	None	Yes
	Annex III	Annex IV Annex V Annex VI	No Yes, with design procedure No
IIa	Annex II	None	Yes
	Annex VII	Annex IV Annex V Annex VI	No Yes, with design procedure No
I	Annex VII	None	Yes, with design procedure

Procedures with design control and application of standards

I already talked a lot in other articles about standards relevant for software development: IEC 62304, IEC 62366 and IEC60601-1.
The EC has its own view of standards. It has selected a set of standards, which are recommended to prove conformity of products to EC requirements: the Harmonized Standards. Manufacturer shall implement them on a voluntary basis. The list of Harmonized Standards is published in the Official Journal of European Commission and can be found at ref. 6.
For software, we find in this list IEC 62304, IEC 62366 and section 14 of IEC 60601-1. All three standards require manufacturers to have a design control procedure for software. Based on this information, and being voluntary (!), we can simplify the table this way, keeping in mind that design control procedure is mandatory:

Class#	Procedure	Combined with
III	Annex II	None
	Annex III	Annex V
IIb	Annex II (w/o 4)	None
	Annex III	Annex V
IIa	Annex II	None
	Annex VII	Annex V
I	Annex VII	None

Only the level of scrutiny of design will change, given the class of software. IEC 62304 is pretty clear about that. Only a part of the standard is mandatory for software with a low level of risk, whereas the full standard is mandatory for software with a high level of risks.

The main difference between Annex II and other annexes is linked to the way manufacturer top-management organizes the company. Usually:

• Annex II is applied to the whole company, for every product in the scope of the Quality Management System. In most of cases the company is ISO 13485 certified and has an activity in medical devices only,
• Annex III, VII and V can be applied to a subset of products delivered by the company. It may be ISO 9000 certified for all its products. A subset of products is composed of medical devices, for which the company chose to apply the relevant annexes of the EC directive,
• Annex III, VII and V can also be chosen by a company with a single product or a single family of products.

Of course, every case may be found in the nature, like a company manufacturing only medical devices and applying other annexes than annex II.

A word on procedures after design

Design control procedure is of high importance. But other tasks shall not be neglected.

Annex V is all about production. For software, production is made of installation, configuration, testing:

• Installation: flashing the software on a micro controller, installation on a server, on clients, etc…
• Configuration: defining the good configuration files for the customer, using administrative tools,
• Testing: test of the final configuration defined for the customer, test of software integrated in a product item …

These steps shall be monitored very carefully. Some may be done by the customer and shall be double-checked. A divergence from expected behavior is very common with software. It’s mandatory to have procedures to handle these tasks to have software work properly.

Bug fixes and enhancements: A full quality system according to annex II shall have procedures to manage bugs and enhancements. So do procedures according annex III, V and VII. Collecting bug and enhancements is a mandatory task, based on the interpretation of the EC directive in annex V, section 3.1 or annex VII section 4.

The IEC 62304 standard gives a comprehensive list of processes to implement in order to have software developed and maintained according the state of the art. Applying this standard is the best thing to do prior to any software medical device CE conformity project.

Declaring CE conformity of the device

There is no specific issue about software, when declaring CE conformity of a device. Many things may happen between software release for use and CE conformity, especially clinical studies. During these studies, software may be modified and some bugs should certainly be fixed.

When clinical studies are complete and successful, a final validation review is planned. The device manufacturer’s team assesses the technical file of the device: conception, verification, risk assessment, results of clinical tests and benefit for the patient.

The content of the software design documentation may be screened during this meeting. The specification, architecture and tests documents shall have been verified during a previous meeting, before clinical tests. The validation meeting shall focus on risk management, bugs fixes, version control, mandatory content in the software user manual, and clinical benefit of the device.

When everything is ok (i.e. the manufacturer estimates that device is ready for placing it on the market), usually after the final validation review, the CE conformity is ready to be issued.

Depending on the class of the device, a notified body issues a certificate of conformity. then the manufacturer declares the conformity:

• Step 1 for Class I (sterile or with a measuring function), Class IIa, Class IIb and Class III devices: the notify body delivers a certificate of conformity,
• Step 2: the manufacturer declares the conformity.

Of course, the notified body doesn’t declare CE conformity in a snap of a finger. It reviews the whole documentation produced about the device. The process usually takes a couple of months. But if the documentation follows clearly a software design process compliant with the standards quoted above, then the job of the notified body is made easier. It should prevent them from asking troubleshooting questions about software and/or issuing non-conformities.

Conclusion

Congratulations if you read this till the end!
Placing software medical device on the European market is a long journey with lots of obstacles and long detours.
I hope you know a bit more about it, at the end of this page.


Updated on August 2016
Reason: periodic review of articles
Fixed dead links in Foreword section.