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, we verbinden de bestaande Word-workflow met gestructureerde ePI.
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 open, 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 ePI FHIR Composition en de geneste secties inspecteren;
- daaruit een DOCX met herkenbare content controls per sectie maken;
- de sectietags uit zo'n DOCX weer inspecteren;
- bekende compatibiliteitstags aan officiële ePI-codes koppelen;
- onbekende FHIR-secties behouden;
- de keten testen met openbare EMA-voorbeelden.
Daarmee staat de technische kern van de brug. We breiden die nu gericht uit met DOCX naar FHIR, normatieve preflight en een volledig roundtrip-verschilrapport. Dat zijn uitbreidingen op een bewezen architectuur, geen nieuwe technische gok.
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: 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.