Building on Lithos, Part 2: adding prescriptions to an existing app

What you are actually adding

Behind the button is a licensed physician network with multi-state licensure, protocols for each treatment, AI-prepared consultations, e-prescribing and pharmacy routing, and a stack of rules about consent, identity, privacy, and which treatments may be handled asynchronously where. You are not building any of that. You are adding a surface in your product where a user can request care under the protocol configured for your program, and reacting to what the clinician decides. The architecture post explains the layers; this one is the integration.

The path, step by step

1. Configure the program. At onboarding, clinical protocol configuration sets the treatments providers may prescribe for your users, the required intake_data keys for each encounter type, and the states you open first. Every tier covers all 50 states; you choose where to market.
2. Map your user to a patient. When a user starts, create a Lithos patient with your user ID as external_id, their demographics and address, and the telehealth_consented_at timestamp your flow captured. This is the record everything else hangs on; it is created once, and a duplicate external_id is rejected so you cannot create the same user twice.
3. Run intake in your UI. Render your program’s intake in your design system. Validate inline for experience; the API validates intake_data again against your configured keys so incomplete cases never reach a physician. Our intake design guide covers the anatomy.
4. Submit the encounter. Create an initial encounter with the patient id and intake_data. Lithos prepares it — intake, assessment, clinical summary — and routes it to a licensed physician in the user’s state; the first encounter also sets the patient’s assigned clinician for continuity.
5. React to the decision. The physician approves or rejects, or the encounter pauses as escalated when more information is needed; you learn which over a webhook, fetch the encounter, and update the user’s screen. Approvals produce prescriptions and a pharmacy order automatically.
6. Show the order. Order status — created, processing, completed — arrives as webhooks, with the fulfilling pharmacy on the order. “Where is my medication” becomes a screen in your app rather than a support ticket.
7. Run renewals as check-ins. When a refill is due, collect the protocol’s follow-up in your app and submit a follow_up encounter. The record already holds the history; the check-in asks what changed, and each prescription’s days_supply tells you when the next one is due.

# 1 — once per user
POST /v1/patients
{ "external_id": "usr_1042", "first_name": "…", "last_name": "…", "date_of_birth": "…", "sex": "…",
  "address": { "line1": "…", "city": "…", "state": "TX", "postal_code": "…" },
  "email": "…", "phone": "+1…", "telehealth_consented_at": "2026-09-23T14:02:00Z" }

# 2 — per request (renewals use "encounter_type": "follow_up")
POST /v1/encounters
{ "patient_id": "pat_test_…", "encounter_type": "initial", "intake_data": { …your configured keys… } }

# 3 — your webhook handler (thin payload → GET the resource)
# encounter.approved → GET /v1/encounters/{id}: show the decision, read prescriptions[].days_supply
# order.completed    → GET /v1/orders/{id}: confirm, schedule the follow-up

Design the boundaries

The integration is a few weeks of engineering. The design decisions around it are what make the feature lawful and trusted.

• Say who decides. Users must understand that a licensed clinician reviews their request and may decline it, and that they are entering a telehealth relationship. Disclosures, consent language, and the clinician’s identity on the prescription are not optional and should read as reassurance, not fine print.
• Separate care from product. Price the medical program on its own line — a subscription or per-visit fee — distinct from your app, your merchandise, or your supplements. It keeps billing honest and keeps you clear of fee-splitting and kickback concerns; see anti-kickback rules for telehealth marketing.
• Fix the marketing stack. Pages and screens that handle health information cannot carry advertising pixels. Decide which surfaces are “health” before launch; see HIPAA and your marketing stack.
• Draw the data line. Keep protected health information on Lithos under its BAA. Your database holds the external ID, the care-plan status, and what your product needs to render — not the chart. If you do hold PHI, you need a BAA and the controls that come with it.
• Handle the no. Some users will be declined or routed to a live visit. Design that screen with the same care as the yes: what happened, what the options are, who to contact.

Business model

Most embedded programs run a monthly care subscription that covers clinician review, renewals, and support, with medication either included or billed at pharmacy cost. The two questions to settle early are refunds — what happens when a clinician declines after the user paid — and pauses, which are common in weight and hormone programs. Our guides to pricing GLP-1 subscriptions and refunds and chargebacks cover both; the short version is to charge for care at decision time, not at intake.

Timeline

After a working session and a tailored proposal, technical kickoff issues API access and sandbox credentials. Weeks one and two are intake and webhooks in your app, tested end to end. Weeks three and four are first real users in the states you open, then the rest at your pace. The week-by-week plan in the launch timeline applies with one difference: you already have the users.

Frequently asked questions