Beginning January 1, 2026, UnitedHealthcare (UHC) will dramatically narrow coverage for Remote Physiologic Monitoring (RPM) across its commercial, Medicare Advantage, and exchange plans.

Under its new policy, RPM is considered “proven and medically necessary” only for two indications:

• Chronic heart failure
  
  
• Hypertensive disorders of pregnancy
  

For almost everything else, including type 2 diabetes, essential hypertension, COPD, obstructive sleep apnea, anxiety, depression, and other chronic conditions, UHC declares RPM “unproven and not medically necessary due to insufficient evidence of efficacy.”

Professional societies have already sounded the alarm. The American Academy of Sleep Medicine, for example, has publicly criticized the change, noting that UHC will no longer cover RPM for most sleep apnea patients despite routine use of remote CPAP adherence monitoring in clinical practice.

👉 Read the Full Guide: The 2026 UnitedHealthcare Remote Care Shift

UHC’s stated rationale is simple: outside of heart failure and pregnancy-related hypertension, they say the science just isn’t there.

That raises a very concrete question for anyone running a practice or caring for chronically ill patients:

Is UHC right? Does the evidence actually say that RPM is “unproven” for these other conditions?

Let’s walk through what the data show.
‍

What the Evidence Actually Says About RPM

1. Heart failure and hypertensive pregnancy: UHC’s “yes” column

Here, the science and UHC are broadly aligned.

In heart failure, multiple randomized and quasi-experimental studies have shown that remote monitoring of weight, blood pressure, and symptoms can reduce hospitalizations and sometimes improve survival, especially in recently hospitalized, high-risk patients. Several trials and meta-analyses report meaningful reductions in HF admissions with telemonitoring compared with usual care.

For hypertensive disorders of pregnancy, home blood pressure monitoring with remote review has been shown to safely reduce in-person visits while maintaining good maternal-fetal outcomes. That combination of clinical plausibility, emerging trial data, and clear short-term risk (preeclampsia, severe hypertension) makes RPM in HDP an easy “yes.”

So far, so good. The question is what happens when we look at the many conditions UHC has moved into the “unproven” bucket.

2. Diabetes and essential hypertension: strong signals on risk-factor control

For type 2 diabetes, there is now a substantial body of randomized trials and meta-analyses looking at telehealth and RPM-like interventions (remote blood glucose or weight monitoring with feedback). Across studies, these programs consistently show modest but clinically meaningful reductions in HbA1c, often in the range of 0.3–0.5 percentage points compared with usual care, along with better blood pressure control in many cohorts. Those are exactly the risk factors every endocrinologist and PCP is trying to move.

Continuous glucose monitoring (CGM) – which is, in practice, a disease-specific form of RPM – has such strong evidence that it is widely covered by payers (including UHC) for appropriate diabetic populations. It’s hard to argue that remotely tracking glucose is “proven” when the device is called a CGM, but “unproven” when the CPT codes happen to sit in the RPM family.

For essential hypertension, the evidence is even harder to dismiss. Multiple large trials and systematic reviews show that:

• Home BP monitoring with telemetric transmission and clinician feedback
  
  
• Achieves larger reductions in systolic BP than office-only care (often by 4–10 mmHg)
  
  
• Increases the proportion of patients who reach guideline BP targets
  
  

Better blood pressure control is one of the most well-validated surrogates we have for reducing stroke and MI risk. To say RPM for hypertension is “unproven” requires you to ignore a decade of telemonitoring data and the physiology linking BP to outcomes.

Do we have 10-year trials proving that RPM prevents strokes and MIs directly? No. But that standard, if applied consistently, would also invalidate a lot of what we do in everyday medicine.

3. COPD and other chronic diseases: not perfect, but far from “no evidence”

For COPD, remote monitoring programs typically track symptoms, oxygen saturation, and sometimes activity or spirometry. The literature is mixed – not every trial is positive – but several randomized studies and reviews have found:

• Fewer exacerbation-related hospitalizations in telemonitored groups
  
  
• Longer time to first hospitalization after discharge in some programs
  
  
• Improved self-management and earlier rescue therapy in certain models
  
  

The effect sizes vary, and not every study meets every endpoint. But the pattern is very different from a clean “RPM doesn’t work.” It looks more like: RPM probably helps when it is integrated into a responsive care model; its value is less clear when used as a bolt-on gadget without workflow.

For obstructive sleep apnea (OSA), the core of modern care already relies on something very close to RPM: CPAP devices that remotely report usage and leak data. A 2023 meta-analysis concluded that telemonitoring of CPAP increases nightly adherence by roughly 30–45 minutes on average, especially when paired with coaching. That’s not a miracle, but it’s not nothing, and it’s precisely why sleep programs use these tools.

