Zapx Labs
Home/Products/Thalix
Healthcare InfrastructurePilotBuilt by Zapx Labs
Thalix logo

Thalix

Built like a computer: a fabric that never silently loses a message, a kernel that decides who may see what and audits every answer, and agents that assist without ever deciding. One Rust binary, SQLite inside, runs on anything from a single PC to a hospital's GPU servers.

Thalix runs on synthetic data in every demo and is not a medical device. Clinical deployment needs a clinical safety case, information-governance approval and a security review. Agents never make clinical decisions.

Healthcare Infrastructure

Thalix

Live preview
Thalix live product screenshot

Who it’s for

Hospital digital and integration teams, clinical safety officers, and the clinical, operational and administrative teams across the hospital who end up working with the agents, tasks and boards. Also the platform under Zapx Labs' own clinical products.

Problem

Hospital data lives in HL7 feeds, FHIR servers, PACS, monitors and spreadsheets that do not agree on who the patient is. Every new dashboard or AI assistant rebuilds the same plumbing, department by department, and none of it can say who saw what, or why. Meanwhile much of the work around care, such as chasing results, triaging referrals, reconciling medicines, preparing theatre lists and coding, is still done by hand.

How it works

  1. 1

    Drivers for HL7 v2, FHIR R4, DICOMweb, MQTT, IEEE 11073 SDC, webhooks and files turn every message into a CloudEvents envelope with FHIR content, link the patient identity, drop duplicates, keep the raw message and dead-letter anything unmappable. Senders are acknowledged only after the event is durably logged.

  2. 2

    The kernel projects live objects from the log (patients, encounters, locations and beds, orders, results, vitals, appointments, documents, imaging studies, devices, tasks) and answers every request with identity from hospital SSO, Cedar policy with purpose of use and field-level redaction, typed actions with two-person approvals, and a hash-chained audit. Exposed over REST and MCP.

  3. 3

    Agents on local Ollama, Claude or OpenAI-compatible models act for the signed-in person and propose actions as cards. Workflows are declarative, so any multi-step process between people, teams and agents can be one: the demo hospital runs bed turnaround, result follow-up and discharge, and the same engine fits referral triage, medicines reconciliation or theatre lists. Apps package boards, workflows and agents with computed risk tiers and two-person review. The canvas shows it all on live boards resolved as the viewer.

Key features

  • Drivers for HL7 v2 over MLLP, FHIR R4, DICOMweb, MQTT, webhooks, files, NATS federation and external drivers in any language
  • Replayable event log: acknowledge after commit, de-duplication, dead letters with replay, raw messages kept
  • One patient across systems: every identifier links to one Thalix patient, conflicts raised for review
  • Kernel: OIDC identity, Cedar policy with purpose of use, field-level redaction, break-glass, typed actions with approvals
  • Hash-chained audit of every read, search, stream, action and denial, verifiable from the workspace
  • Agents that act for a person under the model's approved data classes, with cited hospital documents and scoped memory
  • Declarative workflows with tasks, forms, escalation ladders and confirmations that run as the person
  • App store with computed risk tiers, two-person review and a signed, locked certified shelf
  • Canvas boards for any department, with charts, tables, forms and bed maps, built by people or agents and resolved as the viewer
  • Edge, site and central nodes federate over NATS JetStream; offline bundle and installer for air-gapped sites

Inside Thalix

Screens from the current build. Details may change as the product develops.

Built like a computer. Hospital systems at the bottom, the fabric turning them into one replayable stream, the kernel deciding who may see and do what, agents, workflows and apps working through it, and boards on top. Models run on site; hosted ones only by choice, under a data ceiling.
One platform, every department. If work is repetitive, follows rules or is spread across systems, an agent can prepare it, check it or route it, and a person decides. The demo hospital runs bed turnaround, result follow-up and discharge.
How an agent acts. It reads only what its person may see, drafts and proposes, and never decides: a doctor confirms, a tier-3 order needs a second person, and every step lands in the audit. These limits are kernel policies, not prompt instructions.
Workflows — an abnormal result starts a follow-up by itself. An agent drafts the summary, a doctor reviews it with a form, a repeat test needs a consultant's approval, and the nurse gets the plan. Illustration with synthetic data.
Assistant — a nurse asks what is waiting. The agent shows the tools it used, answers from the record with a live board panel and a cited document, and proposes an action she confirms. Illustration with synthetic data.
App store — new boards, workflows and agents arrive as apps with a computed risk tier. A tier-2 app needs an app reviewer and the clinical safety officer; certified apps are signed and locked, and any install can be rolled back. Illustration with synthetic data.
Audit — every read and action, by people, agents and workflows, in a hash-chained log. Pick an entry and the kernel names the rules it applied, such as why a porter saw the bed but not the patient. Illustration with synthetic data.
Runs on your servers. One Docker Compose stack with the models beside it, an offline bundle for air-gapped sites, and nodes linked edge to site to central. A hosted model, if you choose one, sees operational data only.
Thalix appliances, a concept. Hardware shipped with the whole stack installed and set up for the site: a desktop Edge unit for a ward or clinic, a 2U Site server with four GPUs and a DPU, and a 32U Rack with GPU nodes, TPU/NPU-class inference cards, storage and UPS. Specifications are illustrative.
Thalix appliances in place, as concept renders: a Thalix Rack in a hospital server room, a Thalix Edge at a nurses' station, and a Thalix Site server going into a rack. Made with an image model; these are not photographs of shipping hardware.

Thalix project deck

Twelve slides: the problem, the four layers, what the fabric guarantees, the kernel's four questions, the running demo, where the project stands, and a six-week pilot plan.

1 / 12

Use the arrows or the thumbnails. Click a slide to view it full screen.

Download PDF

Example journey

Step 1

Connect the feeds

Point drivers at the PAS, LIS, PACS and bedside devices. Events start flowing into one log within minutes.

Step 2

Sign in as a role

A nurse, a doctor and a porter see the same patients differently. Ask the kernel why, and it names the policy.

Step 3

Let agents and workflows help

Ask the assistant what is waiting for you. Agents prepare, check and route a department's repetitive work, and workflows hand it to the right people as tasks. The demo shows beds, results and discharge.

Step 4

Grow with apps

Package a board and its workflow, have two people review it, install it like an app, and roll it back if it goes wrong.

Get updates

Current status: Pilot

FAQ

Thalix is built by Zapx Labs.