The previous article was about ISiK — the mandate that forces hospital systems to expose FHIR. ISiK is the supply side of Germany's interoperability push: it governs what shape the data takes when it leaves a hospital. This article is about the next national layer where structured health data becomes operationally relevant at scale.
Since 1 October 2025, the elektronische Patientenakte — the ePA, in its "ePA für alle" form — has entered mandatory everyday use for healthcare providers. Statutory insurers now provide one by default for every insured person, on an opt-out basis, and practices, hospitals, pharmacies, and other medical providers are required to use and fill it with the legally defined data created during treatment. By a wide margin, it is the largest FHIR deployment the country has ever attempted.
Having spent years inside German clinical systems, this is the shift I find most significant — not because it introduces FHIR (ISiK already did that for hospitals) but because of what it does to the kind of data flowing through the system, and the scale it does it at.
From documents to data
The original ePA was, in practice, a document store. PDFs and structured documents filed against a patient, exchanged through an IHE-based document service. Useful, but closed: a document is something you open and read, not something you query.
"ePA für alle" changes the architecture. Alongside the document-based service, it introduces a Medication Service — a FHIR-server component that holds medication data as structured, individually addressable FHIR resources. Dispensing data flows in from the E-Rezept infrastructure, and the service generates the elektronische Medikationsliste (eML) — not as a PDF, but as structured FHIR that a practice information system can consume and reason about natively.
This is the shift that matters: from documents about the patient to structured data of the patient. Queryable, comparable, reusable across systems. It is exactly what FHIR was designed for — and exactly the point where conformance stops being cosmetic.
The MIO layer
The structured content of the ePA is defined through the MIO layer — Medizinische Informationsobjekte, FHIR profile specifications originating from the KBV/mio42 ecosystem and implemented through the ePA specifications. The MII has its KDS profiles, gematik has ISiK, and the ePA medication architecture has MIO-based content realized through gematik's ePA infrastructure. They are independent profile worlds inside one country, on independent release schedules.
The architectural direction is telling: MIOs are moving from being stored as closed documents toward being decomposed into individual FHIR instances on the FHIR-based services. In the digital medication process, ePA 3.0 starts with the eML built from prescription and dispensing data, while ePA 3.1 is intended to support the electronic medication plan including its AMTS-relevant data (Arzneimitteltherapiesicherheit — medication therapy safety) through the Medication Service. The document dissolves into data.
A data quality problem at a new scale
Every national FHIR program in Germany has the same structural challenge — the same profile implemented differently across many independent systems. ISiK has it across hundreds of hospital information systems. The MII has it across 41 data integration centers. The ePA has it across every practice, pharmacy, and hospital in the country — tens of thousands of data sources, running software from dozens of vendors, all writing into one shared national record infrastructure.
The variability problem doesn't scale linearly. It compounds. A medication resource written by one practice's PVS may carry elements another omits; a code valid in one system's terminology snapshot may be retired in another's. Multiply that across tens of thousands of source systems feeding a single national service, and the question "is this data conformant?" stops being answerable by anyone who only looks at their own output.
And here the stakes are different from a hospital interoperability API. This is medication data. A non-conformant or mis-coded medication resource isn't just a data-quality blemish on a dashboard — it can feed a faulty interaction check, or be silently dropped from an AMTS evaluation. For research data, a terminology inconsistency biases a study. For medication data in a record clinicians actually act on, it touches patient safety.
Certified once, operating continuously
The connection to the ePA is tested when a system is certified for it. But the data doesn't stop after certification — it flows continuously, from systems that update on their own schedules, against MIO profiles that version (3.0 to 3.1 and onward), and terminology that drifts: pharmaceutical central numbers (PZN), ATC classifications, the code systems behind the medication MIOs.
This is the same gap the ISiK article described — conformance verified at a point in time, in a system that operates continuously — but with two amplifiers: national reach, and patient-safety stakes. The day after a system is certified for the ePA, the question of whether the FHIR it writes is still conformant is open again. Certification alone does not provide continuous evidence between release cycles.
What this asks of the teams writing into it
For a vendor whose software now writes medication data into the national record, the operational question is no longer "did we pass the connection test?" It's "is the FHIR we are writing into the ePA conformant right now — against the current MIO profiles, with current terminology — and would we know if that changed?"
Every one of those vendors validates their FHIR output somewhere. Most do it in CI, against test fixtures, before they ship a release. That is necessary work. It is also not the same as knowing the data is conformant today — and that gap is exactly where the next article picks up.