Evaluate migration to FHIR validator for questionnaire validation in the SDC library

[jingtang10]

Is your feature request related to a problem? Please describe.
In the SDC lib, we validate answers in a questionnaire response by going through the value constraint extensions. Our code is pretty clean :): https://github.com/google/android-fhir/tree/master/datacapture/src/main/java/com/google/android/fhir/datacapture/validation.

However, as SDC IG evolves, there is an ongoing need for maintainance of validation code to keep up with any new extensions. Given that there is an existing FHIR validator in Java that already does validation (which includes questionnaire validation), we should look into using that validator.

Describe the solution you'd like
Our validator validates on a per-question level. And as far as I know, the FHIR validator only has an API on the per-resource level. Given that we actually do validation for each key stroke when the user fills the questionnaire, this might be an issue and in our evaluation we need to pay special attention to this aspect.

The other thing we need to do is to attribute any error message back to individual questions - and the FHIR validator will include the link id in the context. There is a small issue though - link id in questionnaire is not unique (surprisingly!) if there are nested questions under either a repeated group or a question with repeated answers (since the nested questions will be duplicated for each instance of the repeated groups or the repeated answers). We might need to raise a feature request for the validator to enrich the context field to be a linkid/index chain.

Describe alternatives you've considered
status quo (validation code in sdc lib) - works well but duplication of effort
other validation libs? - if so they probably should use the FHIR validator instead?

Additional context
https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator

Would you like to work on the issue?
probably :)

[jingtang10]

@fredhersch

[jingtang10]

Related but maybe different from #962?

[grahamegrieve]

in terms of linkIds in issues... I'll investigate

[jingtang10]

thanks @grahamegrieve - in terms of duplication of link ids @joiskash drew some diagrams here: https://build.fhir.org/questionnaireresponse.html#link that explain the situation very well.

[grahamegrieve]

Well, it turns out that the response doesn't include the link id at all. It's just where in the qr the issue is
Questionnaire.item[0].item[2].answer[3]. But we certainly could add a linkId based response... it'd be (/{linkId})+)?

[jingtang10]

ah ok - but we'd need the index as well since repeated groups or repeated answers might cause duplication of link ids in qr (although link ids in the questionnaire are always unique).

for example, if you have a question with link id 1 which is vaccination date, and a question on vaccination type nested under this question with link id 2. and you have provided 2 answers to question 1, in the qr you'd have two answers each with a nested question 2. this makes the link id 2 not unique in the qr.

[jingtang10]

i guess i don't mind Questionnaire.item[0].item[2].answer[3] -> we can parse this and locate the question equally as well as the link id + index based approach.

[grahamegrieve]

yes index oops. so (/{linkId}[n])+. but you want to do it by link id not by element id in the QR?

[jingtang10]

actually it is fine as is i think. we'll try this first grahame and get back to you if we need this to be changed.