Real-Time Healthcare Video Glossary: Compliance and Media Terms

Germany

KBV (Kassenärztliche Bundesvereinigung)

The KBV (Kassenärztliche Bundesvereinigung) is the umbrella body of Germany’s 17 regional Associations of Statutory Health Insurance Physicians and represents contracted physicians and psychotherapists at federal level. For video care, the KBV and the GKV-Spitzenverband, the national association of statutory health insurers, agree the technical requirements in Anlage 31b and publish a list of certified video service providers. The KBV does not certify services itself: independent, accredited bodies do, so “KBV-certified” is market shorthand for a service on that list. A practice can generally bill video consultations only after telling its regional association that it uses a certified provider.

Why it matters: for a product aimed at German statutory care, that list is the gate to your customers’ billing; Trembit’s teletherapy platform development work includes webPRAX Face2Face, a psychotherapy video service on it.

Anlage 31b BMV-Ä

Anlage 31b to the Bundesmantelvertrag-Ärzte (BMV-Ä) is the agreement, made under § 365 SGB V, that sets the technical, security and data protection requirements for video consultations in German statutory care. The current reading version is dated 5 August 2026. Transmission should be peer-to-peer without a central server; a provider that departs from this must still ensure adequate protection. All content must be end-to-end encrypted to the state of the art set by BSI TR-02102, the provider may neither view nor store it, and connection metadata must be deleted within three months. Compliance is proven with an IT-security certificate and a GDPR Article 42 data protection certificate, both from ISO/IEC 17065-accredited bodies.

Why it matters: these clauses decide your media architecture before the first sprint, above all whether an SFU is acceptable and how end-to-end encryption survives it; our guide to meeting KBV certification requirements walks through them.

DiGA (Digitale Gesundheitsanwendung)

A DiGA (digitale Gesundheitsanwendung, digital health application) is a medical device whose main function rests on digital technology and which people with German statutory insurance can receive on prescription or with their insurer’s approval, once BfArM has listed it in the DiGA directory under § 139e SGB V. Under § 33a SGB V, eligible products are in risk class I, IIa or IIb. Since 1 January 2025, manufacturers must prove data security with a certificate based on BSI technical guidelines, and a separate data protection certification applies. From 1 July 2026, permanently listed DiGA must collect data for application-accompanying success measurement (AbEM).

Why it matters: DiGA status is a reimbursement route, not a licence to run video consultations, so a DiGA with live sessions still has to settle how its video meets German rules; our guide to Germany’s certified telehealth developers separates DiGA makers from video platforms.

DSGVO (Datenschutz-Grundverordnung)

DSGVO (Datenschutz-Grundverordnung) is the German name for the EU General Data Protection Regulation, Regulation (EU) 2016/679, which has applied since 25 May 2018. It treats data concerning health, meaning personal data about a person’s physical or mental health including the provision of health care, as a special category whose processing is prohibited unless an Article 9 exception applies. Controllers and processors must secure processing in line with the risk, and Article 32 names pseudonymisation and encryption among the measures. Processing on a controller’s behalf needs an Article 28 contract, and the most serious infringements can be fined up to €20 million or 4% of worldwide annual turnover, whichever is higher.

Why it matters: in a video consultation, the stream, recordings, chat and call metadata can all carry health data, so architecture decides how much of your product falls under Article 9; see how to design GDPR-compliant healthcare video architecture.

gematik (Gesellschaft für Telematik)

gematik (Gesellschaft für Telematik) is the company that develops and operates the Telematikinfrastruktur (TI), Germany’s secure information, communication and security infrastructure for health care, set up under §§ 306 and 310 SGB V. The Federal Republic, represented by the Federal Ministry of Health, holds 51% of its shares; the rest belong to national bodies of the self-governing health system, including the KBV and the GKV-Spitzenverband. Applications on the TI include the electronic patient record (ePA), the e-prescription (E-Rezept), KIM secure messaging and the TI-Messenger. The KBV and GKV-Spitzenverband agree the video consultation requirements in consultation with gematik.

Why it matters: German practice software increasingly connects to TI services, so a video product that has to sit inside those workflows needs a plan for them; our telemedicine app development page covers the KBV and GDPR side of a German build.

United Kingdom

DSPT (Data Security and Protection Toolkit)

The Data Security and Protection Toolkit (DSPT) is an online self-assessment that every organisation with access to NHS patient data and systems must use to show it practises good data security and handles personal information correctly. It measures performance against the National Data Guardian’s 10 data security standards and replaced the Information Governance Toolkit in April 2018. The toolkit is updated each year: the 2026-27 edition (version 9) was published in September 2026. For NHS trusts, integrated care boards and several other organisation types, including key IT suppliers, it uses an outcomes-based format aligned to the Cyber Assessment Framework (CAF).

Why it matters: a video platform supplier with access to NHS patient data and systems has to complete it, and buyers read it next to your clinical safety evidence; our guide to NHS-compliant video shows where it fits alongside DCB0129 and FHIR.

DTAC (Digital Technology Assessment Criteria)

The Digital Technology Assessment Criteria (DTAC) is NHS England’s assessment framework that care commissioners and providers use to assure digital health technology products before using them in the NHS and adult social care. It covers five areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility. In early 2026 NHS England issued a refreshed form with 25% fewer questions, removed duplication with the DSPT and the pre-acquisition questionnaire, and focused DTAC on software-based products. The previous form should not be used from 6 April 2026 onwards. DTAC works alongside other approvals, such as medical device certification, and does not replace them.

Why it matters: evidence packs written for the old question set need re-mapping to the new form; our security and compliance service builds the clinical-safety and governance evidence NHS buyers ask for.

DCB0129

DCB0129 is the NHS information standard for clinical risk management in the manufacture of health IT systems, published under section 250 of the Health and Social Care Act 2012. It applies to organisations that develop and maintain health IT for use in health and care, and sets requirements for a clinical risk management process, with a Clinical Safety Officer responsible for the safety of the system. Its core records are a Hazard Log, which tracks how hazards are identified and resolved, and a Clinical Safety Case Report, which argues that the system is safe for a given use at a defined point. The current specification is version 4.2, and NHS England has started a review of DCB0129 and DCB0160.

Why it matters: for a video consultation product, hazards such as a dropped call mid-assessment or one-way audio belong in the Hazard Log; our guide to clinical AI frameworks shows how teams structure that evidence.

DCB0160

DCB0160 is the NHS information standard for clinical risk management in the deployment, use, maintenance and decommissioning of health IT systems. It applies to the health organisations that run a system, not to the manufacturer that built it. Like DCB0129, it is published under section 250 of the Health and Social Care Act 2012 and sets requirements for the effective application of clinical risk management, in this case in the local setting where the system is used. The two standards are designed to work together: DCB0160 is supported by the manufacturer-side DCB0129. NHS England has started a review of both to keep them aligned with current technology and clinical practice.

Why it matters: your NHS customer’s DCB0160 work builds on the safety evidence you hand over under DCB0129, so the two sets of documents have to agree; our guide to NHS-compliant video covers both sides.

NHS login

NHS login is the NHS identity service that gives patients a simple, secure and reusable way to access multiple digital health and care services. Patients registered with a GP practice in England, or receiving NHS services in England, create an account, complete security checks, and can then sign in to any app or website that shows the NHS login button, including the NHS App. It is based on OpenID Connect, and each integrating service chooses the level and combination of identity verification and authentication it requires. To use it, a service must be commissioned or sponsored by an NHS organisation and align with the NHS Long Term Plan.

Why it matters: for a patient-facing video service, NHS login can replace a separate account and identity check before the consultation, but eligibility depends on NHS sponsorship; our system integration service covers identity integration alongside NHS APIs.

GP Connect

GP Connect is a set of NHS services that let authorised clinicians and systems in other care settings use a patient’s GP practice record, regardless of which GP clinical system the practice runs. Its capabilities are Access Record (a read-only HTML view, or structured, coded data a consuming system can import), Appointment Management (booking into the patient’s practice or another care setting in a primary care network), Update Record and Send Document, which delivers a consultation summary to the registered practice. Access Record is offered as FHIR APIs, while Send Document travels over ITK3 messaging and MESH. A National Data Sharing Arrangement launched in 2023 sets user organisations’ obligations.

Why it matters: when a consultation happens away from the patient’s own practice, Send Document or Update Record is how the outcome reaches the GP record; see our guide to NHS-compliant video.

United States

BAA (Business Associate Agreement)

A business associate agreement (BAA) is the written contract HIPAA requires before a covered entity lets a business associate create, receive, maintain or transmit protected health information (PHI) on its behalf. Business associates include app developers, cloud providers, IT contractors and AI vendors serving health plans, clearinghouses or providers, and a subcontractor handling PHI for a business associate is one too. Under 45 CFR 164.504(e), the BAA must describe the permitted and required uses and disclosures of PHI and bar the associate from using or disclosing it beyond them. Business associates are also directly liable for certain HIPAA requirements, including the Security Rule.

Why it matters: every vendor in a telehealth call path that handles PHI, from the video API to recording storage and transcription, needs a BAA or has to leave the path; our SFU comparison for telemedicine shows how this differs between managed and self-hosted media servers.

PHI (Protected Health Information)

Protected health information (PHI) is individually identifiable health information that a HIPAA covered entity or its business associate holds or transmits, in any form or media: electronic, paper or oral. It covers information, including demographic data, about a person’s past, present or future physical or mental health, the care they receive, or payment for that care, when it identifies them or could reasonably be used to identify them. Names, addresses, birth dates and Social Security numbers are common identifiers. Employment records held by a covered entity in its role as employer are excluded, and de-identified health information carries no Privacy Rule restrictions.

Why it matters: in a telehealth product, PHI is not only the medical record; the visit’s video and audio, chat, recordings, transcripts and appointment data can qualify when they identify a patient, so map where each one flows, as in HIPAA-grade telehealth from MVP to audit-ready.

HITECH Act

The HITECH Act (Health Information Technology for Economic and Clinical Health Act) is a US law enacted as part of the American Recovery and Reinvestment Act of 2009 and signed on 17 February 2009 to promote the adoption and meaningful use of health information technology. Its privacy and security provisions strengthened HIPAA enforcement with four tiers of civil penalties by level of culpability, made business associates directly liable for certain HIPAA requirements, and led to the HIPAA Breach Notification Rule, which requires covered entities and business associates to give notice after a breach of unsecured PHI. HHS finalised these changes in its 2013 Omnibus rulemaking.

Why it matters: HITECH is why a video or transcription vendor cannot treat HIPAA as only its customer’s problem, and why an incident needs a breach-notification plan; see is your telehealth platform actually HIPAA audit-ready?

Real-time media & voice

DTLS-SRTP

DTLS-SRTP is the key-exchange method WebRTC uses to encrypt audio and video: a DTLS handshake on the media path derives the keys for Secure RTP (SRTP) and SRTCP (RFC 5764). Because keying happens on the media path, it does not depend on the signalling channel. The WebRTC security architecture (RFC 8827) makes it mandatory: implementations must support SRTP, DTLS and DTLS-SRTP keying, and all media channels must be secured via SRTP. The protection runs between the two ends of each DTLS session, so when media is routed through an SFU, that session ends at the server and the protection is hop-by-hop.

Why it matters: DTLS-SRTP satisfies “encrypted in transit”, but on its own it does not meet a requirement that your media server must not see content; see building HIPAA-compliant video consultations with WebRTC and LiveKit.

SFrame (Secure Frame)

