In many digital health teams, compliance is an event rather than a process: once a year, shortly before an audit or certification, someone checks where things stand. Every line of code written between two such deadlines goes unassessed until the next one – and the gaps discovered then are expensive to fix.
azuma nori supports both modes of operation: the classic gap analysis as a snapshot, and headless operation, which lets you automate the check inside your CI/CD pipeline. This article shows how to move from point-in-time to continuous compliance.
There's a translation gap between a regulatory requirement and the line of code that satisfies it. On one side stands a regulatory or compliance lead who knows BSI TR-03161 or the EU Cyber Resilience Act. On the other, a development team that wants to ship, but rarely has time to work through several hundred pages of technical guideline. Translating between the two worlds costs time, money, and patience – and is the real friction in the compliance process.
This article describes where that gap comes from, what it costs, and how azuma nori closes it by translating regulatory requirements directly into concrete, verifiable statements about the codebase.
For most digital health companies, source code is the most valuable asset – and also the most sensitive one. That's exactly why it's a problem that many compliance and code-analysis tools require you to upload your code to a third-party cloud for analysis. You trade compliance for losing control over your own IP.
azuma nori takes the opposite approach: the analysis runs locally on the developer's machine, and the source code never leaves the device. This article explains why that makes a real difference, both architecturally and legally.
The Cyber Resilience Act (CRA) is no longer a future concern – it's applicable EU law. The first hard obligations kick in on September 11, 2026, and the regulation applies in full from December 11, 2027. For digital health providers, this raises a question many still underestimate: where exactly does the CRA apply to me – and what about my software supply chain?
This article explains what the CRA requires, which deadlines apply, how it relates to medical device regulation (MDR), and what this means in practice for DiGAs, health apps, and their suppliers.
While the GesundheitsID is just finding its way into everyday DiGA use, the next major identity wave is already emerging at the European level: the EUDI Wallet. By the end of 2026, every EU member state must provide its citizens with such a digital wallet – and healthcare is one of the sectors required to accept it first. For DiGA manufacturers and Digital Health providers or developers, it pays to understand this topic now, while you can still stay ahead of the market.
This article provides an outlook: what the EUDI Wallet is, what the timeline looks like, why healthcare is particularly affected, and how the wallet relates to the GesundheitsID.
The Telematics Infrastructure (TI) is the digital backbone of the German healthcare system – and it is currently undergoing the biggest transformation in its history. Under the banner of TI 2.0, gematik is gradually replacing the hardware-centric architecture of connectors and cards with an internet-based, identity-centric model. For DiGA manufacturers, this is not a distant infrastructure question, but the framework in which GesundheitsID, ePA, and e-prescriptions operate.
This article explains what changes with TI 2.0, how the sectoral identity federation works, and what this specifically means for connecting your application.
Almost every DiGA team faces the same question early on: "We know Keycloak / Auth0 – can't we just use that?" A valid consideration, as both are mature Identity & Access Management systems. The honest answer is: For the login of a standard web application, yes – for a regulated digital health application with GesundheitsID and BSI TR-03161 requirements, you will hit clearly identifiable limits.
This article categorizes what Keycloak and Auth0 do well, where they reach their limits in the healthcare context, and when a specialized Health IAM is the better choice.
Since January 1, 2025, self-declarations are a thing of the past: DiGA manufacturers must prove compliance with data security requirements via an official certificate according to BSI TR-03161 to be included in the DiGA directory. This has turned a recommendation into a strict admission requirement – and for many teams, the critical path to reimbursement.
This article explains what the BSI TR-03161 is, what requirements it sets, how the certification works, and what specifically matters regarding authentication and identity management.
Since January 2024, it has been mandatory for DiGA manufacturers to enable their users to authenticate via the GesundheitsID (Health ID). What sounds like a manageable "just another login method" turns out to be one of the more complex integration projects on the way to the DiGA directory – because behind it is not just an OAuth flow, but the entire sectoral identity federation of the telematics infrastructure (TI 2.0).
This article explains what the GesundheitsID is, why it is mandatory, how the integration works technically, where the real hurdles lie, and how you provide the proof required by the BfArM.
We are pleased to announce that azuma healthtech has officially been accepted into the Spitzenverband Digitale Gesundheitsversorgung (SVDGV) (Digital Healthcare Association).