Beyond the dashboard.
How the workflow is implemented.
OnePass is a purpose-built operational workflow application for behavioral health admissions. This brief describes the architecture observed in the current application source—not a speculative feature list or a claim of enterprise certification.
01 / Component architecture
A Flask backend coordinates intake tickets, step-downs, discharges, event history and reporting endpoints. Server-rendered pages and browser JavaScript display workflow states and refresh the board. A relational SQLite database holds task and event records. Conditional Flask-Mail delivery communicates operational exceptions if mail is configured.
HTML/Jinja pages, QR entry, staff-code session, browser refresh
Tickets, elapsed-time rules, state transitions, conditional notification handlers
Ticket tasks, staff codes, timestamps, event trail, beds and discharge workflows
02 / What happens when a task is completed?
The feature is not merely a checkbox. The backend records discrete tasks and the staff user who marked each step. Subsequent board refreshes reflect current state, while an event trail supports reconstruction of the workflow.
A staff member marks a step complete
The browser submits POST /task/<id>/toggle from the task detail view.
Task-level state is persisted
The application stores completion status, completed_by staff code and a server-generated completed_at timestamp.
A related event is logged
The ticket_events table logs the completion/reopen action with event type, staff code and timestamp.
Other views refresh
GET /api/tickets and GET /api/stats supply board data; the existing command center refreshes its tickets about every 10 seconds.
A same-minute cluster of completions can be examined in task history. The system records those timestamps; it does not currently block rapid bulk check-offs or automatically classify them as inaccurate.
03 / Operational logic, not generic form filling
Timed handoff condition
The application measures elapsed time between “Nursing notified” and “Nursing with client.” Visual urgency progresses through configured intervals. Staff may escalate with a reason to Intake Lead or leadership.
Incomplete work remains visible
Tickets can close complete or incomplete, with delay reasons and notes. Both routes can generate operational email summaries; closed-incomplete items remain on the follow-up board.
Dedicated transition model
Discharge workflows cover successful, AFA, behavioral, medical and step-down paths, with confirmation and bed-assignment history and 72/48-hour attention categories.
Conditional communication paths
BHT requests, laundry reminders, escalation emails and completion summaries use predefined templates and configured recipient groups. SMTP delivery is conditional on an available mail service.
04 / Data and interfaces
Existing implementation
- Core data:
intake_tickets,ticket_tasks,ticket_eventsand bed assignment events. - Operational feed: JSON endpoints for tickets, stats, discharges and step-downs.
- Time logic:
America/New_Yorktimestamps and elapsed-minute calculations. - Facility context: an Open-Meteo weather feed in the Command Center greeting.
- Email: Flask-Mail SMTP with role-based recipient groups from environment configuration.
- Optional language generation: AI-written email narrative is feature-flagged; deterministic workflow rules are not model-generated.
Engineering work for wider deployment
- Identity/security: stronger authentication, permissions and testing.
- Reliability: durable background jobs for reminders, monitoring and retry behavior.
- Persistence/scale: production database planning, migrations, backups and observability.
- Clinical rules: configurable per-program deadlines validated against applicable regulatory and organizational requirements.
- Interoperability: scoped integrations with authorized EHR/bed-management systems.
- Analytics: multi-site bottleneck reports, trend comparisons and pilot-based outcome validation.
05 / What an operations pilot would measure
Before scaling a clinical operations platform, a defined pilot can test whether the software improves performance in real workflows—not only whether the screens look good.
Time from arrival to handoff
Baseline and pilot median/percentile completion times, segmented by shift and volume.
Where delays originate
Nursing wait intervals, documentation delays, handoff interruptions, and outstanding tasks.
Staff usability
Update completion rate, notifications acted on, workflow friction and training time.
Did the process improve?
Separate client feedback and retention measures, analyzed appropriately rather than inferred solely from workflow timestamps.