SFrame (Secure Frame, RFC 9605, August 2024) is an IETF standard for end-to-end encryption and authentication of media frames in multiparty calls, designed so that SFUs can read the metadata they need to route media without access to the media itself. Unlike SRTP, it is independent of RTP, so it works with other media transports, and it encrypts whole frames, which is more bandwidth-efficient. SFrame leaves key management to the application, for example through Messaging Layer Security (MLS). In browsers, the W3C WebRTC Encoded Transform working draft defines SFrame encryptor and decryptor objects for RTP senders and receivers.

Why it matters: SFrame is the standard way to keep an SFU while hiding media from your own servers, but server-side features such as recording or live captions then have to run on a client that holds the keys; see per-speaker live captions in WebRTC.

E2EE vs transport encryption

Transport (hop-by-hop) encryption protects media on each network leg, while end-to-end encryption (E2EE) keeps media encrypted from sender to receiver so that no server in between can read it. In WebRTC, transport encryption is always present through DTLS-SRTP, but when a call is routed through an SFU, each leg ends at the server. For group calls, RFC 9605 describes two layers: hop-by-hop encryption between each endpoint and the SFU, and E2EE of the media between endpoints. A peer-to-peer WebRTC call has only two endpoints, so its DTLS-SRTP session already runs end to end, including when a TURN server relays the packets.

Why it matters: requirements such as Anlage 31b’s end-to-end rule or a hospital security questionnaire hinge on this difference, and it shapes server design; see when HIPAA requirements conflict with video performance.

TURN (Traversal Using Relays around NAT)

TURN (Traversal Using Relays around NAT, RFC 8656) is a protocol that lets a client behind a NAT or firewall exchange media through a relay server when a direct connection to its peers is impossible. The client asks the TURN server to allocate a relayed transport address, and the server forwards packets between that address and the peers; one allocation can serve several peers. TURN was designed to be used as part of ICE, where relayed candidates provide the path of last resort. Clients can reach a TURN server over UDP, TCP, TLS-over-TCP or DTLS-over-UDP. RFC 8656 replaced the earlier RFC 5766.

Why it matters: hospital and corporate networks can block the UDP paths WebRTC prefers, so a TURN service reachable over TCP or TLS decides whether clinicians can join at all; see why hospital networks break WebRTC.

ICE (Interactive Connectivity Establishment)

ICE (Interactive Connectivity Establishment, RFC 8445) is the protocol WebRTC uses to find a working network path between two endpoints when one or both sit behind NATs. Each side gathers candidate addresses: host addresses on its own interfaces, server-reflexive addresses learned from a STUN server, and relayed addresses allocated on a TURN server. The two sides exchange candidates, run connectivity checks on candidate pairs, and select a pair that works. ICE relies on STUN (RFC 8489) for these checks, which also keep NAT bindings alive. RFC 8445 replaced the earlier RFC 5245.

Why it matters: many “the call never connected” tickets trace back to ICE handling, such as a missing TURN fallback or ignored connection-state events; see why WebRTC projects fail in production.

SFU (Selective Forwarding Unit)

An SFU (Selective Forwarding Unit) is a media server that receives each participant’s audio and video streams and forwards selected streams to the other participants without decoding and mixing them. RFC 7667 describes this topology as a Selective Forwarding Middlebox, which chooses for each receiver which of the currently active sources to send. Because it forwards rather than transcodes, an SFU usually works with simulcast or SVC to give each receiver a stream that suits its bandwidth, desired video size and codec support. Each participant sends media once to the server rather than to every peer, and receives a separate stream for each participant it displays.

Why it matters: once a consultation has more than two parties, such as an interpreter or a family member, an SFU is the usual architecture, and it changes the encryption picture; see P2P vs SFU for telemedicine.

MCU (Multipoint Control Unit)

