NHOS Support Chat: Architecture, Operations, and Verification Status of a Self-Hosted Customer Support Platform for Health Technology

NHOS Support Chat is a self-hosted, privacy-oriented, real-time customer support platform developed by NHOS Labs, Inc. This technical note documents the platform's architecture, development methodology, feature inventory, security and privacy design, operational economics, implementation status, limitations, and validation roadmap. The system is designed to give the deploying organization direct control over its support application and stored support data without depending on a third-party hosted chat provider or external AI API.

Background and Motivation

Health technology organizations must evaluate support infrastructure in light of data handling, operational cost, vendor dependence, auditability, and privacy requirements. Third-party support services can simplify deployment but may place conversation data and parts of the support workflow within vendor-controlled environments. Self-hosting offers an alternative in which the organization operates the application and manages its configuration, retention policies, and infrastructure responsibilities.

NHOS Support Chat investigates the feasibility of implementing an integrated support platform under a constraint of avoiding purchased chat services and external API keys. The design emphasizes operator control, deterministic automation, data minimization, and transparent system behavior. Self-hosting alone does not establish compliance with HIPAA, GDPR, or other legal and regulatory frameworks; those determinations depend on the deployment, data, applicable obligations, and organizational practices.

System Architecture

The platform consists of three principal components.

Component A — Embeddable JavaScript Widget

The browser-side widget, nhos-support.js, initializes within an isolated Shadow DOM container and renders the chat interface. It supports visitor messaging, contextual knowledge-base suggestions, and file attachments. It communicates with the backend over HTTPS, using Socket.IO when available and HTTP polling as a fallback.

Component B — Node.js/Express Backend

The backend exposes a REST API under /api/support/. It manages conversations and tickets, authentication, NIME™ responses, knowledge-base operations, attachment processing, service-level agreement (SLA) timestamps, and scheduled operational tasks.

Component C — Administrative Dashboard

The static HTML/JavaScript dashboard provides interfaces for managing live chats, tickets, visitors, knowledge-base articles, service-level metrics, configuration, canned responses, notifications, and CSV exports.

The documented MySQL data model contains eleven principal tables: agents, visitor_sessions, conversations, conversation_messages, tickets, ticket_messages, kb_articles, canned_responses, attachments, email_logs, and settings.

The technical note includes system architecture and data-flow diagrams, deployment topology, schema documentation, an API endpoint reference, and environment configuration details.

NIME™ — NHOS Interactive Message Engine

NIME™ is the deterministic, rule-based response engine integrated into the support messaging workflow. It operates without external AI API calls or machine-learning inference. Its documented intent library comprises twelve patterns: greeting, hours, contact, products, pricing, research, technical support, medical safety, human handoff, thanks, goodbye, and ticket status. When no pattern matches, the engine uses a contextual fallback intended to direct the visitor toward human assistance.

NIME™ is not presented as a clinical decision-support or diagnostic system. Its medical-safety handling is designed to avoid providing medical advice, diagnoses, treatment recommendations, or medication guidance and to redirect health-related queries appropriately. The effectiveness of this boundary under adversarial prompts has not been independently validated.

Feature Inventory

The platform's documented features include:

• Bidirectional visitor-to-agent live messaging.

• Ticket creation and management for offline support, with email notifications.

• Deterministic rule-based automated responses through NIME™.

• Knowledge-base content management and contextual in-widget article suggestions.

• Visitor session monitoring, including current page context.

• SLA tracking and first-response metrics.

• Configurable business-hours automation and agent-status handling.

• Canned responses with slash-command autocomplete.

• File attachments with a documented 10 MB per-file limit and MIME-type allowlisting.

• CSV export for conversations and tickets.

• Scheduled weekly digest email reporting.

• Configurable retention settings and scheduled cleanup.

• Message, conversation, ticket, and knowledge-base management, including deletion and bulk operations where supported.

• Widget appearance settings, including color, position, offsets, welcome message, and logo.

• Desktop notifications, sound alerts, and title-bar notification behavior.

Security and Privacy Design

The documented security design includes password verification using bcrypt-hashed credentials, JWT-based authentication, parameterized SQL queries, output escaping intended to mitigate cross-site scripting, and an allowlist-based attachment workflow. Uploaded files are described as receiving randomized filenames, being stored outside the web root, and being served through authenticated endpoints. Database credentials, SMTP credentials, and the JWT signing secret are configured through an environment file outside the web root.

The platform does not rely on third-party analytics, tracking pixels, fingerprinting scripts, or cross-site identifiers as part of its documented support-widget design. However, the application processes support message content and may store visitor IP addresses, user-agent strings, session identifiers, and current page URLs. Hosting-provider logs, backups, and email infrastructure may also constitute separate data-access or retention surfaces. Accordingly, self-hosting should not be interpreted as eliminating every third-party data exposure.

These descriptions document the intended and reported implementation. They are not a substitute for independent verification of authentication, authorization, session handling, transport security, access isolation, attachment handling, deletion behavior, or API abuse protections.

Deployment and Operational Economics

The platform is deployed at:

https://nhos.health/gov/

The documented deployment uses a Node.js/Express application, MySQL, a browser-side JavaScript widget, and a static administrative interface. Site-wide integration across all NHOS pages is described as planned rather than complete.

The reported deployment uses existing shared hosting, a bundled MySQL database, an existing SMTP mailbox, allocated disk storage, and an existing SSL/TLS certificate. On that basis, the paper estimates zero incremental monthly cash cost for the current deployment.

This is a deployment-specific marginal-cost estimate, not a claim that the system has zero total economic cost. Hosting allocation, maintenance, development labor, backups, and future capacity requirements still have economic implications.

The technical note also provides a three-year cost framework and a functional comparison with commercial support platforms. Such comparisons are limited to the features and cost assumptions documented in the paper; they do not establish equivalent reliability, performance, security, support quality, or usability.

Project Website and Access

Project information and documentation for NHOS Support Chat are available at:

https://nhos.health/support-chat/

The deployed support application is available at:

https://nhos.health/gov/

The project page provides an additional point of reference for readers interested in the platform and its development.

Deployment Status and Evidence Boundaries

NHOS Support Chat is reported as implemented, deployed, and functionally operational on the NHOS governance portal. The development team reports functional verification of delivered features. The current deployment location and rollout status are documented in the technical note.

The paper distinguishes implementation from independent validation. The following activities remain outstanding or require further evidence:

• Independent security audit and penetration testing.

• Load testing and performance characterization at scale.

• External-user usability evaluation.

• Independent testing of the NIME™ medical-safety boundary and escalation behavior.

• Tested database restoration and broader reliability procedures.

• Regulatory and data-protection assessment for specific deployment contexts.

The technical note defines a Production Readiness Verification Matrix with eight gates: four critical gates (C1–C4) and four high-priority gates (H1–H4). These gates address authentication and authorization, attachment security, visitor-data isolation, deletion and retention behavior, database reliability, scheduled-task and email reliability, messaging recovery, and NIME™ boundary testing.

The system should therefore be characterized as an implemented and operational research platform ready for evaluation—not as independently certified, clinically validated, or demonstrated to be enterprise-ready.

Scope and Limitations

This work documents a deployed software implementation and its technical design. It does not claim:

• Regulatory compliance with HIPAA, GDPR, the Medical Device Regulation (MDR), or any other framework.

• Clinical validation or demonstrated clinical benefit from NIME™.

• Independent security certification or proof of resistance to all attacks.

• Empirical improvement in customer satisfaction, resolution time, or agent productivity.

• Validated maximum throughput, concurrency, or production-scale performance.

• Suitability for every health technology deployment or data classification.

Formal security, reliability, performance, usability, and regulatory-positioning work is identified as future work. These boundaries are part of the paper's evidence statement and should be considered when evaluating the platform.

Document Contents

The technical note provides:

• System architecture diagram and data-flow diagrams.

• Development methodology and technology-selection rationale.

• Feature inventory and NIME™ rule-engine description.

• Security and privacy design, including data-handling boundaries.

• Deployment topology, operations, and cost analysis.

• Eleven-table database schema with column-level documentation.

• API endpoint reference and environment configuration reference.

• Functional comparison with tawk.to.

• Production Readiness Verification Matrix and implementation-status summary.

• Known limitations and a validation roadmap covering security, reliability, load testing, usability, and regulatory positioning.

• Reviewer response and revision history.

Supplementary Files

A consolidated view of the NHOS Support Chat message lifecycle across all six phases, together with three asynchronous background paths, is provided as a supplementary figure. Individual phase diagrams appear as Figures 2–5 in the main PDF. The consolidated diagram provides a single-page overview and is supplied separately rather than embedded in the main document.

The supplementary files are:

• figure-4-end-to-end-flow.pdf — vector PDF for viewing and printing.

• figure-4-end-to-end-flow.svg — SVG source for scalable rendering and editing.

• figure-4-end-to-end-flow.png — raster PNG for preview and compatibility.

Keywords

Customer support; live chat; self-hosted software; health technology; privacy engineering; real-time messaging; knowledge management; deterministic rule-based automation; NIME; NHOS Labs; Node.js; MySQL; Socket.IO; data minimization; software validation; operational cost analysis.

Suggested Citation

NHOS Labs, Inc. (2026). NHOS Support Chat: Architecture, Operations, and Verification Status of a Self-Hosted Customer Support Platform for Health Technology (Version 2.2.0). Zenodo. https://doi.org/10.5281/zenodo.23299241

License

Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0), subject to the license selected for the deposited record.