Austria’s electronic health record system has specific integration requirements that most development teams discover only after their architecture is already set. Here’s what to decide before you write the first line of code.
Most founders building digital health products for the Austrian market spend the first few months focused on MDR classification and GDPR compliance and discover ELGA six months later, when the engineering team starts asking how patient data actually gets in and out of the system. That moment is expensive. At fireup.pro, we’ve built healthcare products for the DACH region since 2018, including platforms serving over 1.8 million users, and ELGA’s architecture keeps catching teams off guard for the same set of reasons.
Table of Contents
What ELGA is and why it’s not germany’s TI
ELGA (Elektronische Gesundheitsakte) is Austria’s nationwide electronic health record system, operational since 2015 and mandatory for hospitals, pharmacies, and most outpatient facilities. It gives patients and authorized healthcare providers access to lab results, medication data, radiology reports, discharge letters, and e-prescriptions.
The key distinction for development teams: ELGA is not the same system as Germany’s Telematikinfrastruktur (TI), and integration requirements differ significantly. A product already integrated with TI in Germany cannot be „extended” to work with ELGA in Austria. The standards overlap at the conceptual level, both use HL7, but the implementation profiles, document types, identity infrastructure, and governance are entirely separate.
ELGA is operated by ELGA GmbH, a non-profit entity co-owned by the Austrian federal government, federal states, and social insurance bodies. Access requires registration as an ELGA participant and integration with Austria’s identity infrastructure via the eCard – the electronic health insurance card every resident carries. For a startup, this means ELGA integration isn’t an API call with a developer key. It’s an institutional process with specific certification steps that need to be scoped into the project timeline from the start.
The CDA-to-FHIR Transition: what it means if you’re building now
The current technical foundation of ELGA is HL7 CDA (Clinical Document Architecture), a document-based standard where health data is exchanged as structured XML documents – discharge summaries, lab reports, e-prescriptions – each conforming to an Austrian-specific implementation profile.
Teams planning products in 2026 face a genuine dilemma. The standard is in active transition. HL7 Austria has published a FHIR Core Implementation Guide, and the Austrian Patient Summary is being developed in FHIR R4. ELGA GmbH is moving toward FHIR-based document exchange, aligned with EU-level requirements from the European Health Data Space. But ELGA is not FHIR today — and a team that builds their data exchange layer around FHIR-only from the start will hit a gap in production.
A 2023 European review found that only 7 out of 38 digital health applications analyzed were compatible with the current Austrian ELGA standard. The main barrier in most cases wasn’t regulatory, it was interoperability gaps at the document-type level that teams hadn’t accounted for during architecture design.
The practical approach we recommend to clients is to design for the transition: implement CDA document handling for current ELGA integration, but structure the internal data model around FHIR resources. When we worked on mySugr – the diabetes management platform that Roche acquired with 1.8 million users, the decisions made about data representation in early sprints determined how much rework was needed as standards evolved. That lesson shapes how we advise teams entering the Austrian market today.
What EHDS changes for products building in Vienna
The European Health Data Space Regulation entered into force in March 2025. For Austrian digital health startups, the headline deadline is March 2029: by that date, EU member states must support cross-border exchange of priority data categories, patient summaries and e-prescriptions in standardized format.
Austria is in a relatively strong position. The country has operated ELGA since 2015, maintains the HealthData@AT infrastructure for secondary data use, and participates in the cross-border eHDSI exchange framework. The regulatory trajectory maps onto existing infrastructure rather than requiring a full rebuild.
„The teams that handle EHDS preparation smoothly are those that treat it as an architecture constraint from sprint one, not a migration project for 2028. The standards are converging toward FHIR, your internal data model should already reflect that.” — Jarek Szczotka, Strategic Growth Advisor , fireup.pro
Three areas require decisions before your first sprint. How you handle patient consent and data access logging – EHDS introduces a secondary-use concept that goes beyond GDPR’s existing consent framework, requiring your consent model to distinguish between primary care use and research use at the data level. How you represent patient data internally – EHDS is building on FHIR, making an internal FHIR representation the right long-term choice even where CDA is still required at the exchange layer. And how your architecture handles cross-border patient identity – Austria uses eCard and national ID infrastructure; EHDS will require mapping to a European patient identifier.
The compliance stack for a Vienna gigital health startup in 2026
| Layer | What It Requires | When It Applies |
|---|---|---|
| GDPR | Consent, access logging, data subject rights, DPAs with vendors | Always, from day one |
| MDR 2017/745 | CE marking, technical documentation, notified body for class IIa+ | If your software qualifies as a medical device |
| ELGA integration | CDA conformance, ELGA GmbH participant registration, eCard IdP | If your product reads or writes patient health data in Austria |
| EU AI Act | Risk classification, human oversight, audit logging (high-risk from Aug 2028) | If your product includes AI features affecting clinical decisions |
| EHDS | FHIR alignment, patient summary support, secondary use governance | Full application from March 2029 |
Austria is also developing its DiHA (Digitale Gesundheitsanwendungen) framework for reimbursement through statutory health insurance, the Austrian equivalent of Germany’s DiGA. The framework is still forming through 2026 and into 2027, but teams planning to pursue insurance reimbursement should build their evidence documentation with DiHA criteria in mind from the start.
For a deeper look at how the EU AI Act interacts with this compliance stack, see our article on what the 2028 deadline means for medical AI teams in DACH.
3 architecture decisions that determine ELGA integration cost
Our healthcare engineering team has built production systems across this compliance stack for clients including mySugr/Roche, 9amHealth, Selfapy, and Mentalyc. The teams that handle ELGA integration smoothly share three decisions made early.
1. Document type scope. ELGA supports a defined set of document types: lab results, discharge letters, radiology reports, medication data, e-prescriptions, and others. Deciding upfront which types your product reads, writes, or both determines the scope of your CDA conformance work. In our work with 9amHealth — a virtual care platform that grew to serve 40,000 new users in 2026 alone through employer benefit programs — data model decisions made in the first two sprints shaped everything that followed. Teams that scope document types mid-project typically discover they’ve built the wrong data model around the wrong document structure.
2. Identity architecture. ELGA uses Austria’s e-government identity infrastructure: eCard authentication for patients, specific credential types for healthcare providers. This affects authentication flows, session handling, and access control from the first sprint — it can’t be stubbed out and retrofitted before launch. On Selfapy, a digital CBT therapy platform that achieved BSI IT-Grundschutz certification in Germany, the identity and access control architecture was defined before a single product feature was built. The same principle applies to ELGA.
3. Internal representation standard. If your internal data model is CDA-shaped, migrating to FHIR later means rebuilding core data structures under time pressure. If your internal model is FHIR-shaped with a CDA translation layer for ELGA exchange, that translation layer shrinks as ELGA migrates and your core model stays stable. The second approach costs more at the start and significantly less over the product lifecycle.
🚀 If you’re building a digital health product for the Austrian market and want a technical review of your ELGA integration approach before architecture decisions are locked 👉 we’re happy to talk. Our healthcare team has delivered products across the full Austrian compliance stack, from ELGA integration and MDR documentation to EHDS preparation.