An MCU (Multipoint Control Unit) is a central conferencing server that, in its classic mixing form, decodes every participant’s stream, combines them into a composite audio and video output, re-encodes it and sends each participant a single stream. RFC 7667 maps MCUs onto the RTP mixer and translator roles and notes that they may also contain signalling support and application-layer functions. Mixing keeps each client’s download to one stream, which suits weak devices and legacy endpoints, at the cost of heavy server-side processing. Because the server decodes the media to mix it, the mixed output cannot be end-to-end encrypted between participants.

Why it matters: an MCU still earns its place for composite recording, SIP gateways or broadcast output, but not where media must stay hidden from servers; see SFU vs MCU vs P2P media server architecture.

Simulcast

Simulcast means sending several differently encoded versions of the same media source at the same time, typically the same camera at different resolutions or bitrates, as separate RTP streams. RFC 8853 defines how to do this in RTP and how to signal it in SDP with the `a=simulcast` attribute, and WebRTC exposes it as multiple encodings on one sender. An SFU then forwards whichever version suits each receiver’s bandwidth, screen size or layout, and can switch versions as conditions change without asking the sender to re-encode. The cost is higher upload bandwidth and encoding load on the sender.

Why it matters: a client that never sends the simulcast layers the SFU expects is a common cause of frozen or low-quality group video; see our WebRTC rescue playbook.

SVC (Scalable Video Coding)

SVC (Scalable Video Coding) encodes video as layers, a base layer plus enhancement layers in time (frame rate) or space (resolution), so a server can drop layers for a receiver without re-encoding. In WebRTC it is configured with the `scalabilityMode` setting defined in the W3C Scalable Video Coding Extension for WebRTC, a Working Draft last updated on 14 September 2026, using values such as `L1T3` for three temporal layers. That specification sends all layers in a single RTP stream; codecs whose RTP payload formats support this include VP8, VP9, AV1, H.264 and H.265. Compared with simulcast, the sender encodes once.

Why it matters: SVC lets an SFU adapt each receiver’s quality from one upload, which matters when participants join from networks of very different quality; see how we use it in WebRTC development.

WHIP (WebRTC-HTTP Ingestion Protocol)

WHIP (WebRTC-HTTP Ingestion Protocol, RFC 9725, March 2025) is an IETF standard for pushing live media from an encoder or browser into a streaming service or CDN over WebRTC, using a simple HTTP exchange. The client sends its SDP offer in an HTTP POST, receives the SDP answer in the response, and ends the session with an HTTP DELETE; ICE and DTLS-SRTP then carry the media as in any WebRTC session. WHIP supports Bearer token authentication. It fills a gap the RFC itself names: WebRTC deliberately leaves signalling unspecified, which held back its use for ingest in broadcast and streaming.

Why it matters: WHIP lets a live clinic session, lecture or event publish from standard encoders into a WebRTC or CDN pipeline without custom signalling code; see live streaming app development.

WHEP (WebRTC-HTTP Egress Protocol)

WHEP (WebRTC-HTTP Egress Protocol) is the playback counterpart to WHIP: a simple HTTP-based protocol that lets WebRTC viewers watch content from streaming services, CDNs or WebRTC transmission networks. The player sends an SDP offer in an HTTP POST to a WHEP endpoint and receives the answer, following the same pattern as WHIP, after which media flows over standard WebRTC. WHEP is not yet an RFC: as of 30 September 2026 it is the IETF working-group Internet-Draft draft-ietf-wish-whep-04 (June 2026), on the Standards Track, which has completed working-group last call.

Why it matters: WHEP lets a standard player receive a WebRTC stream from any compliant server, which matters when viewers need real-time rather than near-live playback; our WebRTC consulting covers WHIP/WHEP pipeline design.

LL-HLS (Low-Latency HLS)

