Illustration of the Network of Things

Interagency Data Exchange

SARA solves interagency data sharing requirements in a new way.

Sharing critical client data with stakeholder agencies is becoming a new norm, but the challenges remain in terms of technical, legal, and budgetary obstacles. Consider the following issues most agencies face: 

1. Getting permission from participants to share data with other agencies.

2. Ensuring that clients are recognized between systems, so data is picked up regardless of which program the client receives services from.

3. Ensuring that the diverse CMSs can actually communicate with each other using common data formats. 

4. Ensuring that only PERMISSABLE data elements are transmitted to relevant stakeholders. 

5. Ensuring that relevant, shared client data is transmitted and made available to every partner case management system to increase service/investment efficiency and reduce duplication.

“It’s important to compare the annual cost of SARA to that of the employees that would be needed to do the same work. SARA can do so many things. It is very cost effective.”

—Dr. Chaz Compton
SDSU Research Foundation, Project Director – WINTAC

Traditional Approaches to Data Integration

There are three traditional approaches to integrating common data for multiple agencies:

  • Replace all existing case management systems (CMS) with a universal CMS for all to use.
  • Create an additional application layer designed to capture information from all stakeholder CMSs and update every related CMS accordingly while providing a common performance reporting tool.
  • Integrate the data manually, which still requires an application to identify shared clients.

In addition to the hurdles that each of these three approaches present, none solve the problem of actually collecting the required data for performance reporting. Each approach is costly, time-consuming, and can’t guarantee that the agency will be in compliance when required. None of these approaches solve the problem of first getting specific permission from clients to share the data.

The primary issue with all of these approaches is the significant differences between how and when systems capture, store, and identify client data.

The SARA Approach to Data Integration

SARA is an extension to any case management system that automatically captures relevant client data BEFORE it is entered into the CMS.

There is no need to format and match data after the fact, and no need to modify any aspects of the existing CMS.

SARA provides each CMS with an API that automatically downloads and uploads data from and to SARA, formats the data for the specific CMS, and puts it into the system, making it available to staff. Client permission to share data is automatically gathered by SARA. Relevant data is automatically shared between agency/partner systems when sharing is approved. As a bonus, the required performance data from each program/partner becomes available system-wide in real-time.

Lastly, SARA collects required performance data. This is particularly useful for client-related performance data that must be collected after clients exit a program. 

SARA Data Transmissions

Data transmissions between SARA and case management systems are accomplished with a REST API on the SARA side and a behind-the-firewall utility on the CMS side (provided by The Career Index Corporation).

SARA’s REST API is an application program interface (API) that utilizes HTTP requests to receive, place, post, and delete data. This API enables multiple software applications to communicate with each other. The interaction works via secure, encrypted HTTPS and requires proper credentials to access the API.

The utility is a Windows® service that initiates data transfer on a regular schedule (e.g., every 60 seconds).

The REST API has access to a table on the SARA server that specifies login credentials and IP address as well as a CMS-specific Stored Procedure that retrieves the data required by the calling CMS. It also formats the data to the requirements of the CMS and ensures that all required fields are included.

The API can also receive new client data as well as case manager changes and exit dates from the utility. New clients entered into the CMS can be automatically added to SARA. Likewise, SARA can automatically switch clients to a new case manager or start post-exit follow-up based on information received from the CMS. In addition, the REST API can process ten different custom fields in the transfer process. These fields can be used to activate and/or cancel specific SARA tasks making her a tightly integrated team player with the existing CMS.

It’s a complex process that is seamless to SARA’s users. You don’t have to understand how it works for it to work flawlessly.

SARA is Secure

SARA is a cloud-based application residing on the AWS GovCloud, only available to U.S. entities that can meet AWS’s stringent security requirements for government-related applications. 

SARA is HIPPA Certified, meaning that your staff can safely communicate personal medical information via SARA.

One way to evaluate the security of a site is to scan the vulnerability of the site and its SSL certificate. Qualsys SSL Labs has a service that allows for in-depth analysis:

This site rates and as a B. The Career Index Corporation’s VA implementation rates the highest A+ score.

The REST API and Windows service for data transfer between SARA and your agency CMS are located behind the SARA firewall and respond to incoming data requests only. The Career Index Corporation provides a utility to be installed behind the agency's firewall. The provided Windows service application needs access to a data store used for staging data to be transferred from SARA to the CMS and vice versa (SARA data is never uploaded directly to the agency CMS). The utility is fired by a scheduled task controlled by the agency. When fired, it connects with the SARA API using an encrypted HTTPS protocol. Part of the transmission is a user ID and encrypted password. The SARA API compares the user ID, decrypted password, and IP address of data stored for the utility communicating with it. The communication is allowed only if all values match.

In terms of Personally Identifiable Information (PII), SARA only stores first and last name, email address, and cell phone number — information that is available in public directories. SARA does not use SSN, date of birth, or store the client’s physical address.

PII data is stored encrypted using 256-bit encryption algorithms both in transit and while at rest.

Identifying Clients Across Agency Boundaries

Critical to integrating data systems is the ability to reliably identify existing clients regardless of which agency serves the client. Some agencies considered using Social Security Numbers (SSN), but that identifier is highly sensitive, and, in many areas, clients can decline to provide the SSN leading to lost records. Also, the presumption that two people never have the same SSN is incorrect. Unfortunately, the use of fraudulent SSNs is becoming more common.

To understand how SARA handles this issue, let’s examine how new clients are entered into SARA. The following information is required to establish a new client record:

  • First Name and Last Name
  • Email and/or Mobile Number
  • Internal CMS ID – e.g., the internal client identifier in the originating CMS
  • Case manager identifier (typically case manager’s email or assigned staff ID)

New clients can be added in one of three ways:

  1. Initial batch process. The Career Index Corporation receives an encrypted spreadsheet with the required client information and updates SARA accordingly.
  2. Automated processing using a Windows service and the SARA REST API. Each time a new client is entered into the CMS, the client is automatically added to SARA in the next transmission.
  3. Manually entered by a caseworker (if allowed by agency.

When a new client is entered (regardless of the method), SARA initiates a fuzzy-logic search algorithm to determine if that client already exists in related instances of SARA. The algorithm uses a combination of email address, cell number, and client's first and last name to make a confidence-based determination.

If SARA finds a potential match, the client is added to a cross-match table with the internal CMS client id from the system where the client was found.

Each agency has a set of rules to approve data sharing and transfer. For example, an agency may have a rule that all new matches found are automatically approved within seven days. This allows designated staff to manually approve or disapprove new client additions for data sharing. Rules can be set according to the needs of the agency.


At a 30,000-foot level, the traditional concept of linking CMSes together on the backend or creating a new, universal CMS may appear simple, but as you get closer to the ground, the picture becomes exponentially more complex. This work could easily result in continuous “change orders” on a massive scale, with unforeseen results. The devil is in the details, many of which will not appear until long after you made the change.

The SARA approach bypasses much of this inherent complexity. There is no need to modify existing systems. In fact, changes to the CMS mid-stream have virtually no impact. Agencies can be added along the way, and changes to how SARA operates can easily be made without requiring massive change orders. This last piece is crucial, as WIOA is a new law that is bound to change with time.

As a side-benefit, SARA changes staff focus from data entry, documentation, and compliance to direct client interaction and service, which benefits the clients and increases staff satisfaction and morale.