Inhoudsopgave

Waar moet ik aan denken als ik zelf software wil ontwikkelen?

Praktijkvraag 1

Waar moet ik aan denken als ik zelf software wil ontwikkelen?

Het ontwikkelen van medische software/app is een vak waarbij je onder andere ervaren ontwikkelaars, projectleiders en architecten nodig hebt. het is sterk ad te raden zelf te ontwikkelen als deze kennis en ervaring niet in huis is.

Europese Wetgeving (MDR en MDD)

In mei 2017 is de nieuwe Europese Medical Device Regulation (MDR) gepubliceerd. Deze vervangt de Medical Devices Directive (MDD). Tot 26 mei 2020 geldt een overgangsperiode waarin leveranciers medische hulpmiddelen mogen laten registreren volgens beide regelingen. Vanaf 26 mei 2020 moeten medische hulpmiddelen voldoen aan de nieuwe regels om toegelaten te worden tot de Europese markt. Hulpmiddelen die vóór 26 mei 2020 gecertificeerd zijn mogen uiterlijk tot 26 mei 2025 op de markt worden gebracht of in gebruik worden genomen.

In de MDD wordt het ‘in huis’ ontwikkelen van medische hulpmiddelen door zorginstellingen niet expliciet genoemd. Onder deze regelgeving is het dus onduidelijk waaraan zelfontwikkelde software moet voldoen. Dit is anders in de nieuwe MDR. Hierin wordt wel expliciet aandacht besteed aan het ‘in huis’ ontwikkelen van medische hulpmiddelen door zorginstellingen.

Een zorginstelling heeft tot 26 mei 2020 formeel de mogelijkheid om zelfontwikkelde software in gebruik te nemen die niet aan de eisen van de nieuwe MDR voldoet. Nieuwere versies van deze software, die na deze datum in gebruik genomen worden, zullen echter wel aan deze nieuwe regelgeving moeten voldoen. Meer informatie over wetten, normen en richtlijnen staat in Praktijkvraag 13.

'In huis' ontwikkelen - artikel 5 van MDR

 In het tweede hoofdstuk van de MDR is artikel 5 gewijd aan het op de markt brengen en in gebruik nemen van medische hulpmiddelen.

De paragrafen 4 en 5 beschrijven waaraan ‘in huis’ ontwikkelde medische hulpmiddelen wel en niet moeten voldoen. Met uitzondering van de relevante general safety and performance requirements (GSPR) uit Annex 1 hoeft verder niet aan de in de MDR gestelde eisen voldaan te worden, mits aan een aantal voorwaarden voldaan wordt.

 

Deze voorwaarden zijn:

  • a) De medische hulpmiddelen worden niet gedeeld met andere juridische entiteiten.
  • b) Het ontwikkelen en gebruiken van de hulpmiddelen gebeurt onder geschikte kwaliteitsmanagementsystemen.
  • c) De zorginstelling rechtvaardigt in de documentatie dat aan de specifieke eisen voor de patiëntendoelgroep niet voldaan wordt door equivalente op de markt verkrijgbare hulpmiddelen.
  • d) De zorginstelling verschaft op verzoek informatie aan de autoriteiten over het gebruik van dergelijke hulpmiddelen, inclusief een rechtvaardiging voor het ontwikkelen, modificeren en gebruik hiervan.
  • e) De zorginstelling maakt publiekelijk een verklaring waarin duidelijk staat welke hulpmiddelen ‘in huis’ ontwikkeld zijn en hoe deze te herkennen zijn. De instelling verklaart ook dat deze hulpmiddelen voldoen aan de relevante general safety and performance requirements (GSPR) uit Annex 1. Als hier niet helemaal aan voldaan wordt, bevat de verklaring een rechtvaardiging hiervoor.
  • f) De zorginstelling documenteert de structuur van de ontwikkelafdeling, het ontwikkelproces, het ontwerp en de prestaties van de hulpmiddelen, inclusief het beoogd gebruik. Deze documentatie moet gedetailleerd genoeg zijn om het voor de autoriteiten mogelijk te maken om vast te stellen dat aan de general safety and performance requirements uit Annex 1 wordt voldaan.
  • g) De zorginstelling zorgt ervoor dat alle hulpmiddelen worden ontwikkeld in overeenstemming met hetgeen onder f) gedocumenteerd is.
  • h) De zorginstelling evalueert het klinisch gebruik van de hulpmiddelen en neemt indien nodig (correctieve) maatregelen.

Algemene veiligheids- en prestatievereisten: Annex 1 MDR

In Annex 1 van de MDR staan de general safety and performance requirements verspreid over 23 paragrafen. Zelfontwikkelde hulpmiddelen moeten aan deze eisen voldoen. Voor software zijn lang niet alle paragrafen relevant, zoals paragrafen met eisen over verpakkingen en transport, sterilisatie of het gebruik van chemicaliën.

De eisen die wel relevant zijn voor zelfontwikkelde software bespreken we hieronder kort. Zoals onder voorwaarde f) hierboven vermeld is, moet de documentatie van de zelfontwikkelde software duidelijk maken dat aan deze eisen wordt voldaan.

 

Prestaties en veiligheid (GSPR1)

De eerste eis is een algemene eis. Het medisch hulpmiddel moet correct en veilig functioneren en onder normale omstandigheden geschikt zijn voor de intended use.

 

Risicomanagement (GSPR2 t/m 5, GSPR8)

Deze eisen gaan in op verschillende aspecten van risicomanagement. Risico’s moeten geminimaliseerd worden en gewogen tegen de voordelen. Hiervoor moet een systeem voor risicomanagement opgezet worden, waarin dit proces gedocumenteerd wordt. Risicomitigerende maatregelen worden genomen en de gebruikers worden geïnformeerd over eventuele restrisico’s. Er wordt ontworpen voor patiëntveiligheid en rekening gehouden met de kennis en ervaring van de gebruikers.

 

Interactie met de omgeving (GSPR14)

Als een hulpmiddel bedoeld is om te gebruiken in combinatie met andere hulpmiddelen dan moet de hele combinatie veilig zijn. In het ontwerp moeten risico’s die voortkomen uit een mogelijke negatieve interactie tussen software en de IT-omgeving waarin deze opereert geminimaliseerd worden.

 

Elektrisch programmeerbare systemen (GSPR17)

Hulpmiddelen die software bevatten of alleen uit software bestaan moeten zo ontworpen worden dat zij herhaalbaar en betrouwbaar gebruikt kunnen worden voor hun intended use. Een enkele fout, in het systeem of omgeving, mag niet leiden tot gebrekkig functioneren of risico’s. Deze situaties moeten netjes afgehandeld worden. Hulpmiddelen die software bevatten of alleen uit software bestaan moeten ontwikkeld worden op basis van de laatste stand van de techniek op het gebied van ontwikkelprocessen, risicomanagement, informatiebeveiliging, verificatie en validatie.

Als software bedoeld is om gebruikt te worden op mobiele apparaten dan moeten specifieke kenmerken van het apparaat, zoals grootte van het scherm, in het ontwerpproces meegenomen worden.

De ontwikkelaar stelt minimumeisen op voor hardware, IT-netwerken en beveiligingsmaatregelen, die nodig zijn om de software zoals bedoeld te kunnen gebruiken.

 

GSPR23 Gebruiksaanwijzing

In de gebruiksaanwijzing moet in ieder geval worden opgenomen:

  • hoe de software gebruikt moet worden;
  • alle zaken die van belang zijn voor een juist functioneren;
  • alles wat voor de veiligheid van de gebruiker en anderen van belang kan zijn;
  • de hierboven genoemde minimumeisen voor hardware, netwerken, et cetera.

 

Voor hulpmiddelen in klasse 1 en 2a mag de gebruiksaanwijzing achterwege blijven als deze hulpmiddelen veilig zonder gebruiksaanwijzing te gebruiken zijn.

Internationale normen en harmonisatie door de EU

In het voorgaande werd duidelijk dat de EU eisen stelt als zorginstellingen zelf medische software willen ontwikkelen. Kort samengevat zijn dit eisen op het gebied van:

  • kwaliteitsmanagementsysteem;
  • risicomanagement;
  • ontwikkelprocessen en
  • productveiligheid.

 

Internationale organisaties zoals de ISO (International Organisation for Standardization) en de IEC (International Electrical Commission) hebben over deze onderwerpen de afgelopen jaren normen gepubliceerd, zie tabel 4.1.1. Een aantal van deze normen is door de EU geharmoniseerd. Dit betekent dat wanneer men kan aantonen dat aan deze normen wordt voldaan, verondersteld wordt dat aan de gestelde eisen voor dat specifieke onderwerp wordt voldaan.

Geharmoniseerde normen zijn normen die door de Europese Commissie zijn gemandateerd. De betreffende norm krijgt dan de toevoeging EN en in Nederland de toevoeging NEN-EN. Om een kwaliteitsmanagementsysteem en risicomanagement op te zetten kunnen dus beide door de EU geharmoniseerde normen ISO 13485 en ISO 14971 gebruikt worden. Ook IEC 62304 is door de EU geharmoniseerd en deze norm kan dus prima gebruikt worden als blauwdruk voor de op te zetten en te beschrijven ontwikkelprocessen. De IEC 82304-1 norm is pas vrij recent gepubliceerd en nog niet door de EU geharmoniseerd. De verwachting is dat dit in de toekomst wel gaat gebeuren.

Tabel 4.1.1Internationale normen medische software

Softwareontwikkelproces volgens IEC 62304

In de IEC 62304 worden processen voor de levenscyclus van medische software beschreven. Het ontwikkelproces bestaat uit acht processen, zie figuur 4.1.1. Deze processen staan ook vermeld in tabel 4.1.2. Niet alle processen moeten voor alle software doorlopen worden. Het wel of niet verplicht zijn van een proces hangt af van de risicoclassificatie van de software die ontwikkeld wordt.

In IEC 62304 worden drie klassen gehanteerd:

 

Klasse A - als de software geen schade aan de gezondheid kan veroorzaken.

Klasse B - als de software geringe schade aan de gezondheid kan veroorzaken.

Klasse C - als de software serieuze schade aan de gezondheid of zelfs de dood kan veroorzaken.

 

Risicomanagement is een integraal onderdeel van IEC 62304. Dit betekent dat in elk proces van de levenscyclus gekeken moet worden of er nieuwe risico’s geïdentificeerd kunnen worden op basis van de resultaten van het vorige proces. Voor deze risico’s moeten mitigerende maatregelen getroffen worden.

 

Ontwikkelplan

Het eerste proces van de levenscyclus is het opstellen van een ontwikkelplan. Dit ontwikkelplan beschrijft alle uit te voeren activiteiten en op te leveren producten in de levenscyclus, passend bij de omvang en classificatie van het systeem. Ook configuratieprocedures en changemanagementprocedures worden in het plan beschreven. Dit plan verwijst verder naar de gebruikte ontwikkelingsstandaarden, -methoden en tools en plannen voor de overige processen. Het ontwikkelplan moet gedurende het hele project actueel gehouden worden.

 

Software-requirementanalyse

In dit proces worden de eisen die aan de software worden gesteld gedefinieerd en gedocumenteerd, eventueel op basis van de systeemeisen als de software deel uit maakt van een groter systeem. Hierin worden in ieder geval functionele en nietfunctionele eisen meegenomen, evenals inen uitvoer, interfaces met andere systemen, alarmen, waarschuwingen en berichten voor de gebruiker. Verder is het van belang dat risicomitigerende maatregelen die in software geïmplementeerd moeten worden, opgenomen worden als eis. De requirements moeten duidelijk geformuleerd worden en elkaar niet tegenspreken. Ze moeten eenduidig identificeerbaar, testbaar en tot de bron traceerbaar zijn.

 

Software-architectuurontwerp

Op basis van de software-requirements wordt in dit proces een software-architectuur ontworpen. Deze architectuur beschrijft de structuur van de software en identificeert de verschillende softwareonderdelen. Daarbij hoort een beschrijving van de interfaces tussen de softwareonderdelen. Als besloten wordt softwareonderdelen te gebruiken van andere komaf (SOUP: Software of Unknown Provenance), dan worden in deze stap de functionele en niet-functionele eisen opgesteld waaraan deze SOUP moet voldoen. Voor systemen in klasse C moet in het kader van risicomanagement in deze fase bekeken worden welke onderdelen gesegregeerd moeten worden. Gesegregeerd betekent in deze context: onafhankelijk van de overige onderdelen, dus bijvoorbeeld draaiend op een eigen processor.

 

Software detailed design

