Telemedicine in cardiology combines video visits with a steady stream of cardiac data collected between them: patient-recorded ECGs, ambulatory monitor reports, implanted device transmissions, blood pressure and weight. The visit is short, but the data behind it is large, and most of the engineering work sits in that data.
This guide explains which cardiology visits work over video, where the data comes from, how a remote rhythm monitoring workflow runs from transmission to chart, and the design checks that keep a cardiology telehealth platform safe to operate.
What does telemedicine in cardiology involve?
Building a virtual cardiology service?
Agnotic builds telemedicine platforms that bring video visits, ECG files and device data into one clinician workflow.
Telemedicine in cardiology is the delivery of heart care at a distance through video visits, review of patient-recorded and ambulatory ECGs, remote monitoring of implanted pacemakers and defibrillators, and home readings such as blood pressure and weight. The software must route each data type to the right clinician and file it in the chart.
A cardiology service usually runs two tracks at once. One is scheduled visits, where a cardiologist reviews symptoms, medicines and recent data. The other is unscheduled review, where a device clinic or monitoring team works through incoming transmissions and decides who needs a call today.
Which cardiology visits work well over video?
Video works best for visits where the history and recent data carry the decision and a hands-on exam adds little. Visits that depend on auscultation, a new murmur or an echo usually need the patient in the clinic.
- Medication titration: Heart failure and blood pressure follow-ups, where home readings and symptoms drive dose changes.
- Rhythm follow-up: Review of a monitor report or patient-recorded ECGs after an ablation, cardioversion or new antiarrhythmic.
- Post-procedure checks: Wound questions, activity limits and medicine review after a catheterization or device implant, with photos uploaded before the visit.
- Results review: Discussing a stress test, echo or lab result that has already been performed in person.
- Cardiac rehab check-ins: Progress reviews between supervised sessions, where the program allows virtual contact.
For Medicare patients, the Consolidated Appropriations Act, 2026 keeps telehealth available to patients at home through 31 December 2027. A platform should still store the visit's modality and the patient's location, because coverage rules for later years may differ.
Where does cardiac data come from between visits?
Cardiac data between visits comes from four kinds of source, and each arrives in a different format on a different schedule. Plan the intake for each one separately rather than treating them as one device feed.
- Consumer ECG recordings: Single-lead tracings from watches and handheld devices, usually shared as PDF exports or through a phone app's health data store.
- Ambulatory monitors: Holter and patch monitors and mobile cardiac telemetry, where the monitoring vendor reads the recording and returns a report.
- Implanted devices: Pacemakers, defibrillators and loop recorders that transmit through a home monitor to the manufacturer's clinician portal.
- Home vitals: Cuffs and scales that send readings for blood pressure and fluid management, often under a remote monitoring program.
Consumer ECG is regulated software, not a gadget feature. In 2018 FDA granted De Novo DEN180044 for Apple's ECG app, creating a Class II category for over-the-counter ECG software, and later apps from other makers were cleared against it. Each app's labeling sets what its classification means, so the platform should store the source app and its result category with each tracing.
Billing follows the data type. Home readings can be billed as Medicare remote physiologic monitoring, where the CY 2026 Physician Fee Schedule final rule created two new codes: 99445 covers device supply for a short period of 2 to 15 days, and 99470 covers the first 10 minutes of treatment management. Remote interrogation of implanted devices is billed under its own device monitoring codes, so keep the two streams apart in the data model.
How does a remote rhythm monitoring workflow run?
A remote rhythm monitoring workflow runs in six steps, from the moment a device or monitor sends data to the moment the result is filed and the patient is contacted. Each step has an owner and a time limit the team agrees in advance.
1. Receive: Transmissions arrive in the manufacturer's portal or the monitoring vendor's system, either on a schedule or because the device detected an event.
2. Normalize: The platform pulls the transmission or report, matches it to the patient, and records the device, event type and timestamps in one internal format.
3. Triage: A device nurse or technician reviews the event against the protocol the cardiologists wrote, marking it routine, needing review or urgent.
4. Review: Urgent and flagged events go to the responsible clinician, who decides on a call, a medicine change, an in-person visit or emergency advice.
5. Contact: The patient is reached by phone or message, and the attempt and outcome are recorded, including failed attempts.
6. File: The report and the clinician's interpretation are filed to the EHR, and the billable period or interrogation is logged for coding.
Patient matching in step 2 is where errors hide. Device portals identify patients by device serial number and the clinic's own enrollment record, so the platform needs a mapping table from serial numbers to EHR patient IDs, updated whenever a device is replaced.
Getting device data into the EHR
Device data reaches the EHR through a mix of structured messages and documents. The goal is that a cardiologist opening the chart sees the latest interrogation, the monitor report and the trend of home readings without logging into three portals.
- Implanted device summaries: The IHE Implantable Device Cardiac Observation profile defines how device observations travel, typically as HL7 v2 ORU messages, and some manufacturers and EHRs support it.
- Monitor reports: Holter and patch reports usually arrive as PDF documents, filed with a document type and the reading cardiologist's name.
- ECG tracings: Patient-recorded ECGs are filed as documents with the recording time, source app and result category in the metadata.
- Home readings: Blood pressure and weight are better as discrete observations, through FHIR Observation resources where the EHR accepts writes, or HL7 v2 results otherwise.
Decide early which data is discrete and which is a document. Discrete values can drive flowsheets, trends and alerts. Documents are easier to file but cannot be graphed, so heart failure programs that track weight trends need discrete weights.
How should cardiology alerts be triaged?
Cardiology alerts should be triaged against written protocols that the cardiologists own, with thresholds set per patient where needed and a named reviewer for every time window. Software applies the protocol; it does not invent one.
Implanted devices can raise many event transmissions, and many are known, stable findings. The platform should let the device team mark a finding as expected for a patient, so the same event does not page someone every night, while a new or worsening event still surfaces.
Out-of-hours cover needs the same rigor. If urgent events arrive at night, the protocol names who reviews them and how fast, or states plainly that the service is not for emergencies, and the patient enrollment materials say the same.
What changes for heart failure programs?
Heart failure programs change the data model most, because decisions rest on trends rather than single events. A gain in weight over a few days, rising blood pressure or new symptoms reported in a check-in can all prompt a diuretic change before the patient feels unwell enough to call.
That puts three demands on the platform. Readings must be discrete and timestamped so trends can be computed. The trend rule, such as the weight change over a set number of days, must be written by the program's clinicians and stored per patient, since targets differ. And the action taken, such as a dose change or a same-week visit, must be recorded against the alert that triggered it.
Symptom check-ins are worth structuring too. A short questionnaire on breathlessness, swelling and sleep position gives the reviewer comparable answers each week, where free-text messages vary from patient to patient.
Some heart failure patients also have implanted devices that report fluid or activity measures. Where they do, show device trends and home readings on one timeline, so the reviewer is not comparing two screens.
Design checks for a cardiology telehealth platform
Run these checks with the cardiology, device clinic and IT leads before the first patient enrolls. Each one can be tested with sample data.
- Serial mapping: Every implanted device serial number maps to one EHR patient, and replacements update the map the same day.
- Protocol ownership: Triage thresholds are written and signed by a cardiologist, stored as configuration and versioned.
- Reviewer coverage: Every hour of the week has a named reviewer or a stated no-coverage window that patients were told about.
- Failed contact: The workflow records failed calls and escalates after a set number of attempts.
- Source labeling: Each ECG tracing stores its device, app and result category, so readers know what produced it.
- Discrete versus document: Weights and blood pressures are discrete values; reports and tracings are documents with proper types.
- Billing separation: Remote physiologic monitoring time and implanted device interrogations are logged separately.
- Visit context: Video visits open with the latest device summary, monitor report and home trends on screen.
How Agnotic can help
Cardiology telehealth depends on getting many data streams into one place the cardiologist trusts. Agnotic Technologies builds that platform for the client: video visits with device and ECG context on screen, intake from manufacturer and monitoring portals, serial-number matching, protocol-driven triage queues, and filing to the EHR as discrete data or documents.
The client's cardiologists define the protocols and coverage. Agnotic implements them as versioned configuration with audit trails, so a threshold change is reviewed and traceable.
Bring cardiac data into your telemedicine platform
See how Agnotic builds virtual care platforms with device data, or browse the HL7 integration hub.
Related reading on Agnotic
Continue with telemedicine requirements, Florida telehealth law, remote monitoring and alert fatigue.
