Ask a doctor how they sent a colleague that X-ray last week and you’ll usually get a sheepish answer: WhatsApp. Ask how the patient sent the photo of their healing wound, and it’s the same. Clinical communication has quietly migrated onto consumer messengers — because they’re free, everyone has one, and they work.

They’re also a confidentiality problem hiding in plain sight. Patient images and clinical discussions end up on a third party’s servers, in another jurisdiction, on personal phones, in the same app as family group chats. The clinic doesn’t control where the data lives, how long it’s kept, or who could be compelled to hand it over. Most practices know this. They keep doing it anyway, because the compliant alternative was a six-figure enterprise contract or nothing at all.

There’s a third option worth knowing about: a self-hosted, end-to-end encrypted messaging framework you run yourself. VBWD‘s messaging plugins — meinchat and meinchat-plus — are open, source-available components designed for exactly this shape of problem. Here’s an honest look at what they do, and just as importantly, what they don’t.

What “end-to-end” actually means here

The claim that matters, stated plainly in the project’s own documentation: the server holds no keys and never encrypts or decrypts. Clients encrypt. The server checks that the sealed envelope is a legal shape and size, stores it, passes it on, and tracks delivery. That’s its entire role.

Read that again from a clinic’s perspective. It means your own server administrator cannot read a consultation. Neither can your hosting provider. Neither can anyone who obtains a copy of the database. The confidentiality doesn’t rest on a promise or a policy — it rests on the server not possessing the keys.

The encryption is a Signal-style double ratchet, the same broad design used by the messaging apps with the strongest privacy reputations. Around it sit the details that separate a real implementation from a demo: signed and one-time prekeys, so you can send a message to a colleague who’s offline and it decrypts correctly when they open their phone; padding of messages to fixed blocks, so an observer watching the traffic learns a message’s length only to within a block rather than exactly; a downgrade defence, so a client that demanded encryption refuses an answer that arrives unencrypted; and support for a second device, with biometric pairing on iOS.

One point of precision, because in security an imprecise claim is a false one: base meinchat is not end-to-end encrypted. It encrypts the message cache stored on the device, but the messages themselves pass through the server readable. End-to-end encryption comes from enabling meinchat-plus, a separate plugin that layers on top. For clinical use, that plugin isn’t optional — it’s the point.

Privacy that’s built in rather than promised

Three design decisions stand out for anyone handling patient information.

There is no way for an administrator to read conversations. The admin panel lets you manage nicknames, ban abusive accounts, and audit transfers. There is no screen anywhere that opens a doctor-patient thread. That’s not a permission you switch off — the feature doesn’t exist. A practice manager cannot read a consultation even if they want to.

Retention is short by default and yours to set. Server-side messages default to a two-day window, with a nightly job that hard-deletes them — no tombstones, no soft-delete graveyard quietly retaining what you thought was gone. Set it to zero and the server becomes effectively amnesic. That’s data minimisation as a default rather than an afterthought.

It runs on your infrastructure. Self-hosting means the data sits in a jurisdiction you chose, on hardware you control, with no third-party processor in the middle. For European practices weighing data-residency obligations, that’s a structurally different position from “a US vendor promises to store it in Frankfurt.”

What it fits: the conversation, not the consultation

Being clear-eyed about the shape of the tool matters more than listing features. meinchat has no video and no voice. It is text and images. It is not a video-visit platform, and if live consultations are what you need, this is the wrong tool and you should look elsewhere.

What it is good at is the enormous volume of clinical communication that isn’t a video visit:

• Doctor-to-patient follow-up — post-op check-ins, “does this look infected?”, medication questions, triage before a visit is booked. Photos travel as client-encrypted attachments.
• Doctor-to-doctor consults — the eConsult: a GP asking a dermatologist to glance at an image, a specialist second opinion, the informal question that currently happens over a consumer messenger.
• Multidisciplinary team discussion — group rooms for case conversations across a care team.
• Intake from someone who isn’t a patient yet — a public widget where a guest can start a conversation without an account.

Clinicians use web, iOS, or Android against the same backend, so the phone in a doctor’s pocket and the browser at reception are the same system, with one set of rules.

The bots — for admin, not diagnosis

The platform ships a bot framework that plugs into the messenger, and it’s worth understanding what’s appropriate here. A bot can answer questions grounded in your own documents — opening hours, preparation instructions, insurance and billing questions, what to bring — using full-text search over a corpus you supply. Notably, retrieval runs inside your own database: your document corpus isn’t shipped to an external search service.

There’s a hard safety boundary to state out loud. A retrieval bot answering “when should I stop eating before my procedure” is an administrative tool. It is not a diagnostic one, and it must never be presented to a patient as clinical advice. Triage and symptom assessment are regulated clinical activities with real consequences when they go wrong. Use the bot to take load off reception, not off the clinician.

