Healthcare TV Fleet Management — Real-Time Monitoring Platform

The context: Hospital patient room TVs are more than entertainment devices—they're touchpoints for patient education, care team communication, and service requests. Managing hundreds of these devices across multiple facilities requires visibility into device health, firmware status, user interactions, and integration state. The challenge was building a monitoring platform that could deliver real-time telemetry at scale without becoming a maintenance burden or security liability.

What started as a diagnostic tool evolved into a comprehensive fleet management platform: 44,000+ lines of C# running on .NET 8, a REST API with 700+ endpoints spanning 42 controllers, real-time WebSocket streams, and integration points for enterprise monitoring systems. The platform now handles continuous telemetry from hundreds of LG commercial displays across healthcare facilities.

Chapter 1: Understanding the problem space

Hospital TV deployments have unique operational requirements. Devices operate in patient rooms where reliability directly affects care experience. Firmware updates must happen without disrupting patients. Staff need visibility into room status and device health. And everything must operate within the constraints of hospital network security policies and HIPAA compliance requirements.

The existing approach was reactive: wait for complaints, manually inspect devices, and hope that firmware updates completed successfully. There was no centralized visibility, no automated diagnostics, and no integration with the hospital's operational monitoring infrastructure. Every troubleshooting session started from scratch.

The goal became clear: build a platform that could provide continuous, real-time visibility into every device in the fleet—power state, firmware version, configuration drift, integration health, and user activity patterns—while maintaining the security posture required for healthcare environments.

Chapter 2: Architecture and data ingestion at scale

The platform's architecture centers on a multi-protocol ingestion layer that captures telemetry from TV devices through several channels. Each LG commercial display exposes diagnostic information through manufacturer-specific interfaces, and the platform connects to these through persistent TCP sessions, browser debugging protocols, and proprietary management APIs.

The ingestion pipeline follows a batched processing model: raw telemetry flows through a central log processor that aggregates entries (50 per batch, 1-second flush interval), parses device-specific event formats, and routes data to specialized tracking services. This approach keeps per-event overhead low while maintaining near-real-time visibility.

For device identity, the platform uses a composite identifier derived from hardware attributes (MAC address, serial number, model) that remains stable across IP changes. When a device moves to a new IP via DHCP, the platform migrates its tracking state automatically—no manual re-registration required. This was critical for hospital networks where IP assignments can shift during maintenance windows.

The API layer exposes this telemetry through both REST endpoints (for polling and integration) and WebSocket streams (for real-time dashboards). Live log streams use bounded per-client send queues with backpressure handling, so a slow dashboard client doesn't stall the broadcast to others.

Chapter 3: Security as a foundation, not an afterthought

Operating in a healthcare environment meant security couldn't be bolted on later. The authentication system implements JWT tokens with short-lived access tokens (15 minutes) and longer-lived refresh tokens (7 days) stored in httpOnly cookies. Token rotation happens automatically—each refresh invalidates the previous token and issues a new one, limiting the window for token theft.

Password storage uses PBKDF2 with 600,000 iterations, following OWASP 2023 recommendations. The platform supports multi-factor authentication via TOTP for admin accounts, with configurable enforcement policies per user role.

Session management implements secure defaults: 8-hour timeouts, session rotation on authentication state changes, and secure cookie flags (httpOnly, sameSite=Strict, secure flag auto-enabled for HTTPS). Brute-force protection locks accounts after failed attempts with configurable backoff periods.

For cross-origin security, the platform implements environment-specific CORS policies. Development mode restricts origins to localhost; production mode requires explicit allowlisting of hospital dashboard URLs. This prevents cross-origin attacks while allowing legitimate dashboard deployments.

API key management provides an alternative authentication path for service integrations. Keys can be generated with scoped permissions, revoked individually, and tracked for usage patterns. This enables secure machine-to-machine communication for monitoring system integration without exposing user credentials.

Chapter 4: Database optimization for continuous telemetry

Continuous telemetry from hundreds of devices generates significant database load. The initial implementation was straightforward but inefficient: each flush cycle opened multiple database connections and executed individual INSERT statements in loops. At 600+ TVs, this meant 192 database connections per minute and thousands of individual SQL commands.

The optimization work focused on three areas. First, connection consolidation: all flush operations now share a single database connection per cycle, reducing connection overhead by 94%. Second, bulk INSERT statements: instead of one command per record, the platform now builds multi-row INSERT statements that handle batches of 100+ records in a single roundtrip. Third, flush interval tuning: doubling the interval from 5 to 10 seconds cut database load in half without meaningfully impacting dashboard freshness.

The combined effect was dramatic: database connections dropped from 192/minute to 6/minute (97% reduction), SQL commands per 100 records dropped from 100+ to 16 (84% reduction), and transaction conflicts that had caused intermittent errors disappeared entirely.

For transient error handling, the platform implements retry policies with exponential backoff that recognize database-specific error patterns—timeouts, connection resets, transaction conflicts—and retry appropriately rather than failing immediately. This makes the platform resilient to brief database hiccups without masking persistent problems.

Chapter 5: Fleet-scale operations and adaptive tuning

Scaling to 600+ devices required rethinking several assumptions. Health checks that worked fine at 50 TVs became bottlenecks at 600. Discovery scans that completed in seconds could saturate network bandwidth when run against large IP ranges. Background processes that were invisible at small scale became resource hogs.

The platform now implements adaptive tuning that adjusts operational parameters based on current load. Under high load, discovery fanout is capped to prevent bandwidth saturation. Health check concurrency scales with available resources. Polling intervals extend when the server is under pressure and contract when headroom is available.

For per-TV connection management, the platform maintains persistent sessions where possible, reusing existing connections for shell commands rather than opening new ones. Connection failures trigger per-device backoff rather than fleet-wide retries, preventing thundering herd problems when network issues affect multiple devices simultaneously.

Background services follow proper lifecycle management through ASP.NET Core's IHostedService pattern. Every service that runs continuously—telemetry collection, scheduled tasks, statistics aggregation—has explicit startup and shutdown hooks that ensure clean state transitions during restarts and graceful degradation during failures.

Chapter 6: Network security and compliance posture

Hospital network architecture requires strict segmentation. The platform operates within a three-VLAN model: a TV management VLAN for device communication (cleartext protocols isolated from patient networks), an IT operations VLAN for monitoring and database access, and a staff access VLAN for dashboard users.

This segmentation is critical because some TV management protocols don't support encryption—a hardware limitation, not a software choice. VLAN isolation compensates for protocol limitations by ensuring cleartext traffic never traverses patient or public network segments. Firewall rules enforce this boundary with default-deny policies and explicit allowlists for required communication paths.

For HIPAA compliance, the platform addresses technical safeguards through multiple layers: unique user identification via authentication, automatic session logoff after configurable timeouts, audit trails for all TV interactions and configuration changes, and encryption for dashboard access (HTTPS required in production). The network architecture documentation maps these controls to specific regulatory requirements (45 CFR § 164.312) for compliance reviews.

Enterprise monitoring integration happens through Zabbix, exposing custom health metrics—device connectivity, firmware status, alert counts, backup verification—through a dedicated metrics endpoint. This allows the platform's health to be monitored alongside other hospital infrastructure, with alerting rules defined in the organization's standard monitoring framework.

Impact

This platform transformed hospital TV management from reactive troubleshooting to proactive operations. Staff can see device health across the entire fleet in real-time, identify firmware update failures before patients complain, and track integration health with hospital systems. The security work established a foundation that meets healthcare compliance requirements without compromising operational utility. And the performance optimizations ensure the platform scales with the fleet rather than becoming a bottleneck.