Skip to content
This repository has been archived by the owner on May 25, 2022. It is now read-only.

Case Management Integration

rdsubhas edited this page Jun 14, 2014 · 5 revisions

What is a Case Management System?

RapidFTR will be used for immediate registration of unaccompanied and separated children and to aid rapid reunification. The relationship between the aid agency and the child however, lasts much longer than this initial contact. The aid agency will typically follow up with the child regularly for the next 12 months after they have been reunified or placed in care. This long term relationship goes beyond the responsibilities of RapidFTR. RapidFTR is currently being managed in various Case Management Systems (different organisations have their own CMSs). CPIMS is one example of a Case Management System and is currently being used by Save The Children.

Rationale for CMS Integration

Before RapidFTR, all registration was done via paper forms. These forms would then have to be hand delivered to wherever the CMS was set up (it is not in the camps -> CPIMS for example is a standalone desktop app and so data is not shared across multiple instances). The paper forms could potentially spend quite a lot of time travelling around before the information was finally available in the correct system.

The focus for the integration piece is to remove as many paper forms as possible from the whole process. If RapidFTR is already capturing most of the necessary information, there is no reason that a file should be printed out (in PDF or Excel) and then re-typed into CPIMS or any other case management system.

How will this integration take place?

The idea is to expose the child data via an explicit api that the Case Management Systems can then call to get import data from RapidFTR.

The current thought process exposes a 1 way operation -> i.e. a CMS can export data out of rapidFTR, but cannot import data back into it. Going down the 2-way route would move RapidFTR into the realms of case management and so we’ve been exploring an alternative. Since CPIMS seems to generally be used as a data warehouse/reporting system in most instances, we could recommend that it continue to be used in this read-only type mode. RapidFTR would then act as the sole data collection tool, meaning no data would be changed in the CMS, only viewed. This removed the requirement for importing data back into RapidFTR and allows us to expose a 1 way export api.

Note. RapidFTR already had an API that was being used by the mobile application, the work done was just to standardise the api and move the existing calls into an 'api' namespace. This also meant updating the mobile application to consume the new/moved api. In order to support backwards compatibility, the old api calls were left in the code; this is important as we still have an older version of RapidFTR currently deployed in the field. We can now upgrade the server for these installations without being forced to upgrade the mobile apps in parallel. However, once the phones have been upgraded, the old calls need to be removed from the codebase.

Short term

Currently the CMSs are not in a position to be able to consume the API that we will be creating, and are assumed to be around 12 months away from this. We have a stop-gap solution to provide more immediate benefits.

There are many different case management systems that we will eventually need to integrate with. We are starting by focussing on CPIMS, as it is the most closely related to RapidFTR in that, it deals with child protection (as opposed to proGres for example, which deals with the general refugee population). We have identified two sets of stories, one for the longer term goal of a generic API to integrate with multiple case management systems, and another set of stories for a more immediate, temporary integration with CPIMS in particular.

The stop gap solution involves an option added to the RapidFTR UI which exports to CPIMS via an excel spreadsheet, in a format that can be directly imported into CPIMS via it's existing import function. To make sure this doesn't muddy the RapidFTR code we have implemented this a separate gem that is included.

API Documentation

The technical documentation of the API can be found on apigee. The page lists all of the available end points and is an interactive site that allows you to interact with the API and see the returned results in the browser.