In mental health conditions like anxiety and depression, the story is different. Here UHC’s skepticism is closer to the evidence: remote physiologic signals (wearables, passive smartphone data) are still exploratory, and we don’t have robust RCTs showing that billing RPM codes for these conditions improves outcomes above standard telepsychiatry and psychotherapy. If UHC had narrowed its critique to these domains, the “insufficient evidence” label would be far easier to defend.

But that’s not what they did; they declared RPM “unproven and not medically necessary” for essentially every non-HF, non-HDP indication, including diseases where the signal is strong.

4. Economics and overuse: a real issue, but a different argument

There is another piece of context: RPM billing has exploded, especially in Medicare.

HHS’s Office of Inspector General (OIG) reported that Medicare payments for RPM exceeded $500 million in 2024, only a few years after the codes were introduced. They flagged multiple billing patterns suggestive of possible waste or abuse – for example, practices billing RPM for very large proportions of their panels, or for patients with minimal engagement.

From a payer’s perspective, that’s scary. If RPM is being used in a high-volume, low-touch way (essentially as a subscription revenue stream), the program can turn into pure cost without proportional benefit. Tightening coverage is one way to slam on the brakes.

But that’s not a scientific critique – it’s a utilization management response. The honest argument would be: “We believe RPM is being overused and sometimes misused; we’re limiting coverage to narrow, high-risk use cases while we figure out how to ensure value.” Instead, the policy language says: “RPM is unproven and not medically necessary” for most chronic conditions.

Those are very different claims.

If you’re still sharing revenue with a full-service RPM vendor, losing UHC coverage will hurt more than it has to. Before you make any moves, model what your margin looks like with and without a vendor in the loop.
‍
👉  Vendor Revenue Analyzer
‍

So, Is UHC’s RPM Policy Backed by Science?

If you define “backed by science” as:

• “There is no convincing evidence that RPM improves meaningful clinical endpoints in diabetes, hypertension, COPD, OSA, etc.”

then the answer is no. The literature shows consistent improvements in intermediate outcomes (HbA1c, BP, adherence, exacerbation rates) and, in some areas like heart failure, direct reductions in hospitalizations. Those are exactly the kinds of outcomes that clinical guidelines and other payers treat as meaningful.

If you define “backed by science” more narrowly as:

• “We only consider something proven if there are large, long-term RCTs showing hard outcome and mortality benefits for each individual ICD-10 pairing we’re asked to cover”

then you could try to defend UHC’s stance, but you’d also have to admit that standard-of-care medicine fails that bar in many places, not just RPM.

A more honest reading is:

• The clinical evidence supports RPM as a useful tool in managing several chronic diseases (particularly diabetes, hypertension, HF, COPD, and OSA), with modest but real benefits.
  
  
• The economic evidence generally shows RPM is cost-effective over time in high-risk cardiovascular populations, and may be cost-neutral or modestly cost-increasing in others, depending on program design.
  
  
• The policy change is far more aligned with cost and utilization concerns (and OIG’s fraud warnings) than with a neutral summary of the literature.

For clinicians and practice leaders, the takeaway is:

• UHC’s decision is not simply a reflection of “the science changing”. It is a business decision, partially justified with a very conservative reading of the evidence.
  
  
• When UHC says RPM is “unproven” for your diabetic, hypertensive, or COPD patients, that statement is out of step with the peer-reviewed data and with how Medicare and many other payers view RPM.

You don’t have to pretend RPM is a magic bullet. It isn’t. But if we’re going to take away a tool many teams use to keep fragile patients out of trouble, we should at least be honest about why.

This policy is about cost and control, not a sudden discovery that remote monitoring “doesn’t work.”

While UHC is tightening, CMS is doing the opposite. If you want to rebuild on a more stable foundation, start with Advanced Primary Care Management and how it fits with RPM and CCM in 2025–26.
‍

👉CMS 2025–26 RPM & APCM Guide

‍

The Neuro-Symbolic Divide

Can We "Un-Smear" the Black Box?

Artificial Intelligence is currently fractured between two powerful but incompatible paradigms.

On one side, we have Symbolic AI. It is defined by clarity and structure. It relies on localist representations—ontologies and knowledge graphs—where every node has a distinct address and meaning. It is perfectly interpretable, extends infinitely, and suffers no context limits. However, it has a fatal flaw: brittleness. It shatters when faced with the noise and ambiguity of the physical world.

On the other side, we have Neural Networks. These are masters of noise, thriving on the messy, distributed patterns of reality. But they are opaque black boxes. Their knowledge is "smeared" across millions of weights in a holographic fog—a phenomenon recently characterized as superposition (Elhage et al., 2022). Because concepts are entangled, we cannot easily peek inside to see what the network knows, nor can we add to it safely. When we attempt to teach a trained network a new fact, the necessary weight updates inevitably disrupt existing patterns, leading to Catastrophic Forgetting (McCloskey & Cohen, 1989).

