Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

The Rapid Diagnostics Toolkit can be configured in a number of different ways, details about some of the most common are listed below.

Provisioning: By diagnostic type, or by list of tests

The toolkit can be configured to either request a specific test result type and allow the user to choose any test available, or to present the user with a specific set of tests to choose from.

Using the Diagnostic Type

This approach is helpful for programs which are most interested in the result of an RDT, and where multiple RDT's may be available to users potentially including new tests in the future.

We recommend this for most programs since the RDT's available may change, but it may introduce challenges with users with less training, or when very specific RDTs will be available for campaigns of with limited lifespans

For example, provisioning could be requested with a Malaria Falciparum diagnostic code, and the user will see all tests which include a Falciparum result, including tests which might have other diagnostic results as well. If a user normally tests with First Response PF tests, but they are unavailable one day, they could instead use a Care Start PF / PV test instead, and the application and program will function seamlessly.

To configure in this mode, the provisioning intent should use the following variables:

  • rdt_config_provision_mode  = 'CRITERIA_SET_AND'

  • rdt_config_provision_mode_data = Space separated list of all of the Diagnostic Codes for the diseases needed from the list of Currently Supported RDTs
    • 'mal_pf mal_pv' - For example, will show all tests which include both PF and PV results


Using the List of Tests

In this approach, the app provides a limited subset of the tests available, allowing the user to pick from only that list. This approach can reduce errors in choosing tests, and streamline choices for end users, but may introduce problems if replacement tests are used or programs introduce other options.

To configure in this mode, the provisioning intent should use the following variables:

  • rdt_config_provision_mode  = 'CRITERIA_SET_OR'

  • rdt_config_provision_mode_data = Space separated list of all of the Toolkit Codes for the diseases needed from the list of Currently Supported RDTs
    • 'sd_bioline_mal_pf_pv carestart_mal_pf_pv' - For example, will allow the user to only choose SD Bioline PF / PV tests, or Carestart PF / PV tests, in a situation where those are the only two available to a program.

Debug Mode

For an app builder, the toolkit allows provisioning tests in "debug mode," which may provide additional options for streamlining testing and integration of the app

  • FLAG_TESTING_QA
    • 'TRUE' - Allow QA Options
    • 'FALSE' - Normal user mode

[Optional] Connecting a Cloudworks Backend

During provisioning, the toolkit can provide a Data Source Name (DSN) to a compatible Cloudworks backend to capture additional data about the tests. Cloudworks will provide the DSN once configured for data feeds, it should be in the form of a web URL. 

If a Cloudworks backend is to be used, the following variable will need to be configured as Extra values during the Provisioning step.

  • rdt_config_cloudworks_dns- The DSN URL of the Cloudworks server

In additional the following values are optional to provide but will change the behavior of cloudworks.

  • rdt_config_cloudworks_context - A unique identifier which can be used to connect test data to a specific session or individual in the future. Should be a non-identifiable field like a case id

  • No labels