Case Management Systems
A case management system is software that tracks individuals through structured intervention workflows, maintaining longitudinal records of assessments, services, and outcomes while enforcing confidentiality controls appropriate to the sensitivity of protection data. These systems differ fundamentally from beneficiary registration databases in their orientation toward ongoing relationship management rather than point-in-time enrollment, and from programme management systems in their focus on individual welfare rather than aggregate service delivery.
Protection case management carries obligations that exceed those of general programme data. A case file for a survivor of gender-based violence or a separated child contains information that, if disclosed, could result in physical harm, social ostracism, or retaliation. The technical architecture of case management systems must therefore embed confidentiality as a structural property rather than a procedural afterthought. This means access controls enforced at the database level, audit trails that cannot be circumvented by administrators, and encryption that protects data even when infrastructure is compromised.
- Case
- A structured record tracking an individual’s journey through assessment, intervention, and closure, including all associated documentation, service records, and case notes.
- Case Worker
- The staff member assigned primary responsibility for a case, conducting assessments, developing care plans, and coordinating service delivery.
- Care Plan
- A documented set of interventions, referrals, and objectives agreed between case worker and client, with timelines and responsible parties identified.
- Case Closure
- The formal ending of active case management, occurring when intervention objectives are met, the client disengages, or circumstances make continued management impossible.
- Confidentiality Classification
- A data sensitivity level assigned to case information determining who can access it, typically ranging from general programme staff visibility to case-worker-only restriction.
- Inter-Agency Case Transfer
- The formal handover of case responsibility from one organisation to another, requiring secure data transmission, consent verification, and case acceptance protocols.
Case Management Domains
Case management systems serve distinct protection domains, each with specific workflow requirements, data elements, and confidentiality thresholds. While the underlying technical architecture shares common patterns, the functional configuration differs substantially across domains.
Child protection case management addresses separated and unaccompanied children, children associated with armed forces or groups, child survivors of violence, and children at risk of exploitation. The primary framework is the Inter-agency Guidelines on Case Management and Child Protection, which specifies minimum data elements, workflow stages, and inter-agency referral protocols. Cases progress through identification, assessment (using tools such as the Best Interest Assessment), care planning, implementation, follow-up, and case closure or transfer. The system must track family tracing efforts, alternative care placements, and best interest determinations, while maintaining strict separation between case data and family tracing databases to prevent inadvertent disclosure of a child’s location to potentially harmful family members.
Gender-based violence case management serves survivors of sexual violence, intimate partner violence, forced marriage, and other forms of GBV. The guiding framework is the Inter-Agency Minimum Standards for GBV in Emergencies, emphasising survivor-centred approaches where the survivor controls what information is recorded and shared. GBV case management systems enforce particularly restrictive access controls, as disclosure risks include retaliation by perpetrators, honour-based violence, and social exclusion. The system must support informed consent documentation, safety planning, and incident tracking while enabling anonymised aggregate reporting for coordination purposes.
General protection case management covers individuals facing protection risks not falling into specialised categories: persons with specific needs, individuals at risk of detention or deportation, victims of trafficking, and persons facing discrimination or denial of rights. These cases often involve legal assistance, advocacy interventions, and coordination with authorities, requiring the system to track legal status, documentation efforts, and interactions with state actors.
The technical distinction between these domains lies primarily in mandatory data elements, workflow stages, and default access restrictions rather than in fundamental architecture. A well-designed system supports multiple domains through configurable workflows and field definitions rather than requiring separate installations.
System Architecture
Case management systems comprise interconnected components handling data capture, workflow orchestration, access control, and reporting. The architecture must accommodate both online operation in office environments and offline operation for field-based case workers visiting clients in locations without connectivity.
+------------------------------------------------------------------+| CASE MANAGEMENT SYSTEM |+------------------------------------------------------------------+| || +---------------------------+ +-----------------------------+ || | PRESENTATION LAYER | | MOBILE APPLICATION | || | | | | || | +-------+ +----------+ | | +-------+ +----------+ | || | | Web | | Reports | | | | Forms | | Offline | | || | | UI | | Dashboard| | | | Entry | | Cache | | || | +---+---+ +----+-----+ | | +---+---+ +----+-----+ | || | | | | | | | | || +------+-----------+--------+ +------+-----------+----------+ || | | | | || +------v-----------v------------------v-----------v----------+ || | API / SERVICE LAYER | || | | || | +------------+ +------------+ +------------+ | || | | Case | | Workflow | | Reporting | | || | | Service | | Engine | | Service | | || | +------+-----+ +------+-----+ +------+-----+ | || | | | | | || +---------+---------------+---------------+------------------+ || | | | || +---------v---------------v---------------v------------------+ || | ACCESS CONTROL LAYER | || | | || | +------------+ +------------+ +------------+ | || | | Role-Based | | Case-Level | | Field-Level| | || | | Permissions| | Permissions| | Permissions| | || | +------------+ +------------+ +------------+ | || +------------------------------------------------------------+ || | | | || +---------v---------------v---------------v------------------+ || | DATA LAYER | || | | || | +------------+ +------------+ +------------+ | || | | Case | | Audit | | Document | | || | | Records | | Trail | | Storage | | || | | (encrypted)| | (immutable)| | (encrypted)| | || | +------------+ +------------+ +------------+ | || +------------------------------------------------------------+ |+------------------------------------------------------------------+Figure 1: Case management system component architecture
The presentation layer provides interfaces for different user contexts. Web interfaces serve office-based supervisors and programme managers who require full case visibility and reporting access. Mobile applications serve field-based case workers who conduct home visits and community outreach in areas with intermittent or no connectivity. The mobile application maintains an encrypted local cache of assigned cases, synchronising with the central system when connectivity permits.
The service layer implements core business logic. The case service handles CRUD operations on case records, enforcing data validation rules specific to each protection domain. The workflow engine manages case progression through defined stages, triggering notifications when cases require action and escalating overdue cases to supervisors. The reporting service generates both operational reports for case management and anonymised aggregate reports for coordination and donor reporting.
The access control layer enforces confidentiality through three complementary mechanisms. Role-based permissions determine what functions a user can perform: case workers can create and update cases, supervisors can reassign cases and access workload reports, programme managers can view anonymised aggregates. Case-level permissions restrict which cases a user can access: case workers see only their assigned cases plus cases explicitly shared with them, supervisors see cases assigned to their team. Field-level permissions control visibility of specific data elements: certain high-sensitivity fields such as perpetrator information in GBV cases remain visible only to the assigned case worker regardless of other permissions.
The data layer stores case records with encryption at rest, maintains immutable audit trails recording every access and modification, and manages document attachments such as consent forms, assessment documents, and referral letters. The audit trail design prevents even database administrators from modifying historical records, protecting against both external compromise and internal misuse.
Case Workflow Design
Case workflows define the stages through which cases progress, the transitions permitted between stages, and the conditions that must be satisfied for transitions to occur. A well-designed workflow enforces minimum standards while accommodating the reality that protection cases rarely follow linear paths.
+------------------+ | | | IDENTIFICATION | | | +--------+---------+ | | Case opened v +--------+---------+ | | | ASSESSMENT | | | +--------+---------+ | +--------------+--------------+ | | v v +--------+---------+ +--------+---------+ | | | | | CARE PLAN | | REFERRAL ONLY | | DEVELOPMENT | | (no ongoing | | | | management) | +--------+---------+ +--------+---------+ | | | Plan approved | Referral confirmed v v +--------+---------+ +--------+---------+ | | | | | IMPLEMENTATION | | CLOSED | | | | | +--------+---------+ +------------------+ | | Objectives met / Client disengages v +--------+---------+ | | | CASE REVIEW | | | +--------+---------+ | +---------+---------+---------+ | | | v v v+---+----+ +-----+----+ +-+-------+| | | | | || CLOSED | | REOPENED | |TRANSFER || | | | | |+--------+ +----------+ +---------+Figure 2: Protection case workflow states and transitions
The identification stage captures initial information about the individual and the protection concern. This stage collects minimum data necessary to open a case: identifying information, presenting concern, source of referral, and initial risk assessment. Systems should enforce that cases cannot remain in identification beyond a defined period (48 hours for emergency cases, 5 working days for standard cases) without progressing to assessment or being closed with documented reason.
The assessment stage involves comprehensive evaluation of the individual’s situation, needs, and resources. For child protection, this includes the Best Interest Assessment. For GBV, this includes safety assessment and needs assessment following survivor-centred principles. The system should present assessment forms appropriate to the protection domain and enforce completion of mandatory fields before progression. Assessment may result in immediate referral without ongoing case management (for cases where external services address the need) or progression to care planning.
Care plan development documents agreed interventions, responsible parties, and timelines. The system should support structured care plan entry with predefined intervention types, enabling consistent reporting while allowing narrative elaboration. Care plans require supervisor approval in most configurations before implementation begins, providing a quality assurance checkpoint.
The implementation stage tracks delivery of planned interventions and services. Case workers record case notes documenting interactions, service delivery, and changes in client situation. The system should prompt for follow-up entries when defined intervals elapse without activity, flagging potentially neglected cases to supervisors. Implementation may continue for weeks, months, or years depending on case complexity.
Case review evaluates whether intervention objectives have been achieved and determines next steps. Reviews may occur at scheduled intervals (every 30, 60, or 90 days depending on configuration) or when triggered by significant events. Review outcomes include closure (objectives met), continued implementation (objectives partially met), care plan revision (circumstances changed), or transfer (case moving to another organisation or location).
Case closure records the reason for ending active management, ensures documentation is complete, and may trigger data retention processing. Systems should prevent closure until mandatory documentation is present and should record closure reason using standardised categories enabling aggregate analysis. Closure does not necessarily mean data deletion; retention requirements typically mandate preserving case records for 5-25 years depending on case type and jurisdiction.
Workflow configuration varies by protection domain. GBV case management emphasises survivor autonomy, permitting survivors to pause or close cases at any point regardless of intervention completion. Child protection workflows may require inter-agency panel review before certain transitions. The system should support workflow customisation without requiring code changes, using configuration interfaces accessible to programme managers.
Access Control and Confidentiality
Protection data requires access controls exceeding those of typical programme information. The consequences of unauthorised disclosure range from social harm to physical danger, making confidentiality a safety issue rather than merely a compliance requirement.
+------------------------------------------------------------------+| ACCESS CONTROL MODEL |+------------------------------------------------------------------+| || USER || | || v || +-------------------+ || | AUTHENTICATION | Username/password + MFA || +--------+----------+ || | || v || +--------+----------+ || | ROLE CHECK | What functions can this user perform? || | | || | - Case Worker | Create, update assigned cases || | - Supervisor | + reassign, view team cases || | - Manager | + view anonymised reports || | - Administrator | + user management, no case access || +--------+----------+ || | || v || +--------+----------+ || | CASE PERMISSION | Which cases can this user access? || | | || | - Assigned cases | Primary case worker || | - Shared cases | Explicit share granted || | - Team cases | Supervisor of assigned worker || | - None | No case-level access (managers) || +--------+----------+ || | || v || +--------+----------+ || | FIELD PERMISSION | Which fields can this user see? || | | || | - Standard fields | All with case access || | - Restricted | Case worker + explicit grant || | - Confidential | Case worker only || +--------+----------+ || | || v || +--------+----------+ || | AUDIT LOGGING | Record access for accountability || +-------------------+ || |+------------------------------------------------------------------+Figure 3: Layered access control model for protection case data
Role-based access control establishes baseline permissions. A typical configuration includes:
Case Worker role permits creating cases, updating assigned cases, recording case notes, initiating referrals, and viewing own caseload reports. Case Workers cannot access cases assigned to others, cannot modify completed assessments, and cannot view workload reports for other workers.
Supervisor role inherits Case Worker permissions and adds ability to reassign cases within their team, access all cases assigned to team members, approve care plans, conduct case reviews, and view team workload and performance reports. Supervisors cannot access cases outside their team unless explicitly shared.
Programme Manager role permits viewing anonymised aggregate reports, configuring workflow parameters, and managing user accounts. Programme Managers cannot access individual case records, ensuring separation between operational oversight and case confidentiality.
System Administrator role permits technical system management: user provisioning, backup configuration, and system monitoring. Administrators cannot access case data; administrative functions operate on system metadata rather than case content.
Case-level permissions determine which specific cases a user can access. The primary mechanism is case assignment: each case has an assigned case worker who has full access. Cases may be shared with additional users when collaborative management is required, such as when a case involves multiple service areas. Sharing creates explicit permission grants recorded in the audit trail. Supervisors gain access to cases through team membership rather than explicit sharing, enabling oversight without requiring individual grants.
Field-level permissions protect particularly sensitive data elements within accessible cases. A supervisor reviewing a team member’s GBV caseload can see case status, intervention summary, and follow-up dates, but cannot see perpetrator identifying information, incident details, or safety plan specifics. These fields display as “[Restricted]” or similar placeholder, indicating data exists but is not visible at the user’s permission level. Field-level restrictions apply regardless of other permissions, preventing supervisory access from inadvertently exposing survivor-controlled information.
Consent-based access implements survivor-centred principles in GBV case management. The survivor’s documented consent specifies what information can be shared with whom. The system enforces these consent decisions, preventing referral information transmission when consent is absent and restricting inter-agency data sharing to consented elements. Consent can be modified during case management, with the system adjusting permissions accordingly.
Audit trails record every access to case data. The trail captures user identity, timestamp, action performed, and fields accessed. For sensitive operations (viewing restricted fields, exporting data, printing case files), the system may require the user to provide a reason recorded in the audit. Audit trails must be immutable; even database administrators should lack ability to modify audit records. Typical implementations write audit data to append-only storage or use cryptographic chaining to detect tampering.
Supervisor Oversight and Quality Assurance
Case management quality depends on systematic oversight that identifies struggling cases, supports case workers, and ensures adherence to standards without creating surveillance that undermines worker-client relationships.
+------------------------------------------------------------------+| SUPERVISION DASHBOARD |+------------------------------------------------------------------+| || WORKLOAD SUMMARY ALERTS || +---------------------------+ +--------------------+ || | Worker | Active | New | | 3 cases overdue | || |-----------+--------+----- | | for follow-up | || | A. Smith | 12 | 2 | | | || | B. Jones | 18 | 1 | | 1 assessment | || | C. Wilson | 8 | 3 | | exceeds 5 days | || | D. Brown | 15 | 0 | | | || +---------------------------+ | 2 care plans | || | pending approval | || CASE STATUS +--------------------+ || +---------------------------+ || | Stage | Count | QUALITY METRICS || |----------------+----------| +--------------------+ || | Assessment | 8 | | Avg days to | || | Care Planning | 6 | | assessment: 3.2 | || | Implementation | 31 | | | || | Review Due | 7 | | Care plans with | || | Pending Close | 3 | | objectives: 94% | || +---------------------------+ | | || | Follow-up rate: | || | 87% within SLA | || +--------------------+ |+------------------------------------------------------------------+Figure 4: Supervisor dashboard showing workload and quality indicators
Caseload monitoring tracks the volume and distribution of cases across workers. Sustainable caseloads vary by context: a case worker handling complex child protection cases in a stable setting might manage 15-20 active cases, while emergency response contexts may temporarily require 25-30. The system should display current caseloads against configured targets, highlighting workers approaching or exceeding sustainable levels. Caseload alerts enable supervisors to redistribute cases before worker burnout affects case quality.
Timeline enforcement identifies cases requiring attention. The system tracks expected follow-up intervals (every 14 days, 30 days, or as specified in care plans) and flags cases where intervals have elapsed without documented contact. Stage duration monitoring identifies cases stuck in early stages: an assessment extending beyond 5 days may indicate access difficulties, case complexity, or worker overload. Escalation rules can automatically notify supervisors when cases exceed stage duration thresholds.
Case review sampling supports quality assurance through systematic review of case documentation. Supervisors should review a sample of each worker’s cases regularly, examining assessment completeness, care plan quality, and documentation standards. The system can facilitate sampling by presenting random case selections or cases meeting review criteria (newly closed, high complexity score, extended duration). Review findings should be documented within the system, creating a quality assurance record.
Supervision session support provides structured information for case worker supervision meetings. Case workers and supervisors benefit from case summaries showing recent activity, upcoming deadlines, and cases requiring discussion. The system should enable marking cases for supervision discussion and recording supervision notes without those notes becoming part of the case record accessible to others.
Performance metrics aggregate individual case data into quality indicators. Useful metrics include: average time from identification to assessment completion, percentage of care plans with documented objectives and timelines, follow-up completion rate (follow-ups conducted within planned interval), case closure rate with documented outcomes, and reopen rate (percentage of closed cases subsequently reopened). These metrics should trend over time, enabling detection of improving or declining practice patterns.
Quality assurance must balance accountability with trust. Excessive surveillance can drive workers toward documentation compliance rather than client welfare, and can undermine the autonomy and judgment essential to effective case work. Systems should provide supervisors with summary visibility rather than detailed monitoring of every action, reserving detailed review for cases identified through sampling or alerts.
Anonymised Reporting and Analytics
Protection coordination requires aggregate information about caseloads, trends, and service gaps while protecting individual confidentiality. Case management systems must produce useful analytical outputs without enabling identification of individuals.
Aggregate reporting counts cases by category without revealing individual identities. Reports display totals: “47 active GBV cases, of which 23 are in implementation stage” rather than listing cases. Standard aggregate reports include: new cases opened by period, cases by stage, cases by protection concern type, cases by demographic category (age group, gender), and cases by geographic area. Aggregate reports serve coordination meetings, donor reporting, and programme planning.
Minimum cell size prevents deduction of individual identities from aggregate data. If a report shows “2 GBV cases in village X involving girls aged 10-14”, the small number may enable identification in a small community. Systems should suppress cells below a configured threshold (typically 5) or combine small cells with adjacent categories. A report might show “>5” or “suppressed” rather than exact counts when thresholds are not met.
Anonymisation for analysis removes or transforms identifying information when case-level data is needed for programme learning or research. True anonymisation is difficult: combinations of demographic and geographic variables may uniquely identify individuals even when names are removed. Effective anonymisation may require generalisation (replacing village name with district), suppression (removing rare characteristics), or perturbation (adding noise to numerical values). Systems should provide anonymisation functions rather than expecting analysts to manually de-identify exported data.
Donor reporting presents a particular challenge. Donors increasingly request case-level data to verify service delivery, but providing identifiable protection data to donors violates confidentiality principles and may endanger clients. Organisations should negotiate reporting requirements that satisfy donor accountability needs through aggregate data, activity documentation, and anonymised case summaries rather than identifiable records. The system should generate donor-appropriate reports that meet reporting obligations without compromising protection.
Trend analysis identifies patterns that inform programming. Rising case numbers in a specific area may indicate emerging protection concerns or improved identification. Changing demographic patterns may signal population movement or shifting vulnerabilities. Case duration trends may reflect service availability or case complexity changes. Systems should support time-series analysis, enabling comparison across periods and detection of statistically significant changes.
Offline Capability
Field-based case workers frequently operate in locations without reliable connectivity. Home visits in rural areas, community outreach in informal settlements, and mobile programming all require case management functionality independent of network access.
+------------------------------------------------------------------+| OFFLINE OPERATION MODEL |+------------------------------------------------------------------+| || CENTRAL SERVER MOBILE DEVICE || +-------------------+ +-------------------+ || | | | | || | Full case | | Assigned cases | || | database | Sync when | only | || | | connected | | || | All users +<---------------->+ Single user | || | All cases | | Encrypted local | || | | | storage | || +-------------------+ +-------------------+ || || SYNC PROCESS: || +------------------------------------------------------------+ || | | || | 1. Device connects to network | || | 2. Authenticate user | || | 3. Upload: New cases, updated records, completed forms | || | 4. Download: Reassigned cases, updated reference data | || | 5. Conflict resolution: Server timestamp wins by default | || | 6. Confirmation: Both sides acknowledge sync complete | || | | || +------------------------------------------------------------+ || || CONFLICT HANDLING: || +------------------------------------------------------------+ || | | || | Same field edited on server and device: | || | - Server version retained as primary | || | - Device version preserved in case notes with timestamp | || | - Alert generated for case worker review | || | | || +------------------------------------------------------------+ |+------------------------------------------------------------------+Figure 5: Offline synchronisation model for mobile case management
Selective synchronisation downloads only cases assigned to the user rather than the full database. A case worker with 20 assigned cases receives those cases on their device; cases assigned to colleagues remain on the server. This design limits data exposure if a device is lost or compromised and reduces storage and synchronisation requirements on mobile devices. When a case is reassigned, synchronisation removes it from the previous worker’s device and adds it to the new worker’s device.
Local encryption protects data at rest on the mobile device. Case data stored locally should be encrypted with keys derived from user credentials, preventing access if the device is lost. Device-level encryption (full disk encryption) provides defence in depth. Applications should implement timeout policies that require re-authentication after inactivity periods (15-30 minutes is typical).
Synchronisation protocols must handle the realities of intermittent connectivity: partial transfers, connection drops, and variable bandwidth. Effective implementations use incremental synchronisation (transferring only changed records rather than full database), checkpointing (enabling resumption of interrupted transfers), and compression (reducing data volume for slow connections). Synchronisation should be opportunistic, occurring automatically when connectivity is detected rather than requiring manual initiation.
Conflict resolution addresses the situation where the same case is modified on both server and device before synchronisation. This occurs when a supervisor updates a case while a case worker is in the field with an offline copy. Resolution strategies include: last-write-wins (most recent change retained, earlier change lost), server-wins (server version takes precedence, device changes require re-entry), and merge (attempt to combine changes, flagging conflicts for manual resolution). Most case management systems use server-wins with preservation of device changes in case notes, ensuring no data is lost while maintaining single authoritative record.
Offline-first design assumes disconnected operation as the default rather than exception. Interfaces should not display connectivity-dependent features prominently. Users should understand which functions work offline (viewing cases, entering data, completing assessments) and which require connectivity (initiating inter-agency referrals, accessing newly assigned cases). Clear status indicators show synchronisation state: last sync time, pending changes awaiting upload, and synchronisation errors requiring attention.
Inter-Agency Case Transfer
Protection cases frequently require transfer between organisations when clients relocate, when specialised services are needed, or when organisational presence changes. Secure and complete case transfer preserves continuity of care while maintaining confidentiality.
Transfer initiation begins when a case worker determines that another organisation should assume case responsibility. Common triggers include: client relocation to area served by another organisation, case type transition (general protection case developing GBV dimensions requiring specialised response), and programme closure or handover. The initiating case worker documents the transfer reason and identifies the receiving organisation.
Consent verification ensures the client agrees to information sharing with the receiving organisation. Transfer requires informed consent documenting: what information will be shared, with whom, for what purpose, and what the client can expect from the receiving organisation. Consent should be documented within the case record before transfer proceeds. For child protection cases, consent processes must account for the child’s evolving capacity and may require guardian involvement.
Secure transmission protects case data during transfer. Methods include: encrypted file transfer (case exported as encrypted file with password shared through separate channel), direct system integration (where both organisations use compatible systems, secure API-based transfer), and secure referral platforms (inter-agency platforms designed for protected data exchange). Unencrypted email attachment is never appropriate for protection case data.
Receiving acknowledgment confirms the receiving organisation has received the case, verified data integrity, and accepted case responsibility. Until acknowledgment, the transferring organisation retains responsibility. Systems should track transfer status: initiated, transmitted, received, accepted. Transfers pending acknowledgment beyond configured thresholds (48-72 hours) should generate alerts.
Case closure at origin occurs after receiving acknowledgment. The transferring organisation closes the case with “transferred” as the closure reason, documenting the receiving organisation and transfer date. Depending on data retention policies, the transferring organisation may retain a record of the case with limited detail or may delete case data after transfer completion.
Inter-agency platforms facilitate transfers between organisations using different case management systems. Primero’s inter-agency referral functionality enables transfers between Primero instances and exports to other systems. The Child Protection Information Management System Guidelines specify data elements and transfer protocols for child protection cases. GBV coordination increasingly uses standardised referral pathways with agreed data sharing protocols.
Platform Options
Case management system selection must balance functionality requirements against operational capacity, cost, and data sovereignty considerations. The protection sector has converged on several primary platforms, each with distinct strengths and constraints.
Primero is the open-source case management platform developed by UNICEF and partners, providing specialised functionality for child protection and GBV programming. Primero implements child protection case management workflows based on inter-agency guidelines, GBV case management with survivor-centred consent management, family tracing and reunification with integration to ICRC family links, and mobile offline capability for field-based case workers. Primero can be self-hosted for complete data control or accessed through UNICEF-managed hosting. The platform requires technical capacity for deployment and maintenance; organisations typically need dedicated system administration or partnership with technically capable organisations.
CommCare is an open-source mobile data platform that can be configured for case management workflows. CommCare provides flexible form design enabling customised assessment and case management workflows, strong offline mobile capability designed for low-connectivity environments, and integration capabilities connecting to external systems. CommCare requires significant configuration to implement protection case management standards; organisations must build workflows, access controls, and reporting rather than using predefined protection-specific functionality. CommCare suits organisations with technical configuration capacity wanting flexibility beyond protection-specific platforms.
Apricot and similar commercial platforms offer case management functionality aimed at social services organisations. These platforms provide polished user interfaces, integrated reporting, and vendor support, but may not implement protection-sector-specific requirements like inter-agency transfer protocols or survivor-centred consent models. Data hosting is typically vendor-managed, raising data sovereignty considerations for organisations operating in contexts where data must remain within specific jurisdictions.
Salesforce Nonprofit Success Pack and Programme Management Module can be configured for case management, leveraging Salesforce’s platform capabilities. This approach suits organisations already using Salesforce for other functions and wanting unified data architecture. Significant customisation is required to implement protection workflows and access controls. Salesforce’s data hosting is primarily US-based, which may conflict with data sovereignty requirements. The platform is available at reduced cost through nonprofit programmes but still represents substantial investment.
Custom development creates organisation-specific systems meeting exact requirements. This approach offers maximum flexibility but demands sustained development and maintenance capacity rarely available in humanitarian organisations. Custom systems risk becoming unsupported when developers leave and often lack the security review that established platforms receive. Custom development is generally appropriate only when genuinely unique requirements exist that no available platform can accommodate.
| Platform | Strengths | Considerations | Suitable For |
|---|---|---|---|
| Primero | Protection-specific workflows, inter-agency standards, self-hosting option | Requires technical deployment capacity | Organisations implementing CP/GBV programming at scale |
| CommCare | Flexible configuration, strong offline, open source | Requires building protection workflows | Organisations with configuration capacity wanting flexibility |
| Apricot | Polished interface, vendor support | May lack protection-specific features | Domestic services, stable contexts |
| Salesforce | Platform ecosystem, nonprofit programme | US data hosting, customisation required | Organisations already using Salesforce |
Implementation Considerations
Organisations with Limited IT Capacity
Small organisations and those without dedicated IT staff can implement case management through hosted solutions and implementation partnerships. Primero is available through UNICEF-managed hosting, eliminating the need for server administration while maintaining access to protection-specific functionality. CommCare Cloud provides similar hosted access to CommCare. These arrangements reduce technical burden but require understanding hosting terms, particularly data location and access provisions.
Implementation partnerships with larger organisations provide technical support and access to established systems. A small organisation might use a protection cluster lead’s Primero instance under agreed data sharing and access arrangements. Such arrangements should be documented in data sharing agreements specifying responsibilities, access provisions, and exit procedures.
Simpler alternatives exist for organisations managing small case volumes where full case management systems would be disproportionate. Structured spreadsheets with appropriate access controls can manage 20-50 cases, though this approach lacks audit trails, workflow enforcement, and scalability. The transition threshold from spreadsheets to proper case management systems typically occurs around 30-50 active cases or when multiple case workers need coordinated access.
Organisations with Established IT Functions
Organisations with technical capacity can deploy self-hosted platforms, enabling complete data control and customisation. Self-hosted Primero or CommCare requires Linux server administration, database management, and application maintenance skills. Deployment complexity varies: CommCare requires relatively straightforward Docker deployment, while Primero involves more complex infrastructure. Budget 2-4 weeks for initial deployment and testing, with ongoing time for updates and maintenance.
Integration with existing systems extends case management value. Integration patterns include: identity provider integration for single sign-on (connecting to Microsoft Entra ID, Okta, or similar), beneficiary registration integration (linking case records to registration data without duplicating entry), referral service integration (automated referral transmission to receiving organisations), and reporting integration (feeding anonymised aggregates to organisational dashboards).
Customisation should follow platform conventions rather than forking codebases. Both Primero and CommCare support extensive configuration without code changes. Customisation requiring code changes creates maintenance burden and may conflict with future updates. Engage with platform communities before undertaking development; desired features may already be planned or implementable through configuration.
High-Risk Operating Contexts
Contexts with surveillance risks, device seizure potential, or infrastructure instability require additional security measures. Local encryption ensures case data remains protected if devices are seized. Remote wipe capability enables destruction of data on compromised devices. Duress protocols address situations where staff are compelled to provide access; some organisations implement duress passwords that appear to provide access while triggering alerts and hiding sensitive data.
Network security in hostile environments may require VPN usage for all case management traffic, connection through trusted networks only, or air-gapped local instances that never connect to internet. Air-gapped operation creates synchronisation challenges: data must be transferred through physical media (encrypted USB drives) following secure procedures.
Exit planning prepares for rapid departure. Organisations operating in volatile contexts should maintain current backups stored outside the country, documented data destruction procedures for emergency evacuation, and succession plans for case transfer if operations cease abruptly. Case continuity matters for protection clients; planning should address how cases will be transferred to continuing organisations if evacuation occurs.