‍

The Question: Is there a way to combine the infinite, safe extensibility of an Ontology with the noise-tolerance of a Neural Network?

The Hypothesis:

If we use a strict Ontology as a curriculum, can we force a Neural Network to organize itself into discrete, interpretable "blocks" instead of a distributed mess?

To answer this, I developed a novel training protocol called Recursive Ontology-Guided Sparse Zipping (ROGUE-Zip).

The goal of ROGUE-Zip is ambitious: Train a network layer to learn a specific level of an ontology, and then mathematically force that layer to "hand over" the knowledge to the layers below it, resetting itself to a clean Identity Matrix. By combining this with sparsity constraints, we aim to physically sequester knowledge deep in the network—building a neural brain that grows layer by layer, concept by concept, without forgetting what it learned before.

‍

The Apparatus & Implementation‍

Building a "Transparent Box" for Neural Research

To validate the ROGUE-Zip architecture, we first needed to prove the fundamental physics of the "Zip"—the ability to transfer logic between layers without loss. This required a custom tooling approach, eschewing standard black-box libraries for a pixel-perfect visualization of the network's internal state.

1. Biological Inspiration: Systems Consolidation

Our architecture is not arbitrary; it mimics the mammalian solution to the stability-plasticity dilemma. As established by McClelland et al. (1995), the brain utilizes a complementary learning system: rapid acquisition of fragile memories in the Hippocampus, followed by a period of "sleep" (systems consolidation) where those memories are interleaved into the Neocortex for permanent storage.

‍

Standard Neural Networks lack this "Sleep" phase. They are "always awake," meaning every new gradient update impacts the same shared weights as the previous tasks. ROGUE-Zip attempts to engineer a synthetic version of this consolidation cycle, treating the top layer as the Hippocampus (Short-Term Memory) and the lower layers as the Neocortex (Long-Term Instinct).

2. The Mechanism: The Identity Matrix

To implement this consolidation mathematically, we utilize a specific linear algebra concept: the Identity Matrix.

In a neural network, if a layer’s weights form an Identity Matrix (a perfect diagonal line of 1s, with 0s everywhere else), that layer becomes a "ghost." It passes data through unchanged ($f(x) = x$), effectively contributing zero cognitive work to the system.

While Chen et al. (2015) famously used identity initializations to expand network capacity (the "Net2Net" approach), ROGUE-Zip inverts this paradigm. We use asymptotic identity constraints to compress active logic into lower layers, recycling the layer for future tasks.

3. The Physics of Zipping: A Multi-Objective Tug-of-War

The core engineering challenge was creating a training loop that respects two contradictory goals simultaneously. We rejected the standard "Head Switching" approach in favor of a Gradient Superposition strategy.

$$\nabla_{Total} = \nabla_{Distillation} + \lambda(t) \cdot \nabla_{Identity}$$

By slowly ramping the identity pressure ($\lambda$) over thousands of epochs, we create a "Tug-of-War." The layer is forced to straighten out, but the accuracy gradient acts as a tether, ensuring it only straightens as fast as the lower layers (The Trunk) can absorb the logic.

‍

4. Critical Design Decision: The Topological Valve

During early testing, we encountered a theoretical roadblock that caused total collapse. We discovered that the choice of activation function is critical for Zipping.

• The Failure (Standard ReLU): As a layer approaches Identity, it passes raw features forward. If those features are negative, ReLU deletes them ($max(0, -x) = 0$). This renders the transformation non-invertible—the Trunk cannot "pre-compensate" for deleted data.
• The Fix (Leaky ReLU): We switched to a Leaky ReLU. This ensures that even as the layer becomes a "ghost" (Identity), the information pipeline remains open (bijective). Negative values are scaled, not destroyed, allowing the lower layers to adapt.

5. The Interactive Notebook

This is not a static paper; it is a live experiment. To allow for reproducibility and exploration, I built The HCL Trainer v8—a custom, "transparent-box" neural network engine in vanilla JavaScript. It visualizes every weight matrix and activation vector in real-time, allowing us to visually verify that the "Zipping" process is structurally valid and not just a statistical illusion.

[Link to Interactive HCL Trainer v8] (Host your HTML file and insert link here)

We invite you to use this apparatus to replicate the experiments below, specifically contrasting the successful "General-to-Specific" curriculum against the failed "Physical-to-Abstract" curriculum.

‍

Experimental Results‍

The "House of Cards" vs. The "Strong Foundation"

