Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Changed link to point to gitHub doc

The following section provides detailed instructions and descriptions for the inclusion of the Rapid Diagnostic Toolkit application into the user workflow of a CommCare based application. For users wishing to include the Rapid Diagnostic Toolkit into an application built in an alternate digital health platform please see the Digital Health Software the Toolkit callout configuration section below docs.

Table of Contents

Android Callout 

To link from your Commcare application to the Rapid Diagnostics Toolkit, you need to have access to the advanced feature, Android App Callout. This feature is available to all CommCare app builders with an Advanced or higher plan or with a self-hosted instance. For those users, the Rapid Diagnostics Toolkit is free to use through an open source software license.

...

To ensure that CommCare is able to associate the Rapid Diagnostics Toolkit returned data with the relative person that the test is being completed for, certain properties need to be shared between CommCare and the Rapid Diagnostics Toolkit and vice versa. When initiating the RDT we need to share a unique id with the Rapid Diagnostics Toolkit and save it to the client case.

Initiate RDT Callout 

Step 1: Add 3 hidden value questions which provide the data properties to be shared with the Rapid Diagnostics Toolkit

...

To help users differentiate between tests that are running simultaneously and to report accurate data for multiple simultaneous tests, the session can be provided with two "Flavor Text" (flavor_one and flavour_two) lines which will be displayed in the UI of Rapid Diagnostics. 

Step 2: Add 4 hidden value questions to store the returned information from the Rapid Diagnostics Toolkit. If the RDT result is being captured in a different form than where it was initiated (example: Workflow 4) then you will need to save the following hidden values as case properties. 

  • time_resolved

  • time_expired

  • returned_session_id

  • test_provisioned with calculate condition: if(returned_session_id=””,’no,’yes’)

Step 3Add the android callout question

Step 4: Set up the android callout properties 


Extra

  • Set External App field to Custom and the text box to org.Rapid Diagnostics Toolkit.action.Provision

  • rdt_session_id = hidden value session_id

  • rdt_config_provision_mode  =

    •  'CRITERIA_SET_AND' If, for example, users should be allowed to pick any test which supports a Malaria Diagnosis, they can request the following, which will filter for all available criteria.

    • ‘CRITERIA_SET_OR’ if Alternatively, a session can be requisitioned to choose any test which meets one of the provided options

  • rdt_config_flavor_one = hidden value flavor_one

  • rdt_config_flavor_two = hidden value flavor_two

  • rdt_config_translator_session = 'xform_response'

  • rdt_config_translator_result = 'xform_response'

  • rdt_config_classifier_mode = 

    • 'PRE_POPULATE' - This setting will pre populate the select list to the user with the scanner interpreted result from the RDT image. The user can then confirm the results or update it what they determine the result to be

    • ‘BLIND’ - This setting will save the the scanner interpreted result  but hide them from the user when they capture the user interpreted result

  • FLAG_ANDROID_CALLING_PACKAGE = 'org.commcare.dalvik'

  • rdt_config_provision_mode_data =

    • Space separated list of test IDs used by the organization. Currently supported RDT IDs and information below:

    • ‘sd_bioline_mal_pf_pv’ - SD Bioline Malaria Ag Pf/Pv

    • ‘sd_standard_q_mal_pf_ag’ - SD Standard™ Q Malaria P.f Ag

    • ‘sd_bioline_mal_pf’ - SD Bioline Malaria Ag Pf

    • ‘carestart_mal_pf_pv’ - CareStart™ Malaria Pf/Pv (HRP2/pLDH) Ag Combo RDT

    • ‘firstresponse_mal_pf_pv’ - First Response® Malaria Ag P.f./P.v. (HRP2/pLDH) Card Test

    • 'firstresponse_mal_pf' - First Response® Malaria Ag P.f (HRP2) Card Test

  • rdt_input_translate = 'provision_flat'

...

  • rdt_session_time_resolved = hidden value time_resolved

  • rdt_session_time_expired = hidden value _time_expired

  • rdt_session_id = hidden value returned_session_id



Initiate Result Callout 

Step 1: Add a Image Capture question 

Step 2: Add 7 hidden properties to store the returned properties from the Rapid Diagnostics Toolkit 

...

  • Classifier_pf_outcome - this will save the rdt pf outcome determined by the classifier

  • Classifier_pv_outcome - this will save the rdt pv outcome determined by the classifier

  • Time_read - this will save the time that the user entered the test result

  • Seconds_elapsed - this will be user to calculate the time (in seconds) between the test being initiated and the user entering the results

  • Pf_outcome -  this will save the rdt pf outcome determined by the user

  • Pv_outcome - this will save the rdt pv outcome determined by the user


Step 3: Add the android callout question


Step 4: Set up the android callout properties 

  • Set External App field to Custom and the text box to org.Rapid Diagnostics Toolkit.action.Capture

Extra

  • Rdt_session_id = hidden value session_id



Response:

  • Result_mal_pf = hidden value pf_outcome

  • Result_mal_pv = hidden value pv_outcome

  • Rdt_session_result_time_read = hidden value time_read

  • Result_classifier_mal_pf = hidden value classifier_pf_outcome

  • Result_classifier_mal_pv = hidden value classifier_pv_outcome

  • Rdt_session_result_raw_image_path = image capture question



Customizing the Usage of the Toolkit

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.

...

here.