Healthtech Software Development for the German Market: DiGA, gematik, FHIR, and Hosting
Germany has 83 million people, statutory insurance that covers almost all of them, and a health system that only recently started paying for software. That combination makes it one of the most attractive digital health markets in Europe, and one of the hardest to enter. Healthtech software development for Germany means building against a stack of rules that most other markets do not have: a reimbursement path for apps with its own certification, a national health network run by a single agency, and data protection law that treats a diagnosis code differently from an email address.
This post is for founders and CTOs who are planning a product for the German market, or who already have one and are finding out what the next customer's procurement team will ask for. We have written before about healthcare SaaS compliance across Europe and about engineering for the European Health Data Space. This one stays inside Germany and goes deeper on the parts that are specific to it.
The regulatory frame: DiGA, MDR, and gematik
Three regulatory layers shape most healthtech products in Germany. Which ones apply depends on what your software does and who pays for it.
The first is medical device classification under the EU Medical Device Regulation. If your software supports diagnosis, therapy, or monitoring of a patient, it is very likely a medical device, and the MDR rule for software (Rule 11) tends to push it into class IIa or higher rather than class I. That decision comes early and it is expensive to get wrong. A class I device can be self-declared; anything higher needs a notified body, a quality management system aligned with ISO 13485, and a technical file that engineers contribute to for the life of the product. A wellness app that tracks sleep is not a medical device. An app that tells a diabetic patient how much insulin to take is.
The second layer is DiGA, the reimbursement path introduced by the Digital Healthcare Act in 2019. A DiGA is a low-risk medical device (class I or IIa) that a doctor can prescribe and that statutory insurance pays for. Approval runs through the BfArM fast track and requires more than a working product: evidence of a positive care effect, either upfront or within a provisional listing period, plus proof that the software meets the requirements of the DiGA ordinance on data protection, information security, interoperability, and usability. Since 2025 the security requirements include a certified information security management system according to ISO 27001, which means a young company needs an ISMS before it has significant revenue. Budget for that.
The third layer is gematik, the agency that runs the Telematikinfrastruktur (TI), Germany's national health data network. If your product needs to talk to practice management systems, receive electronic prescriptions, exchange documents with doctors via KIM (the TI mail service), or read from and write to the electronic patient record (ePA, which moved to an opt-out model in 2025), you are dealing with gematik specifications. Practice software has its own approval process with gematik. Most healthtech startups do not build a practice system, but many need a TI connection, and the specifications are long, versioned, and written in German.
None of these layers is optional if it applies to you, and the sequencing matters. Decide the MDR class first, because it determines whether DiGA is even available and how much of your process has to be documented. Then decide whether you need TI access, because that changes your hosting and security architecture.
Data standards you will need to speak
German healthcare data has a defined vocabulary, and integrations fail when a product ignores it.
HL7 FHIR R4 is the exchange format that the German system has settled on. The ePA, the e-prescription service, and the ISiK specifications for hospital information systems are all FHIR based, and gematik publishes German profiles that constrain the base resources. Build your internal data model so that Patient, Encounter, Observation, Condition, and MedicationRequest map to FHIR resources without a translation layer that loses information. You do not have to store FHIR JSON natively, but if your relational model cannot round-trip a FHIR bundle, integration work later becomes a rewrite.
For coding, Germany uses ICD-10-GM for diagnoses, a national modification maintained by BfArM and updated every year. It differs from the WHO version and from ICD-10-CM used in the United States, so an imported code list from a US product is wrong for Germany. Procedures use OPS, again a German system. SNOMED CT became available in Germany through a national license in 2021 and is required in several TI specifications. LOINC covers lab results. Treat all of these as versioned reference data with an update process, not as constants in the codebase. A diagnosis code that was valid in the 2025 catalogue can be split or retired in the 2026 one, and your reports need to survive that.
Health data under the GDPR in Germany
Health data is a special category under Article 9 of the GDPR. That changes what is allowed by default, and the German Federal Data Protection Act adds its own provisions in section 22 for processing health data in a treatment context. Practically, it means you need an explicit legal basis for every processing purpose, a data protection impact assessment before launch, and a data protection officer if you process health data at scale. "We have a privacy policy" is not enough. The supervisory authorities of the federal states, not one national body, enforce this, and they do audit healthtech companies.
Retention rules pull in the opposite direction from the right to erasure. Under section 630f of the German Civil Code, a doctor must keep treatment records for ten years after the end of treatment, and other rules extend that to thirty years for some records. If your product holds documentation on behalf of a clinic, you cannot simply delete a patient's data on request. You need to be able to distinguish legally mandated retention from data you hold for your own purposes, and delete only the second. We covered the engineering side of that in GDPR right to erasure engineering; in healthcare, the retention exceptions are the norm rather than the edge case.
One more German particularity: medical confidentiality under section 203 of the Criminal Code. A doctor who lets an outside party access patient data can commit a criminal offense unless that party is bound by the same duty. Since 2017, IT service providers can be bound as "involved persons", but your contracts with medical customers need to say so, and your staff need to know that this obligation exists.
Hosting requirements
Where the data sits is the question German buyers ask first. The DiGA ordinance requires that personal data is processed in Germany, another EU or EEA member state, or a country with an adequacy decision, and only for the purposes the ordinance lists. Hospitals and insurers often go further and require a data centre in Germany. A US hyperscaler's Frankfurt region satisfies the letter of the ordinance but not every procurement team; several will insist on a German provider or on a sovereign cloud offering with separated operations.
The certifications that come up are ISO 27001 for the ISMS and BSI C5, the German cloud security criteria catalogue, for the hosting provider. Since 2024, providers of cloud services to the statutory health system need a C5 attestation under section 393 of the Social Code Book V. Pick a provider that already has one; getting a C5 report yourself is a project on its own. On the application side, the BSI's technical guideline TR-03161 defines security requirements for health apps, and DiGA applicants have to demonstrate compliance with it.
Do not treat these as paperwork. They dictate concrete choices: encryption at rest with customer-controlled keys, network isolation per environment, logged and reviewed admin access, tested backups with defined restore times, and no production data in staging. If you plan for them at architecture time they are a few weeks of work. If you retrofit them after a customer's security questionnaire arrives, they are months.
Architecture decisions we make for healthtech SaaS
Regulation is the reason for most of the structural choices in a German healthtech product. Here is what we typically do at Wolf-Tech when we build custom software for this market.
Tenant separation for medical practices is stricter than in a normal B2B SaaS. Each practice is a separate data controller with its own confidentiality duty, so shared tables with a tenant column and application-level filtering is a hard sell to a practice's data protection officer. We use PostgreSQL row-level security as a floor and, for larger customers, a schema or database per tenant, with the trade-offs described in our row-level security post. The cost is operational, mainly in migrations and monitoring. The benefit is that you can answer "can practice A ever see practice B's data?" with a database guarantee instead of a code review.
Regulators require audit trails, so we build them in from the start. The MDR expects traceability of who changed what in a device's data, and the GDPR requires you to demonstrate lawful access. We record every read and write of patient data with user, role, timestamp, purpose, and the record identifier, in an append-only store that application code cannot update or delete. We described the design in audit log architecture for B2B SaaS. In healthcare, add access to the audit log itself to the list of audited events, because the question "who looked at this patient's file" is one that regulators and patients both ask.
API boundaries are where health data leaks in practice, so we keep them narrow. Every external interface, whether a FHIR endpoint, a KIM gateway, or a lab import, runs through a dedicated integration service with its own credentials, strict schema validation, and rate limits. Internal services never call external systems directly. Tokens for TI components live in a secrets manager with rotation, never in environment files checked into a repository. Errors from external systems are logged without the payload, since a stack trace with a FHIR bundle in it is a data breach.
Finally, we version the reference data. ICD-10-GM, OPS, and the FHIR profiles from gematik all change yearly, and the software has to know which version a record was coded against. A small table with catalogue versions and effective dates, joined into every coded field, saves a great deal of confusion when a report from 2027 has to explain a diagnosis recorded in 2025.
Where to start
If you are early, the order is: settle the MDR classification with a regulatory consultant, decide whether DiGA is your path to revenue, and only then finalize the technical architecture. If you already have a product and a German customer is asking questions, the fastest way to find out where you stand is a structured review of the codebase and infrastructure against the requirements above, which is what our code quality consulting engagement is for. Either way, the companies that do well in this market are the ones that treat the regulation as an input to the design rather than a checklist at the end.
If you are planning a healthtech product for Germany and want a second opinion on the architecture, write to us at hello@wolf-tech.io or visit wolf-tech.io.