Every condition is a different signal.
One backend reads all of them.
Cuffs, cameras, inhalers, CGMs, questionnaires — normalized onto one timeline and scored against the 2026 rules, so every day is either billable or context.
I run a clinic
Stand up a monitoring program for a specific condition. Device kits, thresholds, escalation owners, and a claim line that will survive an audit. Live in days, not quarters.
Start a program Track BI am building on it
Use Gathermed as the backend for your own monitoring product. Ingest, normalization, thresholds, audit, and billing logic behind your API and your brand.
See the architecture
Thirty cells decide whether the month is paid.
Whether sixteen of them are filled, or two, or none, determines which code you bill and whether the month is paid at all. Most platforms hide that behind a dashboard. We put it in the front door, because it is the number your program lives on.
The measurement is not the product. The decision is.
Hardware companies sell you a sensor and hand you a portal. Six sensors later you have six portals, six adherence definitions, and no single answer to the only question that matters: is this patient getting better, and did anyone act when they were not.
Any source, one schema
Aggregator APIs for the consumer and connected-device long tail. Direct manufacturer interfaces for PAP, CGM, and inhaler sensors. HL7v2 and FHIR for lab and EHR context. Camera-derived measurement where no sensor exists, which is most of neurology and most of rehabilitation.
Billable or context, labeled
Every source is tagged at ingest. A cleared cuff can support a device-supply line. A smartwatch notification cannot. The platform enforces that distinction rather than leaving it to whoever is closing the month, which is where audit findings come from.
Thresholds with owners and clocks
Every threshold routes to a named clinician with a response clock and a recorded disposition. Alerts into a shared inbox are how monitoring programs fail clinically and how they fail audits. Both failures have the same root cause.
Code selection by counter, not by hope
The transmission counter picks the device code. The timer picks the management code. Mutually exclusive pairs are enforced. RPM and RTM cannot both fire in a calendar month for the same patient, and the platform refuses rather than warns.
An audit trail built before the audit
Who was enrolled, on whose order, against which diagnosis, with which device, transmitting how many days, reviewed by whom, for how long, with which interactive communication. Exportable as a defense packet per patient per month.
Your product, our plumbing
The same engine runs behind an API with per-tenant isolation and your own brand on the patient app. If you are a sponsor or a digital health team, you do not need to rebuild ingest, normalization, and billing logic. See the architecture.
Everything orbits the same backend.
The transmitted day is the unit of truth
Sixteen filled cells decide whether the month is billable at all — so the grid sits at the front door, nudges go out in the patient's language, and a quiet device becomes a phone call on day nine, not a write-off on day thirty-one.
A fleet you control, per serial
Cellular first, so there is no app to fail. Bind, transmit, unbind, wipe, re-kit, rebind — the passport travels with the hardware, attribution follows the binding window, and the cuff outlives the episode.
Built for the panel you actually have
No-smartphone kits, materials and check-ins in the patient's language, accessible variants as first-class kit decisions, and a stratified funnel that shows who the program reaches — and who it is missing.
Named owners on real clocks
Escalation pods, titration protocols, response clocks, and audit-ready documentation. Staffing designs that survive OIG attention — with our clinical operations team alongside yours from enrollment day.
18 conditions, each with its own signal stack
Not one generic program with a condition dropdown. Each of these has its own device stack, its own thresholds, its own escalation design, its own code path, and its own honest note about where the evidence or the reimbursement is thin.
If you are a sponsor, the honest version is worth reading
Pharmaceutical manufacturers cannot bill RPM or RTM. Those codes belong to treating practitioners. Any vendor telling you about your remote monitoring revenue line is selling you something that does not exist.
What does exist is more interesting. Your therapy has a persistence problem, a tolerability problem, or a titration-inertia problem, and none of them are visible in claims until months after the patient has already quit. Daily-resolution measurement of the interval between prescription and discontinuation is a real evidence asset, a real payer-negotiation asset, and in several categories a real clinical benefit.
It also sits inside a fraud and abuse framework that has teeth. Subsidizing a service that generates billable revenue for prescribers is remuneration to referral sources, and the Office of Inspector General has been publishing on remote monitoring specifically since 2023. We will walk you through the structures that work and the ones that do not before we quote you anything.
The structural constraint, stated plainly
A sponsor-funded program in which prescribers receive free or below-cost monitoring services that they then bill to Medicare implicates the federal Anti-Kickback Statute. The defensible structures separate the sponsor's data interest from the provider's billing interest entirely. Get counsel before the first dollar moves, not after.
What a sponsor actually buys
Multi-tenant infrastructure with per-tenant isolation, your brand on the patient application, consented data flows scoped at the field level, condition-specific instruments that already exist, and an audit posture that will survive diligence. Not a revenue share on someone else's claims.
Pick a condition. See the whole program.
Device stack, thresholds, escalation design, code path, and the parts we would not put on a sales slide.