Domestic Violence Shelter Software: Meeting Funder Reporting Without Keeping Two Sets of Client Records

Two sets of records, kept for a good reason

Your funders want detail. VOCA and FVPSA reporting asks for service counts, demographics, outcomes and unmet requests, and your state administering agency has its own template on top. Your legal obligations point the other way. The confidentiality provisions attached to VAWA and VOCA funding prohibit sharing personally identifying information about a survivor without informed, written, reasonably time limited consent, and they specifically prohibit entering that information into shared databases such as a community homeless management information system. That is why domestic violence providers use comparable databases rather than the shared system every other homelessness funded agency in the county uses.

The practical result inside most agencies is two records of the same work. One identified record so advocates can actually serve the person in front of them, and one de identified extract assembled at report time. They are built by different people at different times from the same underlying reality, and they never quite agree. Reconciling them is a week of somebody's quarter, and the discrepancies are impossible to explain because there is no lineage from the aggregate number back to the work that produced it.

The second constraint shapes the technology itself. Shelter location confidentiality is a physical safety matter, not a preference. That affects what the system may store, what it may display, what appears in a URL, what shows in an email notification, what a printed report contains, and what an audit log needs to capture. Most software products treat address as a field. Here it is a risk.

What Osnium and Apricot actually cover

Osnium is built specifically for this sector and understands the domain, including the shape of victim services reporting. Apricot by Bonterra is a broader nonprofit case management platform with wide adoption and real configurability. If you run a single agency with a shelter and an advocacy programme, one of these is very likely the right answer and you should exhaust that path before considering a build.

Where they run short is at the edges that matter most. The first is reporting specificity. Every state administering agency has its own template, its own definitions of a service unit, and its own quirks about how a person served in two programmes should be counted. Configurable products get you close, and the last mile becomes a spreadsheet that somebody rebuilds every quarter.

The second is confidentiality architecture. What most products offer is role based permissions. What this work needs is programme level walls, meaning an advocate in the legal programme cannot see the shelter record for the same person unless a release exists, plus a record of every access, plus a design where the answer to who is in shelter right now is not visible to anyone whose role does not require it. That is a data model decision, not a permissions setting, and it is hard to retrofit.

The third is the hotline. Crisis line contacts are mostly anonymous, frequently do not become clients, and still have to be counted, categorised and reported. Products that assume a client record exists before a service can be logged force advocates to create phantom records, which is both bad data and a confidentiality problem.

Problem one: report from the record, not alongside it

The design goal is that the aggregate report is derived from the same records advocates create in the course of their work, with de identification applied at the reporting boundary rather than by keeping a parallel file. Every service entry carries the programme, the funding source, the service type mapped to your funder's definitions, and the unit measure. The quarterly report then computes from those entries, and every figure can be traced back to its constituent records by someone with the right access.

That traceability is the whole point. When a funder queries a number, you should be able to see what it is made of without reconstructing the quarter. And when the same person receives shelter and legal advocacy, the deduplication rule for reporting should be a defined rule in the system rather than a judgement someone makes differently each time.

Problem two: confidentiality has to be structural

Build the walls into the model. A client record exists once. Programme participation records hang off it, and access is granted per programme. Cross programme visibility requires a release of information that is itself a record with a scope, a date range and an expiry, and the system enforces the expiry rather than trusting anyone to remember it. Access to any identified record is logged with the user, the time and the reason where the situation warrants it.

Then handle the details that cause real harm. Notification emails and text messages should never contain identifying content, because a survivor's device may not be private and neither may a staff member's. Printed and exported documents need watermarking and a record of who exported what, since an export is the most common way confidential data leaves a controlled environment. Search behaviour needs thought, because a system that confirms whether a name exists is disclosing information even when it shows no record. And there must be a documented process for what happens when a court order or subpoena arrives, which is a legal question for your counsel and your state coalition, not a technical one, but the system needs to be able to support whatever answer they give.

Problem three: beds, units and the reality of a full shelter

Availability is not a bed count. It is a bed count constrained by room composition, family size, gender of household members, accessibility needs, pets, and whether two households can safely be placed near each other. An advocate taking a hotline call at two in the morning needs to know in seconds whether a family of five with a dog can be accommodated tonight, and if not, which partner agency to call.

A build should model units and their constraints, hold the current occupancy as a live picture, and support the transfer and referral flow to partner agencies without transmitting identifying information unless a release exists. Waitlist and unmet request logging matters too, because unmet requests are both a funder reporting element and the evidence your agency uses when it asks for more capacity.

Problem four: the hotline and the records that are not clients

Crisis line work is the largest volume of service most agencies deliver and the least well captured. The system needs a lightweight contact log that takes seconds to complete, works while the advocate is still on the call, records call type, presenting issues, referrals given and duration, and does not require a client record to exist. Some contacts later become clients, and there should be a way to link them when consent exists, but the default has to be anonymous.

Cost, timeline and what drives it

In Digital Heroes delivery experience a first release covering confidential client records with programme level access control, bed and unit management, service and hotline logging and de identified funder reporting runs $60,000 to $130,000 in 12 to 16 weeks. Adding safety planning, protective order and court accompaniment tracking, outcome measurement, secure document handling and multi site or multi agency deployment takes it to $150,000 to $320,000 over 7 to 12 months.

Price drivers specific to this sector: the number of distinct funder report formats, since each is real work and they change. Multi agency deployment, which is where a coalition build gets its economics, because one system serving fifteen member agencies costs far less per agency than fifteen licences plus fifteen sets of workarounds. Security review depth, which should be higher here than in most projects and should include penetration testing before go live. Offline or low connectivity capture if advocates work in courthouses and hospitals. And accessibility and language support, since your clients and your staff are not uniform and a system that only works in English excludes people who need it.

What keeps it down: starting with one programme, keeping outcomes measurement for phase two, and using an established hosting platform with proper controls rather than anything bespoke at the infrastructure layer.

When to buy, honestly

If you are one agency with one shelter and one advocacy programme, buy. Osnium and Apricot both cost a fraction of a build and both are better than what a small custom project would produce on the budget you are likely to have. Your money is better spent on advocates. We would say the same thing to any agency that asked us.

The build case is real in three situations. A state coalition funding one system across member agencies, where the per agency economics change completely and the reporting consistency across members becomes a genuine asset. A large multi programme agency running shelter, transitional housing, legal advocacy, child services and a hotline, where the confidentiality walls between programmes are a structural requirement rather than a permission setting. And an agency whose funder reporting has genuinely outgrown configuration, where the quarterly spreadsheet rebuild has become an institution. If none of those describe you, buy the product.

How to choose a developer

Ask whether they have read the confidentiality requirements attached to VAWA and VOCA funding, and ask them to explain why victim service providers do not enter client data into a shared homelessness management system. If they have not encountered this, they will design a normal case management system and you will discover the problem after go live.

Ask how they would prevent identifying information appearing in notification emails, exports and URLs. A developer who has thought about this will answer immediately and specifically.

Ask what their security practice actually is: encryption at rest and in transit, access logging, penetration testing before launch, and how they handle their own team's access to production data during development. Insist that no real client data is used in any non production environment.

Ask how they would handle a subpoena for records, and accept an answer that says this is a legal question for your counsel provided they can describe what the system needs to support. Then settle ownership before kickoff: the repository, the cloud accounts and the right to hire anyone else should be yours in writing. At Digital Heroes the client owns the code from the first commit, and for records this sensitive the agency should never be dependent on a supplier for access to its own data.