TECHNICAL OVERVIEW - Queue & Ticketing System
Queue & Ticketing System – Technical Specification
This document outlines the technical architecture, functional modules, integration endpoints, and deployment requirements for the Minerva Data Queue & Ticketing System.
System Architecture
The system follows a modular, service‑oriented design with RESTful APIs, real‑time WebSocket notifications, and pluggable hardware drivers.
Essential Functional Modules
Core capabilities delivering operational efficiency, mandatory for deployment.
State machine governing patient journey: CHECKED_IN → IN_QUEUE → IN_SERVICE → COMPLETED. Supports multiple concurrent service lines (triage, general, specialist). Real‑time queue updates are pushed via WebSocket to all connected clients and public displays.
API Endpoints: POST /api/v1/queue/assign, GET /api/v1/queue/status/{serviceId}, WS /ws/queue/live.
State transition diagram for patient flow.
Tracks each physical room/bay as a resource with status: AVAILABLE, OCCUPIED, RESERVED, MAINTENANCE. Intelligent assignment engine matches patient needs (procedure type, equipment) with room capabilities.
Data Model: Room { id, type, equipment, currentStatus, lastOccupied }. Endpoint: POST /api/v1/rooms/assign.
OLAP cubes store aggregated metrics: average wait time, service duration, throughput per hour, peak periods. Pre‑built dashboards (Grafana compatible) and exportable CSV/PDF reports. Data retention policy configurable (default 24 months).
Key Metrics API: GET /api/v1/analytics/wait‑times?from=...&to=....
On‑demand analytics and reporting.
Rule engine evaluates urgency based on configurable clinical flags (e.g., PAIN_LEVEL > 7). Priority inversion prevention via aged ticket escalation. Workload distribution uses round‑robin with capacity awareness; each staff member has a max concurrent patient limit.
Configuration: JSON rule definitions loaded at runtime.
Printers: ESC/POS thermal printer integration via USB/network. Ticket template: variable fields (ticket number, service point, timestamp). Driver uses ipp:// or raw socket. API: POST /api/v1/hardware/print.
Displays: Large screen driven by a dedicated React web view that subscribes to /ws/queue/display. Content: ticket number, service point, animated background. Supports HDMI/DisplayPort.
Audio Paging: Text‑to‑speech (TTS) engine; calls /api/v1/hardware/announce with ticket number and service point. Plays through system default audio device or network speaker (Sonos/Dante optional).
Printer output / display content.
Audio announcement waveform placeholder.
Patient‑Centred Modules (Optional)
Non‑essential but recommended features focused on user experience and comfort.
- Physical Comfort & Perceived Fairness
Patients remain seated; system tracks logical queue position independently of physical location. AI‑based ticket number recycling uses a cryptographically secure pseudo‑random sequence to mask actual queue order, enhancing perceived fairness. - Anxiety Reduction
Client‑side animation library (CSS/WebGL) shows estimated progress bar; configurable easing curves reflect real‑time throughput. - Age‑Adaptive UI
When patient age is known (via EHR integration), the display view adjusts font size, contrast, and visual complexity. Alternatively, kiosk login mode selects child/adult/elder interface profile. - Step‑Away Procedure
Patients can request a temporary pause (POST /api/v1/queue/pause). System retains position and notifies via SMS (Twilio integration) or on‑screen alert when reactivated.
Illustration of adaptive UI and progress feedback.
Integration, APIs & Deployment
How the system connects with existing Minerva Data modules and external services.
HL7 v2 messages (ADT^A04, SIU^S12) for patient demographics and appointments. FHIR R4 API (Patient, Appointment, Encounter) for bidirectional sync. Queue ticket creation automatically fetches patient details from the HIS, ensuring consistency.
GET /fhir/Patient/123Authorization: Bearer {token} Sample FHIR request for patient lookup.
• Server: Linux (Ubuntu 20.04+), Docker/Kubernetes, Node.js 18 LTS, PostgreSQL 14+. • Printers: Epson TM‑T88 series (or compatible ESC/POS) connected via Ethernet/USB. • Displays: Any HDMI/DP screen running a modern web browser (Chromium in kiosk mode). • Network: All hardware must be on the same VLAN as the API server; WebSocket connections require WSS if SSL‑terminated. • Audio: 3.5mm jack speakers or IP‑based (Sonos/Dante) driven by TTS engine.
Network topology sketch.
Deployment & Commissioning Checklist
Ensure the following prerequisites are met before integration team on‑boarding.
- Docker host or Kubernetes cluster with at least 4 vCPU, 8GB RAM.
- PostgreSQL database instance accessible from application pod.
- Printer IP addresses and display screen browsers configured in kiosk mode.
- SSL certificate for the domain (for WSS and secure API calls).
- LDAP/SAML integration for staff authentication (optional).
- Twilio account SID and token for SMS notifications (step‑away feature).