Gematik ePA Integration Guide for App Developers

Introduction

Germany is the largest healthcare market in the European Union. Approximately 74 million people carry statutory health insurance, and since January 2025, every one of them has an electronic health record (elektronische Patientenakte, or ePA) active by default. The system is managed by gematik, the national agency responsible for Germany's digital health infrastructure.

For health app companies, this creates both a requirement and an opportunity. Any product that handles patient health data in Germany will eventually need to interface with ePA. At the same time, ePA access gives apps a structured, standardized source of lab results, prescriptions, vaccination records, and diagnoses that would otherwise require manual entry or fragmented API integrations.

This guide covers the technical and regulatory requirements for connecting your app to ePA. It explains the two integration pathways, what data you can access, the FHIR R4 resources involved, security requirements, and realistic timelines based on our experience with healthcare data integration projects.

What Is gematik ePA?

The ePA is Germany's centralized electronic health record system. It sits within the Telematikinfrastruktur (TI), the secure network that connects all participants in the German healthcare system: hospitals, general practitioners, pharmacies, insurers, and approved third-party applications.

Each ePA stores a patient's clinical data: lab results, prescriptions, medication plans, vaccination records, visit summaries, diagnoses, and allergy information. The record is longitudinal, meaning it accumulates data across providers over time. A patient who visits a cardiologist, gets bloodwork at a lab, and picks up a prescription at a pharmacy will have all three events reflected in their ePA, provided each provider uploads the data.

This is a meaningful departure from how health records work in many other markets. In the United States, for example, patient data is typically siloed across individual provider systems (Epic, Cerner, Athenahealth), and interoperability depends on point-to-point integrations or health information exchanges. Germany's approach centralizes the record at the national level.

One important caveat: ePA completeness depends on both the medical facility and the patient. The record contains only what healthcare providers have actually uploaded. Some facilities are faster to adopt than others, and upload practices vary across regions. Your app should be designed to handle partial or incomplete records without breaking.

Since 2025, ePA enrollment is opt-out rather than opt-in. Patients can deactivate their record, but the default is active. This means the addressable population is large from day one.

Who Can Integrate?

Two categories of organizations can connect to ePA:

Healthcare providers (doctors, hospitals, pharmacies) who are already part of the Telematikinfrastruktur. They connect via a TI connector and an SMC-B card, which is their institutional authentication credential.

Third-party applications approved by gematik. These are apps that patients choose to grant access to. The app must go through a gematik approval process and authenticate via the gematik Identity Provider (IDP). Patient consent is required, and it is granular: the patient decides which data categories the app can access and can revoke that consent at any time.

For most health app companies building products like chronic disease management tools, baby development trackers, fitness platforms, or clinical decision support systems, the third-party application pathway is the relevant one.

Path A: Third-Party ePA App

This is the faster route to market. Your app gets listed in a gematik-approved directory. Patients find your app through their insurer's ePA application, review what data it requests, and grant or deny access per category.

Once authorized, your app reads structured FHIR R4 data from the patient's ePA. You do not get write access. You cannot issue prescriptions. Insurance reimbursement is not available through this path. But you are live with real patient data significantly faster than through the DiGA route.

How It Works

The patient opens their insurer's ePA app (each of Germany's ~100 statutory insurers provides one), navigates to the third-party app directory, and selects your application. They then review a consent screen that lists the specific data categories your app has declared it needs. This follows GDPR data minimization principles: you must declare exactly what you need and justify why. If your app tracks medication adherence, you request access to MedicationRequest and MedicationStatement resources. You do not request vaccination records.

The patient approves, and your app authenticates via the gematik IDP for that session. Your backend then connects to the insurer's ePA FHIR endpoints and fetches the approved data categories.

Consent is not permanent. Patients can revoke access at any time, and your app must handle that gracefully: clear cached data, stop fetching, and inform the user.

For apps that serve minors, the authentication system must support proxy relationships. The parent or legal guardian acts on behalf of the child, and the consent flow needs to reflect that.

What You Need to Build

The engineering work for Path A is substantial but straightforward for experienced teams. The core tasks break down into three areas:

Data layer: Implement FHIR R4 parsing for ePA resources (lab results, medications, vaccinations, diagnoses). If your team has worked with FHIR in other contexts, this will be familiar territory. Connect to insurers' ePA FHIR endpoints to fetch approved data categories.

Authentication and consent: Integrate with the gematik Identity Provider (IDP) for session-based authentication. Build a consent flow UI where patients review, grant, and revoke access per data category. For apps serving minors, support guardian/proxy authentication.

Compliance and approval: Complete a security audit (penetration testing, encryption, access logging), prepare GDPR compliance documentation (privacy policy, data processing agreements, data minimization), and submit everything to gematik for approval.

The technical integration is work, but it is well-scoped and predictable. The real weight in ePA integration is on the formal and regulatory side: gematik's approval process, security audit requirements, and the documentation burden. Plan your timelines accordingly.

Timeline

Expect 4 to 9 months from kickoff to approval, depending on team size, existing FHIR experience, and how much of your data layer you need to build from scratch. Teams that have already worked with FHIR R4 in other contexts (US EHR integrations, for example) will be on the shorter end.

Path B: DiGA (App on Prescription)

DiGA (Digitale Gesundheitsanwendung) is the more powerful integration path. If your app qualifies, doctors can prescribe it to patients. Germany's statutory health insurers pay for it, typically between 5 and 15 EUR per patient per month. You get deeper ePA access, including write permissions, meaning your app can contribute structured data back to the patient's record.

The trade-off is regulatory complexity. You need CE marking as a medical device, clinical evidence that your app improves patient outcomes, and approval from BfArM (Bundesinstitut fur Arzneimittel und Medizinprodukte), Germany's federal authority for drugs and medical devices.

Regulatory Requirements

Your app must be CE-marked as a medical device under the EU Medical Device Regulation (MDR). The specific class (I, IIa, or higher) depends on the app's intended purpose: simpler health apps typically fall under Class I, while apps that directly influence clinical decisions or involve measurement functions may require Class IIa or above. The classification determines how much external oversight you need. What matters most at this stage: you need MDR certification, and the sooner you start the process, the better.

Once CE-marked, you apply to BfArM for listing in the DiGA directory. BfArM reviews your clinical evidence, security posture, and usability. They offer a Fast-Track option: a 3-month provisional listing while you gather full evidence. This is worth pursuing if your evidence base is still being built, since it gets your app into the reimbursement system faster.

The clinical evidence requirement is where timelines vary most. BfArM accepts both prospective clinical studies and real-world evidence from existing usage data. If you already have a deployed user base and can demonstrate positive health outcomes from your data, the evidence phase shortens considerably.

For security, you must pass the BSI TR-03161 assessment. BSI (Bundesamt fur Sicherheit in der Informationstechnik) is Germany's federal cybersecurity agency, and TR-03161 is their standard for health applications. This requires an external auditor and covers encryption, access controls, data handling, and infrastructure security.

Additional Work Beyond Path A

On the engineering side, DiGA adds three things: extending your FHIR implementation to write data back to ePA, connecting to the GKV (statutory insurer) billing system for reimbursements, and mapping your app's indications to ICD/OPS codes for prescription eligibility. This is manageable engineering work on top of what you already built for Path A.

