Synchronous, Asynchronous, and Remote Patient Monitoring — Three Products, Three Architectures

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you are scoping a telemedicine product, the first architecture decision is not which video vendor to pick — it is which of the three modalities you are actually building, because each one points at a different pipeline, a different cost center, and a different page of the Medicare rulebook. Founders routinely pitch "a telehealth app" that quietly contains all three, then budget for one. This article gives you the taxonomy that every later article in this course leans on: what each modality is, what its architecture looks like, what it costs, and which billing rules become engineering requirements. It builds on what telemedicine, telehealth, and digital health actually mean and on why telemedicine video is harder than a normal video call.

Three modalities, three clocks

The cleanest way to separate the three is by their clock — how much time passes between the patient producing clinical information and the clinician acting on it.

Synchronous telemedicine is a live conversation: patient and clinician are present at the same time, connected by real-time video or audio. The clock runs in milliseconds; if the two sides drift more than a fraction of a second apart, conversation breaks down. A scheduled video consult, a virtual urgent-care visit, and a tele-stroke assessment are all synchronous. Think of it as a phone call that happens to carry a clinical encounter.

Asynchronous telemedicine — the regulatory term is store-and-forward — decouples the two sides. The patient (or a clinician at another site) captures information now: photos of a skin lesion, an intake questionnaire, a short video of a child's breathing. The system stores it, and a clinician reviews it hours or days later, sending back a diagnosis or treatment plan. Medicare's regulation defines it as the transmission of medical information reviewed at a later time, and is strict about the format: a phone call, a fax, or a text message without visualization of the patient does not qualify, while a dermatological photograph adequate for diagnosis does (42 CFR §410.78(a)(1)) [1]. Think of certified mail carrying photographs to a specialist, with the reply guaranteed by a deadline.

Remote patient monitoring (RPM) removes the encounter entirely. A device in the patient's home — a blood-pressure cuff, a glucose meter, a pulse oximeter, a connected scale — takes readings on a schedule and transmits them automatically to the care team's system, which watches the stream for trends and anomalies. No appointment exists; the product is a pipeline that never closes. Think of a smoke detector wired to the fire department rather than a yearly fire inspection.

Figure 1. The defining variable is the clock: milliseconds for a conversation, hours for a review queue, continuous for a monitoring pipeline.

A fourth word you will meet — hybrid telehealth — is not a fourth modality. It is a product that deliberately combines the three: an asynchronous intake that escalates to a live visit, or a monitoring program with scheduled video check-ins. We return to hybrids at the end, because they are where most real products land.

Synchronous: the conversation architecture

A synchronous product is built around one job: keep two (or more) people in a natural conversation while the network does its worst. The architecture is the real-time stack this course's Block 3 covers in depth — the browser standard for real-time media called WebRTC, a signaling service that sets the call up, relay servers (called TURN) for networks that block direct connections, and a media server (called an SFU) once more than two people join. The protocol internals live in the Video Streaming section's WebRTC explainer; here, what matters is the shape: media flows continuously in both directions, and every component sits in the latency budget.

That budget is unforgiving. The international standard for voice transmission, ITU-T Recommendation G.114, advises keeping one-way delay under 150 milliseconds for natural conversation and treats 400 ms as the planning ceiling beyond which interactivity degrades [2]. In practice a telemedicine call targets a few hundred milliseconds glass-to-glass — from the patient's camera to the clinician's screen. Nothing in the pipeline may "think it over": no batch step, no queue, no overnight job. Reliability engineering, not features, is where the budget goes, because a dropped clinical call is an adverse event, not an annoyance.

The regulatory frame matches the architecture. Under Medicare, "telehealth" in the statutory sense — Social Security Act §1834(m), implemented at 42 CFR §410.78 — means a service furnished through an interactive telecommunications system: at minimum, audio and video equipment permitting two-way, real-time interactive communication (42 CFR §410.78(a)(3)) [1]. Real-time is in the definition. Audio-only is allowed for a patient at home, but only if the practitioner is technically capable of video and the patient cannot use it or does not consent — and the claim must carry CPT modifier 93 to attest to that [1]. Read that as a product requirement: your synchronous product must ship working video even for the visits that end up audio-only, because the capability itself is a billing condition.

