Spring naar inhoud

Classificatie Software als Medisch Hulpmiddel

23 december 2019

Als fabrikanten software als medisch hulpmiddel willen ontwikkelen en op de markt brengen, moeten ze voldoen aan de wettelijke vereisten van de Europese verordening voor medische hulpmiddelen (EU) 2017/745 (MDR). Naast toestellen, instrumenten, apparaten, enz. verwijst de MDR naar software. Maar de MDR geeft geen definitie van wat wordt bedoeld met medische software. De richtlijn MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR geeft deze wel. Software kan worden beschouwd als medische hulpmiddelen software (MDSW) als een set instructies die invoergegevens verwerkt en uitvoergegevens maakt (dat wil zeggen, voldoet aan de definitie van software in de MDCG 2019-11) en voldoet aan de definitie van medisch hulpmiddel van de MDR. De MDR definieert medische hulpmiddelen op basis van het beoogde doel (artikel 2, MDR). Dit zijn:

  • diagnose, preventie, monitoring, voorspelling, prognose, behandeling of verlichting van ziekten,
  • het diagnosticeren, bewaken, behandelen, verlichten of compenseren van letsel of handicap,
  • onderzoek, vervanging of aanpassing van de anatomie of een fysiologisch of pathologisch proces of aandoening, en
  • verkrijgen van informatie door in vitro onderzoek van monsters genomen uit het menselijk lichaam, inclusief orgaandonatie, bloed en weefseldonaties.

Daarnaast zijn producten voor anticonceptie en voor reiniging, desinfectie of sterilisatie medische hulpmiddelen in de zin van de wet. Medische hulpmiddelen moeten ook voor mensen zijn bedoeld. Het actieve principe is ook belangrijk. Medische hulpmiddelen werken in of op het menselijk lichaam, maar niet farmacologisch, metabolisch of immunologisch.

Over het algemeen maakt de MDR wel duidelijk dat software meer moet kunnen dan alleen zoeken, opslaan, archiveren of verzenden om als medische hulpmiddel software te worden beschouwd. In het bijzonder interpreteert het gegevens en helpt het bij het stellen van diagnoses en het initiëren van therapieën. Dit betekent bijvoorbeeld dat systemen voor patiëntgegevensbeheer, ziekenhuisinformatiesystemen of medische leer- en onderwijsprogramma’s geen medische hulpmiddelen zijn. Ook EU-Commissie richtlijn MEDDEV 2.1/6 Guidelines on the Qualification and Classification of Stand Alone Software Used in Healthcare Within the Regulatory Framework of Medical Devices biedt in dit verband nadere aanwijzingen. Hierin wordt software die acties uitvoert die beperkt zijn tot “opslag, archivering, communicatie, eenvoudig zoeken of compressie zonder verlies” niet gekwalificeerd als medisch hulpmiddel. Dat klinkt eenvoudig. Maar wat als deze functies nog steeds het beoogde doel van een medisch hulpmiddel ondersteunen? Software die bedoeld is om vitale fysiologische parameters van een sensor bij de patiënt via een draadloos netwerk over te dragen naar een bewakingssysteem kan bijvoorbeeld in deze categorie vallen.

International Medical Device Regulators Forum (IMDRF) richtlijn IMDRF/SaMD WG/N12 “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations” geeft een algemeen aanvaarde definitie van stand-alone software. Hierin is de indeling gebaseerd op het vermogen om zelfstandig een medisch doel te vervullen zonder deel uit te maken van (embedded te zijn op) de hardware van een medisch hulpmiddel. Dit zou betekenen dat software op niet toegewijde hardware (PC, laptop, mobieltje) moet worden uitgevoerd om stand-alone te worden. Ook MEDDEV 2.1/6 hanteert het onderscheid tussen embedded en stand-alone software. Dit is in strijd met de MDR vereiste dat software moet worden geclassificeerd volgens het beoogde doel. Daarom kan software beter worden beoordeeld op of het zelfstandig als de software zijn eigen beoogde doel kan vervullen, ook al wordt deze geïnstalleerd op een medisch hulpmiddel geleverd. Daarom introduceert de richtlijn MDCG 2019-11 de term “Medical Device Software” (MDSW). MDSW wordt gedefinieerd als “alle software die bedoeld is om te worden gebruikt, alleen of in combinatie, voor een in de definitie van een” medisch hulpmiddel “in de MDR of IVDR gespecificeerd medisch doel, ongeacht of de software onafhankelijk is of het gebruik van een medisch hulpmiddel aanstuurt of beïnvloedt. ”

MDSW bestaat dus uit twee subtypen:

  • Onafhankelijke MDSW die informatie verstrekt voor diagnostische of therapeutische doeleinden en
  • MDSW die het gebruik van een medisch hulpmiddel aansturen of beïnvloeden.

Software die een hulpmiddel aanstuurt of het gebruik van een hulpmiddel beïnvloedt, valt in dezelfde klasse als het hulpmiddel (MDR Bijlage VIII uitvoeringbepaling 3.3). Volgens MDR artikel 2 (2) betekent een accessoire voor een medisch hulpmiddel een artikel dat, hoewel het zelf geen medisch hulpmiddel is, door de fabrikant bestemd is om samen met een of meer specifieke medische hulpmiddelen te worden gebruikt om het met name mogelijk te maken dat het medisch hulpmiddel wordt of de medische hulpmiddelen worden gebruikt overeenkomstig de beoogde doeleinden ervan of om specifiek en rechtstreeks bij te dragen tot de medische functionaliteit van de medische hulpmiddelen overeenkomstig de beoogde doeleinden ervan. Software die het gebruik van een (hardware) medisch hulpmiddel aanstuurt of beïnvloedt, kan als accessoire voor een (hardware) medisch hulpmiddel worden gekwalificeerd. Deze software heeft op zichzelf geen medisch doel of creëert zelf geen informatie voor één of meer van de in de definitie beschreven medische doeleinden. Deze software kan het apparaat aansturen of beïnvloeden via een interface of via de operator van het hulpmiddel. Ook kan het output leveren gerelateerd aan de (hardware) werking van het hulpmiddel. Heeft de software een medisch bedoeld doel dan kan het geen accessoire zijn. De MDCG-richtlijn spreekt een duidelijke taal: MDSW met een medisch doel kan geen accessoire zijn.

Volgens IMDRF/SaMD/WG/N12 is software met een medisch doel:

  • Software die andere functies uitvoert dan opslag, communicatie en “eenvoudig zoeken”,
  • Software die nieuwe informatie levert, op basis van gegevens van individuele patiënten, en
  • Software die volgens de fabrikant nieuwe informatie levert bedoeld voor diagnose of behandeling.

Opmerkelijk is dat volgens de MDCG 2019-11 zelfs software die wordt geïntegreerd en uitsluitend wordt geleverd embedded op de hardware van het medisch hulpmiddel, onafhankelijk kan zijn en op zichzelf een medisch hulpmiddel kan zijn. Onafhankelijke MDSW moet worden beoordeeld in overeenstemming met zijn eigen risicoclassificatie. In MDR artikel 2 (4) wordt in een bijzin aangegeven dat software als een actief hulpmiddel wordt beschouwd. Aldus zijn de classificatieregels 9, 10, 11 en 22 van MDR bijlage VIII in principe van toepassing. Aangezien MDSW geen stoffen fysiek kan toedienen en/of verwijderen, is regel 12 niet van toepassing. Daarnaast moet regel 15 worden overwogen voor MDSW dat wordt gebruikt voor anticonceptie.

Met name classificatieregel 11 is voor MDSW van toepassing. De MDCG 2019-11 geeft aanwijzingen hoe deze regel te hanteren. Volgens de MDCG-richtlijn kan regel 11 voor onafhankelijke MDSW in drie delen worden verdeeld:

  • regel 11a: Software die informatie verstrekt voor diagnostische of therapeutische doeleinden (klassen IIa – III),
  • regel 11b: Softwarebewaking van fysiologische processen (klassen IIa – IIb) en
  • regel 11c: alle andere software (klasse I).

De MDCG benadrukt dat regel 11a bedoeld is om een risico gebaseerde benadering te bieden, rekening houdend met de gevolgen van een verkeerde beslissing die is genomen op de gegevens die door de software in kwestie zijn verstrekt. Helaas gebruikt de MDR de uitdrukking “kan veroorzaken” zonder rekening te houden met de waarschijnlijkheid van de gebeurtenis. Om dit probleem op te lossen, adviseert de MDCG-richtlijn nu om gebruik te maken van het reeds eerder genoemde IMDRF risico-categorisatiekader. Het ondersteunt de risicoclassificatie van software door twee essentiële aspecten te introduceren:

  • de betekenis van de verstrekte informatie en
  • de ernst van de medische indicatie voor gebruik van het hulpmiddel.

De volgende afbeelding laat zien hoe u de IMDRF-risicoclassificatie kunt toepassen op regel 11:

De ernst van de indicatie is niet controleerbaar door de fabrikant, maar hangt af van wat de software moet analyseren: Hoe kritisch is de gezondheidssituatie of de ziekte? Heeft het een tijdkritische behandeling nodig? Is de patiëntenpopulatie kwetsbaar in vergelijking met andere populaties? De betekenis van de informatie is de belangrijkste factor die rechtstreeks door fabrikanten kan worden beïnvloed door middel van de productclaim. Om dit duidelijk te maken gebruiken we een app voor het beoordelen van moedervlekken als voorbeeld. Met deze app kunnen gebruikers foto’s maken van moedervlekken en deze vervolgens opslaan en analyseren. Op basis van beeldverwerkingsalgoritmen biedt de app een gedetailleerde beoordeling van de gescande moedervlekken. Bovendien beoordeelt de app de waarschijnlijkheid dat de gescande moedervlek een melanoom is om een vroege diagnose van huidkanker te ondersteunen. Eén ding is duidelijk, deze app is een onafhankelijke MDSW volgens de MDCG-richtlijn. Kleine verschillen in het beoogde doel hebben aanzienlijke gevolgen. Stel je voor dat de app in twee versies bestaat:
De nummering van IMDRF-risicoklassen verschilt enigszins van de MDR-risicoklassen. In totaal kunnen 4 verschillende klassen worden afgeleid. De vraag is ook of er nog klasse I-software zal zijn, aangezien deze niet in de IMDRF tabel voorkomt. Het antwoord is ja, namelijk in geval dat de software overeenkomstig MDR bijlage VIII uitvoeringsregel 3.3 een hulpmiddel bestuurt of het gebruik ervan beïnvloedt, en dus in dezelfde klasse als het hulpmiddel valt. Ook in gevallen waarin de software geen informatie verstrekt voor diagnostische of therapeutische doeleinden (regel 11 c) valt software in klasse I.

  • gebruikt door patiënten voor een eerste zelfevaluatie en
  • gebruikt door beroepsbeoefenaren in de gezondheidszorg voor medische diagnose.

Hoewel versie 2 van de app wordt gebruikt voor directe diagnose, is regel 10 niet van toepassing. Het verwijst naar “directe diagnose of monitoring van vitale fysiologische processen” (overweging 3 van 6.2. Bijlage VIII). In plaats daarvan passen we regel 11 toe. Versie 1 “informeert over opties voor diagnose” (betekenis van informatie) en zelfs met de meest kritische situatie optie eindigen we met klasse IIa. Versie 2 “helpt bij de diagnose”, terwijl de uiteindelijke diagnose onder de verantwoordelijkheid van de arts valt. Hier zou de meest kritische situatie optie ons naar klasse IIb leiden. Als het medische doel van de app de directe en het enige hulpmiddel voor de diagnose is, dan kan de app zelfs worden toegewezen aan klasse III.

De uitkomst van softwareclassificatie heeft belangrijke gevolgen voor een fabrikant. Hoe hoger de risicoklasse, hoe hoger de inspanning voor de technische documentatie. Zo zijn klinische proeven verplicht voor producten met een hoog risico zoals klasse III en implanteerbare hulpmiddelen. Fabrikanten wordt daarom geadviseerd om de bewoordingen van de IMDRF risicocategorisatie te gebruiken voor het beoogde doel om de classificatie duidelijk te rechtvaardigen. Bovendien moeten fabrikanten het beoogde doel duidelijk verwoorden, om medische van andere functies te onderscheiden.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google photo

Je reageert onder je Google account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s

Deze site gebruikt Akismet om spam te bestrijden. Ontdek hoe de data van je reactie verwerkt wordt.

%d bloggers liken dit: