DiGA AbEM 2026 – the Application-Accompanying Performance Measurement

By Christoph Eberhardt · CEO, DUX Healthcare · As of 17 April 2026

The application-accompanying performance measurement (AbEM) 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 architectural decision: 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.

What AbEM is – and what it is not

The application-accompanying performance measurement (AbEM) was introduced with the Digital Act (DigiG) and the 2nd DiGAV Amendment Ordinance of 27.01.2026. Legally it sits in § 139e Abs. 13 SGB V↗ (BfArM publication duty from 01.01.2026, authorisation to issue regulations for sentence 3 no. 1–3) and in the newly inserted Section 6a DiGAV (§§ 23a–23e) (operational design). The DiGA-Leitfaden v3.6 Ch. 6 sets out the operating details. The ministerial draft of the 2nd DiGAV AmendV of 03.01.2025 already defined Stages I and II in full substance – including the question catalogue in Annex 3 and the dataset structure in Annex 4; the final DiGAV of 27.01.2026 took over this structure and added the BfArM list of indication-specific questionnaires for Stage III (§ 23e(3)).

Three distinctions needed in almost every first conversation about AbEM:

1. AbEM is not the evidence study under § 10 DiGAV. The evidence study is a one-off comparative demonstration. AbEM runs continuously from listing, without a comparator, without pre-specification, without an endpoint – it has a calendar.
2. AbEM is not the 20% rule. The 20% rule is a reimbursement mechanism in § 134(1) sentence 3 SGB V; the manufacturer’s duty to transmit AbEM results arises from § 134(1) sentence 4 no. 3 SGB V. AbEM is the data substrate that makes this coupling operationalisable.
3. AbEM is not marketing analytics. Engagement tracking, funnel metrics, and retention cohorts from product analytics do not fulfil AbEM requirements: the DiGAV prescribes definitions, collection timing, tolerance windows, data formats, and consent architecture down to the detail (DiGAV § 23c Abs. 5; DiGA-Leitfaden v3.6 Kap. 6.2.2).

One hard limit teams regularly overlook: the AbEM obligation applies only to DiGAs for which permanent listing has already been decided – not to DiGAs in the trial period. In addition, the PROM and patient satisfaction collection (§§ 23d, 23e) is waived for DiGAs whose positive care effects have been demonstrated exclusively via pSVV (DiGAV § 23a Abs. 1 Satz 2). The choice between medical benefit (mN) and pSVV therefore has not only an evidence consequence but an AbEM consequence.

Stages I / II / III – staggered through 2029

AbEM is introduced in three stages, each with its own collection and reporting dates (DiGA-Leitfaden v3.6 Kap. 6.2, 6.4).

From the respective first report, manufacturers deliver half-yearly electronically to the BfArM: quarters I and II by 15 October of the current year, quarters III and IV by 15 April of the following year (DiGAV § 23a Abs. 3).

Stage I – usage data, operationally sharp

The usage data are the operationally sharpest stage because the definitions are hard and the collection arises technically in the app:

• Usage volume: average time of use per week in minutes, over the period from the day of the entry of the activation code until the end of the usage duration (for DiGAs with usage duration > 90 days: 90 days) (DiGAV § 23c Abs. 2). To be reported are mean, standard deviation, minimum, maximum, median, lower and upper quartile – each per week.
• Usage frequency: average number of usage events per week, same metrics (DiGAV § 23c Abs. 3).
• Discontinuation: for a usage duration ≥ 90 days, an uninterrupted non-use of three weeks (21 days) counts as discontinuation. For a usage duration < 90 days, a non-use of 25% of the usage duration counts as discontinuation (at 40 days prescription duration: 10 days). Users resuming after the discontinuation criterion has been met still count as discontinuers; the post-hoc data are not reported (DiGAV § 23c Abs. 4; DiGA-Leitfaden v3.6 Kap. 6.2.2.3).

Six discontinuation metrics are to be reported per quarter: total number and rate of discontinuers, distribution of discontinuations over the weeks of the usage duration, total number and rate of users with complete use, and the average number of days to discontinuation (DiGAV § 23c Abs. 5).

Stage II – PGI-C and patient satisfaction

From 01.07.2027 two actively collected instruments complement the passively captured usage data:

• Patient Global Impression of Change (PGI-C): a 7-point scale for subjective change in health status since the start of use (“very much better” to “very much worse”). Single collection at the end of the usage duration (if > 90 days: after 90 days), tolerance window −7 to 0 days. Answers outside the window count as missing values (DiGA-Leitfaden v3.6 Kap. 6.2.3; DiGAV § 23d Abs. 2).
• Patient satisfaction: five items on an 11-point scale (0–10), in prescribed order, each question to be answered individually and confirmed. Question 5 is the Net Promoter Score. Single collection at the halfway point of the usage duration (if > 90 days: after 45 days), tolerance window −7 to 0 days (DiGA-Leitfaden v3.6 Kap. 6.2.4; DiGAV § 23d Abs. 3; questionnaire template: DiGAV Anlage 3).

Participation in §§ 23d and 23e is voluntary for insured persons; manufacturers are obliged to inform about this voluntariness (DiGAV § 23a Abs. 4).

Stage III – indication-specific PROMs

From 01.07.2028 a third dimension joins: an indication-specific PROM from a list to be published by the BfArM (§ 23e(3) DiGAV; publication by 01.07.2027). Suitable questionnaires shall contain no more than ten items. Collection is twofold: directly after activation (baseline) and at the end of the usage duration or after 90 days. The tolerance window at the end is again −7 to 0 days (DiGA-Leitfaden v3.6 Kap. 6.2.5; DiGAV § 23e Abs. 4).

Two refinements easily skipped in product discussions:

• If a DiGA has demonstrated multiple medical benefits, reporting on one pVE via indication-specific PROM suffices – the choice is the manufacturer’s (DiGA-Leitfaden v3.6 Kap. 6.2.5).
• If a DiGA has demonstrated exclusively pSVV, PROM collection is waived entirely (DiGAV § 23a Abs. 1).
• Manufacturers must notify the BfArM three months before start of collection which questionnaire they have chosen from the BfArM list (DiGAV § 23e Abs. 3).

The 20% rule – how reimbursement changes from 2026

§ 134(1) sentence 3 SGB V prescribes that the reimbursement agreement between the GKV-Spitzenverband and the manufacturer, from 01.01.2026, shall provide a share of performance-dependent price components of at least 20% of the reimbursement price; the transmission of AbEM results to the GKV-SV is anchored in § 134(1) sentence 4 no. 3 SGB V (§ 134 Abs. 1 SGB V↗). The specific design – which AbEM metric at what weighting steers the 20% – is, per DiGA-Leitfaden v3.6 Ch. 6.1, still to be determined by the framework agreement partners (DiGA-Leitfaden v3.6 Kap. 6.1).

Three consequences that land in product and pricing discussions at the same time:

1. The risk of “marketed but ineffective” shifts. A part of the payer risk migrates into ongoing measurement.
2. Retention and discontinuation rates become price-relevant. In Stage I, usage and discontinuation data are the only available metrics; from 2027 PGI-C joins, from 2028 indication-specific PROMs. Product development must grow with the weighting in the framework agreement.
3. Two-stage price negotiation. DiGA price negotiation becomes structurally two-stage: one-off on the base reimbursement price, continuously on the AbEM metrics. Teams negotiating in 2026 are not negotiating a price but a measurement logic.

The readings differ – and, remarkably, they are closer to one another than political camp thinking might suggest. The GKV-Spitzenverband sees, in the mandatory AbEM and the performance-dependent price components, per DiGA-Bericht 2025 (§ 33a(6) SGB V report, status 31.12.2025), a “disproportionate build-up of bureaucratic instruments” and also points to the time lag: the reimbursement-agreement deadline (01.01.2026) and the AbEM data-delivery deadline (from 15.04.2027) do not correspond (GKV-Spitzenverband DiGA-Bericht 2025, Abschnitt 1.1↗). The SVDGV criticises from an industry perspective: the effort is out of proportion to the foreseeable insights, AbEM threatens to impair use and adherence through additional in-app hurdles, and the insights would anyway be gained elsewhere – for example via the Forschungsdatenzentrum (FDZ) Gesundheit (SVDGV DiGA-Report 2025, Kap. 2.2↗). Both positions are legitimate; neither is neutral. For manufacturers the dispute changes little – the dates from 01.07.2026 stand.

PROM integration – an architectural topic, not a report

The operationally most important sentence from Ch. 6.3 of the DiGA-Leitfaden reads: “The collection of the data must happen within the DiGA. […] Notifications to users, e.g. by email, push notification, or SMS outside the application, are not permitted.” (DiGA-Leitfaden v3.6 Kap. 6.3)

The sentence works in three directions:

1. The obvious engagement mechanics are cut off. Push, email, and SMS outside the app fall away. A single in-app reminder per collection time point is permitted, no more.
2. The tolerance windows are tight. PGI-C and patient satisfaction each have a window of seven days before to 0 days after the reference date. Answers outside it are missing values. Collection is therefore not “show an invitation and hope”, but a calendar-driven workflow hooking into the next natural in-app touchpoint.
3. The account and prescription model must be AbEM-capable. Time-zero is the entry of the activation code – not account creation, not the end of onboarding. Teams not deterministically logging the activation-code event lose tolerance windows to timestamp drift.

Data model – which data, when, where

Designing AbEM architecture models five data blocks, not one report:

1. Prescription and activation layer. One unique event per prescription: activation-code entry (timestamp = t0), assignment to prescription type (initial prescription vs. direct follow-up prescription – follow-up prescription data do not flow into AbEM results but are reported as a context counter). Additionally approvals by the health insurance fund (counted analogously) and self-payer marking (self-payer data are to be excluded) (DiGAV § 23b Abs. 2; DiGA-Leitfaden v3.6 Kap. 6.1, 6.2.1).

2. Usage telemetry (Stage I). Per user and week: time in application, number of usage events, derivable discontinuation observation (21 days or 25% of usage duration). Horizon ends with usage duration or after 90 days – whichever comes first.

3. Actively collected instruments (Stages II/III). Per user: PGI-C once at the end, patient satisfaction once at the halfway mark, indication-specific PROM twice (activation + end). Per instrument: participation yes/no, answer inside/outside tolerance window, timestamp.

4. Quarterly aggregates. Per metric, mean, standard deviation, minimum, maximum, median, 25th and 75th percentile are to be reported (DiGAV Anlage 4). That is not a KPI set, it is a statistical profile.

5. Consent and processing block. AbEM needs its own legal basis: § 4(2) sentence 1 no. 3 DiGAV permits processing for producing the AbEM dataset under § 139e(13) sentence 2 SGB V and for evidence for reimbursement agreements under § 134 SGB V (DiGAV § 4 Abs. 2 Satz 1 Nr. 3↗). Further processing requires separate consent (DiGAV § 23a Abs. 6). For the voluntariness logic of §§ 23d/23e, opt-out and the “remind me later” choice (single in-app reminder) are mandatory (DiGA-Leitfaden v3.6 Kap. 6.3.1).

Two operational consequences: the pseudonymous user account must be stable at prescription level – the follow-up prescription identification under § 23b(2) requires the manufacturer to recognise a renewed activation of the same account after the end of the usage duration as a direct follow-up prescription. And: the BfArM publication of results only kicks in at at least 200 users per calendar quarter (DiGAV § 20 Abs. 4); the reporting duty itself is independent of this and applies from 15.04.2027 for all DiGAs subject to collection.

What DUX does differently

DUX Healthcare builds DiGAs on the mHealth Suite, a platform with pre-validated modules. Five DiGAs run on this platform today – platform-developed, each DiGA tested under BSI TR-03161, CE-compliant under MDR.

AbEM is the clearest use case for platform-carried development, because it is product-independent in three things:

• Usage telemetry and discontinuation heuristics. The definitions from § 23c DiGAV – time per week, usage events, 21-day window – are platform logic, not a DiGA feature.
• In-app survey engine with tolerance windows and consent. The questionnaire content varies per DiGA; the engine (reference-date calculation from the activation code, tolerance windows, consent UI, order enforcement, single reminder) is platform-portable.
• BfArM reporting form export. Quarterly aggregation, distribution metrics, and electronic export run over the same path, independent of the indication.

Teams treating DiGA development as a project solve AbEM five times. Teams treating it as platform work solve it once and roll it out. With AbEM the platform advantage is especially pronounced because the architectural decisions are tightly defined – every individual implementation is tested against the same definitions. More on platform mechanics at /build/; on the DiGAV architecture behind AbEM see the DiGA Approval Guide, and on the data and account model that architecturally carries AbEM, see the DiGA pillar hub.

Frequent misconceptions

Five patterns recurring in advisory conversations, each costing three weeks of rework:

1. “AbEM results are a substantial modification.” No. DiGAV § 18 Abs. 2↗ makes explicitly clear that changes in AbEM results are not substantial modifications under § 18(1) DiGAV. That is deliberate – otherwise every half-yearly report would trigger formal notification waves.
2. “We can drive users to the survey via push.” No. Collection must happen inside the DiGA; email, SMS, and push messages outside the application are prohibited (DiGA-Leitfaden v3.6 Kap. 6.3). A single in-app reminder per collection time point is permitted – no more.
3. “The 200-user threshold determines whether we have to report.” No. The 200-user threshold from § 20(4) DiGAV determines from when the BfArM publishes results – the manufacturer’s reporting duty is independent of this and applies from 15.04.2027 for all DiGAs subject to collection.
4. “Self-payers count like insured persons.” No. AbEM captures data from standard care via statutory health insurance; self-payer data are to be excluded (DiGA-Leitfaden v3.6 Kap. 6.1). That is a data-model property, not an after-the-fact filter logic.
5. “Users who resume count as active again.” No. Under § 23c(4) sentence 4 DiGAV, discontinuation is final: users resuming after 21 days of non-use remain discontinuers, and the post-hoc data do not flow into the results presentation.

The sixth pattern is not a misconception but a responsibility error: the concrete coupling of the 20% rule to individual AbEM metrics is determined by the framework agreement between the GKV-SV and manufacturer associations under § 134 SGB V. The DiGA-Leitfaden Ch. 6.1 explicitly notes that this coupling is still to be determined by the framework agreement partners. Teams going into price negotiations in 2026 are thus negotiating parts of the measurement logic – not just a price.

Answers to frequent questions