With the apparatus calibrated and the Handover Protocol stabilized, we executed two distinct curriculum experiments to test the limits of the ROGUE-Zip architecture. The results provided a stark contrast between Residual Learning (Success) and Catastrophic Forgetting (Failure), offering critical insights into how neural networks organize hierarchical knowledge.

Experiment A: The Success (L2 $\to$ L3)

The Curriculum: "General-to-Specific"

1. Foundation: Train on L2 Categories (e.g., Mammal vs. Vehicle).
2. Zip: Handover logic to Trunk. (Block 4 $\to$ Identity).
3. Extension: Train on L3 Subgroups (e.g., Dog vs. Car).

The Observation:

As we began training on L3, the "Zip" (Identity Matrix) in Block 4 naturally dissolved. The "OffDiag" score rose rapidly, indicating the layer was mutating to handle the new complexity.

However, the L2 Accuracy (Green Line) remained high (~90%) throughout the entire process.

This is a textbook demonstration of Residual Learning. By Zipping L2, we forced the "Trunk" (Blocks 1-3) to become a robust, general-purpose feature extractor. When we asked the network to learn L3, it did not need to rewrite the Trunk; it simply utilized the existing "Mammal" features and added a fine-tuning layer in Block 4 to distinguish "Dog" from "Cat." The foundation held.

Experiment B: The Failure (L1 $\to$ L2)

The Curriculum: "Physical-to-Abstract"

1. Foundation: Train on L1 Motion (Moving vs. Static).
2. Zip: Handover logic to Trunk.
3. Extension: Train on L2 Categories (Mammal vs. Vehicle).

The Observation:

The moment we applied pressure to learn L2, the system collapsed. The accuracy for the previous task (L1) plummeted, and the network struggled to learn the new task. It was a complete House of Cards collapse.

‍

The Interpretation: The "Gerrymandering" Problem

This failure mirrors the classic Catastrophic Interference phenomenon described by McCloskey & Cohen (1989), but with a specific topological cause. We hypothesize that L1 (Motion) creates Orthogonal Decision Boundaries relative to L2 (Category).

• "Living Things" contains both Moving entities (Mammals) and Static entities (Plants).
• "Non-Living Things" contains both Moving entities (Vehicles) and Static entities (Furniture).

By forcing the Trunk to lock into a "Motion-based" worldview first, we essentially gerrymandered the neural representation. When we later asked it to group "Mammals" and "Plants" together (as Living things), the network had to shatter its existing Motion boundaries to comply. The foundation wasn't just insufficient; it was actively fighting the new structure.

‍

Key Finding: Curriculum Matters

The ROGUE-Zip protocol is powerful, but it obeys the principles of Curriculum Learning (Bengio et al., 2009). These experiments suggest a fundamental rule for Neuro-Symbolic training: The Foundation must be Semantic, not just Statistical.

A "General" foundation (like Categories) creates a trunk that can support specific details. A "Narrow" foundation (like Motion) creates a rigid trunk that shatters when the worldview expands. Zipping works best when we follow the natural hierarchy of the ontology, moving from broad, inclusive concepts down to specific differentiations.

‍

Technical Deep Dive

The Physics of Forcing Identity

While the concept of ROGUE-Zip is intuitive—"make the layer a ghost"—the mathematical implementation is violent. Forcing a non-linear, high-dimensional transformation to collapse into a linear Identity Matrix fights against the natural gradient descent process.

Here is the post-mortem of the technical hurdles we cleared to make the Handover Protocol stable.

1. The Optimization Problem: Orthogonal Gradient Decoupling

In our initial attempts (v4-v5), we tried a "Hard Zip" approach where we manually overwrote the gradients of Block 4:

block4.W.grad.fill(0)

We assumed we could freeze the "Accuracy" optimization and purely optimize for "Identity." This failed because it decoupled the parameters $\theta_4$ from the global loss function. The optimizer marched blindly toward the Identity Matrix $I$, moving orthogonal to the complex manifold required to maintain feature coherence. The result was immediate representational collapse.

The Fix: Gradient Superposition

We moved to a multi-objective optimization strategy. We retained the backpropagated gradients from the distillation loss ($\mathcal{L}_{KD}$) and added the identity penalty gradients:

$$\nabla_{\theta_4} \mathcal{L}_{Total} = \nabla_{\theta_4} \mathcal{L}_{KD} + \lambda(t) \nabla_{\theta_4} \mathcal{L}_{Identity}$$

‍

This turns the process into a dynamic equilibrium. The optimizer finds a path to $I$ that lies within (or very close to) the null space of the accuracy loss, effectively rotating the "Trunk" to compensate for the stiffening of Block 4.

‍

‍

2. The Topological Failure: Non-Injective Mapping

