Validate StructureMaps based on connection to Questionnaires

[pld]

Extend validation tooling and expand CI to:

1. Parse the Composition to create a map from Questionnaires to the StructureMaps
2. For each (Questionnaire, StructureMap) pair
   1. Generate a QuestionnnaireResponse for the Questionnaire
   2. Run the StructureMap against the QuestionnaireResponse and output a list of additional [Resources]
      • Fail any StructureMap fails to run
   3. For each Resource in the output list of [Resources]
      1. Validate it is valid FHIR with valid references
         • Fail if any resource is invalid or has invalid references
3. Pass

[pld]

Somewhat related issue, https://github.com/onaio/fhir-tooling/issues/6

[pld]

Somewhat related issue, https://github.com/opensrp/fhircore/issues/3113

[f-odhiambo]

NB. We need some form of template validation that will help validate gaps in missing references that cause malformed resources e.g.

1. Encounter.subject = Patient/$patient_id = valid
2. Encounter.subject = $patient_id is not valid
3. Encounter.subject = Patient/ is not valid

This should apply to other Resources that reference each other

Maybe having a reference check such as Reference xx/xx should be sufficient

[pld]

Good call, yep we probably need something like a linter for FHIR, or a very rudimentary version of that

[dubdabasoduba]

@Wambere @f-odhiambo I am looking at this validation in 2 stages

Stage 1

• Here we validate the schema i.e. is the generated resource a valid FHIR resource?
• This will check for all the required FHIR properties and their syntax making sure the resources are valid.
• This uses the HAPI validator lib which is already added as a dependency on the efsity based on this function
• This step addresses the comments by @f-odhiambo here

Stage 2

• Here we go a little deeper in the reference validation.
• We know the references are correctly structured if they pass stage 1.
• This stage checks if the referenced resources actually exist.
• We might need 2 approaches for this
  1. For some cases checking the referenced resources in the generated bundle will suffice since all the subject resources are in the bundle. Examples of such situations are when testing the SM and QR generated during client/entity registration.
  2. For other cases we might want to provide a way to give the validator the subject resources referenced but not found on the current extracted bundle by:-
     • Adding them in a folder somewhere
     • Adding the server credentials of where the subject resource might be found. The validator would then access the server in search of the subject resource.
• This stage also addresses the comments by @pld here

cc: @pld

[pld]

Sounds good, for stage 2 we would not want to access a server, we need to have this test work without assuming anything exists that the test writer cannot control.

There's a potential Stage 3 where we write the extracted resources first, or a subset of them, like should create this resources with these keys filled... hmm actually instead of writing the extracted resource a Profile might be want we want , then we validate that the extracted resources matches the target (or the profile). And later we build tooling to generate the structuremap from the Q and the target/profile

@Wambere let's focus on Stage 1 for now, get that into CI, then we can revisit the approach for Stage 2 and how it fits into our priorities.