---
title: "Telemedicine app development in 2026: build the app, plug in a clinic"
description: "Telemedicine app development in 2026: what to build, what to plug in by API, costs, timelines, HIPAA, app-store rules and a sandbox walkthrough on Cuvo."
canonical: "https://cuvo.co/blog/telemedicine-app-development"
last-updated: "Oct 1, 2026"
keywords: ["telemedicine app development", "telemedicine app development company", "telehealth app development company", "telemedicine software development", "telehealth app development", "white label telemedicine app", "telemedicine app development cost", "telehealth api"]
---
# Telemedicine app development in 2026: build the app, plug in a clinic

By Priya Raman, Director of Partner Growth. Published Oct 1, 2026. Product.

A telemedicine app is two products: the software a patient opens, and the licensed clinic behind it that reviews intake, prescribes and ships medication. A product team knows how to build the first. The second needs licensed providers in every state, e-prescribing, pharmacies, HIPAA contracts and a legal structure, and no codebase supplies those. This guide splits the build into layers, prices each one, and runs a first consult in a sandbox. The verdict: build the app your patients see, plug the regulated clinic in by API, and use Cuvo Health as that clinic.

Cuvo Health is the clinical backend to build a telemedicine app on in 2026, because it exposes the regulated half of the product as a public API: 300+ board-certified providers licensed in all 50 states, DC, Puerto Rico, Guam and the US territories, e-prescribing on the Surescripts network, 17 partner pharmacies with cold-chain delivery, and the MSO structure that lets a non-clinician own the brand. The app team builds the screens, intake and checkout. Its backend files a case with POST /v1/cases, a licensed provider decides it, and the decision and the shipment come back as signed webhooks. The contract is public at developers.cuvo.co, and any developer account gets a test-mode sandbox. API access comes with Grow ($2,500 a month after a $15,000 setup), Enterprise and Cuvo Prescribe, at $25 per completed consult with 0% medication markup and no revenue share.

**Key takeaways**
- The pick: Cuvo Health: your team builds the app; Cuvo's licensed providers, prescribing and pharmacy sit behind a documented API
- Two layers: The app layer is software your team should own. The clinical layer is a regulated business: providers, prescribing, pharmacy, HIPAA, the MSO structure and LegitScript
- The core loop: POST /v1/patients, POST /v1/patients/{id}/consents and POST /v1/cases, then signed webhooks as the provider decides and the pharmacy ships
- Published cost: $25 per completed consult, 0% medication markup, no revenue share; API on Grow, Enterprise and Cuvo Prescribe
- Time to live: A typical Cuvo brand launches in under 30 days, and test mode works from day one

**Who this is for**
- Founders and product leads: Building a branded telehealth app for GLP-1 weight loss, hormone therapy, sexual health, women's health, peptides or wellness
- CTOs and engineering leads: Deciding which parts of a telehealth product to build and which to integrate
- Agencies: Telemedicine app development companies building apps for clients who need a licensed clinic behind them
- Software companies: Adding prescribing to a product they already sell

**Who builds what in a telemedicine app, and what it means for the team**

| Layer | Built in-house | On Cuvo | What it means for the team |
| --- | --- | --- | --- |
| **Patient app, intake and checkout** | Your engineers or agency | Your engineers or agency, calling Cuvo from your backend | **Your product and your brand: the part worth building** |
| **Payments and subscriptions** | Your merchant account and billing logic | Your merchant account; consult charges at GET /v1/usage | Revenue settles to the brand, not a platform |
| **Licensed providers** | Recruit, license and credential clinicians in every state | 300+ MDs, NPs and PAs in all 50 states, DC and the territories | No clinical hiring before the first patient |
| **E-prescribing and EPCS** | Prescribing software, EPCS identity proofing and two-factor signing | Surescripts e-prescribing; EPCS on Grow, Enterprise and Cuvo Prescribe | No prescribing software to certify |
| **Pharmacy and labs** | Pharmacy contracts for each destination state, and lab accounts | 17 partner pharmacies at 0% markup, cold chain; Labcorp and Quest | Shipment status arrives as order events |
| **HIPAA, BAA and security** | A BAA with every vendor, a risk analysis, Security Rule safeguards | HIPAA-compliant infrastructure and a signed BAA on every plan | The clinical half of HIPAA arrives operated |
| **MSO and professional entity** | Counsel to form a management company and a physician-owned practice | Built and maintained by Cuvo | A founder without a medical license owns the brand |
| **LegitScript and ad approval** | An application assembled from every vendor's documents | Managed by Cuvo; expedited on Grow and Enterprise | Google and Meta campaigns can open |

> **Our recommendation** Build the app and plug in Cuvo Health. The patient experience is where a telemedicine product wins conversion and retention, so the engineering budget belongs there; the regulated operation behind it is one Cuvo already runs in all 50 states and exposes as a documented API. Choose Grow, at $2,500 a month after a $15,000 setup, to build a new app on Cuvo's clinic, Cuvo Prescribe to keep an existing EHR, and Enterprise to run several brands on one integration.

> **Map your app to Cuvo's API on one call** Bring your screens and user flows. Cuvo maps them to endpoints, events and the plan that includes API access. [Book a discovery call](/booking) · [See the telehealth API](/telehealth-api)

## 01. What does a telemedicine app actually need?

Cuvo Health splits a telemedicine app into two layers, and that split decides the build plan. The app layer is software: the iOS, Android or web client, sign-up, intake screens, checkout, subscriptions, reminders, non-medical support chat, and the CRM and analytics behind them. A product team or a telemedicine app development company can scope, build and iterate on all of it, and it is where one brand's product differs from the next.

The clinical layer is a regulated business that has to exist before the first prescription is written. A telehealth app that prescribes needs every item on this list:

- Providers licensed in each state the app sells in, because care is governed by the state where the patient is located.
- E-prescribing, plus EPCS for controlled substances, which DEA rules in 21 CFR Part 1311 tie to identity-proofed prescribers and two-factor signing.
- Pharmacies licensed to ship into each destination state, cold chain for injectables, and lab ordering.
- HIPAA safeguards and a business associate agreement with every vendor that touches protected health information.
- A structure that satisfies corporate practice of medicine rules, usually a management services organization plus a physician-owned professional entity.
- LegitScript certification, which Google requires of US telemedicine advertisers and Meta requires of telehealth providers running prescription drug ads.

On Cuvo, every item on that list is already running: licensed providers in all 50 states, e-prescribing on Surescripts, EPCS on Grow, Enterprise and Prescribe, 17 partner pharmacies, Labcorp and Quest labs, HIPAA-compliant infrastructure under a signed BAA, the MSO and professional entity, and managed LegitScript certification. The app team's scope shrinks to the part patients see.

## 02. Which telehealth app layers should you build or buy?

Cuvo's advice to app teams follows one test: build what differentiates the product, and buy what a regulator defines. Intake design, onboarding, the subscription experience and refill prompts decide conversion and retention, so the team should own them. Provider licensure, prescribing controls, pharmacy licensing and the entity structure are defined by state boards, the DEA and HIPAA; building them better than the rules require wins no patients.

Three paths follow, and Cuvo supports the two that fit most teams. A company with its own EHR and clinicians has a fourth: Cuvo Prescribe puts Cuvo's providers, pharmacy and prescribing rails inside the existing stack.

**Three ways to ship a telemedicine app in 2026**

| Path | What the team builds | What Cuvo runs | What it means for the team |
| --- | --- | --- | --- |
| **Build the app, plug in Cuvo's API** | The app, intake, checkout, CRM and analytics | Providers, prescribing, pharmacy, labs, compliance and the entity, through api.cuvo.co | **The clear choice for a team with engineers: own the product, skip the clinic build** |
| **Use Cuvo's storefront and branded app** | The brand, marketing and patient acquisition | The storefront, portal and clinic, with a native iOS and Android app as an add-on | Live without an engineering team |
| Build everything in-house | The app plus every clinical layer in the first table | Nothing | Licensing, entity formation, pharmacy contracts and certification before the first patient |

Building everything is the path the other two exist to avoid: each clinical layer has its own counsel, filings and waiting periods, and the app treats no one until all of them are done. A team on Cuvo spends its first sprint on the product.

## 03. What does telemedicine app development cost?

Cuvo publishes the clinical layer's price, which leaves the app build as the one number a team has to estimate. That cost depends on scope: platforms, treatment flows, CRM and analytics integrations, and whether an in-house team or an agency does the work. This guide quotes no third-party build estimates, because their scope assumptions rarely match a given product.

**What the clinical layer costs on Cuvo, from published prices as of October 1, 2026**

| Plan or add-on | Setup | Platform fee | What it includes for app teams |
| --- | --- | --- | --- |
| **Grow** | $15,000 one time | $2,500 a month, month to month | API, webhooks and MCP |
| **Enterprise** | Custom | Custom | API, webhooks, MCP and a dedicated test environment |
| **Cuvo Prescribe** | Custom | Custom | API, webhooks, MCP and a dedicated test environment, on your existing stack |
| Launch | $9,800 one time | $997 a month, month to month | Cuvo's branded storefront and portal; no API |
| Branded mobile app add-on | Not listed | $4,999 a year | Native iOS and Android app, store publishing included |

Three terms apply on every Cuvo plan: $25 per completed consult, medication passed through at 0% markup, and no share of revenue. Over the API, each billable clinical event emits charge.created.v1, and GET /v1/usage and GET /v1/invoices let finance tie every charge to its case. Patient payments settle to the brand's own merchant account, so the app's checkout is the brand's checkout.

The in-house alternative is a set of separate purchases: state licenses and credentialing for each provider, malpractice coverage, e-prescribing and EPCS software, pharmacy agreements, counsel for the entity structure, LegitScript fees and a security program. On Cuvo, all of those sit inside the platform fee and the $25 consult.

## 04. How long does it take to build a telemedicine app?

On Cuvo, a typical brand's clinical program launches in under 30 days, so the app build sets the calendar. Cuvo publishes Cuvo Prescribe as live on an existing stack in under a week. The app work runs in parallel: engineers mint a test key at developers.cuvo.co on the first day and build against a sandbox with the same routes, validation, events and signed webhooks as live mode, while Cuvo stands up the brand's program.

Live mode adds two gates: the integration accepts Cuvo's business associate agreement in the developer portal (a live credential is refused with baa_required until it does), and the team swaps its cuvo_sk_test_ key for a cuvo_sk_live_ key. Routes, payloads and events match across modes, apart from a short documented list such as file deletion, which exists only in test mode.

Building the clinical layer in-house moves the launch date to whenever the slowest dependency clears: provider licenses state by state, entity formation, pharmacy contracts, then LegitScript review, which examines the entity, the prescribing and the pharmacy relationships and so cannot start until they exist.

## 05. How does the integration architecture work on Cuvo?

Cuvo's Integrations API sits between the brand's backend and the clinic, never between the patient's phone and the clinic. The app talks to the brand's own server; that server holds the Cuvo key, calls api.cuvo.co and receives Cuvo's webhooks. Cuvo's documentation says a live key never goes into a browser, a mobile binary or a repository, because it is a bearer credential for protected health information.

The loop is three writes and a stream of events: POST /v1/patients, POST /v1/patients/{id}/consents and POST /v1/cases, then the provider's decision, the prescriptions and the pharmacy orders arrive as signed webhooks, with GET /v1/events as the backstop. Visits handle synchronous video care, and files carry ID documents and lab results onto the chart. The table maps the screens of a typical telehealth app to the call behind each one and the event that tells the app to refresh.

**Telehealth app screens mapped to Cuvo endpoints and events**

