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.

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.