Take a mid sized cardiology practice following 1,200 patients with implanted devices: pacemakers, implantable cardioverter defibrillators, cardiac resynchronization devices and loop recorders. Each of those patients sends scheduled remote transmissions, and any of them can send an unscheduled alert at three in the morning.
That is tens of thousands of transmissions a year, and here is the part that catches practices out. Almost none of them arrive in the EHR. They arrive in the device manufacturer’s portal, and there are four of those.
Four Portals, None of Them Your Record
Each major manufacturer runs its own remote monitoring platform. Medtronic has CareLink, Boston Scientific has LATITUDE, Abbott has Merlin.net, Biotronik has Home Monitoring. A device clinic following a mixed population is logging into all four, every day, in addition to the record where the patient’s chart actually lives.
The practical consequences are the ones you would expect and one you might not:
- Nobody can see a patient whole. The transmission is in one system, the medication list and the echo report are in another.
- Review is invisible to the practice. Work done inside a manufacturer portal produces no record in the chart unless somebody re enters it, which means the clinical work and the documentation that supports billing it are two separate tasks.
- Coverage is fragile. A device clinic staffed by two people who know all four portals is two absences away from a backlog.
The standard that exists to solve this is the IDCO profile, Implantable Device Cardiac Observation, designed specifically to move device interrogation data into a record as structured observations rather than as a document. Support varies by manufacturer and by EHR, which is why this belongs in the vendor conversation early. Ask any cardiology EMR software vendor whether they support IDCO and with which manufacturers, rather than asking whether they “support remote monitoring,” which every vendor will answer yes to.
The test that separates a real integration from a claimed one: does a transmission arrive as discrete data that can be trended, queried and attached to a billing period, or does it arrive as a PDF? If it is a PDF, you have moved the filing problem, not solved it.
The 90 Day Cycle Is a Calendar Problem
Remote device monitoring has its own code family, and the thing that trips practices is not code selection. It is period tracking.
The professional component is reported with 93294 for pacemaker systems and 93295 for implantable defibrillator systems. The technical component is 93296, used for both. All three are 90 day services, and this is the part that matters operationally: they may be reported only once during the period, regardless of how many interrogations actually occurred. A period is established when remote monitoring is initiated, or on the 91st day, and runs for the subsequent 90 days. In practice that caps each patient at roughly four billable cycles a year.
So every one of those 1,200 patients is on their own rolling 90 day clock, started on a different date, and the practice has to know where each clock is. Two failure modes follow directly:
- Billing inside a period already reported produces a denial, and at volume it produces a pattern of denials that attracts attention.
- Missing a cycle entirely produces nothing at all. No denial, no error, no line on a missing charge report. The work was done, reviewed and clinically acted on, and simply never billed.
The second one is the expensive one precisely because it is silent. A practice that cannot produce a list of patients whose period closed last month without a bill is losing revenue it has no mechanism to detect. This is the single strongest argument for keeping device monitoring inside the system that also handles cardiology billing, rather than reconciling a portal export against a claims file once a quarter.
Verify current descriptors, periods and payer specific policy before building any of this into a workflow, since the details are revised.
Alert Triage, and What Counts as Actionable
Volume alone is not the problem. Undifferentiated volume is.
Transmissions split into two categories that deserve completely different handling. Scheduled transmissions are routine surveillance, reviewed on a cadence, and most of them are unremarkable. Alert transmissions are device generated and arrive when something crossed a threshold.
Within alerts, the clinical weight varies enormously. A lead impedance change out of range, a sustained ventricular arrhythmia episode, or a device reaching elective replacement indicator needs same day attention. A gradual rise in atrial fibrillation burden or a slow battery trend needs attention, but on a different clock. Treating all of them as one queue guarantees that the third category, the ones that matter this afternoon, sit behind the ones that matter this month.
What the practice has to settle, and write down:
- Which alert types trigger same day review, and who owns that queue by name rather than by team.
- What the escalation path is when the reviewer is not the electrophysiologist.
- What gets documented for a normal transmission, because “reviewed, no action” still has to exist in the chart to support the period.
- What happens to an alert that arrives on a Friday evening.
A cardiology EHR system that receives transmissions as discrete data can drive that triage from the chart, so the reviewer works one worklist instead of four portals, and the documentation is generated by the review rather than typed afterward from memory.
Home Blood Pressure Is a Different Code Family
Hypertension management brings its own remote data, and it is worth being precise here because practices routinely confuse these codes with remote physiologic monitoring.
Self measured blood pressure has two codes of its own. The first covers patient education and training on the setup and use of a device validated for clinical accuracy, including calibration, and is reportable once per device. The second covers the actual monitoring: separate self measurements of two readings one minute apart, twice daily across a 30 day period, with a minimum of twelve readings, collection of the data, a report of the average systolic and diastolic pressures, and communication of a treatment plan to the patient. That one is reportable once per calendar month.
Three things follow that are easy to get wrong:
- The device has to be validated for clinical accuracy. A cuff the patient bought without checking against a recognized validation protocol does not satisfy the requirement, which makes device selection part of the clinical workflow rather than a patient decision.
- The average and the communicated plan are both documentation requirements, not just clinical good practice. A note recording twelve readings but no average and no communicated plan has not evidenced the service.
- This is not the same as remote physiologic monitoring, which has its own codes, its own device definition and its own time requirements. Running both for the same patient in the same period needs a deliberate decision rather than an accident.
Heart Failure and the Work Between Visits
Device and blood pressure data converge most usefully in heart failure, where the clinically actionable signal is often a trend rather than a reading: weight climbing several pounds across a week, activity dropping after a medication change, thoracic impedance shifting, atrial fibrillation burden rising.
Acting on those trends is structured between visit work: someone reviews, someone contacts the patient, a titration decision gets made and documented, and the care plan is revised. That is what care management programs are built to organize and fund, and it is also where the documentation has to be a byproduct of the work rather than a separate chore, because a titration conversation that happened by phone and was never written down did not happen as far as the record is concerned.
What to Test Before You Commit
Feature lists will not distinguish these systems. Run the scenarios:
- Receive a device transmission and show whether it arrives as discrete observations or as an attached document.
- Produce every patient whose 90 day period closes in the next two weeks, and every one that closed last month without a bill.
- Route a red alert and show where it lands, who owns it, and what the clock looks like.
- Document a routine review and confirm the documentation supports the period without separate data entry.
- Record a month of self measured blood pressure, and have the system calculate the average and prompt for the communicated plan.
- Trend weight, blood pressure and arrhythmia burden for one heart failure patient on a single screen.
A system that handles all six is running your device clinic. One that handles two is storing documents about it.
The Point
Cardiology generates more continuous patient data than almost any other ambulatory specialty, and most practices are managing it with a set of manufacturer portals, a spreadsheet tracking billing periods, and two people who know how it all works.
That arrangement is survivable and it is expensive in ways that never appear as a line item: cycles that were worked and never billed, alerts that waited behind routine transmissions, and clinical review that lives outside the chart it should be part of. The fix is not more staff in the device clinic. It is transmissions arriving as data, periods tracked by the system that bills them, and triage driven from one worklist instead of four logins.