Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate StructureMaps based on connection to Questionnaires #199

Open
pld opened this issue Jun 12, 2024 · 11 comments · May be fixed by #281
Open

Validate StructureMaps based on connection to Questionnaires #199

pld opened this issue Jun 12, 2024 · 11 comments · May be fixed by #281
Assignees
Labels
efsity FCT features Enhancement New feature or request

Comments

@pld
Copy link
Member

pld commented Jun 12, 2024

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 pld added Enhancement New feature or request efsity FCT features labels Jun 12, 2024
@pld
Copy link
Member Author

pld commented Jun 12, 2024

Somewhat related issue, #6

@pld
Copy link
Member Author

pld commented Jun 12, 2024

Somewhat related issue, opensrp/fhircore#3113

@f-odhiambo
Copy link
Contributor

f-odhiambo commented Jun 13, 2024

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
Copy link
Member Author

pld commented Jun 14, 2024

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

@dubdabasoduba
Copy link
Member

@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
Copy link
Member Author

pld commented Jun 20, 2024

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.

@pld pld added the Blocked Something is blocked label Jul 18, 2024
@pld
Copy link
Member Author

pld commented Jul 18, 2024

marking as blocked by #15

@Wambere Wambere removed the Blocked Something is blocked label Aug 20, 2024
@Wambere
Copy link
Contributor

Wambere commented Aug 29, 2024

Breaking this down to actionable tasks

  • Create a new command in efsity to validate structureMaps
    - Call it validateStructureMap
  • Set up two modes
    - Single mode: requires structureMap and questionnaire paths as input and validates the structureMap provided
    - Project mode: requires the project folder path and composition path as required input. This will use the composition to extract and map questionnaires to structureMaps, confirm they exist in the project path, and validate all pairs found
  • For each Questionnaire use the generateResponse command to generate QuestionnaireResponses
    - Use the validateFhir command to validate the generated QuestionnaireResponses
  • Use the extract command to run the StructureMap against the generated and validated QuestionnaireResponses to get the expected resources
    - If successfully generates resources, use the validateFhir command to validate the output resources. Pass if all generated resources are valid, and fail if any of them are invalid
    - If fails to generate resources, fail. The structureMap is invalid
  • Write tests
  • Update documentation
  • Integrate into the CI workflow

cc @pld @ndegwamartin

@Wambere Wambere linked a pull request Aug 30, 2024 that will close this issue
2 tasks
@Wambere
Copy link
Contributor

Wambere commented Sep 18, 2024

@pld @dubdabasoduba @f-odhiambo @ndegwamartin

We are trying to map the Questionnaires and StructureMaps in the composition file and we're trying to figure out if it's possible for us to all agree on the same format to naming these resources. For example can we enforce that the title should always match? Or the title and the identifier.value should always match (replacing spaces with - or something like that)

For example:

composition_config.json

[
  {
    "title": "Questionnaires",
    "mode": "working",
    "section": [
      {
        "title": "Add Family Member",
        "focus": {
          "reference": "Questionnaire/ccaedb32-0e23-4a29-8df1-bde75bf4a183",
          "identifier": {
            "value": "add-family-member"
          }
        },
        "mode": "working"
      }
    ]
  },
  {
    "title": "StructureMaps",
    "mode": "working",
    "section": [
      {
        "title": "Add Family Member",
        "focus": {
          "reference": "StructureMap/eb7e8cbb-4cef-4d62-9e4d-7d4243b68c80",
          "identifier": {
            "value": "add-family-member"
          }
        },
        "mode": "working"
      }
    ]
  }
]

So far it looks like every project has it's own style

@dubdabasoduba
Copy link
Member

@Wambere @sharon2719 I am okay with the suggested naming approach. Can we add it to the validation? So validation fails if the naming is not adhered to.

@Wambere
Copy link
Contributor

Wambere commented Sep 23, 2024

After a small discussion with @ndegwamartin we found out that this is already happening here for the validate command. This basically checks the structureMap that is referenced inside the questionnaire (so not using the composition)
So @sharon2719 is looking into how we can basically use the same functionality to build the Questionnaire/StructureMap map

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
efsity FCT features Enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants