Engineering for Scale
and Isolation.
A pragmatic guide for technical stakeholders detailing the exact control plane constraints, telemetry ingestion bypasses, and state-management protocols that enforce operational security and sub-second scale processing.
The Control Plane
// Identity, State, and Consent Isolation
The system of record is strictly isolated from telemetry ingestion. Red Hat Keycloak operates as the identity fortress, fulfilling enterprise requirements for SAML, Active Directory, and OIDC federated workflows. Cloud SQL (PostgreSQL) is utilized exclusively for relational, transactional state—specifically User Accounts, Facility Mappings, and the Universal HIPAA Consent Kill Switch. This architectural constraint enforces instant ACID-compliant consent propagation without the latency risks of massive table bloat commonly found in scaled RPM systems.
The Hybrid Lakehouse
// Parquet-Backed Telemetry Ingestion
Continuous high-frequency Remote Patient Monitoring (RPM) telemetry architecturally bottlenecks standard OLTP database performance at scale. To circumvent this, the ingestion API verifies HIPAA consent via Postgres and immediately bypasses the database, writing batched telemetry directly to Google Cloud Storage (GCS) as highly compressed Apache Parquet files. Data is physically partitioned by patient ID (e.g., gs://rpm-data/patient_id=X/...), enforcing strict logical and physical separation that naturally prevents cross-patient PHI leakage.
Resilient Transport Layer
// HTTP/3 (QUIC) with Automated HTTP/2 Fallback
High-frequency telemetry demands a transport layer that can survive the unpredictable latency of patient home networks. Internal data routing and client ingestion utilize HTTP/3 over QUIC. By operating over UDP, this eliminates TCP head-of-line blocking, ensuring that erratic edge connections never stall the broader telemetry stream. For legacy infrastructures that cannot support QUIC, the system seamlessly falls back to HTTP/2 multiplexing, maintaining uninterrupted data transit.
Stateless Analytical Engine
// Zero-Overhead Data Retrieval (CQRS)
Heavy AI symptom drift calculations and dashboard aggregations are executed without indexing overhead or impacting the write-path database. The routing layer utilizes native DuckDB bindings, spinning up the analytical engine entirely in the memory of the Cloud Run container. DuckDB issues HTTP range requests directly against the GCS Parquet files, calculating rolling baselines in milliseconds. The container returns the serialized JSON artifact and immediately destroys the in-memory engine, ensuring complete blast-radius isolation.
Client-Side Memory Management
// Aggressive PHI Cache Invalidation
Client-side state management is explicitly hardened against PHI leakage on shared clinical workstations. Data fetching via React 19 and TanStack Query is configured with aggressive zero-caching policies (gcTime: 0, staleTime: 0) for any endpoints returning medical data. Upon component unmount, tab closure, or view navigation, raw telemetry instantly evaporates from browser memory, neutralizing the risk of unauthorized extraction from local browser states.
Zero-State Edge Computing
// Secure Server Components & Rust WASM
While our dynamic web portals utilize strict zero-cache client fetching, our physical point-of-care Kiosks and highly volatile edge environments operate on a strict Server-Side Rendered (SSR) architecture. By rendering the UI on the server for these shared devices, we physically prevent the transmission of raw JSON telemetry payloads over edge networks. Furthermore, physical edge logic executes via memory-safe Rust compiled to WebAssembly (WASM). This delivers native execution speeds at the edge without leaving volatile, garbage-collected PHI traces in local machine memory.
Enterprise Edge Connector
// Certified Legacy Ingress via Rhapsody
To bridge the gap between deeply fragmented hospital databases and modern infrastructure, we established a strategic ingress partnership with Rhapsody. This functions as a dependable, highly compliant edge connector that cleanly normalizes legacy configurations directly into our strict FHIR R5 schemas. Rhapsody is independently certified against HITRUST CSF and ISO 27001, cryptographically and operationally extending our security perimeter straight into the hospital’s operational core.
Asynchronous Telemetry & Zero-PHI Messaging
// Strict Inbound Routing & Granular Consent Propagation
To maximize patient engagement without compromising the security perimeter, the platform utilizes SMS and asynchronous webhooks strictly as inbound telemetry vectors. Patients opt-in to transmit behavioral signals into the system, while outbound communication is hardcoded to a Zero-PHI policy. The sole exception—transmitting a patient's first name to an authorized Wellness Partner or Care Circle member—is governed by granular, explicitly granted consent. Because relational state and consent are isolated in Cloud SQL, a patient's decision to revoke this access triggers the Universal HIPAA Consent Kill Switch, instantly and universally terminating that data flow at the routing layer before the next message can ever be compiled.
Cryptographic Security & Immutable Audit Logging
// FIPS 140-2 Compliant Encryption & Traceability
Physical partition isolation in our Lakehouse is backed by strict cryptographic standards. All Protected Health Information (PHI) and telemetry data is encrypted at rest using AES-256 and in transit via TLS 1.3. Furthermore, because our architecture isolates transactional state in PostgreSQL, we maintain an immutable, highly queryable Audit Trail. Every consent revocation, dashboard load, and AI-driven DuckDB query is logged with a cryptographic timestamp and Keycloak Identity marker, ensuring frictionless compliance with HIPAA Security Rule audit requirements.
Definitive Architectural Certainty
By strictly bifurcating transaction state (PostgreSQL) from analytical data volume (GCS + Parquet) and enforcing zero-cache policies on the client layer (TanStack Query), the system physically eliminates both database table explosion and browser-level PHI leakage.
A Note from the Founder
I believe in systems. The first databases I worked on were for Logistics in the USAF—I'm not going to say it was pretty, but my manual was thick and the steps were spelled out. Later in life, I took flight lessons. I'm not a pilot, but I learned a deep appreciation for pre-flight checklists and doing the hard, boring work up front so that we minimize emergencies later.
I have taken a pilot's approach to developing systems and writing code. "Move fast and break things" is great for a start-up building an app that puts an emoji on a picture and turns you into a meme. It is not a recipe for critical enterprise infrastructure. And that is what we are building: critical infrastructure. We do the hard work first so that we aren't pushing patches at 4:30pm on a Friday.
Our commitment is: it works, and we trust it, before we push it. I won't say that we will never have an issue. But I will say that they will be smaller, faster to patch, and impact your systems less than the monolithic, legacy architectures of our competitors.
When you have a question, a suggestion, a concern, or a compliment... we are here to listen.