FAQ on Medi­cal Device Soft­ware Qua­li­fi­ca­ti­on and Classification

MDCG 2019-11 Rev.1 pro­vi­des gui­dance on the qua­li­fi­ca­ti­on and clas­si­fi­ca­ti­on of soft­ware under the EU Medi­cal Devices Regu­la­ti­on (MDR 2017/745) and the EU In Vitro Dia­gno­stic Medi­cal Devices Regu­la­ti­on (IVDR 2017/746). It is pri­ma­ri­ly inten­ded as gui­dance for manu­fac­tu­r­ers to ensu­re that their soft­ware pro­ducts com­ply with EU regulations.

Our FAQ explains the most important aspects of the MDCG Gui­dance Docu­ment 2019-11 Rev.1 of the Medi­cal Device Coor­di­na­ti­on Group.

What is medi­cal device soft­ware (MDSW) and how is it qualified?

MDSW is soft­ware with a medi­cal pur­po­se in accordance with MDR or IVDR. It can be used inde­pendent­ly or in con­junc­tion with devices. The decisi­ve fac­tor for qua­li­fi­ca­ti­on is the cle­ar­ly defi­ned inten­ded pur­po­se by the manu­fac­tu­rer. This also includes soft­ware that pro­ces­ses medi­cal data or is an acces­so­ry for a medi­cal device. The type of use (cloud, mobi­le, etc.) or the risk of poten­ti­al dama­ge is irrele­vant. Examp­les: Apps for dia­gno­sis, the­ra­py plan­ning or monitoring.

What is the dif­fe­rence bet­ween MDSW and soft­ware that dri­ves a medi­cal device?

MDSW has its own medi­cal pur­po­se. Con­trol soft­ware only affects the func­tion of a device but does not ful­fil any medi­cal pur­po­se of its own. Both types are sub­ject to the MDR but dif­fer in terms of clas­si­fi­ca­ti­on and assessment.

How is MDSW classified?

Clas­si­fi­ca­ti­on is based on MDR/IVDR – in par­ti­cu­lar MDR Rule 11 (Annex VIII Sec­tion 6.4) – accor­ding to risk and influence on medi­cal decisions:

  • Class I: low risks.
  • Class IIa–III: depen­ding on the impact on health and tre­at­ment decisions.

MDSW, which dri­ves the devices, must not be clas­si­fied lower than the asso­cia­ted device (Annex VIII, Sec­tion 3.3).

What role does the inten­ded pur­po­se play?

The inten­ded pur­po­se is the cen­tral cri­ter­ion for qua­li­fi­ca­ti­on and clas­si­fi­ca­ti­on. It must be medi­cal­ly jus­ti­fied, cle­ar­ly for­mu­la­ted and sup­port­ed by tech­ni­cal docu­men­ta­ti­on. Unclear or insuf­fi­ci­ent infor­ma­ti­on can lead to incor­rect clas­si­fi­ca­ti­on and regu­la­to­ry problems.

How do modu­lar struc­tures influence the assessment?

Each modu­le is asses­sed sepa­ra­te­ly. Only modu­les with a medi­cal pur­po­se are sub­ject to MDR/IVDR. In the case of func­tion­al depen­den­ci­es (e.g. medi­cal modu­le with non-medical user inter­face), the who­le must be con­side­red. Chan­ges to modu­les may requi­re a new qua­li­fi­ca­ti­on or classification.

How is the IMDRF risk clas­si­fi­ca­ti­on applied?

The intro­duc­tion of Rule 11 MDR is essen­ti­al­ly based on the IMDRF gui­de­lines. The cli­ni­cal bene­fit of the soft­ware and the pati­en­t’s sta­te of health are taken into account. Equivalents:

  • IMDRF IV → MDR Class III
  • IMDRF III → MDR Class IIb
  • IMDRF I/II → MDR Class IIa

It is hel­pful, but only the MDR clas­si­fi­ca­ti­on is legal­ly binding.

How can MDSW be pla­ced on the market?

MDSW can:

  • be mar­ke­ted inde­pendent­ly as a medi­cal device/in vitro dia­gno­stic device (e.g. dia­gno­stic apps) or
  • as part of a device if it is inte­gra­ted into a hard­ware pro­duct (e.g. con­trol sys­tem in a blood ana­ly­sis device).

The con­nec­tion to the hard­ware does not chan­ge the qua­li­fi­ca­ti­on – the inten­ded pur­po­se remains decisive.

Which soft­ware does not count as MDSW?

Soft­ware wit­hout a medi­cal pur­po­se, such as bil­ling tools, well­ness apps, simp­le data sto­rage or com­mu­ni­ca­ti­on tools, do not count as MDSW. Sys­tems that only dis­play, store or for­ward data (e.g. HIS, PACS, LIS) are also not included, unless they inter­pret or influence medi­cal decisions.

What should you do now?

  1. Cla­ri­fy the medi­cal pur­po­se of your soft­ware at an ear­ly stage and check whe­ther it is clas­si­fied as MDSW.
  2. Deter­mi­ne the cor­rect risk class precisely.
  3. Take stan­dards such as IEC 62304, ISO 14971, IEC 82304–1, etc. into account from the out­set – not just as an afterthought.
  4. Deve­lop a docu­men­ted qua­li­ty manage­ment system.
  5. Ensu­re that soft­ware life­cy­cle pro­ces­ses are traceable and auditable.

Now is the right time to clo­se regu­la­to­ry gaps – only tho­se who ans­wer regu­la­to­ry ques­ti­ons ear­ly on can bring MDSW pro­ducts to mar­ket safe­ly, eco­no­mic­al­ly and in com­pli­ance with the law. We are hap­py to sup­port you. Get in touch with us.

back

Stay up-to-date

We use your email address exclusively for sending our newsletter. You have the right to revoke your consent at any time with effect for the future. For further information, please refer to our privacy policy.