Your Austrian health app won’t get reimbursed, not because of the science, but because of the code

Austria is finalizing a reimbursement pathway for digital health applications. Most applications will fail and not for clinical reasons.

We work with healthtech teams across the DACH region, and when the news about Austria’s DiHA framework started circulating in early 2026, we saw a familiar pattern in how teams responded. Founders forwarded the announcement to their product leads. Product leads told their engineers to „make sure we’re FHIR-compatible.” And clinical teams started asking about study design.

The clinical teams were solving the wrong problem first.

In Germany, where this reimbursement model has been running since 2019, the most common reason applications fail before approval has nothing to do with clinical evidence. It’s data infrastructure that can’t pass a BSI audit, software lifecycle documentation that was never created, and interoperability gaps with national health record systems. Austria has spent three years watching Germany’s failure modes. It’s building stricter technical gates into its framework from the start.

What DiGA reimbursement in Austria actually means

A DiGA, Digitale Gesundheitsanwendung, is a certified health app that patients can access through statutory health insurance with no out-of-pocket cost. Germany created this category in 2019 under the Digital Versorgung Gesetz, making it the first country to put apps on national prescription. Austria is building its equivalent into the Erstattungskodex, the national reimbursement registry run by the Österreichische Gesundheitskasse, with the first DiHA (Digital Health Application) approvals expected from 2026 onward.

To qualify, an application must satisfy three overlapping frameworks at the same time: EU Medical Device Regulation (MDR), Austria’s ELGA data infrastructure standards, and for any app with algorithmic decision support – the EU AI Act. Meeting one without the others doesn’t get you to a submission. It gets you to a rejection with a long list of outstanding items.

What 5 years of German DiGA actually shows

Germany has approved over 50 DiGAs since 2019. The application rejection rate is more instructive. Research published in PMC analyzing the path to an Austrian DiHA framework identifies technical and regulatory documentation failures as consistently accounting for more rejections than inadequate clinical evidence.

The failure pattern is almost always the same. A company runs an 18-month clinical study, then discovers during technical review that their logging infrastructure doesn’t meet BSI TR-03161 requirements for data security. Or their cloud infrastructure doesn’t satisfy data sovereignty requirements for health data in the German/Austrian context. Or their HL7 FHIR implementation passes basic testing but fails when the certification body runs it against the actual national health record system.

We’ve seen versions of all three in projects we’ve been brought into mid-stream usually when a team realizes their original architecture wasn’t built with any of this in mind. Austria is designing its framework with these failure modes explicitly in scope. The technical bar is being set to avoid Germany’s early approval patterns, where some apps scraped through on provisional status with significant technical debt still outstanding.

The 3 technical issues that kill applications before clinical review

Audit trails. Austrian DiHA certification requires complete, tamper-proof logs of every interaction that touches patient data. Not system logs designed for debugging – clinical-grade audit trails that record who accessed what, when, from which clinical context, and with what outcome. Most consumer-facing health apps have logging built for error tracking. That’s architecturally different from what a certification audit expects. Retrofitting it into a live product isn’t a sprint task; it’s a structural change that touches the data layer.

MDR documentation that covers your development history. Apps pursuing DiHA status typically fall under MDR Class IIa, which requires a Technical File covering the full software development lifecycle your process, testing methodology, change management, and risk documentation all structured per IEC 62304. That documentation covers your product’s development history. If you built the app without IEC 62304-compliant processes, you can’t document a process you didn’t follow. This is the single most expensive thing to fix retroactively.

HL7 FHIR R4 integration with ELGA. Austria’s national electronic health record system uses HL7 FHIR as its interoperability standard. A DiHA that can’t exchange data in FHIR R4-compliant format with ELGA won’t clear technical conformity assessment. We’ve built FHIR integration layers into both greenfield health platforms and products that already had years of production data behind them — the latter is a fundamentally different project, typically 6–9 months when done properly. Our article on healthcare system integration covers what that scope actually looks like.

The AI Act layer most teams aren’t accounting for

If your app uses algorithmic decision support risk scoring, triage assistance, personalized recommendations based on health data you’re looking at EU AI Act high-risk classification under Article 6. The Digital Omnibus extended the original August 2026 compliance deadline to December 2027 for standalone systems and August 2028 for AI embedded in MDR-regulated products. We covered this in detail in our piece on AI Act and SaMD compliance.

What matters for Austrian DiHA applications specifically: the certification authority treats AI Act compliance as a prerequisite, not a parallel track. An app with an AI component that hasn’t completed a conformity assessment won’t receive DiHA status regardless of the clinical study behind it. The check happens early in the process.

The combination of MDR, AI Act, and ELGA requirements is where most applications collapse. Each framework has distinct documentation requirements, testing standards, and audit logic. Running three compliance workstreams against a codebase that was designed for none of them is expensive and slow and it’s the situation most teams find themselves in when reimbursement moves from „future roadmap” to „we’re submitting in 12 months.”

What we’ve seen in products that make it through

The health products we’ve built or contributed to that moved efficiently through certification processes, including work with mySugr/Roche and 9amHealth, shared characteristics that had nothing to do with being compliance-driven companies.

Data governance was a product requirement from the start, not a compliance project that came later. Audit trails, consent flows, and data lineage were built into the core data model before the first user touched the product. FHIR endpoints weren’t a Q4 integration project – they were part of the API design from sprint one. IEC 62304 documentation was a living artifact maintained alongside the codebase, updated with each significant change, not assembled retroactively when someone decided to seek certification.

If you’re at MVP stage and DiHA reimbursement is on the roadmap, the decisions you’re making now about your data model and architecture are the decisions that will determine whether you can certify in two years or whether you’ll be rebuilding. Our piece on healthcare MVP development covers how to scope that correctly from the start.

When to start

If DiHA reimbursement is on your roadmap for 2027 or 2028, the technical groundwork needs to start now. The MDR Technical File covers your development history — you can’t backfill a process you didn’t follow. Building a FHIR integration layer into a mature product without prior FHIR design is a 6–9 month project on its own. IEC 62304-compliant processes can’t be retroactively documented.

The FFG and aws „Digital Health Austria” flagship program running in 2026 is partly designed to help Austrian healthtech companies reach this baseline. If you’re applying, the technical criteria align closely with what DiHA certification assessors will look for.

If you’re building a health product for the Austrian market and want a read on where your architecture stands relative to DiHA requirements, we’re happy to take a look.