The current Medicare access rules are generous but dated: the Consolidated Appropriations Act, 2026 (signed 2026-02-03) extended the pandemic-era flexibilities — home as an eligible originating site, no geographic restriction, audio-only for non-behavioral care — through December 31, 2027, while behavioral and mental telehealth at home, including audio-only, is permanent [3]. The CY 2026 Physician Fee Schedule also streamlined how services join the Medicare telehealth list and permanently removed several frequency limits [4]. Dates like these shape roadmaps: reimbursement and the rules that shape the product covers the cliff-watching.

Asynchronous: the queue architecture

A store-and-forward product is built around a different job: capture clinical information well, store it safely, and move it through a review queue inside a deadline. The pipeline is capture → validate → encrypt and store → queue → clinician review → response. No component has a real-time constraint; every component has an integrity constraint. The center of gravity moves from the network to the data: image quality validation at capture (a blurry photo discovered at review time wastes a day), encryption at rest from the first byte, an auditable trail of who reviewed what, and retention rules for an archive that grows forever.

Quality at capture is the clinical make-or-break. A 2026 systematic review and meta-analysis of teledermatology found diagnostic concordance with face-to-face examination of about 76% across skin conditions — and adding dermoscopy (a standardized close-up imaging attachment) lifted concordance in skin cancers from 67% to 80% [5]. The engineering translation: guided capture flows, automatic blur and exposure checks, and resolution floors are clinical features, not UX polish. Medicare's own store-and-forward definition makes the same point in regulatory language — the photograph must be "adequate for furnishing or confirming a diagnosis" [1]. The specialty deep-dive lives in specialty visual consults.

The billing geography is the part that surprises teams. Under Medicare, store-and-forward qualifies as statutory "telehealth" in exactly one situation: federal telemedicine demonstration programs in Alaska or Hawaii (42 CFR §410.78(d)) [1]. Everywhere else, asynchronous care is paid through a separate family Medicare deliberately keeps outside the telehealth definition — communication technology-based services (CTBS). The two workhorses: HCPCS G2010, remote evaluation of patient-submitted video or images with follow-up to the patient within 24 business hours, and CPT 99421–99423, online digital evaluation-and-management conducted through a patient portal over up to 7 days, tiered by clinician time (5–10, 11–20, 21+ minutes) [6]. Because these are not "telehealth," the §1834(m) restrictions never attach — no originating-site rules, no expiry dates to watch. State Medicaid is broader still: as of the Center for Connected Health Policy's Fall 2025 review, 40 state Medicaid programs reimburse store-and-forward, with 8 more paying through CTBS-style codes [7].

Notice what the codes do to your architecture. "Within 24 business hours" is a queue service-level agreement your system must measure and enforce. "5–10 minutes over 7 days" means the product must track cumulative clinician time per case. The billing descriptor is a requirements document.

The economics are the reason asynchronous products exist. A live visit consumes clinician time in fixed, scheduled blocks; a review queue consumes it in minutes, on the clinician's schedule, with no no-show risk. At 5 minutes per case, one clinician-hour reviews about 12 dermatology cases; the same hour holds two, perhaps three, scheduled video visits. That throughput difference — not the infrastructure bill — is the business case, and it is why direct-to-consumer platforms described in the product landscape article run asynchronous-first.

RPM: the pipeline architecture

A remote patient monitoring product is built around a third job: run a fleet of devices in patients' homes and turn their readings into timely clinical action without drowning the care team. The pipeline: device → short-range radio (usually Bluetooth Low Energy) or a built-in cellular modem → a gateway (the patient's phone app or a dedicated hub) → an ingestion API → a time-series store → a rules engine → alerts and a care-team dashboard. The standards stack exists and is worth using: the ISO/IEEE 11073 personal-health-device family defines the device data model, the Bluetooth SIG's health-sensor profiles carry it over BLE, and HL7 FHIR's Personal Health Device implementation guide maps device readings into FHIR Observation resources your EHR integration can consume [8].

