Terug

Het hoe en waarom van Certificering van Medische apps
Redactie MTIntegraal

07 september 2015

(Laatst aangepast: 20-07-2016)

Het hoe en waarom van Certificering van Medische apps

Publicaties Berichten

Het ontwikkelen van een medische app is relatief eenvoudig en het aantal apps groeit dan ook explosief. Een groot aantal van deze apps speelt in op de persoonlijke gezondheid en levensstijl (“personal health”) en wordt door leken gebruikt. Maar meer en meer apps komen beschikbaar voor professionals en veel artsen maken daar al gebruik van of hebben zelf een medische app ontwikkeld. Waar moeten die medische apps aan voldoen? Is een certificering nodig? Waar moeten een ziekenhuis en een app ontwikkelaar op letten bij het ontwikkelen en op de markt zetten van een medische app? In dit artikel wordt een globaal overzicht gegeven van de huidige wet- en regelgeving op dit gebied.

Wanneer is een app een medisch hulpmiddel?

Een “app” is een software toepassing (applicatie) die bedoeld is om op een mobiele  telefoon, tablet of computer geïnstalleerd te worden en waarmee we een bepaalde  taak kunnen uitvoeren. In wet- en regelgeving spreken we van “standalone software”, dat is software welke niet in een apparaat zit, maar welke los op de markt wordt gebracht. Standalone software omvat apps welke via app-stores kunnen worden gedownload, maar ook software applicaties welke op een drager worden geleverd (bijv. SD-card, DVD) en software toepassingen op een website (“SAAS”, software as a service).

In Nederland valt standalone software onder de Wet medische hulpmiddelen (WMH) [1]. In deze wet zijn de eisen van een aantal Europese richtlijnen op het gebied van medische hulpmiddelen omgezet, waaronder die van de MDD (“Medical Device Directive”) [2].

Software is een medisch hulpmiddel als het bedoelde gebruik voldoet aan de definitie van medisch hulpmiddel zoals gedefinieerd in de Wet medische hulpmiddelen. Omdat deze afweging niet altijd eenvoudig is, is er een Europees richtsnoer (MEDDEV 2.1/6) [3] welke als leidraad gebruikt kan worden. Deze MEDDEV bevat de huidige Europese consensus over kwalificatie en classificatie van medische software. Voor sommige lidstaten gaat deze interpretatie niet ver genoeg (bijv. Zweden) en daar gelden aanvullende eisen. Dit verschil van inzicht is echter alleen van belang als medische software ook in andere lidstaten op de markt gebracht gaat worden.

Softwareproducten met een medisch doel moeten zijn aangemeld als medisch hulpmiddel en een CE-markering hebben. Een CE-markering geeft aan dat de fabrikant verklaart dat het product voldoet aan de van toepassing zijnde essentiële eisen en dat de fabrikant een conformiteitsroute doorlopen heeft. In de praktijk betekent dit dat een fabrikant van medische software een set technische documentatie met bewijzen  voor veiligheid en functionaliteit beschikbaar heeft en een kwaliteitssysteem heeft opgezet om te borgen dat software op een gestructureerde wijze wordt ontwikkeld.

Wat wet- en regelgeving betreft is medische software niet anders dan een infuuspomp, een MRI of een katheter.

De fabrikant van medische software is verantwoordelijk voor het voldoen aan wet- en regelgeving, onafhankelijk of de activiteiten geheel of gedeeltelijk worden uitbesteed. De fabrikant is diegene onder wiens naam het product in de handel wordt gebracht.

Classificatie van medische software

Medische hulpmiddelen worden geclassificeerd volgens bijlage IX van de MDD. Software wordt gezien als een actief medisch hulpmiddel en daarmee kunnen classificatieregels 9 t/m 12 van toepassing zijn.

Door het volgen van de classificatieregels kan software in klasse I, IIa of IIb vallen, afhankelijk van het bedoelde gebruik en bijbehorend risico. Ingeval van een klasse I moet aanvullend nog gekeken worden of de software een meetfunctie heeft, in dat geval is classificatie Im van toepassing.

De classificatie van het medisch hulpmiddel heeft invloed op de te volgen conformiteitsroute en bepaalt of een externe partij (Notified Body) ingeschakeld moet worden. De producteisen (essentiële eisen in de MDD) zijn voor alle risicoklassen gelijk.

 

Ontwikkelen van medische software

Waar bij niet-software producten storingen en incidenten ontstaan door veroudering en slijtage, houdt software haar initiële performance vast over de gehele levenscyclus (uiteraard afhankelijk van de beschikbaarheid van de benodigde hardware en andere benodigde software). Dit betekent dat storingen (bugs) vrijwel alleen het gevolg zijn van het gevolgde ontwikkelproces.

Vandaar dat eisen worden gesteld aan het ontwikkelproces van medische software en om daar invulling aan te geven kan internationale norm IEC 62304 [4] toegepast worden. Deze norm specificeert activiteiten, processen en documentatie in de levenscyclus van medische software.

IEC 62304 volgt het watervalmodel, maar ook andere ontwikkelmethoden (Agile, SCRUM) kunnen toegepast worden. Voor alle fasen in het ontwikkelproces (zoals planning, eisen, architectuur, implementatie, testen) is documentatie nodig welke intern beoordeeld en vastgesteld dient te worden, voordat naar een volgende fase wordt overgegaan. Afhankelijk van het risico van de software kunnen bepaalde activiteiten achterwege worden gelaten, zoals code-reviews of unit-testen.

Door het toepassen van de IEC 62304 norm ontstaat een gestructureerd ontwikkelproces, waardoor fouten voorkomen en gedetecteerd kunnen worden, wat leidt tot een betere kwaliteit van het softwareproduct. Eventueel kan ook de ISO 13485 [5] norm worden toegepast voor het opzetten van een compleet kwaliteitssysteem, echter deze norm bevat (nog) geen specifieke eisen voor software producten, maar is generiek bedoeld voor fabrikanten van medische hulpmiddelen.

 

Essentiële eisen

Onafhankelijk van de classificatie moet alle medische software aan de essentiële eisen van de MDD voldoen. Voor software zijn een aantal van deze eisen niet van toepassing (zoals die voor steriliteit en constructie), maar de eisen op het gebied van risicomanagement, etikettering, verificatie, validatie en klinische evaluatie zijn belangrijk bij software producten.

De technische documentatie van de fabrikant bevat de bewijsvoering van het voldoen aan de essentiële eisen. Dit in de vorm van testrapportages, risicomanagement overzichten, architectuur documentatie, rationales, samenvattingen, ed. Van de etikettering (gebruikershandleiding en etiket) dienen er voorbeelden aanwezig te zijn.  Voor verschillende onderwerpen zijn internationale normen beschikbaar, zoals voor usability validatie, risicomanagement en klinische evaluatie.

Voor validatie van software is een draft norm beschikbaar, welke naar verwachting binnen niet al te lange tijd gepubliceerd gaat worden: IEC 82304-1 [6]. Deze norm beperkt zich niet tot medische software, maar omvat “health” (definitie WHO [7]) software en kan ook worden toegepast voor apps welke niet aan de definitie van medisch hulpmiddel voldoen. Deze norm verwijst nadrukkelijk naar de IEC 62304 norm, welke daarmee ook van toepassing gaat worden bij “health” software.

Onder bepaalde voorwaarden mag bij professioneel gebruikte apps de handleiding in elektronische vorm worden meegeleverd (bijvoorbeeld als onderdeel van de app), zoals in Europese verordening 2012/207 [8] gesteld.

Het etiket van de app (in de vorm van een “omtrent” of “about” menu) dient onder andere de naam en adres van de fabrikant te bevatten, het versienummer van de software en de CE-markering.

 

 

Het gebruik van medische apps

Om vast te stellen dat de gebruiker met een kwalitatief goede, veilige en betrouwbare medische app te maken heeft kunnen medische apps worden beoordeeld aan de hand van een aantal simpele criteria, zoals bijvoorbeeld de handleiding, gegevens van de fabrikant, eventuele recensies en de CE-markering. Niet CE-gemarkeerde medische apps mogen in Nederland niet worden gebruikt.

Het  Convenant “Veilige toepassing van medische technologie in het ziekenhuis” [9] legt nog eens vast dat ziekenhuizen alleen CE-gemarkeerde medische hulpmiddelen mogen  toepassen. Daarnaast moeten gebruikers bekwaam zijn en moet vooraf worden vastgesteld dat het medisch hulpmiddel aan de specificaties voldoet en aan het pakket van eisen van het ziekenhuis. Voor een infuuspomp, een MRI en een katheter kunnen we dat nog wel inzichtelijk maken, maar hoe doe je dat voor software?

