Digital health has a build problem. Every clinic app, patient portal, wellness product, and pharma support tool needs roughly the same skeleton — a secure backend, an AI layer, a web app, iOS and Android, and a way to handle payments and access — and health teams rebuild it from scratch every time, usually while wrestling the hardest constraints in software: privacy, data residency, and compliance. A full-stack framework that ships that skeleton pre-built is worth health innovators’ attention, and VBWD is a notably complete one — with the boundary stated up front: it’s infrastructure, not a medical device, and it doesn’t supply clinical judgement, validation, or regulatory approval.

What “all in the box” means for a health app

VBWD is a constructor for commercial applications, and for health builders the appeal is that “full-stack” is literal:

• A real backend — Python/Flask over PostgreSQL and Redis, with an event system.
• A web frontend — Vue 3, with a patient-facing app and a full admin backoffice.
• iOS and Android — native clients on the same backend, which matters when patients live on their phones.
• An AI layer — a central model-connection manager, retrieval-grounded assistants that answer only from your vetted content, and an agent-callable interface.
• A commercial and access engine — subscriptions, billing, invoicing, access controls, and payments.

The word that matters is one: one backend serving the patient’s phone, the clinician’s browser, and the admin’s dashboard, with one access model deciding who can see what — instead of three subtly different systems and three places for patient data to leak.

The properties health builders actually need

What makes it fit health specifically isn’t a medical feature — it’s the substrate. Because it’s self-hosted and source-available, patient data lives in a database the organisation owns, in a jurisdiction it chooses — the precondition for most health-data compliance, and for patient trust. Its messaging layer is end-to-end-encryptable, with no admin content inspector, so a secure clinician-patient channel is a real option rather than a consumer-app compromise. Its assistants ground answers in your own approved content rather than the open internet. And its search layer is engineered so patient records can’t be surfaced by a misconfigured query. Explore the architecture, the plugins, and the docs to see how these compose.

The same kit across health verticals

Because the core is neutral and each vertical is a plugin, one construction kit builds very different health products: a chronic-disease self-management program with secure check-ins and a vetted-content assistant; a mental-health practice’s encrypted between-session channel with session billing; a pharma patient-support program the sponsor owns end to end; a compliant teledermatology-and-pharmacy storefront; a patient-owned rare-disease registry and community. Different disease areas, different approaches — the same underlying platform, with the domain logic as the part the team actually builds.

The boundary, because it’s health

In healthcare the caveats are the point, not the fine print. A framework can give you a secure, owned, multi-platform foundation for a health application; it cannot give you the clinical validation, the regulatory approval, the compliance program, or the medical judgement that any patient-facing product requires. VBWD provides the infrastructure — the secure backend, the encrypted channel, the grounded assistant, the mobile clients, the billing — and every piece of the actual medicine, and its governance, still has to be built and validated properly on top. It is emphatically not a medical device or a clinical decision system, and no amount of good plumbing changes that.

Why it matters for health innovators

The reason so many good digital-health ideas never ship isn’t a shortage of clinical insight — it’s that building secure, compliant, multi-platform software is expensive and slow, and doing it wrong with patient data is dangerous. A framework that hands you an owned, self-hosted, privacy-respecting, web-plus-mobile foundation — free for commercial use below a defined revenue threshold (see pricing) — lets a health team spend its scarce time on the clinical product and its governance rather than on rebuilding the skeleton. For an industry where the plumbing is unusually hard and the stakes are unusually high, that’s exactly where the leverage is.

General information for healthcare and technology decision-makers, not medical, legal, or regulatory advice. Any patient-facing deployment requires clinical validation, governance, and compliance review appropriate to the jurisdiction. VBWD is infrastructure, not a medical device or clinical system.

There are around 7,000 known rare diseases, and for most of them the single biggest obstacle to a cure isn’t the science — it’s that the patients are scattered, uncounted, and invisible. A condition affecting a few thousand people worldwide has no natural place to gather, no registry, no dataset a researcher can study. The knowledge exists, distributed across isolated families who have never met. The tragedy of rare disease is often a tragedy of fragmentation.

Why registries decide everything

For a rare genetic condition, a patient registry is the foundation everything else is built on. It’s how you learn the natural history of a disease nobody has studied, how you find enough patients to run a trial, how you give a drug company a reason to invest in a treatment for a small population. No registry, no data; no data, no trial; no trial, no therapy. The registry is upstream of hope.

Yet building one is brutally hard for the patient advocacy groups who care most. Commercial registry software is expensive and often means handing the community’s data to a vendor. Academic registries live and die with a grant. And the deepest problem is trust: rare-disease families, who have frequently been failed by institutions, are asked to hand their genetic and medical data to a platform they don’t control, for research they can’t see. Many, understandably, decline — and the fragmentation persists.

A different approach: the community owns the registry

Flip the ownership. Imagine a patient advocacy organisation running its own registry and community on infrastructure it controls. A self-hosted, source-available platform like VBWD makes that structurally possible — with the necessary caveat that it is infrastructure, not research and not medicine: it provides the platform, not the science, the ethics approval, or the clinical validation.

What it does provide fits the need with unusual precision. Self-hosting means the community’s genetic and medical data lives on infrastructure the patient organisation owns — the single most important fact for winning the trust of families who’ve learned to be wary. A secure community and messaging layer lets scattered patients find each other, which for rare disease is itself therapeutic and a recruitment channel. Access controls govern precisely who can see what. And a dataset layer means that when the community chooses to share data with a legitimate researcher, it can do so on its own terms — governed, consented, and revocable — rather than surrendering it wholesale. The plugins and architecture show how the data and community pieces compose; the platform is source-available and free to run below a defined revenue threshold, which matters when the operator is a small advocacy group rather than a funded company.

Patient-owned data as the unlock

The quiet revolution here is consent that patients actually control. In the standard model, a patient signs their data away once and loses sight of it. In a community-owned registry, the organisation and its members hold the data, decide which research to support, and can share a governed dataset with a pharma partner or academic group as a deliberate, revocable act. That reframes the relationship: patients stop being subjects to be harvested and become stewards of an asset that might fund their own cure. For populations repeatedly failed by institutions, ownership is what makes participation feel safe enough to happen at all.

The boundary

Precision matters even in an optimistic piece. A registry platform is not a clinical trial, an ethics committee, or a guarantee of research quality — those require institutional review, informed consent frameworks, data-protection compliance, and scientific rigour that no software supplies. Owning the infrastructure removes the trust and cost barriers to gathering the data; the responsible science still has to be done properly on top of it, and rare-disease data is especially sensitive precisely because small populations are easier to re-identify.

Why it matters

For rare disease, the bottleneck is almost always that the patients can’t be found and their data can’t be pooled — and that’s a fragmentation and trust problem as much as a scientific one. Self-hosted, source-available infrastructure lets the people with the most at stake own the registry, hold the data, find each other, and choose how their information advances research. It won’t discover a therapy. But it can build the trusted, community-owned foundation without which the therapy never gets studied at all — and for 7,000 diseases waiting to be counted, that foundation is the thing standing between invisibility and a chance.

General information for patient organisations, researchers, and technology decision-makers, not medical, legal, or research-governance advice. Patient registries and data sharing require ethics approval, informed consent, and data-protection compliance appropriate to the jurisdiction. VBWD is infrastructure, not a research platform, clinical system, or medical device.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

Teledermatology is one of medicine’s genuine digital success stories — a photo of a rash, a specialist opinion, a prescription, all without a waiting room. But behind the tidy patient experience sits a mess: the consultation runs on one system, the prescription on another, the pharmacy fulfilment on a third, and compliance with pharmacy law is stitched across all of them by hope. Skin conditions are common, chronic, and image-friendly, which makes dermatology the perfect place to see both the promise and the plumbing problem.

The compliance sprawl problem

Selling regulated products — prescription dermatology treatments, restricted-strength topicals, even some cosmeceuticals — is not e-commerce with extra steps. It’s a regulated activity with real obligations that differ by jurisdiction: prescription verification, pharmacist oversight, age and identity checks, record-keeping, and rules about what can be sold to whom and where. In the EU and US these differ enough that “just use a standard online store” quietly becomes non-compliant the moment a real prescription is involved.

So dermatology-and-pharmacy operators end up bolting a subscription plugin here, a compliance module there, a webhook to a pharmacy system, and a separate teledermatology tool on top — a fragile stack where the storefront doesn’t know what the consultation knows, and neither fully owns the patient relationship.

A different approach: one platform, compliance built in

The alternative is a platform where the storefront, the consultation channel, and the compliance rules live in the same system. A self-hosted, source-available platform like VBWD is designed around exactly that kind of composition — with the standing caveat that it is commerce-and-communications infrastructure, not a medical device, and the clinical judgement always belongs to the prescriber.

The pieces line up. A shop engine with configurable product types can model the difference between an over-the-counter moisturiser and a prescription-gated treatment, applying the right checks to each. A secure messaging and image channel carries the teledermatology consultation — a photo of the affected skin, the clinician’s response — on infrastructure the operator controls rather than a consumer app. Access controls and gated products enforce who can buy what. Subscription billing handles the repeat-prescription model that chronic skin conditions naturally fit. And provider-agnostic payments, including regional processors, keep the checkout working across the jurisdictions the compliance rules already differ across. The plugin catalogue and pricing page show how the commerce pieces assemble.

The compliance reality check

Here is the line that matters, because pharmacy is heavily regulated and overclaiming is dangerous. A platform can enforce rules you configure — gate a product behind a prescription, require an identity check, keep the records — but it cannot decide what your legal obligations are, and it is not itself a licensed pharmacy or a compliance guarantee. The prescriber prescribes; the pharmacist oversees; the operator holds the licences and the legal responsibility. Software makes a compliant workflow easier to build and harder to accidentally break. It does not replace the pharmacist, the prescriber, or the regulatory approval — and any dermatology-plus-pharmacy deployment needs proper legal and pharmacy sign-off before it touches a real patient.

Why it matters

The teledermatology experience is good; the infrastructure under it is usually a compliance liability waiting to surface. Consolidating the storefront, the consultation, and the rule-enforcement into one self-hosted platform the operator owns turns a fragile multi-vendor stack into a single system with the patient data and the compliance logic under one roof. For a field as image-driven and prescription-heavy as dermatology, that’s the difference between a demo that impresses and a service that survives an audit. VBWD is free for commercial use below a defined revenue threshold, making owned, compliant infrastructure reachable for the independent pharmacies and clinics that need it most.

General information for pharmacy, dermatology, and technology decision-makers, not medical, legal, pharmaceutical, or regulatory advice. Selling regulated products and delivering telemedicine carry jurisdiction-specific legal obligations; obtain qualified legal and pharmacy review before deployment. VBWD is infrastructure, not a licensed pharmacy or a medical device.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

A patient tells their therapist things they’ve never told anyone. Then, between sessions, they message that therapist about a hard night — and the message travels through a consumer app, sits on a third party’s servers, and is, in a very real sense, no longer private. For every other kind of medical data this is bad. For mental health, where the stigma is the illness’s cruelest feature, it can be catastrophic.

Why privacy is the treatment, not a feature

In depression, anxiety, and every psychiatric condition, confidentiality isn’t an administrative nicety — it’s a precondition for the therapy working at all. People don’t disclose what they fear will leak. A patient who suspects their therapy messages could surface — in a breach, a subpoena, an app’s data-sharing policy — will hold back, and holding back is the opposite of treatment. The privacy is the clinical container.

Yet async messaging between sessions is enormously valuable in mental health. The gap between weekly appointments is long, and a supported check-in during a bad stretch can matter more than the session itself. So clinicians face a bind: the between-session channel patients need runs on infrastructure that undermines the confidentiality the treatment depends on.

A different approach: confidentiality by architecture

The resolution is to make privacy structural rather than promised. This is where a self-hosted platform with genuine end-to-end encryption changes the equation — and, as always in a clinical context, the boundary first: VBWD is infrastructure, not therapy. It is not a treatment, not a diagnostic tool, and not a replacement for a clinician. What it offers is a communication layer whose privacy is enforced by design.

The relevant properties are specific. With its end-to-end encryption layer, the server holds no keys and never decrypts — clients encrypt, and the server only stores and relays sealed envelopes. A practice’s own administrator cannot read a therapy exchange; neither can the host, nor anyone who obtains the database. There is no admin content inspector anywhere in the system — not a permission that’s switched off, but a feature that doesn’t exist, so no one can be pressured into reading what they structurally cannot. Retention is short by default and set by the practice, so sensitive exchanges aren’t hoarded. And it’s self-hosted, so the data lives in a jurisdiction the practice chooses. The developer documentation and architecture pages lay out how the encryption and messaging seams work.

Add subscription billing for session packages and the practice has a sustainable async-care offering that doesn’t compromise the one thing psychiatric care can’t compromise.

The hard limits — read these

Mental health demands the most careful boundaries of any specialty, so several must be explicit. This is text and images, not a crisis service — an encrypted messaging channel is categorically not a suicide hotline or emergency response, and any deployment must route acute risk to real crisis pathways loudly and immediately. It is not an AI therapist; automated responses have no place in delivering psychiatric care, and the value here is secure human-to-human communication, not a bot pretending to counsel. And confidentiality has a legal ceiling — mandatory-reporting and duty-to-warn obligations still apply, and a system must be designed around them, not in denial of them.

Why it matters

