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.

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.