Open ndegwamartin opened 2 weeks ago
One more thing, for the QuestionnaireResponse to be generated as expected we need to have cr enabled set to true
is the other option to spin up a HAPI server in the CI flow, run tests against that, then spin it down, but problem w/this is that it'd be too slow?
is the other option to spin up a HAPI server in the CI flow, run tests against that, then spin it down, but problem w/this is that it'd be too slow?
Should be feasible to implement but will be a higher LOE and C.I. will probably be slower when running the validation
Here are the final steps based on the stated factors:
We can investigate whether it is feasible to whitelist requests from Github(C.I.) and then use that as the auth mechanism in which case we will not need the Keycloak and Gateway setups (thanks for this @pld )
cc @bennsimon @dubdabasoduba
@ndegwamartin what are these used for? If they are used somehow for validation do we need the server? I haven't checked so I might be sending you on a wild goose chase.
@ndegwamartin what are these used for? If they are used somehow for validation do we need the server? I haven't checked so I might be sending you on a wild goose chase.
That is a config on the server side, i.e HAPI itself . The above configures the url as logical identifiers - https://hapifhir.io/hapi-fhir/docs/server_jpa/configuration.html#logical-references
Note, our validation approach requires the server with or without that enabled since we use $populate operations for the QR generation cc @Wambere
We need to have a running HAPI FHIR server in order to support validation. Our implementation requires a live server to be running - see https://github.com/onaio/fhir-tooling/issues/305
We could have the server deployed for the validation and maybe use the same server for terminologies as per the FHIR spec (Documentation on when to use a Terminology Service in FHIR)
Factors to consider: