.jpg)
Wat Zijn Onze Geheimen Voor Het Maken Van MDR-gecertificeerde Software?
Software als medisch hulpmiddel is niets nieuws. Het certificeren van software onder de nieuwe Wetgeving Medische Hulpmiddelen kan echter ingewikkeld zijn. Daarom loont het om een ervaren expert bij de hand te hebben die je door de documentatie loodst welke door de Notified Body vereist wordt.
Bij Peercode bieden we niet alleen regulatory advies voor medische hulpmiddelen, we zijn ook fabrikant van drie zelf-ontwikkelde medische softwareproducten die op de Europese markt zijn. Dat betekent dat we niet alleen ruime ervaring hebben met het helpen van bedrijven om hun medische hulpmiddelen MDR-gecertificeerd te krijgen, maar ook ervaring uit de eerste hand hebben. Dus wat zijn onze geheimen om dit goed aan te pakken? Laten we dat eens bekijken.
Geheim 1
Het is geen geheim dat Peercode momenteel drie verschillende softwareproducten op de markt heeft. De Notified Body controleert jaarlijks één product. Hoewel elk product anders is, is na de goedkeuring van het eerste product voor ieder volgend product slechts beperkt ondersteunend bewijs nodig over een cyclus van 5 jaar. Zoals aan het begin gezegd, hebben we tot nu toe drie softwareproducten ontwikkeld als medische hulpmiddelen die zijn gecertificeerd onder de MDR. Hier een korte samenvatting van elk hulpmiddel:
- De MASK-air App is ontwikkeld voor mensen met allergieën en astma. Het helpt patiënten hun symptomen bij te houden en stuurt een bericht wanneer er een mogelijk waarschuwingssignaal is. Het is een mobiele applicatie die nuttige gegevens levert die een patiënt kan delen met zijn arts.
- IMID Monitor ondersteunt patiënten met reumatoïde artritis en inflammatoire darmaandoeningen in een ziekenhuisomgeving. In afwachting van een afspraak vullen ze een wetenschappelijk gevalideerde vragenlijst in. De arts heeft vanaf een computer toegang tot deze informatie en kan deze gebruiken voor de bespreking van en de besluitvorming over de behandeling.
- Ons derde softwareproduct, Atris, maakt verbinding met sensoren – zoals een hartslagmeter – leest de gegevens uit en stuurt deze naar een applicatie die bijhoudt hoeveel er door iemand wordt bewogen. De gegevens worden ook naar een dashboard gestuurd, waar een arts toezicht houdt op elke patiënt. Dit kan helpen bij het informeren en ondersteunen van een geschikt revalidatieprogramma.
Zoals u kunt zien, is elk product heel verschillend wat betreft gebruikers, functionaliteit en toepassing. De documentatie die de Notified Body nodig heeft, lijkt echter sterk op elkaar. De dossiers voor deze producten hebben een vergelijkbare structuur.
Voor bedrijven met meer dan één softwareproduct als medisch hulpmiddel is het van cruciaal belang dat het eerste product over die wettelijke drempel komt. Daarna weet u hoe het moet. U heeft het proces en de documentatie al een keer doorlopen. Dit bevat:
- Wat de software zal doe
- Voor wie het is bedoeld
- Hoe je de klinische claim onderbouwt
Dat betekent dat we een sjabloon kunnen gebruiken om het dossier op te stellen voor verschillende soorten medische software; niet alleen voor onze eigen software, maar ook voor andere bedrijven. Dit maakt het opstellen van de benodigde documentatie een stuk eenvoudiger.
Geheim 2
Naleving van de MDR vereist een duidelijk overzicht van het beoogde doeleinde en de beoogde gebruikers – doorgaans artsen en/of patiënten – en een risicoclassificatie – wat de mogelijke schade voor een patiënt is. Deze informatie bepaalt het toepassingsgebied van uw documentatie en wat u hierin moet opnemen. Het is cruciaal om deze eerste stap goed te doen, omdat het de richting van de rest van de documentatie bepaalt.
De tweede belangrijke factor is de claim over het klinische voordeel. De Notified Body moet duidelijk begrijpen hoe de software de patiënt ten goede komt. Bedrijven moeten dit kwantificeren en kwalificeren, en het voorzien van bewijs om de claim te ondersteunen. Als de software beweert 'tijd te besparen', moet dit worden bewezen met haalbaarheidsstudies, feedback van gebruikers en meningen van experts.
Eén van onze softwareproducten verbindt bijvoorbeeld op afstand de gezondheidsgegevens van patiënten – via sensoren thuis – met een arts door gebruik van een medisch, verbindend hulpmiddel. Om dit soort monitoring op afstand te valideren, was input van artsen nodig over hoe het hun werk ten goede komt, plus een bruikbaarheidsonderzoek om aan te tonen dat de software gemakkelijk en veilig te gebruiken is.
Geheim 3
Naast duidelijkheid over het beoogde doeleinde en de beoogde gebruiker, moet de documentatie voor de Notified Body gemakkelijk te begrijpen zijn. Simpel gezegd, om uw medische software goedgekeurd te krijgen, moet deze worden begrepen. Tegelijkertijd is het belangrijk om feitelijke informatie te gebruiken om een overtuigende onderbouwing te kunnen geven die samenvat wat het product doet en waarom het nuttig is.
Nogmaals, in tegenstelling tot een fysiek medisch hulpmiddel, zijn deze twee dingen bij software misschien niet meteen duidelijk. Daarom is het belangrijk om het uit te leggen in lekentaal, te getuigen van de technische kant ervan en het te ondersteunen met het benodigde bewijs.
Geheim 4
Het mooie van software voor medische hulpmiddelen is dat ontwikkeling en productie hetzelfde zijn. Een ander voordeel ten opzichte van het produceren van fysieke producten is dat er bewijs kan worden gehaald uit externe studies en literatuur – het is niet altijd nodig om een intern onderzoek uit te voeren. Dit kan helpen om het samenstellen van het dossier te versnellen.
Geheim 5
Als er software in een fysiek medisch hulpmiddel zit, wordt het ingewikkelder. Als de software en de hardware niet afzonderlijk kunnen functioneren, moet voor zowel het hulpmiddel als de software worden bewezen dat ze samen werken.
Als stand-alone software als medisch hulpmiddel fysiek verbinding maakt met een fysiek hulpmiddel van derden, dan is het absoluut noodzakelijk om de verbinding en overdracht van gegevens te valideren, maar niet het fysieke hulpmiddel zelf. Dit garandeert dat de invoergegevens correct zijn en dat er geen verlies of manipulatie is bij data export van het fysieke apparaat en het overzetten naar de software.
MDR: Investering versus kosten
Onder de vorige EU-regelgeving – de Medical Device Directive (MDD) – kon software als medisch hulpmiddel zelfgecertificeerd zijn. Dit betekende in feite dat het onwaarschijnlijk was dat de documentatie door een Notified Body zou worden onderzocht, omdat deze als een laag risico werd beschouwd.
Nu, onder de MDR, moet een Notified Body software als medisch hulpmiddel controleren voordat het op de markt wordt gebracht. Zodra het op de markt is, kan de software worden geïnspecteerd door de autoriteiten, omdat het als een hoger risico wordt beschouwd. Dit zorgt voor een push-pull-effect.
Enerzijds vertrouwen zorgaanbieders steeds meer op medtech devices, waarvoor slimme softwareoplossingen nodig zijn. Aan de andere kant zullen bedrijven in medische hulpmiddelen twee keer nadenken over investeringen in software vanwege de kosten om aan de wettelijke eisen te voldoen. De juiste begeleiding en ondersteuning is dus belangrijk om de kosten laag te houden.
Waar vindt u de juiste hulp?
Er zijn een aantal bronnen om op de hoogte te blijven van de wettelijke eisen van de EU voor software als medisch hulpmiddel. Naast de officiële mededelingen van de EU over de MDR zijn er ook gedetailleerde richtlijnen beschikbaar van de MDCG.
Met deze officiële bronnen moet u er echter goed induiken en beoordelen wat u werkelijk nodig heeft voor het kwaliteitssysteem van uw product. En dat kost tijd. Naast deze officiële kanalen zijn er ook groepen op LinkedIn die kunnen worden gevolgd welke links bevatten naar blogs en nieuws over de MDR.
Met de komst van de MDR en software als medisch hulpmiddel valt er veel te leren. Zelfs als u een regulatory expert in huis heeft, is het niet altijd gemakkelijk om volledig te begrijpen wat er nodig is en hoe u dit moet verpakken voor de Notified Body. Daarom is het de moeite waard om met ons van Peercode Regulatory Consultancy te praten.