A Working Snapshot of the TIR Labs Data Architecture
This note is a snapshot of the TIR Labs data architecture after the first build phase. It is not a final-state architecture diagram. It is a record of what has been built so far, what the system is already being asked to support, and which decisions seem important to preserve as the product keeps changing.
TIR Labs started with a practitioner-facing glucose review dashboard, but the architecture now supports a broader care-management workflow. The system has to handle practitioner and client identity, device connection, connected health data, patient-entered context, care communication, insurance coverage workflows, and saved monitoring definitions. That is still early. But it is enough architecture to see the shape of the product.
The Current Stack
The practitioner portal is a Next.js application backed by Neon Postgres and deployed on Fly. The Android patient app is written in Kotlin and uses Android Health Connect as the first real-world bridge for patient-side health data. The public website is separate and hosted on Firebase, but it is not part of the product data system.
The practitioner portal reads from backend APIs rather than talking directly to device sources or external services. That boundary matters because it keeps the practitioner experience insulated from the specifics of any one data source. When a new device integration arrives, or when an existing source changes its shape, the portal does not have to change alongside it. The APIs absorb that complexity and present normalized data to the product surface.
Stedi handles insurance eligibility checks because it sits in the healthcare clearinghouse layer and speaks the right protocols for payer communication. Resend handles transactional email for magic-link authentication and enrollment flows. USDA FoodData Central supports nutrition lookup for patient meal logging. Health Connect on Android is the current path for pulling CGM and activity data from the patient's device without requiring a direct vendor integration for every supported device.
The Data Sources We Support Or Are Preparing For
Health Connect changed the data architecture problem early. Unlike a direct vendor API, Health Connect aggregates data from multiple possible sources on the patient's device. That means the product receives glucose and activity records with different metadata shapes, different source identifiers, and different reliability characteristics depending on what the patient's device and apps are doing.
That pushed the schema toward a generalized connected-health layer. The current design includes source-aware CGM concepts, cgm_connections, cgm_devices, and cgm_readings, that preserve where data came from without making the practitioner experience vendor-specific. Future sources, including Apple HealthKit and direct CGM vendor APIs, fit into the same pattern without requiring the product surface to change.
Beyond CGM, the product is already handling several other categories: practitioner and patient workflow data including accounts, sessions, enrollments, and invite states; patient-entered context including meals and care-note replies; operational care data including coverage records, eligibility checks, benefit snapshots, and estimates; and practitioner configuration data including saved pattern monitors and notification state.
Those categories matter because they should not collapse into one generic patient data bucket. A glucose reading, a mobile session, an eligibility result, and a saved monitor definition all belong to the patient workflow, but they mean very different things.
The Core Shape Of The Database
The database has evolved into several related clusters, each representing a distinct part of the care workflow.
Identity and access covers practitioner accounts, patient accounts, sessions, magic links, enrollment invites, and practitioner-client enrollments. The schema reflects the intended model: a practitioner invites a patient into their care program, the patient accepts, and the relationship is tracked explicitly from that point forward.
Mobile and device authorization is kept separate from enrollment deliberately. A patient joining a practitioner's care program and a patient authorizing a phone to send Health Connect data are related events but not the same event. The schema includes mobile handoffs, mobile sessions, device records, and sync audits as distinct concepts because the product needs to know not only who the patient is, but which specific device installation is authorized to send data on their behalf.
Connected health data sits in the generalized CGM layer, with source-aware connections, normalized glucose values, source record identifiers, and dedupe rules to handle the reality of device data, which often arrives with backfill behavior, repeated sync attempts, or missing identifiers. Activity and other health events sit in a separate patient_health_events table rather than being folded into the glucose data model, because steps and workouts have different units, rhythms, and review value.
Coverage and reimbursement support covers eligibility checks, normalized eligibility statuses, raw payer response storage, benefit snapshots, and estimates. The product does not simply surface a raw payer response. It normalizes the result into operational statuses the practitioner can act on, while still preserving the raw response for audit and troubleshooting purposes.
Saved monitoring definitions round out the schema. A saved monitor stores the practitioner's intent, which patient, what question, what kind of monitor, and whether it is active, rather than storing a frozen answer from a past review. That means the product can reevaluate the monitor against the current review window instead of showing stale results as if they were current.
What This Is Not Yet
This is not a mature analytics warehouse.
TIR Labs does not yet have a separate analytics modeling layer, a full observability stack, or automated reconciliation across multiple data sources. Some data paths are still intentionally pragmatic. Some tables carry the history of how the product evolved rather than reflecting a clean final design. iOS and Apple HealthKit are planned but not yet implemented.
The architecture today is an operational product database with growing analytics responsibilities. It supports real workflows, real persistence, and increasingly structured health and operational data. It is still early, but it is no longer abstract.
The Direction
The shape of this architecture reflects a consistent set of choices. Source-specific details are preserved where they matter, but the practitioner experience is not allowed to become vendor-specific. Data is normalized into product-owned concepts before it reaches practitioner workflows. Enrollment, device authorization, and data access are kept as separate concerns rather than collapsed into a single onboarding event. Operational data and health signal data stay connected through the patient workspace without being treated as interchangeable. And when the product needs to track something over time, it stores a definition the system can reevaluate, not a snapshot it can only display.
These are not novel architectural ideas. What matters is that they were applied consistently as the product grew, and that the data still means what it is supposed to mean.