Compliance ist in vielen Digital-Health-Teams ein Ereignis, kein Prozess: Einmal im Jahr, kurz vor Audit oder Zertifizierung, wird geprüft, wo man steht. Alles, was zwischen zwei solchen Stichtagen an Code entsteht, bleibt bis zum nächsten Stichtag unbewertet – und die dabei entdeckten Lücken sind dann teuer nachzubessern.
azuma nori unterstützt beide Betriebsarten: die klassische GAP-Analyse als Momentaufnahme und den headless Betrieb, mit dem sich die Prüfung in der CI/CD-Pipeline automatisieren lässt. Dieser Artikel zeigt, wie sich damit von punktueller zu kontinuierlicher Compliance wechseln lässt.
Zwischen einer regulatorischen Anforderung und der Zeile Code, die sie erfüllt, liegt eine Übersetzungslücke. Auf der einen Seite steht ein Regulatory- oder Compliance-Verantwortlicher, der die BSI TR-03161 oder den EU Cyber Resilience Act kennt. Auf der anderen Seite ein Entwicklungsteam, das liefern will, aber selten Zeit hat, sich durch mehrere hundert Seiten Technische Richtlinie zu arbeiten. Die Übersetzung zwischen beiden Welten kostet Zeit, Geld und Nerven – und ist die eigentliche Reibung im Compliance-Prozess.
Dieser Artikel beschreibt, wo diese Lücke entsteht, was sie kostet und wie azuma nori sie schließt, indem es regulatorische Anforderungen direkt in konkrete, überprüfbare Aussagen über die Codebasis übersetzt.
Der Quellcode ist bei den meisten Digital-Health-Unternehmen das wertvollste Asset – und zugleich das sensibelste. Genau deshalb ist es ein Problem, dass viele Compliance- und Code-Analyse-Werkzeuge verlangen, den Code in eine fremde Cloud hochzuladen, um ihn dort zu analysieren. Man tauscht Compliance gegen Kontrollverlust über die eigene IP.
azuma nori geht den umgekehrten Weg: Die Analyse läuft lokal auf der Maschine der Entwickler, der Quellcode verlässt das Gerät nicht. Dieser Artikel erklärt, warum das architektonisch und rechtlich einen echten Unterschied macht.
Der Cyber Resilience Act (CRA) ist keine Zukunftsmusik mehr – er ist geltendes EU-Recht. Ab dem 11. September 2026 greifen die ersten harten Pflichten, ab dem 11. Dezember 2027 gilt die Verordnung vollständig. Für Digital-Health-Anbieter stellt sich damit eine Frage, die viele noch unterschätzen: Wo genau betrifft mich der CRA – und was ist mit meiner Software-Lieferkette?
Dieser Artikel erklärt, was der CRA verlangt, welche Fristen gelten, wie er sich zur Medizinprodukte-Regulierung (MDR) verhält und was das konkret für DiGAs, Health-Apps und ihre Zulieferer bedeutet.
Während die GesundheitsID gerade erst in den DiGA-Alltag einzieht, zeichnet sich auf europäischer Ebene die nächste große Identitäts-Welle ab: die EUDI Wallet. Bis Ende 2026 muss jeder EU-Mitgliedstaat seinen Bürgerinnen und Bürgern eine solche digitale Brieftasche bereitstellen – und das Gesundheitswesen gehört zu den Sektoren, die sie als Erste akzeptieren müssen. Für DiGA-Hersteller und Digital Health Anbieter bzw. Entwickler lohnt es sich, das Thema jetzt zu verstehen, solange man dem Markt noch voraus ist.
Dieser Artikel gibt einen Ausblick: Was die EUDI Wallet ist, welcher Zeitplan gilt, warum Healthcare besonders betroffen ist und wie sich das Wallet zur GesundheitsID verhält.
Die Telematikinfrastruktur (TI) ist das digitale Rückgrat des deutschen Gesundheitswesens – und sie durchläuft gerade den größten Umbau ihrer Geschichte. Unter dem Stichwort TI 2.0 löst die gematik die hardwarezentrierte Architektur aus Konnektoren und Karten schrittweise durch ein internetbasiertes, identitätszentriertes Modell ab. Für DiGA-Hersteller ist das keine ferne Infrastruktur-Frage, sondern der Rahmen, in dem GesundheitsID, ePA und E-Rezept funktionieren.
Dieser Artikel erklärt, was sich mit TI 2.0 ändert, wie die sektorale Identity-Föderation funktioniert und was das konkret für die Anbindung deiner Anwendung bedeutet.
Fast jedes DiGA-Team stellt sich früh dieselbe Frage: „Wir kennen Keycloak / Auth0 – können wir das nicht einfach nehmen?" Eine berechtigte Überlegung, denn beide sind ausgereifte Identity-&-Access-Management-Systeme. Die ehrliche Antwort lautet: Für den Login einer Standard-Webanwendung ja – für eine regulierte Digital-Health-Anwendung mit GesundheitsID und BSI-TR-03161-Pflicht stößt man damit an klar benennbare Grenzen.
Dieser Artikel ordnet ein, was Keycloak und Auth0 gut können, wo sie im Gesundheitskontext an Grenzen stoßen und wann ein spezialisiertes Health-IAM die bessere Wahl ist.
Seit dem 1. Januar 2025 ist Schluss mit der Selbsterklärung: DiGA-Hersteller müssen die Einhaltung der Datensicherheits-Anforderungen über ein offizielles Zertifikat nach der BSI TR-03161 nachweisen, um ins DiGA-Verzeichnis aufgenommen zu werden. Damit ist aus einer Empfehlung eine harte Zulassungsvoraussetzung geworden – und für viele Teams der kritische Pfad auf dem Weg in die Erstattung.
Dieser Artikel erklärt, was die BSI TR-03161 ist, welche Anforderungen sie stellt, wie die Zertifizierung abläuft und worauf es speziell beim Thema Authentisierung und Identitätsmanagement ankommt.
Seit Januar 2024 ist es für DiGA-Hersteller verpflichtend, die Authentifizierung ihrer Nutzerinnen und Nutzer über die GesundheitsID zu ermöglichen. Was nach einem überschaubaren „noch-ein-Login-Verfahren" klingt, entpuppt sich in der Praxis als eines der komplexeren Integrationsprojekte auf dem Weg ins DiGA-Verzeichnis – weil dahinter nicht nur ein OAuth-Flow steckt, sondern die gesamte sektorale Identity-Föderation der Telematikinfrastruktur (TI 2.0).
Dieser Artikel erklärt, was die GesundheitsID ist, warum sie Pflicht ist, wie die Integration technisch funktioniert, wo die echten Hürden liegen und wie du den vom BfArM geforderten Nachweis erbringst.
Wir freuen uns bekanntzugeben, dass azuma healthtech offiziell in den Spitzenverband Digitale Gesundheitsversorgung (SVDGV) aufgenommen wurde.