Advocate General Opinion on Software Medical Devices

On 28 June 2017, Advocate General Sanchez-Bordona (AG) presented his opinion in case C-329/16 Syndicat national de l’industrie des technologies médicales and Philips France following a request for preliminary ruling from the Conseil d’État (France) to the Court of Justice of the European Union (CJEU) concerning the laws governing the classification of software medical devices.

The AG’s opinion is not binding on the CJEU, but it provides useful guidance on the application of the EU medical devices Directive 93/42/EEC (the MDD) to software programs.  Importantly, it confirms the position set out in the Commission’s MEDDEV 2.1/6 guidance that software which merely stores and archives data is not a medical device; the software must perform an action on data (i.e., it must interpret and/or change the data).

EU national courts use the preliminary ruling procedure if they are in doubt about the interpretation or validity of an EU law. In such cases, they may ask the CJEU for advice. The Advocate Generals provide the CJEU with public and impartial opinions to assist the Court in its decision making. The Advocate Generals’ opinions are advisory and non-binding, but they are nonetheless influential.  In the majority of cases the CJEU follows the Advocate General.

Background

Philips France (Philips) manufactures and places on the EU market a software program called Intellispace Critical Care and Anesthesia (ICCA), which is used by physicians to provide information necessary for the proper administration of medicines for the purposes of resuscitation and anaesthesia.  The software highlights possible contraindications, interactions with other medicines and excessive dosing.  Philips classified the ICCA as a medical device under the MDD and the product bears a CE mark confirming that the software complies with the applicable requirements of the MDD.

Under French law, software programs intended to support medical prescriptions are subject to national certification requirements.  The French Government’s position is that the ICCA must comply with this national certification requirement. Further, it does not consider the ICCA to be a medical device within the meaning of Article 1(2)(a) of the MDD because the function of assisting with prescriptions does not fall under any of the defined purposes within the definition of a medical device.

Philips claimed that the national certification requirement should not apply as it amounted to a restriction on import, contrary to EU law, and that the French Government was in breach of Article 4(1) of the MDD, which provides that Member States must not restrict the placing on the market or the putting into service of medical devices bearing the CE mark within their territory.

The French Conseil d’État referred to the CJEU a request for a preliminary ruling on the question of whether software equivalent to the ICCA satisfies the definition of a medical device under the MDD.

AG Opinion

The AG opinion suggests that Philips had correctly classified the ICCA as a medical device.  It highlights that since the ICCA bears a CE mark and is freely marketed in 17 EU Member States, it benefits from a presumption of conformity with the MDD.  It was a matter for the French Government to rebut this presumption, and it had failed to do so.

In reaching his conclusion, the AG highlighted a number of points, including:

  • In order to qualify as a medical device, software must have a function beyond collection and archiving of data (i.e., it must have more than a purely administrative function). Rather, it must modify or interpret the data.  The ICCA software includes an engine that allows healthcare professionals to calculate the prescription of medications and the duration of treatments.  In light of such functions, the AG considers it difficult to maintain that the ICCA does not have a diagnostic or therapeutic purpose within the scope of the definition of a medical device. The ICCA is not a software program that is limited to administrative functions, but rather software that helps determine the proper prescription for the patient.  It is therefore a medical device as it has the aim of “preventing, controlling, treating or alleviating a disease”.
  • The fact that the ICCA does not act by itself in or on the human body does not preclude it from classification as a medical device. Contributing to the principal action of correcting the human body through the taking of medicinal products is sufficient.

The above conclusion endorses the position set out in the Commission MEDDEV 2.1/6 guidance on qualification and classification of standalone software, which states:

“…if the software does not perform an action on data, or performs an action limited to storage, archival, communication, ‘simple search’ or lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) it is not a medical device.”

FDA Device History File vs. EU Medical Devices Directive Technical Files

FDA Device History File vs. EU Medical Devices Directive Technical Files

The FDA has built the DHF around control. This is the defining factor. It has designed GMPs around this. For the FDA, the DHF shows design output as a product of design input. It traces the device’s development history, and how design requirements were met in accordance with 21CFR 820.

FDA DHF shows design history between research and development, something of a grey, overlapping area. Now, if a company decides to commercialize a product that it was earlier researching; or if some other change happens to the product, that is from when design control takes over. Design Controls also demand that the principles of design control are met and that the product is under change control. In other words, it shows a sequence of events over a period of time.

For the FDA, DHFshould be proven by the design history. US FDA Design Control Documents include

  • design planning
  • design input
  • design changes
  • design reviews
  • design verification/validation
  • design transfer –all of these have to be demonstrated in the DHF.

This is in contrast to the parameters set out in the EU’s Medical Device Directive (MDD), whose technical file shows conformance with that device’s “essential requirements”. The EU Council Directive 93/42/EEC (Medical Device Directive), in its Annex VII, EC Declaration of Conformity, has clear guidelines on conformity on the part of the manufacturer. It states that the technical documentation must include:

  • a general description
  • design drawings, diagrams/descriptions
  • methods of manufacture
  • risk analysis results
  • essential requirements/standards met
  • methods of sterilization, where applicable
  • results of design verifications/validations/test results
  • labels/instructions for use.

As a reading of these points suggests, the emphasis is on different aspects of documentation between the two systems.

 

Contact Detail

webinars@globalcompliancepanel.com
http://www.globalcompliancepanel.com

Phone: 800-447-9407
Fax: 302-288-6884

1000 N West Street | Suite 1200 | Wilmington | DE | USA | 19801