Specifications that keep evolving
gematik specifications are versioned and updated over time. Software that works with the TI has to absorb those changes without turning every release into a rebuild.
All services
Healthcare software development
Healthcare software development in Germany: from the ePA to practice network platforms
Within IBM Deutschland's team, we develop C++ backend components of Germany's electronic patient record (ePA), following gematik specifications. That ePA serves 73 million insured people. We bring this experience to software for medical practices, practice networks and healthcare companies that handles health data the way data protection and social security law require.
- ePA backend to gematik specs
- Practice network appointment platform
- Data protection for health data
Background
ePA, telematics infrastructure and cloud rules: the legal framework
Since January 15, 2025, statutory health insurers have been required to provide an electronic patient record to every insured person who has not opted out (Section 342 SGB V). After an introductory phase in pilot regions, the nationwide rollout began on April 29, 2025, and since October 1, 2025, all healthcare providers have been required to use the ePA. Practices in the statutory system must upload lab results, imaging reports and electronic doctor's letters from the current treatment, among other data, unless the patient has objected (Section 347 SGB V).
The ePA runs on the telematics infrastructure (TI), the interoperable information, communication and security infrastructure that connects healthcare providers, payers and insured people (Section 306 SGB V). gematik (Gesellschaft für Telematik) issues its functional and technical specifications and approves TI components and services that are functional, interoperable and secure; security requirements are set in consultation with the BSI, Germany's federal cybersecurity agency (Sections 311 and 325 SGB V).
Health data is a special category of personal data: under Article 9 GDPR, processing it is prohibited in principle and allowed only under one of the listed exceptions, such as the provision of health care or treatment. Large-scale processing requires a data protection impact assessment (Article 35(3)(b) GDPR). Healthcare providers, health and long-term care insurers and their processors may process health data in the cloud only under the conditions of Section 393 SGB V:
- Processing in Germany, the EU, an equivalent state, or a third country with an adequacy decision under Article 45 GDPR; the provision also requires the processing entity to have an establishment in Germany
- Technical and organizational measures in line with current technology; for practices in the statutory system, they count as adequate if the IT security guideline under Section 390 SGB V is met
- A current C5 attestation under the BSI criteria catalog for the cloud systems used, or proof under an equivalent standard: Type 2 since July 1, 2025, or Type 1 during the first 18 months for systems first placed on the market after June 30, 2025
- The complementary customer criteria listed in the attestation report, meaning the measures on the cloud customer's side, must be implemented
Typical starting points
Why healthcare software projects work differently
The domain logic is rarely the hardest part. Difficulty arises where regulation, data protection and daily practice meet.
Access rights that depend on context
Who may see which data depends on role, treatment context and the patient's objection or consent. These rules belong in the data model and server logic, not just in the interface.
Cloud operations with legal conditions
For providers and insurers using the cloud, Section 393 SGB V prescribes location, C5 attestation and implemented customer criteria. An architecture that ignores this from the start will have to be migrated later.
Coordination between practices by phone
Open appointments between practices are often arranged by phone or through personal contacts. A platform has to be faster than that phone call in daily practice, or nobody will use it.
What we build
What we build for practices, practice networks and healthcare companies
We take on new builds as well as work within existing teams that need systems-level experience.
Platforms for practice networks and care networks
Appointment exchange, member management and billing between practices, medical care centers and hospitals, with approval workflows and role-based permissions. On the Praxisnetz Nürnberg Süd platform, patient names are visible only to the two practices involved in an appointment.
Backend development to gematik specifications
Systems-level components in C++, REST and SOAP interfaces, code reviews and performance analysis within existing teams, the way we work on the ePA at IBM.
Applications for sensitive health data
Data-minimizing data models, permissions checked on the server, traceable access and encrypted transport. Operational logs capture technical data such as path, status and response time, but no request content.
Cloud architectures under Section 393 SGB V
Choice of region and services, implementation of the customer criteria from the C5 report in the application, and technical input for your data protection impact assessment.
Integrations and replacing manual workflows
Connections to existing systems, generated documents such as PDF invoices, and exports for billing and administration, so less work bounces between phone, email and spreadsheets.
Approach
How we run healthcare software projects
We settle data protection and regulatory questions before the first line of code, not right before go-live.
- 01
Map data flows and the legal framework
Which data is involved, who is the controller, does Section 393 SGB V apply, is the TI affected? We map the data flows and resolve open questions together with your data protection officer.
- 02
Model roles and permissions
Before any interface exists, we define which role may see and change which data in which context. We enforce these rules on the server and test them automatically.
- 03
Build in short iterations with practice teams
A first usable version typically takes 3 to 6 weeks. Feedback from doctors and practice staff goes straight into the next iteration.
- 04
Secure operations and hand over
We set up deployment, database migrations and backups in a traceable, documented way. You receive the complete source code and documentation that lets another team continue the work.
Technology
Technology for systems-level components and healthcare web platforms
For performance-critical backend components we work with C++, CMake and Boost, REST and SOAP interfaces, containers on Docker and Kubernetes, and static code analysis with SonarQube. These are the tools we use in ePA development.
We build web platforms such as the appointment exchange for Praxisnetz Nürnberg Süd with React, TypeScript, Express and PostgreSQL, running in Docker containers behind Nginx. We choose the stack based on requirements and existing infrastructure.
Typical stack
- C++
- CMake
- Boost
- REST and SOAP
- PostgreSQL
- React
- TypeScript
- Docker
- Kubernetes
- SonarQube
Case studies
Work in the ePA, a practice network and emergency care
On the ePA, we work within IBM Deutschland's existing development team. We built the Praxisnetz Nürnberg Süd platform as a complete system, as well as Ride-Guard, a web app that lets medical personnel retrieve stored emergency information by scanning an NFC chip or QR code.
HealthcareIBM Deutschland GmbH
EHR Backend Development
C++-based backend development for Electronic Health Records following Gematik standards
C++RESTDocker
HealthcarePraxisnetz Nürnberg Süd e.V.
Praxisnetz Nürnberg Süd Appointment Platform
Regional appointment exchange for medical practices with specialty-based search, secure booking and automated billing
ReactExpressPostgreSQL
HealthcareRide-Guard
Ride-Guard Emergency System
Next.js-based emergency platform for motorcyclists and adventurers with NFC chip and QR code integration
Next.jsSupabaseStripe
Frequently asked questions
Frequently asked questions about healthcare software development
No. gematik approvals apply to components and services of the telematics infrastructure and their manufacturers or providers, and we do not hold such an approval. Our experience with gematik specifications comes from backend development for the ePA at IBM Deutschland. If your project requires an approval, we clarify early which parts are affected and who is responsible.
No, we do not develop certified medical devices. Whether your project falls under medical device regulation should be clarified before it starts. Our focus is software for organization, communication and data exchange, such as appointment platforms, portals and backend services.
For healthcare providers, health and long-term care insurers and their processors, Section 393 SGB V governs this: it is permitted if location, technical and organizational measures, a current C5 attestation and the implemented customer criteria are in place. We plan the architecture and provider choice accordingly and implement the customer criteria in the application. The data protection assessment remains with you and your data protection officer.
Yes, that is how we work at IBM: we implement development tasks in C++ backend components, review pull requests and keep performance and security in view. In your project we work the same way, within your processes, your ticketing system and your review rules instead of bringing our own.
It depends on scope, integrations, security and data protection requirements and your existing systems, including requirements such as Section 393 SGB V or a TI connection. In a free 30-minute initial call, we assess feasibility and scale. You then receive a transparent proposal covering approach, milestones and billing.
Initial consultation
Discuss your healthcare project with the founders
Tell us briefly which data your software processes and who uses it. In a free 30-minute call, we clarify which requirements apply and what a sensible first step looks like. We reply to every inquiry within 24 hours.
More services
What else we build for businesses.
Web apps & business software
Internal tools, dashboards and SaaS products that follow your processes instead of bending them. Designed and coded by the founders themselves.
Learn moreCustomer & service portals
Protected portals for customers, dealers and members: orders, bookings and documents as self-service, with clear roles and permissions.
Learn moreIntegrations & automation
API integrations, ERP and accounting connections, PDF imports and automated jobs that move data reliably between your systems.
Learn moreAccessibility & BFSG
WCAG 2.2 AA audits, fixes in the source code and automated CI checks for web apps, portals and online shops that fall under Germany's BFSG.
Learn more