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.

Selling paracetamol online looks, on the surface, like selling anything else: a product page, a cart, a payment button. Then a regulator asks where your prescription verification happens, which member states you ship to, whether your OTC and prescription-only lines are actually distinguishable in the database, and where health-related purchase data physically lives. At that point most general-purpose e-commerce stacks run out of answers.

This article is honest about one thing up front: no software makes a pharmacy compliant. Operating a legally-registered online pharmacy in the EU requires the appropriate national registration and licences, a responsible registered pharmacist, and legal review under your member state’s rules. What a shop engine can do is give you technical building blocks that map cleanly onto those obligations, so the compliance work is a configuration and process exercise rather than a fight with the software. VBWD’s shop engine is built to be that kind of foundation, not a certificate.

Why generic e-commerce fails for pharmacy

Off-the-shelf shop platforms model a “product” as a single flat shape: title, price, image, stock. Pharmacy products are not one shape. An OTC analgesic, a prescription-only antibiotic, and an age-restricted product each carry different mandatory attributes and different rules for who may buy them and from where.

Generic platforms also assume you want to sell to everyone who can reach the URL. Pharmacy is the opposite: EU rules for online medicine sales are national, set per country, so your default posture must be to restrict and then selectively permit. Bolting country logic onto a platform that assumes global reach tends to leave gaps.

Finally, most stacks treat order data as commercial data. A prescription upload, or the fact that someone bought a specific medicine, is health-related data under GDPR and deserves stricter handling than a T-shirt order. The architecture has to respect that from the start.

The building blocks, mapped to EU requirements

VBWD is a self-hosted, source-available platform: Python/Flask, PostgreSQL, Vue 3, Docker, with an agnostic core and everything domain-specific implemented as plugins. Shop, product types, discounts, invoicing, and payments are all plugins on that platform. Below, each capability is paired with the pharmacy obligation it supports.

Product types for OTC, prescription, and restricted lines

The shop engine models a product type as an additive cluster of custom fields registered through a product-type registry. Rather than forcing every product into one schema, you define a type per category and attach only the fields that category needs.

• OTC: standard commercial fields plus active ingredient and pack size.
• Prescription-only: the same, plus a prescription-required flag and fields for the verification workflow.
• Restricted: additional eligibility or age-gating attributes.

This gives you a database-level, queryable distinction between prescription and OTC products — the clear separation regulators expect — instead of a convention that lives only in a category name. You can read more about how the platform composes these clusters in the architecture overview.

Country access control for national rules

Because online-medicine rules differ by member state, jurisdiction control is a first-class need. The platform’s CMS supports country-based access, so you can restrict which markets see and reach given pages and product areas. Combined with a deny-by-default posture, this lets you serve only the countries where you hold the correct registration, rather than exposing your full catalogue to the entire EU and hoping.

Catalogue with a shared filter and pagination contract

The shop catalogue uses a shared filter and pagination contract, so browsing, filtering, and paging behave consistently across product types. In practice this means a customer can filter to only OTC products, or a pharmacist-facing view can filter to prescription lines awaiting verification, using the same predictable mechanism. The consistency matters when you later attach audit and reporting on top of it.

Age and eligibility gating

For age-restricted and eligibility-restricted products, the extra fields on a product type feed gating patterns at the point of sale. The gate is expressed as product data plus order-time checks, which keeps the rule attached to the product rather than hard-coded into a single checkout screen. You still design the exact eligibility policy — the engine gives you the place to attach it.

A prescription-handling workflow

Prescription handling is where the pieces combine. There is no single “prescription” button; instead you compose one from parts you already have:

• A product type flags the line as prescription-required.
• Order data carries the prescription’s state through fulfilment.
• Secure messaging handles uploading a prescription and the pharmacist’s verification exchange, keeping that sensitive material off email.

The registered pharmacist remains the decision-maker. The software’s job is to make sure a prescription-required item cannot progress to fulfilment without the verification step being recorded — a control you configure, not a legal guarantee the platform issues.

An audit trail via the event bus and signed webhooks

