Op vrijdag 10 december jl. vond een webinar plaats met als onderwerp “Medical Device Regulation en Cybersecurity Act”.

In deze webinar legde Hans de Raad, eigenaar van OpenNovations en bestuurslid van DARQA, wat de nieuwe Medical Device Regulation (MDR) inhoudt en welk verbanden er tussen de MDR en de Cybersecurity Act (CSA) zijn. Zo hebben beide richtlijnen hetzelfde doel: generieke beschrijvingen voor software en hardware bieden (software requirements) zodat bedrijven aan de hand daarvan producten kunnen creëren zonder zelf het wiel opnieuw te hoeven uitvinden.

Dit is een vervolg van de webinar gehouden op 29 oktober 2021 en we nemen dan ook weer dezelfde ENISA en ETSI richtlijnen als uitgangspunt. Ook de ISPE heeft een aantal richtlijnen uitgegeven naast GAMP. Echter de richtlijen van ENISA en ETSI zijn beter bruikbaar.

De MDD, de voorganger van de MDR, was destijds nog relatief simpel en bestond vooral voor plastic producten met een CE markering. De MDR richt zich meer op “state of the art”: meer ingewikkelde producten met of zonder software of software als een medical device (SAMD); alle software waarmee een (medische) diagnose kan worden gesteld en/of een behandelplan kan worden opgesteld. Bij grensgevallen wordt aangeraden om toch maar alle maatregelen volgens de MDR uit te voeren want het kost vaak meer moeite om te beargumenteren waarom je dit niet hebt gedaan.  

Waar de MDD alleen op het product focuste, focust de MDR op het product in zijn functionele en operationele context, dus meer op interfaces tussen softwaresystemen en interacties met mensen. Life cycle management is daardoor belangrijker geworden waardoor er binnen een leverancier of organisatie ook een qualified person moet zijn die verantwoordelijk is voor de kwaliteit gedurende de hele levensloop van het product. De aangestelde qualified person kan niet zomaar de eerste de beste zijn maar moet hiervoor echt wel de benodigde achtergrond en kennis hebben.

Nieuw in de MDR is de Unique Device Identification (UDI) voor elk individueel device waardoor je de hele levensloop van een device, dus ook een software systeem, kunt volgen.

De in de MDR genoemde Notified Bodies zullen een grote rol gaan spelen en actief gaan inspecteren waarbij de prioriteit vooralsnog zal liggen bij systemen die direct met de patient en zijn veiligheid te maken hebben. Deze inspecties vinden al plaats sinds 2017.  

Het product moet regelmatig getest worden en de uitkomsten van die testen moet uiteraard gedocumenteerd worden. Als auditor kan je ook om die rapporten vragen, zowel bij de ontwikkelaar als bij de producent.

De hele MDR is erop gericht een product zo specifiek mogelijk te beschrijven om daarmee standardisering te bereiken. Dit geldt vooral voor softwaresystemen, die steeds worden geupdate waardoor ze na bijvoorbeeld 5 jaar niet meer lijken op wat ze in het begin waren. Hier zie je een duidelijke link met de Cybersecurity Act (CSA) en ook met ISO15408. Dit zijn standaarddefinities van veiligheidsnormen voor softwaresystemen en hoe deze te valideren, inclusief gestandaardiseerde testen. Daarbij is “fit for purpose” in de juiste omgeving een belangrijke factor, in samenhang met patientenveiligheid.     

Hoe zwaarder de klasse van je medical device hoe zwaarder de bewijslast, dus hoe belangrijker het is om het dossier steeds te actualiseren en er voor te zorgen dat je klinische evaluatierapporten up to date zijn. Daarbij komt dat voor oudere medical devices die eigenlijk vooral een mechanische tool waren tot nu toe min of meer oogluikend werd toegestaan dat zij ook voor medische doeleinden werden gebruikt, de zogenaamde “grandfather provision”. Dat mag en kan nu niet meer; een medical device en het gebruik daarvan moet goed gedocumenteerd zijn en van het gebruiksdoel mag niet afgeweken worden.

De leverancier moet door verdergaande standaardisering dus aandacht besteden aan het QMS (afhankelijk van de norm die gehanteerd wordt), de technische documentatie (het V-model), klinische onderzoeken inclusief post market surveillance (farmacovigilantie), fysieke testen (bijvoorbeeld volgens IEC 60601-1), functionele veiligheid (bijvoorbeeld door bewust “foutieve” testdata te gebruiken) en cybersecurity.

De overeenkomsten tussen de MDR en de CSA zijn duidelijk te zien in de MDCG 2019-16, de Guidance on Cybersecurity for Medical Devices. In de MDR Annex 1 wordt nog verder ingegaan op cybersecurity met bijvoorbeeld het ontwikkelen van life cycle management (de hele levensloop van het medical device documenteren en up to date houden tot het moment dat het device niet meer gebruikt wordt), risico management, beveiligen van informatie en de verificatie en validatie daarvan.

Belangrijk component van cybersecurity is de operationele veiligheid; de omgeving waarin en het doel waarvoor het softwaresysteem wordt gebruikt. Dat geldt zowel voor de producent als de ontwikkelaar/gebruiker. Zo kan er bijvoorbeeld gebruik worden gemaakt van zogenaamde dummy data voor trainingsdoeleinden. Het zal je nog verbazen hoe vaak er “gewoon” bestaande data gebruikt wordt voor trainingen waardoor die data dus oneigenlijk gebruikt wordt en een datalek een reële mogelijkheid wordt.

Het vaststellen van een voldoende niveau van cybersecurity kan en moet door middel van allerlei soorten testen als onderdeel van je validatie en kwalificatie. Echter, niet altijd alles kan worden afgedekt, vooral niet wanneer het zogenaamde “malware” betreft die al in het programma is ingebed nog voordat je het daadwerkelijk gaat gebruiken. Daarom is het belangrijk dat je met je IT-afdeling overlegt over hoe en wat, zodat eventuele problemen zo snel mogelijk gevonden worden en er adequate actie kan worden ondernomen om de mogelijke schade zoveel mogelijk te beperken. Datzelfde geldt voor datastromen: het is mooi als data zoveel mogelijk versleuteld verzonden wordt, maar voorkom dat dat ertoe leidt dat ook de eigen systemen de data niet meer herkennen en dus niet ingrijpen op het moment dat er iets loos is met die data.

Het is dus belangrijk om bij de leverancier van het product om achtergrond/ontwikkel-informatie – en documentatie (inclusief training) te vragen en die ook kritisch te bekijken en te bevragen.

Goede beveiliging begint bij het ontdekken van mogelijke beveiligingslekken; als je weet waar het mis gaat weet je wat je er tegen kunt doen. Daarbij is het ook belangrijk dat je weet welke autorisaties gebruikers van een systeem hebben c.q. welke rollen er binnen een systeem zijn en hoe die zijn begrensd. Regelmatige training in cybersecurity om bewustzijn te creëren en te behouden is ook essentieel. Zorg ook voor back up systemen voor het geval het toch ergens mis gaat.

Aan dit webinar werd deelgenomen door 15 mensen. Mensen die nog vragen hebben of feedback willen leveren op dit webinar of die ideeën hebben voor volgende webinars kunnen dat laten weten via een email naar Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken..

De video gemaakt tijdens deze webinar is op het ledengedeelte van deze website te bekijken via deze link.