Ein Sicherheitshinweis in einer Arzneimittelinformation ändert sich. Der Medical Writer passt das QRD-Dokument in Word an. Regulatory Affairs prüft den Text mit der Änderungsverfolgung. Danach folgen Kommentare, Sprachfassungen und die endgültige Freigabe.
Zu diesem Zeitpunkt ist der Inhalt fertig, die elektronische Produktinformation jedoch noch nicht. Für die europäische elektronische Produktinformation (ePI) muss derselbe genehmigte Text auch als strukturiertes FHIR vorliegen.
Wer diesen Schritt durch Kopieren und Einfügen löst, beginnt praktisch eine zweite Redaktionsrunde. Dann können ein Absatz, ein Abschnittscode, eine Sprache oder eine Tabelle von der gerade freigegebenen Fassung abweichen.
Genau dieses Problem haben wir adressiert: Wir ersetzen Word nicht, sondern verbinden den bestehenden Word-Workflow mit strukturierter ePI.
Word und FHIR haben unterschiedliche Aufgaben
Word eignet sich gut zum Schreiben, Redigieren und visuellen Vergleichen. Die Teams kennen das Werkzeug, Prüfer können Änderungen nachvollziehen und das Dokument passt in bestehende Freigabeprozesse.
FHIR verfolgt ein anderes Ziel. Darin wird nicht nur sichtbar, dass etwas wie eine Überschrift aussieht, sondern auch, um welchen offiziellen ePI-Abschnitt es sich handelt, zu welchem Dokumenttyp und welcher Sprache der Inhalt gehört und wie ein anderes System ihn wiederverwenden kann.
Der ePI Implementation Guide des European Medicines Regulatory Network modelliert diese Informationen in FHIR. Die EMA erklärt außerdem, dass Organisationen ePI mit externen Werkzeugen erstellen und als FHIR hochladen dürfen. Ein Word-zu-FHIR-Plugin stellt die EMA nicht bereit.
Beide Welten werden vorerst nebeneinander bestehen. Herkömmliche Word/PDF-Produktinformationen bleiben Teil des regulatorischen Prozesses, während ePI strukturierte, wiederverwendbare Informationen ergänzt. Auch die Änderungsverfolgung ist im ePI-Editor derzeit nicht verfügbar. Es ist daher nachvollziehbar, dass Teams ihren bestehenden Dokumentenworkflow nicht einfach aufgeben.
Eine konkrete Variation ohne doppelte Arbeit
Angenommen, durch eine Variation ändern sich Abschnitt 4.4 der Fachinformation und die entsprechende Passage in der Packungsbeilage. Eine kontrollierte Kette könnte dann so funktionieren:
- Der Spezialist passt den Text im kontrollierten QRD-DOCX an.
- Die Prüfer bewerten die Änderung in ihrem bestehenden Word-Prozess.
- Nach der Freigabe erkennt die Konvertierung die offiziellen Dokumente und Abschnitte.
- Der Text wird den richtigen FHIR-Profilen, Abschnittscodes und der richtigen Sprache zugeordnet.
- Ein Preflight prüft die Datei vor dem Upload.
- Ein Vergleich zeigt, was sich gegenüber der vorherigen Fassung geändert hat und ob Text und Struktur vollständig erhalten blieben.
- Aus derselben Struktur kann wieder ein lesbares Word-Dokument für die Qualitätskontrolle erzeugt werden.
Der Gewinn liegt nicht nur in der Zeitersparnis. Entscheidend ist, dass ein nachweisbarer Übergang zwischen dem genehmigten Text und der digitalen Publikation entsteht.
Warum ein gewöhnlicher Dokumentkonverter nicht ausreicht
Ein generischer Konverter kann Text aus DOCX extrahieren. Für Arzneimittelinformation ist das erst der Anfang.
Unsere ePI-Brücke ist daher darauf ausgelegt:
- QRD- und ePI-Abschnitte anhand ihrer Bedeutung erkennen, nicht nur anhand der Schriftgröße;
- Dokumenttyp, Sprache und offizielle Abschnittscodes korrekt erfassen;
- Listen, Tabellen, Links, Fußnoten und Inline-Formatierung kontrolliert umwandeln;
- gegen die aktuellen FHIR- und ePI-Profile validieren;
- unbekannte Abschnitte sichtbar erhalten, statt sie stillschweigend zu entfernen;
- einen prüfbaren Differenzbericht für Text und Struktur liefern;
- über Produkte, Variationen und Sprachfassungen hinweg reproduzierbar arbeiten.
Deshalb ist „es kommt XML heraus“ kein Abnahmekriterium. Die relevante Frage lautet: Können Regulatory Operations und Quality nachweisen, dass der richtige Inhalt in die richtige Struktur übertragen wurde, ohne unerwarteten Verlust?
Was wir dafür gebaut haben
Elk Solutions hat dafür einen offenen, selbst hostbaren Transformationskern gebaut. FHIR ist darin maßgeblich, während DOCX der Adapter für Erstellung, Prüfung und Qualitätskontrolle bleibt. Der Kern benötigt weder einen Microsoft Office-Server noch eine proprietäre Dokumentenruntime.
Der funktionierende Kern:
- eine ePI FHIR Composition und ihre verschachtelten Abschnitte untersuchen;
- daraus ein DOCX mit erkennbaren Content Controls je Abschnitt erstellen;
- die Abschnittstags aus einem solchen DOCX wieder auslesen;
- bekannte Kompatibilitätstags mit offiziellen ePI-Codes verknüpfen;
- unbekannte FHIR-Abschnitte erhalten;
- die Kette mit öffentlichen EMA-Beispielen testen.
Damit steht der technische Kern der Brücke. Wir erweitern ihn nun gezielt um DOCX zu FHIR, normativen Preflight und einen vollständigen Roundtrip-Differenzbericht. Das sind Erweiterungen einer bewährten Architektur und kein neues technisches Wagnis.
Für wen dieses Problem bereits konkret ist
Diese Lösung ist unmittelbar relevant für:
- ePI- und Regulatory-Operations-Teams von Zulassungsinhabern;
- Medical Writer sowie Product-Information- und Labelling-Spezialisten;
- Dienstleister, die mehrere Arzneimittelportfolios betreuen;
- RIM- und Integrationsteams, die FHIR in bestehende Prozesse einbinden;
- Qualitätsverantwortliche, die die Gleichwertigkeit von Versionen nachweisen müssen.
Die europäische Einführung erfolgt schrittweise, und Sprachfassungen werden derzeit einzeln importiert. Dies ist daher keine einmalige Konvertierungsaufgabe, sondern wiederverwendbare Infrastruktur für ein Portfolio aus Variationen, Dokumenten und Sprachen.
Quellen und aktueller Stand
- EMA ePI Frequently Asked Questions
- EMRN ePI Implementation Guide
- EMA ePI user guide for applicants
- EMA: Entwurf der ePI-Implementierungsroadmap
Die zitierte EMA-FAQ wurde am 8. April 2026 aktualisiert. Roadmap und Funktionalität werden weiterentwickelt; prüfen Sie vor einer Implementierungsentscheidung immer die neuesten offiziellen Leitlinien.