MDR technisch dossier maken
Onder de MDR is het technisch dossier geen document dat u eenmalig samenstelt maar een dossier dat actueel moet blijven, gevoed door post-market surveillance. Appfront bouwt het systeem waarin die twee aan elkaar hangen: de documentatie per hulpmiddel en per versie, en de signalen uit de markt die erop terugslaan.
Wat de MDR van een fabrikant vraagt
Verordening (EU) 2017/745 vraagt van elke fabrikant een technische documentatie volgens de bijlagen bij die verordening: beschrijving en specificatie van het hulpmiddel, informatie voor de gebruiker, ontwerp- en fabricagegegevens, de algemene veiligheids- en prestatie-eisen met de onderbouwing per eis, risicomanagement, verificatie en validatie, en klinische evaluatie. Daar komt een aparte documentatie over post-market surveillance bij.
Dat tweede deel is wat de MDR wezenlijk anders maakt dan het oude regime. U moet een PMS-plan hebben, actief gegevens uit de markt verzamelen, die periodiek analyseren en de uitkomst terugvoeren naar het technisch dossier, de risicoanalyse en waar nodig het ontwerp. Afhankelijk van de risicoklasse levert dat een PMS-rapport of een periodiek veiligheidsverslag op, met een eigen actualisatiefrequentie. Daarnaast lopen vigilantie en trendrapportage.
In de praktijk staan die twee sporen bij veel fabrikanten los van elkaar. Het technisch dossier zit in een documentbeheersysteem of in een mappenstructuur, en de klachten en meldingen in een ander systeem of in een postbus. De MDR vraagt juist om de verbinding: een klacht moet vindbaar zijn vanuit het hulpmiddel en zichtbaar terugslaan op de risicoanalyse. Zonder die koppeling is de analyse handwerk en is bij een audit niet aantoonbaar dat de terugkoppeling heeft plaatsgevonden.
Dit systeem staat naast uw bestaande omgeving en vervangt hem niet. Draait er al een kwaliteitsmanagementsysteem met documentbeheer, dan bouwen we de MDR-laag daarop voort. Zit uw productie in een productiesysteem, dan halen we daar de batchgegevens uit die u nodig heeft om een melding te herleiden. Wij bouwen dat via koppelingen, zodat u niet aan één leverancier vastzit.
Hoe wij uw MDR-systeem bouwen
Wij beginnen bij de structuur van uw dossier en niet bij een schermontwerp. Als de opbouw niet aansluit op wat uw aangemelde instantie verwacht, kost elk audit-verzoek alsnog zoekwerk.
Welke hulpmiddelen brengt u op de markt, in welke risicoklassen, in welke varianten en versies. Daaruit volgt hoe het dossier is opgebouwd: per hulpmiddel, per familie, of per basis-UDI. Die keuze bepaalt de rest en is achteraf duur om te wijzigen.
We ontwerpen hoe een signaal uit de markt zijn weg vindt naar het dossier: van klacht naar hulpmiddel, naar de betrokken risico’s, naar een beoordeling en waar nodig naar een wijziging. Die keten is de kern van het systeem.
We werken in sprints en beginnen bij de kant met het meeste dagelijkse verkeer, doorgaans klachten en meldingen. Uw kwaliteitsafdeling werkt mee en toetst elke sprint aan echte gevallen uit uw eigen historie.
Voor de overdracht lopen we het systeem na met de vragen van een aangemelde instantie: toon van dit hulpmiddel de actuele documentatie, de laatste PMS-analyse en wat daaruit is gevolgd. Wat dan niet in enkele klikken te tonen is, passen we aan.
Wat het systeem concreet doet
Zes onderdelen die samen het dossier en de bewaking ervan vormen. Welke u nodig heeft hangt af van uw risicoklassen en van de omvang van uw portfolio.
Technische documentatie per hulpmiddel
De documentatie opgebouwd volgens de indeling van de verordening, per hulpmiddel en per versie, zodat u van elke uitgebrachte variant kunt terugvinden welke documentatie erbij hoorde. Wijzigingen zijn zichtbaar als wijziging, met de reden erbij.
Eisen met hun onderbouwing
Per algemene veiligheids- en prestatie-eis vastgelegd of hij van toepassing is, welke norm u toepast en welk bewijsstuk de naleving aantoont. Dat is de tabel waar een auditor als eerste om vraagt, en de plek waar losse verwijzingen het snelst verouderen.
Klachten, meldingen en vigilantie
Elke melding gekoppeld aan het hulpmiddel en aan het betrokken risico, met een beoordeling of het een meldingsplichtig voorval is en een vaste route als dat zo is. Termijnen worden bewaakt, want die lopen vanaf het moment dat u ervan weet.
PMS-analyse en trendbewaking
Signalen bij elkaar per hulpmiddel, met een trendbeeld over de tijd zodat een toename opvalt voordat hij een probleem wordt. De periodieke analyse put daaruit in plaats van dat iemand hem met de hand samenstelt uit exports.
Actualisatie op de klok
PMS-rapporten en periodieke veiligheidsverslagen hebben een frequentie die per risicoklasse verschilt. Het systeem plant die vooruit en waarschuwt op tijd, inclusief de klinische evaluatie die periodiek moet worden herzien.
UDI en identificatie
Basis-UDI en UDI per verpakkingsniveau vastgelegd bij het hulpmiddel, zodat een melding uit de markt herleidbaar is tot een specifieke uitvoering. Voor het aanleveren aan de Europese databank bereiden we de gegevens voor in de vereiste vorm.
Voor wie wij bouwen
Vier soorten organisaties met een ander vertrekpunt. Het verschil zit vooral in de risicoklasse en in of u zelf fabrikant bent.
Fabrikanten van fysieke hulpmiddelen
Productie, batches en leveranciers spelen mee in het dossier. Vaak sluit dit aan op uw productiesysteem, zodat een melding herleidbaar is tot een charge.
Softwarefabrikanten en SaMD
Uw hulpmiddel is software, dus versies wisselen sneller dan bij hardware. Bouwt u die software zelf, kijk dan ook naar medical device software laten maken; deze pagina gaat over het dossier eromheen.
Importeurs en distributeurs
U bent geen fabrikant maar draagt eigen verplichtingen: controleren of de fabrikant zijn zaken op orde heeft, klachten doorgeven en traceerbaarheid houden. Dat vraagt een lichter systeem met een ander zwaartepunt.
Bedrijven met een groeiend portfolio
Eén hulpmiddel houdt u nog in mappen bij. Vanaf een stuk of vijf varianten met eigen versies wordt de vraag welke documentatie bij welke uitvoering hoort te lastig om handmatig te beantwoorden.
Test je idee eerst — werkend prototype in 1 dag
Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.
Bekijk OneDayBuild →Technologie en koppelingen
Wat wij inzetten volgt uit uw situatie. Wij bouwen geen medisch hulpmiddel: dit systeem ondersteunt uw kwaliteitsproces en is zelf geen hulpmiddel. Waar het raakt aan gevalideerde omgevingen stemmen we dat af met uw kwaliteitsmanager.
Waarom Appfront
Dossier en markt in één keten
De MDR gaat over terugkoppeling. Wij bouwen daarom niet twee systemen naast elkaar maar één keten waarin een melding zichtbaar terugslaat op de risicoanalyse.
Gebouwd op de auditvraag
Wij ontwerpen vanuit wat een aangemelde instantie vraagt en toetsen dat voor de overdracht met een proefronde. Dat is concreter dan voldoen aan een norm op papier.
Versies die kloppen
Van elke uitgebrachte uitvoering moet u kunnen tonen welke documentatie erbij hoorde. Dat is een ontwerpvraag over versiebeheer en die beantwoorden we aan het begin, niet halverwege.
Eerlijk over onze rol
Wij zijn geen aangemelde instantie en geen regulatory consultant. Wij bouwen het systeem; de inhoudelijke beoordeling en de gesprekken met uw notified body blijven bij u en uw adviseur.
Security en privacy
Meldingen uit de markt bevatten regelmatig gegevens over patiënten: een omschrijving van een voorval, soms letsel, soms herleidbare details. Dat zijn bijzondere persoonsgegevens en die horen niet ongefilterd in een kwaliteitssysteem. Wij richten de invoer zo in dat wat nodig is voor de beoordeling wordt vastgelegd en de rest niet, en dat vrije tekstvelden expliciet waarschuwen tegen het overnemen van patiëntgegevens.
Daarnaast is uw technisch dossier zelf uw meest waardevolle bedrijfsinformatie: ontwerp, testresultaten en klinische onderbouwing bij elkaar. Toegang gaat daarom per rol en per hulpmiddel, met een aparte, tijdelijke rol voor externe auditors die alleen ziet wat bij hun scope hoort. Elke wijziging aan een goedgekeurd document wordt gelogd met wie en waarom, en een goedkeuring vraagt om een elektronische handtekening. Hoe wij zelf met beveiliging omgaan staat in ons informatiebeveiligingsbeleid; meldingen van buitenaf lopen via ons CVD-beleid.
Veelgestelde vragen over het MDR technisch dossier
De verordening schrijft een indeling voor: beschrijving en specificatie van het hulpmiddel inclusief varianten, de informatie die u aan de gebruiker meelevert, ontwerp- en fabricagegegevens, de algemene veiligheids- en prestatie-eisen met per eis de onderbouwing, risicomanagement, verificatie en validatie, en de klinische evaluatie. Daarnaast een aparte documentatie over post-market surveillance. Wij bouwen die indeling in als structuur, zodat u niet zelf hoeft te bedenken waar iets hoort.
PMS is het brede proces van gegevens uit de markt verzamelen en analyseren. PMCF is het deel daarvan dat gericht klinische gegevens verzamelt na het op de markt brengen, om de klinische evaluatie actueel te houden. Vigilantie is de meldingsroute voor ernstige voorvallen en veiligheidscorrecties, met eigen termijnen. Ze hangen samen maar hebben verschillende uitkomsten, en juist dat onderscheid ontbreekt vaak in een gedeelde postbus.
Doorlopend, en dat is de kern van de MDR. Daarbovenop gelden vaste momenten: PMS-rapporten en periodieke veiligheidsverslagen kennen een frequentie die per risicoklasse verschilt, en de klinische evaluatie moet periodiek worden herzien. Wij bouwen die momenten in als geplande taken met een verantwoordelijke, want doorlopend actueel houden is in de praktijk precies wat blijft liggen zonder een datum.
Ja, maar lichter. Als importeur controleert u of de fabrikant zijn verplichtingen is nagekomen, houdt u een register van klachten en niet-conforme hulpmiddelen bij, geeft u meldingen door en zorgt u voor traceerbaarheid van wat u heeft geleverd. Dat is een kleiner systeem met een ander zwaartepunt: minder documentatie, meer keten en traceerbaarheid.
Die pagina gaat over het bouwen van medische software zelf, waarbij de software het hulpmiddel is en normen als IEC 62304 gelden voor de ontwikkeling ervan. Deze pagina gaat over het systeem waarin u als fabrikant uw dossier en uw marktbewaking beheert; dat systeem is zelf geen hulpmiddel. Maakt u software-hulpmiddelen, dan heeft u vaak allebei nodig en houden wij ze gescheiden.
Software die u gebruikt binnen uw kwaliteitsmanagementsysteem moet geschikt zijn voor het beoogde gebruik, en dat vraagt onderbouwing. Hoe zwaar die is, hangt af van welke stappen u erop laat leunen. Wij leveren de documentatie die u voor die onderbouwing nodig heeft en stemmen de omvang af met uw kwaliteitsmanager, in plaats van er een aanname over te doen.
De Europese databank wordt gefaseerd verplicht en de aanlevering verloopt via vastgestelde formaten. Wij bereiden de gegevens voor in de vorm die wordt gevraagd, zodat aanleveren geen overtypwerk is. Wat de koppeling precies kan, hangt af van wat er op het moment van bouwen beschikbaar is; dat stellen we in de verkenning vast in plaats van het vooraf toe te zeggen.
Voor het dossier alleen kan dat, en veel fabrikanten doen dat ook. Waar het vastloopt, is de terugkoppeling: een documentbeheersysteem kent geen meldingen, geen risico’s en geen trends, dus de analyse blijft handwerk in exports. Heeft u weinig hulpmiddelen en weinig meldingen, dan zeggen wij eerlijk dat een eigen systeem de moeite niet is.
Een MDR-systeem laten bouwen?
Vertel welke hulpmiddelen u op de markt brengt en waar uw dossier nu uit elkaar valt, dan denken we mee over de opbouw, de koppeling met uw meldingen en de actualisatiemomenten. Wij bouwen dit als los systeem en als onderdeel van een breder traject maatwerk software.