Dynamically generate job aids from DeviceDefinition

[vincent-karuri]

To support displaying job aids to the user, we'll need a way to dynamically generate the NativeForm steps that constitute a job aid (pulling them from the FHIR DeviceDefinition). The process needs to be dynamic since job aids vary from one manufacturer to another.

At the moment, we generally expect a text prompt and an accompanying image to be sufficient fields for most steps in a job aid. Data corresponding to each step should ideally be collated into one "object" to simplify queries.

The implementation plan is as follows:

• [ ] Have the first section of the form common to all RDTs and allow a user to select the RDT they wish to capture either manually or by scanning a barcode
• [ ] Close out the first section and launch a second section that displays the job aid for the selected RDT, possibly including timers (this section will require extracting step information from the DeviceDefinition)
• [ ] Close out the second section and launch a third section that presents general RDT post-collection information
• [ ] Each of the sections is tracked as three separate forms (might also require separate event types for each) - 1 and 3 being static and 2 being dynamic

@githengi suggests using the Questionnaire FHIR resource to collate step data. This would include the text prompt, the image, timer information etc.

[vincent-karuri]

@pld I'll need help creating the questionnaire.

[pld]

k, go ahead and create a draft, I can review

[vincent-karuri]

I'm thinking we can encode Questionnaires in the property or capability fields of the DeviceDefinition?

Each Questionnaire would correspond to a step on the form and have one item that displays the instructions and another that holds the base64 encoded image e.g.

{
    title:step1,
    description: this is the first page on the form,
    [ 
       {
          text: step instructions go here,
          type: display
       },
       {
          text: base64 encoded image goes here,
          type: display
       },
       {
          text: Timer information,
          type: dateTime
       }
       .
       .
       .
    ]
},
.
.
.
{
    title:step4,
    description: this is the fourth page on the form,
    [ 
       {
          text: step instructions go here,
          type: display
       },
       {
          text: base64 encoded image goes here,
          type: display
       },
       {
          text: Timer information,
          type: dateTime
       }
       .
       .
       .
    ]
},
.
.
.

[pld]

Are the questionnaires tied to specific devices?

On Nov 17, 2020, at 8:07 AM, vincent-karuri notifications@github.com wrote:

I'm thinking we can encode Questionnaires in the property https://github.com/onaio/Covid19/blob/87cec883409c16b5ce3ac7b1ab9c0df4cb2a06e6/scripts/device-definition/device_definitions-rdt-og-2020-09-18.json#L166 or capability https://github.com/onaio/Covid19/blob/87cec883409c16b5ce3ac7b1ab9c0df4cb2a06e6/scripts/device-definition/device_definitions-rdt-og-2020-09-18.json#L32 fields of the DeviceDefinition?

Each Questionnaire would correspond to a step on the form and have one item that displays the instructions and another that holds the base64 encoded image e.g.

{ title:step1, description: this is the first page on the form, [ { text: step instructions go here, type: display }, { text: base64 encoded image goes here, type: display }, . . . ] }, .. . .. { title:step4, description: this is the fourth page on the form, [ { text: step instructions go here, type: display }, { text: base64 encoded image goes here, type: display }, . . . ] }, .. . .. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/onaio/rdt-standard/issues/590#issuecomment-728915262, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMEUEGRCAXTETPJJCI53SQJYSBANCNFSM4THI5WUQ.

[vincent-karuri]

Yes, they correspond to job aids. And each device might have a different job aid.

[vincent-karuri]

But I think we were looking to provide some generic job aids at some point. @shivenbhatt1 could you confirm this?

[shivenbhatt1]

@vincent-karuri @pld All the steps are listed in the FHIR device definitions list An explanation is given in #588 and images are being compiled in #358. All the images for antibody-based rdts are already in. We need some nasal swab images.

[vincent-karuri]

So we want all RDTs of a particular type e.g. blood, swab etc. sharing the same job aids, right?

On Tue, 17 Nov 2020, 18:44 shivenbhatt1, notifications@github.com wrote:

@vincent-karuri https://github.com/vincent-karuri @pld https://github.com/pld All the steps are listed in the FHIR device definitions list https://docs.google.com/spreadsheets/d/1P9yCzXHoy9Dz0_hp43GX_qpOc6Ayvz_D2TCReNVN_n4/edit#gid=0 An explanation is given in #588 https://github.com/onaio/rdt-standard/issues/588 and images are being compiled in #358 https://github.com/onaio/rdt-standard/issues/358. All the images for antibody-based rdts are already in. We need some nasal swab images.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/onaio/rdt-standard/issues/590#issuecomment-729015094, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7P3HWFFSLST5GPG3TNLS3SQKK4NANCNFSM4THI5WUQ .

[shivenbhatt1]

@vincent-karuri That is correct. I'm going through some of the nuances of the swabs and verifying general stock images right now. But blood tests seem pretty straight forward.

[vincent-karuri]

Ok, @pld do you know if there's a way to cater for this fact - multiple devices sharing the same aids?

I guess we could always allow duplicate aids (which would cleanly integrate completely different flows for each RDT in case we needed them) but may not be ideal in this case where we want only 2 sets of job aids shared among all RDTs.

[pld]

Yea agree that's not clean, also logically storing these with the DeviceDefinition sounds inappropriate, b/c these aren't actually part of the definition of the device, it's seperate information.

We can look at the FHIR resources and see what it makes sense to connect in here, I could start taking guesses, but probably makes sense to have a conversation with @githengi and @craigappl.

[vincent-karuri]

Ok, more formally or just on this issue?

[pld]

On this topic:

1) is there an appropriate FHIR resource for this job aids 2) what are the appropriate hooks in the DeviceDefinition to connect this

I think you should do a first pass and propose answers (or a set of possible answers) to the above, then we can discuss with them

On Nov 18, 2020, at 8:33 AM, vincent-karuri notifications@github.com wrote:

Ok, more formally or just on this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/onaio/rdt-standard/issues/590#issuecomment-729679849, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMEWRSEXTGM3LGTSL53TSQPEMNANCNFSM4THI5WUQ.

[vincent-karuri]

With trying to keep the job aids separate from (and still be able to share them across) DeviceDefinitions, sounds like we might need a way to reference a job aid definition.

We could possibly use logical references or literal references for this. We can add job aid resources as part of the DeviceDefinition bundle and use their unique ids as references within a DeviceDefinition.

We might need to define an extension that holds the job aid reference in the DeviceDefinition - I don't think there's a provision for job aids in the standard DeviceDefinition. The reference will simply point to the job aid's unique resource id.

We can keep @githengi's suggestion of using Questionnaire as the resource holding the job aids.

Again, not sure any of this is quite the right way to do this in FHIR.

[pld]

Questionnaire makes sense, let's keep it as decoupled as we can, we'll probably want to rewrite this once we make progress w/the android fhir sdk and there's another use case

[vincent-karuri]

Ok, I think the easiest way to keep Questionnaires decoupled for now is to have them as separate entries in the Bundle. Moving them outside the Bundle may start to complicate things a bit.

[pld]

Agreed that sounds good

On Dec 1, 2020, at 03:28, vincent-karuri notifications@github.com wrote:

 Ok, I think the easiest way to keep Questionnaires decoupled for now is to have them as separate entries in the Bundle. Moving them outside the Bundle may start to complicate things a bit.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[vincent-karuri]

• [ ] Modify python script to include Questionnaire data
• [ ] Create a helper util on the Android client to process Questionnaires and dynamically generate forms from them
• [ ] Modify the event-saving process to support launching forms based on responses in a submitted form

[vincent-karuri]

Implementation plan to support dynamic form generation and auto-launch of chained forms:

• Generate a valid Questionnaire beforehand for testing purposes
• Pull the DeviceDefinition resource ID from obs (this corresponds to the device the user selected)
• From the DeviceDefinition, retrieve the Questionnaire tied to it from the FHIR bundle
• Dynamically generate a Native Form from the Questionnaire with all required values pre-populated e.g. baseentityid, location, team, openmrs values etc.
• The generation should happen in it's own thread separate from the one that saves the form, all interaction with the app can be blocked using a progress dialog as this happens
• Launch the form once generation is complete
• Each form can have an optional top-level nextStaticForm or nextDynamicForm value to specify if a submitted form requires generation and launch of a static or dynamic form after it's submitted
• nextStaticForm should point to a form under assets while nextDynamicForm should name an obs from which a Questionnaire resource ID can be retrieved