Two regulatory facts shape the whole product. First, the device test: to bill Medicare's RPM codes, the device must meet the FDA's definition of a medical device under section 201(h) of the Federal Food, Drug, and Cosmetic Act — FDA clearance is not required, but the definition must be met, and the readings must be automatically collected and transmitted, not typed in by the patient [9]. A manual-entry symptom diary is a different (and largely non-reimbursable) product. Second, the day-count test: the device-supply code CPT 99454 pays only when readings are transmitted on at least 16 days in a 30-day period — and effective January 1, 2026, the CY 2026 Physician Fee Schedule added CPT 99445, which covers 2–15 days in 30, plus CPT 99470, covering the first 10 minutes (rather than 20) of monthly treatment-management time [4][10]. Your ingestion pipeline must therefore count distinct days with at least one reading per patient per rolling 30-day window — a database query that directly decides revenue, and the single most common thing RPM builds get wrong.

The compliance posture around RPM is tightening as the money grows. The HHS Office of Inspector General reported Medicare RPM payments of about $536 million in 2024 — up 31% in a year, from $15 million in 2019 — covering nearly one million enrollees, and flagged billing patterns warranting scrutiny, including practices that billed RPM for patients with no prior relationship [11]. The product translation: enrollment provenance, consent records, and time-tracking for the treatment-management codes (99457/99458 at 20-minute tiers, 99470 at 10) belong in the data model from day one. The clinical-program side of RPM — care-team workflows, alert design, billing programs like chronic care management — is the subject of the chronic-care and RPM playbook; the machine-learning layer on the data stream is covered in RPM anomaly detection.

Figure 2. Three pipelines that share almost no components: a media path with a millisecond budget, a queue with an integrity budget, and a device fleet with a day-count budget.

One compliance umbrella, three risk surfaces

All three modalities live under the same law. The readings, the photos, and the video stream are all protected health information (PHI) — health data tied to an identifiable person — and the HIPAA Security Rule's technical safeguards (45 CFR §164.312: access control, audit controls, integrity, transmission security) apply to each pipeline end to end [12]. Every vendor that touches the data needs a signed Business Associate Agreement — the contract that makes a vendor legally accountable for PHI — exactly as the BAA article describes.

What differs is where the risk concentrates. Synchronous risk lives in transit and in the recording question — media encrypted with DTLS-SRTP, and a deliberate decision about whether sessions are recorded at all. Asynchronous risk lives at rest: a long-lived archive of diagnosable images is exactly the asset a breach monetizes, so storage encryption, access control, and retention discipline carry the load. RPM risk lives in the supply chain: a fleet of consumer-grade devices, a phone app, a cellular carrier, and a device vendor's cloud — each hop a place PHI flows and a party that may need a BAA. Same umbrella, three different places to hold it.

The worked example: one clinic, three cost centers

Take a clinic running 1,000 encounters per month and put it through each modality. The arithmetic is rough by design — the point is where the money sits, not the third digit.

Synchronous: the cost is the media path (and the engineering around it). A 720p WebRTC visit runs about 1.2 Mbps in each direction. A 20-minute visit is 1,200 seconds: 1.2 Mbps × 1,200 s = 1,440 megabits ≈ 180 MB sent per participant, and the same received. Through an SFU, the server relays both participants' streams: roughly 4 × 180 MB ≈ 0.7 GB of server traffic per visit, or about 720 GB across 1,000 visits. At typical cloud egress pricing that is tens of dollars a month; on a managed video API at ~$0.004 per participant-minute it is 2 × 20 × $0.004 = $0.16 per visit, or $160/month. Cheap either way — the real synchronous spend is the reliability engineering (TURN capacity, reconnection, monitoring) priced in the cost-model article.

Asynchronous: the cost is clinician throughput. 1,000 cases × 4 photos × 5 MB = 20 GB of new images per month. Encrypted object storage at ~$0.023/GB-month makes that $0.46/month — and even a fully accumulated 7-year archive (20 GB × 84 months = 1.68 TB) holds around $39/month. The infrastructure is approximately free; the binding constraint is the review queue: at 5 minutes per case, 1,000 cases = 5,000 clinician-minutes ≈ 83 clinician-hours per month.

RPM: the cost is the fleet. The data is trivial — 1,000 patients × 4 readings/day × ~1 KB ≈ 4 MB/day, about 120 MB/month: a month of clinical data from a thousand-patient fleet is less data than 15 minutes of one video visit. But each patient holds hardware: a cellular-connected cuff or hub at $50–100 amortized over 24 months plus $3–8/month connectivity plus logistics lands around $10–20 per patient per month — $10,000–20,000/month for the fleet, two orders of magnitude above the other two pipelines' infrastructure.