De software wordt in onderdelen (units) verdeeld. Als het een systeem in klasse C is dan wordt voor al deze units een gedetailleerd ontwerp gemaakt. In deze ontwerpen worden ook de interfaces tussen de units onderling en andere systemen beschreven. Ook moet worden geverifieerd of het gedetailleerd ontwerp de architectuur correct implementeert.

 

Software unit implementation

De units worden geprogrammeerd. De validatieprocedure van een enkele unit is afhankelijk van zijn risicoclassificatie. Om een unit samen te voegen met de rest van de code wordt gehandeld volgens het van tevoren opgezette acceptatieplan met bijbehorende criteria. De resultaten van het acceptatieplan worden gedocumenteerd.

 

Software integration and integration testing

De geïntegreerde software-items worden volgens het integratieplan getest en gedocumenteerd. Met regressietesten, het testen van al aanwezige functionaliteit, wordt aangetoond dat er geen nieuwe problemen zijn. Gecontroleerd wordt onder meer op functionaliteit, afvangen of beheersen van risico’s en verkeerd gebruik. De software-integratie- en systeemtesten mogen gecombineerd worden.

 

Software system testing

Voor het gehele systeem wordt de werking gecontroleerd aan de hand van een verzameling tests, die alle functionaliteiten dekt. Goede uitgangspunten om deze testset samen te stellen zijn de requirements voor het systeem. Voor iedere test wordt de input, verwachte uitkomst, pass/fail criteria, uitvoerend persoon en procedures gedocumenteerd. De documentatie bevat ook de versie van de software die getest is, evenals relevante harden softwareconfiguraties tijdens het testen, gebruikte test tools en de datum van de testen.

 

Software release

Alvorens de software vrij te geven is het van belang dat men zich ervan verzekert dat alle testactiviteiten zijn uitgevoerd en wat de resultaten hiervan zijn. Eventuele afwijkingen die nog in de versie zitten, worden beoordeeld op hun risico. Het moet duidelijk zijn welke versie vrij wordt gegeven en gebruikers moeten weten welke versie zij mogen gebruiken.

Figuur 4.1.1 Software-ontwikkelprocessen volgens IEC 62304

Tabel 4.1.2IEC 62304 software ontwikkelprocessen

Aandachtspunten

Ten slotte nog een aantal zaken die in het voorgaande niet echt aan bod zijn gekomen en specifiek van belang zijn voor zorginstellingen.

 

Is scripten programmeren?

De Europese wetgeving en ook de internationale normen maken geen onderscheid tussen gebruikte programmeertalen. De gebruikte programmeertaal bepaalt dus niet of er wel of niet aan regelgeving voldaan moet worden. Dit wordt bepaald door de aard van de toepassing. Alleen als een medisch hulpmiddel, met CE-markering, de mogelijkheid biedt functionaliteit aan te passen of toe te voegen via scripts of business logica, en de leverancier staat dit toe voor klinisch gebruik (intended use) kan er beargumenteerd worden dat voor deze scripts of business logica niet apart aan de regelgeving voldaan hoeft te worden. De ontwikkelde scripts of business logica vallen in dit geval onder de originele CE markering van de fabrikant.

De zorginstelling blijft natuurlijk wel (mede) verantwoordelijk voor veilig gebruik van het medisch hulpmiddel en dus een veilig ontwikkelproces voor deze scripts.

 

Is configureren programmeren?

Nee, configureren is geen programmeren. Wanneer een leverancier configuratiemogelijkheden inbouwt voor de eindgebruiker (intended use) moet hij ervoor zorgen dat deze mogelijkheden veilig gebruikt kunnen worden.

 

Is een Excelsheet software?

De gebruikte programmeertaal bepaalt niet of er wel of niet aan regelgeving voldaan moet worden. Dit wordt bepaald door de aard van de toepassing. Het zou vreemd zijn als een dosisberekening voor Total Body Irradiation geschreven in Excel niet en geschreven in C++ wel aan regelgeving moet voldoen.

 

Scheiding van rollen

Wanneer in een zorginstelling zelfgeschreven software gebruikt wordt, kan gemakkelijk de situatie ontstaan dat één persoon meerdere rollen heeft, waaronder die van eindgebruiker. Zeker wanneer de persoon die betrokken is bij de ontwikkeling van software, ook de enige gebruiker van deze software is, is het aan te bevelen om een extra persoon te laten toezien op het testen en naleven van de regelgeving.