Naast de CE-markering speelt de beveiliging (“security”) van medische data een steeds belangrijkere rol. Wat gebeurt er met de data en wie heeft daar potentieel toegang toe? Welke maatregelen heeft de fabrikant tijdens het ontwerp genomen om een juist niveau van beveiliging mogelijk te maken? Een gebruiker moet zich bewust zijn van de risico’s op dit gebied om tot een juiste keuze te komen en zich niet alleen op de prijs of de vormgeving van een app baseren.

 

De rol van IGZ en de Notified Body

De Inspectie voor de Gezondheidszorg (IGZ) houdt toezicht op medische hulpmiddelen. Het toezicht gebeurt op basis van incidentmeldingen van fabrikanten en zorgaanbieders en op basis van risico-inschatting.

In juni en oktober 2013 heeft IGZ een tweetal conferenties gehouden over het thema software als medisch hulpmiddel met als doel het veld (gebruikers, managers, fabrikanten) te informeren over bestaande wet- en regelgeving en het feit dat de inspectie gaat handhaven vanaf januari 2014.

Ook heeft IGZ een marktverkennend onderzoek uitgevoerd waarbij van softwareproducten informatie werd opgevraagd. Deze informatie werd beoordeeld op compleet- en correctheid tegen bestaande normen en richtsnoeren.

De IGZ handhaaft vanaf 1 januari 2014 op de wet medische hulpmiddelen. Bij een overtreding kan de minister van VWS een boete opleggen van maximaal 900.000,- euro. Het is bekend dat in een aantal gevallen een boete is opgelegd.

Een Notified Body (in Nederland is dat bijvoorbeeld DEKRA Certification) toetst initieel het kwaliteitssysteem en de technische documentatie van de fabrikant tegen de van toepassing zijnde wet- en regelgeving. Nadat dit proces is afgerond geeft de Notified Body een CE-certificaat af. Met dit certificaat mag de fabrikant de software beschikbaar stellen voor gebruik. In Europa zijn ongeveer 70 Notified Bodies actief; de fabrikant kiest er daarvan één.

De Notified Body komt jaarlijks een geplande audit uitvoeren en komt daarnaast ook onaangekondigd. Tijdens deze opvolgingsbezoeken wordt beoordeeld of nog steeds aan de van toepassing zijnde wet- ene regelgeving wordt voldaan en hoe met informatie uit de markt wordt omgegaan (“post market surveillance”), waaronder klachten en incidenten.

 

Conclusie

Software met een medisch doel moet aan de eisen van de MDD voldoen. Bestaande wet- en regelgeving bevat voldoende houvast om tot kwalitatief goede en veilige  medische apps te komen. Fabrikanten moeten zich realiseren dat ze geen spelletjes maken, maar software welke invloed kan hebben op de diagnose of therapie van een patiënt en dat daar CE-markering voor nodig is.

Het is van belang dat gebruikers van medische apps zich bewust zijn van de mogelijke risico’s en alleen die medische apps gebruiken welke CE-gemarkeerd zijn. Een CE-markering biedt geen garantie op een foutloze app, maar zegt wel iets over het gevolgde ontwikkelproces en de aanwezige bewijsvoering.

 

Het Convenant “Veilige toepassing van medische technologie in het ziekenhuis” maakt geen onderscheid tussen software en hardware. Daarom zouden  ziekenhuizen medische apps onder hetzelfde regime moeten laten vallen als de infuuspomp, de MRI en de katheter en zich moeten overtuigen of er wel voldoende bewijs is voor veiligheid en performance en of er klinische data is.

[1] Wet op de medische hulpmiddelen (Wmh), BWBR0002697.
[2] COUNCIL DIRECTIVE 93/42/EEC of 14 June 1993 concerning medical devices.
[3] MEDDEV 2-1-6 rev1 [2012] Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices
[4] IEC 62304 [2006] Medical device software - Software life-cycle processes
[5] ISO 13485 [2003] Medical devices - Quality management systems - Requirements for regulatory purposes
[6] IEC/DIS 82304-1 [2015] Health software — Part 1: General requirements for product safety
[7] Preamble to the Constitution of the World Health Organization as adopted by the International Health Conference, New York, 19-22 June, 1946; signed on 22 July 1946 by the representatives of 61 States (Official Records of the World Health Organization, no. 2, p. 100) and entered into force on 7 April 1948.
[8] COMMISSION REGULATION (EU) No 207/2012 of 9 March 2012 on electronic instructions for use of medical devices
[9] Convenant “Veilige toepassing van medische technologie in het ziekenhuis”, 2011

Toon alle referenties

Auteur