Community Health Worker Software: Why a Home Visit With No Signal Still Has to Reach a Payer

Why community health worker programs break the software they inherit

The software a community health worker program gets handed is almost always built for someone else. Either it is a slimmed down clinical record designed for a provider sitting in an exam room with a wired connection, or it is a form collection tool built for field research. Neither one matches the actual job.

The actual job looks like this. A worker parks outside a third floor walkup at 10am. There is no cell signal in the stairwell and none in the apartment. She spends 50 minutes with a client who has uncontrolled diabetes, no working refrigerator for insulin, an eviction notice on the counter, and a daughter who translates. She arranges a food pantry referral, calls the utility company on speaker, documents a housing instability concern, and flags a blood sugar reading that needs a nurse to look at it today. She leaves, drives to the next visit, and the phone reconnects somewhere on the arterial road.

That encounter has to become three things at once: a clinical escalation that reaches a supervising provider within hours, a referral with a closed loop back to the pantry, and a documented service that a payer will reimburse. Clinical systems handle the first badly from a phone and not at all offline. Form tools handle the capture and nothing downstream. So programs run three parallel systems and a WhatsApp group, and the reconciliation happens on a supervisor's laptop on Friday.

The cost shows up in two places. Encounters that never turn into revenue because the documentation missed an element the payer requires. And escalations that arrive late because the only path from a kitchen table to a nurse was a text message that got buried.

Problem 1: offline is the operating condition, not an edge case

Most software calls offline support a feature and implements it as a cache that syncs when convenient. In this work, offline is where the job happens. Basements, rural roads, buildings with thick walls, phones on prepaid plans that throttle. A worker may document six encounters before anything reaches a server.

CommCare deserves credit here. It was built offline first for exactly this kind of field work and it does that part properly. Where it stops is everything after capture: it is a data collection platform, so the encounter it produces is a form submission, not a service line that adjudicates against a payer rule or a task that escalates to a clinician on a clock. Julota takes the opposite approach, focusing on consent based data sharing across agencies, which is genuinely useful when your program sits in a multi agency coalition, but it is not a field productivity tool for a worker with a phone and no signal.

A build has to make offline a design constraint everywhere, not just on the form. That means conflict resolution when a supervisor edited a care plan while a worker was underground, a local queue for photos and signatures that survives the app being killed, deterministic identifiers generated on the device so a duplicate client is not created on sync, and a visible sync state so the worker knows what has landed. Get this wrong and workers stop trusting the app, which means they write on paper, which means you are back where you started with worse morale.

Problem 2: a non clinical encounter still has to satisfy a payer

Reimbursement for this work has moved fast. Medicare introduced community health integration services in the 2024 physician fee schedule, and a growing number of state Medicaid programs now cover community health worker services, generally with their own certification, supervision and documentation requirements. The details differ by state and they change, which is precisely why this is hard to buy.

The documentation rules are unforgiving in a specific way. A payer typically wants an identified need tied to a diagnosis or a health related social need, a supervising provider relationship, an initiating visit, time spent, and a service that matches a defined activity. A free text note saying the worker helped with housing satisfies none of that. What gets billed is structure.

So the encounter form in a custom build is not a questionnaire, it is a service definition. Activity types map to billable codes. Time capture is a real field with a start and stop, not a guess typed at the end of the week. Health related social needs are recorded as coded values so they can also appear on a claim and in your outcome reporting. And the system knows which of your workers were certified and supervised on the date of service, because a payer will ask. When a worker finishes an encounter, the app should already know whether it is billable and tell her what is missing, in the driveway, not three weeks later in a denial.

Problem 3: caseload assignment is geography, language and trust

Assigning caseloads by alphabet or by whoever has capacity wastes the thing that makes this model work. A worker who lives in the neighborhood, speaks the language, and has already knocked on that block is worth several from across town. Programs know this and do it manually, which caps the program at whatever a supervisor can hold in her head.

Assignment logic worth building considers travel geography rather than zip codes, since a river or a highway matters more than a boundary line. It considers language and dialect, not just a language field. It weights continuity, so a client who has met one worker keeps her. It respects declared conflicts, because in a small community the wrong pairing is a real problem. And it accounts for acuity, so a caseload of 60 stable clients and a caseload of 25 in crisis are not treated as the same load.

