Somone asked me about the "complexified" coding of remote monitoring, a current hot topic at CMS.
I'm not a native expert, so I asked Chat GPT for some orientation. As below.
##
From Holter to Remote Monitoring: How a Simple Coding Logic Produced 17 Codes—and Why CMS May Collapse Them to Four
The current RPM and RTM code families can appear bewildering to anyone entering the subject for the first time. By 2026, the portion of the Medicare remote-monitoring universe now under CMS review comprises 17 separate CPT codes. Taken together, they distinguish initial setup, device supply, duration of monitoring, type of therapeutic monitoring, and different increments of professional management time.
- In the CY 2027 Physician Fee Schedule proposed rule, CMS is now asking whether that elaborate architecture should be replaced, for Medicare payment purposes, by just four G-codes. (public-inspection.federalregister.gov)
That apparent complexity has a fairly simple origin. Monitoring has long been treated as a service that can be divided into recognizable economic components: someone starts the patient on the service and explains the device; someone supplies the technology and acquires the data; someone processes or organizes the information; and a physician or other professional reviews it and acts on it. Those functions may occur at different times and may be performed by different entities.
The idea predates contemporary digital health by decades.
Holter Monitoring as the Historical Template
Traditional ambulatory ECG monitoring provides the cleanest example. The current Holter family, 93224–93227, first appeared in CPT in 1990. The wording has changed over time, but the underlying structure has endured for roughly 36 years. (codingahead.com)
CPT 93224 represents the global Holter service. The component codes divide that global service into distinct activities: 93225 for recording, including connection and disconnection; 93226 for scanning analysis and report; and 93227 for physician or other qualified health professional review and interpretation. Medicare continues to recognize this same division. (cms.gov)
This differs from the usual radiology convention. A radiology service ordinarily has one CPT code, and its two economic pieces can be identified by appending -TC for the technical component or -26 for the professional interpretation. Holter coding does not rely on that convention. CPT supplies separate component codes, and Medicare expressly instructs contractors not to use -TC or -26 with the Holter family. (cms.gov)
The reason is easy to see operationally. One practice might connect the monitor and instruct the patient. A separate organization might receive the recording and perform the technical analysis. A cardiologist might perform the professional interpretation. The code set permits each component to be identified separately, while still allowing a single global code when one organization furnishes the whole service.
That same logic survived the transition to newer ambulatory ECG technology. When CPT created codes for extended continuous ECG monitoring, including modern patch-monitor systems such as Zio-like services, it again separated recording, technical analysis, and professional interpretation. CMS itself referred back to the existing 93224–93227 Holter family when valuing the newer extended-monitoring codes. (cms.gov)
The hardware therefore evolved much faster than the coding philosophy.
The Odd Medicare Rule for ECG Interpretation
ECG coding also sits on top of an unusual provision of Medicare law.
Section 1848(b)(3) of the Social Security Act requires the Secretary of Health and Human Services to make separate payment for the interpretation of electrocardiograms when the ECG is performed or ordered in conjunction with a physician visit or consultation. At the same time, Medicare must remove the corresponding interpretation work from the relative value of the visit so that the same work is not paid twice. (ssa.gov)
The statute doesn't command CPT to create an interpretation-only code. It is a requirement for separate Medicare payment, not a statutory specification of coding mechanics. Still, ECG coding fits that requirement neatly. A routine 12-lead ECG has a global code, a tracing-only code, and a dedicated interpretation-and-report code rather than depending only on the generic -TC and -26 modifiers.
Bonus: The Topsy Turvy History
The history is unusually convoluted.
In the Omnibus Budget Reconciliation Act of 1990, Congress initially adopted essentially the reverse rule: when an ECG accompanied a physician visit, Medicare generally was not to make separate payment for the interpretation. (uscode.house.gov)
Congress changed direction in the Omnibus Budget Reconciliation Act of 1993. From 1993 forward, Medicare law requires separate payment for ECG interpretation. The current U.S. Code preserves both the present rule and the history of the earlier language that barred such separate payment. (uscode.house.gov)
That statutory change did not produce the Holter family; 93224–93227 were already present in CPT in 1990. But it fits comfortably with a broader Medicare tradition in which the technical production of ECG information and its professional interpretation are treated as distinct services.
That is useful context for RPM and RTM. Separating monitoring into setup, technology, data acquisition, and professional work is not a newly invented digital-health payment theory. It is a familiar coding concept being applied to a newer kind of longitudinal care.
The Same Logic, Applied Over a Month
RPM and RTM are clinically different from Holter monitoring, but structurally they are close relatives.
RPM generally concerns remotely acquired physiologic information such as blood pressure, weight, pulse oximetry, or respiratory parameters. RTM occupies a somewhat different space, including monitoring of therapy adherence, therapy response, and therapeutic intervention, with device-supply codes divided into areas such as respiratory, musculoskeletal, and cognitive behavioral therapy monitoring.
The crucial difference is that Holter monitoring is usually an episode. The patient wears the device for a defined interval, data are recorded and processed, and the physician interprets the result. RPM and RTM are typically longitudinal management services. The device may remain with the patient, data can flow repeatedly during the month, clinical staff or professionals may communicate with the patient, and management may continue month after month.
Even so, the correspondence is easy to recognize:
| Coding function | "Traditional" Holter monitoring | Modern RPM/RTM |
|---|
| Initiation | Connection, recording setup and patient instruction | Initial device setup and patient education |
| Technology/data | Recording and technical processing | Device supply, data recording/transmission and monitoring infrastructure |
| Professional work | Review and interpretation | Review, patient interaction and treatment management |
| Complete service | Global Holter code available | Multiple recurring components currently billed separately; CMS is considering rebundling them |
The newer code families add another dimension that traditional Holter coding largely does not: time. Holter coding mainly asks what part of the service was performed and by whom. RPM and RTM also ask how many days of monitoring occurred and how much treatment-management time was furnished during the month.
Why the Code Family Kept Growing
The present 17-code structure did not appear all at once. It accumulated through individually plausible distinctions.
There is a setup code because patient onboarding is an initial service rather than a monthly recurring activity. Device-supply codes recognize the cost of hardware, connectivity, and data infrastructure separately from professional management. Treatment-management codes recognize time spent reviewing information, interacting with the patient, and adjusting care.
RTM then adds another layer because its device-supply services are separated according to the therapeutic domain being monitored.
CPT added still more detail in 2026. Previously, the principal device-supply codes generally contemplated 16–30 days of monitoring within a 30-day period, and the principal treatment-management codes generally began at 20 minutes per month. Effective in 2026, CPT introduced shorter-duration alternatives. RPM gained 99445 for 2–15 days of device data and 99470 for the first 10 minutes of treatment management. RTM gained 98984–98986 for 2–15 days of device data in different therapeutic categories and 98979 for the first 10 minutes of treatment management. (apma.org)
Each change can be defended on its own. Twelve days of legitimate monitoring may require meaningful resources. Ten minutes of actual clinical management is still professional work. Different RTM applications may use different devices and carry different costs.
The difficulty appears when all of those reasonable distinctions are multiplied together.
By 2026, the set CMS is now examining contains 17 CPT codes: seven RPM codes and ten RTM codes. Across the family, CPT distinguishes setup, shorter versus longer data-collection periods, 10 versus 20 minutes of initial management, additional time, and—in RTM—different therapeutic applications. (public-inspection.federalregister.gov)
This is a familiar coding paradox. Added precision is readily justified one decision at a time; the final matrix can nevertheless become much more complicated than the clinical service it is meant to describe.
CMS Considers a Much Simpler Model
The CY 2027 Physician Fee Schedule proposed rule begins to move in the opposite direction.
CMS has made several formal proposals involving the existing RPM and RTM codes. These include requiring a separately reportable initiating visit when remote monitoring begins, limiting RTM to established patients, restricting payment for certain services furnished by contracted rather than practice-employed clinical staff, and revising practice-expense values because CMS believes some remote-monitoring devices may now be less costly than initially estimated. (cms.gov)
Beyond those proposals, CMS is also considering something more fundamental. It is soliciting comment, rather than yet formally adopting a replacement coding system, on whether the 17 existing RPM/RTM CPT codes should be bundled into only four HCPCS G-codes. (public-inspection.federalregister.gov)
Under the concept CMS describes, GRPM1 would cover initial RPM setup and patient education, while GRPM2 would cover the recurring monthly RPM service, combining device supply and data transmission with treatment management. GRTM1 and GRTM2 would provide the parallel structure for RTM.
The contemplated monthly RPM code illustrates how much bundling CMS has in mind. CMS describes a monthly service that would include device supply, at least two days of transmitted data, treatment-management services, at least one real-time interactive communication with the patient or caregiver, and at least 20 minutes of management time. (public-inspection.federalregister.gov)
The four-code model would therefore preserve only two principal distinctions: RPM versus RTM, and initial setup versus ongoing monthly service. Most of the present subcategories would disappear.
The Policy Issue Is Larger Than Administrative Simplification
CMS is not interested in consolidation merely because 17 codes are cumbersome.
The agency expressly points to the proliferation of remote-monitoring codes and to findings from the HHS Office of Inspector General. OIG reported that about 43% of Medicare beneficiaries receiving RPM did not receive all three principal components of the service. CMS cites that finding in explaining why the current code structure may not fully ensure that beneficiaries receive remote monitoring as the integrated service policymakers intended. (public-inspection.federalregister.gov)
That finding exposes the tradeoff inherent in component coding.
Separating a service into billable parts can be highly useful because payment can follow the entity actually performing the work. But once each element becomes separately billable, Medicare may find itself paying for individual pieces of a clinical process without necessarily purchasing the complete process.
The contemplated G-codes would shift the unit of payment. Instead of separately purchasing technology, data, and treatment-management pieces, Medicare would move closer to paying for an integrated month of remote monitoring that includes the technology, transmitted information, patient interaction, and clinical management.
That is a more consequential change than simply reducing the number of billing codes.
A Coding Pendulum
Viewed over several decades, the history forms a recognizable progression.
The Holter system established the value of separating important components of a monitoring service. RPM and RTM extended that approach to longitudinal care, separating setup, device supply, monitoring duration, professional time, and therapeutic category. Over time, component coding became increasingly fine-grained.
CMS is now testing the opposite proposition: perhaps some of those distinctions are no longer worth preserving for Medicare payment.
The emerging sequence is therefore straightforward:
Holter: divide a monitoring test into its major technical and professional components.
RPM/RTM: apply that component logic much more finely to an ongoing digital service.
CMS 2027 concept: combine most of those pieces again and pay for a more complete monthly service.
Seen in that light, today's code proliferation is not simply the product of inexplicable coding bureaucracy. The individual codes grew from a legitimate and longstanding idea: different work should be separately identifiable when different parties may perform it or when the resources differ.
The harder question is where that process should end.
For a Holter service that has been coded in component form for roughly 36 years, separating recording, technical analysis, and professional interpretation remains easy to understand. For recurring remote care that combines a device, transmitted data, patient communication, and treatment management, CMS is now asking whether the better unit of payment is not each constituent part, but the month of monitoring care as a whole.
