Accessible Health Apps: DiGA Duties Under German Law

The entitlement is narrowly drawn. Under Section 33a(1) SGB V, insured persons are entitled to medical devices of lower and higher risk class whose main function is essentially based on digital technologies, and the entitlement covers only those applications that the Federal Institute for Drugs and Medical Devices has entered into the register under Section 139e SGB V and that are either prescribed by a physician or approved by the health insurance fund. Bringing an application into reimbursement is therefore an administrative procedure, not a marketing project – with the same duties of evidence that apply elsewhere in healthcare.

A second line runs in parallel and has nothing to do with the register. Under Section 1(3) BFSG, the Accessibility Strengthening Act applies to services provided to consumers after 28 June 2025 and lists services in electronic commerce under number 5 of that provision. A health app with registration, consent, subscription management or direct purchase therefore operates in both legal spheres at once. What follows from this for native applications is set out in detail in the article on BFSG duties for iOS and Android.

The Social Code itself is clearer than the ordinance in other places. For the electronic patient record, Section 341(1) SGB V provides that information on findings, diagnoses, therapeutic measures carried out and planned as well as treatment reports is to be made available to insured persons electronically in an accessible manner. The word sits in the statutory text, not in an explanatory memorandum. As soon as a digital health application writes data into the record or reads from it, it touches this line.

Section 342 SGB V is more concrete still with regard to the user interface of the record. Paragraph 7 obliges the health insurance funds to ensure, by 1 January 2022 at the latest, that insured persons can exercise their rights and read the log data in an accessible manner via a user interface on both a suitable mobile device and a suitable stationary device. Two device classes, expressly named: the requirement is therefore not limited to the phone view. For the listing procedure the deadline in Section 139e(3) SGB V applies at the same time, under which the federal institute decides within three months of receipt of the complete application documents, extendable by up to three further months in justified individual cases.

A digital health application has one peculiarity that sets it apart from an ordinary online offering: the most valuable part sits behind the login. Redeeming the activation code, consenting to data processing, daily documentation and the export for the treating physician are flows that an external testing tool does not reach. How to cover such areas systematically is described in the article on auditing behind the login.

The second difference is the sign-in itself. Health data call for a procedure with a high security standard, and that is typically where the hardest barriers appear: one-time codes with a short window, image puzzles, swipe gestures for identification. Which alternatives can be implemented without lowering the level of protection is described in the article on accessible authentication. Whether the flow holds up in practice usually only becomes clear in a screen reader test on both platforms.

The most frequent findings in health applications arise at value entry. A field without an associated label, a unit that only sits next to it visually, and an error message that is neither linked to the field nor announced: those three defects together make daily documentation unusable for screen reader users. The following pattern connects label, unit, hint and error to the field and additionally announces the error to assistive technology.

Three points carry this pattern. The label is connected to the field through the for attribute, so it is announced on focus. The unit sits next to the field visually and additionally in the hint text, because a purely visual abbreviation is lost to speech output. The error message names the rejected value and the permitted range instead of merely flagging an error; with the alert role it reaches the screen reader even while focus stays in the field. The second frequent finding sits alongside in presentation: health applications like to fix font sizes so that charts and scales do not shift, and in doing so they block the magnification that part of the target group depends on. The following approach ties typography to the system setting, gives touch targets a minimum size and respects the system setting for reduced motion.

Both patterns are deliberately plain, because in an audit they do not have to convince through elegance but through traceability. An audit report assigns every finding to a place in the code; the simpler that place, the shorter the path from finding to fix. Anyone who tackles accessibility only after the decision negotiates the same changes under time pressure and with a running notification duty in the background. Readers who want the contractual side will find acceptance and defect remedies in the article on accessibility in contracts; how the same logic plays out in a completely different sector is shown in the article on accessible hotel booking.