Eine verwaltete Umgebung für ePI: vor und nach der EMA

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 und machen das EMA-Portal nicht zur einzigen Verwaltungsumgebung. Wir verbinden den bestehenden Word-Workflow mit strukturierter ePI und halten die Nachweise rund um diesen Übergang fest.

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:

1. Der Spezialist passt den Text im kontrollierten QRD-DOCX an.
2. Die Prüfer bewerten die Änderung in ihrem bestehenden Word-Prozess.
3. Nach der Freigabe erkennt die Konvertierung die offiziellen Dokumente und Abschnitte.
4. Der Text wird den richtigen FHIR-Profilen, Abschnittscodes und der richtigen Sprache zugeordnet.
5. Ein Preflight prüft die Datei vor dem Upload.
6. Ein Vergleich zeigt, was sich gegenüber der vorherigen Fassung geändert hat und ob Text und Struktur vollständig erhalten blieben.
7. 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 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:

• ein öffentliches EMA-FHIR-Beispiel mit 32 verschachtelten SmPC-Abschnitten untersuchen;
• daraus ein kontrolliertes DOCX mit stabiler Identität je Abschnitt erstellen;
• genau eine Word-Änderung in das ursprüngliche FHIR zurückschreiben;
• 31 unveränderte Abschnitte und nicht narrative Inhalte nachweislich erhalten;
• einen semantischen Roundtrip-Differenzbericht liefern;
• die Ausgangs-Bundle mit dem offiziellen HL7 FHIR Validator und dem EMRN-ePI-Profil prüfen: 0 Fehler und 0 Warnungen in der kontrollierten Erprobung.

Die automatisierte Suite umfasst 27 Tests und deckt auch XML- und DOCX-Package-Sicherheit ab. Damit steht der technische Kern für Preflight und Roundtrip-Nachweis. Die wichtige Grenze: die freie Erkennung beliebiger historischer QRD-DOCX-Dateien, mehrsprachige Batchverarbeitung, Benutzerverwaltung und RIM-Integration sind noch nicht als Produktfunktionen realisiert.

Für den eigenen Projektcode wurde außerdem noch keine öffentliche Softwarelizenz gewählt. Wir sprechen daher von einem funktionsfähigen Kern in der Designpartnerphase, nicht von einem fertigen oder öffentlich verfügbaren Open-Source-Produkt.

Vom Transformationskern zur Verwaltungs­umgebung

Eine verwaltete Umgebung zum Erstellen, Prüfen, Freigeben und Verfolgen von ePI — vor und nach der Einreichung bei der EMA. Der funktionsfähige Kern löst den schwierigsten technischen Übergang. Die Produktrichtung ergänzt die umgebende Kontrollschicht.

Die vorgesehene Verwaltungs­umgebung ergänzt:

• Produkte, Zulassungen, Dokumente und Sprachen;
• eigene QRD-Vorlagen, Terminologie und Unternehmensregeln;
• Import von Word und bestehenden FHIR-ePI;
• Versionsverwaltung, aussagekräftige Unterschiede, Rollen, Kommentare und Freigaben;
• automatische FHIR-Erzeugung, lokale Validierung und ein reproduzierbares EMA-Einreichungspaket;
• die Registrierung des manuellen Imports und der Einreichung im PLM Portal;
• die Kontrolle nach der Publikation, indem die ePI über die öffentliche EMA-API abgerufen und mit der freigegebenen Version verglichen wird.

Die letzten beiden Schritte werden bewusst nicht als vollständig automatisiert dargestellt. Die EMA bietet eine öffentliche Lese-API für publizierte ePI, dokumentiert derzeit jedoch keine öffentliche Write-API für die ePI-Einreichung. Das Portal bleibt damit der offizielle Endpunkt, während die Organisation die Kontrolle über Quellen und vorgelagerten Prozess behält.

Diese manuelle Übergabe wird nicht zu einer unsichtbaren Lücke. Die Umgebung zeigt, welches Paket außerhalb des Systems hochgeladen werden muss, und hält SHA-256, Version, freigebende Person und Datum fest. Sie wird als verwaltete private Umgebung oder als Self-hosted/private Cloud bereitgestellt. Elk Solutions kann die Technik betreiben; Inhalte, Rollen und Vorschriften bleiben unter der Kontrolle des Kunden.

Bewusst entsteht kein vollständiges RIM- oder Dokumentenmanagementsystem. Es ist die spezialisierte ePI-Kontrollschicht zwischen bestehenden Quellen, dem PLM Portal und der publizierten ePI-API.

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 public API for published ePI
• 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.