How We Replaced Five Disconnected Tools with One Secure System, and Gave a Distributed Healthcare Network Full Visibility for the First Time
CPCG’s OCSR model was trusted by healthcare providers across the US. The infrastructure running it, spreadsheets, AnyDesk, Splashtop, and manual coordination, could not scale with it. We built one platform that automated kiosk connections, enforced shift-based access, gave managers live visibility across every location, and gave compliance teams a full audit trail where none existed before. Five tools became one. Every shift now starts in seconds.
Collaborative Patient Care Group (CPCG) is a Washington, DC-based outsourcing and consulting firm serving healthcare providers across the United States. They support medical clinics, pharmacies, and DME/HME providers with administrative operations, revenue cycle management, and technology-enabled workflows, deploying tools like Microsoft Power Platform, Power BI, and SharePoint to reduce the burden on clinical teams.
One of their core service models is the On-Screen Customer Representative: remote agents who support patients at unattended kiosks located in medical supply stores and healthcare facilities. The kiosk acts as a physical touchpoint; the OCSR, sitting anywhere in their offshore support center, provides the human presence behind the screen.
When they came to AppVerticals, CPCG’s service model was working. The infrastructure holding it together was not. They needed a technology partner who could understand a distributed, compliance-sensitive healthcare operation, not a vendor selling them a remote access tool, and not a team that would hand them five integrations and call it a platform.
There’s a pattern we recognize in service organizations that have scaled through relationships and reputation: the quality of the offering gets ahead of the infrastructure that delivers it. CPCG had built an OCSR model that healthcare providers trusted. What they didn’t have was a platform that could run it at scale without the operations team carrying most of the coordination weight manually.
Every shift started with friction. An OCSR coming online had to check a spreadsheet for their assigned kiosk, open a separate communication tool to confirm the assignment, launch AnyDesk or Splashtop to attempt a connection, and then wait, sometimes for on-site consent that didn’t come, before the session could begin. When a connection failed during a valid shift window, there was no central log to show whether the problem was the kiosk, the tool, or the schedule. Someone had to investigate manually.
Managers had no live view of what was happening across the network. Which kiosks were active? Which OCSRs were idle? Which sessions had run long? None of these questions had an immediate answer. Compliance monitoring, ensuring sessions ran only within scheduled windows, that agents were where they were supposed to be, depended on after-the-fact review rather than real-time control.
And there was no audit function. If a session quality issue was raised, verifying it required going back through disconnected tool logs, if logs existed at all. For a healthcare-adjacent operation where accountability and documentation matter, this wasn’t a minor gap. It was a liability.
The brief was clear enough: build a unified remote support platform. What we pushed to understand before writing a line of code was what was actually causing the friction, and in what order those causes needed to be addressed.
The answer shaped everything. The OCSR experience was broken at the first step: connection. Scheduling visibility, monitoring, and collaboration features are only valuable if the fundamental act of connecting to a kiosk is reliable, instant, and doesn’t require a person on-site. We built the remote access and automated kiosk unlock layer first, not because it was the most complex feature, but because every other feature in the system depended on it working.
We sequenced schedule-based access control second, because this was the mechanism that gave the entire operation structure. OCSRs connecting only during assigned windows transform idle kiosks, early logins, and shift overruns from invisible events into auditable ones. The access layer and the scheduling layer together created the compliance foundation the client needed before they could meaningfully use any reporting or monitoring tools we built on top.
The role-based portals, audit module, real-time dashboards, collaborative session tools, and skill-based assignment engine were built last, on top of a system that already knew who was connected, to what kiosk, during which scheduled window, and for how long. That sequencing kept the architecture clean and gave CPCG a platform they could validate incrementally. Each phase worked before the next one began.
The platform covers every part of CPCG's kiosk operation, from the moment an OCSR logs in to the moment a super admin reviews session quality the following morning.
Before any screen went into design, we mapped the full permission and role structure across all four user types, OCSR, Store Manager, Org Admin, and Super Admin. CPCG’s operation involves multiple organisations, multiple store locations, and multiple kiosks per store, each with different scheduling rules and access requirements. Building individual modules without a shared data model underneath would have produced a platform that looked unified and behaved like separate tools. We started there.
The desktop clients, built in Electron JS for both the kiosk and OCSR sides, and the web portals were developed in parallel rather than sequentially. This let us test role interactions against real data early, catching permission edge cases before they became integration problems. The Zoom SDK powered the remote desktop and video layer; SendGrid handled system-wide notifications across all role levels. AWS infrastructure was provisioned with the session volume and geographic distribution of the kiosk network in mind.
We ran the audit module and collaborative session features in close collaboration with CPCG’s operations leads, mapping the actual sequence of a quality review, and the actual steps an OCSR takes when pulling in a colleague during a complex patient interaction, before building either. The specificity of those workflows only came from having the right people in the room during the design phase. We made sure they were.
CPCG’s OCSR network now operates from a single platform that covers every part of its remote delivery model, session initiation, schedule enforcement, live monitoring, quality auditing, and inter-agent collaboration.
The five-tool stack that every OCSR navigated at the start of every shift is gone. Kiosk connections are automated and consent-free. Schedules are visible, enforced, and logged. Managers have a live view of session activity across the entire network. Super admins can join a session silently for quality review without interrupting the OCSR or the patient interaction on the other end.
The compliance and audit infrastructure that the previous setup couldn’t provide now exists as a platform property rather than a coordination task. As CPCG adds kiosk locations, brings on new client organisations, or expands its OCSR headcount, the platform absorbs that growth without requiring the operations team to manage more, because the management is already built in.
"We needed more than just remote access, we needed a system our whole operation could run on. AppVerticals understood our compliance needs and role complexity from day one. They built a tool so advanced and complex that it runs our operations.”
Managing a distributed remote support network across physical locations, in healthcare or any compliance-sensitive environment, requires more than remote access software. We've built this before. We know what it takes.
Start a conversation