Department Command Center Tabs

Why

The Department Command Center is a per-department operational dashboard. Different departments (ward, clinic, OR, nursing home, blood bank) need different views, but everyone needs a sensible default. Hard-coding one layout for everyone is wrong; making every department configure tabs from scratch is also wrong.

The starter kit solves this: a fixed baseline of three tabs that every department always gets, plus a menu of optional add-on tabs each department can opt into via the department management form.

The baseline trio

These three tabs are rendered for every department, regardless of configuration. They cannot be removed from the admin form.

Tab	ID	Purpose
Timeline	timeline	Chronological patient-flow view for the day
Main	main	The bento dashboard (queue + floor plan + pipeline + team)
Order System	orders	Open orders by type (lab / imaging / pharmacy)

Why these three: Timeline answers “what’s happening right now and in what order?”, Main answers “what’s the overall state of the department?”, and Order System answers “what work is outstanding?”. Together they cover the three operational questions a charge nurse or department head asks every hour.

Opt-in tabs

Admins pick additional tabs per department via the “Command Center tabs” section in the department form. Current options:

Tab	ID	Good fit for
Labs	labs	Clinical labs, pathology
Team	team	Large nursing units, shift-coverage heavy departments
Analytics	analytics	Admin-facing departments that want historical drill-down
Wellness	wellness	Nursing homes, long-stay wards

Add new optional tabs by:

1. Adding the ID to CommandCenterTabId union
2. Adding the definition (with baseline: false) to COMMAND_CENTER_TABS
3. (Optional) Building a dedicated tab component; otherwise the fallback “configured, not yet wired” card renders automatically.

Where the code lives

Path	Purpose
web/src/pages/admin/department-command-center-tabs/tabsRegistry.ts	Tab definitions, baseline list, resolveDepartmentTabs()
web/src/pages/admin/department-command-center-tabs/CommandCenterTabBar.tsx	The tab strip UI
web/src/pages/admin/department-command-center-tabs/TimelineTab.tsx	Timeline baseline tab content
web/src/pages/admin/department-command-center-tabs/OrderSystemTab.tsx	Order System baseline tab content (placeholder)
web/src/pages/admin/department-command-center.tsx	Hosts the tab bar; Main tab content is inline
web/src/pages/admin/department-management.tsx	Dialog form for picking opt-in tabs
web/src/services/ever-administration/department.service.ts	TDepartmentPayload.starterTabs field

Data model

The department record on MongoDB gains one new optional field:

starterTabs?: CommandCenterTabId[]

This stores only the opt-in tabs. Baseline tabs are resolved in the frontend registry and never written to the database — that keeps the baseline definition in one place and prevents drift.

Resolver contract — resolveDepartmentTabs(starterTabs):

1. Always returns the 3 baseline tabs first, in fixed order.
2. Appends opt-in tabs in the order the admin picked them.
3. Dedupes, filters unknown IDs, and filters opt-ins that collide with baseline.

Backend follow-up (not yet done)

The frontend sends starterTabs on create/update. The backend (services/administration) currently does not have this field declared on its Department entity. Two options:

1. Accept but ignore (current behavior): values are dropped silently.
2. Persist: add starterTabs: string[] to the Department Mongoose schema and to the Joi/class-validator DTO. No migration needed since it’s optional.

Option 2 is the intended end state. Until it lands, opt-in tabs will reset on page refresh.

Why the Main tab doesn’t have its own file

The bento grid dashboard that makes up the Main tab is substantial (queue card, floor plan card, pipeline card, staff leaderboard, overview card) and lives in department-command-center.tsx itself. Rather than extract it into a dedicated MainTab.tsx, the page renders it inline behind an activeTab === 'main' guard.

This keeps the refactor low-risk: no code was moved, only wrapped. Future iterations can extract if Main grows further.

How to use this doc

If you are adding a new optional tab — follow the “Add new optional tabs by” list above. Ship it without touching the baseline.

If you are wiring Order System to real data — OrderSystemTab.tsx is the seam. Replace the zero-count buckets with real queries against the diagnostics and medication services, matching on departmentId.

If you want to change the baseline trio — don’t. It’s baseline because every department depends on it. If you truly need to, update BASELINE_TAB_IDS AND coordinate a rollout plan with every department admin, because you are changing the default experience globally.

If the backend doesn’t persist starterTabs yet — see the “Backend follow-up” section above. The frontend is ready; the MongoDB field is the last mile.