Figure 3. "Telemedicine" is one word but three Medicare rulebooks — and each rulebook writes requirements into your architecture.

Common mistake: building one product and calling it three

The classic mis-scope reads like this: "We'll build the video visit first; async and monitoring are features we'll add later." Six months later the team discovers that nothing transfers. The media stack is useless to the review queue; the queue has no day-counting; the "quick RPM add-on" needs device procurement, a gateway app, an ingestion API, and a rules engine — a second product. The inverse mistake also ships: an asynchronous-first platform that bolts on live video without a TURN strategy or reconnection logic, and the first dropped consult becomes a clinical incident. Two cheaper, equally damaging variants: storing store-and-forward photos in a bucket nobody signed a BAA for, and counting RPM readings instead of distinct days with readings — which silently misclassifies patients between 99445 and 99454 and turns into a refund conversation with a Medicare contractor [11]. Scope the three as three; share what actually shares (identity, consent, the patient record, audit logging) and keep the pipelines separate.

Hybrids: where real products end up

Most successful products combine modalities deliberately, with explicit escalation paths rather than blurred ones. Three patterns recur. Async-first with synchronous escalation: a questionnaire-and-photo intake handles the routine majority; cases that trip clinical rules escalate to a live visit — the dominant direct-to-consumer design. Monitoring with scheduled conversations: an RPM program streams readings continuously, and the care plan adds a monthly video check-in — the standard chronic-care shape. Visit with an asynchronous tail: a live consult generates an after-visit plan, and follow-up photos flow through a review queue instead of another appointment. Architecturally, every hybrid stands on one shared spine — identity, consent, scheduling, the patient record, audit — with the three pipelines hanging off it as separate services. That spine is exactly the platform anatomy the next article maps end to end.

Figure 4. Hybrids are explicit escalation paths between separate pipelines — not one pipeline doing three jobs.

Where Fora Soft fits in

Fora Soft has built real-time and media software since 2005 — telemedicine, video conferencing, streaming, OTT, e-learning, surveillance, AR/VR; 239+ shipped projects — and telemedicine work regularly spans all three modalities in one engagement. We build the synchronous layer to HIPAA's technical-safeguard bar (encrypted WebRTC, reconnection, audit), store-and-forward workflows where capture validation and queue SLAs are treated as clinical requirements, and RPM pipelines where the day-count and consent logic that billing depends on is in the schema from the first migration. Our surveillance and streaming background carries over directly to the always-on ingestion and alerting that monitoring products need. We start engagements by fixing which modalities the product actually contains — because that decision prices everything downstream.

What to read next

• The anatomy of a telemedicine platform, end to end — the shared spine all three modalities hang off.
• Chronic care management and remote patient monitoring — the full RPM product playbook.
• Reimbursement and the rules that shape the product — the payment rules behind each modality.

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your synchronous vs asynchronous telemedicine plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Modality Architecture Cheat Sheet — Synchronous, store-and-forward, and RPM side by side: pipeline, latency budget, Medicare bucket and 2026 codes, PHI hotspots, and the classic mistake for each — on one page.

References

