<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DiGA – practitioner knowledge for digital health applications on DUX Healthcare</title><link>https://dux-healthcare.com/en/knowledge/diga/</link><description>Recent content in DiGA – practitioner knowledge for digital health applications on DUX Healthcare</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 22 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://dux-healthcare.com/en/knowledge/diga/index.xml" rel="self" type="application/rss+xml"/><item><title>BfArM Data Protection Criteria – the Practical Deep-Dive</title><link>https://dux-healthcare.com/en/knowledge/diga/data-protection-criteria/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><guid>https://dux-healthcare.com/en/knowledge/diga/data-protection-criteria/</guid><description>&lt;p&gt;By &lt;a href="https://dux-healthcare.com/en/company/about/#thomas-wolters"&gt;Thomas Wolters&lt;/a&gt; · CTO, DUX Healthcare · As of 17 April 2026&lt;/p&gt;
&lt;p&gt;The &lt;strong&gt;BfArM Data Protection Criteria&lt;/strong&gt; are the instrument with which the Federal Institute for Drugs and Medical Devices operationalises the GDPR for Digital Health Applications. Since &lt;strong&gt;1 August 2024&lt;/strong&gt;, DiGA manufacturers have been obliged under &lt;a class="source-cite" href="https://www.gesetze-im-internet.de/digav/__4.html" target="_blank" rel="noopener noreferrer"&gt;DiGAV § 4 Abs. 8&lt;span class="source-cite__arrow" aria-hidden="true"&gt;↗&lt;/span&gt;&lt;/a&gt; to implement the catalogue determined by the BfArM under &lt;a class="source-cite" href="https://www.gesetze-im-internet.de/sgb_5/__139e.html" target="_blank" rel="noopener noreferrer"&gt;§ 139e Abs. 11 SGB V&lt;span class="source-cite__arrow" aria-hidden="true"&gt;↗&lt;/span&gt;&lt;/a&gt;. The current version 1.0 was published on &lt;strong&gt;24 April 2024&lt;/strong&gt; and contains around 150 testable individual requirements across twelve test areas. Unlike the GDPR&amp;rsquo;s general clauses and unlike the purely cybersecurity-oriented BSI TR-03161, the BfArM criteria are explicitly tailored to the DiGA-specific situation: pseudonymous use, purpose-bound processing under § 4(2) DiGAV, strict third-country rules, separate consents, electronic withdrawal routes, grace period after the end of the prescription. This article walks the catalogue in detail – with verbatim-cited requirement IDs, from an engineering perspective, for teams not looking for the checkbox but for the architectural decision.&lt;/p&gt;</description></item><item><title>DiGA AbEM 2026 – the Application-Accompanying Performance Measurement</title><link>https://dux-healthcare.com/en/knowledge/diga/abem-outcomes/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><guid>https://dux-healthcare.com/en/knowledge/diga/abem-outcomes/</guid><description>&lt;p&gt;By &lt;a href="https://dux-healthcare.com/en/company/about/#christoph-eberhardt"&gt;Christoph Eberhardt&lt;/a&gt; · CEO, DUX Healthcare · As of 17 April 2026&lt;/p&gt;
&lt;p&gt;The &lt;strong&gt;application-accompanying performance measurement (AbEM)&lt;/strong&gt; is mandatory from 1 July 2026 for all permanently listed DiGAs with at least one demonstrated medical benefit. The first data delivery to the BfArM follows on 15 April 2027. The most common mistake teams currently make is reading AbEM as a reporting obligation – as a dashboard bolted on at the end of a sprint. AbEM is an &lt;strong&gt;architectural decision&lt;/strong&gt;: it reaches into account model, usage telemetry, in-app survey logic, consent architecture, and data protection concept at the same time – and, through the 20% rule under § 134 SGB V from 2026, it couples a fifth of the reimbursement price to measurable product behaviour. Teams treating AbEM as if it were a dashboard are building the wrong vessel. This article explains why – and what a clean AbEM data model actually requires.&lt;/p&gt;</description></item><item><title>DiGA Approval 2026 – the Practical Guide for Manufacturers</title><link>https://dux-healthcare.com/en/knowledge/diga/approval-guide/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><guid>https://dux-healthcare.com/en/knowledge/diga/approval-guide/</guid><description>&lt;p&gt;By &lt;a href="https://dux-healthcare.com/en/company/about/#christoph-eberhardt"&gt;Christoph Eberhardt&lt;/a&gt; · CEO, DUX Healthcare · As of 17 April 2026&lt;/p&gt;
&lt;p&gt;A DiGA application to the BfArM is not a form you fill out on an afternoon. It is a dossier – 26 data blocks under &lt;a class="source-cite" href="https://www.gesetze-im-internet.de/digav/__2.html" target="_blank" rel="noopener noreferrer"&gt;DiGAV § 2 Abs. 1&lt;span class="source-cite__arrow" aria-hidden="true"&gt;↗&lt;/span&gt;&lt;/a&gt;, with CE documentation, clinical evaluation, certificates for information security and data security, data protection concept, evidence study or evaluation concept, liability insurance proof, price statement, and interoperability evidence. Teams touching the regulatory framework for the first time regularly underestimate two things: first, how much of this must be produced &lt;em&gt;before&lt;/em&gt; the BfArM is even involved, and second, how quickly the BfArM actually works once the dossier is complete. This guide walks through the application stage by stage, shows which components teams regularly recognise too late, what realistic timelines look like, which cost blocks are not on the BfArM website – and what actually happens after the decision. The regulatory backbone sits in the pillar hub &lt;a href="https://dux-healthcare.com/en/knowledge/diga/"&gt;DiGA – Practical Knowledge&lt;/a&gt;; this article is the practical addendum.&lt;/p&gt;</description></item><item><title>BSI TR-03161 Certification – A Practitioner's Guide</title><link>https://dux-healthcare.com/en/knowledge/diga/bsi-tr-03161-certification/</link><pubDate>Sun, 19 Apr 2026 00:00:00 +0000</pubDate><guid>https://dux-healthcare.com/en/knowledge/diga/bsi-tr-03161-certification/</guid><description>&lt;p&gt;By &lt;a href="https://dux-healthcare.com/en/company/about/#thomas-wolters"&gt;Thomas Wolters&lt;/a&gt; · CTO, DUX Healthcare · 17 April 2026&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;BSI TR-03161&lt;/strong&gt; – the &lt;strong&gt;Technische Richtlinie (Technical Guideline) of the Bundesamt für Sicherheit in der Informationstechnik (BSI – Germany&amp;rsquo;s Federal Office for Information Security)&lt;/strong&gt; titled &lt;em&gt;&amp;ldquo;Anforderungen an Anwendungen im Gesundheitswesen&amp;rdquo;&lt;/em&gt; – is the regulatory artefact that decides whether a &lt;strong&gt;DiGA (Digitale Gesundheitsanwendung)&lt;/strong&gt; can be filed at the &lt;strong&gt;BfArM (Bundesinstitut für Arzneimittel und Medizinprodukte)&lt;/strong&gt; or not. Since 1 July 2025, a TR-03161 certificate is a formal precondition for application completeness: no certificate, no listing, full stop (&lt;span class="source-cite source-cite--plain"&gt;DiGA Guide v3.6 Sec. 3.4&lt;/span&gt;). International DTx teams entering Germany routinely treat TR-03161 as a side-track they can handle in a final quarter. In practice it is one of the load-bearing architectural decisions of a DiGA project – the cybersecurity standard against which five DiGAs on our &lt;strong&gt;mHealth Suite&lt;/strong&gt; platform have been individually tested. This article is a practitioner&amp;rsquo;s guide to what TR-03161 actually demands, what certification really costs, where teams stumble, and how the &amp;ldquo;ohne Auflagen&amp;rdquo; (without conditions) vs. &amp;ldquo;mit Auflagen&amp;rdquo; (with conditions) outcome is decided.&lt;/p&gt;</description></item></channel></rss>