What should victim services case management software do?
Victim services case management software should help a program coordinate appropriate support while protecting survivor information. Depending on the service, it may support intake, service planning, referrals, contacts, documents, follow-up and aggregate reporting. The design must fit the program's confidentiality obligations, staffing and survivor-centered practice.
The right buying question is not “Can the system collect and analyze everything?” It is “Can the team perform the necessary work with appropriate information, access and control?” More data and broader sharing can create problems rather than solve them.
This guide is for program leaders, advocates, data staff and technology reviewers choosing a system or evaluating an additional analysis workflow. It provides selection criteria and a synthetic pilot. It does not establish that any particular product is approved for a sensitive deployment.
Define the work before choosing the database
Start with the services and decisions the program needs to support. Identify what the advocate needs for continuity, what supervisors need for appropriate review and what a funder actually requires. These audiences do not necessarily need the same information.
The Safety Net Project's database guide emphasizes purpose, confidentiality, security and program capacity when selecting a database. Its central implication for the buying process is that collection and retention should be justified by the service and applicable requirements, not by the convenience of adding more fields.
Write down the intended scope: which records the system would hold, which information would remain elsewhere and which functions would be excluded. Have the appropriate program and legal specialists confirm the requirements before using real survivor information in a new workflow.
What the software may need to support
Scroll horizontally to see all columns →
| Work | What to evaluate | Important distinction |
|---|---|---|
| Intake | A usable process with relevant questions and clear next steps | Do not turn optional analytical interests into required disclosures |
| Service planning | Goals, agreed actions and appropriate follow-up | The plan should reflect the survivor's priorities and the program's role |
| Contacts and notes | Necessary, dated context for authorized staff | Reported statements, observations and interpretation should remain distinguishable |
| Referrals | The permitted handoff, responsible person and follow-up status | Coordinating support does not imply unrestricted data sharing |
| Documents | Source, version and appropriate access | A document's presence does not establish that everyone may read or process it |
| Reporting | Defined, appropriately protected aggregate findings | A funder result should not expose an identifiable story unnecessarily |
For general context, see what case management involves. The specific needs of victim services should shape the implementation rather than being treated as a minor variation of a general contact database.
Test access in every place information appears
A restricted record can still be exposed through a poorly configured search result, summary, export or notification. Test the complete path using the roles that will actually use the system. A permissions checkbox in a demonstration is not enough.
The Office for Victims of Crime's information and technology standards connect technology use with privacy, security and accessibility responsibilities. Use the relevant requirements to define concrete acceptance tests for your program.
Scroll horizontally to see all columns →
| Surface | Question to test |
|---|---|
| Record view | Can this role see only the permitted fields and documents? |
| Search | Does a restricted record reveal its existence or content to an unauthorized role? |
| Generated summary | Does the output stay within the user's permitted sources? |
| Export | Are exported fields and records appropriate to the role and purpose? |
| Notifications | Could a subject line, preview or message reveal sensitive context? |
| Support access | What can vendor staff and other providers access, and under what approved arrangements? |
Document how access changes are handled and how the program can review relevant events. Ask about the actual deployment and data-processing arrangements, not only the product's general description.
A synthetic example for a vendor demonstration
Fictional test case. Test record V-12 has an agreed referral and a follow-up preference. An advocate can view the necessary service record. A reporting user should see only the approved aggregate information. A separate document is intentionally restricted.
The demonstrator changes the follow-up preference, corrects a service date and records that the referral status is still unknown. Test what each role can see afterward, including search, generated summaries and exports.
A successful workflow preserves the permitted current context without exposing the restricted document. It distinguishes a referral sent from a referral completed and a corrected date from an unexplained overwrite. It does not invent a safety finding from the incomplete referral status.
Use synthetic records for the initial demonstration. Removing a name from a real narrative does not necessarily remove identifying details. Any later testing with real information needs the program's approved process and appropriate controls.
Connect what is appropriate; preserve necessary separation
A record can support continuity within an authorized service without becoming a universal profile shared across organizations. Decide which relationships are necessary and permitted, and how uncertain matches or duplicate records will be reviewed.
Do not merge two records solely because an automated match suggests they belong together. A false match can create both inaccurate service history and inappropriate disclosure. Include ambiguous matches and corrections in the pilot.
Multiple programs may use different forms. A limited shared dictionary can help with permitted aggregate reporting, but it should not become a reason to collect unnecessary identifying details or impose a universal questionnaire. Compare only measures with compatible definitions, populations and periods.
Plan record review, retention and exit
Record handling is an operating responsibility, not just a storage setting. Define who reviews records, how corrections are documented and how the required retention and deletion process works. Include backups, exports and other copies in the discussion.
The Safety Net Project's retention and deletion guidance addresses the need for deliberate policies and processes. Apply the requirements relevant to your program; a general article cannot set one retention period for every service.
Ask the vendor to demonstrate a contract-exit scenario with synthetic data. Can the program obtain the information it is entitled to retain in a usable format? What happens to remaining copies, integrations and access? Record the answer in the implementation plan rather than leaving it until the system is being replaced.
Use qualitative analysis for defined questions
Where permitted, reviewed qualitative analysis can help a program understand a bounded question, such as reported obstacles to using a particular service. Define the eligible material, purpose, categories and reviewer before processing it.
Do not treat every case note as a suitable input to a general AI service. Verify the permitted processing, provider arrangements, access, retention and configuration first. Some information may need to remain outside the analysis workflow.
For codebook-based analysis, trained people own the definitions and interpretation. Automated processing may assist with applying approved definitions to eligible material and rerunning analysis after revisions. Review ambiguous and contradictory evidence; source citations do not guarantee that the analysis is correct.
AI should not decide safety, legal questions, eligibility or service priority. Urgent concerns belong in the program's established human response process. No software should be presented as guaranteeing that every danger signal will be detected when a note is written.
Report results without turning every story into a public record
Choose measures relevant to the program and survivor-defined goals. Distinguish services offered, services received, reported experience and appropriately measured outcomes. A case note may describe a need or plan without showing that a later outcome occurred.
Fictional arithmetic example. Of 40 people eligible for a particular voluntary feedback exercise, 20 answer and 14 describe the service as useful. That is 70% of respondents, with 50% response coverage. It is not evidence that 70% of everyone served found the service useful.
This example demonstrates denominators only. Whether such a measure, subgroup or narrative can be collected or published requires the actual program's review. A small or distinctive group can remain identifiable even after names are removed.
Keep definitions, period, coverage and limitations with the approved finding. An authorized reviewer should be able to check the calculation without exposing sensitive information to an audience that does not need it. Use How to Write an Impact Report and report examples for writing ideas only after determining what is appropriate to disclose.
Questions to resolve before selection
- Purpose and fit: Which service and reporting tasks are supported, and which remain elsewhere?
- Data processing: What information is stored or processed, by whom and under which approved terms?
- Access: How do restrictions behave across records, search, summaries, exports and support access?
- Changes: Can trained staff maintain routine questions and definitions through a controlled process?
- Evidence: Can a reviewer inspect the relevant source and correct an interpretation without broadening disclosure?
- Portability: Can the program obtain usable records and carry out its approved exit and retention process?
- Capacity: What training, administration and specialist support will the program need?
The Safety Net database review worksheet is a specialist resource for a more detailed selection review. Treat the list here as a starting point for practical testing, not a replacement for that work.
Where Sopact may fit—and what must be verified
Sopact's broader approach connects collection, quantitative context and reviewed qualitative analysis. For an approved, appropriately bounded workflow, that can address repeated coding, manual joins and report reconstruction while keeping the operating team responsible for definitions and decisions.
That general capability does not establish suitability for identifiable survivor records. Before considering such a deployment, verify the program's confidentiality requirements, product controls, processing arrangements, access, retention and approved scope. Retain a specialized system where it is required or better fits the service.
The qualitative and quantitative analysis guide explains the analytical approach with a fictional example. It is useful for understanding the method, not evidence that sensitive records may be processed without additional review.
Compare operating effort, not just features
Include configuration, training, access review, administration, reporting, corrections and contract-exit work in the ownership assessment. Measure the manual work the proposed system would actually remove and the work it adds.
For example, a summary feature may reduce some preparation time but require source checking. A more complex integration may reduce repeated entry while increasing maintenance. The right decision balances useful staff time, program capacity and the requirements of the service; it is not a contest to maximize the amount of information analyzed.
For broader process guidance, continue to case management best practices and the Case Intelligence course. Apply the specialist boundaries of victim services throughout.
Watch: understand the general collection approach
This introduction describes Sopact's collection and analysis workflow. It is not a victim-services deployment demonstration, confidentiality certification or validation of automated safety decisions.
Frequently asked questions
What should victim services software prioritize?
Appropriate service coordination, survivor-centered practice and protection of information. The program's actual obligations and needs should determine collection, access, processing and reporting.
Should all survivor information be connected across agencies?
No. Determine what sharing is permitted and necessary for the specific purpose. Continuity within an authorized service does not justify unrestricted cross-agency access.
Is removing names enough for a safe demonstration?
Not necessarily. Narratives can contain identifying details. Use synthetic data for an initial demonstration and follow an approved process for any later use of real information.
Can AI guarantee that escalating danger is detected?
No. Automated output can be incomplete or wrong. Urgent concerns and safety decisions require established human procedures and appropriate professional judgment.
Can outcomes be taken directly from existing notes?
Only where the evidence and method support the defined measure and the processing is permitted. A note about a plan or need does not establish a completed service or later outcome.
Does this guide establish that Sopact is approved for survivor records?
No. Product controls, processing arrangements, program requirements and the proposed deployment must be verified before using identifiable survivor information.
