Add support to generate test/dummy questionnaire responses

[Wambere]

Overview
Some projects have a lot of questionnaires, with this functionality it will be possible to quickly generate questionnaire responses which can be used to test the extraction of resources, validation of app configs etc

Currently this is done manually

We can use tools like java-faker or datafaker to help with the actual dummy data generation

The result needs to account for special cases like skip logic. For example if one question asks for the gender and there is a subsequent question that is only relevant to female responders, that answer should only be answered when expected.

We would also want to extract and validate the data after generation. For valiation we can ideally use the same implementation from validate fhir resources

Implementation spec.
Add a new sub command generateResponses to efcity

sample commands:

fct generateResponses -i /path/to/questionnaire 

input

• The questionnaire resource
• Flag is -i and --input as an alias

output

• A valid questionnaire response resource

Acceptance Criteria

• New sub command generateResponses added, taking in a path to a questionnaire resource
• Documentation for the command added to the README
• Extraction and validation of this newly generated questionnaire response
• Unit tests (Framework and status checks to be set up*)

Resources

• https://github.com/DiUS/java-faker
• https://www.datafaker.net/
• Resource validation: Add support for validation of FHIR resources #13

---

[Wambere]

Leaving this open because I'm still looking into using Questionnaire/$populate as an alternative option

[Wambere]

The $populate is part of the Clinical Reasoning module on the HAPI FHIR server as mentioned here. Basically, the operation "generates a QuestionnaireResponse based on a specific Questionnaire, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire". The operation is also defined on the FHIR website here including a bit more detail such as a list of the required parameters when making the request.

To get more detail of how this actually works, checkout the Form Population page which talks about the 3 distinct operations under the populate umbrella, the population modes, how to design Questionnaires to support the operation etc

[Wambere]

In order to test this out,

• I enabled the CR module in the applications.yaml file (Note that this is on the hapi-fhir-jpaserver-starter master branch, not on tagged release yet). (As mentioned in the comment just above this line) This will include the evaluate measure operations, but not any of the questionnaire ones
• When the above is enabled, from the logs we can see the Measure operation providers loaded like below

2023-11-02 10:30:36.779 [main] INFO  ca.uhn.fhir.cr.config.ProviderLoader [ProviderLoader.java:53] loading provider: class ca.uhn.fhir.cr.r4.measure.MeasureOperationsProvider
2023-11-02 10:30:36.780 [main] INFO  c.uhn.fhir.rest.server.RestfulServer [RestfulServer.java:1776] Added 1 plain provider(s). Total 8
2023-11-02 10:30:36.780 [main] INFO  ca.uhn.fhir.cr.config.ProviderLoader [ProviderLoader.java:53] loading provider: class ca.uhn.fhir.cr.r4.measure.SubmitDataProvider
2023-11-02 10:30:36.780 [main] INFO  c.uhn.fhir.rest.server.RestfulServer [RestfulServer.java:1776] Added 1 plain provider(s). Total 9
2023-11-02 10:30:36.781 [main] INFO  ca.uhn.fhir.cr.config.ProviderLoader [ProviderLoader.java:53] loading provider: class ca.uhn.fhir.cr.r4.measure.CareGapsOperationProvider
2023-11-02 10:30:36.781 [main] INFO  c.uhn.fhir.rest.server.RestfulServer [RestfulServer.java:1776] Added 1 plain provider(s). Total 10

• To add the Questionnaire operations, we need to include and load the necessary provider during start up
• On hapi-fhir-jpaserver-starter ( > v6.4.0) the StarterCrR4Config.java file imports the CrR4Config.java from the hapi-fhir repo. This is where the above loaded providers are defined
• The provider we need for our questionnaire is in the same folder here: PopulateOperationConfig.java
• Caveat, this is only available on the current master branch on the hapi-fhir repo not on any tagged release yet
• However, the latest tag has a different (but related) provider here QuestionnaireOperationsProvider.java
• So I updated my pom.xml file to work with the latest tag version of hapi-fhir (v6.8.5)
• Then I update my StarterJpaConfig.java file to import the provider

import ca.uhn.fhir.cr.r4.questionnaire.QuestionnaireOperationsProvider;

• Passed in the provider QuestionnaireOperationsProvider thequestionnaireOperationsProvider as a parameter to the restfulServer function
• Then registered the provider within the same function

fhirServer.registerProvider(thequestionnaireOperationsProvider);

Blocker
With the above however I get the error

org.springframework.context.ApplicationContextException: Unable to start web server; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'hapiServletRegistration' defined in ca.uhn.fhir.jpa.starter.Application: Unsatisfied dependency expressed through method 'hapiServletRegistration' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'restfulServer' defined in class path resource [ca/uhn/fhir/jpa/starter/common/StarterJpaConfig.class]: Unsatisfied dependency expressed through method 'restfulServer' parameter 10; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'ca.uhn.fhir.cr.r4.questionnaire.QuestionnaireOperationsProvider' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

So it looks like I need to define a Bean somewhere... not sure where

cc @ndegwamartin @dubdabasoduba

[pld]

Do you want to try running from main and see what happens?

[Wambere]

I had tried to build the main branch to deploy locally to test but it's broken, it doesn't even build
I tried a couple other branches and tags but none that included these changes seemed to work
Only available option that I have not yet tried, I think is to actually add needed changes to the latest tag and then deploy a snapshot of that locally

[Wambere]

My guess/assumption though is that it would probably give the same or a related error

[pld]

Yea ok, I think should pause on trying to use $populate then

[pld]

is this complete now?

[Wambere]

@pld not yet, I'll spare some time this week to see if I can close it out

[pld]

No worries, I certainly think this is higher priority, I wasn't sure if this was left open by mistake because I thought I saw documentation that covered this feature when I was using the translation generation in fct