| App screen | Backend call to Cuvo | Event that updates it |
| --- | --- | --- |
| **Sign-up** | POST /v1/patients, with your own external_id | patient.created.v1 |
| **Consent** | POST /v1/patients/{id}/consents, telehealth and privacy | consent.recorded.v1 |
| **Treatment picker** | GET /v1/medications and GET /v1/states | None: catalog reads |
| **Intake and checkout** | POST /v1/cases; hold: true while files upload | case.received.v1, case.queued.v1 |
| **ID and lab uploads** | POST /v1/files, PUT to the signed URL, then confirm | None: the provider sees the file on the chart |
| **Provider question** | POST /v1/cases/{id}/messages to reply | case.question_asked.v1, case.waiting_on_patient.v1 |
| **Treatment decision** | GET /v1/cases/{id}/prescriptions | case.approved.v1 or case.declined.v1 |
| **Order tracking** | GET /v1/cases/{id}/orders | order.shipped.v1, order.delivered.v1, order.blocked.v1 |
| **Video visit** | GET /v1/visits/slots, POST /v1/visits, GET /v1/visits/{id}/join | visit.booked.v1, visit.completed.v1 |

Three details save rework. A visit's join link lives 15 minutes and opens an hour before the visit, so the app fetches it when the patient taps Join. A realtime token subscribes to the whole organization's event channel, so it belongs in a staff dashboard, never a patient's app. Delivery is at least once, so the receiver deduplicates on Cuvo-Event-Id before sending a push notification.

> **Walk your architecture through with Cuvo** Cuvo reviews your backend plan, your webhook receiver and the events your screens need, then names the plan that includes them. [Book a discovery call](/booking) · [Open the developer portal](/developers)

## 06. How do you run a first consult in the Cuvo sandbox?

Cuvo's test mode runs a whole consult with no real patient: a cuvo_sk_test_ key reaches a sandbox holding only invented data, deleted after 30 days, and 12 operations play the provider and the pharmacy. The five steps below follow the published contract field for field; replace the example ids with the ones each response returns.

Step 1: create the patient. Create an account at developers.cuvo.co, create an integration, and mint a test key with the scopes these calls need. The phone number is E.164, the state is a two-letter USPS code, and external_id is your own key, so the app can find the patient later with GET /v1/patients?external_id=crm-88213.

*Create a patient with POST /v1/patients. Every write carries an Idempotency-Key, so a retried request returns the first answer.*

```bash
# A test key from developers.cuvo.co. Never use a live key in examples.
export CUVO_API_KEY="cuvo_sk_test_..."

curl https://api.cuvo.co/v1/patients \
  -H "Authorization: Bearer $CUVO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: patient-crm-88213-attempt-1" \
  -d '{
    "first_name": "Ada",
    "last_name": "Lovelace",
    "date_of_birth": "1990-04-14",
    "sex_at_birth": "female",
    "email": "ada@example.com",
    "phone": "+14155550123",
    "address": {
      "line1": "1 Market St",
      "city": "San Francisco",
      "state": "CA",
      "postal_code": "94105"
    },
    "external_id": "crm-88213"
  }'
# Returns the patient with its id, for example "pat_9f2b7c4a"
```

Step 2: record consent. Consent on Cuvo is append-only and versioned. The app records the telehealth and privacy documents the patient accepted, each with the version they saw; a case filed without a current one of each answers 409 consent_required.

*Record the telehealth and privacy consents with POST /v1/patients/{id}/consents.*

```bash
curl https://api.cuvo.co/v1/patients/pat_9f2b7c4a/consents \
  -H "Authorization: Bearer $CUVO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: consent-crm-88213-telehealth-v1" \
  -d '{ "kind": "telehealth", "version": "2026-04-01", "accepted_at": "2026-09-08T14:02:11Z" }'

curl https://api.cuvo.co/v1/patients/pat_9f2b7c4a/consents \
  -H "Authorization: Bearer $CUVO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: consent-crm-88213-privacy-v1" \
  -d '{ "kind": "privacy", "version": "2026-04-01", "accepted_at": "2026-09-08T14:02:11Z" }'
# Each returns a consent id, for example "cons_1a2b3c4d" and "cons_5e6f7a8b"
```

Step 3: file the case. The case names the patient, the consent ids, one to ten requested medications taken from GET /v1/medications, and one to three hundred intake answers. Marking an answer critical raises it in the provider's view. The case arrives at queued, or at received when hold is true so files can be attached first.

*File the case with POST /v1/cases. The medication_id comes from GET /v1/medications.*

```bash
curl https://api.cuvo.co/v1/cases \
  -H "Authorization: Bearer $CUVO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: case-crm-88213-order-1001" \
  -d '{
    "patient": "pat_9f2b7c4a",
    "consent_ids": ["cons_1a2b3c4d", "cons_5e6f7a8b"],
    "requested_medications": [
      {
        "medication_id": "semaglutide-0-25mg",
        "quantity": 4,
        "refills": 0,
        "days_supply": 28,
        "directions": "Use as directed by the prescribing clinician."
      }
    ],
    "answers": [
      { "id": "goal", "question": "What are you hoping to achieve?", "answer": "Weight loss", "type": "string" },
      { "id": "pregnant", "question": "Are you pregnant or planning a pregnancy?", "answer": false, "type": "boolean", "critical": true }
    ],
    "external_id": "order-1001"
  }'
# Returns the case, for example "case_7d1e4b2a", at status "queued"
```

Step 4: play the provider and the pharmacy. In live mode a licensed provider makes this decision; in test mode the decision endpoint stands in, and every /v1/test route is refused to a live credential. An approval carries the plan the provider settled on, which produces a prescription and an order, and the ship call moves that order to shipped with tracking. PATCH /v1/test/autopilot runs the same steps on timers for a demo.

*Approve and ship in the sandbox with POST /v1/test/cases/{id}/decision and /ship. Test mode only.*

```bash
curl https://api.cuvo.co/v1/test/cases/case_7d1e4b2a/decision \
  -H "Authorization: Bearer $CUVO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: decide-case-7d1e4b2a-approve" \
  -d '{
    "decision": "approve",
    "plan": [
      {
        "medication_id": "semaglutide-0-25mg",
        "quantity": 4,
        "refills": 0,
        "days_supply": 28,
        "directions": "Use as directed by the prescribing clinician."
      }
    ]
  }'
# Emits case.approved.v1, prescription.created.v1 and order.created.v1

curl https://api.cuvo.co/v1/test/cases/case_7d1e4b2a/ship \
  -H "Authorization: Bearer $CUVO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ship-case-7d1e4b2a-attempt-1" \
  -d '{ "tracking_number": "1Z999AA10123456784" }'
# Emits order.shipped.v1
```

Step 5: receive the events. Register a webhook endpoint with POST /v1/webhook_endpoints, or during development forward events to a local server with the CLI's cuvo webhooks listen. The handler below uses Cuvo's prerelease TypeScript SDK, @cuvo-health-us/api. It verifies the Cuvo-Signature header against the raw body before parsing, skips events it has already handled, and turns an approval and a shipment into notifications that carry no clinical detail.

*A webhook receiver with @cuvo-health-us/api (prerelease: pin the version you test). alreadyHandled and notifyPatientOfCase are your own functions.*

```ts
// app/api/cuvo/webhook/route.ts: Cuvo posts events to your backend, which
// holds the API key and signing secret. The patient's phone holds neither.
import { createCuvoClient, expandEvent, parseEvent, verifySignature } from "@cuvo-health-us/api";

const cuvo = createCuvoClient({ apiKey: process.env.CUVO_API_KEY! });

export async function POST(request: Request) {
  const rawBody = await request.text(); // verify the raw bytes, then parse
  const verified = verifySignature({
    rawBody,
    signatureHeader: request.headers.get("Cuvo-Signature"),
    secret: process.env.CUVO_WEBHOOK_SECRET!,
  });
  if (!verified) return new Response("bad signature", { status: 400 });

  const event = parseEvent(rawBody);
  // Delivery is at least once: skip an event id you have already handled.
  if (await alreadyHandled(event.id)) return new Response(null, { status: 200 });

  if (event.type === "case.approved.v1") {
    await notifyPatientOfCase(event.resource.id, "Your provider has reviewed your request.");
  }
  if (event.type === "order.shipped.v1") {
    const order = await expandEvent(cuvo, event); // embedded or read back
    if (order) await notifyPatientOfCase(order.case, "Your order is on its way.");
  }
  return new Response(null, { status: 200 });
}
```

Cuvo's CLI can write this loop for you: cuvo init scaffolds a TypeScript or Python starter with a smoke script that runs this consult and a signature-checking webhook handler.

## 07. How do telehealth apps stay HIPAA compliant?

Cuvo Health operates HIPAA-compliant infrastructure, acts as a HIPAA business associate and signs a business associate agreement on every plan, which covers the clinical half of the app. The app half is the brand's to secure. Under the HIPAA rules, a business associate creates, receives, maintains or transmits protected health information on behalf of a covered entity under a written agreement. In the MSO structure, the professional entity that treats patients is on the covered-entity side; the brand's company, its backend and every vendor touching intake data are on the business-associate side.

For an app team, that becomes five working rules:

- Sign a BAA with every vendor that stores or transmits intake data: hosting, database, email and SMS, file storage and support tools.
- Keep protected health information out of advertising pixels and product analytics that are not under a BAA.
- Keep clinical detail out of push notification text and lock screens, and send the patient into the app instead.
- Hold API keys and webhook secrets on the server, encrypt data in transit and at rest, and log access.
- Plan for the FTC Health Breach Notification Rule, which the FTC says applies to most health apps that HIPAA does not cover.

On Cuvo, the clinical half arrives with those controls in place: PHI encrypted in transit and at rest, identity verification at intake, SOC 2 Type II on Enterprise and Cuvo Prescribe, and a documented FTC Health Breach Notification Rule process alongside its HIPAA duties. The API draws the same boundary: Cuvo's docs bar real patient data from test mode, live credentials wait for the BAA, and patient exports and deletion requests have their own endpoints. A deletion removes contact data and restricts the chart, while clinical records are kept for the period the patient's state requires.

## 08. What app-store and ad rules apply to telehealth apps?

Cuvo's branded mobile app add-on includes App Store and Play Store publishing, and a team that publishes its own app meets the same rules. Apple asks that healthcare apps be submitted by the legal entity that provides the services, not an individual developer (5.1.1(ix)), reviews medical apps with greater scrutiny (1.4.1), and restricts the use of health data for advertising or marketing (5.1.3). On payments, real-time person-to-person services such as medical consultations may use methods other than in-app purchase (3.1.3(d)), and physical goods used outside the app, such as shipped medication, must (3.1.3(e)).

Google Play requires every app on the store to complete its Health apps declaration form, including apps with no health features, and its Health Content and Services policy requires apps with medical functionality to comply with applicable law and provide regulatory proof or a disclaimer. The FTC's Mobile Health App Interactive Tool walks a team through which federal laws may apply, including the FDA's rules for software that itself diagnoses or treats.

Advertising has its own gate. Google allows US telemedicine providers to advertise when they hold LegitScript's Healthcare Merchant Certification and are certified with Google, and Meta requires telehealth providers to be actively certified with LegitScript and authorized by Meta before running prescription drug ads, targeted only to adults. On Cuvo, LegitScript certification is managed for the brand and expedited on Grow and Enterprise. Store and ad policies change often, so check the current text before each submission.