Route sequencing on top of that is worth the effort once workers do four or more visits a day. Not to squeeze more visits in, but because a worker who is not driving across the county twice has time to do the visit properly.

Problem 4: safety and supervision happen in real time or not at all

Your workers enter homes alone. Some of those homes are unpredictable. A safety model that consists of texting a supervisor is not a model, it is a hope.

What a build should include: a check in on arrival and departure with an expected duration, an escalation if a worker does not check out within a window, a discreet alert control that does not look like an emergency button to anyone watching, and a location share that is on during a visit and off the rest of the day, because workers will not adopt a system that tracks them at dinner. Address level notes about prior incidents should be visible before the worker knocks, not filed in a supervisor's inbox.

Supervision has the same real time problem. When a worker flags a clinical concern from a kitchen table, that has to reach a supervising nurse or provider with a response clock attached, and the loop has to close so the worker knows what happened. Programs lose good workers to the feeling that they escalate into a void.

Problem 5: certification and training decide whether you get paid

Where states have built community health worker reimbursement, they usually attach certification requirements, continuing education, and a supervision relationship that has to be documented. That turns a training tracker from a human resources (HR) nicety into a billing control.

The build should hold each worker's certification with an expiry, the training hours completed against the requirement, the supervising provider relationship with effective dates, and the ability to answer one question instantly: on this date of service, was this worker eligible to deliver this service under this payer. If the answer is no, the encounter should never reach a claim file. Discovering this after submission is how programs end up returning money.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this shape prices as follows. A focused first release with an offline capable mobile app, structured encounter documentation mapped to billable activities, caseload assignment, and supervisor review and escalation runs $55,000 to $120,000 and ships in 10 to 16 weeks. A full platform adding closed loop referrals with partner organization accounts, certification and supervision tracking, claim file generation, safety check in and escalation, and program outcome reporting runs $140,000 to $320,000 phased over 6 to 12 months.

What drives cost up in this category specifically: the number of payers, because each one has its own documentation elements and file format. Integration with a health system electronic health record, since a read of the clinical record and a write back of the encounter are two different projects and the write back is the hard one. Multilingual field interfaces, which is more than translation because forms and consent language have to be reviewed. And any requirement to exchange data with a community information exchange or a coalition of agencies, where consent management becomes its own subsystem.

What keeps cost down: one payer, one language pair, and a referral loop that starts with your five highest volume partners rather than a directory of two hundred.

Build versus buy, and when buying is the right call

Buy if your program is grant funded, under about 15 workers, and nobody is billing. CommCare will collect your data reliably in the field and cost you very little, and a custom platform would be a distraction from hiring more workers. Buy Julota if your defining problem is sharing consented client data across a police, fire, hospital and community organization coalition, because that is what it is designed around and rebuilding it is not a good use of money.

Build when two or more of these are true. You bill Medicaid or a managed care plan for community health worker services and denials are a live problem. Your workers routinely document in places with no connectivity and paper has crept back in. You run more than about 25 workers, which is where manual caseload assignment stops scaling. You escalate clinical concerns to a provider who works in a different system and the handoff is a phone call. Or you are accountable for outcomes to a health plan contract, which means you need encounter level data joined to utilization, and no form tool will give you that.

The tipping point is billing plus scale. A program that only reports to a grant can live with almost anything. A program whose sustainability depends on reimbursement needs its documentation to be structured at the point of capture, in a stairwell, with no signal.

How to choose a developer

Ask them how the app behaves when a worker documents three visits underground and then the phone dies before sync. If the answer is that data is cached, keep asking until you hear about durable local storage, deterministic identifiers created on the device, and conflict resolution rules. Anyone who has shipped real field software has scars from this and will tell you about them.

Ask them to describe a billable encounter as a data model. You want to hear activity type, time in and time out, health related social need coding, supervising provider, and worker certification status on the date of service. If you hear notes and attachments, they are building a diary.

Ask what they have integrated with. An electronic health record read via a standard interface, a Medicaid managed care encounter file, and a community resource directory are three separate efforts, and the specific systems you use should be named back to you with a timeline rather than waved at.

Ask how consent is modeled if your program shares data with partner agencies. Some records, including substance use treatment information under federal rules, carry disclosure restrictions that a general permissions system will not respect. A developer who raises this unprompted has done the work before.

Ask who owns the code and settle it before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit, and any vendor who resists that is building a dependency you will pay for later.