# 9 veelvoorkomende fouten bij het uitbrengen van software als medisch hulpmiddel en hoe je deze kunt vermijden De Medical Device Regulation (MDR) introduceert strengere eisen voor het lanceren van zorgsoftware op de EU-markt. Zoals bij elke nieuwe regelgeving, kan het even duren voor bedrijven om de naleving op orde te krijgen. Het is ook onvermijdelijk dat er fouten worden gemaakt, met lange vertragingen en hogere ontwikkelingskosten tot gevolg – zonder specialistische begeleiding. **Datum**12 april 2023 Een belangrijke vraag voor bedrijven die nieuwe software als medisch hulpmiddel willen lanceren: wat zijn de meest gemaakte fouten en hoe kunnen ze worden vermeden? Het hebben van deze kennis kan leveranciers van software voor de gezondheidszorg helpen de valkuilen te vermijden en de time-to-market voor nieuwe producten te versnellen. ### 1. Slecht gedefinieerde softwarevereisten Zoals met elk medisch hulpmiddel, moet software die bestemd is voor de zorgsector een duidelijk omschreven doel hebben. Het is ook essentieel om de hardware te definiëren die nodig is om het uit te voeren. Gezien het aantal apparaten en besturingssystemen dat op de markt is, is dat een enorme taak, vooral wanneer bepaalde fabrikanten van Android-apparaten hun eigen functionaliteit toevoegen, wat de compatibiliteitstest voor softwareleveranciers nog zwaarder maakt. Daarom is het zo belangrijk om vooraf vereisten te definiëren om ervoor te zorgen dat klanten gemakkelijk kunnen ontcijferen of het zal werken op hun gekozen besturingssysteem en apparaat. We raden aan om een op risico gebaseerde benadering te volgen bij het definiëren van softwarevereisten. Bij een major release dient elke functie goed getest te worden, terwijl bij een minor release alleen de gewijzigde of nieuwe functionaliteit en enkele sleutel functionaliteiten getest moeten worden (regressietesten). ### 2. Onvoldoende testen Het is belangrijk om elk nieuw softwareproduct grondig te testen. Dat geldt met name voor nieuwe software als medisch hulpmiddel, wat een directe impact heeft op de patiëntenzorg en resultaten. Onvoldoende verificatie- en validatietesten zorgen ervoor dat corrigeerbare problemen ongemerkt op de markt worden gebracht, wat resulteert in een defect of slecht functionerend product. In het beste geval is dit een potentiële PR-ramp, in het slechtste geval kan het een negatieve impact hebben op de patiëntveiligheid. Stel je bijvoorbeeld voor dat belangrijke patiëntgegevens verloren zijn gegaan of op de een of andere manier zijn gecompromitteerd. Daarom is het essentieel om een goed verificatie- en validatieplan te definiëren. Testprotocollen moeten alle softwarevereisten dekken. Elk testprotocol moet ook stapsgewijze richtlijnen bieden voor het verkrijgen van het benodigde bewijs om de softwarevereisten te verifiëren en te valideren en de resultaten beschrijven die naar verwachting zullen worden verkregen door het protocol te volgen. ### 3. Onvoldoende risicobeheersing Niemand denkt graag aan de gevolgen als er iets misgaat met zorgsoftware. Maar wanneer er onvoldoende risicobeheer is in de ontwerp- en ontwikkelingsfase, kan dit later tot aanzienlijke problemen leiden. Daarom moeten softwarevereisten elk aspect van het ontwerp omvatten, inclusief beveiliging, functionaliteit, gebruikersinterface (User Interface, UI), labeling, installatie en configuratie – in overeenstemming met de MDR-vereisten. Elke softwarevereiste heeft een robuust testsysteem nodig, dat verificatie en validatie biedt om te bevestigen dat aan de eisen wordt voldaan. Het niet definiëren van alle noodzakelijke vereisten kan resulteren in een gebrek aan bewijs in de technische documentatie. Ons advies? Volg de norm ISO14971 die het risicobeheerproces voor medische hulpmiddelen schetst, inclusief 'software als medisch hulpmiddel'. Voor meer informatie over risicobeheer kunt u ook ISO/TR 24971 en AAMI TIR32:2004 (R2016) raadplegen. ### 4. Slechte gebruikerstesten In de haast om software voor de gezondheidszorg op de markt te brengen, laten sommige bedrijven het na om gebruikerstesten correct uit te voeren. Dit is een vergissing. Gebruikerstesten moeten correct worden uitgevoerd en gepland om de software te testen tegen de gedefinieerde gebruikerspopulatie. Daarom is het belangrijk om een representatieve testgroep samen te stellen met diverse achtergronden binnen de gedefinieerde populatie, zodat ze tests kunnen uitvoeren die het gebruik in de echte wereld weerspiegelen. Hierbij zijn twee dingen van belang: het bepalen van het beoogde gebruik van de software en het zorgen voor een goede steekproefomvang. Dit soort testen is de sleutel tot het verkrijgen van krachtige feedback over het verbeteren van de software en gebruikservaring. Daarnaast is het ook een verplicht onderdeel van de MDR. Feedback over gebruikerservaring bepaalt of een bedrijf gebruiksaanwijzingen moet maken of dat ze wijzigingen moeten aanbrengen om het bruikbaarder te maken. Sla deze stap over en bedrijven kunnen klachten van gebruikers verwachten. ### 5. Onvolledige wijzigingsdocumentatie Telkens wanneer er een wijziging is in software voor de gezondheidszorg, moet dit worden gedocumenteerd. De wijzigingen vereisen ook verificatie en validatie. Afhankelijk van de omvang van de update kan dit proces enige tijd duren – van een dag tot veel langer, afhankelijk van de complexiteit van de software en de omvang van de update. Bepaalde wijzigingen moeten ook ter goedkeuring naar de Notified Body worden gestuurd. In dit opzicht verschilt software voor de gezondheidszorg van andere soorten software: er is een extra regelgevingssysteem dat op de juiste manier moet worden afgehandeld om naleving en productveiligheid te waarborgen. Dit kan updates vertragen en een verdere regeldruk vormen voor softwareleveranciers in de gezondheidszorg. ### 6. Ontbrekende gebruiksaanwijzing De MDR schrijft voor dat er een gebruiksaanwijzing moet zijn – tenzij het product klasse I of IIa is en gemakkelijk in gebruik. Ontheffing van het geven van instructies dient duidelijk gedocumenteerd te zijn en gebaseerd te zijn op de resultaten van bovengenoemde gebruikerstesten. Wanneer bedrijven echter instructies moeten opstellen, kan dit een lastige taak worden. Afhankelijk van het type software kan dit oplopen tot pagina's en pagina's documentatie. Voor apparaten met een hoog risico zijn instructies verplicht om ervoor te zorgen dat de software kan worden gebruikt zoals bedoeld, vooral wanneer onjuist gebruik van het product kan leiden tot letsel of zelfs de dood van de patiënt. ### 7. “Feature creep” Wanneer software - inclusief producten die zijn ontworpen voor de zorgsector - geen duidelijk gedefinieerd gebruik heeft, kan deze gemakkelijk worden overladen met onnodige functies. Dit soort “feature creep” kan ontwikkel-uren kosten, wat een afleiding vormt van de kernontwikkeling van de software en het samenstellen van bijbehorende documentatie. Om die reden is het belangrijk dat de software voldoet aan de behoeften van de gebruikerspopulatie. We raden aan om ontwikkelingsdoelen altijd in lijn te houden met bedrijfsdoelstellingen en het beoogde gebruik van een softwareproduct. ### 8. Het niet aantonen van klinisch voordeel Met producten zoals software als medisch hulpmiddel kan het definiëren van het klinische voordeel soms een uitdaging zijn. Dat komt doordat er, afhankelijk van wat de software doet, niet altijd kwantitatieve gegevens zijn om een klinisch voordeel te ondersteunen. Simpel gezegd, het is niet altijd gemakkelijk om het klinische voordeel van software als medisch hulpmiddel aan te tonen. In deze situatie vereist het voltooien van het klinische evaluatierapport alternatieve benaderingen. We raden aan om literatuur over vergelijkbare software te bekijken en zo veel mogelijk wetenschappelijke gegevens te includeren. Neem daarnaast resultaten op van gebruikerstesten, zoals gebruikersinterviews, en definieer post-market clinical follow-up (PMCF)-plannen, die plannen illustreren om het klinische voordeel in de nabije toekomst te bewijzen, wanneer mensen het in een real-life context kunnen gebruiken. ### 9. Gebrek aan regelgevende processen Zoals we al hebben besproken, moet software voor de gezondheidszorg onder de MDR voldoen aan regelgevende processen voor verandermanagement. Bovendien moeten er duidelijke processen zijn voor de afhandeling van klachten. Het is een goed idee om processen voor corrigerende en preventieve maatregelen en post-market surveillance (PMS) in werking te stellen voordat de software wordt vrijgegeven. Dit zijn niet alleen verplichte onderdelen voor de MDR, maar je team moet ook worden opgeleid voor deze procedures, zodat gegevens kunnen worden verzameld en klachten snel kunnen worden opgelost om positieve klantrelaties te behouden. Het toezicht na het op de markt brengen is belangrijk om de software iteratief te verbeteren, state-of-the-art te blijven, nuttige functionaliteit toe te voegen en verdere risico's te beperken. *Dawn Regulatory Services levert hoogwaardige diensten, auditing en training voor bedrijven in medische hulpmiddelen.* [*Praat vandaag nog met een specialist.*](https://test.blub.company/contact) [Terug naar overzicht](/evenementen-publicaties) Link gekopieerd naar het klembord ### Klaar om je SaMD zonder fouten te lanceren? Laat je gegevens achter. Wij zorgen voor een duidelijke aanpak om jouw software snel en zeker MDR-proof te maken. ## Nieuwsgierig naar onze laatste updates? Blijf up-to-date in het digitale landschap met onze nieuwsbrief. Schrijf je in en krijg het in je mail.