Een veiligheidswaarschuwing in een geneesmiddeltekst verandert. De medical writer past het QRD-document in Word aan. Regulatory Affairs controleert de tekst met track changes. Daarna volgen opmerkingen, taalversies en een definitief akkoord.
Op dat moment is de inhoud klaar, maar de digitale productinformatie nog niet. Voor Europese elektronische productinformatie (ePI) moet dezelfde goedgekeurde tekst ook als gestructureerde FHIR beschikbaar zijn.
Wie die stap oplost met kopiëren en plakken, begint in feite aan een tweede redactieronde. Dan kunnen een paragraaf, sectiecode, taal of tabel afwijken van wat zojuist is goedgekeurd.
Dat is precies het probleem dat we hebben aangepakt: we vervangen Word niet en maken het EMA-portaal niet tot de enige beheeromgeving. We verbinden de bestaande Word-workflow met gestructureerde ePI en leggen het bewijs rond die overgang vast.
Word en FHIR hebben ieder een andere taak
Word is sterk in schrijven, redigeren en visueel vergelijken. Teams kennen het gereedschap, reviewers kunnen wijzigingen volgen en het document past in bestaande goedkeuringsprocessen.
FHIR heeft een ander doel. Daarin is niet alleen zichtbaar dát iets een kop is, maar ook welke officiële ePI-sectie het is, bij welk documenttype en welke taal de inhoud hoort en hoe een ander systeem die informatie kan hergebruiken.
De Europese Medicines Regulatory Network ePI Implementation Guide modelleert die informatie in FHIR. De EMA geeft bovendien aan dat organisaties ePI met externe tooling mogen maken en als FHIR mogen uploaden. Een Word-naar-FHIR-plugin levert de EMA niet.
De twee werelden blijven voorlopig naast elkaar bestaan. De gebruikelijke Word/PDF-productinformatie blijft onderdeel van het regelgevingsproces, terwijl ePI gestructureerde, herbruikbare informatie toevoegt. Ook ontbreekt track changes momenteel in de ePI-editor. Het is dus logisch dat teams hun bestaande documentworkflow niet zomaar loslaten.
Een concrete variatie zonder dubbel werk
Stel dat na een variatie paragraaf 4.4 van de SmPC en de bijbehorende passage in de bijsluiter veranderen. Een beheerste keten kan dan zo werken:
- De specialist past de tekst aan in het gecontroleerde QRD-DOCX.
- Reviewers beoordelen de wijziging in hun bestaande Word-proces.
- Na akkoord herkent de conversie de officiële documenten en secties.
- De tekst wordt gekoppeld aan de juiste FHIR-profielen, sectiecodes en taal.
- Een preflight controleert het bestand vóór de upload.
- Een vergelijking toont wat ten opzichte van de vorige versie is veranderd en of alle tekst en structuur behouden zijn.
- Vanuit dezelfde structuur kan weer een leesbaar Word-document voor kwaliteitscontrole worden gemaakt.
De winst zit niet alleen in tijd. Het belangrijkste is dat er één aantoonbare overgang ontstaat tussen de goedgekeurde tekst en de digitale publicatie.
Waarom een gewone documentconverter niet genoeg is
Een generieke converter kan tekst uit DOCX halen. Voor geneesmiddelinformatie is dat pas het begin.
Onze ePI-brug is daarom ontworpen om:
- QRD- en ePI-secties op betekenis herkennen, niet alleen op lettergrootte;
- documenttype, taal en officiële sectiecodes correct vastleggen;
- lijsten, tabellen, links, voetnoten en inline-opmaak beheerst omzetten;
- valideren tegen de actuele FHIR- en ePI-profielen;
- onbekende secties zichtbaar behouden in plaats van stilzwijgend verwijderen;
- een controleerbaar verschilrapport voor tekst én structuur leveren;
- reproduceerbaar werken over producten, variaties en taalversies.
Daarom is “er komt XML uit” geen acceptatiecriterium. De relevante vraag is: kunnen Regulatory Operations en Quality aantonen dat de juiste inhoud, in de juiste structuur, zonder onverwacht verlies is overgezet?
Wat we hiervoor hebben gebouwd
Elk Solutions heeft hiervoor een zelf te hosten transformatiekern gebouwd. FHIR is daarin leidend en DOCX blijft de adapter voor schrijven, review en kwaliteitscontrole. De kern vereist geen Microsoft Office-server en geen gesloten documentruntime.
De werkende kern:
- een openbaar EMA FHIR-voorbeeld met 32 geneste SmPC-secties inspecteren;
- daaruit een gecontroleerd DOCX met een vaste identiteit per sectie maken;
- precies één Word-wijziging terugschrijven naar de oorspronkelijke FHIR;
- 31 ongewijzigde secties en niet-narratieve inhoud aantoonbaar behouden;
- een semantisch roundtrip-verschilrapport leveren;
- de uitgangsbundle controleren met de officiële HL7 FHIR Validator en het EMRN ePI-profiel: 0 errors en 0 warnings in de gecontroleerde proef.
De geautomatiseerde suite telt 27 tests en bewaakt ook XML- en DOCX-packageveiligheid. Daarmee staat de technische kern van preflight en roundtripbewijs. De belangrijke grens: vrije herkenning van willekeurige historische QRD-DOCX-bestanden, meertalige batchverwerking, gebruikersbeheer en RIM-integratie zijn nog niet als productfunctie gerealiseerd.
Ook is voor de eigen projectcode nog geen publieke softwarelicentie gekozen. We noemen dit daarom een werkende kern in design-partnerfase, niet een afgerond of openbaar open-sourceproduct.
Van transformatiekern naar beheeromgeving
Eén beheerde omgeving voor het maken, controleren, goedkeuren en volgen van ePI — vóór en na indiening bij EMA. De werkende kern lost het moeilijkste technische overgangspunt op. De productrichting voegt daar de control-laag omheen toe.
De beoogde beheeromgeving voegt toe:
- producten, handelsvergunningen, documenten en talen;
- eigen QRD-templates, terminologie en bedrijfsregels;
- import van Word en bestaande FHIR-ePI;
- versiebeheer, betekenisvolle verschillen, rollen, opmerkingen en goedkeuringen;
- automatische FHIR-generatie, lokale validatie en een reproduceerbaar EMA-aanleverpakket;
- registratie van de handmatige import en indiening in het PLM Portal;
- controle na publicatie door de ePI via de openbare EMA-API terug te lezen en met de goedgekeurde versie te vergelijken.
Die laatste twee stappen worden bewust niet als volledig geautomatiseerd gepresenteerd. EMA biedt wel een openbare lees-API voor gepubliceerde ePI, maar documenteert momenteel geen publieke write-API voor ePI-indiening. Het portaal blijft dus het officiële eindpunt; de organisatie houdt zelf de regie over de bronnen en het proces dat eraan voorafgaat.
Die handmatige overdracht wordt geen onzichtbaar gat. De omgeving toont welk pakket buiten het systeem moet worden geüpload en legt SHA-256, versie, goedkeurder en datum vast. Ze wordt geleverd als beheerde private omgeving of self-hosted/private cloud. Elk Solutions beheert desgewenst de techniek; de klant blijft eigenaar van inhoud, rollen en voorschriften.
Dit wordt bewust geen volledig RIM- of documentmanagementsysteem. Het is de gespecialiseerde ePI-control-laag tussen bestaande bronnen, het PLM Portal en de gepubliceerde ePI-API.
Voor wie dit probleem nu al concreet is
Deze oplossing is direct relevant voor:
- ePI- en Regulatory Operations-teams van vergunninghouders;
- medical writers en product-information- of labelling-specialisten;
- serviceproviders die meerdere geneesmiddelenportfolio's ondersteunen;
- RIM- en integratieteams die FHIR in bestaande processen moeten inpassen;
- kwaliteitsmedewerkers die moeten bewijzen dat versies gelijkwaardig zijn.
De Europese invoering verloopt gefaseerd en taalversies worden op dit moment één voor één geïmporteerd. Dit is daarom geen eenmalige conversieklus, maar herbruikbare infrastructuur voor een portfolio met variaties, documenten en talen.
Bronnen en actuele status
- EMA ePI Frequently Asked Questions
- EMRN ePI Implementation Guide
- EMA ePI user guide for applicants
- EMA public API for published ePI
- EMA: draft ePI implementation roadmap
De aangehaalde EMA-FAQ is bijgewerkt op 8 april 2026. De roadmap en functionaliteit worden verder ontwikkeld; controleer voor een implementatiebesluit altijd de meest recente officiële guidance.