The real challenge is regulatory. You need to pass the BSI TR-03161 security assessment (a formal audit by an external auditor against Germany's health app security standard), gather clinical evidence that your app improves health outcomes, and submit a formal application to BfArM. BfArM reviews your clinical evidence, security posture, and usability before granting DiGA listing.

Prepare for the regulatory process to take significantly more time and effort than the technical work. Clinical evidence gathering, audit scheduling, and BfArM review cycles are where the timeline expands. BfArM offers a Fast-Track option (3-month provisional listing while full evidence is gathered), which is worth pursuing if your evidence base is still being built.

Timeline

The DiGA-specific work adds 6 to 18 months on top of Path A, depending almost entirely on clinical evidence readiness and regulatory processing. If you need to run a prospective clinical study from scratch, plan for the longer end. If you can analyze existing usage data from a deployed product, you may qualify for Fast-Track within a few months of applying.

Quality Management System and ISO 13485

Both MDR certification and DiGA listing require a quality management system (QMS). This is not optional. Your QMS does not have to be formally ISO 13485 certified, but it must meet equivalent requirements: documented processes for design controls, risk management, post-market surveillance, and corrective actions.

In practice, we recommend implementing a QMS aligned with ISO 13485 from the start. The investment pays off across every regulatory checkpoint: CE marking goes smoother, BfArM reviews are faster, and you are already prepared if you later pursue Class IIa products or expand into other regulated markets. Treat QMS implementation as foundational infrastructure, not a late-stage checkbox.

Accessible Data Categories

ePA 3.0 is fully FHIR R4-based. Approved apps receive structured FHIR resources covering six main categories:

Two things to keep in mind when designing your data layer:

First, these are structured FHIR resources, not free-text documents. Your parsing logic should expect well-typed data with standard code systems (ICD-10, LOINC, ATC). Second, not every patient will have complete records across all categories. A patient whose GP has been uploading diligently will have a richer record than one whose providers are still adopting the system. Build your app to deliver value even with partial data.

Dual-Path Strategy: Why You Want Both

A common question from teams evaluating ePA integration: do they need to choose between Path A and Path B?

It depends on whether your app has MDR certification.

Apps without MDR certification can only use Path A. You apply to gematik, get approved, and read patient data. This is a valid starting point for many health and wellness apps that do not qualify as medical devices.

Apps with MDR certification can use both paths simultaneously. The CE mark satisfies the medical device classification requirement for DiGA, and it does not disqualify the app from the Third-Party ePA App route. You can hold both approvals at the same time. For these apps, the strategic play is clear.

Start with Path A as fast as possible. Get your FHIR integration built, pass the security audit, receive gematik approval, and start serving patients with read-only ePA data. This gives you access to real patient data and real usage metrics from day one.

Then pursue Path B in parallel. Insurer reimbursement through DiGA is the strategic goal for any medtech company serious about the German market. Having statutory health insurers pay 5 to 15 EUR per patient per month for your app is the kind of revenue model every medtech founder is working toward. While Path A is live, gather clinical evidence, prepare the BfArM application, implement write access, and build the billing integration.

This sequencing has a compounding effect: by the time BfArM reviews your DiGA application, you have months of real-world usage data to support your clinical claims. The data you collected via Path A feeds directly into your Path B evidence base.

The exception: if your app has no standalone value without write access or prescription distribution, Path A alone may not be viable as a starting point. In that case, plan for the full DiGA timeline from the start.

Practical Recommendations for Engineering Teams

Start with your FHIR competency. If your team has built EHR integrations before (against Epic, Cerner, or other US systems using FHIR R4), the ePA data layer will feel familiar. The resource types are standard. The main difference is the authentication model (gematik IDP rather than SMART on FHIR) and the consent architecture (granular, patient-controlled, revocable).

If your team is new to FHIR, budget additional time for the learning curve. FHIR R4 is well-documented, but parsing real clinical data from production systems is different from reading the spec. Edge cases in code system usage, optional fields, and provider-specific formatting will surface during testing.

Map your existing compliance controls. Teams that have already built HIPAA-compliant infrastructure will find significant overlap with German requirements. Encryption at rest and in transit, access logging, role-based access controls, and audit trails are common to both regimes. The delta is primarily in consent management (GDPR's granular consent model is more prescriptive than HIPAA's authorization framework) and the BSI TR-03161 assessment for DiGA.

Design your consent flow early. The consent UI is not an afterthought. Patients must understand exactly what data your app accesses, why it needs that data, and how to revoke access. gematik reviews this flow as part of the approval process. Build it as a first-class feature, not a checkbox screen.

Plan for the security audit. Both paths require a security assessment. For Path A, this is a penetration test and encryption review. For Path B, it is the formal BSI TR-03161 audit. Either way, do not leave security work for the final weeks before submission. Findings from security audits often require architectural changes that take time to implement.

If your team needs guidance on healthcare infrastructure architecture or FHIR integration patterns, our HealthTech consulting team has worked across both US and European regulatory environments.