How LynCareOS works — operating model, modules, and controls

01Operating model overview

LynCareOS is a multi-tenant family care platform sold direct to families, not to clinical providers. Every operating decision — what to build, how to price, how to gate access, what to seed at signup — flows from one insight: families coordinating end-of-life and complex chronic care all do one of seven things.

A single deployment serves many independent tenant accounts. Inside each tenant, a care circle of carers and observers coordinates around one or more people in care. Data isolation is enforced both in application code and by PostgreSQL row-level security. Carers and observers see only the patients they have been granted access to via the patient_access table; tenant administrators see all patients in their account.

The four moving parts

1. Care Archetype. The dominant daily coordination challenge — not the diagnosis. Seven patterns covering every palliative and complex-care case observed in research. Free at all tiers; selected during onboarding to drive seeding.
2. Care Profile pack. A named, family-recognisable template (e.g. Cancer at home, Breathing difficulties) containing the reason types, observation types, shift task templates, and family-language guides for that pattern. Twelve canonical packs. Two free starters; seven standard at $14.99 USD each; three specialist at $19.99; bundles available at checkout.
3. Care Start apply. A single transaction that copies pack content into the tenant and patient. The product promise is "ready to use in ~30 seconds" — not a marketplace badge. The function is apply_care_start_pack(), dev-verified 2026-06-04 and live on the VPS.
4. Subscription tier. Three plans (Essential / Family / Complete) that govern care-circle capacity, module access, and which Care Profiles can be used at no extra cost. All commerce runs through Stripe live across seven currencies.

The audiences this operating model serves

Practitioner and provider audiences are explicitly out of scope for the consumer product. The roadmap reserves space for an opt-in "share with practitioner" export channel; today the platform is sold and operated as a family tool that a clinician may consult, not a clinician tool that a family may help with. This positioning shapes pricing ($39–$99/yr USD), language register, and the deliberate decision to stay outside the regulated medical-device space.

02The care model

The care model is the spine of the product. It tells the platform which modules to enable, which content to seed, what language register to use, and what to ask first. It is also why the onboarding can be 30 seconds rather than 30 minutes.

Seven Care Archetypes

The archetype is defined by the dominant daily coordination challenge, not the medical diagnosis. Two families managing completely different diseases may share the same archetype because the coordination shape is identical. During the People in Care wizard, the family selects the closest match; the platform activates the modules that matter most and seeds the recognisable language for that pattern.

Archetypes are stored in condition_archetypes (V077, copy reconciled by V006). Detailed pattern definitions including daily reality, what breaks without coordination, and family-language vocabulary live in Palliative Care Archetypes.

Twelve Care Profiles

A Care Profile is the named, plain-language version of an archetype that families recognise. Where the archetype is "Medication Orchestra," the profile is "Cancer at home." Profiles are stored in condition_packs; their content (reason types, observation types, shift task templates) lives in pack_reason_types and pack_shift_tasks (V007–V008).

Care Start — the 30-second seed

Care Start is the operation that turns an unlocked Care Profile into a usable patient record. It runs apply_care_start_pack(tenant, patient, pack) in a single transaction, populating reason_types, enabling observation_types, creating shift task templates, and writing patient.archetype_id so the rest of the product knows what to recommend next.

Without Care Start, families would own permissions to a blank product. The strategic decision was made early: never charge for permissions alone; always charge for permissions + seeded content + the apply step. 25-SUBSCRIPTION-VS-CARE-PROFILES walks through the commercial implications.

Care Pathways (Planning Ahead) — the next layer

Beyond Care Start, the next major release adds Care Pathways — a staged planning journey per archetype with informative stages and optional self-placement (e.g. "Where are we in this journey?"). Specification is complete; implementation is queued at D31. Family + Complete tiers, gated by care_pathways. See 33-CARE-PATHWAYS-MODULE.

03Eleven modules and what they do

The product surface is a set of independently gated modules. Each module is a router in the FastAPI backend protected by require_module(slug); each is a route in the React PWA enabled or hidden based on the tenant's subscription. Eleven are live in production today.

The module system is what makes the three subscription tiers meaningful. Essential ($39/yr) ships with two modules. Family ($69/yr) adds eight more. Complete ($99/yr) adds the heavier clinical modules and unlocks every Care Profile. New modules can be promoted from Future to Live without changing the contract: add a row to billing/tiers.json, register the router with require_module(), and the product surface expands.

Modules shipped today

Modules planned next

04Tiers and entitlements

Three subscription plans price the platform for the family budget, not the institutional buyer. Each tier sets care-circle capacity, module access, and which Care Profiles are included at no extra cost.

Care-circle capacity (server-enforced)

Hard limits are read from backend/billing/tiers.json and enforced server-side in backend/services/tier_limits.py. When a limit is hit the API returns HTTP 402; the SPA renders an <UpgradeGate> with the next-tier offer.

Module access by tier

The full module-by-tier grid is the authoritative reference; the abbreviated view below shows the shipping eleven.

Local pricing in seven currencies — AUD, NZD, GBP, EUR, CAD, INR, USD — is set in Stripe directly via the live switchover playbook. Adaptive Pricing remains off; the displayed price is the final price.

05Commerce & Care Profile packs

Commerce is split deliberately between the recurring subscription and the one-time Care Profile pack. The subscription pays for the platform; the pack pays for the curated content that makes the platform usable in 30 seconds.

Two revenue lines, one checkout

• Subscription — annual, three tiers, seven currencies. Stripe Customer Portal for self-service upgrade/cancel.
• Care Profile packs — one-time, attached to a tenant. Family-tier customers can add packs at $14.99 (standard) or $19.99 (specialist). Complete-tier includes all twelve.
• Add-on people in care — $5/yr each, stored as tenants.extra_care_recipients; lifts the hard cap at any tier.
• Bundles — checkout-time offers (palliative care start, complete care library, paediatric family bundle) packaged as a single line item.