One architectural detail deserves credit. The bot’s search can read your catalogue of services — and the platform’s core registry hard-blocks user records and invoices from ever being searchable, by refusing the registration outright. A bot cannot be misconfigured into searching your patient list or their billing, because there is no code path that would allow it.

The honest limits — read this part

Anyone selling you software for healthcare should tell you where it stops. So:

This is not a compliance product, and no software is. End-to-end encryption and self-hosting are strong technical foundations, but HIPAA, GDPR, or MDR compliance is an organisational achievement, not a feature you install. You’d still need your data protection impact assessment, your processor agreements, your access policies, staff training, and an audit trail. The software is a building block. Your practice remains the data controller and carries the responsibility.

This is not a certified medical device, and nothing here is validated for clinical decision-making.

The messenger must not be your medical record. This one is easy to get wrong and important to get right. Medical record-keeping laws require retaining records for years; this messenger defaults to deleting messages after days, deliberately, for privacy. Those two facts only coexist if you’re clear about roles: the record of truth is your EMR, and anything clinically significant gets documented there. The messenger is the conversation channel, not the chart. Treating a disappearing chat as a clinical record is how practices get into trouble.

Real encryption cuts both ways. If the server can’t read messages, the server also can’t recover them. A clinician who loses their device loses that history. That’s the honest cost of the guarantee, and any vendor offering both perfect confidentiality and full admin recovery is not offering the first one.

Self-hosting is real work. Someone patches the server, takes the backups, and holds the keys to the infrastructure. A practice without IT capability may genuinely be better served by a managed vendor with a signed agreement — and that’s a legitimate answer, not a failure.

Why it’s interesting anyway

The reason this matters isn’t that it’s free — it’s that the trade-off clinics have been living with was always false. The choice was never “consumer messenger or nothing.” It was that the alternatives were priced and packaged for hospital systems, so smaller practices used WhatsApp and hoped.

A source-available framework where the server provably cannot read your patients’ messages, where retention is yours to set, where no administrator can open a consultation, and where the data never leaves your jurisdiction is a different starting point. It doesn’t make you compliant, and it doesn’t do video. But for the everyday traffic of modern care — the photo, the follow-up question, the quick word with a colleague — it is a considerably better foundation than the app your patients also use to send memes.

The messaging plugins are source-available under the platform’s licence and free for commercial use below a defined revenue threshold. Technical details are in the developer documentation and the architecture overview; the source is on GitHub.

General information for practice and technology decision-makers, not legal, regulatory, or medical advice. Compliance obligations vary by country and speciality — consult your data protection officer and legal counsel before deploying any system that handles patient information.

The hard part of selling medicine online isn’t the checkout

If you run a US pharmacy or health-product store, the shopping cart is the easy 10%. The other 90% is proving that the right product went to the right person in a state where you are licensed to sell it, and keeping a record you can defend if a board of pharmacy asks. Generic e-commerce software is built to sell as many units as possible to as many people as possible. That default is exactly wrong for regulated health products.

VBWD is a self-hosted, source-available shop platform (Python/Flask, PostgreSQL, Vue 3, Docker) built as an agnostic core with plugins for shop, product types, discounts, invoicing, and payments. It gives you technical controls that support a compliance program. It does not make you compliant, it is not a certification, and nothing here is legal advice.

The US is a patchwork, and most shop software ignores that

There is no single federal “sell drugs online” licence. Pharmacy practice is licensed state by state through each state’s board of pharmacy, and shipping a prescription into a state generally means holding a licence recognized there. Layered on top:

• OTC products — over-the-counter, sold without a prescription, but some carry their own rules.
• Prescription (Rx) products — require a valid prescription and a licensed pharmacist’s involvement.
• DEA-scheduled controlled substances — a much stricter regime governed by DEA rules on top of everything else. Treat these as a separate, harder problem.
• Age-restricted items — for example, products containing pseudoephedrine follow logging and quantity-tracking patterns.
• FDA oversight of the drug products themselves.
• Health-data privacy — HIPAA applies to covered entities and their business associates. It is the operator’s obligation, not a checkbox in a shop engine.

To operate lawfully you need state-by-state pharmacy licensure, a licensed pharmacist, and real legal counsel. What software can do is model these distinctions instead of flattening every SKU into “a product.” That modelling is where VBWD’s agnostic-core-plus-plugins architecture earns its place.

Product types: model OTC, Rx, restricted, and scheduled differently

VBWD’s shop uses a product-type registry where a type is an additive cluster of custom fields and workflow hooks. You are not forced into one schema for every item. You define an otc type, an rx type, a restricted_otc type, and (if you ever go there) a controlled type, each carrying only the fields and steps it needs.

• rx can require a prescription reference, a prescriber identifier, and a pharmacist-verification state before the order can ship.
• restricted_otc can require date-of-birth capture and quantity limits.
• otc stays lightweight so ordinary vitamins and first-aid supplies don’t inherit friction they don’t need.