Standard neural networks rely on ReLU ($\sigma(x) = \max(0, x)$).

In the limit where $W_4 \to I$ and $b_4 \to 0$, the function of Block 4 becomes simply $f(x) = \text{ReLU}(x)$.

This transformation is non-injective (not one-to-one). Any feature vector $x$ containing negative components—which often encode critical ontological contrasts—is mapped to $0$. This constitutes an irreversible destruction of information entropy. The Trunk layers ($W_{1-3}$) cannot "pre-compensate" for this because they cannot encode information in the negative domain that survives a pass-through Identity-ReLU block.

The Fix: Bijectivity via Leaky ReLU

We switched to Leaky ReLU ($\alpha = 0.01$). This restores the bijectivity of the transformation. Even as $W_4 \to I$, the mapping remains invertible. The Trunk layers can now preserve negative signals by scaling them by $\frac{1}{\alpha}$, allowing the information pipeline to remain open during the handover.

‍

3. Numerical Instability: The "NaN" Explosion

The Identity penalty term $\lambda ||W - I||_F^2$ creates gradients proportional to the distance from identity. In the early phases of zipping, this distance is large, resulting in massive gradient magnitudes ($||\nabla|| \gg 1$). Without normalization, these updates caused the weights to overshoot, leading to floating-point overflows (NaN).

The Fixes:

1. Gradient Clipping: We implemented hard clipping on the optimizer: $\nabla \leftarrow \text{clip}(\nabla, -1.0, 1.0)$. This enforces a maximum step size in the parameter space, ensuring the local linear approximation of the loss function remains valid.
2. Extended Annealing: We increased the $\lambda(t)$ ramp duration from 500 to 2500 epochs. This reduced the time-derivative of the penalty ($\frac{d\mathcal{L}}{dt}$), giving the trunk network sufficient integration time to "absorb" the logic.

4. Convergence Criteria: Pareto Optimality

Our original code waited for the layer to become a perfect Identity Matrix. We found this to be impossible under Gradient Superposition. Because the $\nabla_{KD}$ (Accuracy) term always exerts some pressure, the system settles at a Pareto Optimal point where the two gradients cancel each other out.

We effectively traded "Mathematical Identity" for "Functional Identity"—a state where the matrix is diagonal enough to act as a pass-through, but noisy enough to maintain 99% accuracy.

5. Design Philosophy: Why Identity? (The "Head Switching" Fallacy)

In standard Continual Learning literature, when a researcher wants to "push" logic to a lower layer, they typically use Early Exits or Head Switching. They simply detach the classification head from Block 4 and re-attach it to Block 3.

We explicitly rejected this approach. Here is why Zipping (Identity Forcing) is fundamentally different from Head Switching, and why it is necessary for the ROGUE-Zip architecture.

A. Active Compression vs. Passive Observation

Head Switching is Passive. It asks: "Does Block 3 happen to know enough to solve the task?"

If Block 3 is only 80% accurate, moving the head accepts that 20% loss. It assumes the "intelligence" naturally resides in the upper layers and stays there.

Zipping is Active. It asks: "Can we force Block 3 to learn what Block 4 knows?"

By maintaining the connection through Block 4 while mathematically pressuring it to be an Identity Matrix, we create a back-propagation gradient that aggressively teaches Block 3. We are not just checking if the trunk is smart; we are making it smart. We are forcing the "Concept" (High-level abstraction) to be rewritten as a "Reflex" (Low-level feature).

B. The "Real Estate" Problem (Recycling vs. Abandoning)

If you simply move the Head to Block 3, Block 4 becomes dead weight. It is bypassed. It sits idle, consuming memory but contributing nothing. You have effectively made your brain smaller.

In the ROGUE-Zip protocol, the goal is not just to bypass a layer, but to recycle it.

By forcing Block 4 to become an Identity Matrix ($W \approx I$), we effectively "hollow it out."

• Current State: It acts as a wire, passing data from Block 3 to the output.
• Future State (The Goal): Because it is an Identity Matrix (linear, sparse-ish), it is the perfect starting point for Sparsity-Guided Re-training. In future phases, we can introduce new neurons into this "hollow" layer to learn Task B, while the "Identity" neurons keep passing Task A data through. You cannot easily recycle a bypassed layer; you can recycle a Zipped layer.

C. The Universal Socket

Standard neural network layers drift apart. The "language" (latent space distribution) spoken by Block 3 is usually totally different from Block 4. Moving a head requires training a brand new "Translator" (adapter).

The Identity Matrix is the Universal Socket. By forcing Block 4 to Identity, we guarantee that the output of Block 3 and the output of Block 4 exist in the same vector space. This topological alignment is critical for deep stacking. It ensures that "Down" is a consistent direction for information flow, preventing the "Covariate Shift" that usually plagues modular neural networks.

