How do we intend to Sync both Questionnaire and their receptive Structure maps for Quest? ?

[f-odhiambo]

With the current implementation, we need to create a structure map for some questionnaires in order to map and perform an extraction to get the respective FHIR resources. How do envision to do do this so that we do not need to write StructureMaps in ap for each respective questionnaire but instead sync both Questionnaires and their respective StructureMaps from HAPI

[pld]

We should be able to follow the same pattern as in this PR, https://github.com/opensrp/fhircore/pull/590/files, just as we sync Questionnaires IDd by publisher (which we'll replace later on) we can do the same for StructureMaps.

Not sure what the best way to link Questionnaire to a specific StructureMap is, useContext could solve this generally in the future, for now I suggest a convention where the name of a StructureMap is the same as the name of the Questionniare that it applies to.

[trevorgowing]

I see two potential solutions here related to the the pattern implemented for QuestionnaireSync based on publisher.

1. Filter StructureMap by publisher using existing Questionnaire Publisher Preference.
2. Replicate the Questionnaire Publisher Preference pattern to Filter StructureMaps publisher or by some other StructureMap property.

Either of those will take care of syncing the StructureMaps to the device.

I am not very familiar with the StructureMap resource so I am not sure what the recommended approach is for referencing the source Questionnaire for the StructureMap. I would think that there is likely a spec for that in the SDC IG.

I think that we need to have a look the below to see what the recommend approach is for defining a Questionnaire as the source of a StructureMap for extraction.

• https://build.fhir.org/ig/HL7/sdc/extraction.html#structuremap-based-extraction
• https://build.fhir.org/ig/HL7/sdc/StructureDefinition-sdc-questionnaire-extr-smap.html

[pld]

Is option (1) less additional code? I think there's a least a decent change we redo this after we plan for #594, so I'd suggest the lower LOE approach

[trevorgowing]

Option 1 requires this only
https://github.com/opensrp/fhircore/blob/main/android/quest/src/main/java/org/smartregister/fhircore/quest/QuestApplication.kt#L66

class QuestApplication : Application(), ConfigurableApplication {

  ...

  override val resourceSyncParams: Map<ResourceType, Map<String, String>>
    get() {
      return mapOf(
        ResourceType.Binary to mapOf("_id" to CONFIG_RESOURCE_IDS),
        ResourceType.CarePlan to mapOf(),
        ResourceType.Patient to mapOf(),
        ResourceType.Questionnaire to buildQuestionnaireFilterMap()
      )
    }

  private fun buildQuestionnaireFilterMap(): MutableMap<String, String> {
    val questionnaireFilterMap: MutableMap<String, String> = HashMap()
    val publisher =
      SharedPreferencesHelper.read(USER_QUESTIONNAIRE_PUBLISHER_SHARED_PREFERENCE_KEY, null)
    if (publisher != null) questionnaireFilterMap[Questionnaire.SP_PUBLISHER] = publisher
    return questionnaireFilterMap
  }

...

}

Option 2 additionally requires the addition of an additional user attribute in Keycloak plus the extraction and storage of the value similar to

fhircore/android/engine/src/main/java/org/smartregister/fhircore/engine/ui/login/LoginViewModel.kt

Line 60 in 70c8a14

storeUserPreferences(this)

class LoginViewModel(
  application: Application,
  val authenticationService: AuthenticationService,
  loginViewConfiguration: LoginViewConfiguration,
  private val dispatcher: DispatcherProvider = DefaultDispatcherProvider
) : AndroidViewModel(application), AccountManagerCallback<Bundle> {

  val sharedPreferences =
    SharedPreferencesHelper.init(getApplication<Application>().applicationContext)

  val responseBodyHandler =
    object : ResponseHandler<ResponseBody> {
      override fun handleResponse(call: Call<ResponseBody>, response: Response<ResponseBody>) {
        response.body()?.run {
          storeUserPreferences(this)
          _showProgressBar.postValue(false)
        }
      }

      override fun handleFailure(call: Call<ResponseBody>, throwable: Throwable) {
        Timber.e(throwable)
        _loginError.postValue(throwable.localizedMessage)
        _showProgressBar.postValue(false)
      }
    }

  private fun storeUserPreferences(responseBody: ResponseBody) {
    val responseBodyString = responseBody.string()
    Timber.d(responseBodyString)
    val userResponse = responseBodyString.decodeJson<UserResponse>()
    sharedPreferences.write(
      USER_QUESTIONNAIRE_PUBLISHER_SHARED_PREFERENCE_KEY,
      userResponse.questionnairePublisher
    )
  }

So neither option requires a lot of code.

[pld]

Cool, thanks, let's go w/option 1

[f-odhiambo]

Also noting that we may require other types of extraction in other cases for some questionnaires i.e.

1. Observation-based
2. definition-based
3. StructureMap-based

see more here http://hl7.org/fhir/uv/sdc/2019May/extraction.html
Follow up question, do we tag, the Questionnaire, QuestionnaireResponse and the associated extraction method?
CC @trevorgowing

[trevorgowing]

@f-odhiambo From my understanding only StructureMap-based extraction requires the additional resource whereas Observation-based and Definition-based are defined as extension on the Questionnaire directly. I be could wrong though.

[f-odhiambo]

@trevorgowing, Yeah, I was flagging when you sync do we need to define how to trigger the extraction method? Thoughts?

[trevorgowing]

@f-odhiambo I consider sync and extraction separate. The SDK should take care of extraction for us. We just need to trigger it I would guess. Still digging into the SDC module.