Telehealth analytics and reporting: what OrbitOS shows your brand

Operational reporting in real time

Uptime, latency and queue health are visible live.

• Queue health shows the work waiting for a provider and how long it has waited.
• Visits and provider response sit alongside, so you can see whether the under-six-minute average business-hours response the network is built for is holding on your programs today.
• Operators use this view the way an e-commerce team uses a store-status page: a glance in the morning and a second look after any campaign that drives a spike of intakes.

Revenue and retention reporting per brand

The business view is scoped to your tenant.

• It covers the storefront subscriptions your patients hold, prescriptions dispensed, refill activity and retention over time.
• Because your brand is merchant of record and revenue settles to your own processor, OrbitOS reports the clinical and fulfillment side of revenue, which you reconcile against your processor for cash.
• That pairing, dispensed prescriptions on one side and settled charges on the other, is the most useful reconciliation in a telehealth business and the one most brands skip.

The HIPAA audit trail

Every record view, every edit, every prescription event and every export is logged with who, what and when.

The audit trail is not a report you read daily, but it is the one that answers the questions a compliance reviewer, a LegitScript auditor or a patient's attorney will eventually ask. It also lets you investigate your own operations: who approved a refill, when the pharmacy dispensed it, and whether a support agent opened a record they had no reason to open.

What it is not

OrbitOS is a clinical console with reporting, not a marketing analytics suite.

• It does not run ad attribution, it does not model lifetime value from a template and it does not forecast.
• Those are jobs for the tools your growth team already uses, fed by event data from the platform.
• Keeping the two apart is also what keeps PHI out of your ad stack.

Intake completion

The share of people who start Orbit Intake and finish it.

• Because the intake adapts to each answer and escalates red flags, a low completion rate usually points to one of three things: the questions are landing in the wrong order for your audience, the storefront is sending unqualified traffic, or the checkout step before intake is asking for payment too early.
• Watch completion by acquisition channel.
• Paid social often fills the top of the funnel with people who were never going to qualify.

Provider approval rate

The share of completed intakes a provider approves for treatment.

• This is a clinical outcome, not a marketing target, and you should not try to push it up.
• Read it as a signal about qualification: a falling approval rate after a new campaign means the campaign is attracting people the program is not for.
• Pair it with time to provider decision, which tells you whether the queue is the bottleneck or the clinical criteria are.

Time to first shipment

Days from approval to the pharmacy's prescription.dispensed event, and from there to delivery.

• The first shipment is the moment the patient decides whether this brand is real.
• Delays here come from pharmacy routing, cold-chain logistics, a payment that failed silently or a prescription that needed a clarification.
• OrbitOS shows the clinical and dispensing timestamps; your carrier data closes the loop to the door.

Refill rate and check-in completion

Every refill on MyOrbitHealth passes through a patient check-in and a provider review before the storefront rebills and OrbitRx routes to the pharmacy.

• So the refill funnel has its own stages: check-in sent, check-in completed, provider decision, rebill cleared, dispensed.
• Refill rate is the end-to-end number.
• Check-in completion is the leading indicator.
• A patient who does not complete the check-in is telling you something a week before the churn shows up in revenue.

Support load

Tickets per hundred active patients, tagged by cause: shipping, billing, portal access, clinical question routed to a provider.

• Support volume rises before churn does, and the tag mix tells you which team owns the fix.
• Shipping tickets point at fulfillment.
• Billing tickets point at your rebill messaging and your processor's retry schedule.
• Clinical questions arriving at your support desk mean patients have not found the provider messaging in the portal, which is a product and onboarding problem, not a staffing one.

Reading the stages together

Describe each stage as a share of the cohort that entered the one before it, cohorted by start month and program.

• Look for the single largest drop, fix that, then re-measure.
• Resist the urge to build a wall of charts on day one.
• Five numbers, reviewed weekly, moved more than a dashboard of fifty ever has.

Role-based access

Roles separate clinical access from business access, and the lines are configured per brand.

• In a typical configuration a provider sees the patients and encounters assigned to them.
• A clinical operations lead sees queue and encounter state across the brand.
• A founder or finance lead sees revenue and retention reporting without opening individual charts.
• A support agent sees what they need to resolve a ticket and nothing more.
• Roles are the mechanism that turns the HIPAA minimum-necessary principle into something your team does by default rather than by remembering.

Multi-tenant per brand

Each brand is a tenant with its own patients, providers, storefront configuration and reporting.

• The network's providers may serve more than one brand, but a provider working inside your tenant sees your patients only.
• Reporting is likewise scoped: your retention cohort is your patients, your revenue view is your storefront, and no cross-brand aggregate is exposed to any tenant.
• If you run several brands, each has its own tenant and its own numbers.

Audit covers the reporting too

Running a report, exporting a dataset or changing a role is itself an audited event.

That matters when you grant a contractor or an agency temporary access: you can see what they looked at and what they pulled. It also means access reviews are a query, not a guess.

PHI stays in the clinical console

Names, dates of birth, medications, diagnoses, lab values and messages live in OrbitOS, which is HIPAA compliant with a BAA in every contract, SOC 2 Type II, HITRUST-aligned and encrypted in US regions.

Your team works with that data inside the console under role-based access. When you need the same facts in a spreadsheet, the export is yours to run and the export is logged.

Event-level and de-identified data leave through the API

What reaches your CRM, warehouse or BI tool should be shaped for the job.

• An event such as prescription.dispensed carries an opaque patient identifier, the event type and a timestamp.
• Your warehouse can hold the mapping back to a person only if the warehouse is under a BAA; otherwise keep the mapping inside OrbitOS and join on the identifier only when you need to act.
• Aggregated reporting, counts by stage and cohort, carries no PHI at all and can go anywhere.
• Design the pipeline so the least sensitive representation that answers the question is the one that leaves the platform.

No ad pixels or tracking scripts on PHI pages

Do not load ad pixels, session recorders or third-party analytics SDKs in the patient portal, the native app, the intake flow or any page a patient reaches after authenticating, unless that vendor has signed a BAA and you have confirmed what it collects.

• The federal regulators responsible for HIPAA have published guidance on online tracking technologies used by regulated entities, parts of which have been litigated, so read the current version with counsel.
• The practical posture has not changed with the litigation: a pixel that sees a patient's identity next to a program name is a disclosure, and most ad vendors will not sign a BAA.
• Keep marketing analytics on the public storefront, and keep the storefront free of health details tied to an identifiable visitor.

Transactional email and URL parameters

A shipment-confirmation email with the medication in the subject line, or a link that carries the program name in a tracking parameter, moves PHI into your email vendor's logs and your analytics tool.

Write transactional messages generically, point patients to the portal for detail and strip tracking parameters from links that lead to authenticated pages. The MyOrbitHealth guide to HIPAA for founders at /blog/hipaa-for-founders covers the BAA and vendor questions in more depth.

Webhooks for streaming events

Register an endpoint and MyOrbitHealth sends signed events, including appointment.completed and prescription.dispensed.

Verify the signature, write the event to your warehouse, and your funnel tables update in near real time. This is the right source for stage timestamps: time to first shipment, time from check-in to provider decision and refill intervals all come from event timestamps rather than from a nightly snapshot.

The REST API for scheduled pulls

The product API at api.myorbithealth.com/v1 uses bearer-token auth with test and live environment-scoped keys, path versioning, documented endpoints for patients, appointments, prescriptions and webhook registration, and X-RateLimit headers at 600 requests per minute per key with burst to 1,200.

• Errors come back as a JSON object with a code, a message and details.
• A nightly job that pulls prescriptions and appointments and upserts them into your warehouse is a few hours of engineering, and a sandbox is provisioned within a day after a short partner review.
• Documentation lives at /api-docs and /telehealth-api.

Bring the BI tool you already use

MyOrbitHealth does not bundle or name a third-party dashboard product.

• Point whatever your team already runs at the warehouse table the webhooks and API fill.
• The only constraint is the one above: if the tool will see PHI, it needs a BAA; if it sees only events and counts, it does not.
• Most brands end up with two layers, a PHI-safe operational view inside OrbitOS and an aggregated business view in their own BI tool, and that split is a feature, not a limitation.

Export on the way out

Contracts run month-to-month after onboarding with no exit or termination fee, and your data is exportable at any time.

If you ever migrate, you leave with your patients, records and history. That is also why we recommend building your warehouse from day one rather than treating OrbitOS as the system of record for business analytics: your numbers should live where you control the schema.

No published benchmarks

We do not publish conversion, retention or revenue benchmarks across brands.

The numbers differ too much by vertical, price point, state mix and acquisition channel to be useful as a comparison, and publishing them would mean aggregating across tenants in a way our multi-tenant model deliberately avoids. Measure your own cohort against your own earlier cohorts.

No AI business-intelligence add-on

There is no paid layer that narrates your dashboard or predicts churn for you.

The platform's AI sits in Orbit Intake, where it adapts questions, scores severity and escalates red flags under provider oversight. If you want modeling on your business data, run it on your own warehouse with your own tools, where you control what the model sees.

No named third-party dashboards

We do not ship a bundled connector to a specific BI product or CRM.

The reason is practical: brands arrive with tools they already know, and a webhook plus a documented API fits all of them. If your engineering team wants a reference pattern, the API docs show the auth, endpoints, error shape and event names to build from.

No cash reporting

Because you are merchant of record and revenue settles to your own processor, OrbitOS does not see settled cash, refunds or chargebacks.

It reports what was prescribed, dispensed and subscribed. Reconcile the two sides in your warehouse; the join key is your order or subscription identifier.