Summary: We don't just want to read the answer sooner; we want to push the computation deeper. We are turning high-level "Conscious Thoughts" (Block 4) into low-level "Instincts" (Block 3), clearing the conscious mind for the next new problem.

‍

Risks & Future Horizons

Engaging the Skeptics & Scaling Up

The experiments in this notebook validate the physics of the "Handover Protocol," but translating ROGUE-Zip from a controlled toy experiment to a production architecture requires addressing structural risks and sketching the path to true Neuro-Symbolic hybrids.

1. What Could Go Wrong? (Risks to Scalability)

We must acknowledge that "Toy Tasks" often hide scaling laws. As we move from HCL Trainer to ImageNet or LLMs, we anticipate three specific friction points:

• The "ImageNet" Scaling Problem: In high-dimensional spaces (e.g., layer width 2048+), the Identity Penalty ($\lambda ||W - I||^2$) might be drowned out by the sheer magnitude of the accuracy gradients. We hypothesize that $\lambda$ must be normalized by layer width ($\frac{1}{\sqrt{N}}$) to maintain the tug-of-war balance.
• Batch Normalization Conflict: Standard ResNets rely on BatchNorm, which fights against fixed weight distributions. Forcing weights to $I$ may cause batch statistics to drift or explode. Future implementations may require LayerNorm or "Fixup" initializations to be Zip-compatible.
• Compute Cost: A 2500-epoch ramp is computationally expensive. We are currently investigating "One-Shot Zipping"—using Low-Rank Factorization to approximate the Identity transition instantly, potentially skipping the ramp entirely.

2. Solving Interference: The Sparse Roadmap

The failure of Experiment B (L1 $\to$ L2) was instructive. It revealed that while we can move logic, the "Trunk" can still suffer from Superposition Interference (Elhage et al., 2022). The network used polysemantic neurons to solve L1 (Motion), leaving no orthogonal subspace for L2 (Category).

The Solution: Neural Reservations

To mitigate this, we are developing a Group Lasso protocol (Yuan & Lin, 2006).

Unlike standard weight decay, Group Lasso enforces neuron-level sparsity (forcing entire columns to zero).

• Step 1: Train the foundation with high Group Lasso, forcing the network to solve the task using only 20% of neurons.
• Step 2: When we Zip and switch tasks, the active neurons are locked, but the 80% "Dead" neurons wake up to handle the new semantic structure.

3. The Neuro-Symbolic Vision

This project is not just about Continual Learning; it is a path toward "Un-Smearing" the black box.

The fundamental problem with neural networks is their holographic nature. A single concept, like "Mammal," is distributed across millions of weights. To change that concept, you must touch all those weights, inevitably disrupting everything else.

The vision of ROGUE-Zip is to force the neural network to betray its own nature. By using a strict Ontology as a curriculum, and then Zipping and locking layers one by one, we aim to coerce the network into organizing itself into discrete, modular blocks. We are trying to build a brain where "Mammal" lives in Block 3, Neurons 10-50, and "Vehicle" lives in Block 3, Neurons 60-100.

If successful, this architecture would transform the neural network from an opaque smear into a structured, queryable engine—combining the noise-tolerance of deep learning with the modularity and infinite extensibility of a symbol system

References

1. Bengio, Y., et al. (2009). Curriculum learning. Proceedings of the 26th Annual International Conference on Machine Learning (ICML).
2. Chen, T., Goodfellow, I., & Shlens, J. (2015). Net2Net: Accelerating Learning via Knowledge Transfer. International Conference on Learning Representations (ICLR).
3. Elhage, N., et al. (2022). Toy Models of Superposition. Transformer Circuits Thread.
4. McClelland, J. L., McNaughton, B. L., & O'Reilly, R. C. (1995). Why there are complementary learning systems in the hippocampus and neocortex. Psychological Review.
5. McCloskey, M., & Cohen, N. J. (1989). Catastrophic interference in connectionist networks. The Psychology of Learning and Motivation.
6. Yuan, M., & Lin, Y. (2006). Model selection and estimation in regression with grouped variables. Journal of the Royal Statistical Society: Series B.

‍

If you are billing RPM for Diabetes, Hypertension, or COPD under UHC, your claims will likely be denied starting January 1st.

If UnitedHealthcare (UHC) is a significant payer for your practice, you need to audit your Remote Patient Monitoring (RPM) panel immediately.

Quietly buried in their December 2025 policy bulletins, UHC has announced a massive restriction on RPM coverage that goes into effect January 1, 2026.