Mental health care is being delivered digitally whether the infrastructure is ready or not, and too much of it runs on consumer tools that quietly betray the confidentiality the treatment requires. A self-hosted, end-to-end encrypted platform lets a practice offer between-session support where privacy is guaranteed by mathematics rather than a policy page — with crisis escalation and clinical judgement kept firmly human. In the one field where a privacy breach can undo the treatment itself, building on infrastructure that provably can’t read the conversation isn’t a luxury. It’s the standard of care catching up to the technology.

General information for mental-health and technology decision-makers, not medical, legal, or clinical advice. Digital mental-health tools require clinical governance, crisis-safety design, and compliance review appropriate to the jurisdiction. VBWD is infrastructure, not a therapeutic or diagnostic service.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

When a pharmaceutical company launches an oncology therapy, it doesn’t just ship a drug — it ships a promise to help patients stay on it. These patient support programs handle side-effect reporting, adherence coaching, financial navigation, and the endless questions a frightened cancer patient has. Almost always, the pharma company outsources the whole thing to a third-party vendor. And almost always, that means handing over the most sensitive data imaginable to a company it doesn’t control.

The patient support program problem

Oncology is where patient support programs matter most and cost most. The therapies are complex, the side effects are serious, and adherence is fragile precisely when it’s most important. A good program measurably improves persistence on therapy. But the standard model has a structural flaw: the manufacturer, the specialty pharmacy, and the third-party program vendor each hold a slice of the patient’s data, none of them owns the whole relationship, and the patient’s cancer information flows through systems the sponsor can neither see into nor fully secure.

When a data breach happens — and in this vendor-sprawl model it eventually does — it’s oncology patients’ records that leak, and the sponsor’s name in the headline.

A different approach: own the program

Now imagine the sponsor or specialty pharmacy running the support program on infrastructure it owns. A self-hosted, source-available platform like VBWD is built for exactly this shape of problem — with the essential caveat, stated up front, that it is infrastructure, not medicine: not a diagnostic system, not a clinical decision tool, and not a substitute for the oncology team.

What it does provide is the operational spine of a program. A secure, end-to-end-encryptable channel for patients to report side effects and ask questions, where the conversation lives on the sponsor’s own servers rather than a vendor’s. A grounded assistant that answers logistics and education questions — how to store the medication, what to do about a missed dose, where to find financial assistance — from the program’s own approved content. Access controls that gate who on the care team sees what, with a search layer engineered so patient records can’t be surfaced by a misconfigured query. And data ownership: the program’s data stays in one place the sponsor controls, instead of scattered across three vendors. Explore the architecture and the developer docs to see how the access and messaging layers fit together.

The pharmacovigilance angle

There’s a regulatory bonus hiding here. Oncology programs carry a duty to capture and report adverse events. A secure channel the sponsor owns, feeding a database the sponsor controls, is a cleaner path to reliable adverse-event capture than a fragmented vendor chain where reports can fall between systems. Owning the infrastructure makes the compliance obligation easier to meet, not harder — provided the pharmacovigilance workflow itself is built and validated properly on top of it.

The boundary

The line is non-negotiable in oncology. A program assistant handling logistics, education, and structured side-effect intake is a support tool. Triaging whether a reported symptom is a medical emergency, or advising on dose changes, is clinical work that belongs to the oncology team, full stop. Owning the platform improves security, data control, and adverse-event capture; it does not and must not replace the clinical judgement that oncology demands.

Why it matters

The current model asks pharma companies to run their most sensitive patient relationships on infrastructure they don’t own, then holds them accountable when it leaks. Self-hosted, source-available infrastructure offers the alternative: keep the program, the data, and the patient relationship under one roof you control. VBWD is free for commercial use below a defined revenue threshold, which makes owning the stack a realistic option rather than a nine-figure build. In oncology, where the data is this sensitive and the stakes this high, ownership isn’t a preference — it’s risk management.

General information for pharma and healthcare decision-makers, not medical, legal, or regulatory advice. Patient support and pharmacovigilance systems require rigorous validation, governance, and compliance review. VBWD is infrastructure, not a medical device or clinical decision system.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

The hardest part of managing type 2 diabetes isn’t the medicine. It’s the 8,760 hours a year the patient spends away from the clinic, making small decisions alone — what to eat, whether to take the dose, whether that number on the meter is worth a call. Adherence quietly decides outcomes, and adherence happens in the gaps between appointments, where most healthcare software simply isn’t.

The gap nobody staffs

A person newly diagnosed leaves the consultation with a plan and a pamphlet. Two weeks later they have a question at 9pm that isn’t urgent enough for the emergency line and won’t wait three months for the next appointment. So they Google it, or ask a general chatbot, or guess. Multiply that by every patient and every small decision, and the gap between visits is where good plans quietly fail.

