Prisoner Reentry Software: Enrolling Someone Inside a Facility and Still Having a Plan on Release Day

The forty eight hours that decide the next three years

Everything in reentry work compresses into release day. Whether there is a bed that night. Whether there is a state identification card, a birth certificate and a social security card, because without those there is no job and no lease. Whether Medicaid was suspended rather than terminated and can be reactivated quickly, or whether the person will wait weeks for coverage they need for medication that runs out on day seven. Whether the supervising officer knows where the person will be living, and whether the address the programme has matches the address on the supervision paperwork.

Programmes that do this well start months earlier, inside the facility. That is where the software problem begins, because a correctional facility is the most hostile environment a case management system can be asked to operate in. Staff often cannot bring a personal device. Network access is restricted or absent. The tablet or laptop that is permitted has to be approved, and what it can reach is controlled by the department of corrections, not by you. So the enrollment interview, the assessment, the goal plan and the consent forms all have to be capturable offline and reconciled later without creating duplicate records for a person who was enrolled twice by two different staff at two different facilities.

Then the person is released and the entire operating context changes. Now there are landlords, employers, a supervising officer, a treatment provider, a benefits caseworker and a family, each holding one part of the record, none of them in your system.

What CaseWorthy and Apricot give you, and where they stop

Both are legitimate case management platforms with real reentry deployments. CaseWorthy is configurable and used across human services. Apricot by Bonterra is widely adopted and easier to stand up. For a single programme with one facility relationship and standard grant reporting, either will serve you and cost far less than a build.

Three things push programmes past them. The first is offline operation inside a facility. Most platforms assume connectivity. Workarounds mean paper forms transcribed later, which is where duplicates and gaps come from, and the transcription lag means the release plan is often not in the system until after release.

The second is cross agency data sharing. Your relationship with corrections, with community supervision and with the county behavioural health authority is governed by specific data sharing agreements that say what may be shared, in which direction, and for what purpose. Encoding those boundaries as enforced rules rather than as staff training is not something a configurable product does well, and the consequence of getting it wrong is a suspended agreement and a programme with no access to the facility.

The third is outcome contracts. If you are paid on milestones, meaning enrollment, placement, 90 day job retention, 12 month housing stability, then the milestone definition, the evidence required, the verification step and the invoice are a financial workflow rather than a case note. Products treat milestones as a checkbox on a case, and you end up assembling invoices from exports.

Problem one: enrollment inside the wall

Build for offline first, on a device the facility will actually permit. That means local storage of the assessment and consent forms, a queue that syncs when the device returns to a network, and conflict handling that assumes two staff may have enrolled the same person. Identity matching should be deterministic where a department identification number exists and scored where it does not, with a human review queue for the rest.

Consent deserves specific attention. A release of information signed inside a facility has a scope and an expiry, and it governs what may be shared with a landlord, an employer or a supervising officer after release. Capture it as a structured record with the scope encoded, not as a scanned signature in a documents folder, because the whole point is that the system can then enforce it.

What should not be in scope is anything that stores content the facility restricts or that would jeopardise your access agreement. Ask the facility what they will permit before design, not after.

Problem two: release day is a checklist with a deadline

Model the release plan explicitly. Identification documents obtained or applied for with a status. Housing placement with a confirmed provider and a date. Transportation from the gate. Medication supply and a scheduled appointment. Benefits status, since Medicaid suspension and reinstatement processes differ by state and getting the reactivation right is the difference between coverage on day one and coverage in week five. Employment referral or a scheduled appointment. Reporting instructions for supervision, with the address that supervision holds matching the one the programme holds.

The system's job is to make the gaps visible with enough lead time to close them. A dashboard of everyone releasing in the next 30 days with unresolved items is the single most used screen in a reentry build, and it is straightforward to produce once the plan is structured data instead of narrative case notes.

Problem three: partners who will never log into your system

Landlords and employers are not going to adopt your software. Supervising officers have their own state system and are not permitted to use yours. The realistic design uses lightweight, purpose specific interactions: a single link an employer follows to confirm continued employment for a milestone, a simple form a landlord uses to confirm tenancy, a scheduled export or secure exchange with supervision where the data sharing agreement permits it.

Every one of those exchanges has to check the consent record before it sends anything. That is the discipline that makes cross agency reentry work sustainable, because the agreements that grant you facility access are the same agreements you lose if identifying information moves in a way somebody did not authorise.

Problem four: measuring recidivism honestly

Recidivism is measured over one, two and three year windows, and the definition varies: rearrest, reconviction, or return to custody. Your programme does not hold that data. The state does. So measurement means a matchback against a criminal justice dataset under an agreement, at intervals, for a cohort defined by enrollment date.

What the software must do is make cohorts precise and reproducible. Enrollment date, programme, dosage of service received, and exit reason all have to be recorded consistently, because the analysis is only as good as the cohort definition. Programmes that cannot say exactly who was in the January 2024 cohort and what they received cannot make a credible outcome claim, no matter how good the work was. Build for the analysis you will be asked for in three years, since retrofitting it onto historical case notes is not possible.

Cost, timeline and what drives the number

In Digital Heroes delivery experience, a first release covering offline pre release enrollment, release planning, placement tracking and funder aligned service documentation runs $70,000 to $150,000 and ships in 12 to 18 weeks. Adding supervision coordination, benefits tracking, partner facing confirmation flows, milestone contract management with invoicing and cohort based outcome reporting takes it to $180,000 to $400,000 over 8 to 14 months.

Price drivers: the number of correctional facilities and jurisdictions, because each brings its own access rules, identification numbering and data sharing agreement. Offline capability, which is real engineering rather than a caching option. Whether you provide substance use disorder treatment, since those records carry additional federal confidentiality protections that shape the architecture and should be confirmed with counsel. Milestone contract billing, which is a financial system rather than a report. And integration or structured exchange with a state system, which is usually a schedule risk driven by the other agency's timeline rather than yours.

What keeps it down: launching with one facility relationship, keeping partner portals out of phase one in favour of simple confirmation links, and deferring outcome analytics until the cohort data is being captured cleanly, which it will be from day one if the model is right.

When you should buy instead

Buy if you run one programme, serve under about 150 people a year, work with a single facility, and report on standard grant measures. Configure CaseWorthy or Apricot, spend the difference on case managers, and revisit in two years. That is the honest answer for most reentry nonprofits and we give it regularly.

Build when you operate across multiple facilities and counties with different rules, when you hold pay for outcomes or milestone based contracts where the money depends on evidence quality, when data sharing with corrections and supervision is contractual and has to be enforced rather than trusted, when you are a county coalition coordinating several providers around one person, or when your staff are transcribing paper forms after every facility visit. The trigger is coordination across organisations that do not report to each other, which is exactly the thing generic case management does not do.

How to choose a developer

Ask what they would build for a caseworker with an approved laptop, no network, and four enrollment interviews scheduled inside a facility. If they describe a mobile app that syncs, ask how it handles two staff enrolling the same person at different sites in the same week.

Ask how consent scope would be enforced at the moment of an outbound exchange with an employer or a supervising officer. The answer should be a check in the code path, not a training note.

Ask whether they have worked with 42 CFR Part 2 protected records, and if your programme provides substance use disorder treatment, treat a blank look as disqualifying. Confirm the applicable requirements with your counsel and hold the developer to them.

Ask how they would define and freeze a cohort for a three year outcome study. Then settle ownership in writing before kickoff: the repository, the cloud accounts and the right to hire another firm should be yours. At Digital Heroes the client owns the code from the first commit, which matters here because your data sharing agreements are with your organisation and the records have to remain under your control.