Scan barcode or QR code to get study subjects' data (incl string vars) from a lookuptable or equivalent

Feature Suggestions
#1

For repeated measurements (panel setting) it would be great enumerators can

  1. just scan a barcode or QR code to get to the right assignment;
  2. in within a questionnaire scan a bar code to preload values
#2
  1. not possible. Enumerators can’t make assignments.
  2. not possible. Tablets work disconnected.
#3
  1. ok
  2. through lookup tables?
#4

elaborate on #2 please

#5

Goal is to preload data from a lookuptable by scanning a study participant’s code. The data the lookuptable contains comes from earlier rounds in a cohort or panel study.
Added value:

  • prevent ID errors (enumerators being in wrong HH): scanning a code is more certain than entering an ID code.
  • Avoid entering string data (names, etc ) again.

For follow-up visits:

  1. enumerator scans a QRcode on the study participant’s card
  2. string variable corresponding to QRcode is generated
  3. ideally destring to numeric (not yet possible?)
  4. use this numeric as rowcode variable for lookuptable (these cannot contain strings)
  5. use data from lookuptable to either preload values (from census or baseline) or use for calculations?

It boils down to the lack of flexibility (lookuptables only numeric) and scanned codes being stored as string vars.

#6

No on the first point. This is not an added value. You can perfectly scan the ID barcode and verify that you are in the correct household with the current functionality.

No on the second point. If the information is known it should be preloaded in the office (names).

Subsequent plan is not clear:

  1. enumerator [JOHN] scans a QRcode on the study participant’s card
    then
  2. enumerator [MARY] scans a QRcode on the study participant’s card

and you end up with two interviews. How would MARY know that JOHN has already processed this household? Everything goes broken from that point onward.

The security issues of giving to every enumerator the full data of the previous survey are unthinkable. Syncing all that data over the networks, storing 1000000 records only to process 10 interviews, etc, etc, etc.

You are definitely coming from some background where you experienced such a system in a CONNECTED setup, where you scan your passport in the airport and the query is run to retrieve your visa number. But the visa data are not stored every such terminal.

It boils down to the lack of flexibility (lookuptables only numeric) and scanned codes being stored as string vars.

It boils to fundamental differences in environments and philosophy of the system.

#7

Thanks, these are good points.

Whether using a QR code or not, having data available from previous rounds on the tablets to check the accuracy of a measurement is challenging. Collecting anthropometry every month and wanting to check the current measurement length measurements with 5-6 previous measurements in the same child is difficult. We did this before with surveybe which slowed down the program significantly (surveybe is a rather heavy program to run though).
In clinical trials, being able to get a patient’s morbidity history to decide to exclude them from a trial etc. will require other solutions.

#8

Since this a feature request, could say more about the shortcomings of how current functionality for your needs?

Based on your description, I understand that you are conducting a panel survey, and want to validate measures obtained at time T with those obtained at time T-1 (for example).

If that’s the case, I would suggest that you create assignments for each household at time T that contain preloaded values for measures from time T-1. That is, each interviewed household would have an assignment, and each assignment would contain data about the attributes of the household (or its members, possessions, etc.).

In a certain sense, the only thing that differs between the two approaches–preloading in the field or preloading before going to the field–is when the preloading takes place, and by what mechanism. For the QR code approach, preloading happens at interview-time. For the preloading in the assignment, preloading happens at assignment creation.

Could you provide some use cases when interview-time preloading would be strictly preferred–or even required–as opposed to assignment creation-time preloading?

#9

Sorry for the late reply .

  1. On preloading data from previous rounds to validate current entries: the current functionality works. Preloading data from previous rounds (t-1, t-2, t-3) into the current round (t) is what we are doing now. We just need to assess how slow the program becomes if we preload too much data (one, two our three previous rounds).

  2. To avoid ID errors with QR code: An enumerator opens his assignment, checks identifiers from HH to ascertain that he is in the correct HH, he will also scan the QRcode of participant’s study card. The scanned QR-code will be compared to the preloaded qr code (validation)

  3. I understand that the current system does not support scanning a QR code to get to the right assignment.

  4. What lacks in my view is the ability to scan a barcode to retrieve values from a lookuptable. (QR code are strings and lookuptable is numeric).

Could you provide some use cases when interview-time preloading would be strictly preferred–or even required–as opposed to assignment creation-time preloading?

With interview-time, are you referring to the use of lookuptables or a preload at time of interview that requires connection with an external source/server?

Thanks

#10

By interview-time preloading, I was referring to your strategy of scanning a QR code in order to pull values from a lookup table into the interview (e.g., pull preloaded information for household 123).

I was looking for use cases when you would absolutely need the QR code strategy, or would strongly want it.

Regarding

On preloading data from previous rounds to validate current entries: the current functionality works. Preloading data from previous rounds (t-1, t-2, t-3) into the current round (t) is what we are doing now. We just need to assess how slow the program becomes if we preload too much data (one, two our three previous rounds).

The Interviewer application should not be any slower because of preloading, since preloading is essentially the same has answering questions. But let us know if it is. The only thing that may be slightly slower, in my experience, is opening the interview for the very first time.