Clinics know this. The answer — structured, between-visit support: check-ins, reminders, a trusted place to ask — is well understood. What’s missing is affordable infrastructure to run it without shipping patients’ diabetes data to a third-party app nobody vetted.

A different approach: the program as software you own

Consider a structured self-management program built on infrastructure the clinic controls. This is where a self-hosted platform like VBWD becomes relevant — and precision matters here, so plainly: VBWD is infrastructure, not medicine. It is not a diagnostic tool and does not replace a clinician. What it provides is the delivery layer for a program a care team designs.

The pieces map neatly onto the need. A secure messaging channel (self-hosted, end-to-end encryptable) lets a patient ask that 9pm question and a nurse answer it the next morning, without the conversation living on a consumer app. A grounded assistant answers routine questions — “should I take my metformin with food?” — from the clinic’s own vetted content, not the open internet, so the guidance is the clinic’s, not a model’s guess. Subscription billing turns the program into a sustainable service line rather than unpaid labour. And because it’s self-hosted, the diabetes data — arguably some of the most sensitive a person has — stays in the clinic’s own database, in its own jurisdiction. You can see how these pieces compose in the plugin catalogue and the architecture overview.

The boundary that keeps it safe

The line has to be bright, because diabetes self-management is exactly where a careless tool does harm. A between-visit assistant answering “here’s what our clinic advises about carbohydrates” and “here’s when to call us” is an education-and-logistics tool, and a genuinely useful one. An assistant deciding whether a specific reading means a specific patient should change insulin is a clinical act, and no amount of good infrastructure turns it into one. Grounding and self-hosting improve privacy and consistency; they do not confer clinical judgement, and the program must be designed so a human always holds the decisions that matter.

Why it changes the economics

The reason clinics don’t already run programs like this isn’t ignorance — it’s cost. Custom patient-engagement software is expensive, and the off-the-shelf options often mean handing patient data and the customer relationship to a vendor. A self-hosted, source-available platform inverts both problems: the clinic owns the software and the data, and stands up the program in weeks rather than commissioning a build. For a chronic condition managed mostly at home, closing the between-visit gap affordably isn’t a nice-to-have — it’s where the outcomes actually live.

General information for healthcare decision-makers, not medical, legal, or regulatory advice. Any patient-facing deployment requires clinical validation, governance, and compliance review appropriate to the jurisdiction. VBWD is infrastructure, not a medical device.

Explore VBWD

VBWD is a self-hosted, source-available platform for building secure, data-owned applications — used here as infrastructure, never as a medical device. Learn more:

• Platform and docs: vbwd.cc — the plugins, the architecture, the developer docs, and pricing.
• Source on GitHub: github.com/VBWD-platform
• See it running: demo video · LinkedIn

Free for commercial use while VBWD-attributable sales stay under the value of 6.7 BTC a year.

A patient with type 2 diabetes asks an AI chatbot how to manage their diet. The answer that comes back might be excellent, or it might be subtly wrong, written at a reading level they can’t follow, and impossible to trace to any source. A new cross-sectional study set out to measure exactly that — the quality, readability, and transparency of AI-generated health information — and the results are a useful warning for any clinic thinking about how its patients get educated online.

The three things that were measured

The study assessed online and AI-generated information about type 2 diabetes on three axes, and each one maps to a real risk:

• Quality — is the information actually correct and complete? Wrong guidance about a chronic condition compounds over years.
• Readability — can a normal person understand it? Health information written above a patient’s reading level is functionally useless, however accurate.
• Transparency — can you tell where it came from and whether it’s trustworthy? An answer with no traceable source can’t be verified, corrected, or defended.

These aren’t academic niceties. For a chronic condition like diabetes — managed largely by the patient, at home, for the rest of their life — the quality of everyday information is a genuine determinant of outcomes. And the study’s framing makes clear that AI-generated material varies on all three, which is precisely the problem: variance, in a domain where consistency is the point.

The transparency gap is the quiet danger

Of the three, transparency is the one most people underestimate. A general AI chatbot produces a fluent, confident paragraph about managing blood sugar — and gives you no way to know whether it’s drawn from a clinical guideline, a decade-old forum post, or a plausible-sounding blend of both. It reads exactly as authoritative when it’s right and when it’s wrong.

For a clinician, that’s the nightmare. You can correct a patient who cites a specific bad website. You cannot correct a patient who says “the AI told me,” because there’s no source to examine, no author to weigh, nothing to point at. The information has authority without accountability. And a chronic-disease patient makes small self-management decisions daily, each one nudged by whatever they read last.