Because types are additive, adding a compliance field to Rx products never touches the OTC catalogue. The range of shop building blocks is on the plugins page.

Geo-blocking: only ship where you hold a licence

State-level access control lets you restrict which shipping destinations a product or the whole store will accept. If your licensure covers a defined set of states, you configure those as the allowed set and orders to other states are refused before payment, not after. This is a technical guardrail against the most common failure mode: selling into a state where you have no standing. It enforces your list; it does not tell you which states you are licensed in. That comes from your licences and your counsel.

Age and identity gating

For age-restricted products you can gate purchase behind date-of-birth or identity-verification steps tied to the product type, so the check fires for the SKUs that need it and stays out of the way for the ones that don’t. The gate is a workflow step you place in the order path; the strength of the identity check depends on the verification method and provider you connect.

Prescription upload and pharmacist verification

An Rx workflow is a product type plus order data plus messaging. A customer ordering an rx item uploads or references a prescription, the order lands in a pending pharmacist review state, a licensed pharmacist reviews it, and only an explicit approval moves it toward fulfilment. Secure messaging between the operator and customer handles clarifications without email sprawl. VBWD gives you the state machine and the data model; the licensed pharmacist doing the review is a human role you must staff, not software.

Audit trail: the event bus and signed webhooks

Regulated selling lives or dies on records. VBWD’s event bus emits domain events across the order lifecycle, and outbound webhooks are signed so a downstream system can verify authenticity. You can stream purchase and verification events to an append-only log or a compliance system of record — for example, the logging pattern behind restricted-OTC sales. The signed, event-driven design is described under features. You still define what to log and how long to retain it; the platform gives you a tamper-evident pipe to send it through.

Pricing, tax, payments, and disclosures

Unified pricing supports per-jurisdiction tax, which matters when health-product taxability varies by state. Payments run through swappable provider adapters, so you can choose processors that will underwrite pharmacy-adjacent merchants rather than being locked to one. The CMS lets you publish the disclosures regulators and customers expect — pharmacist name and credentials, licence information, and terms — as first-class content next to the store.

Data residency and access control for health data

VBWD is self-hosted. The database runs on infrastructure you control, which is a precondition for handling protected health information under a program you can actually audit. Granular access control limits who inside your organization can see order and health-related fields. To be blunt: this supports a HIPAA program, it does not constitute one. VBWD is not “HIPAA-certified,” and no vendor can hand you compliance. The safeguards, the business-associate agreements, the training, and the accountability are yours.

A worked configuration sketch

Say you are licensed to ship Rx items to three states and OTC nationwide. A configuration might look like this:

product_types:
  otc:
    fields: [dosage, active_ingredient]
    ship_states: ALL
  restricted_otc:
    fields: [dosage, active_ingredient, dob_required, unit_quantity_cap]
    verification: [age_gate]
    audit_events: [purchase.logged]
  rx:
    fields: [prescription_ref, prescriber_id, pharmacist_review_state]
    workflow: [pending_review -> approved -> fulfil]
    ship_states: [CA, NY, TX]     # only where you hold licensure
    verification: [identity_check]
    audit_events: [rx.uploaded, rx.reviewed, rx.approved, order.shipped]

webhooks:
  - event: rx.reviewed
    url: https://compliance.internal/log
    signed: true
  - event: purchase.logged
    url: https://compliance.internal/restricted-otc
    signed: true

tax:
  strategy: per_jurisdiction
payments:
  adapters: [processor_a, processor_b]

The list of ship states is a hard technical boundary. The signed webhooks turn every review and restricted sale into a record you can retain and reconcile. None of this decides whether your licences actually cover CA, NY, and TX — that is a legal fact you supply. Integration details and adapter contracts are in the documentation.

Honest limits

Be clear-eyed about what a shop engine cannot do:

• It does not grant pharmacy licensure or replace a licensed pharmacist.
• It does not make you HIPAA-, FDA-, DEA-, or board-compliant. It provides controls a compliance program can use.
• Controlled substances are materially harder. DEA rules go well beyond the patterns above; do not treat scheduled drugs as “just another product type.”
• Identity and age verification are only as strong as the provider and method you wire in.
• Geo-blocking enforces the state list you give it; correctness of that list is on you and your counsel.

Takeaway

Compliance-first commerce means the software’s defaults push toward restriction, verification, and record-keeping instead of maximum throughput. VBWD gives you the technical building blocks — product types that separate OTC from Rx from restricted, state-level geo-blocking, verification gates, a pharmacist-review workflow, a signed audit trail, per-jurisdiction tax, swappable payments, and self-hosted data you control. It is source-available under BSL 1.1 (free until 6.7 BTC/year of attributable sales, converting to Apache-2.0), so you can inspect and run the whole stack yourself. Pair those controls with your licences, your pharmacist, and your lawyers. The platform handles the technical guardrails; the licence to operate is still yours to earn and hold. You can review commercial terms on the billing page.

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