Eine verwaltete Umgebung für ePI. Vor und nach der EMA.

Eine verwaltete Umgebung zum Erstellen, Prüfen, Freigeben und Verfolgen von ePI — vor und nach der Einreichung bei der EMA. Das ist die Kernproposition.

Ein Medical Writer ändert eine genehmigte Arzneimittelinformation in Word. Die Organisation muss danach nicht nur dieselbe Bedeutung als FHIR liefern, sondern auch wissen, welche Quelle, Regeln, Prüfung und Version zu dieser Lieferung geführt haben — und ob nach der Publikation dasselbe Ergebnis verfügbar wurde.

Das PLM Portal der EMA enthält einen ePI-Editor. Die aktuelle EMA-FAQ erlaubt Zulassungsinhabern außerdem ausdrücklich, FHIR-ePI mit eigenen Systemen oder Dienstleistern zu erzeugen und anschließend zu importieren. Das Portal ist damit das offizielle Ziel; es muss nicht die tägliche Verwaltungsumgebung oder die einzige Quelle der Wahrheit sein.

Elk Solutions entwickelt deshalb keinen zweiten isolierten Editor, sondern eine spezialisierte ePI-Kontrollschicht. Der bestehende Transformationskern weist den kontrollierten Word↔FHIR-Übergang bereits nach. Die umgebende Verwaltungs­umgebung befindet sich in der Designpartnerphase.

Eine Umgebung, eine nachweisbare Kette

Word, FHIR und das EMA-Portal müssen nicht dieselbe Aufgabe erfüllen.

Word eignet sich weiterhin für Schreiben, Änderungsverfolgung, Kommentare und etablierte Freigabeprozesse. FHIR hält fest, welches Dokument, welche Sprache und welchen offiziellen ePI-Abschnitt ein Text repräsentiert. Wert entsteht, wenn beide Seiten nachweislich auf dieselben Inhalte verweisen.

Der Transformationskern verwendet FHIR als kanonische Struktur und erzeugt daraus ein kontrolliertes DOCX. Jeder Abschnitt erhält eine stabile Identität, einen Quellhash und einen Inhaltsfingerabdruck. Nach einer Änderung in Word werden nur nachweislich geänderte Abschnittstexte zurückgeschrieben. Ein semantischer Diff zeigt anschließend, was sich geändert hat und was nicht.

Die vorgesehene Verwaltungs­umgebung führt zusammen, was heute leicht zersplittert:

• Produkte, Zulassungen, Dokumente und Sprachen;
• eigene QRD-Vorlagen, Terminologie und Unternehmensregeln;
• Import von Word und bestehenden FHIR-ePI;
• Versionsverwaltung und aussagekräftige Unterschiede zwischen Versionen;
• getrennte Rollen für Autor, Reviewer und letztverantwortliche Person;
• dokumentierte Kontrollen, Kommentare und Freigaben;
• automatische FHIR-Erzeugung und lokale Validierung;
• ein vollständiges und reproduzierbares EMA-Einreichungspaket;
• einen sichtbaren Status: Entwurf → geprüft → freigegeben → bereit für EMA → eingereicht → publiziert;
• nach der Publikation: ePI über die öffentliche EMA-API abrufen und automatisch mit der freigegebenen Version vergleichen.

Die EMA dokumentiert derzeit eine öffentliche Lese-API für publizierte ePI, aber keine öffentliche Write-API für die automatisierte Einreichung. Die Portalhandlung bleibt deshalb sichtbar Teil der Kette, statt eine nicht vorhandene Automatisierung vorzutäuschen.

Aktion außerhalb des Systems erforderlich

Paket EP-2026-0042 im PLM Portal hochladen. SHA-256, Version, freigebende Person und Datum sind dokumentiert.

Sobald die EMA die ePI publiziert, ruft die Umgebung das Ergebnis über die öffentliche API ab. Erst ein semantisch grüner Vergleich schließt die Nachweiskette.

Die Produktgrenze: Kontrollschicht statt RIM oder DMS

Die Umgebung ersetzt kein allgemeines Dokumentenmanagement- oder Regulatory- Information-Management-System. Sie verbindet bestehende Quellen und Systeme mit dem offiziellen EMA-Prozess und kontrolliert gezielt den ePI-Übergang:

Bestehende Quellen und Systeme
             ↓
      ePI-Verwaltungsumgebung
 strukturieren · prüfen · reviewen
       nachweisen · exportieren
             ↓
        EMA PLM Portal
             ↓
      Publizierte ePI-API
             ↓
 automatische Abschlusskontrolle

Die Umgebung kann in zwei Formen bereitgestellt werden:

• verwaltete private Umgebung: Elk Solutions betreibt die Technik; der Kunde verwaltet Inhalte, Rollen und Vorschriften;
• Self-hosted/private Cloud: Quellinformationen und Verwaltung bleiben vollständig in der eigenen Infrastruktur der Organisation.

So wird „unter eigener Regie“ zu einer nachweisbaren Systementscheidung statt zu einer bloßen Marketingaussage.

Was die Erprobung heute beweist

Der aktuelle Demonstrator durchläuft eine vollständige, begrenzte Kette:

1. ein öffentliches EMA-FHIR-Beispiel wird gelesen;
2. die 32 verschachtelten SmPC-Abschnitte werden zu einem kontrollierten Word-Dokument;
3. genau eine sichtbare Textänderung wird vorgenommen;
4. nur diese geänderte Narrative wird im ursprünglichen FHIR gepatcht;
5. 31 andere Abschnitte und nicht narrative Inhalte bleiben erhalten;
6. ein semantischer Differenzbericht macht das Ergebnis prüfbar;
7. der offizielle HL7 FHIR Validator mit EMRN-ePI-Profil meldet 0 Fehler und 0 Warnungen.

Die automatisierte Suite umfasst 27 Tests. Der Java-Code erreicht 88,44 % Line Coverage und 75,04 % Branch Coverage. Das stützt den technischen Nachweis, ersetzt aber keinen Praxistest mit Ihrem eigenen Dokumentenworkflow.

Was die Verwaltungs­umgebung noch nicht beweist

Die Grenze ist ebenso wichtig wie das grüne Ergebnis.

• Der funktionierende Roundtrip verwendet ein von der Lösung kontrolliertes DOCX; beliebige historische QRD-Dokumente werden noch nicht frei erkannt.
• Die vollständige Erprobung nutzt ein öffentliches englisches CAP- SmPC-Beispiel; mehrsprachige Portfolioverarbeitung ist noch keine Produktfunktion.
• Portfolio- und Sprachverwaltung, Benutzerrollen, Freigabeflüsse, eigene Regelsätze, Übergaberegistrierung und RIM-Integration sind noch nicht als Produktionsdienst umgesetzt.
• Der Vergleich mit über die EMA-API publizierten ePI ist ein geplanter nächster Schritt; der aktuelle Demonstrator führt diese abschließende Kontrolle noch nicht aus.
• Die EMA bietet für ePI derzeit keine öffentlich dokumentierte Write-API. Import, formale Einreichung und Publikation bleiben daher Schritte im PLM Portal und bei der zuständigen Behörde.
• Der offizielle Validator prüft FHIR- und Profilregeln. Ein grüner Validator beweist nicht eigenständig, dass jede inhaltliche Regulatory-Entscheidung richtig ist.
• Für den eigenen Projektcode wurde noch keine öffentliche Softwarelizenz gewählt.

Dies ist daher ein funktionsfähiger Kern mit einer Verwaltungs­umgebung in der Designpartnerphase, keine fertige ePI-Plattform.

Wo der erste praktische Wert liegt

Der erste verkaufbare Wert ist weder „ein DOCX erzeugen“ noch „noch ein Editor“. Er liegt in drei Entscheidungsmomenten:

• Preflight vor dem Upload: technische und profilbezogene Probleme früher im Einreichungsprozess finden;
• Roundtrip-Nachweis nach einer Änderung: zeigen, welche Abschnitte sich änderten, welche erhalten blieben und was weiterhin menschliche Prüfung verlangt.
• Verwaltungsnachweis rund um die Übergabe: nachvollziehbar festhalten, welche Quelle, Regeln, Freigabe und Paketversion an das PLM Portal gingen, und nach der Publikation prüfen, was tatsächlich verfügbar wurde.

Das ist besonders relevant für Regulatory Operations, Product-Information- und Labelling-Teams, Medical-Writing-Agenturen, Submission Service Provider und RIM-Integratoren. Ein Dienstleister oder Integrator mit mehreren Kundenworkflows ist wahrscheinlich der stärkste erste Designpartner.

Warum jetzt

Die europäische Einführung erfolgt stufenweise. Die EMA-Roadmap beschreibt eine freiwillige operative Nutzung für zentral zugelassene Produkte ab Ende 2026, zunächst für Impfstoffe, danach für Onkologie und anschließend breiter. Word und PDF bestehen anfangs neben ePI fort.

Damit ist jetzt der richtige Zeitpunkt, nicht nur FHIR erzeugen zu lernen, sondern den gesamten Weg von der verwalteten Quelle bis zum publizierten Ergebnis nachweisbar zu machen.

Quellen

• EMA ePI Frequently Asked Questions
• EMRN ePI Implementation Guide
• EMA ePI user guide for applicants
• EMA public API for published ePI
• EMA ePI implementation roadmap