LL-HLS (Low-Latency HTTP Live Streaming) is the low-latency mode of HTTP Live Streaming, which delivers live video over ordinary HTTP servers and CDNs with less delay from the live edge than standard HLS. It combines three mechanisms: Partial Segments, small pieces such as CMAF chunks published before a full segment is finished; Blocking Playlist Reload, where the server holds a playlist request until new content exists; and preload hints for upcoming parts. The mode is specified in the HLS second-edition Internet-Draft (draft-pantos-hls-rfc8216bis-22, August 2026), which would obsolete RFC 8216, and in Apple’s HLS developer documentation.

Why it matters: for one-to-many clinical education or live events, LL-HLS scales through standard CDNs with lower delay than classic HLS but is not conversational, which is where WebRTC takes over; see when WebRTC is mandatory and when it is overkill.

Jitter buffer

A jitter buffer is a receive-side buffer that holds incoming RTP packets briefly, puts them back in order and releases audio samples or video frames at a steady pace, so playback stays smooth even though packets cross the network with varying delay (jitter). The W3C WebRTC statistics specification describes its purpose as recombining RTP packets into frames and producing smooth playout, and exposes metrics such as `jitterBufferDelay` and the number of packets discarded for arriving too late. A larger buffer absorbs more jitter but adds latency, which is why WebRTC receivers adjust the buffer as network conditions change.

Why it matters: jitter-buffer statistics are among the first things to check when users report choppy audio or lip-sync drift, and in voice AI the buffer adds directly to response delay; see understanding jitter in WebRTC.

Barge-in

Barge-in is a caller’s ability to interrupt a voice system while it is speaking, using speech or keypad (DTMF) input, so the system stops its prompt and listens. The term comes from interactive voice response: the W3C VoiceXML 2.0 standard lets application authors enable or disable barge-in per prompt, noting that it speeds up conversations but should be turned off when the user must hear a warning or legal notice in full. In AI voice agents, barge-in means detecting the user’s speech while text-to-speech audio is playing, stopping playback quickly and passing the new input to the model.

Why it matters: an agent that talks over patients or ignores interruptions feels broken, and barge-in quality depends on VAD tuning and on how fast playback can be cut in the media pipeline; see voice AI agents over WebRTC.

VAD (Voice Activity Detection)

Voice activity detection (VAD) is signal processing that classifies short stretches of audio as speech or non-speech. In telephony codecs it drives discontinuous transmission: RFC 3389 describes the VAD’s job as discriminating between active and inactive voice segments, so the sender can stop sending full audio during silence and transmit comfort-noise updates instead. RTP can also carry a per-packet voice-activity flag (RFC 6464), which lets conference servers pick active speakers without decoding every stream; the detection algorithm itself is left to the implementation. Voice AI agents use VAD to decide when a user has started or stopped speaking.

Why it matters: in a voice agent, VAD settings decide both how fast the agent answers and whether it cuts people off, and they need tuning on real call audio rather than defaults; see building a voice AI agent on FreeSWITCH.

SIP trunk

A SIP trunk is an IP connection that carries phone calls between an organisation’s SIP-based voice system, such as an IP PBX, contact-centre platform or voice application, and a voice service provider’s network, in place of physical telephone lines. It uses SIP (Session Initiation Protocol, RFC 3261) to set up, modify and end calls, while the audio itself travels separately as RTP. The SIP Forum’s SIPconnect Technical Recommendation defines a standards-based approach to this direct IP peering between SIP-enabled PBXs and service providers, and the Forum runs SIPconnect certification. Through the trunk, the provider connects calls to and from the public telephone network.

Why it matters: a voice AI agent that answers or places ordinary phone calls, such as an appointment line, needs a SIP trunk into its media server; see AI voice assistant development.

Building real-time video or voice for German, UK or US healthcare?

Trembit is a WebRTC engineering team with 50+ video and voice projects behind it, including webPRAX Face2Face, a psychotherapy platform on the KBV and GKV-Spitzenverband list of certified video services. Tell us your market and your architecture, and we’ll show you which of these requirements shape your build first.

Talk to an engineer