Spring naar inhoud

Medische hulpmiddelen softwarelevenscyclus

24 december 2019

De Europese verordening voor medische hulpmiddelen (EU) 2017/745 (MDR) en de verordening voor in-vitrodiagnostiek (EU) 2017/746 (IVDR) vereisen dat fabrikanten rekening houden met de softwarelevenscyclus van medische hulpmiddelen. De levenscyclus van een product beschrijft een proces van het productidee tot de marktuitsluiting. Dit concept wordt ook toegepast op software als medisch hulpmiddel. De Europese wetgever verplicht fabrikanten om rekening te houden met de principes van de productlevenscyclus.

Concreet bevat de MDR vier directe verwijzingen naar de levenscyclus van medische hulpmiddelen:

  • De fabrikant moet de klinische evaluatie en de bijbehorende documenten gedurende de gehele levenscyclus van het product up-to-date houden (artikel 61, MDR).
  • De fabrikant moet gedurende de gehele levenscyclus van het product continu risicomanagement uitvoeren (bijlage I, MDR).
  • De fabrikant moet een kwaliteitsmanagementsysteem opzetten en in stand houden gedurende de gehele levenscyclus van het product (bijlage IX, MDR).
  • De fabrikant moet een typekeuring aanvragen bij een aangemelde instantie waaruit blijkt dat het product gedurende de gehele levenscyclus aan de bepalingen van de MDR voldoet (bijlage X, MDR).

Een andere 5e verwijzing verwijst expliciet naar software als een medisch hulpmiddel. Daar staat:

  • In het geval van producten waarvan de componenten software of producten in de vorm van software omvatten, wordt de software ontwikkeld en vervaardigd in overeenstemming met de stand van de techniek, rekening houdend met de principes van de levenscyclus van de software, risicobeheer inclusief informatiebeveiliging , verificatie en validatie ” (Bijlage I, MDR).

In bijlage I definieert de MDR de algemene eisen voor veiligheid en prestaties van medische hulpmiddelen. Daarnaast zul je als fabrikant ook rekening moeten houden met de vereisten van de Algemene Verordening Gegevensbescherming (AVG). Als een fabrikant software als medisch hulpmiddel op de markt wil brengen, moet hij bewijzen dat hij aan al deze eisen voldoet. Aangezien het testen van software onmogelijk de volledige  juistheid van software kan bewijzen, moeten softwarefouten (bugs, bruikbaarheidsproblemen) vanaf het begin worden vermeden door het volgen van softwarelevenscyclusprocessen. Alle softwaregerelateerde richtlijnen voor softwarevalidatie eisen van fabrikanten van medische hulpmiddelen deze levenscyclusprocessen te volgen. Ze dwingen echter niet een specifiek levenscyclusmodel, zoals een watervalmodel, v-model of een agile ontwikkelingsproces, af. De fabirakant mag vrij kiezen welk model hij wil gebruiken voor zijn software product, mits hij het model maar beschrijft en de activiteiten conform het beschreven model uitvoert.

Als fabrikanten deze eis in de praktijk willen implementeren, zijn 4 normen bijzonder belangrijk.

IEC 62304

IEC 62304 “Software voor medische hulpmiddelen – Processen in levenscyclus van programmatuur” is de eerste norm die in overweging moet worden genomen bij het bekijken van de software-levenscyclus. De norm beschrijft levenscyclusprocessen en kent daaraan bepaalde activiteiten en taken toe. Het is van toepassing op de ontwikkeling en het onderhoud van medische software. Het maakt niet uit of de software zelf een medisch hulpmiddel is of dat het wordt gebruikt als een ingebed of integraal onderdeel van een medisch hulpmiddel. De toepassing van de norm veronderstelt dat de fabrikant zijn software ontwikkelt en onderhoudt als onderdeel van een systeem voor kwaliteitsbeheer en risicobeheer.

IEC 62304 vereist van fabrikanten dat zij de risico’s van hun medische software classificeren. De norm specificeert afhankelijk van de bijdrage van de software aan een gevaarlijke situatie 3 veiligheidsklassen:

  • Klasse A: Geen letsel of schade aan de gezondheid is mogelijk.
  • Klasse B: Niet-ernstig letsel is mogelijk.
  • Klasse C: Dood of ernstig letsel is mogelijk.

Fabrikanten passen de beschreven processen toe, afhankelijk van de respectieve beveiligingsklasse.

De IEC 62304-procesnorm beschrijft 5 basissoftwareprocessen:

  • ontwikkeling
  • onderhoud
  • risicomanagement
  • configuratie
  • probleem oplossing

Aan het begin van de softwareontwikkeling vindt een planning plaats. De fabrikant stelt een gedetailleerd software-ontwikkelingsplan op, dat hij moet bijhouden, afhankelijk van de voortgang van de ontwikkeling. De fabrikant analyseert vervolgens de softwarevereisten. Dit omvat functies zoals tijdgedrag, besturingssysteem, geheugengrootte, standaardinstellingen, interfaces, authenticatie, netwerkprotocollen en nog veel meer. De fabrikant moet vervolgens een geschikte software-architectuur ontwerpen en vervolgens beschrijven hoe hij de software wil implementeren en integreren.

IEC 62304 legt de vereisten voor de software-architectuur in detail uit. Deze omvatten bijvoorbeeld interfaces tussen componenten en speciale vereisten voor “onbekende” softwarecomponenten. De standaard beschrijft componenten als “Software van onbekende herkomst” (SOUP), of “Off-the-Shelf-software”. Dit is algemeen beschikbare software die niet is ontwikkeld voor het betreffende medische hulpmiddel. Vanuit het oogpunt van risicobeheer staat SOUP natuurlijk voor speciale uitdagingen. Het is daarom niet verwonderlijk dat het ontwikkelingsproces ook een beschrijving van softwaretests bevat. Het softwareontwikkelingsproces wordt afgesloten met informatie over documentatie en archivering. Ten slotte beschrijft de norm hoe wijzigingen op een ordelijke manier moeten worden geïmplementeerd en vrijgegeven. Het software-onderhoudsproces begint met een onderhoudsplanning die bijvoorbeeld procedures voor ontvangst, documentatie en traceerbaarheid omvat.

Het is geen verrassing dat risicomanagement eerst een gevarenanalyse bevat. De nadruk ligt op componenten die kunnen bijdragen aan een gevaarsituatie en hun oorzaken. De gevarenanalyse wordt gevolgd door een overweging van risico beperkende maatregelen, hun verificatie en traceerbaarheidsdocumentatie. Fabrikanten moeten de risico’s van softwarewijzigingen ook expliciet overwegen en organiseren. Opgemerkt moet worden dat er geen toevallige fouten met software kunnen zijn, zoals die kunnen optreden met fysieke medische hulpmiddelen vanwege de inferieure kwaliteit van een geleverd en verwerkt materiaal of vanwege fouten als gevolg van onachtzaamheid van werknemers in productie. Als software een fout bevat, worden alle kopieën van deze versie van de software, in tegenstelling tot een fysiek medisch apparaat, beïnvloed door deze fout. Softwarefouten zijn daarom altijd systematische fouten. Nogmaals, SOUP speelt een belangrijke rol, omdat de standaard expliciet een evaluatie vereist van openbaar beschikbare lijsten met “SOUP-afwijkingen”.

IEC 62304 laat de juiste configuratie van medische software niet aan het toeval over. Een gedetailleerde uitsplitsing van identificatie, documentatie en goedkeuringsstappen zorgt ervoor dat de fabrikant de best mogelijke configuratie kan vinden, aanpassen en traceren. Het proces omvat op zijn beurt een speciale overweging van SOUP.

IEC 62304 vereist een systematische analyse van problemen en wijzigingen die zich hebben voorgedaan in verband met de softwareapplicatie; de Post-Market Surveillance. Dit omvat passende communicatie met gebruikers en vereist dat de fabrikant betrokken partijen en verantwoordelijke autoriteiten informeert over problemen die zich voordoen in verband met het gebruik van medische software. De fabrikant moet ook alle gegevens bijhouden en ook een trendanalyse van softwareproblemen uitvoeren.

IEC 82304-1

Een andere norm IEC 82304-1 ” Gezondheidssoftware – Algemene eisen voor productveiligheid” is ook belangrijk. Het heeft betrekking op vragen over de veiligheid en risico’s van software die onafhankelijk van hardware op de markt moet worden gebracht (“stand-alone software”, “gezondheids-apps”). Een gezondheidsapp kan ook een medisch hulpmiddel zijn. De norm beschrijft de vereisten voor fabrikanten en bestrijkt de hele levenscyclus. Dit omvat ontwerp, ontwikkeling, validatie, installatie, onderhoud en verwijdering. Het toepassingsgebied is dus uitgebreider dan die van IEC 62304. De standaard beschrijft ook vereisten op hoger niveau die verder gaan dan pure softwareontwikkeling. Er is ook een herkenbare focus op beveiliging.

De norm beschrijft eerst een aantal vereisten voor gezondheids-apps:

  • vereisten voor risicobeheer (bijvoorbeeld met betrekking tot doel en gebruikersprofiel),
  • gebruikersvereisten (bijvoorbeeld met betrekking tot informatiebeveiliging en softwareondersteuning),
  • systeemvereisten (bijvoorbeeld in termen van interoperabiliteit en prestaties).

Dit wordt gevolgd door een analyse van het softwarelevenscyclusproces. Hier verwijst de norm rechtstreeks naar IEC 62304. Bovendien beschrijft IEC 82304-1 de validatie van gezondheidsapps en instrueert fabrikanten om bijbehorende begeleidende documenten te formuleren. De bijgevoegde documenten moeten de volgende inhoud bevatten:

  • gebruiksaanwijzing met beschrijving van de Health App
  • beveiligingswaarschuwingen
  • installatie gids
  • inschakel- en uitschakelprocedures
  • handleiding
  • meldingen
  • ontmanteling
  • technische beschrijving, bijvoorbeeld voor netwerkintegratie

Ten slotte beschrijft de norm de voorwaarden voor alle activiteiten van de fabrikant na het in de handel brengen van een gezondheids-app. Dit omvat uiteraard passend onderhoud en service van de software, evenals hervalidatie en geordende buitenbedrijfstelling aan het einde van de levenscyclus.

Gedefinieerde processen zijn ook belangrijk als het gaat om het documenteren van fouten of problemen en het informeren van de verantwoordelijke autoriteiten.

IEC 60601-1

Naast de twee hierboven genoemde normen, speelt de norm IEC 60601-1 ” Medische elektrische toestellen – Deel 1: Algemene eisen voor basisveiligheid en essentiële prestaties” een rol als centrale norm voor medische apparatuur. Hoofdstuk 14 gaat over “Programmeerbare elektrische medische systemen (PEMS)” en biedt het algemene kader voor een levenscyclusanalyse van medische software. Momenteel is een tweede versie van IEC 62304 in ontwikkeling. Het doel van deze normontwikkeling is het creëren van een uniform raamwerk voor alle softwaretypes.

Al met al kan onafhankelijke of hulpmiddel gerelateerde software worden onderscheiden, elk met een medisch of (alleen) gezondheid gerelateerd doel, elk werkend op een specifiek of algemeen hardware platform.

In hoofdstuk 14 vult IEC 60601-1 de bestaande vereisten voor het risicobeheerproces en de levenscyclusanalyse aan met de nodige aspecten van medische software (programmeerbare elektrische medische systemen, PEMS). Dit omvat toevoegingen aan de volgende PEMS-aspecten:

  • documentatie
  • risicobeheersplan
  • ontwikkelingslevenscyclus
  • probleem oplossing
  • risicobeheerproces
  • vereiste specificatie
  • architectuur
  • ontwerp en uitvoering
  • verificatie
  • bevestiging
  • wijziging
  • integratie in IT-netwerken

IEC 60601-1 stelt in bijlage H een model voor van een ontwikkelingslevenscyclus voor PEMS. Het model is gebaseerd op het gevestigde V-model voor softwareontwikkeling en is verdeeld in een ontledings- en een integratieproces. Beginnend met de gebruikersbehoeften, beschrijft het model verschillende softwarespecificatie en ontwikkelingsstappen in een gelaagde weergave, die vervolgens worden gecombineerd voor softwareverificatie en validatie. Het model bepaalt de afzonderlijke stappen met betrekking tot risicobeheer.

IEC 60601-1 breidt het risicobeheerproces uit met software specifieke aspecten, met name met betrekking tot gegevens, zoals

  • beschikbaarheid van data
  • data-integriteit
  • gegevensfout
  • data tijd toewijzing
  • dataveiligheid

De integratie van software in IT-netwerken vereist uiteraard speciale voorzorgsmaatregelen op het gebied van beveiliging en risicobeheer. IEC 60601-1 behandelt dit aspect expliciet. De norm vereist bijvoorbeeld dat het doel van de integratie, de kenmerken en de configuratie van het netwerk worden gedocumenteerd. Bovendien moet de distributeur de aandacht van de gebruiker vestigen op de risico’s die voortvloeien uit netwerkintegratie.

IEC 62366-1

IEC 62366-1 “Medische apparatuur – Deel 1: Aanbrengen van bruikbaarheid-engineering aan medische apparatuur” gaat over ergonomie en de interactie van de gebruiker met het hulpmiddel. Ergonomie moet worden overwogen voor elk medisch hulpmiddel (het is vergelijkbaar met IEC 60601-1-6, een andere bruikbaarheidsnorm voor medisch elektrische toestellen). Het implementeren van deze norm voor software vereist dezelfde methode als voor hardware hulpmiddelen. De goede praktijk van de software-industrie is het bijhouden van ergonomie-eisen met traceerbaarheidsmatrices tussen deze eisen en de ontwerpdocumenten, net als voor andere software-eisen.

Conclusie

Kortom, als u medische hulpmiddelen software ontwerpt, begin met IEC 62304, dat is de belangrijkste norm. Pas daarbij de algemene kwaliteitsmanagement en risicomanagementprincipes van ISO 13485 en ISO 14971 toe. Als u vertrouwd bent met IEC 62304, ga dan verder met IEC 60601-1 sectie 14 en eindig met IEC 62366. Als u kwaliteitsmanager bent, schakel dan de hulp in van een softwareprojectmanager om u uit te leggen wat er op het spel staat binnen IEC 62304 en andere normen.

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: