GuideGLP
Retiring as a standalone service under the Canvas-first architecture. GuideGLP partners become Organizations in the shared Canvas instance.
Why GuideGLP as a service is retiring
The original design put GuideGLP in its own standalone service with its own database, its own physician tables, its own orders table. This created:
- Duplicate effort: GuideGLP and DTC had parallel implementations of order lifecycle, billing, pharmacy routing, and notifications.
- Divergent data models:
guide_physiciansvs the YourEra physician table,guide_ordersvs orchestrator orders. - A cross-cutting "source" discriminator threading through every service that had to branch on whether a request came from GuideGLP or DTC.
- No path to share Canvas infrastructure — GuideGLP patients were explicitly excluded from Canvas.
Under Canvas-first, GuideGLP partners are tenants in the shared platform. The tenant
discriminator is Organization.kind, not a service boundary. See
canvas-first-principles §3 for
the multi-tenancy pattern.
What happens to each GuideGLP responsibility
- Partner identity + branding:
organization-service.organizations+organization_branding+organization_portal_config+organization_notification_config. - White-label portals:
patient-portal(white-labeled perorganization_custom_domains) +admin-portal(tenant-scoped withadmin_org_memberships). - Partner physicians:
physician-registry+physician_org_memberships. The same registry powers YourEra DTC physicians; a physician can serve multiple orgs. - Partner orders:
commerce-service.orderswithorganization_id. Same orchestrator saga runs for every fill, regardless of tenant. - Partner intake flows:
intake-gatewaywith host-based org resolution. Custom domains configured viaorganization_custom_domains. - Partner patient records: Canvas FHIR
PatientwithmanagingOrganizationset to the partner'sOrganization. Clinical data isolation is enforced in our service layer, not by Canvas. - Partner notifications:
notification-servicewith per-org verified senders (fromorganization_notification_config.from_email) and per-org template overrides. - Partner pharmacy routing: Same
pharmacy-router, same policy (GMP primary, Strive fallback), with routing re-evaluated per fill saga. - Partner billing:
commerce-service+payment-servicesupportbilling_plans.organization_idfor per-org pricing overrides.
Migration path
The standalone guide-glp service + DB retires as the final phase (17) of the Canvas-first refactor. For each partner:
- Create an
organizationsrow + CanvasOrganizationresource. - Configure branding, portal flags, notification config, custom domains.
- Onboard partner physicians via
physician_org_memberships. - Migrate partner patients: create Canvas
PatientwithmanagingOrganization+patient_directoryrow. - Migrate in-flight orders to
commerce-service.orderswithcharge_methodreflecting their plan. - Cut the partner over: new intakes land on Canvas-first; old
guide-glpservice stops accepting new writes for them. - Once all partners cut over, delete the
guide-glpservice, repo, and database.
See Refactor Sequence for the full ordered plan.
If you're looking for GuideGLP-specific information
For anything about a specific partner's configuration (Biologics branding, LCMC physicians, Sleep Corner custom domain, etc.), the canonical sources under Canvas-first are:
- Organization state — admin-portal
/all/organizations/{id}/manage(superadmin only). - Partner physician memberships — admin-portal
/org/{slug}/physicians. - Partner custom domain TLS status — admin-portal
/org/{slug}/custom-domains. - Partner branding — admin-portal
/org/{slug}/branding. - Partner pharmacy routing overrides — (if any) Pharmacy Router §per-org routes.
- Partner pricing overrides — commerce-service
billing_planswithorganization_idset.