Op 26 mei 2021 was het eindelijk zo ver. Ruim vier jaar na de vaststelling werd de Verordening betreffende medische hulpmiddelen (EU 2017/745), beter bekend als de Medical Devices Regulation (‘MDR’), van toepassing. Dat het zolang duurde voordat de MDR van toepassing werd, kwam mede door de coronacrisis. Als gevolg daarvan werd besloten de MDR een jaar later in te laten gaan.

De MDR bouwt voort op oude regels met betrekking tot medische hulpmiddelen (Richtlijn 90/385/EEG en Richtlijn 93/42/EEG). Die oude regels waren toe aan een grondige aanpassing om, aldus overweging 1 bij de MDR, een “robuust, transparant, voorspelbaar en duurzaam regelgevingskader (..) dat een hoog niveau van veiligheid en gezondheid waarborgt en tegelijkertijd innovatie ondersteunt”, te creëren. Het doel van de MDR is aldus de patiëntveiligheid te vergroten en er ook voor te zorgen dat innovatieve medische hulpmiddelen beschikbaar blijven voor patiënten.

De MDR is veel meer dan het resultaat van het oppoetsen van twee oude Europese richtlijnen. De MDR brengt verandering. Zeker voor ontwikkelaars van medische software (waaronder ook apps). In een serie van drie verdiepende blogs zetten wij 12 belangrijke aandachtspunten op een rij.

Opzet blogserie

In dit eerste blog staan wij stil bij twee aandachtspunten: de kwalificatie van software als medisch hulpmiddel en het vaststellen van de risicoklasse.

In het tweede blog bespreken wij zes aandachtspunten: verplichtingen voor fabrikanten (de term voor softwareontwikkelaars die in de MDR wordt gebruikt), de EU-conformiteitsverklaring en CE-conformiteitsmarkering, algemene veiligheids- en prestatie-eisen, technische documentatie, klinische evaluatie, UDI en Eudamed.

In het derde blog bespreken wij de laatste vier aandachtspunten: post-market verplichtingen, vigilantie (het opvolgen van incidenten en calamiteiten), de zogenaamde Person Responsible for Regulatory Compliance (‘PRRC’) en overgangsbepalingen.

De kwalificatie als medisch hulpmiddel

De MDR is alleen van toepassing als er sprake is van een medisch hulpmiddel. Het is dus belangrijk om eerst stil te staan bij de vraag: wanneer kwalificeert software als een medisch hulpmiddel in de zin van de MDR? Het antwoord op die vraag is niet altijd even gemakkelijk te geven.

Software kwalificeert als medisch hulpmiddel als het door de fabrikant bestemd is om alleen of in combinatie te worden gebruikt bij de mens voor één of meer specifieke medische doeleinden. Medische doeleinden zijn bijvoorbeeld de diagnose, preventie, monitoring, voorspelling, prognose en behandeling van ziekte, letsel of een beperking.

Software kan stand-alone zijn (dat is software die onafhankelijk c.q. zelfstandig functioneert) of een ander medisch hulpmiddel aansturen of beïnvloeden (software die functioneert door middel van interactie met een ander medisch hulpmiddel). Het door de fabrikant omschreven beoogde medisch doeleinde is (mede) relevant voor de kwalificatie en classificatie (zie hierna) als medisch hulpmiddel.

Om het in de praktijk gemakkelijker te maken om vast te stellen of software een medisch hulpmiddel in de zin van de MDR is, heeft de Medical Device Coordination Group (‘MDCG’) een guidance document opgesteld. In het document worden tal van voorbeelden gegeven en relevante beoordelingscriteria aangereikt.

Als medisch hulpmiddel kwalificeert bijvoorbeeld software die:

• rechtstreeks een medisch apparaat bestuurt (bijvoorbeeld software voor radiotherapiebehandeling);
• beslissing bevorderende informatie verschaft (denk aan software die ondersteunt bij het bepalen van het moment van ontslag van patiënten op de IC of software die ondersteunt bij de preoperatieve screening van een patiënt en helpt te bepalen of een patiënt voorafgaand aan een operatie op de polikliniek moet worden gezien); of
• ondersteuning biedt aan beroepsbeoefenaren in de gezondheidszorg (denk aan software waarmee ECG-beelden beter kunnen worden geïnterpreteerd).

Tegelijkertijd kwalificeert niet alle software die in de gezondheidszorg wordt gebruikt als medisch hulpmiddel. Zo is software die gebruikt wordt voor het ‘eenvoudigweg’ doorzoeken, opslaan, archiveren of uitwisselen van patiëntgegevens geen medisch hulpmiddel. Ook software die alleen bestemd is voor lifestyle- en welzijnsdoeleinden (en niet voor medische doeleinden), kwalificeert niet als medisch hulpmiddel.

Waar de software ‘draait’ (bijvoorbeeld als Software-as-a-Service (‘Saas’) oplossing in de cloud, lokaal op een computer (on premise) of mobiele telefoon) en het bestaan van het risico op schade voor patiënten of gebruikers van de software, is niet van invloed op de kwalificatie van software als medisch hulpmiddel.

Samenvattend is software die bestemd is om medische informatie te verwerken, te analyseren, te creëren of te wijzigen voor een door de fabrikant bepaald medisch doel (diagnose, preventie, voorspelling of behandeling van letsel, een beperking of ziekte), een medisch hulpmiddel in de zin van de MDR. Is eenmaal vastgesteld dat software een medisch hulpmiddel is, dan moet vervolgens worden vastgesteld in welke risicoklasse de software valt. Hoe hoger de risicoklasse, hoe meer verplichtingen de MDR met zich meebrengt voor de fabrikant.

Risicoklasse