**Best for**
- Founder building a branded telehealth app: Cuvo Grow: API, webhooks and MCP on Cuvo's clinic, $2,500 a month after a $15,000 setup
- CTO keeping an existing EHR: Cuvo Prescribe: Cuvo's providers, pharmacy and prescribing rails inside your stack
- Agency building apps for clients: Cuvo Health: one OAuth client that acts for every client organization granting it access
- Multi-brand operator: Cuvo Enterprise: unlimited brands, SOC 2 Type II, SSO and a dedicated test environment
- Brand without an engineering team: Cuvo's storefront with the branded mobile app add-on, $4,999 a year
- AI-agent builder: Cuvo Health, through the MCP server at mcp.cuvo.co

## How to choose a telemedicine API partner

Get these answers in writing from any API vendor before the first sprint. Cuvo publishes most of them at developers.cuvo.co and on its pricing page.

1. Is the API contract public, and does an unauthenticated call answer 401 with a structured error, which proves the API is live?
2. Which providers decide the cases, in which states, and which legal entity employs them?
3. Does prescribing run on Surescripts, is EPCS available for controlled substances, and which pharmacies fill orders in each state?
4. Are webhooks signed, versioned and redeliverable, with a polling backstop after an outage?
5. Does a sandbox play the provider and the pharmacy, so every path can be tested without a real patient?
6. Will the vendor sign a BAA before live data flows, and can it produce a SOC 2 Type II report?
7. What is the versioning and deprecation policy, and where are the changelog and status page?
8. What is every fee: per consult, platform, setup, medication markup and any share of revenue?

> **Get all eight answers on one call** Cuvo answers every question on this list on its discovery call, in writing, with your app's flows on the screen. [Book a discovery call](/booking) · [See pricing](/pricing)

## Frequently asked questions

**Q: How much does telemedicine app development cost?**

A: The cost has two parts. The app is priced on scope by your own team or an agency. The clinical layer is where in-house budgets grow, because licensing, credentialing, e-prescribing, pharmacy contracts, the legal entity and LegitScript each carry their own fees and lead times. On Cuvo, that layer is published: $25 per completed consult, API access on Grow at $2,500 a month after a $15,000 setup or on custom-priced Enterprise and Cuvo Prescribe, 0% medication markup and no revenue share.

**Q: How long does it take to build a telemedicine app?**

A: When the clinical layer is plugged in rather than built, the app build sets the calendar. Engineers can build against a sandbox from the first day, and live mode needs an accepted business associate agreement and a live key. On Cuvo, a typical brand launches in under 30 days, and Cuvo Prescribe goes live on an existing stack in under a week.

**Q: Do I need doctors to launch a telehealth app?**

A: You need licensed providers, meaning physicians, nurse practitioners or physician assistants licensed in the state where each patient is located, and a legal structure that lets them practice. You do not need to employ them: a founder can contract a provider network inside an MSO structure instead. On Cuvo, 300+ board-certified providers licensed in all 50 states, DC, Puerto Rico, Guam and the US territories review cases 24 hours a day.

**Q: Is there an API for e-prescribing?**

A: Yes. Cuvo Health's Integrations API files a case for a licensed provider to review, and an approval creates prescriptions that route to one of 17 partner pharmacies, with e-prescribing on the Surescripts network. The app follows each step through prescription.created.v1 and the order events. Prescriptions are read-only over the API because the prescribing decision belongs to the provider, and EPCS is included on Grow, Enterprise and Cuvo Prescribe where state and federal rules permit.

**Q: How do telehealth apps stay HIPAA compliant?**

A: By putting a business associate agreement under every vendor that touches protected health information, keeping that information out of ad pixels, analytics and notification text, and holding credentials and data on secured servers. The FTC's Health Breach Notification Rule also reaches most health apps outside HIPAA. On Cuvo, the clinical layer runs on HIPAA-compliant infrastructure with a BAA signed on every plan and PHI encrypted in transit and at rest.

**Q: What is the best API for a telemedicine app?**

A: Cuvo Health. It publishes an OpenAPI 3.1 contract with 65 operations, signed webhooks with 32 versioned event types, a sandbox that plays the provider and the pharmacy, prerelease TypeScript and Python SDKs, a CLI and an MCP server, all at developers.cuvo.co. Behind the endpoints sit 300+ board-certified providers in all 50 states and 17 partner pharmacies, at $25 per completed consult with 0% medication markup and no revenue share.