The pattern behind this and the chatbot studies

This sits alongside the broader finding that the public is already pouring health questions into general assistants. The common thread is the same: general-purpose AI produces health information of uncontrolled quality, unknown readability, and no transparency — and patients can’t tell the difference. The tool is fluent enough to be trusted and generic enough to be wrong.

The constructive question for a clinic isn’t whether patients should use AI for health information. They already do. It’s whether the information they get can be made to score well on exactly the three axes this study measured — quality, readability, and transparency — instead of being left to chance.

Where owned infrastructure changes the equation

This is where a self-hosted, content-owned approach becomes relevant — and, in a medical context, precision matters, so let’s be exact. Platforms like VBWD are infrastructure, not medicine: self-hosted, source-available software for running your own content and assistant, not a clinical or diagnostic system. But that infrastructure maps onto the study’s three axes in a way a general chatbot structurally cannot.

Quality becomes controllable. When a clinic owns its patient-education content — in its own content system, reviewed by its own clinicians — and an assistant answers only from that vetted material rather than the open internet, quality stops being a lottery and becomes an editorial responsibility the organisation actually holds.

Readability becomes a choice. You control the source text, so you write it at the reading level your patients need, in the languages they speak. A grounded assistant then draws on material you’ve already made readable, instead of generating prose at whatever level the model defaults to.

Transparency becomes possible. This is the decisive one. When answers come from a defined corpus you maintain, you can say where information came from, keep it current, and stand behind it. “The assistant told me” becomes “our clinic’s vetted guidance says,” with a source a clinician can point to, examine, and correct. Authority regains its accountability.

The boundary, stated plainly

None of this makes software into a clinician, and in a medical context that caveat is not boilerplate — it’s the whole safety case. A grounded assistant serving your own vetted diabetes-education content is a patient-information tool, and a good one. It is not a diagnostic device, it does not replace the consultation, and it must never be positioned as clinical advice for an individual. Owning the content and the infrastructure improves quality, readability, and transparency; it does not turn education into diagnosis, and the study is a reminder of why that line matters.

The takeaway

This research measured what everyone half-knew: AI health information is a mixed bag of uncontrolled quality, uneven readability, and near-zero transparency — and patients can’t tell the good from the bad. A clinic can’t fix the general internet, but it can offer patients something better on its own turf: vetted content it controls, written to be understood, served by an assistant that answers only from sources the clinic can name and stand behind. In a chronic-disease world run largely by patients at home, that’s not a small improvement. It’s the difference between information you can trust and information that merely sounds like it.

General information for healthcare and technology decision-makers, not medical, legal, or regulatory advice. AI patient-information tools are not a substitute for professional care; any clinical deployment requires validation, governance, and compliance review appropriate to the jurisdiction.

In a single month, people had more than 600,000 conversations about their health with one general-purpose AI chatbot. Not with a doctor. Not with a medical service. With Microsoft Copilot — the same assistant they use to draft emails. A new study in Nature Health looked at what those conversations actually contained, and the findings should reshape how clinics think about the AI their patients are already using.

What people are actually asking

The researchers (Costa-Gomes et al., Microsoft AI) analysed 617,827 health-related conversations from January 2026. The breakdown is revealing:

• 40.8% sought general health education — non-personal questions about conditions and treatments.
• Around 20% described personal symptoms, interpreted test results, or managed a condition.
• 14.5% asked about symptoms on behalf of someone else — a child, an elderly parent, a partner. Roughly one in seven health questions is about a dependent.
• Mobile users asked about symptoms more than twice as often as desktop users (15.9% vs 6.9%).
• Evening and nighttime queries carried more emotional-wellbeing concern than morning ones.

Read those numbers as a clinician and a picture forms: a worried parent at 11pm, on a phone, typing a child’s symptoms into a general chatbot because the surgery is closed and the emergency line feels like too much. That’s not misuse. That’s a real human need meeting the only tool that’s awake.

The problem the study names

Here’s the uncomfortable finding. The researchers are blunt that conversational AI “can fail in triage settings,” and that users sometimes do no better at identifying a condition than they would without it. Their key line deserves to be quoted in every hospital IT meeting: “strong benchmark performance does not always translate to real-world reliability.”

A general chatbot can pass medical exams and still give a frightened parent the wrong steer at midnight — because a benchmark is a clean question and a scared person at 11pm is a messy one. The model wasn’t built for triage, isn’t accountable for the answer, and has no idea what your local services, your protocols, or this specific patient’s history actually are.

