What 5 Years With Kencor Health Taught Us About RPM Compliance

Most RPM compliance content is written in the abstract. It lists frameworks, references HIPAA, and tells you to "implement proper security controls."

That is not very useful when you are a CTO at a scaled Health IT company trying to close a deal with a hospital system, or a Head of R&D trying to build out a software layer for your medical device.

This blog is built on five years of actual product delivery with Kencor Health, whose SAMi platform is a real remote patient monitoring product used in real clinical settings. The numbers at the end of this story are not hypothetical.

• 67% reduction in hospital readmissions
• 156% increase in billing revenue
• 87% patient engagement rate
• 71% medication adherence rate
• Zero HIPAA breaches across a five-year partnership

These outcomes did not happen because the team was lucky with compliance. They happened because compliance was built into the product, not layered on after the fact.

Here is what that actually looks like in practice.

RPM Compliance Gaps Most Teams Miss

Remote patient monitoring sits at the intersection of three things that are each difficult on their own: healthcare data privacy, real-time clinical workflows, and reimbursement billing. When you combine all three, compliance becomes extremely easy to get wrong.

Based in the American Journal of Managed Care, RPM adoption in the US has grown by over 300% since 2019. With that growth has come regulatory attention.

The common failure pattern we see across RPM products is not one large breach or one obvious gap. It is a collection of small decisions that stack up over time and create a platform that cannot pass an enterprise audit, cannot support hospital-grade reimbursement workflows, and cannot scale without significant technical rework.

Five years with Kencor Health taught us exactly what those small decisions look like and how to make better ones from the start.

Read more: Remote Patient Monitoring Architecture: The Stack That Survived 5 Years

Lesson 1: Compliance Is a Product Decision, Not a Legal One

The first and most important lesson from the Kencor engagement is that compliance cannot live in a legal document or a checkbox exercise. It has to live in the product itself.

When SanoWorks joined the Kencor team, the goal was to strengthen the SAMi platform with AI-driven analytics, better patient communication tools, and automation-first design. But every one of those product decisions carried a compliance dimension.

What this looked like in practice:

• AI analytics required audit trails for clinical insights
• Patient communication followed HIPAA minimum necessary standards
• Reimbursement automation aligned with CMS billing compliance rules

The practical result: Zero HIPAA breaches across five years. Not because the team ran quarterly compliance reviews, but because the product was built to make non-compliant actions structurally difficult.

If your compliance approach depends on people following rules correctly every time, it will eventually break. The more reliable model is to build a product where the compliant path is also the easiest path.

Lesson 2: Reimbursement Compliance Is Clinical Compliance

One of the most costly misunderstandings in RPM is treating billing and clinical compliance as separate workstreams. They are not.

CMS requires specific documentation to support RPM reimbursement. To bill under CPT 99457, for example, a clinician must spend at least 20 minutes per calendar month on interactive communication. That is a clinical requirement with a billing output. If your platform does not capture and store that interaction time in a way that is auditable, you have a compliance problem and a revenue problem at the same time.

The Kencor Reimbursement Compliance Framework (how SAMi handled this):

The 156% increase in billing revenue at Kencor was not primarily a sales outcome in fact it was a product outcome. The platform was built to capture and document the clinical activity that justifies reimbursement, and it did so automatically rather than relying on manual input from clinical staff.

If your RPM platform does not handle this end-to-end, you are almost certainly leaving reimbursement on the table and creating audit risk at the same time.

Lesson 3: Patient Engagement Is a Compliance Lever

Most health IT teams think of patient engagement as a product quality metric. Kencor's experience shows it is also a compliance asset.

RPM programs that achieve lower engagement have higher rates of gaps in monitoring data. Gaps in monitoring data create two problems:

• They reduce the clinical value of the program (fewer data points, weaker clinical picture)
• They create reimbursement risk (CMS requires consistent data collection to support billing)

Kencor's 87% patient engagement rate and 71% medication adherence rate were not achieved by luck. The SAMi platform was designed with patient communication tools that made it easy for patients to stay connected to their monitoring program.

Automated reminders, condition-specific modules that made data submission feel relevant rather than administrative, and clear feedback loops between patients and care teams all contributed.

