Community Health Worker Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the scope creep from an offline visit form into a clinical record?

The brief is a field app for home visits. By the time it is specified it includes care plans, medication lists, vital signs, provider notes and a message thread with the clinic, and the project is now building a small electronic health record with none of the budget or the regulatory groundwork one requires.

The drift starts from a real need. Workers do encounter clinical information, and supervisors do need to escalate. But there is a large difference between recording that a client reported a blood sugar reading and holding that reading as clinical data of record. The first is an observation with a source attached. The second brings clinical data governance, provider workflow and a much heavier compliance posture, and it puts your programme in the position of maintaining a clinical record that the health system will not trust anyway because it did not originate there.

The fix is a boundary stated in the specification. Your system holds the encounter, the referral, the health related social need and the escalation. Clinical facts are captured as reported observations with a source and a timestamp, and they travel to a clinician as a task with a response clock rather than being stored as a diagnosis. If a supervising provider wants that observation in the chart, it is written into their system as a note, not held as truth in yours.

Say this out loud in the first scoping session, because the alternative is a two year project in a programme funded a year at a time.

What goes wrong when you migrate client rosters, consent and encounter history?

Duplicates, missing consent, and encounter history that cannot be replayed.

Duplicates come first because your roster arrives from several places: a health plan file, a hospital referral list, a paper intake, and the workers' own outreach. The same person appears with a different name spelling, a different date of birth transposition and two addresses. Merging on name and date of birth alone will merge two different people, which in this population is worse than leaving duplicates, because a merged record can attach one family's history to another. Merge deliberately with a worker confirming, and keep the merge reversible.

Consent is the one that stops work. If your programme shares data with partner agencies, each client's consent has a scope and a date, and consents captured on paper often do not say what a data sharing system needs them to say. Migrating a scanned form as an attachment gives you storage rather than permission. Some records, including substance use treatment information under federal rules, carry disclosure restrictions that a general permissions model will not respect. Get this reviewed by counsel before the migration, not after a partner asks for data.

Encounter history is the third. Old records are prose, so they cannot be reclassified into billable activity types retrospectively, and you should not try. Load them as reference, keep them searchable, and start structured capture from go live. Programmes that attempt to retro code a year of narrative notes spend months producing data nobody will defend in an audit.

Why do health record and payer file integrations break after launch?

Because one of them depends on another organisation's release calendar and the other depends on rules that change without you being told.

The health record side has an asymmetry worth planning around. Reading clinical context is comparatively straightforward. Writing the encounter back into the clinical record is a different project entirely, and it depends on a health system's willingness, their interface team's queue and their governance review. Treat the write back as its own phase with its own timeline. Programmes that promise it in release one usually deliver neither the write back nor the field app on time.

The payer side fails through drift. Each payer has its own file format and its own required elements, and both change. A field that was optional becomes mandatory, a code set is updated, or a plan changes its submission window. Your file keeps generating and the rejections arrive weeks later in a report nobody owns. The pattern is always the same: no error at the point of failure, a delay before the consequence, and by then a month of encounters is affected.

Two controls handle most of it. Validate every encounter against the payer's current required elements at the point of capture, so the worker is told what is missing in the driveway rather than three weeks later. And give every submitted encounter a state that ends in paid, denied with a worked reason, or written off with an approval, with anything stuck in between appearing on a named person's queue. A rejection report without an owner is not a control.

What happens when certification, supervision and consent are not covered?

You submit encounters you were not eligible to bill, and you give away data you did not have permission to share.

Where states have built reimbursement for community health worker services, they generally attach certification requirements, continuing education and a documented supervision relationship. That turns a training tracker from a human resources (HR) convenience into a billing control. If a worker's certification lapsed on the fourteenth and you billed encounters from the fifteenth onward, you will be returning money, and you will find out during a review rather than at submission.

The fix is to hold each worker's certification with an expiry, their training hours against the requirement, and their supervising provider relationship with effective dates, then answer one question before any encounter reaches a claim file: on this date of service, was this worker eligible to deliver this service under this payer. If the answer is no, the encounter never enters the file. That check costs almost nothing to build and it prevents the most avoidable category of repayment.

Consent fails differently. A general permissions system will happily share a record with a partner agency because the user has access rights, without asking whether this client consented to this disclosure to this organisation. Model consent as its own object with a scope, a purpose, an expiry and a revocation path, and make sharing check it rather than checking role permissions. Where records carry statutory disclosure restrictions, those flags must travel with the data rather than being applied at the point of display.

Should you build custom or configure what you already own?

If your programme is grant funded, under about 15 workers, and nobody is billing, do not build. CommCare will collect your data reliably in places with no signal, it costs very little, and it was designed offline first for exactly this kind of work. The money belongs in wages.

If your defining problem is sharing consented client data across a coalition of police, fire, hospital and community organisations, look hard at Julota before commissioning anything. That consent based sharing model is what it is built around, and reproducing it is not a good use of a programme budget.

Also exhaust what you have. A number of programmes that describe a software problem have a form design problem: a single long questionnaire that workers abandon halfway, no structured activity list, and no validation. Restructuring a CommCare form to capture activity type, time in and time out, and coded social needs will get you part of the way to billable structure without a build.

Build when reimbursement plus scale make the gap structural. You bill Medicaid or a managed care plan and denials are a live problem. Paper has crept back in because workers do not trust the app to keep their data. You run more than about 25 workers, which is where manual caseload assignment stops scaling. Clinical escalations reach a supervisor too slowly to be safe. Or you are accountable to a health plan contract for outcomes and need encounter level data joined to utilisation, which no form tool will give you.

How do hidden costs get into a field software quote?

They arrive through payer count, through language, and through the parts of offline nobody demonstrates.

• Each payer is a rule set and a file. Different required elements, different formats, different submission windows. Two payers is not twice one payer, but it is a long way from the same.
• Write back to a hospital record. A separate project on someone else's calendar, and the hardest half of any health record integration. Price it as a phase, never as a line.
• Multilingual field interfaces. More than translation, because consent language and form wording need review by someone qualified, and every change carries that review cost again.
• Offline conflict handling. The demonstration always shows a form saved and synced. The cost is in conflict resolution, deterministic identifiers, media queues and the state indicator that tells a worker what has actually landed.
• Consent management. If you exchange data with a coalition, consent becomes a subsystem with legal review attached, not a checkbox.
• Devices and connectivity. Prepaid plans throttle, older phones have small storage, and both change how much can queue locally.

What separates a build that works from one that fails here?

Four things, and workers decide two of them.

The first is whether offline is designed or bolted on. Ask what happens when a worker documents three visits underground and the phone dies before sync. If the answer is that data is cached, keep asking until you hear about durable local storage, identifiers generated on the device so sync never creates a duplicate client, media queues and explicit conflict rules. Anyone who has shipped real field software has scars from this and will describe them.

The second is whether a billable encounter is modelled as data. Ask them to describe one. You want activity type, time in and time out, coded health related social needs, supervising provider and worker certification status on the date of service. If you hear notes and attachments, they are building a diary.

The third is field testing before launch. Pilot with one or two teams for two or three weeks alongside the current process, because field conditions produce problems no design session predicts: glare on a screen in a stairwell, an address that does not match the buzzer panel, a form that needs one hand while the other holds a folder. Programmes that skip the pilot get adoption failure and blame the workers.

The fourth is ownership. You should own the repository, the infrastructure accounts and the right to hire anyone else, settled before kickoff. At Digital Heroes the client owns the code from the first commit. A programme whose sustainability depends on reimbursement cannot afford a dependency on the firm that generates its claim files.