Verifiable records are central to pharmacy operations. VBWD’s core emits domain events on an event bus, and you can subscribe outbound signed webhooks to relay those events to an external audit log or an existing pharmacy management system. Because the webhooks are signed, the receiving system can verify authenticity. This gives you an append-only trail of who did what and when, feeding a system of record you control. See the features overview for the event and webhook surface.

Pricing, VAT, and invoicing

Medicines frequently sit under specific or reduced VAT rates that vary by country. The unified price model carries per-line tax so VAT is computed and shown per line item rather than as an opaque total, and the invoicing plugin produces the corresponding documents. That per-line transparency is what makes cross-border VAT handling auditable later.

Self-hosted, EU data residency, and GDPR

Because a purchase of a specific medicine — and any uploaded prescription — is health-related personal data, where that data lives is not a detail. VBWD is self-hosted, so you choose the hosting, including keeping data resident in the EU. There is no obligatory third-party SaaS in the transaction path holding your patients’ health data. This supports GDPR obligations around health data; it does not discharge them. You still need your lawful basis, your retention policy, your data-processing records, and your DPO arrangements where required.

Swappable payment providers

Payments are implemented as swappable adapters, so you can select providers that fit your market and your acquirer relationships rather than being locked to one processor. Details of the payment and billing surface are in the billing documentation.

CMS for mandatory legal pages and the common logo

Legally-operating online pharmacies in the EU must display mandatory information — including registered pharmacist and operator details — and link back from the EU common logo for online medicine sellers to the relevant national register entry. The platform’s CMS is where you author and maintain those legal pages and place the common-logo linkback, keeping the required disclosures under version control alongside the shop.

A worked configuration example

Suppose you are registered to sell OTC medicines in Germany and Austria only, with a prescription workflow for a limited prescription-only range. A rough shape of the configuration looks like this:

product-types:
  otc:
    fields: [active_ingredient, pack_size, vat_rate]
  prescription:
    fields: [active_ingredient, pack_size, vat_rate,
             prescription_required: true,
             prescription_status]      # unverified | verified | rejected
  age_restricted:
    fields: [active_ingredient, pack_size, vat_rate,
             min_age]

country-access:
  default: deny
  allow: [DE, AT]

workflow:
  prescription_required:
    block_fulfilment_until: prescription_status == verified
    channel: secure_messaging          # upload + pharmacist review

audit:
  webhook:
    events: [order.created, prescription.verified,
             prescription.rejected, order.fulfilled]
    signed: true
    target: https://your-pharmacy-system.internal/audit

data:
  hosting: self_hosted
  residency: eu

This is illustrative, not a drop-in file: the exact field names, event names, and options follow the plugin configuration documented in the platform docs. The point is that each obligation — jurisdiction, product distinction, prescription control, audit, residency — has an explicit, reviewable home.

Honest limits

Read this part twice. VBWD is not certified, approved, or endorsed by any medicines regulator, and running your shop on it does not make your pharmacy legal. It gives you technical building blocks; it does not give you a licence.

• You must hold the appropriate national registration and licences for every country you sell into. These rules are national and differ per member state.
• You need a responsible registered pharmacist accountable for dispensing decisions.
• You must obtain independent legal and regulatory review before going live, and keep it current as rules change.
• The platform does not implement Falsified Medicines Directive serialization or verification against national medicines verification systems. Where the FMD context applies to your operation, that is a separate obligation you address with the appropriate systems.
• GDPR compliance for health data is a programme — lawful basis, retention, records, DPO — not a switch the software flips.

None of these are gaps in the software; they are the parts of pharmacy operation that are legal and human by design, and no shop engine should pretend otherwise.

Takeaway

A compliance-ready pharmacy shop is one where every regulatory obligation has a clear technical home: prescription and OTC products are distinct in the data, sales are geo-restricted to the countries you are registered in, prescription verification is a recorded control, health data stays on infrastructure you govern in the EU, and every significant action leaves a signed, auditable trace. VBWD’s shop engine gives you those homes on a self-hosted, source-available platform you can inspect and extend. The licences, the pharmacist, and the legal sign-off remain yours to hold — which is exactly as it should be.

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