And there’s a second problem the healthcare sector feels more sharply: those 600,000 conversations, full of symptoms and test results, happened on a general consumer platform. That’s a lot of intimate health information flowing somewhere a clinic doesn’t control and can’t see.

The realistic response isn’t “tell patients to stop”

Patients will not stop. The convenience is overwhelming and the need is genuine, especially out of hours and for the one-in-seven questions asked on behalf of someone who can’t ask themselves. Telling people not to use AI for health is telling the tide not to come in.

The realistic response is to give them a better version of the thing they’re already reaching for — one grounded in vetted content, controlled by clinicians, and running where the data stays put.

Where a self-hosted, grounded assistant fits

This is where infrastructure like VBWD becomes relevant — and it’s worth being precise, because health is exactly the domain where vague claims do harm. VBWD is a self-hosted, source-available platform, not a medical device and not a diagnostic tool. What it provides is the layer underneath a health information service that a clinic or health organisation runs itself.

Three properties of that layer map directly onto the study’s findings:

Grounded, not general. VBWD’s assistant plugins answer from a document corpus you supply — your vetted patient-education material, your prep instructions, your local service information — using retrieval over your own content rather than a model’s open-ended guesswork. The difference between a general chatbot and one that can only answer from clinician-approved material is the difference between “the model’s best guess” and “what your clinic actually says.”

Your data stays yours. Because it’s self-hosted, those conversations happen on infrastructure the organisation controls, in a chosen jurisdiction — not on a consumer platform. The 600,000-conversations-somewhere-else problem becomes conversations on your own system.

Boundaries you enforce. A grounded assistant scoped to administrative and educational content — opening hours, preparation instructions, “here’s what our clinic advises about this,” when to seek care — is a genuinely useful tool. It is emphatically not a triage or diagnostic system, and the study is a strong argument for keeping that line bright.

The line that must not be crossed

Let this be unambiguous, because the Nature Health findings demand it: an AI assistant answering “what does our clinic advise about a fever in a toddler, and when should you go to A&E” is an administrative and educational tool. An AI assistant deciding whether a specific child is sick is a regulated clinical activity, and this study is direct evidence that general chatbots fail at exactly that. Grounding and self-hosting improve safety and privacy; they do not turn an information service into a clinician. No infrastructure does.

The takeaway

Six hundred thousand health conversations a month with a general assistant is not a problem you can ban your way out of. It’s a signal: people want fast, private, always-available health information, and they’ll take it from whatever’s nearest. The constructive move for a clinic isn’t to fight that — it’s to offer a version grounded in its own vetted content, running on its own infrastructure, with the diagnostic line firmly held. Meet the need the study documents, without inheriting the failure mode it warns about.

General information for healthcare and technology decision-makers, not medical, legal, or regulatory advice. AI information tools are not a substitute for professional medical assessment; deployment in any clinical setting requires appropriate validation, governance, and compliance review. Study: Costa-Gomes et al., Nature Health, 2026.

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.

Data is a product — if you can collect it, package it, and charge for it

Plenty of businesses sit on, or near, valuable data — pricing trends, environmental readings, market shares, regional statistics — and never turn it into revenue, because the path from “we could gather this” to “customers pay us for it monthly” is a stack of unglamorous engineering: collection, cleaning, versioning, delivery, access control, and billing. VBWD splits that path into two focused pieces — datavibes for producing datasets and the dataset plugin for selling them — so you can run a data product without building the plumbing from scratch.

datavibes: the data generator

datavibes is a config-driven toolkit whose single job is to produce datasets. It pulls data from public sources, normalises and derives it, and emits a ready-made, versioned dataset — timestamped snapshots you can hand to anything downstream. It is deliberately simple: no web server, no database, no billing inside it. Given a dataset’s configuration and a point in time, it produces the same dataset every time. That determinism is the point — a data product people pay for has to be reproducible, not a one-off scrape that no one can regenerate.

Each dataset is defined declaratively: a small configuration plus, where needed, a tiny adapter for its specific source. You run it two ways from one codebase. As a command you schedule — a cron job (for example, a GitHub Action) runs it on an interval and captures the fresh snapshot — or as a library another Python program imports to drive the same pipeline in-process. The result is a growing series of clean, dated snapshots for each dataset: the raw material of a data business.

Inside VBWD this shows up as a Data Generator admin panel. You manage profiles — each a named dataset with a slug, title, category, row count, and its latest snapshot — and you manage their schedules with cron expressions: enable or disable a profile, see its last run and next fire time, check whether the last run succeeded, or trigger a run on demand. In other words, the collection side becomes an operational surface you watch and control, not a pile of scripts you hope still work.

