Die Jira-Integration von CertHub übernimmt Entwickler-Anforderungen aus Jira direkt in die Technische Dokumentation für MDR, IVDR und IEC 62304 — und schließt die Lücke zwischen Entwicklung und Zulassung ohne manuelles Copy-Paste.
Die Lücke zwischen Entwicklung und Zulassung bezeichnet die Trennung zwischen dem Ort, an dem Produktanforderungen entstehen (Jira, genutzt von Entwicklungsteams), und dem Ort, an dem sie für die regulatorische Einreichung dokumentiert werden müssen (Word-Vorlagen, Excel-Rückverfolgbarkeitsmatrizen, bestehende eQMS-Systeme). In den meisten MedTech-Unternehmen werden Anforderungen an beiden Stellen gepflegt, manuell abgeglichen und driften regelmäßig auseinander. Diese Lücke ist eine der führenden Ursachen für Auditbefunde, spät entdeckte Inkonsistenzen und verzögerte Markteinführungen.
Ein einzelnes Medizinprodukt der Klasse IIb umfasst typischerweise Hunderte untereinander verknüpfter Dokumente über QMS, Technische Dokumentation und Kennzeichnung hinweg. Wenn die Quelle der Anforderungen in Jira liegt, die Technische Dokumentation aber manuell gepflegt wird, driften diese Dokumente mit jedem Sprint weiter auseinander.
Die Jira-Integration von CertHub importiert ausgewählte Jira-Issues als strukturierte Anforderungen in das regulatorische Datenmodell von CertHub. Einmal importiert, lassen sich diese Anforderungen aus jeder Einreichungsvorlage referenzieren — Technische Dokumentation, Klinische Bewertung, Gebrauchsanweisung, Kennzeichnung — und bei Bedarf aktualisieren. Das Entwicklungsteam arbeitet weiter in Jira. Das Regulatory-Team liest aus derselben Quelle, ohne irgendetwas abzuschreiben.
CertHub ist ein in Deutschland entwickeltes Regulatory Information Management System (RIMS) für MedTech-Hersteller. Jira ist ein weit verbreitetes Issue-Tracking- und Anforderungsmanagement-Werkzeug von Atlassian, typisch für Software- und Hybridprodukte in der Medizintechnik.
Jedes Mal, wenn sich eine Anforderung in Jira ändert, muss jemand auf der regulatorischen Seite das bemerken, interpretieren und manuell in die nachgelagerten Dokumente fortschreiben. Für einen typischen CertHub-Kunden verteilt sich der Aufwand wie folgt (manuell vs. CertHub, pro Änderung):
| Schritt | Manuell | Mit CertHub |
|---|---|---|
| Impact-Analyse | 2 Stunden | 1 Klick (automatisiert) |
| Dokumente aktualisieren (Klinische Bewertung, IFU, Label) | 4 Stunden | 0,5 Stunden |
| Review und Freigabe | 2 Stunden | 0,5 Stunden |
| Revision der Technischen Dokumentation | 2 Stunden | 1 Klick (automatisiert) |
| Konformitäts-Reassessment | 3 Stunden | 1 Stunde |
| Typischer Gesamtaufwand pro Änderung | ~12 Stunden | ~2 Stunden |
Die Zeilenwerte spiegeln den sequenziellen Aufwand je Schritt wider; der manuelle Gesamtwert rundet sich auf ~12 Stunden, wenn Review- und Dokumentationsschritte in der Praxis teilweise parallel laufen.
Jede Änderung wirkt sich typischerweise auf etwa fünf technische Dokumente aus. Bei sechs Änderungen pro Jahr ergibt das rechnerisch 12 h × 5 TDs × 6 Änderungen = 360 Stunden manueller Aufwand, reduziert auf 60 Stunden mit CertHub — für eine einzige Jurisdiktion. Bei einem voll belasteten Stundensatz von 100 €/h entspricht das einer Differenz von rund 30.000 € pro Jahr.
Die Lücke erzeugt darüber hinaus drei strukturelle Fehlerbilder.
Das Regulatory Information Management System von CertHub basiert auf einer einfachen Umkehrung: Teams pflegen nicht länger Dokumente, sondern ein regulatorisches Datenmodell — eine einzige, strukturierte Repräsentation des Produkts, die Folgendes umfasst:
Dokumente werden zum Output des Datenmodells — nicht mehr zum Ort, an dem Daten eingegeben werden. Ändert sich die Zweckbestimmung einmal, wird jedes betroffene Dokument über alle Produktvarianten und Jurisdiktionen hinweg automatisch nachgezogen.
Damit dieses Modell funktioniert, muss das Datenmodell aus den Systemen gespeist werden, die die Teams ohnehin nutzen. Jira ist das erste und häufigste dieser Systeme.
Eine Nutzerin oder ein Nutzer aus dem Regulatory- oder QM-Team autorisiert CertHub über einen Standard-Berechtigungsfluss, aus Jira zu lesen. Die Verbindung wird einmal pro Workspace eingerichtet und für jede weitere Synchronisation wiederverwendet.
CertHub zeigt die verfügbaren Jira-Projekte. Ausgewählt wird das Projekt, in dem die Produktanforderungen liegen — typischerweise das Projekt, das das Entwicklungsteam für den Release-Scope pflegt.
CertHub listet die Issues des Projekts. Anforderungen bleiben. Testfälle, Spikes oder interne Entwicklungstickets lassen sich ausfiltern. Übrig bleibt die Teilmenge an Jira-Issues, die tatsächlich in die regulatorische Dokumentation gehört.
Die ausgewählten Anforderungen landen als strukturierte Einträge im Anforderungsbereich von CertHub — nicht als eingefrorener Screenshot, sondern als lebendige Referenzen. Sie lassen sich abfragen, verknüpfen und in Einreichungsvorlagen einbetten. Eine spätere Synchronisation bringt das Datenmodell wieder mit dem aktuellen Stand in Jira in Deckung.
MDR Anhang II verlangt eine dokumentierte Nachweiskette von der Zweckbestimmung über die Risikoanalyse und die Design-Verifizierung bis zur klinischen Evidenz. Jedes Glied dieser Kette muss in Daten verankert sein, die aktuell, konsistent und vor einer Benannten Stelle verteidigungsfähig sind.
Stammen die Anforderungen per Live-Synchronisation aus Jira, werden drei Dinge möglich, die manuelles Copy-Paste nicht zuverlässig leisten kann.
Für Teams, die nach IEC 62304 für Software-Lebenszyklusprozesse arbeiten, ist der Punkt noch schärfer: Software-Anforderungen leben naturgemäß in Jira, und sie direkt an das regulatorische Datenmodell zu binden, ist, wie ein moderner Software-Lebenszyklusprozess aussehen sollte.
Jira ist für die meisten MedTech-Teams die erste Integration, weil Software-Anforderungen dort am häufigsten liegen. Es ist nicht die einzige unterstützte Quelle. Das regulatorische Datenmodell von CertHub ist so konzipiert, dass es aus den Systemen einliest, die die Teams ohnehin nutzen:
Aus demselben Datenmodell erzeugt CertHub Einreichungen für:
Aus derselben Quelle werden auch EUDAMED, Swissdamed und GUDID gespeist.
Zwei Situationen zeigen, wo die Integration ihren Platz verdient.
Wenn Entwickelnde eine Anforderung in Jira ändern. Im klassischen Ablauf passiert auf der regulatorischen Seite erst einmal gar nichts, bis jemand es bemerkt. Das Ticket kann wochenlang in „Done" stehen, bevor ein QM-Engineer registriert, dass die Verifikationsstrategie in der Technischen Dokumentation nicht mehr stimmt. Mit der Jira-Integration taucht die Änderung beim nächsten Sync im regulatorischen Datenmodell auf. Die KI-gestützte Impact-Analyse von CertHub markiert die betroffenen Dokumente. Der Handlungsbedarf ist vor dem nächsten Audit bekannt — nicht danach.
Wenn das Regulatory-Team eine Einreichung vorbereitet. Im klassischen Ablauf heißt das: den aktuellen Stand dutzender Jira-Tickets mit Word-Dokumenten abgleichen, die vor drei Sprints aktuell waren, und in Excel eine Rückverfolgbarkeitsmatrix erzeugen, die beim Speichern schon wieder überholt ist. Mit CertHub zieht sich der Anforderungsteil der Einreichungsvorlage direkt aus dem aktuellen Datenbestand. Die Rückverfolgbarkeitskette wird aus dem Modell generiert, nicht von Hand rekonstruiert.
Teams, die am ersten Tag den größten Nutzen ziehen, teilen drei Merkmale:
Für diese Teams ist die Integration weniger ein Feature als eine Richtungsentscheidung: Das Regulatory-Team pflegt keine eigene Kopie der Anforderungen mehr, sondern liest die Version, die die Entwicklung ohnehin pflegt.
Die Standard-Einführung von CertHub dauert vom Kick-off bis zum vollen Betrieb acht Wochen.
Vier Erfolgsfaktoren verankern den Zeitplan: bestehende Daten aus jedem System übernehmen; KI-gestützte Strukturierung in das regulatorische Datenmodell; automatische Fortschreibung durch Single-Source-of-Truth-Logik; und weltweite Einreichungen aus einer gemeinsamen Basis.
Alle Produkt- und Regulierungsdaten, die CertHub verarbeitet, werden ausschließlich in europäischen Rechenzentren in Frankfurt gespeichert. Es gibt keinen Transfer in die USA oder andere Drittländer und keine Abhängigkeit von US-Infrastrukturpartnern. Der relevante Compliance-Stand (Stand 2026):
Was synchronisiert die Jira-Integration von CertHub tatsächlich? Sie importiert vom Nutzer ausgewählte Jira-Issues (typischerweise Anforderungen) als strukturierte Einträge in das regulatorische Datenmodell von CertHub. Testfälle, Spikes und andere Nicht-Anforderungs-Tickets lassen sich beim Import ausfiltern.
Hält die Integration die Daten über die Zeit synchron? Ja. Einmal importiert, werden Anforderungen referenziert — nicht kopiert — und können bei Bedarf aktualisiert werden. Eine Aktualisierung bringt das regulatorische Datenmodell wieder mit dem aktuellen Stand in Jira in Deckung.
Welche Regulierungen und Standards werden unterstützt? Die Integration speist das regulatorische Datenmodell von CertHub, das EU MDR 2017/745, EU IVDR 2017/746, FDA 510(k), UK MDR (MHRA), Swissmedic, ANVISA, Health Canada (CMDR), TGA, IMDRF/MDSAP und den EU AI Act unterstützt. Sie ist explizit auf ISO 13485, ISO 14971, IEC 62304, IEC 62366 und die Rückverfolgbarkeitsanforderungen aus MDR Anhang II ausgerichtet.
Ist das für SaMD und IEC 62304 geeignet? Ja. Software-Anforderungen leben naturgemäß in Jira, was SaMD-Teams unter IEC 62304 zum primären Anwendungsfall macht. Die Integration bindet Jira-Anforderungen direkt an das regulatorische Datenmodell und unterstützt damit die Rückverfolgbarkeit im Software-Lebenszyklus.
Kann CertHub an andere Werkzeuge als Jira angebunden werden? Ja. Das Datenmodell von CertHub liest aus Polarion, DOORS, Dassault, Word, Excel, bestehenden eQMS- und Dokumentenmanagementsystemen, PDFs und SharePoint ein. Jira ist die häufigste erste Integration, weil Software-Anforderungen typischerweise dort liegen.
Wo werden unsere Daten gespeichert, wenn wir CertHub nutzen? In europäischen Rechenzentren in Frankfurt. Es gibt keinen Transfer in die USA oder andere Drittländer. CertHub ist DSGVO-konform und ISO 27001 zertifiziert.
Wie viel Zeit können wir konkret sparen? Im Kostenmodell von CertHub — basierend auf typischen MedTech-Arbeitsabläufen — sinkt der Aufwand pro regulatorischer oder produktbezogener Änderung von rund 12 Stunden auf 2 Stunden. Bei sechs Änderungen pro Jahr mit jeweils etwa fünf betroffenen technischen Dokumenten in einer Jurisdiktion sind das rund 300 gesparte Stunden pro Jahr, bzw. etwa 30.000 € bei einem voll belasteten Stundensatz von 100 €/h. Die tatsächlichen Einsparungen hängen vom Portfolio und Dokumentenumfang ab.
Wie lange dauert es bis zum Betrieb? Acht Wochen vom Kick-off bis zum vollen Betrieb, einschließlich Konfiguration, Datenübernahme und Nutzer-Onboarding.
Was passiert, wenn wir CertHub verlassen? CertHub unterstützt ein vollständiges Off-Boarding und die Datenübergabe. Kundendaten bleiben Eigentum des Kunden.
Die Jira-Integration steht CertHub-Kunden als Teil des Regulatory Information Management Systems zur Verfügung. Sie ist die erste einer Reihe von Anbindungen, die die Werkzeuge, mit denen MedTech-Teams ohnehin arbeiten, an das eine regulatorische Datenmodell binden, aus dem weltweit eingereicht wird.
Demo buchen — um die Jira-Anbindung in Aktion zu sehen.
CertHub bietet Software für digitales Qualitätsmanagementsystem (QMS) und Technische Dokumentation, damit Hersteller von Medizinprodukten ihre Produkte deutlich schneller auf den Markt bringen können.
© CertHub 2025