The compliance benefit: Higher engagement means fewer data gaps. Fewer data gaps means stronger billing documentation. Stronger billing documentation means more defensible reimbursement claims during audits.

If your RPM platform treats engagement as a nice-to-have, it is also creating compliance and revenue risk.

Lesson 4: Long-Term Partnerships Surface Compliance Drift

One of the most underappreciated aspects of the Kencor engagement is that it lasted five years. That is not common in health IT development.

Most HealthTech products are built, launched, and then maintained by teams who were not involved in the original design decisions. Compliance documentation written during development becomes out of date. Security controls implemented at launch are not updated as the platform scales. New features are added without proper risk assessment.

This is compliance drift. It is quiet, it is gradual, and it is one of the leading reasons why platforms that passed initial audits fail subsequent ones.

What five years of continuous partnership prevented:

• New EHR and device integrations underwent compliance reviews before production deployment
• Security controls evolved with changing threats, not just discovered vulnerabilities
• Billing logic was updated alongside 2022 and 2024 CMS RPM reimbursement changes
• Clinical decision audit trails remained consistent across product updates

A platform that has been in production for three or more years without this kind of ongoing oversight is very likely to have gaps. The question is whether you find them in an internal audit or a hospital due diligence process.

Lesson 5: Zero Breaches Is an Engineering Outcome

The zero HIPAA breach record across five years is the outcome that tends to get the most attention. It is worth being specific about what made it possible.

A HIPAA breach in an RPM context does not only mean a hacker stealing data. It includes:

• Unauthorized staff access to patient records
• PHI shared through non-encrypted channels
• Missing BAAs with third-party PHI vendors
• Patient data sent to incorrect recipients

Each of these is an engineering problem as much as a policy problem.

The technical controls that kept SAMi clean:

• RBAC based on clinical responsibilities, not job titles
• End-to-end encryption across devices, platforms, and EHR systems
• Third-party PHI vendor checks with signed BAAs before integrations
• Automated PHI routing validation to prevent misdirected communications

None of these controls are exotic. They are standard in well-run health IT teams. What made the difference at Kencor was consistency. The same standards were applied to every new feature, every new integration, and every new vendor across five years.

RPM Compliance Stack: What Your Platform Actually Needs

Based on the Kencor engagement and broader experience across RPM builds, here is a practical view of what a compliant RPM platform needs at each layer.

If your platform has gaps at the billing logic or clinical documentation layer, you are likely losing revenue and creating audit exposure at the same time. If your gaps are at the security or interoperability layer, you are at risk of failing hospital enterprise due diligence.

Read More: HIPAA in 2026: What Changed, What Didn't, and What Your Team Must Know

What This Means for Healthcare Product Leaders

The Kencor story is directly relevant to the challenges faced by scaled Health IT companies and digital health platforms that are growing past early product market fit.

If you are a CTO or VP of Engineering: The compliance questions you will face in enterprise hospital deals are not just about certifications. Buyers will want to see how your platform handles audit trails, how your FHIR integrations manage data integrity, and how your security controls are maintained over time. Five years of zero breaches and clean billing logic is a stronger answer than a SOC 2 report alone.

If you are a Head of Regulatory Affairs or R&D Director: RPM compliance has a clinical dimension that goes beyond software security. CMS billing rules, clinical documentation standards, and patient consent requirements all need to be reflected in how the product is built, not just in your compliance documentation.

If you are a CIO evaluating RPM vendor partnerships: The most important signal is not which compliance frameworks a vendor lists. It is whether their product was designed to make compliant workflows the natural path, and whether they have a track record of maintaining that over time.

RPM Compliance: Quick Reference Numbers

Conclusion

Five years working with Kencor Health reinforced one thing clearly: audit-ready RPM platforms are built through continuous engineering discipline, not last-minute compliance preparation. Teams that treat compliance as part of product architecture, clinical workflows, and operational design are the ones that keep hospital contracts, pass audits confidently, and scale revenue without increasing risk.

For CTOs, VPs of Product, and regulatory leaders, the real challenge is not simply becoming compliant. It is building an RPM platform that remains compliant, defensible, interoperable, and financially sustainable as the business grows.