Software in Medical Devices, by MD101 Consulting

Warning: this article was written in 2011 and is obsolete!

Go to the version updated with the MDR.

Foreword

I used the references below to create this article:

1. Consolidated 93/42 EEC Directive: In html In PDF
2. Guidance on medical devices classification: MEDDEV 2.4/1 rev.9
3. Manual on borderline and classification in the community regulatory framework for medical devices
4. Recommendation NB-MED/2.2/Rec4 Revision 5, Software and Medical Devices
5. 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.

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. 4 written by Notified Bodies gives good examples in §3.1 about how to classify software.

The table below gives my interpretation of each rule for software, based on what I read in ref. 2 and ref. 4.

Rule#	Text	Software
9	All active therapeutic devices intended to administer or exchange energy	This rule and its sub rules apply to software connected or integrated into such device or software, which influences or drives the device. Standalone software doesn’t administer or exchange energy and doesn’t fall into that category, unless it influences or drives such device.
10	Active device for diagnosis	This rule and its sub rules may apply to software connected or integrated into such device or software, which influences or drives the device. Standalone software may fall into that category (see paragraph about PACS below).
11	Active devices to administer or remove medicine	This rule and its sub rules apply to software connected or integrated into such device or software, which influences or drives the device. Standalone software doesn’t administer or remove medicine and doesn’t fall into that category, unless it influences or drives such device.
12	All other active devices	This rule is a “fall through” rule, when other rules do not apply, even interpreted extensively.

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,
• Software allowing the user to drive or influence such device by any mean or any media

Rule 10:

• Software embarked in any scanner (ultrasound, X-Ray, MRI), an electronic thermometer …
• Software connected through network (wired or wireless) to a diagnosis device. Eg: Picture Archiving and Communication System (PACS),
• Software allowing the user to drive or influence such device by any mean or any media

Rule 11:

• Software embarked in a dialysis equipment
• Software connected through network (wired or wireless) to a device delivering or administering medicine
• Software allowing the user to drive or influence such device by any mean or any media

Rule 12: Anything else

• Software embarked in an hospital bed
• Software used to monitor or control a class I device
• 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.

Special considerations for Picture Archiving and Communication Systems:

Classification rules cannot cover every case. The working group on “borderline and classification” was created to give recommendations on such cases. It edited a manual (ref. 3) on 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.

Relying on my own experience, I find their recommendations very useful to classify PACS.

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
Class 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
Class 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
Class 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
Class 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 their document (ref. 4), 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 shall have design control procedures,
• 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, I modified the table to select procedures applicable to software.

Class	Procedure	Combined with	Applicable to software?
Class III	Annex II	None	YES, with design procedure
	Annex III	Annex IV Annex V	NO YES, with design procedure
Class IIb	Annex II (w/o 4)	None	YES, with design procedure
	Annex III	Annex IV Annex V Annex VI	NO YES, with design procedure NO
Class IIa	Annex II (w/o 4)	None	YES, with design procedure
	Annex VII	Annex IV Annex V Annex VI	NO YES, with design procedure NO
Class 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. 5.

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 in 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
Class III software	Annex II	None
	Annex III	Annex V
Class IIb software	Annex II	None
	Annex III	Annex V
Class IIa software	Annex II	None
	Annex VII	Annex V
Class I software	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 organization of the manufacturer:

• Annex II is applied to the whole company, for every product (excepted derogations with justification). 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 small subset of products is composed medical devices, for which the company applies the relevant annexes of the EC directive.

Of course, every case may be found in the nature, like a company manufacturing only medical devices and applying other annexes than annex II. But I personally haven’t found the case yet.

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 nominal 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, §3.1 or VII §4.

The IEC 62304 standard gives a comprehensive list of procedures to implement in order to have software developed and maintained according the state of the art. I warmly recommend you to implement this standard. This is the best thing to do prior to any EC conformity procedure.

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 tests. During these tests, software may be modified and some bugs should certainly be fixed.

When clinical tests are complete and successful, a final validation review is scheduled. The device manufacturer’s team assesses the technical file of the device: conception, verification, risk assessment, and clinical tests. The content of the software design documentation is 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 and mandatory content in the software user manual.

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 or the manufacturer declares the conformity:

• Class I (sterile or with a measuring function), Class IIa, Class IIb and Class III devices: the notify body declares the conformity,
• All other Class I devices : 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 him from asking troubleshooting questions about software and/or issuing non-conformities.

Write what you do. Do what you write. Increase you chances to be CE marked!