1. 42 CFR §410.78 — Telehealth services (definitions of asynchronous store-and-forward technologies, interactive telecommunications system, originating site; audio-only conditions and CPT modifier 93; Alaska/Hawaii store-and-forward exception at §410.78(d)), https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-B/part-410/subpart-B/section-410.78 — accessed 2026-06-11. Tier 1.
2. ITU-T Recommendation G.114 (05/2003) — One-way transmission time: ≤ 150 ms one-way delay acceptable for most user applications; 400 ms planning limit, https://www.itu.int/rec/T-REC-G.114 — accessed 2026-06-11. Tier 1.
3. HHS — Telehealth policy updates, Telehealth.HHS.gov (Medicare telehealth flexibilities extended through 2027-12-31 by the Consolidated Appropriations Act, 2026, H.R. 7148, signed 2026-02-03; behavioral/mental telehealth at home and audio-only permanent), https://telehealth.hhs.gov/providers/telehealth-policy/telehealth-policy-updates and CMS, Telehealth FAQ (updated 2026-02-26), https://www.cms.gov/files/document/telehealth-faq-updated-02-26-2026.pdf — accessed 2026-06-11. Tier 1.
4. CMS — Calendar Year (CY) 2026 Medicare Physician Fee Schedule Final Rule (CMS-1832-F), fact sheet 2025-10-31, https://www.cms.gov/newsroom/fact-sheets/calendar-year-cy-2026-medicare-physician-fee-schedule-final-rule-cms-1832-f; final rule, Federal Register, 2025-11-05, https://www.federalregister.gov/documents/2025/11/05/2025-19787/medicare-and-medicaid-programs-cy-2026-payment-policies-under-the-physician-fee-schedule-and-other — telehealth-list streamlining, permanent removal of certain frequency limits, remote-monitoring rate setting; new lower RPM thresholds effective 2026-01-01. Tier 1.
5. Diagnostic accuracy of teledermatology for skin diseases: a systematic review and meta-analysis, Frontiers in Medicine (2026), https://www.frontiersin.org/journals/medicine/articles/10.3389/fmed.2026.1739592/full — diagnostic concordance ~76% across skin conditions; dermoscopy improved concordance in skin cancers from 67% to 80%. Tier 5 (peer-reviewed).
6. AAFP — How to Code for Telehealth, Audio-Only, and Virtual-Digital Visits (HCPCS G2010 remote evaluation of recorded video/images with follow-up within 24 business hours; CPT 99421–99423 online digital E/M over 7 days, time-tiered), https://www.aafp.org/family-physician/practice-and-career/getting-paid/coding/coding-telehealth-audio-virtual-digital-visits.html — accessed 2026-06-11. Tier 5 (professional-society coding guidance on Tier-1 code descriptors).
7. Center for Connected Health Policy (CCHP) — State Telehealth Laws and Reimbursement Policies Report, Fall 2025 (40 state Medicaid programs reimburse store-and-forward; 8 additional states via CTBS codes), https://www.cchpca.org/resources/state-telehealth-laws-and-reimbursement-policies-report-fall-2025/ — accessed 2026-06-11. Tier 5 (institutional policy tracker).
8. HL7 — Personal Health Device Implementation Guide (FHIR mapping of ISO/IEEE 11073 personal-health-device observations to Device/Patient/Observation resources), http://hl7.org/fhir/uv/phd/ ; ISO/IEEE 11073 PHD family and IEEE 11073-10206 abstract content model carried over Bluetooth LE health-sensor profiles, https://sagroups.ieee.org/11073/phd-wg/ — accessed 2026-06-11. Tier 1 (standards).
9. CMS — Remote Patient Monitoring (Medicare coverage page: device must meet the FDA definition of a medical device under FD&C Act §201(h); data automatically collected and transmitted; established-patient requirement), https://www.cms.gov/medicare/coverage/telehealth/remote-patient-monitoring — accessed 2026-06-11. Tier 1.
10. McDonald Hopkins — CMS Lowers Time Thresholds for Remote Patient Monitoring (CPT 99445: device supply, 2–15 days in 30, paid at parity with 99454; CPT 99470: first 10 minutes of monthly treatment management; effective 2026-01-01), https://www.mcdonaldhopkins.com/insights/news/cms-lowers-time-thresholds-for-remote-patient-monitoring — accessed 2026-06-11. Tier 4 (health-law summary of the Tier-1 final rule [4]).
11. HHS Office of Inspector General — Billing for Remote Patient Monitoring in Medicare (2025-08): Medicare RPM payments ≈ $536M in 2024 (vs $15M in 2019, +31% year over year), ~1 million enrollees; billing patterns warranting scrutiny, including practices billing RPM with no prior patient relationship, https://oig.hhs.gov/reports/all/2025/billing-for-remote-patient-monitoring/ — accessed 2026-06-11. Tier 1.
12. 45 CFR §164.312 — Technical safeguards (HIPAA Security Rule: access control, audit controls, integrity, authentication, transmission security), https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 — accessed 2026-06-11. Tier 1.

Where lower-tier sources disagreed with rule text, the rule text won: vendor explainers that describe store-and-forward as "Medicare telehealth" are contradicted by 42 CFR §410.78(d), which confines that treatment to Alaska/Hawaii demonstration programs [1]; older RPM guides stating a hard 16-day minimum are superseded for 2026 by the CY 2026 PFS final rule's 2–15-day codes [4][10].