By Eugenia Nemkova, Marketing Director, Trembit · Last updated 30 September 2026
Evaluating a telemedicine video vendor means testing two things that a generic video RFP usually misses. The first is compliance: can the vendor’s platform legally carry patient data in your market (a signed BAA in the US, a GDPR Article 28 processing agreement in the EU and UK, certification under KBV Anlage 31b in Germany, DSPT and clinical-safety evidence for the NHS), and can it show you where every piece of media goes? The second is clinical reliability: does a consultation hold together on a patient’s old phone, in a group session, behind a hospital firewall? A vendor that fails either track is the wrong choice. Below are eleven questions to ask, and what a credible answer sounds like.
If you’re already past choosing a vendor and dealing with a platform that drops calls, start with our WebRTC rescue playbook instead.
This is a buyer’s guide, not legal or clinical-safety advice. Confirm contract terms, certification scope and safety sign-off with your counsel and accountable roles.
Key takeaways
- Compliance and reliability are separate tracks. Most questionnaires cover only compliance and miss what actually breaks a launch: sessions dropping in front of clinicians.
- No vendor is “HIPAA-certified.” The evidence is a signed BAA covering every subcontractor that touches patient data.
- In the EU and UK, the DPA must cover the whole chain. That includes TURN relays and media-server hosting, not just the vendor’s own entity.
- KBV Anlage 31b covers every statutory video consultation in Germany, not only psychotherapy. It regulates the media path itself, and the certified list is public.
- Uptime is necessary but not sufficient. It tells you the server was up, not whether a consultation finished. Ask for a measured drop rate and a tested group size as well.
- Test on a real hospital network. UDP-blocking firewalls are where telehealth video breaks, and TURN over TCP/TLS is the standard fix.
Short on time? The eleven questions are condensed into a checklist you can paste into an RFP.
What compliance questions should you ask a telemedicine video vendor?
“Are you HIPAA/GDPR compliant?” is a question no vendor fails, so it tells you nothing. Ask for artefacts instead: a contract, a certificate with an expiry date, a data-flow diagram. In telemedicine video, compliance depends on where the media path runs and who can access it, and a badge tells you neither.
1. Will you sign a Business Associate Agreement, and who else in your stack signs one?
Under HIPAA, any company that creates, receives, maintains or transmits protected health information on your behalf is a business associate, and so is any subcontractor doing the same for them (HHS guidance on business associates). HHS does not recognise private “certifications” of Security Rule compliance.
The subcontractor point matters most for video. HHS’s cloud computing guidance says a provider storing only encrypted health data, with no decryption key, is still a business associate. The “conduit” exception covers only transmission services with no more than temporary storage. Whether a given relay qualifies is a legal call, so ask the vendor to put its position in writing.
A good answer: “Yes, here’s our standard BAA, and here are the subprocessors that touch patient data (hosting, TURN relays, recording storage, transcription) with their BAA status.” Red flag: “Our infrastructure is HIPAA-compliant,” with no BAA on offer. Encryption alone doesn’t make a platform compliant, and HIPAA requirements can pull against video performance in ways a good vendor can explain.
2. Will you sign a GDPR Article 28 processing agreement that covers every sub-processor?
Data concerning health is a special category under GDPR Article 9(1). Article 28 requires a binding contract between you and the processor. It forbids the processor from engaging another processor without your written authorisation, and it requires the same data-protection obligations to be passed down to every sub-processor by contract (Art. 28(2)–(4)). In a video platform, the SFU host, the TURN provider, recording storage and any transcription or AI service are all sub-processors.
A good answer: a DPA with a named sub-processor list that states what each one processes and where. Red flag: a DPA that covers only the vendor’s own legal entity, or a sub-processor list that just says “various cloud providers.” See our guide to GDPR-compliant healthcare video architecture.
3. Selling into German statutory care: is the product certified under KBV Anlage 31b?
Anlage 31b to the BMV-Ä (version of 5 August 2026) governs every video consultation in German statutory care, by doctors and psychotherapists alike, and practitioners may use only certified services (§ 4(4)). It regulates the media path itself:
- Transmission should be peer-to-peer, without a central server. A provider that deviates must ensure adequate protection (§ 2(2)).
- Content must be end-to-end encrypted to the state of the art defined by BSI TR-02102 (§ 2(3)), and the provider must be unable to view or store it (§ 2(4)).
- Processing is allowed only in Germany, the EU, an equivalent state, or an adequacy-decision country (§ 2a(2)).
- Evidence is two certificates from ISO/IEC 17065-accredited bodies: IT security, and GDPR Article 42 data protection (§ 5(2)).
The KBV doesn’t certify anyone itself. It publishes the list of certified providers, which makes this the easiest question here to verify.
A good answer: the product name as it appears on the KBV list, the certifying body and the expiry date. From most vendors, the honest answer is “no, and here’s what it would take.” Red flag: “We’re GDPR-compliant, so KBV is covered.” For psychotherapy specifically, see our teletherapy platform development page. For the full certification path, read how to meet KBV certification requirements.
4. Selling to the NHS: who is the manufacturer under DCB0129, and what goes into our DSPT?
The Data Security and Protection Toolkit is an annual online self-assessment against the National Data Guardian’s 10 data security standards. Every organisation with access to NHS patient data and systems must use it. The 2026-27 version (v9) was published on 8 September 2026. Clinical safety is a separate matter. DCB0129 applies to manufacturers of health IT and DCB0160 to the organisations deploying it, and NHS England is currently reviewing both standards.
A good answer: the vendor states which role it plays. If it sells you a product, it’s the manufacturer and should have a DCB0129 safety case and hazard log owned by its own Clinical Safety Officer. If it builds your product, you’re probably the manufacturer, and the vendor supplies the engineering evidence your CSO and DSPT submission rely on (encryption, access control, audit logging). If the vendor will access NHS patient data itself, ask for its own DSPT status. Red flag: a vendor that offers to “handle your DSPT” or sign your safety case. The full breakdown is in our guide to NHS-compliant video: DCB0129/DCB0160, DSPT and FHIR.
5. Where do patient data and media actually live, and can you show me?
“It’s encrypted, so location doesn’t matter” is the answer to watch for. For your business, this is the question a hospital security review or a data-protection authority will ask you, and “the vendor said it was encrypted” won’t carry the rollout. In a standard SFU architecture, WebRTC’s DTLS-SRTP encryption is hop-by-hop: the media server decrypts media in order to forward it, unless the vendor has added an end-to-end layer on top. A TURN relay chosen purely by geography can route a German patient’s call through a relay in another jurisdiction. This is exactly why Anlage 31b defaults to peer-to-peer.
A good answer: a region for each component (signalling, media server, TURN, recording storage, logs, any AI or transcription endpoint), in-region or self-hosted TURN, and a data-flow diagram the vendor can walk you through live. Red flag: “EU region” as a single answer covering everything.
6. How do you handle recording and consent?
A good answer: recording is off by default and needs separate, explicit, withdrawable consent from every party, not consent bundled into the terms of service. A visible indicator stays on throughout, and storage is encrypted, with role-based access and defined retention. Anlage 31b permits recording only with consent (§ 3). In the US, check state recording-consent law too, because some states require every party’s consent.
Then ask where recording happens. Pure peer-to-peer has no server to record on; with an SFU, the recording server joins your compliance scope.
What reliability questions should you ask a telemedicine video vendor?
An uptime figure answers “was the server up?” A clinician wants to know whether the consultation finished, on devices and networks the vendor doesn’t control. The German regulator writes it into the rules: Anlage 31b requires the software to adapt audio and video quality when connection quality fluctuates (§ 5(1) no. 4).
7. What is your call drop rate, and how exactly do you measure it?
For your business, a dropped consultation is a lost appointment and a clinician who stops trusting the tool, and neither shows up in an uptime report.
A good answer: a number with a definition, for example “sessions with an unrecovered disconnect, as a share of sessions that connected.” It should come with the method (client-side telemetry from WebRTC’s getStats() API, per-session quality records, alerting) and ideally a breakdown by platform and network. Ask separately for the connection-setup failure rate, because sessions that never connect don’t show up in a drop rate.
Red flag: an uptime percentage offered as the whole answer.
8. At what group size does quality degrade, and on which devices did you test that?
In an SFU, each participant sends one stream but receives and decodes one from everyone else, so the load on the weakest device grows with every tile. In a peer-to-peer mesh, upload grows too. Group sessions break first on the patient’s budget phone, not on the server; we explain why in the six-participant scaling cliff.
Video group psychotherapy is capped at eight patients plus one therapist. The KBV list of 24 August 2026 shows each product’s maximum participant count, from 2 to 400, and its footnote says these figures are supplied by the vendors. A declared maximum is where the conversation starts. Ask how it was tested.
A good answer: a participant count from load tests on mid-range phones over home and mobile networks, plus what happens at the limit: simulcast layers, pausing off-screen video, audio-only fallback.
9. How does the platform behave on a restrictive hospital network?
Hospital guest and clinical networks often block UDP or allow only web ports. The TURN standard, RFC 8656, supports TCP “because some firewalls are configured to block UDP entirely,” and also defines TLS-over-TCP.
A good answer: TURN over UDP, TCP and TLS on port 443, self-hosted or in-region, tested from inside a real hospital network or a simulated locked-down one. The vendor should also know what share of its sessions fall back to relay. Red flag: “Our video API handles that,” with no detail behind it.
Locked-down clinical networks are the everyday environment for much of our telemedicine app development work, including the hospital platform described below.
10. What happens when a session drops mid-consultation?
A good answer: automatic reconnection (ICE restart) without sending the patient back to a waiting room. The clinician sees an explicit “patient reconnecting” status rather than a frozen frame. There’s a defined timeout with a fallback such as a rejoin link or a phone line. And rejoining re-checks identity, so a dropped seat in a group session can’t be taken by someone else (Anlage 31b already requires everyone in the room to be introduced at the start, § 3). This is a clinical-safety question as much as a technical one: under DCB0129, a silent drop mid-consultation is a hazard-log entry.
11. Do you own the media layer, or are you wrapping a third-party video API?
Either answer can be fine; you’re testing whether the vendor names the trade-off honestly. With a hosted video API, the API provider becomes another sub-processor needing its own BAA or DPA, and its regions, relays and outages become yours. A vendor that owns the WebRTC layer (self-hosted SFU and TURN, or peer-to-peer) has more to operate, but can draw a data-flow map and defend it to a reviewer. For the architecture choice underneath this, see P2P vs SFU for telemedicine and, if an SFU is on the table, choosing between Janus, mediasoup and LiveKit. Red flag: the vendor can’t tell you which of the two it is.
A short checklist to bring into a vendor call
Compliance
- [ ] Signed BAA, plus every subprocessor touching patient data and its BAA status
- [ ] GDPR Article 28 DPA with a named sub-processor list: what each processes, and where
- [ ] Germany: product name, certifying body and expiry date as they appear on the KBV list
- [ ] NHS: who is the DCB0129 manufacturer, what evidence the vendor gives your CSO and DSPT, and its own DSPT status
- [ ] Per-component hosting region, including TURN, recording and AI/transcription, shown on a data-flow diagram
- [ ] Recording off by default, with separate, withdrawable consent from every party
Reliability
- [ ] Drop rate and connection-setup failure rate, each with a definition and measurement method
- [ ] Tested maximum group size, with the devices and networks it was tested on
- [ ] TURN over TCP/TLS on 443, tested on a locked-down network
- [ ] Mid-session reconnect behaviour, clinician alert, fallback and identity re-check
- [ ] Owned media layer or wrapped API, and who is in the media path
Don’t have a shortlist yet? Our comparison of telemedicine app development companies is a starting point.
How does Trembit answer these questions?
We build telemedicine video layers for other companies’ products, so we’re usually the ones answering this list. Two deliveries show how.
Compliance, Germany: we built webPRAX Face2Face, a peer-to-peer psychotherapy video platform. There’s no server-side access to or storage of media, the infrastructure is 100% German-hosted, STUN/TURN is self-hosted, and recording needs dual consent. It’s certified under Anlage 31b and appears on the KBV list of 24 August 2026 under its provider, Healthy Projects GmbH, with a certificate valid to February 2028 and a declared maximum of 20 participants.
Reliability, US: in a long-term development partnership on Equiti Health’s Martti medical video-interpreting platform, we built the WebRTC core, the Epic, Oracle Cerner and eClinicalWorks integrations, and the monitoring stack, under HIPAA and SOC 2. It serves 4,000+ healthcare facilities, often on constrained hospital networks, at 99.99% uptime, sustained through redundancy at every layer, automated failover and real-time monitoring of connection quality.
Uptime is the reliability figure we publish, so apply this guide’s own test to it. It proves the platform stayed available across thousands of facilities, the precondition for everything else. It doesn’t prove that every consultation finished. That’s the job of the session-level monitoring behind it, and we’d rather walk you through those measurements on a call than print a drop rate here without its definition.
Where our role ends is part of the answer. We’re the engineering partner: we don’t act as your Clinical Safety Officer, submit your DSPT, or claim certifications we haven’t earned. We build the platform and produce the evidence those accountable roles review. That’s the work behind our telemedicine app development practice.
FAQ
What’s the single most important question to ask a telemedicine video vendor? There isn’t one. A vendor strong on compliance and weak on reliability, or the reverse, is still the wrong pick. If you only get two questions, ask for the sub-processor list behind the BAA or DPA, and for the measured drop rate with its definition. Together they show whether the vendor knows its own media path.
Is a HIPAA-compliant video vendor automatically GDPR-compliant? No. A vendor serving both markets needs a BAA for US patient data and a separate Article 28 DPA for EU/UK data, and neither covers KBV certification or NHS obligations.
Do I need a KBV-certified vendor if I’m not doing psychotherapy in Germany? If you offer video consultations billed to German statutory health insurance, yes. Anlage 31b covers doctors’ consultations as well as psychotherapy. Outside the statutory system, it doesn’t apply.
What’s a realistic call drop rate for a telemedicine platform? We haven’t seen a universal benchmark with a published method, so we won’t quote one. The useful test is whether the vendor has its own measured figure, defines what counts as a drop, and reports connection-setup failures separately. Ask any vendor, including us, for their measured number on a call.
Should I choose a vendor that uses a third-party video API, or one that owns the WebRTC layer? A hosted API is faster to a demo but adds a sub-processor and infrastructure you can’t audit. An owned layer costs more engineering and is easier to defend in review. In Germany, the peer-to-peer default in Anlage 31b tips the balance.
Can I use this checklist to audit a platform we already built? Yes. Every question applies to an in-house platform, for example ahead of a compliance review or a KBV certification attempt.
The right vendor answers both tracks credibly, not just the one it’s comfortable with. If you’re weighing vendors’ answers, or checking your own platform against this list, talk to Trembit’s telemedicine team. It’s a free 30-minute architecture call: bring the answers you’ve collected or your current architecture, and we’ll go through them against this checklist. No deck, no pitch.
