DARIA

DARIA is a case-management system for abortion funds. It began with the DC Abortion Fund (DCAF), went into service there in 2016, and is now used by multiple funds across the United States. The project is no longer an active Civic Tech DC project, but the open-source software and an independent DARIA Engineering team remain active.

Why abortion funds needed more than shared spreadsheets

Abortion funds help people navigate appointments and provide grants when they cannot afford the full cost of abortion care. That work involves calls, contact information, patient status, pledges, clinic coordination, and follow-up across volunteer shifts.

According to the DARIA project documentation, about 75 DCAF case managers were recording roughly 3,500 calls each year in shared Excel sheets before the application launched. Case managers had to learn spreadsheet conventions, search for missing information, avoid overwriting one another’s work, and reconstruct context across shifts.

Built with abortion-fund case managers

DARIA was created by abortion funders and people who support abortion funds. DCAF supplied the original workflow, case-manager expertise, and production setting. The system was designed to mirror how volunteer case managers return calls, track patient needs and status, issue funding pledges, and record fulfillment.

That direct user involvement shaped the product more than a generic customer-relationship-management template could. Case-manager feedback collected by the project describes less time troubleshooting spreadsheets, better continuity between shifts, and more attention available for conversations with patients.

Those reports are valuable project evidence, but they are user accounts rather than an independent impact evaluation.

A workflow designed around sensitive care

DARIA uses a familiar case-management workflow while making choices specific to abortion-fund practice:

• patient records are searchable and organized around calls, status, pledges, and clinic coordination;
• each adopting fund has a separate instance and controls its own data;
• administrators can manage fund-specific settings and reporting workflows;
• anonymized data can be exported for analysis;
• sensitive information is deliberately minimized, restricted, or excluded from exports;
• personally identifying fields are removed on documented schedules after administrative use.

The project’s data-collection practices explain how the team weighs operational value against the harm that a breach could cause. One documented example is the decision to remove an immigration-status flag because the risk to patients outweighed the convenience to case managers.

Open-source software and the work around it

Volunteers built a Ruby on Rails application and released it under the MIT License. The public repository includes the application, tests, setup documentation, security guidance, onboarding material, a data dictionary, and contribution instructions. A public sandbox lets eligible organizations explore the workflow without real patient data.

Civic Tech DC helped provide an early community and volunteer home. The sustained project depended on more than initial software development: fund practitioners, technical leadership, security advice, documentation, administration, and ongoing maintenance.

From Civic Tech DC project to independent team

The current project README says DCAF and several other funds use DARIA and that the software is generally stable. The independent DARIA Engineering team now supports adoption, separate deployments, patches, monitoring, and maintenance.

This page labels DARIA as a past Civic Tech DC project because ownership and day-to-day work transitioned to the independent DARIA Engineering community. The repository is not archived and continues to receive updates. Organizations considering the software should use current DARIA documentation and contact its maintainers rather than treating this historical case study as implementation or security advice.

What DARIA’s history shows

1. Map the real workflow before choosing a database. The useful unit was not a generic “contact”; it was the sequence of calls, needs, pledges, clinics, and follow-up that case managers already understood.
2. Co-design changes the product. Practitioners revealed shift handoffs, high-risk data, reporting needs, and terminology that an outside technical team would have missed.
3. Privacy is a product requirement. Data minimization, separation, retention, and export rules belong in product decisions and code.
4. Adoption includes migration and administration. A working application still needs onboarding, data migration, fund-specific configuration, support, and training.
5. A durable volunteer project needs an owner. The transition to an independent team and service model matters as much as the first release.

Reuse the work or bring a related workflow

Abortion funds interested in DARIA should review the adoption guide, test the sandbox, and contact the current DARIA team. Developers can inspect the repository and its contribution guidance.

If your nonprofit or public-interest organization has a different case-management, database, or service-delivery problem, start with the workflow and bring it to Civic Tech DC. An existing tool may be the answer; if new work is justified, user participation, privacy, maintenance, and open-source reuse should shape it from the beginning.