A huge share of clinical communication runs on consumer messengers because the compliant alternatives were priced for hospital systems. A self-hosted, source-available E2E messaging framework where the server provably holds no keys — and where the admin content inspector doesn’t exist, the search seam raises if you point it at patients, and the honest limits are stated up front.
The compliance gap everyone in healthcare knows about, and what closing it actually looks like in code.
Here’s a fact the healthcare industry would rather not put in a press release: a huge share of clinical communication runs on WhatsApp. The X-ray a GP sends a dermatologist for a second opinion. The photo a patient sends of a wound that looks angry. The quick “is this normal?” at 9pm. It’s all flowing through a consumer messenger, on personal phones, sitting on a third party’s servers in another jurisdiction, in the same app as the family group chat.
Everyone involved knows it’s a bad idea. They keep doing it, because for years the alternative was a six-figure enterprise contract or nothing, and “nothing” doesn’t answer the patient. That’s the gap. And it’s the kind of gap that self-hosted, source-available software is unusually well suited to closing.
VBWD‘s messaging plugins — meinchat and meinchat-plus — are a decent case study in what that alternative looks like when it’s built properly. Also in what it honestly can’t do, which is the more interesting half.
The architectural claim
The line that matters, straight from the project’s documentation: the server holds no keys and never encrypts or decrypts. Clients encrypt. The server validates that the sealed envelope has a legal shape and size, stores it, broadcasts it, tracks delivery. Full stop.
That’s a meaningfully different security posture from “we encrypt your data at rest and promise not to look.” A clinic’s own sysadmin can’t read a consultation. Neither can the hosting provider, nor anyone who walks off with the database. Confidentiality isn’t resting on policy or good intentions — it rests on the server not having the keys. There’s nothing to subpoena from the operator that isn’t ciphertext.
Underneath is a Signal-style double ratchet, with the unglamorous parts that separate real crypto from a weekend project: signed and one-time prekeys consumed atomically (so two senders can’t race for the same one), which is what makes asynchronous first-message delivery to an offline recipient work. Padding to fixed 256-byte blocks, so traffic analysis reveals length only to within a block. A downgrade defence — a client that demanded encryption rejects a reply that arrives in plaintext protocol. Multi-device, including reading your own sent messages on a second device, with biometric pairing on iOS.
And a precision point that matters, because a sloppy security claim is just a false one: base meinchat is not end-to-end encrypted. It encrypts the local cache on the device; messages themselves pass through the server readable. E2E comes from enabling meinchat-plus, a separate plugin layered on top via extension ports. For clinical use that plugin isn’t a nice-to-have — it’s the entire premise.
Three decisions worth stealing
The admin content inspector doesn’t exist. Not “is permission-gated” — doesn’t exist. Admins manage nicknames, ban abuse, audit transfers. There is no screen that opens a doctor-patient thread. You can’t misconfigure your way into a practice manager reading consultations, because the code isn’t there. That’s privacy enforced by absence, which is the only kind that survives a bad quarter and a curious executive.
Retention defaults to two days. A nightly job hard-deletes messages and attachments — no tombstones, no soft-delete graveyard quietly retaining what you believed was gone. Set it to zero and the server is effectively amnesic. Data minimisation as the default rather than a checkbox on page four of the settings.
The search seam physically can’t reach patients. The bot framework’s /search command reads a core registry that raises if a plugin tries to register users, user details, or invoices as searchable. Not a filter — a refusal at registration. There is no code path by which a bot gets talked into searching your patient list. More projects should encode their compliance boundaries as things that throw.
The dependency graph is the product
There’s an engineering detail here that explains why this works at all. The messenger, the E2E layer, and the bots are separate plugins over one core that already knows about users, permissions, and events. meinchat-plus doesn’t fork the messenger; it registers against extension ports. The bot bridge doesn’t hard-import the crypto — it detects whether a real device directory exists and negotiates plaintext or E2E accordingly, so a bot works identically whether or not you deployed encryption.
That’s why “turn on end-to-end encryption for our clinic” is a deployment decision rather than a migration project. Most systems can’t say that, because their encryption story was bolted on after the schema was set.
There’s also a nice piece of operational honesty in the repo: SSE streaming once took production down, because synchronous workers each parked on an open chat tab until roughly four tabs froze the whole platform. The fix — threaded workers sized to the DB pool, releasing the connection during the idle wait, capped stream lifetimes — is committed in the shipped config. You inherit the scar tissue.
What it can’t do, plainly
No video. No voice. It’s text and images. If you’re picturing telemedicine as a video visit, this isn’t that tool and nothing about it pretends to be. What it fits is the enormous non-video volume of clinical work: follow-up, triage before booking, the photo, doctor-to-doctor eConsults, group rooms for multidisciplinary case discussion, guest intake from someone who isn’t a patient yet.
It is not a compliance product, because no software is one. E2E and self-hosting are strong foundations; HIPAA or GDPR compliance is organisational — DPIA, processor agreements, access policy, training, audit. The practice stays the data controller. Anyone selling you “HIPAA-compliant software” as a shrink-wrapped property is selling you a feeling.
It is not a certified medical device, and the retrieval bot is an administrative tool — opening hours, prep instructions, billing questions — never clinical advice or triage. That boundary is not negotiable, and it’s on the operator to hold it.
The messenger must not be the medical record. This is the sharpest tension in the whole idea and it’s worth stating loudly: record-keeping law wants years; this thing deletes after days, on purpose. Those coexist only if the EMR is the record of truth and the chat is merely the channel, with anything clinically significant documented properly. Treat a disappearing chat as a chart and you’ll meet a regulator.
Real encryption cuts both ways. A server that can’t read messages can’t recover them. Lost device, lost history. Any vendor promising both perfect confidentiality and full admin recovery is quietly not offering the first one.
Self-hosting is work. Someone patches, backs up, and holds the infrastructure keys. A two-doctor practice without IT capability may be genuinely better off with a managed vendor and a signed agreement. That’s a legitimate answer.
Why it’s worth watching
The interesting claim isn’t that this is free. It’s that the trade-off clinics accepted was always fake. The choice was never “consumer messenger or nothing” — it’s that the compliant options were built and priced for hospital systems, so everyone else used WhatsApp and hoped nobody noticed.
A framework where the server provably cannot read the messages, retention is yours, no admin can open a consultation, the bot can’t be pointed at your patient list, and the data never leaves your jurisdiction is a categorically different starting point. It doesn’t make you compliant. It doesn’t do video. But for the daily traffic of actual care, it’s a substantially better foundation than the app your patients use to send memes — and the fact that it’s a plugin rather than a platform means a clinic can adopt it without betting the practice on a vendor.
General information for technology and practice decision-makers — not legal, regulatory, or medical advice. Obligations vary by country and speciality; talk to your DPO and counsel before deploying anything that touches patient data.
Learn more about VBWD
VBWD is a self-hosted, source-available platform for building subscription products, marketplaces, and AI-powered apps. Explore it further:
- 🌐 Website and documentation: vbwd.cc — see the plugins, architecture, and developer docs.
- 💻 Source code and plugins on GitHub: github.com/VBWD-platform
- 🎥 Watch VBWD in action: demo video 1 and demo video 2
- 💼 Follow the project on LinkedIn: linkedin.com/company/vbwd
VBWD is source-available — get the SDK on GitHub.