In dit artikel laten we zien hoe de Medical Imaging Quantification Center bewezen wetenschappelijk onderzoek in de klinische praktijk brengt, geïllustreerd aan de hand van een recent voorbeeld waarvan we de nodige stappen, ervaringen en handige tips presenteren. De casus die wordt gepresenteerd is de implementatie van een nieuwe 4D flow Magnetic Resonance Imaging techniek voor gebruik in de klinische praktijk.
Invoering
De implementatie van klinische innovaties van wetenschappelijk artikel naar routinematige klinische praktijk of product omvat vele stappen, waaronder bescherming van intellectueel eigendom, demonstratie van proof of concept, validatie, opschaling naar klinisch onderzoek, realisatie van ondersteuning en vergoeding, en distributie. Onderzoekers zijn meestal niet in staat al deze stappen alleen uit te voeren. Ideeën kunnen worden opgepakt door een commerciële partij, die over de middelen, expertise en ervaring beschikt om deze route met succes te volgen. Vanwege de complexiteit van dit proces zullen veel goede ideeën echter niet hun weg vinden naar klinische praktijk.
Wij zijn van mening dat de academische wereld door een goede organisatie beter zou kunnen worden uitgerust en georganiseerd om de implementatie in de klinische praktijk van nieuwe klinische protocollen en technologie te stroomlijnen. Om deze reden is in 2016 het Medical Imaging Quantification Center (MIQC) opgericht in het Amsterdam UMC. Het hoofddoel van MIQC is om zelf-ontwikkelde kwantitatieve beeldvormingstechnieken te implementeren in de klinische praktijk, waarmee de kloof tussen wetenschappelijk onderzoek en klinische praktijk snel wordt overbrugd.
In dit artikel laten we zien hoe MIQC bewezen wetenschappelijk onderzoek in de klinische praktijk brengt, geïllustreerd aan de hand van een recent voorbeeld waarvan we de nodige stappen, ervaringen en handige tips presenteren. De casus die wordt gepresenteerd is de implementatie van een nieuwe 4D flow Magnetic Resonance Imaging (MRI) techniek voor gebruik in de klinische praktijk.
Bij patiënten met (structurele) hartziekten is het gebruik van MRI belangrijk voor diagnose, risico-evaluatie en lange-termijn follow-up. 4D flow MRI is een nieuwe MRI-techniek die de bloedstroom meet in drie loodrechte richtingen (3D) als functie van de tijd (4D) – zeg maar een video van de bloedstroom over de hartslag. De resulterende stroompatronen van de bloedstroom door het hart en de grote bloedvaten worden gevisualiseerd en gekwantificeerd, hetgeen waardevolle informatie oplevert die de besluitvorming ondersteunt. Standaard 4D flow MRI-scans kunnen tot 20 minuten of langer duren en zijn niet geschikt voor klinisch gebruik. Daarom is in het Amsterdam UMC een 4D flow MRI-versnellingstechniek ontwikkeld om scantijden te realiseren die geschikt zijn voor klinisch gebruik (onder 10 minuten). Omdat er bij cardiologen en radiologen vraag was naar snelle 4D flow MRI in de patiëntenzorg ter ondersteuning van de besluitvorming, heeft MIQC de kloof tussen onderzoek en klinische praktijk overbrugd. Inmiddels worden patiënten met (structurele) hartziekten regelmatig gescand met de nieuwe 4D flow MRI-sequentie als toevoeging op het standaard klinische onderzoek.
Projectvoorwaarden
First Things First: kwalificatie voor implementatie
Alvorens in te gaan op de implementatie eisen waaraan moet worden voldaan, is het belangrijk om te beoordelen of het project überhaupt in aanmerking komt voor implementatie in de patiëntenzorg. Het lijkt misschien voor de hand liggend, maar de functionaliteit behoort gevalideerd te zijn en er behoort een beoogd voordeel voor de patiënt te hebben. Bovendien kan het kosten-batenaspect al in overweging worden genomen – niet alleen de kosten van het toekomstige idee in de praktijk, maar ook: is het de moeite waard om het idee te implementeren ten opzichte van het verwachte voordeel? Als aan deze belangrijkste criteria is voldaan, kan “het dichten van de kloof tussen onderzoek en klinische praktijk” worden ingepland.
In ons geval werd de snelle 4D flow MRI-technologie grondig gevalideerd voor wat betreft de meetnauwkeurigheid van de bloedstroom en gepubliceerd in meerdere peer-reviewed artikelen. De meerwaarde (voornamelijk scantijdverkorting) werd ook aangetoond in pilotstudies. Gebaseerd op de huidige literatuur over 4D flow in het algemeen, is 4D flow een aantrekkelijk alternatief voor meerdere 2D flow acquisities, vooral voor het kwantificeren van de bloedstroom bij de hartkleppen en in een complexe hartanatomie zoals bij patiënten met structurele hartziekte. Bovendien opent 4D flow de weg naar veelbelovende nieuwe nabewerkingsmogelijkheden die zouden kunnen bijdragen aan de diagnose en de prognose van de patiënt. De toegevoegde waarde en de kosten-batenverhouding van klinisch geïmplementeerde 4D flow moeten voor specifieke indicaties echter nog worden bepaald. Naar onze verwachting weegt het voordeel van onze implementatie zwaarder dan de inspanning en daarom hebben we de implementatie in gang gezet.
De beoogde “kloof-dichten”: Europese Verordening Medische Hulpmiddelen
De voorschriften rondom het gebruik van alle verschillende soorten medische hulpmiddelen voor patiëntenzorg zijn momenteel vastgelegd in de Europese Richtlijn Medische Hulpmiddelen (MDD) [1], die op 26 mei 2021 wordt vervangen door de daaropvolgende Europese Verordening Medische Hulpmiddelen (MDR) [2]. Deze voorschriften hebben betrekking op alle aspecten van medische hulpmiddelen (software, hardware, enz.) en accessoires voor gebruik bij mensen, en leggen in detail uit wat nodig is om een medisch hulpmiddel op de markt te brengen voor patiëntenzorg. Een bijbehorende eis voor medische hulpmiddelen is de CE-markering, die een (te) hoog obstakel kan lijken. In de MDR is echter het volgende een specifiek aspect opgenomen: “Zorginstellingen moeten de mogelijkheid hebben hulpmiddelen intern te vervaardigen, aan te passen en te gebruiken, om, weliswaar op een niet-industriële schaal, tegemoet te komen aan de specifieke behoeften van patiënten doelgroepen waaraan niet op een passend prestatieniveau kan worden voldaan door een gelijkwaardig hulpmiddel dat op de markt beschikbaar is.” (MDR [2] “Overwegende”, punt 30). Deze doelstelling in de MDR om een medisch hulpmiddel zonder CE-markering te gebruiken, wordt nader toegelicht in artikel 5.5. De belangrijkste punten zijn dat het medische hulpmiddel of de techniek in eigen huis ontwikkeld wordt en uitsluitend in hetzelfde ziekenhuis (of instituut) gebruikt wordt. Ook moet documentatie, te verzamelen in een vrijgavedossier, worden aangemaakt, waaronder: 1) een verklaring dat er geen gelijkwaardig alternatief op de markt is, 2) een veiligheidstestrapport, 3) een verwijzing naar gevalideerde klinische meerwaarde, 4) een prospectieve risico-inventarisatie, 5) een gebruikershandleiding en 6) een verklaring over de “algemene veiligheids- en prestatie-eisen” van bijlage I van de MDR [2]. Ten derde moeten de fabricage en het gebruik plaatsvinden onder een passend kwaliteitsmanagementsysteem. Dit kan worden geïmplementeerd door een lokaal kwaliteitsmanagementsysteem van de afdeling of door een algemeen kwaliteitsmanagementsysteem van de instelling. Tenslotte is een interne “Post Market Surveillance” (PMS) vereist om de ervaring die is opgedaan bij het klinisch gebruik van de hulpmiddelen te beoordelen en de nodige corrigerende maatregelen te nemen.
In ons geval hadden de meeste stappen of medische hulpmiddelen die in ons proces werden gebruikt al een CE-markering, waaronder de MRI-scanner (hardware en software) en het Picture Archiving and Communication System (PACS). In onze instelling moeten zelf-ontwikkelde medische hulpmiddelen inclusief software samen met het vrijgavedossier worden goedgekeurd door een certificatiemanager, werkzaam bij Service Bureau & Instrumentatie, dat een ISO 9001-accreditatie heeft. Alle andere benodigde punten werden stap voor stap doorlopen en worden hieronder toegelicht.
Spelen volgens de regels: voorschriften en ethiek
Zoals eerder vermeld, is het belangrijkste document de MDR, waarin de regels zijn vastgelegd waaraan we moeten voldoen en die het lezen waard is. Vooral de artikelen 2 en 5 en de bijlages I en VIII zijn een goed begin. Artikel 2 specificeert of definieert de termen die in de MDR worden gebruikt, zoals “medisch hulpmiddel”, “beoogd doeleinde”, “op de markt brengen”, “zorginstelling” en “fabrikant”. [2] In artikel 5 staat de crux van “Op de markt brengen en in gebruik nemen” inclusief de bijzondere uitzondering voor het gebruik van medische hulpmiddelen zonder CE-markering door zorginstellingen. Er moet echter altijd aan algemene veiligheidsaspecten worden voldaan, en deze worden nader toegelicht in de bijlagen, met name bijlage I. Ook kunnen de “Classificatieregels” in bijlage VIII van bijzonder belang zijn, aangezien deze inzicht geven in welke regels en voorschriften mogelijk van toepassing zijn op je software of apparaat. [2]
Wetgevende teksten lezen is niet het meest aansprekende werk voor niet-juristen, maar je kunt er niet omheen, want het is te belangrijk. Het moet worden gelezen en begrepen. Verdwaal daarom niet in het doolhof van kruisverwijzingen, maar laat ook geen hele hoofdstukken weg met de gedachte dat “staat opgesomd in bijlage …” overgeslagen kan worden.
Sinds 25 mei 2018 is de Europese Algemene Verordening Gegevensbescherming (AVG) [3] van toepassing. Dit is een andere belangrijke wettekst om op te letten. In het dagelijks leven is de AVG vooral merkbaar door meldingen over cookies op elke website, maar de belangrijkste drijfveer van de AVG is het beschermen van persoonsgegevens. Patiënten hebben het recht dat hun medische gegevens vertrouwelijk worden behandeld en je moet daarvoor zorgen, want elke ontduiking van de wet kan worden bestraft. In 2019 kreeg een Nederlands ziekenhuis een boete van € 460.000 opgelegd door de Nederlandse Autoriteit Persoonsgegevens vanwege onvoldoende interne beveiliging van patiëntendossiers, omdat ziekenhuispersoneel ongeautoriseerde toegang had tot de medische dossiers van een publiek persoon. Dit voorbeeld geeft het belang aan van gegevensbescherming en de mogelijke gevolgen voor ziekenhuizen of andere soortgelijke instellingen. Het beste advies is dus om de patiëntgegevens zo goed mogelijk te beveiligen, wat natuurlijk makkelijker gezegd is dan gedaan. We willen hier de artikelen 24, 25 en 32 van de AVG benadrukken: “Verantwoordelijkheid van de verwerkingsverantwoordelijke”, “Gegevensbescherming door ontwerp en door standaardinstellingen” en “Beveiliging van de verwerking”. [3] Neem bij twijfel contact op met uw plaatselijke deskundige op het gebied van informatiebeveiliging en privacybescherming om geen fouten te maken of zelfs de kans te lopen vervolgd te worden.
Als data ook voor onderzoek worden gebruikt, is een ander belangrijk aspect dat gerespecteerd moet worden de ethiek van de wetenschap. Wanneer je met gevoelige patiëntgegevens werkt, moet je zorgen voor een goede wetenschappelijke manier van werken en beveiliging. In Nederland is de Wet Medisch-wetenschappelijk Onderzoek met mensen (WMO) ingevoerd om deelnemers aan medisch-wetenschappelijk onderzoek te beschermen. [4] Daarom moet de implementatie van een wetenschappelijk idee op een solide basis staan en zou het een slecht idee zijn om te beginnen voordat dat is toegestaan. Vraag eerst een ethische goedkeuring of een waiver van uw plaatselijke medische ethische toetsingscommissie (METC) voordat u met gevoelige patiëntgegevens gaat werken.
In ons geval hebben we zowel de MDR als de AVG bestudeerd om er zeker van te zijn dat we aan de regelgeving voldeden. Bovendien hadden we nauw contact met onze ziekenhuis experts op het gebied van informatiebeveiliging en privacybescherming, evenals met ICT-experts. Ook werd voor ons project een waiver (of niet-WMO verklaring) afgegeven door de lokale METC, omdat alleen pro- en retrospectieve gegevens worden verzameld en verwerkt, en de proefpersonen niet worden onderworpen aan acties of specifiek gedrag van hen wordt verlangd.
Project uitvoering
De kern: processtructuur en risico-evaluatie
Om te beginnen moet er altijd een plan zijn. Denk goed na over alle noodzakelijke stappen, de betrokken mensen en de benodigde infrastructuur, evenals kritieke interactiepunten zoals gegevensoverdracht. Als dit plan eenmaal is gemaakt, breng je alle betrokken partijen, zoals onderzoekers, laboranten, artsen, IT-ondersteuners en projectleiders, samen aan één tafel en bespreek je mogelijke bronnen van storingen, knelpunten en andere fouten. Werk in een protocol het plan uit evenals de kritische vragen en verbeterpunten en maak een risicoanalyseoverzicht.
In ons geval heeft de MIQC-groep het project geïnitieerd en gecoördineerd. Samen met alle betrokken partijen kwam de MIQC-groep regelmatig bijeen en stelde een prospectieve risico-inventarisatie (risicoanalyseoverzicht) op met alle processtappen en het bijbehorende risico. De processen variëren van het starten van de MRI-scanner en het verwelkomen van de patiënt tot het analyseren van de 4D flow-gegevens in speciale software (zie figuur 2), en uiteindelijk de laatste gegevensexport en langdurige opslag. Alle genoemde risico’s zijn gecategoriseerd in een risicomatrix op basis van de frequentie waarmee fouten kunnen optreden en de impact die deze fout zou hebben. Als een bepaald risico als te hoog wordt beschouwd, wordt besproken hoe deze foutbron kan worden omzeild, verholpen of beheerst. Bovendien worden bij elk risico de verantwoordelijke persoon, open vragen en opmerkingen genoteerd, zodat de voortgang van elke risicobeheersing goed wordt gedocumenteerd en elke verbeterstap kan worden getraceerd. De prospectieve risico-inventarisatie wordt na elke vergadering bijgewerkt en het project mag pas worden gestart nadat alle risico-items zijn gecategoriseerd als laag of zeer laag. Onze prospectieve risico-inventarisatie bevat ongeveer 66 vermeldingen in 14 processtappen. Een voorbeeld van een prospectieve risico-inventarisatie is hier te vinden. [5]
Rome is niet in één dag gebouwd: de tijdlijn
Het integreren van een wetenschappelijk idee in de klinische praktijk is niet gemakkelijk en gaat ook niet snel. Goede dingen hebben tijd nodig. Voor maximaal succes moeten alle mogelijke risico’s grondig worden overwogen, moeten de voorschriften volledig worden nageleefd en moeten alle processen goed worden geïmplementeerd. Veiligheid, beveiliging en risicobeheer komen ten koste van alles op de eerste plaats en mogen niet worden beïnvloed door tijdsdruk. Omdat het opzetten van een dergelijk project een iteratief proces is waarbij veel verschillende mensen en partijen betrokken zijn, moet de tijdlijn vrij royaal worden gepland.
In ons geval kwam het idee om nieuwe 4D flow sequenties voor de kliniek te implementeren voor het eerst naar voren in 2017, in juli 2018 begon het implementatieproces en de geïmplementeerde technologie is live gegaan in november 2019. Een goede tijdlijn om mee te beginnen zou een volledig jaar zijn.
AVG in de praktijk: beveiliging en privacy
Volgens de AVG heeft de verwerkingsverantwoordelijke de verantwoordelijkheid om passende technische en organisatorische maatregelen te nemen om gegevensbescherming en veilige gegevensverwerking te waarborgen. Bovendien worden die maatregelen herzien en waar nodig geactualiseerd (AVG [3], artikel 24). Maar wat betekent passend? De AVG beschouwt het ontwerp van gegevensbescherming in relatie tot het risico. Je moet dus rekening houden met de state-of-the-art technische mogelijkheden, de implementatiekosten en de risico’s van verschillende waarschijnlijkheid en ernst voor de rechten van patiënten die voortvloeien uit de gegevensverwerking. Passend betekent ook dat de genomen beveiligingsmaatregelen in verhouding staan tot het aantal gevallen of patiënten. Kleine knelpunten in het werkproces kunnen worden getolereerd voor een klein aantal gevallen, zoals 5 patiënten per week (laag risico), maar zouden ernstiger wegen als dit aantal zou toenemen tot bijvoorbeeld 100 patiënten per week. De gegevensverwerking of -export moet minimaal, veilig en geanonimiseerd (of gepseudonimiseerd) zijn (AVG [3] artikel 25). Belangrijke beveiligingsaspecten zijn onder meer pseudonimisering en versleuteling van gevoelige informatie, beperking van ongeoorloofde toegang, de mogelijkheid om gegevens te herstellen in geval van onbedoeld verlies van gegevens en het regelmatig testen van alle verwerkingsstappen (AVG [3] artikel 32).
In ons geval, om een nieuwe MRI-sequentie toe te voegen in de patiëntenzorg voor een kleine groep patiënten, begint de AVG-verantwoordelijkheid op het moment dat we onbewerkte signaalgegevens exporteren die moeten worden gereconstrueerd tot afbeeldingen op een aparte reconstructie computer. Het belangrijkste aspect voor ons is het voorkomen van ongeautoriseerde toegang. Daarom worden de gegevens door de laborant handmatig opgeslagen in een één-richting “drop box” (niet de cloud-opslag) en direct na de export automatisch verder gestuurd naar een beveiligde projectmap. Alleen noodzakelijke ruwe gegevens worden geëxporteerd en geen andere medische afbeeldingen of gevoelige gegevens. Niettemin bevatten ruwe gegevens gevoelige patiëntinformatie. De gegevens worden langdurig opgeslagen op een netwerkschijf binnen het ziekenhuisnetwerk die automatisch wordt geback-upt en alleen toegankelijk is voor geautoriseerd personeel dat bij het project betrokken is. Na een succesvolle reconstructie worden beeldgegevens (met patiëntinformatie) veilig verzonden naar postprocessing software of naar het PACS, het punt waarop onze specifieke AVG-verantwoordelijkheid eindigt en wordt overgedragen aan de standaard IT-infrastructuur voor reguliere patiëntenzorg. Als de onbewerkte beeldgegevens worden gebruikt in andere onderzoeksprojecten, worden de gegevens gepseudonimiseerd voordat ze worden overgedragen en wordt de codering versleuteld zodat deze alleen toegankelijk is voor projectbeheerders.
Maak je leven niet te moeilijk: procesautomatisering
Twee belangrijke aspecten bij het in de klinische praktijk implementeren van een wetenschappelijk idee waren beveiliging en risico-evaluatie. Elke menselijke interactie is vatbaar voor fouten. Procesautomatisering is bekend in robotica of bedrijfsprocessen, omdat geautomatiseerde processen ervoor zorgen dat hetzelfde proces keer op keer met dezelfde snelheid, dezelfde grondigheid en dezelfde uitkomst keer op keer wordt uitgevoerd zonder menselijke tussenkomst. Vooral gegevensbeheer, zoals het hernoemen, overdragen of opslaan van gegevens, kan en moet worden geautomatiseerd, net als rekenintensieve processen waaronder beeldreconstructie of nabewerkingsstappen. Dit is niet alleen robuust en veilig, maar ook sneller en gemakkelijker dan om alles handmatig te doen. Stel je voor dat je 100 of zelfs 1000 datasets moet kopiëren, plakken en/of hernoemen. Je kunt beter je tijd besteden aan een goed script en daarna van een welverdiende kop koffie genieten. Extreem handig zijn tools voor procesautomatisering, zoals bijvoorbeeld CTP of DICOMTK, en shell-scripts voor zowel Linux- als Windows-systemen. Er zijn veel verschillende instructies over shellscripting online te vinden en deze maken het leven gemakkelijker.
In ons geval wordt de “drop box” met binnenkomende gegevens in de gaten gehouden door een script. Telkens wanneer er nieuwe onbewerkte gegevens binnenkomen, zal het script de gegevens naar een beveiligde projectfolder sturen en een reconstructietaak starten. Vervolgens worden de onbewerkte gegevens van de MRI-scanner gereconstrueerd tot medische beelden in de DICOM-standaard, met een juiste naam en voor de lange termijn opgeslagen in een speciaal archief in het ziekenhuisnetwerk. Bovendien worden de DICOM-beelden van de innovatieve MRI-sequentie naar het PACS-systeem gestuurd. Tenslotte wordt er een e-mail naar de verwerkingsverantwoordelijke gestuurd samen met een logbestand met alle noodzakelijke stappen die zijn genomen, maar zonder gevoelige informatie. Bovendien wordt na elke wijziging in software of gegevensverwerkingsstap een test uitgevoerd waarbij de gegevens worden geëxporteerd en gereconstrueerd om zo de volledige functionaliteit van de procesautomatisering te testen.
Twee hoofden zijn beter dan één: codering en repositories
In de 21e eeuw zijn softwaremodificaties of -codering bijna niet te vermijden in de zorgsector. Machines worden bestuurd door software, medische beelden worden gemaakt met bepaalde algoritmen en ook analysetools van welke aard dan ook worden in softwarecode geschreven. Bijna iedereen kan programmeren, maar niet iedereen is er even goed in. Een van de belangrijkste aspecten om een goede programmeur te worden, is te voldoen aan “The Software Engineering Code of Ethics and Professional Practice” (https://ethics.acm.org/code-of-ethics/software-engineering -code/). Deze regels of ethiek voor programmeurs zijn het lezen waard en zorgen ervoor dat aan de belangrijkste aspecten wordt voldaan. Twee van de belangrijkste punten zijn “Zorg voor voldoende testen, debuggen en beoordelen van software” en “Keur software alleen goed als er een gegronde overtuiging bestaat dat het veilig is en aan de specificaties voldoet”. Dat gezegd hebbende, is het raadzaam om bij elke aanpassing van een wetenschappelijk idee of -project de software op te slaan in een coderepository die versiebeheer biedt. Vooral wanneer dit idee zal worden vertaald naar de klinische praktijk, is het voor een goed risicobeheer vereist om zowel een coderepository te gebruiken als om de softwarecode te laten nakijken. Elke softwarewijziging moet worden gedocumenteerd en gecontroleerd. Een interessant concept waarvan niet iedereen zich van bewust is, is dat de kans dat een bug onopgemerkt blijft drastisch wordt verkleind door de code te laten nakijken door een collega. Heel theoretisch beschouwd: als een softwareontwikkelaar een willekeurige 99% van de bugs in nieuw geschreven software zou detecteren, dan zouden twee softwareontwikkelaars samen 99,99% van de bugs kunnen detecteren. Een eenvoudige manier van versiebeheer en documentatie van codewijzigingen is mogelijk met behulp van software repositories zoals SVN, Git of Github. Ze kunnen worden gebruikt voor software die voor het publiek toegankelijk is, maar ook voor privésoftware. In beide gevallen wordt elke softwarewijziging van een ontwikkelaar in detail vermeld en kunnen alle wijzigingen worden beoordeeld door andere ontwikkelaars, betrokken auditors of zelfs het grote publiek (indien gewenst).
In ons geval werd elke meegenomen softwarewijziging gedocumenteerd in een speciale projectrepository, onafhankelijk getest en nagekeken door ten minste één andere onderzoeker of auditor om de veiligheid te waarborgen. Dit was de praktijk voor veranderingen in de nabewerkingsalgoritmen, de reconstructie-algoritmen en de MRI-scannersoftware. Vooral voor de softwaremodificaties van de MRI-scanner was een veilige implementatie ons uitgangspunt, wat inhoudt dat geen enkele coderegel onvoorwaardelijk wordt uitgevoerd en de uitvoering van elke gewijzigde coderegel afhankelijk is van één bepaalde parameter. Deze parameter zorgt ervoor dat de standaard werking van de scanner niet wordt beïnvloed door de codewijzigingen en dat de laborant of iemand anders die de scanner bedient tijdens het MRI-onderzoek bewust voor deze functie moet kiezen.
RTFM: training en documentatie
Voor een soepele werking is het noodzakelijk dat de neuzen van alle betrokken personen in dezelfde richting staan en alle stappen in het dataverwerkingsproces kennen. Waarom moeten piloten elke dag checklists doornemen? Omdat menselijke interacties vatbaar zijn voor fouten. Daarom moeten de nodige maatregelen worden genomen om deze fouten te vermijden. RTFM is een afkorting voor de uitdrukking “read the factory manual” en wordt vaak gebruikt als antwoord op een vraag die gemakkelijk had kunnen worden beantwoord vanuit de producthandleiding of documentatie. Een gebruikershandleiding of documentatie is dus een cruciaal onderdeel van een dergelijk project, aangezien het voor alle betrokkenen onmogelijk is om specifieke stappen voor een lange tijd te onthouden. Maar iedereen kan op elk moment een bepaalde vraag opzoeken als de documentatie beschikbaar is. En zoals eerder vermeld, is een handleiding ook wettelijk verplicht.
Vanzelfsprekend maakt een vliegtuighandleiding je geen goede piloot, daarom is training het andere belangrijke aspect. Oefening baart kunst. Al het personeel dat met bepaalde hardware en software werkt, moet goed worden opgeleid alvorens met patiënten of patiëntgegevens te werken. Dit kan variëren van het bedienen van een machine tot het verwerken en analyseren van patiëntgegevens. Nuttig aanvullend materiaal is een beknopte handleiding of een eenvoudige checklist om vergissingen en risico’s op de werkplek te verminderen.
In ons geval is er een volledige en beknopte gebruikershandleiding gemaakt met veel illustraties en afbeeldingen van bijvoorbeeld stappen die op de MRI-scanner moeten worden uitgevoerd, verschillende instellingen en werkprocesdiagrammen. Vooral de betrokken laboranten waren goed opgeleid om onze MRI-sequentie voor onderzoek te gebruiken, en om de gegevens te exporteren. In eerste instantie trainden onderzoekers, die het scan protocol ontwikkelden, de laboranten door vrijwilligers te scannen. Vervolgens waren de onderzoekers alleen aanwezig als waarnemer om in te grijpen als dat nodig was. Uiteindelijk gebruikten de laboranten de MRI-sequentie van het onderzoek volledig onafhankelijk. Uitermate behulpzaam waren de beknopte handleidingen voor het bedienen van de MRI-scanner en het analyseren van de gegevens. Die handleidingen hielpen om – letterlijk – alles stap voor stap te doen, waardoor de menselijke foutenbronnen tot een minimum werden beperkt.
Project follow-up
Het verhaal gaat verder: post-markt surveillance
Zelfs nadat je het voor elkaar hebt om een wetenschappelijk idee in de klinische praktijk te implementeren, moet je de resultaten tijdens klinisch gebruik blijven monitoren. Dit staat bekend als post-market surveillance (PMS). Stel doelen voor jezelf, afhankelijk van het geïmplementeerde idee of de functionaliteit, en bepaal na hoeveel casus een evaluatie zinvol is. Een pilotstudie kan 10 proefpersonen bevatten, een kleine studie kan wel 30 proefpersonen bevatten en grotere studies kunnen 100+ proefpersonen bevatten. Als je PMS keer op keer hetzelfde resultaat oplevert, heb je het wetenschappelijke bewijs dat de implementatie correct functioneert. Daarnaast moeten mogelijke problemen of fouten worden gedocumenteerd en moeten bugs worden verholpen wanneer ze zich voordoen. Als je nieuwe functies toevoegt aan de bestaande innovatie of bugs hebt verholpen, begin je opnieuw en moet je de resultaten goed volgen. Zorg ervoor dat je versiebeheer of revisies gebruikt, zodat je altijd weet welke patiënten met welke versie van de sequentie zijn onderzocht. Houd de regelmatige vergaderingen met de gebruikers en het team in stand om iedereen op de hoogte te houden.
In ons geval wordt het PMS – tot nu toe – uitgevoerd in de vorm van maandelijkse overleggen waarin we toezicht houden op de lopende procedures en waar nodig kleine verbeteringen worden aangebracht. Bovendien bespreken we nieuwe functionaliteit en zijn we van plan nieuwe pilotstudies te plannen, maar tot nu toe is er geen substantiële wijziging aangebracht in de oorspronkelijke release. Daarnaast maakte de klinische implementatie van 4D flow MRI het mogelijk dat academisch onderzoek een nieuwe fase van aanverwante vervolgstudies kon ingaan. Een retrospectieve en geanonimiseerde studie heeft bijvoorbeeld al gebruik gemaakt van de verkregen (snelle) 4D flow MRI-gegevens van 32 patiënten met structurele hartziekten.
Slotopmerkingen
Aan de hand van het voorbeeld van een nieuwe MRI-sequentie hebben we aangetoond dat het mogelijk is om een wetenschappelijk idee in de klinische praktijk te brengen. Dat is niet eenvoudig, regelgeving kan behoorlijk frustrerend zijn en het is niet altijd eenvoudig om budget te vinden voor deze activiteiten. Ook lijkt de hele procesimplementatie een langdurige klus, maar het is wel recht-toe-recht-aan en uitvoerbaar. Als je grondig en doelgericht werkt, is de tijd goed besteed en wordt je project in één keer goed. We hopen dat de uitleg de benodigde stappen verduidelijkt en anderen kan helpen om ook hun wetenschappelijk onderzoek dichter bij de patiëntenzorg te brengen. We moedigen andere onderzoeksgroepen aan om hetzelfde te doen.
We wensen je het allerbeste en veel succes!
Ons team (in alfabetische volgorde):
Aart J. Nederveen, Prof. of Applied MR Physics, MIQC founder
Bram F. Coolen, Assistant professor, MRI expert
Carmen P.S. Blanken, 4D flow MRI researcher
Chiel den Harder, MIQC
Eva S. Peper, 4D flow MRI researcher
Gustav J. Strijkers, Prof. of Preclinical and Translational Magnetic Resonance Imaging, MIQC founder
Josien van den Noort, MIQC
Jules L. Nelissen, Medical Imaging Expert
Laura A. van Dijk, MRI technician
Lukas M. Gottwald, 4D flow MRI researcher
Mario Maas, Prof. of Musculoskeletal Radiology, MIQC founder
S. Matthijs Boekholdt, Cardiologist
R. Nils Planken, Radiologist
Paul F.C. Groot, Clinical informatician
Pim van Ooij, 4D flow MRI researcher
Raschel D. van Luijk, MRI technician
A.M. (Sandra) van den Berg – Faay, MRI technician
Referenties
[1] European Parliament and of the Council. Council Directive 93/42/EEC of 14 June 1993 concerning medical devices, 2007. eur-lex.europa.eu:31993L0042.
[2] European Parlament and Council of the European Union. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, 2017. eur-lex.europa.eu:02017R0745-20200424.
[3] European Union. Regulation 2016/679 of the European parliament and the Council of the European Union of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). Official Journal of the European Communities, 2016. eur-lex.europa.eu:32016R0679.
[4] Gevers JKM. Medisch-wetenschappelijk onderzoek met mensen. Tijdschrift voor Gezondheidsrecht, 25(1):17–21, 2001. doi: 10.1007/BF03055859.
[5] Boelhouwers P, Heemskerk BT, Kroeze MM, Lageman G, and Witteveen M. Praktijkgids Prospectieve Risico-Inventarisatie (PRI), 2012.
[6] Gotterbarn D, Miller K, Rogerson S, Barber S, Barnes P, Burnstein I, Davis M, El-Kadi A, Fairweather NB, Fulghum M, Jayaram N, Jeweth T, Kanko M, Kallman E, Langford D, Little JC, Mechler E, Norman MJ, Phillips D, Prinzivalli PR, Sullivan P, Weckert J, Weil V, Weisband S, and Werth LH. Software engineering code of ethics and professional practice. Science and Engineering Ethics, 7(2):231–238, 2001. doi: 10.1007/s11948-001-0044-4.