Als vaststaat dat de software een medisch hulpmiddel is, moet de risicoklasse worden bepaald. Dit doet de fabrikant zelf. De classificatieregels zijn opgenomen in Bijlage VIII bij de MDR. Er zijn vier risicoklassen: I (de lichtste risicoklasse), IIa, IIb, en III (de zwaarste risicoklasse). De risicoklasse bepaalt onder andere of het mogelijk is het medisch hulpmiddel zelf te certificeren (risicoklasse I) of dat een aangemelde instantie dat moet doen (risicoklasse IIa, IIb en III).

Bij het bepalen in welke risicoklasse de software valt, zijn het door de fabrikant beoogde doeleinde en de inherente risico’s ervan bepalend. Daarnaast is de (mogelijke) impact van het medisch hulpmiddel op de gezondheid van de patiënt van belang bij het bepalen van de toepasselijke risicoklasse. Als uitgangspunt geldt dat de meest strikte classificatieregel geldt. Bij twijfel of grensgevallen dient de software dus in de hogere risicoklasse te worden ingedeeld.

Software die informatie genereert die gebruikt wordt bij het nemen van beslissingen voor diagnostische of therapeutische doeleinden behoort in principe tot risicoklasse IIa. Als de beslissingen die worden genomen op basis van de gegenereerde informatie kunnen leiden tot een ernstige verslechtering van iemand gezondheidstoestand of een chirurgische ingreep, valt de software in de hogere risicoklasse IIb. Indien de beslissingen kunnen leiden tot overlijden of onomkeerbare verslechtering van de gezondheidstoestand van de patiënt, dan valt de software in de hoogste risicoklasse (III). Met andere woorden: zowel het belang van de informatie bij het nemen van beslissingen door zorgprofessionals als de gezondheidsconditie van patiënten die worden behandeld, spelen mee bij het vaststellen van de risicoklasse waarin de software valt.

Software die fysiologische processen meet zal veelal een diagnostisch of therapeutisch doel hebben en (reeds) om die reden in risicoklasse IIa vallen. Meet de software vitale fysiologische processen die tot onmiddellijk gevaar voor de patiënt kunnen leiden (zoals ademhaling, hartslag, bloeddruk, lichaamstemperatuur), dan valt de software in risicoklasse IIb. Een voorbeeld is een mobiele app die (afwijkingen van) de hartslag meet, de zorgprofessional daarover informeert en op basis van welke informatie de zorgprofessional zijn diagnose of behandeling (mede) baseert.

Alle overige software – die dus niet wordt gebruikt voor diagnostische of therapeutische doeleinden of om (vitale) fysiologische processen te meten – valt in risicoklasse I. In het guidance document van de MDCG wordt als voorbeeld gegeven een app die bedoeld is om conceptie te ondersteunen door het berekenen van de vruchtbaarheidsstatus van de vrouw met behulp van door de vrouw aangeleverde (gezondheids)gegevens en op basis van een gevalideerd statistisch algoritme.

Bestuurt of beïnvloedt de software het gebruik van een ander medisch hulpmiddel, dan valt de software in dezelfde risicoklasse als dat medisch hulpmiddel. Stand-alone software wordt gezien als actief medisch hulpmiddel waarvoor de classificatieregels afzonderlijk moeten worden gevolgd om de risicoklasse te bepalen.

Onder de MDR zijn de risicoklassen hetzelfde gebleven. De classificatieregels daarentegen zijn strikter geworden. Daardoor kan medische software die onder de oude regels in risicoklasse I viel, onder de MDR in een hogere risicoklasse (met bijbehorende regels) vallen. Zo viel software waarmee informatie wordt gegenereerd ter ondersteuning van het nemen van medische beslissingen en voor diagnostische en therapeutische doeleinden onder de oude regels vaak in risicoklasse I. Onder de MDR valt deze software al snel(ler) in risicoklasse IIa of hoger. Voor de fabrikanten van medische software die dat voor 26 mei 2021 al deden en toen in risicoklasse I vielen, is het dus opletten.

Opletten is het ook wanneer nieuwe functionaliteiten worden toegevoegd aan bestaande software. Als gevolg van die nieuwe functionaliteiten kan de software in een hogere risicoklasse komen. Het is goed dit bij het door ontwikkelen van software voor ogen te houden.

Tot slot

De verplichtingen voor fabrikanten zijn onder de MDR talrijker en verregaander dan onder de oude regelgeving. Zo bespraken wij in dit blog dat:

• de definitie van medisch hulpmiddel uitgebreid is waardoor meer software als medisch hulpmiddel kwalificeert;
• software sneller in een hogere risicoklasse valt met bijbehorende verplichtingen; en
• er tal van extra (informatie)verplichtingen voor fabrikanten bij zijn gekomen, zowel voorafgaand aan het op de markt brengen van het medisch hulpmiddel als daarna (waarover het tweede en derde blog uit deze serie gaan).

Bovendien gelden de regels uit de MDR voor alle fabrikanten van medische hulpmiddelen. Fabrikanten van medische hulpmiddelen die voldeden aan de oude regels, moeten in actie komen om ervoor te zorgen dat hun medische hulpmiddel ook tijdig voldoet aan de nieuwe regels (in het derde blog besteden wij aandacht aan de zogenaamde overgangsregels). Voor softwareontwikkelaars die op dit moment medische software ontwikkelen, is het belangrijk om al in het ontwerpproces rekening te houden met de verplichtingen uit de MDR. En voor alle fabrikanten van medische hulpmiddelen geldt vanaf nu de verplichting om gedurende de hele life cycle van de software continue de veiligheid en kwaliteit ervan te monitoren en te bewaken.

Meer weten?

Wilt u meer weten over de MDR, of advies over wat de MDR nu concreet voor u of uw organisatie betekent? Neem dan contact op met Ernst-Jan Louwers.