If you’re building a video therapy platform for the German market, KBV certification isn’t a checkbox at the end of your roadmap. It’s a constraint that shapes every major architecture decision from day one — and teams that treat it otherwise tend to find out the hard way, usually six months into development and weeks before a planned launch.
The Kassenärztliche Bundesvereinigung (KBV) sets the technical standards for video consultation systems used in statutory health insurance (GKV) billing in Germany. The governing framework, KBV Anlage 31b, defines what your system must do, how it must do it, and what evidence you need to prove it. From 2020, any platform seeking reimbursement for video consultations under GKV must pass this certification.
This article is for CTOs, lead engineers, and product leaders who are either building toward certification or have inherited a platform that needs to get there. We’ll cover the core architectural requirements, the decisions that most often derail reviews, and the patterns that reliably pass.
What KBV Certification Actually Tests
The review process evaluates your platform against a published technical specification. Auditors are not testing whether your product is good — they’re testing whether your implementation is provably compliant with a defined standard.
That distinction matters architecturally. You’re not optimizing for user experience during the review; you’re producing documented, verifiable evidence that your system behaves according to specification under defined conditions.
The certification covers five main domains:
- Video and audio quality — minimum bitrates, resolution standards, codec requirements
- Encryption and transport security — end-to-end encryption requirements, TLS versions, key handling
- Authentication and identity — patient and practitioner identity verification, session authorization
- Data residency and processing — where data is stored, processed, and transmitted
- Logging and audit trail — what must be recorded, for how long, and in what format
Each domain has both functional requirements (what the system must do) and testable criteria (how auditors verify it). Your architecture needs to satisfy both.
The Five Architecture Decisions That Determine Whether You Pass
1. Encryption Architecture: End-to-End Is Non-Negotiable, But Implementation Details Matter
KBV requires end-to-end encryption for all video and audio streams. In practice, this means WebRTC with DTLS-SRTP — the default transport encryption in browser-based WebRTC. But “using WebRTC” is not the same as being compliant.
What gets teams in trouble:
The most common failure here is using a media server architecture (SFU or MCU) in a way that breaks end-to-end encryption. Many popular video infrastructure providers — and many homegrown systems — route media through a server that decrypts and re-encrypts streams. This is invisible to users but terminates E2E encryption at the server.
KBV Anlage 31b requires that media content is not accessible to intermediary servers. If your SFU touches decrypted media — for transcription, recording, layout composition — you need to document this explicitly and ensure that such processing happens only with proper consent and under a data processing agreement (DPA) that satisfies GDPR and the German Social Code (SGB X).
What passes:
- Selective Forwarding Unit (SFU) architectures, where the server forwards encrypted packets without decryption
- Clear documentation of where keys are generated, stored, and rotated
- TLS 1.2 minimum on all signaling channels (TLS 1.3 preferred)
- Cipher suite documentation included in your technical submission
2. Data Residency: Germany (or EEA) Is Required — and Provable
Health data processed under GKV rules falls under both GDPR and the German Social Code Book V (SGB V). The practical upshot: patient data must be stored and processed within Germany or the European Economic Area, and you must be able to demonstrate this.
What gets teams in trouble:
Using a global CDN or media relay network without pinning to EEA regions. Many cloud providers have “EU regions” that technically span EEA jurisdictions but may route traffic through non-EEA infrastructure during failover. If you can’t contractually and technically guarantee EEA residency, auditors will flag it.
Relying on a US-headquartered infrastructure provider without a valid data processing agreement and Standard Contractual Clauses (SCCs) is a common blocker that surfaces late in the process.
What passes:
- Infrastructure explicitly deployed in German or EEA data centers (AWS Frankfurt, Azure Germany North, and Google Cloud Frankfurt are all used successfully)
- TURN server infrastructure located within Germany — this is frequently missed; if your TURN servers are in Virginia, media packets traverse the US
- Data processing agreements with all subprocessors that include SCC addenda
- Architecture diagrams included in the submission that map every data flow to a geographic location
3. Session Authentication: Two-Factor for Practitioners, Verified Identity for Patients
KBV requires practitioners to authenticate with two-factor authentication. Patient authentication requirements are less prescriptive but must include a verifiable identity link to the appointment booking.
What gets teams in trouble:
Implementing 2FA as an optional feature rather than a mandatory gate. If practitioners can bypass 2FA even in an edge case (password reset flow, legacy API token, admin override), the system is non-compliant.
Session token handling is also scrutinized. Tokens must expire, must be invalidated on logout, and must not be transmissible in URL parameters (which appear in server logs and browser history).
What passes:
- 2FA is enforced at the account level for all practitioner roles, with no bypass paths
- TOTP (authenticator app) or SMS as an acceptable second factor
- Session tokens are delivered via HTTP-only cookies or secure storage, never in URLs
- Token expiration under 24 hours with explicit re-authentication for new sessions
- Invitation-based patient session links that are single-use or time-limited
4. Audit Logging: Structured, Immutable, and Retention-Compliant
KBV requires a documented audit trail of consultation sessions. This is not application logging — it’s a separate, tamper-evident record that can be produced during an audit or dispute.
Required events to log (at minimum):
- Session creation and termination with timestamps
- Practitioner and patient join/leave events.
- Authentication events (login, 2FA verification, logout)
- Any technical failures that interrupted the session
- Consent acknowledgments
What gets teams in trouble:
Conflating application logs with audit logs. Your Datadog or CloudWatch logs are for operations — audit logs are for compliance. They need separate storage, separate access controls, and a defined retention period. For GKV-related records, the retention requirement is typically 10 years under SGB V.
Using mutable log storage. If your audit logs are stored in a database table that application code can write to, that’s not audit-grade. Auditors look for append-only storage, cryptographic chaining, or a separate write-protected log sink.
What passes:
- Dedicated audit log storage, separate from application logs, with write-once semantics
- Structured log format (JSON with defined schema) that can be exported for review
- Log entries include session IDs, user IDs (pseudonymized where required), and event type.
- Retention policy documented and technically enforced (e.g., S3 Object Lock with 10-year retention)
5. Video and Audio Quality: Minimum Baselines Must Be Provable Under Test Conditions
KBV specifies minimum quality thresholds for video consultations. The current requirements include a minimum video resolution of 320×240 pixels and a frame rate of 15fps at standard consultation bandwidth, with audio quality sufficient for clinical communication.
What gets teams in trouble:
Passing quality tests on a developer machine on a fast office connection, then failing under simulated network constraint tests that auditors use. The spec requires that quality baselines are maintained under defined degraded network conditions, not just under ideal conditions.
Adaptive bitrate logic that aggressively reduces quality before dropping the call is often the right product decision, but can push you below the certification floor during stress tests if thresholds aren’t tuned.
What passes:
- Documented quality floor settings in WebRTC configuration that prevent codec parameters from falling below KBV minimums
- Quality metrics collected via RTCPeerConnection.getStats() and logged per session
- Network simulation testing (Chrome DevTools throttling, tc netem in CI) as part of your pre-submission test suite
- Codec configuration documented: VP8/VP9/H.264 all pass; document what you use and why
Architecture Decision Summary
| Decision Area | Common Failure | Passing Pattern |
| Encryption | SFU decrypts media without documented DPA | SFU in forwarding-only mode; key handling documented |
| Data residency | TURN/media servers outside EEA | All infrastructure pinned to German/EEA regions |
| Authentication | 2FA optional or bypassable | 2FA mandatory, no bypass paths, token expiry enforced |
| Audit logging | App logs used for compliance | Separate append-only audit store, 10yr retention |
| Video quality | Quality untested under degraded conditions | Codec floors set, stress tested, metrics logged per session |
The Certification Process: What to Expect
KBV certification for video consultation systems is managed through the KBV itself and requires submission of a technical dossier, a self-assessment questionnaire, and evidence of testing. The review timeline varies but typically runs 8–16 weeks from a complete submission.
The most common reasons for extended timelines or rejection:
- Incomplete documentation — missing architecture diagrams, undocumented subprocessors, or gaps in the DPA chain
- Failed technical tests — quality or security tests that don’t meet the specification under test conditions
- Scope creep during review — making infrastructure changes after submission that require re-review
The practical implication: treat your submission as a snapshot. Lock your infrastructure and configuration before submission, and plan your development roadmap around the review window.
Working with a Partner Who Knows This Territory
KBV certification sits at the intersection of WebRTC engineering, German healthcare regulation, and cloud infrastructure compliance. Very few teams have deep expertise in all three simultaneously — and gaps in any one area show up in the review.
Trembit has worked with telehealth and video consultation platforms targeting the German and European markets, helping teams structure their architecture for regulatory compliance from early design through certification submission. We’ve navigated the specific requirements of KBV Anlage 31b, helped teams identify compliance gaps in existing systems, and built the audit logging, encryption, and authentication infrastructure that passes review.
If you’re building toward KBV certification, starting a remediation effort on an existing platform, or trying to understand what your current architecture is missing, we’re available for a technical assessment.
Getting the architecture right before submission is always cheaper than fixing it after.