The dataset plugin: the storefront and the delivery

Producing snapshots is half the business; the other half is selling access to them, and that is what the dataset plugin does. It consumes the files datavibes produces and turns each dataset into something you can monetise. A dataset is modelled as a priceable item: a customer buys it, the purchase grants an entitlement, and the entitlement unlocks API access to the data. The billing, tax, and invoicing all run through VBWD’s unified pricing and subscription engine, so a dataset is sold with the same machinery as any other product on the platform — one-off, or on a recurring subscription for continuously-updated data.

Just as important for actually getting customers: every dataset can carry its own SEO metadata and get its own indexable landing page. Instead of one generic “datasets” page, each dataset has a real URL that describes what it contains and can rank in search — so buyers discover the specific dataset they need. Because VBWD serves crawlable pages for its single-page frontend, those per-dataset pages are visible to search engines, not just to logged-in users.

How the two fit together

The division of labour is clean, and it is what makes the whole thing maintainable:

• datavibes collects and generates — on a schedule, deterministically — and emits versioned snapshots. It knows nothing about money.
• the dataset plugin catalogues those snapshots, gates them behind entitlements, serves them over an API, gives each one a sellable page, and handles the billing.
• the rest of VBWD — accounts, subscriptions, invoices, the agnostic plugin core — carries everything around them.

You can run either half on its own. Use datavibes purely internally to feed your own dashboards, reports, or AI assistants; or use the dataset plugin to sell data you already have. Together, they are a self-hosted “data product” business: collect on a schedule, publish snapshots, sell API access, and let each dataset earn its own search traffic.

Business models this unlocks

The same two pieces support several ways to make money, and you can mix them:

• Subscription data feeds. A dataset that refreshes on a schedule is a natural subscription: customers pay monthly for continuous access to the latest snapshots via the API. Recurring revenue from something a cron job maintains.
• One-off dataset sales. For point-in-time data — a full historical archive, a specific snapshot — sell it once with entitlement-gated download or API access.
• Freemium and samples. Publish a small or delayed snapshot free to rank in search and prove value, and gate the full resolution, full history, or real-time feed behind payment. The free sample is your marketing; the entitlement is your paywall.
• Data-as-an-API. Because access is delivered through an API keyed to an entitlement, your buyers are developers integrating your data into their own products — a higher-value, stickier customer than a one-time download.
• Vertical data products. Curate datasets for a specific audience — environmental and air-quality readings for a wellness or property brand, energy and renewable-share figures for a sustainability consultancy, regional weather or mobility statistics for a logistics tool. A focused, well-maintained vertical dataset beats a generic dump.
• Internal leverage. Even with nothing for sale, feeding clean, versioned data into your own analytics and reporting removes a recurring manual chore and makes your numbers reproducible.

A worked example

Say you want to sell an environmental dataset — air-quality readings by region. You define a datavibes profile that pulls from the public source, normalises it into a consistent schema, and derives the fields you care about. You schedule it to run daily, so each morning a new timestamped snapshot lands. In the dataset plugin you publish that profile as a product: a monthly subscription for API access to the latest data, plus a one-off price for the full historical archive. You give it an SEO page describing exactly what it covers, so a business searching for regional air-quality data finds your page and subscribes. From then on, the cron job maintains the product and the platform handles discovery, entitlement, delivery, and billing. Your ongoing work is curation and quality, not plumbing.

The honest limits

A data business has real responsibilities the software cannot discharge for you. First, rights: datavibes pulls from public sources, but “public” is not the same as “free to redistribute or resell” — you are responsible for confirming you have the right to package and sell any derived dataset, and for respecting each source’s terms and licence. Second, quality and liability: determinism means datavibes reproduces a dataset faithfully, but if the upstream source is wrong or changes shape, your dataset inherits that — you own data quality, documentation, and any accuracy claims you make to customers. Third, operations: this is self-hosted, so you run the schedules, storage, and API, and you own uptime and backups. What the platform gives you is the technical path from collection to paid API; the editorial judgement, the source licences, and the trust you build with buyers are yours.

Takeaway

Turning data into a product usually stalls on engineering no one wants to build. VBWD removes that blocker by separating the job cleanly: datavibes produces versioned datasets on a schedule, deterministically, from simple configuration; the dataset plugin catalogues them, gates them behind entitlements, serves them over an API, and gives each one a sellable, searchable page — all billed through the platform’s subscription engine, all self-hosted, all yours. If your business sits near data worth paying for, the path from “we could collect this” to “customers subscribe to it” is now a configuration and a cron schedule, not a project.

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