Build a Patient Flow Board With ToolJet MCP for bed managers

Introduction

A patient flow board gives hospital bed managers a live view of admissions, ward occupancy, discharges, and delays. A morning printout can quickly become outdated, making it harder to track changes across a busy hospital. In this tutorial, you’ll learn how to build a live patient flow board with ToolJet MCP for a 600-bed teaching hospital. The board brings key patient flow data into one operational view, including admissions, bed occupancy, discharge queues, and delay trends. You’ll also see how an AI agent can generate the ToolJet application, including the data, queries, and interface. By the end, you’ll have a practical operations board for monitoring patient flow and supporting day-to-day bed management.

The live overview: headline tiles, admissions and discharges by hour, the 8-hour occupancy projection with both scenarios, wards ranked by risk, and waits by department with the assumptions panel.

The discharge queue grouped by delay reason, ranked by hours waited, with one owner and target per group and the patients behind each group below.

Weekly trends: delay hours by reason over eight weeks, which bottleneck is growing, and weekly admissions, discharges and occupancy.

Assigning a delay group to an owner with a target time, with the group's patient count, hours waited and usual team shown first.

How to manage hospital patient flow

Track patient flow by combining admissions, discharges, ward occupancy, queue reasons, and delay trends in one live board for the bed office. A coding agent can build that as a working app with ToolJet MCP instead of a manual handoff, inside ToolJet.

1. Gather the live ward census and movement feed
2. Group discharge reasons across the queue
3. Calculate occupancy, waits, and the eight-hour projection
4. Rank the queue by total delay hours
5. Review weekly delay trends and adjust priorities

What the live flow board shows

The live page opens on a compact wall display with ward tiles, hourly flow, a projection panel, and department waits in the same view. The screen keeps the same dense hierarchy across all three pages, so the operator never has to hunt for the next decision. A manager scans for wards at capacity, checks the two occupancy scenarios, and uses the risk flags to find the wards under the most pressure. The discharge queue page groups medically ready patients by reason, then lets a manager open one group to see patient counts, longest wait, owner, target, and note entry. The weekly trends page shifts the focus to reason-level delay hours, so the executive team can read the current bottleneck against the recent average.

• Hourly admissions and discharges on the live overview
• Ward occupancy against capacity with an eight-hour projection
• Discharge queue grouped by delay reason with owner assignment
• Weekly delay trends by reason with recent average comparison
• Role-based writes for bed managers and department heads

Build a Patient Flow Board With ToolJet MCP From the Prompt

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

How one prompt defines the board

The real build took several passes before the structure settled and the screen shape became clear. The requirements are consolidated into one prompt here, so you can reproduce the same patient flow board in a single shot without reworking the specification.

Build a live patient flow board called Patient Flow Board in ToolJet for the bed management office of a 600-bed teaching hospital in Manchester.

Keep it to 3 pages: Live overview, showing admissions and discharges by hour, ward occupancy against capacity, an eight-hour occupancy projection, and waiting times by department; Discharge queue, showing medically ready patients grouped by delay reason, hours waited, owner, target time, note, and the current write controls; Weekly trends, showing delay hours by reason over the last 8 weeks, the current week marked incomplete, and weekly admissions, discharges, and occupancy.

Use only ToolJet native components.

Use PostgreSQL for the operational feed, with wards and capacity, current census, patient movements, expected admissions, department waits, discharge queue, delay history, daily occupancy, and the seed date. Use ToolJet DB for the team-edited records, per-patient delay reason, owner and note, one active owner and target time per delay reason group, and an audit log of every change.

Model discharge delay by reason rather than by ward. Seed synthetic data only, with pseudonymous patient references and no names.

Bed managers can assign groups and update patients, department heads can update patients, and executives are read-only. Enforce writes in the queries. Refresh automatically every 5 minutes. The board is purely operational and must not give clinical advice about individual patients.

How ToolJet MCP assembles the app

ToolJet MCP works through the whole application, from the data model and queries to the pages, components and wiring, and creates a structured ToolJet application inside ToolJet rather than handing back a codebase for you to assemble yourself or export into another build flow. The result sits on a runtime that can carry data connectivity, workflows, permissions, deployment and ongoing change where supported, while still letting you move from AI generation to visual editing and code where a case needs it, all in the same builder. If you want the build pattern, start with the ToolJet MCP documentation for a closer guide.

What caused the repeated admissions bug

The first weekly check showed the same admissions total every day, so the trend chart looked flat and wrong. The cause was a random filter that PostgreSQL evaluated once per ward instead of once per generated day. Reworking the seed logic fixed the pattern.

What tables power the operational feed

The app ended up with thirteen tables in three groups. The live feed uses pf_wards, pf_ward_census, pf_patient_movements, pf_expected_admissions, pf_dept_waits, pf_discharge_queue, pf_delay_history, pf_occupancy_daily, and pf_meta, the team edits live in pf_delay_assign and pf_group_assign, and pf_reasons keeps the delay categories stable. That separation keeps the queue, the weekly trends, and the editable notes tied to one operational model, and it keeps the synthetic feed distinct from the changes the team makes during the shift.

Page	Components	What they cover
Live overview	13
Discharge queue	29
Weekly trends	10

What Got Generated

Metric	Result
Pages	3
ToolJet DB + PostgreSQL tables	13
Queries	26
Components	52
Code files to maintain	0
Repair cycles	2

The components ToolJet MCP created, in the ToolJet inspector

Who uses it in hospital operations

Hospitals and NHS trusts are the obvious fit: bed management, patient flow and discharge teams that need a live view instead of a morning printout. The same pattern works anywhere a queue of ready-to-move items is held up by different external teams and the question is who has to act: step-down and community care providers, hospices, mental health services, and outside healthcare, logistics hubs waiting on customs or carriers, or service desks where tickets wait on other departments.

Who can view and edit the board

As built, access comes from three ToolJet workspace groups. Patient Flow - Bed Managers can assign a delay reason group to an owner with a target time and update any patient's reason, owner and note. Patient Flow - Department Heads can update patients but cannot assign groups. Patient Flow - Executives can open every page but change nothing. ToolJet query permissions enforce this on the write queries, and the Assign and Update buttons are disabled for anyone outside the allowed groups. Workspace admins can also edit. The groups were created without members, so the team adds its own people.

Audit Logs and OpenTelemetry Observability in ToolJet

A Patient Flow Board app that changes real records needs a trail of who did what, and ToolJet provides audit logs for user activity plus OpenTelemetry metrics for platform health. Security teams get evidence for reviews, and platform teams watch performance in the monitoring tools they already run.

When bed managers change a delay reason or owner, the audit trail shows who did it and when. Query metrics and logs help the team see how those writes and reads behave.

Audit Logs and OpenTelemetry Observability in ToolJet

Audit Logs: Who Did What, When and Where

• ToolJet audit logs: record who performed each action, what it was, when and where it happened, including IP address, across user, app and data query events. Filter by user, app or resource over a date range of up to 30 days.
• Retention control: logs are kept for 90 days by default, and admins can change the period with the AUDIT_LOGS_RETENTION_PERIOD environment variable or keep logs indefinitely.
• Audit log files with rsyslog: write audit logs to daily rotated log files on the server.
• Streaming audit logs to Datadog: ship those files through a Datadog Agent for centralised search, security monitoring and long-term retention.

OpenTelemetry Metrics for Apps and the Platform

• OpenTelemetry observability: export app metrics such as query executions, duration, failures and success rates, labelled by app, query and environment, alongside HTTP, database and Node.js runtime metrics.
• Any OTEL-compatible tool: send traces and metrics to Datadog through a Datadog Agent, New Relic, Grafana or another OpenTelemetry backend.

Together, audit logs and metrics show both who changed the Patient Flow Board app's data and how its queries perform in production. Audit logs are included from the Team plan, and the ToolJet pricing page lists unlimited audit log retention on Enterprise.

Enterprise Features for Your Patient Flow Board

This board handles patient references, delay reasons, and handover notes. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

• SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
• Role-based access control: scope permissions to the app, the data source, and each query
• Audit logs: track every login, edit, and approval decision for compliance review
• Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
• Multiplayer editing: several builders work on the same app, with versioning and Git sync
• ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a group owner is assigned, post a Slack message to the ward team, email the department head through Gmail, and write the decision back to pf_group_assign.

Final Takeaways

This article shows a patient flow board that turns a stale morning printout into a live operational view for the bed office. You get hourly admissions and discharges, ward occupancy against capacity, an eight-hour projection, a grouped discharge queue, and weekly delay trends, all backed by editable data and role-based write paths. The build also shows how an agent-generated ToolJet application stays editable after the initial generation, so the team can keep working in the same structured app as ward pressure changes. For a hospital operations team, that is the point of build a patient flow board with ToolJet MCP.

Try ToolJet MCP

Build your own patient flow board with ToolJet MCP for ward operations, then request a ToolJet demo to map it to your hospital data.

FAQs

What is ToolJet MCP for patient flow?

ToolJet MCP lets a coding agent turn patient flow requirements into a ToolJet application. The result is a structured board with pages, data, and edits that stay connected in one place, ready for the bed team to keep using.

What does the Patient Flow Board show?

It shows hourly admissions and discharges, ward occupancy against capacity, an eight-hour projection, department waits, a reason-grouped discharge queue, and weekly delay trends. The display stays operational, not clinical, so the bed team reads flow instead of advice.

How do you reproduce the Patient Flow Board?

Start with the prompt and the same operational tables. ToolJet MCP turns that specification into the pages, data links, and write rules in one build, so the team sees the same structure each time.

Can the Patient Flow Board use PostgreSQL and ToolJet DB?

Yes. PostgreSQL can hold the live operational feed, while ToolJet DB can hold the edits, owners, target times, and audit rows the team changes during the day. That split keeps reads and writes separate.

Do you need code to build the Patient Flow Board?

No. The main pages, data wiring, and write rules can come from the prompt, and code is only for a specific transform or interaction when you need it.

What happens after ToolJet MCP finishes?

The result is a structured ToolJet application, not a throwaway screen. The runtime carries data connections, workflows, permissions, deployment, and ongoing change where supported, so the team keeps working in the same app.

Can several people work on the Patient Flow Board at once?

Yes. Bed managers, department heads, and executives can share the same app with role-based writes, so each group sees the same live picture while only allowed roles change data. That keeps the picture consistent across the team.