Unlike CMS, which is expanding remote care through new payment models like APCM, UHC is moving in the opposite direction. They are adopting a strict "proven vs. unproven" stance that effectively eliminates RPM coverage for the vast majority of chronic conditions.
‍

The New HF/HDP Standard

Starting Jan 1, UHC will consider RPM "Proven and Medically Necessary" for only two primary indications:

1. Heart Failure (HF)
2. Hypertensive Disorders of Pregnancy (HDP)

For almost every other common chronic condition, including Type 2 Diabetes, Essential Hypertension, COPD, Anxiety, and Sleep Apnea, UHC has explicitly flagged RPM as "Unproven and Not Medically Necessary."

What This Means for Your Revenue

If you are currently billing codes 99453, 99454, or 99457 for a UHC patient with diabetes or standard hypertension, you face a high risk of automated denials beginning in the new year.

This applies across Commercial, Medicare Advantage, and Medicaid (Community Plan) lines of business.

Dont Panic. Pivot.

This policy change is aggressive, but it is manageable if you act before the deadline.

• You need to identify every UHC patient currently on RPM.
• You need to verify if they have a qualifying Heart Failure or Pregnancy diagnosis.
• If they don't, you need to transition them to Chronic Care Management (CCM) or other care models before Dec 31st to avoid revenue disruption.

Get the Red Alert Survival Guide

We have compiled a comprehensive resource breakdown of this policy update. It includes the specific policy numbers, a decision tree for your patient panel, and a guide on which "safe harbor" codes (like CCM and RTM) are still viable.

👉 Read the Full Guide: The 2026 UnitedHealthcare Remote Care Shift

How We Automate This Rule

Reading the policy is one thing. Enforcing it across 2,000 patients is another. In FairPath, our Payer Ontology now reflects the 2026 UHC restrictions and automatically cross-references Payer (UHC), Diagnosis (I10 vs I50.9), and Program (RPM) so teams know where RPM is and is not covered.

• Patient records are evaluated against the updated UHC policy logic inside the Payer Ontology.
• When a UHC member is tied to a non-covered diagnosis for RPM, the enrollment workflow surfaces a clear “Not Covered” flag.
• Clinicians and staff can redirect patients into APCM/CCM-first pathways without wasting setup time or billing attempts.

Related Resources for Your 2026 Strategy

The UHC shift is just one part of a chaotic year for remote care. As you restructure your remote care program, use these tools to ensure you remain profitable and compliant:

• The CMS Strategy: While UHC restricts, CMS is expanding. Learn how to pivot to the new Advanced Primary Care Management model. Read the Guide: CMS 2025-26 APCM/RPM
• The Economics: Losing RPM coverage for UHC patients hurts. See how it impacts your bottom line if you are still paying a vendor. Run the Vendor Profit Analyzer
• The Compliance Check: With policies changing this fast, audits are inevitable. Ensure your documentation is bulletproof. Download the 2026 OIG Audit Survival Guide

‍

The $1.2 Million Mistake Most Practices Are Making Right Now

If your practice adopted APCM by shutting down RPM and RTM programs, you left money on the table. If you're running all three programs separately, you're burning cash on duplicate documentation and exposing yourself to compliance risk.

The correct answer isn't either-or, its coordinated integration. Practices that get this right are generating $225-325 net margin per patient monthly while reducing administrative burden by up to 30%.

Here's how the economics actually work, and what separates winning practices from everyone else.
‍

Why Practices Get This Wrong

CMS introduced APCM as a structural upgrade to care management, not a replacement for monitoring programs. Yet most practices treat it as one:

The Replacement Trap: Practices abandon profitable RPM and RTM programs, assuming APCM covers everything. It doesn't. You lose monitoring revenue and weaken care continuity.

The Silo Trap: Practices run all three programs independently, creating redundant workflows, conflicting documentation, and billing errors that invite audits.

Both approaches cost you money. The first sacrifices revenue. The second burns it on overhead.
‍

The Integration Model: Three Programs, One System

Successful practices recognize that APCM, RPM, and RTM serve distinct clinical and financial functions:

APCM provides the overall care management structure—provider accountability, care planning, and transition management.

RPM and RTM deliver continuous patient data that drives specific interventions within that structure.

Integration means these programs share one care plan, one documentation system, and one accountability framework. You bill separately for each service, but you execute them as a unified operation.
‍

What This Looks Like Operationally

Single Care Plan: RPM glucose readings or RTM therapy adherence data flow directly into the APCM care plan, triggering interventions automatically.

Unified Task Management: All outreach, education, and monitoring tasks appear on one centralized list—not scattered across three platforms.

Automated Documentation: Software captures activity in real time, meeting all program-specific billing requirements without duplicate data entry.

One Accountability System: Care navigators, nurses, and providers coordinate under a single supervisory framework rather than juggling separate program rules.