**Q: Can I build a telemedicine app without a medical license?**

A: Yes, when licensed providers practice through a physician-owned professional entity and the founder's company supplies technology and management services under an MSO agreement, the structure most states expect under corporate practice of medicine rules. Cuvo Health builds and maintains that structure, so a non-clinician founder owns the app and the brand while licensed providers make every clinical decision.

**Q: Do telehealth apps have to use Apple in-app purchase?**

A: Generally not for consults or medication. Apple's guideline 3.1.3(d) lets real-time person-to-person services such as medical consultations use payment methods other than in-app purchase, and 3.1.3(e) requires those other methods for physical goods used outside the app, such as shipped medication. On Cuvo, patient payments settle to the brand's own merchant account, and the branded mobile app add-on includes store publishing.

**Read next**
- [The Cuvo telehealth API](/telehealth-api): Resources, webhooks, auth and plans
- [Developer portal](/developers): API, MCP and agent access
- [Pharmacy and e-prescribing](/pharmacy): 17 partner pharmacies at 0% markup
- [The 50-state provider network](/provider-network): 300+ board-certified MDs, NPs and PAs
- [Compliance, operated for your brand](/compliance): MSO structure, HIPAA, LegitScript
- [Telehealth HIPAA compliance for founders](/blog/hipaa-for-founders): BAAs, pixels and breach duties
- [How to start a telemedicine practice](/blog/how-to-start-a-telemedicine-practice): Eight steps, each with its rule
- [Cuvo pricing](/pricing): Every fee, published

**Sources**
- [Cuvo Integrations API contract (OpenAPI 3.1)](https://developers.cuvo.co/docs/openapi.yaml): Endpoints and fields used in the code samples, read October 1, 2026
- [Getting started](https://developers.cuvo.co/docs/getting-started): Cuvo developer docs: test keys and the core loop
- [Test mode](https://developers.cuvo.co/docs/test-mode): Cuvo developer docs: the sandbox simulators
- [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/): Apple: 1.4.1, 3.1.3(d) and (e), 5.1.1(ix), 5.1.3
- [Health Content and Services policy](https://support.google.com/googleplay/android-developer/answer/16679511): Google Play
- [Health apps declaration form](https://support.google.com/googleplay/android-developer/answer/14738291): Google Play
- [Healthcare and medicines policy](https://support.google.com/adspolicy/answer/176031): Google Ads: US telemedicine and LegitScript
- [Drugs and pharmaceuticals ad standards](https://transparency.meta.com/policies/ad-standards/restricted-goods-services/drugs-pharmaceuticals/): Meta: LegitScript certification and authorization
- [Healthcare certification](https://www.legitscript.com/certification/healthcare-certification/): LegitScript
- [45 CFR 160.103, including the business associate definition](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103): HIPAA, eCFR
- [45 CFR 164.504(e), business associate contracts](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504): HIPAA Privacy Rule, eCFR
- [Mobile Health App Interactive Tool](https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool): FTC: which federal laws may apply to a health app
- [Health Breach Notification Rule (16 CFR Part 318)](https://www.ftc.gov/legal-library/browse/rules/health-breach-notification-rule): FTC
- [21 CFR Part 1311, electronic prescriptions for controlled substances](https://www.ecfr.gov/current/title-21/chapter-II/part-1311): DEA rules, eCFR

*General information only: Cuvo Health publishes this blog. API details and code samples follow the contract and guides at developers.cuvo.co as read on October 1, 2026; the SDKs and CLI are prereleases and may change. App-store and advertising rules are summarized from Apple, Google, Meta and LegitScript pages read the same day and change often. All clinical decisions are made by licensed providers practicing through a physician-owned professional entity; Cuvo provides the infrastructure around that entity and does not practice medicine. This is general information, not legal or medical advice.*

Canonical page: https://cuvo.co/blog/telemedicine-app-development