Pack catalogue (canonical)

Pack slugs and pricing are authoritative in Palliative Care Archetypes §3.2; this index is for navigation.

06Care Module — daily capture

The Care Module is where the family actually uses the platform every day. It replaces the patchwork of WhatsApp, paper notebooks, and spreadsheets with one shared workspace organised around the patient.

Each Care Module is a bounded board view: medication, vitals, observations, pain & mind, family help, calendar. Boards open from the People-in-Care list; everything inside is scoped to a single patient and uses the language register seeded by Care Start. The board pattern keeps capture under 30 seconds for the most common tasks: log a dose, record a vital, mark a shift complete.

Capture mechanics

• One-tap log dose — up to four "quick pick" pills surfaced from active scripts; full schedule one tap deeper.
• First-dose reaction check — when a medicine is logged for the first time on a patient, a non-blocking modal asks for an adverse reaction check (REQ-MED-16, live). A care alert is raised if "yes."
• Custom observations — daily logs sourced from the seeded archetype/profile types; rendered in Bollinger trend charts so anomalies are visible at a glance.
• Care alerts — durable in PostgreSQL; the bell icon and PWA badge surface them. Web Push was retired in favour of in-app awareness.

Care Module UI conventions and plug-in architecture for new boards are documented in 29 · Care Module UI architecture and 30 · Plug-in architecture.

07Family coordination

Coordination is the second-most-frequent reason families burn out — after the medical load itself. The platform gives every carer the same picture, the same vocabulary, and a shared sense of who is on next.

Calendar & shifts

The care calendar is monthly and weekly, with shift assignments, location tags, and per-shift task checklists. Coverage gaps are highlighted visually — a missing carer for tomorrow morning shows as a coloured strip rather than a silent gap. Clinical appointments live alongside shifts; the same date frame holds both the pharmacy pickup and the daughter's morning shift.

Family help board

Help is asked for explicitly. A carer posts "I need someone to drive Mum to the appointment Tuesday"; volunteers (extended family, neighbours) claim it. The board doubles as the social safety record — five months in, every family has a public list of who showed up.

Key contacts & roles

The care team directory is the single source of truth for "who do I call when…". Roles include GP, palliative specialist, pharmacist, after-hours nurse line, and family-facing roles. Observers can see the directory; only carers and admins can edit it.

08Customer journeys

Three journeys define the operating model in motion: signup & Care Start, daily capture by the family, and the upgrade flow when a family outgrows their tier.

Signup → Care Start (the 30-second promise)

1. Marketing site → tier picker. Optional Care Start pack pre-selected based on archetype.
2. Stripe Checkout (single transaction): tier + optional pack + optional add-on people.
3. Webhook checkout.session.completed provisions tenant, seeds tenant_pack_purchases, activates modules.
4. Family signs in, runs Add Person wizard, picks archetype, recommended profile is offered.
5. apply_care_start_pack() seeds the patient record. Family lands on a working board.

Daily capture

1. Open app (PWA). Dashboard surfaces "what's happening today" — adherence ring, next dose, one accent CTA.
2. Log dose / record vital / observation. Most paths are one tap.
3. Care alert raised on missed dose, first-dose reaction "yes," abnormal vital, or family help open beyond a window.
4. Other carers see the change in near-real-time (SSE). Bell icon and PWA badge update.

Upgrade journey

1. User attempts a gated action (e.g. add a 6th medicine on Essential).
2. API returns HTTP 402; <UpgradeGate> renders contextual upgrade card.
3. One click → Stripe Customer Portal → tier change. Webhook updates subscriptions and modules expand.
4. Complete-tier upgrade additionally rank-grants all twelve Care Profile unlocks via grant_tier_pack_access().

Detailed swimlane visuals for these journeys live on the workflow page. The flows are derived from 24 · Limits & upgrade APIs §10.

09Controls & compliance

The platform deliberately stays outside the regulated medical-device space, but it carries PHI and operates a multi-tenant model. Controls are designed to be defensible to a privacy regulator and to a security-minded buyer.

Multi-tenant isolation

Every tenant-owned row carries tenant_id. Application code enforces isolation in every query; PostgreSQL row-level security is an additional backstop, not a substitute for app checks. Patient access is a second axis: carers and observers see only patients in patient_access; tenant administrators see all patients in their account. A super-admin may operate on any tenant via an explicit X-Tenant-ID header.

Identity & PHI encryption

• Identity PHI (name, DOB, contact) is encrypted at rest with platform keys, with blind-index lookups so we can search without decrypting.
• Per-tenant data encryption keys are provisioned for the next tranche of column-level encryption.
• MFA secrets use a separate crypto envelope. The encryption key must be pinned on the VPS before public launch (gate D13 / A2).

Audit & observability

Every write to a patient or commerce record carries an actor, timestamp, and tenant. Audit lives in dedicated tables; the platform runbook describes day-2 verification (07 · Platform runbook).

Backup & restore

• VPS-local backup tier — daily automated.
• Workstation offsite copy — pulled regularly. A5 + A5b complete (drill 2026-06-02).
• Cloud offsite (A8) — deferred until scale.

Launch gates

10Roadmap & release posture

Private beta on a Sydney VPS with Stripe live across seven currencies. Eleven modules shipped. Care Start delivered to production 2026-06-04. Three explicit launch gates remain before lifting the marketing gate.

Master sequence

The roadmap is the implementation Bible: it disagrees only with itself, never with the requirements register. When a feature ships, it moves from "Future" to "Delivered" and a status note is added on the same row. See 04 · Roadmap for the full master sequence.