This eliminates the false trade-off between patient volume and compliance. Practices scale both simultaneously.
‍

The Financial Case: Real Numbers from In-House Programs

Most practices running siloed programs capture $150-180 per patient monthly across RPM or basic care management. They're leaving significant reimbursement unclaimed.

Integrated in-house APCM + RPM + RTM programs using modern automation generate $250-350 per patient per month in combined reimbursement. Program costs run approximately $25 per patient monthly ($10 software, $15 per device rental).

Net margin per patient: $225-325 per month, depending on complexity and time documented.

Staffing efficiency compounds these gains. In siloed programs, a three-person care team (two RNs, one MA) manages 600-700 patients due to documentation overhead and system friction. Integrated systems with automation enable the same team to handle 900-1,000 patients while maintaining compliance.

The financial impact is substantial:

Traditional siloed model:

• 700 patients × $160/month = $112,000 monthly gross revenue
• Higher admin overhead, fragmented workflows
• Est. 40% margin after labor and overhead = $44,800 monthly profit

Integrated in-house model:

• 950 patients × $290/month = $275,500 monthly gross revenue
• ~$25/patient program costs = $23,750 monthly
• Same care team, 25% less admin time
• Est. 55% margin after all costs = $151,525 monthly profit

That's a $106,725 monthly difference, or $1.28 million annually, with identical headcount.

These figures reflect actual CMS reimbursement rates and reported results from practices running integrated programs in 2024-2025. The difference comes from eliminating waste and capturing all available compliant reimbursement—not from aggressive billing.

Clinical Scenarios Where Integration Drives Value

Chronic Disease Management (RPM + APCM)

A diabetes patient's RPM glucose monitor flags elevated readings. In an integrated system, those readings automatically update the APCM care plan and trigger an intervention protocol. One documentation event satisfies both programs' billing requirements.

Post-Surgical Rehabilitation (RTM + APCM)

A patient recovering from knee surgery stops engaging with home therapy exercises tracked through RTM. Integrated software alerts the APCM care team immediately, enabling intervention before outcomes deteriorate. Both programs bill compliantly from the same workflow.

Complex Post-Hospitalization Care (RPM + RTM + APCM)

A COPD patient discharged from the hospital needs breathing monitoring (RPM), therapy adherence tracking (RTM), and transition management (APCM). All three run from one system, preventing readmission while maximizing compliant reimbursement.

In each case, integration creates clinical value and financial value simultaneously—not by gaming the system, but by eliminating waste.

Compliance: The Four Non-Negotiables

Integration increases revenue only if you maintain clear program separation in documentation and billing:

Differentiate Services Clearly: Document what RPM, RTM, and APCM each provide. Never blur the lines.

Prevent Time Overlap: If you bill 20 minutes for APCM, that same 20 minutes cannot count toward RPM time requirements.

Document Care Transitions: APCM requires thorough transition documentation. Automate this wherever possible, but verify completeness.

Audit Monthly: Run internal reviews to catch billing errors before external audits do.

Automation handles most of this oversight, but governance remains essential. The practices that avoid trouble treat compliance as a system design problem, not a documentation problem.

Why Automation Is Non-Negotiable

Integration without automation is theory. Automation makes it operational reality.

Platforms like FairPath centralize patient records, automatically manage care tasks against billing criteria, and generate audit-ready documentation in real time. This isn't about convenience—it's about making integration financially viable.

Without automation, the administrative load of running three coordinated programs exceeds the efficiency gains. With automation, you unlock the full revenue potential while reducing overhead.

What to Do Next

If you're running APCM, RPM, or RTM in isolation, you're likely generating $150-180 per patient monthly—and leaving $100-170 per patient unclaimed. If you're avoiding APCM because you think it conflicts with existing programs, you're missing a seven-figure annual opportunity.

The strategic question isn't whether to integrate. It's how quickly you can operationalize integration with the right automation and cost structure to capture $225-325 net margin per patient.

Do This Next:

1. Audit your current APCM, RPM, and RTM programs separately—identify overlap, gaps, and billing inefficiencies
2. Calculate your current per-patient monthly net margin across all programs (including software and device costs)
3. Model the revenue impact of full integration using the $225-325 net margin per patient benchmark and your current census
4. Evaluate whether your current software can support unified workflows or if you need a purpose-built platform
5. Schedule a 45-minute APCM Integration Review to map your specific opportunity and compliance requirements

Integration isn't the future of care management—it's the present. The only question is whether you'll capture the opportunity this year or watch competitors do it first.
‍

Disclaimer: This article provides general information only. Specific reimbursement rules and eligibility vary by MAC, payer, and contract year. Consult with compliance and billing specialists before implementing new programs.

‍