Leverage QR codes in your configuration

An article for configuring DHIS2 to make use of QR codes. This considers primarily reading QR codes, but over time will address more concerning QR code generation, security/data privacy and management.

Instructions

To scan and read QR codes in DHIS2:

  • You do it via the DHIS2 Android App - it cannot be done on the desktop.
  • You need Android App v2.1 or later
  • You need DHIS2 2.34 to be able to select QR render type
  • The DE or TEA needs to be TEXT value type and RENDERED as QR code once added to the program

  • To use the QR code to search for and open a TEI record, the TEA will need to be marked as “searchable” also.

  • I don’t know if it is possible to have DHIS2, via the same data element, both autogenerate a textPattern like “ABC-1234”, and also allow reading of a QR code. This would need testing, but my suspicion is once you render a DE/TEA as a QR code the android will only attempt to read a QR code and not allow text string generation via textPattern.

QR codes: i’m learning a little about how these work, but:

  • It seems QR codes encode a string value. It is a hard-coded thing, so whilst different formats of QR codes (and of course there are many different formats) will appear visually different, the information encoded in the barcode is the same thing. So if the information encoded is “ABC-1234” it will always be read as that.

  • As such, were we to render a Unique ID TEA as QR code part way through an implementation, we wouldn’t need to do anything to change the underlying data, because the actual value stored in DHIS2 is TEXT and not the QR image. DHIS2 essentially decodes the barcode, reads that it says “ABC-1234” and either stores it (if new) or finds a record (if searching and it exists).

  • Thus to use QR codes, the main programmatic consideration needs to be how to put QR codes into the hands of those people who already have been registered.

  • Accepted DHIS2 QR formats are listed in a comment on this thread…  https://community.dhis2.org/t/dhis2-android-capture-app-version-2-1-is-released/39065/23

  • I have also asked in the same thread if Oslo recommend a particular QR code generator as best practise. Once WeAct have settled on a QR code generator, it should be possible to raise the QR coes against the existing Unique IDs.

Some documentation and a use-case that was what brought DHIS2 up to speed on QR codes… 

https://www.dhis2.org/uganda-covid-surveillance - COVID-19 App surveillance and QR code

Documentation - https://docs.dhis2.org/2.33/en/dhis2_android_capture_app/visual-configurations.html#qr-and-barcodes 

Jira - https://jira.dhis2.org/browse/ANDROAPP-1670

Workflow: It strikes me then that the greatest lift to make this happen in an implementation would be…

  1. Find a QR code generator that is compatible with the accepted DHIS2 QR formats (I think this should be VERY easy)
  2. Upgrade to 2.34+ and Android 2.1+

  3. Most importantly, you will need a workflow for solving the following problems:

  4. Deciding the relationship between the QR code and the Unique ID. I could imagine, either:

    • The QR code generator drives the Unique ID as a random string, and we let the QR code generator ensure unicity and not worry about the underlying text string.
    • Continue to have DHIS2 autogenerate the text-string, and then generate QR codes which encode that DHIS2 string.
  5. Decide how the QR code will be stored by the project once it is generated, if at all
  6. Decide how, and in what format, the QR code will be shared with the enrolled individual - since they will need a copy to present at future events when they register (the whole point of the code)
  7. Decide contingencies/protocols for what is accepted should a person return to an event without their QR code? Do you need identification to verify they are who they say they are? Of course it is possible to find a TEI record based on other searchable attributes.
  8. Are the QR codes being generated secure and confidential at the QR generator? It would be worth looking into the privacy and data protection info of the selected QR code generator to see what details are taken and stored.
  9. Possibly there are other things not thought of, but these are just issues I see.

Two possible solutions to the above problems, could be:

  • If they opt to have DHIS2 continue autogenerating textPatterns for the unique ID, then at enrolment the textPattern can be entered into a QR code generator such as this very basic first google search result one: https://www.the-qrcode-generator.com/ - I’m not recommending this generator, it is just an example. It probably has hurrendours privacy
  • You see you can save the QR code as an image. The enrolling agent could do that.
  • We add another TEA to the the TEI’s profile of value type IMAGE, which is marked compulsory, and store this QR code image against it. This will mean if they lose their QR code, it is stored against their profile for an easy reissue.
  • We then write a program notification - this is an automated rule which we can choose to have automatically trigger when enrolment completes - and this notification can send an email to the address of the newly enrolled TEI. It is possible to include variables in these notifications - variables being the responses to attributes to tailor the message. I’m not sure if it is possible to handle images but, if it is, then we include the QR code as a variable and it automatically will get sent to the TEI when enrolment is complete.
  • If it is not possible to send images in program notifications I still recommend we store the QR code against the tracked individual, but then we need to find a way to securely transfer the QR code from the project to the TEI - this could perhaps be as an image attachment, but again you would want to look into the security/data privacy of such an approach.