INBOA clearer picture of
what happened between visits.
The patient app organizes the daily record. The portal is being built to turn that record into efficient clinical context — not another wall of data.
You see snapshots. Diabetes generates continuous context.
Between two appointments, a patient produces thousands of glucose readings and hundreds of small decisions. The signal that matters — a worsening overnight pattern, a run of lows after sport, a stretch of CGM silence — is real, but it’s scattered. INBO’s job is to organize it so the next visit doesn’t begin with reconstruction.
What the app already captures.
Current patient-side building blocks that flow into the clinical picture.
CGM & glucose
Dexcom, FreeStyle Libre (LibreLinkUp), and Nightscout, reconciled to the freshest reading.
Meals & insulin
Carbohydrates and insulin taken, logged as history — recorded, never calculated by the app.
Activity & context
Exercise, medication where relevant, and the meal-period context around each reading.
Monitoring observations
Scoped background monitors that write plain observations, not directives.
Trends & history
Time-in-range, averages, and recurring highs and lows made visible.
Reports
Visit summaries and a gestational-diabetes report built from the patient’s own data.
Guardian & family
Caregiver sharing with roles and permissions designed for a family.
GDM experience
Fasting and post-meal targets, gestational week, and OB visit prep.
The whole practice on one screen.
A practice population becomes a prioritized clinical worklist instead of a set of separate charts someone has to hunt through.
A working foundation, honestly labeled.
The portal today is a working foundation with a synthetic demonstration cohort — not a finished product. Here is exactly what is running versus what is being built.
- Patients enroll with a practice code; the patient redeems it in the app, which establishes the data-sharing relationship
- Clinicians sign in with individually named accounts; four roles — clinician, case manager, quality analyst, org admin — with defined capabilities
- Population overview with cohort time-in-range, averages, and enrollment context
- Patient-level glucose visualization against targets, with recent dose history on the clinical side
- Case workflow — cases can be acknowledged, assigned, resolved, and documented with notes
- Clinician-authored settings — the authorization-and-sync governance loop is real and running
- Clinical activity is designed to be attributable and auditable
- A ranked population worklist that raises patients who appear to deserve review — informed by, never a replacement for, clinical judgment
- A richer patient view with AGP-style glucose visualization and insulin events overlaid on glucose
- A settings-change timeline showing who authored a change, previous and new values, and whether it was applied on the patient side
- Documented clinical messaging — patient-specific, clinician-authored threads delivered to the app, with guardians included appropriately
- An in-portal audit-log viewer, population trends over time, and clinician notifications
Presented as in development. Not yet a production feature set.
No silent clinical changes.
The portal does not reach into a patient’s phone and quietly rewrite insulin-related settings. A clinician can authorize a change; the patient, or a guardian, applies it.
The portal proposes. The phone disposes.
One set of bounds, across both sides of the system.
Clinician-authored settings are designed to enforce the same classes of validity and safety bounds as the phone — so the portal is not a back door around the app’s own validation. A change is authored, attributed, applied, and retained as a chain.
Concept shown — synthetic data — settings history and applied-status timeline are in development.
Built with the pediatric care relationship in the data model — not bolted on.
INBO was born from a parent managing a daughter’s Type 1 diabetes. Guardian relationships shape enrollment, data-sharing, settings approval, communication, and family access — rather than being a checkbox added later.
Three distinct participants with distinct permissions — not one shared account.
A separate clinical build, with deterministic dosing.
Everything on the public side is dose-free. Separately, a private clinical-development edition — a different binary, not sold as a consumer product — contains deterministic insulin-dose calculation for supervised development use.
- A separate build — the public App Store edition does not ship the dose engine at all
- Deterministic arithmetic on explicit, patient/provider clinical settings — a language model is never the dose engine
- Insulin-on-board computed with explicit insulin-action curves (Fiasp, aspart, lispro, and Lyumjev), interpolated from published labeling
- Inputs and the result breakdown are visible and auditable, with the model and curve source recorded per dose
- Explicit bounds — a required maximum single dose, a hard ceiling, round-down insulin, and dose-spacing limits
- Defined refusal conditions: missing, invalid, or stale inputs cause the calculation to refuse rather than invent a number
- No silent auto-tuning — a rating never rewrites a patient’s settings. No pump control. No insulin delivery.
Status: a clinical-development function. It has not completed clinical validation and is presented with no regulatory or outcome claims. Broader distribution of dose calculation would follow the appropriate regulatory pathway.
Built enough to evaluate. Early enough to shape.
We’re looking for endocrinology practices, pediatric programs, academic centers, and experienced clinicians who want to help shape the physician workflow — what rises to the top of the worklist, which patterns matter, which alerts create noise, and how settings review and clinical communication should work.