This issue is about providing the possibility to trigger validation of FHIR resources and use other FHIR-related utilities from GITB TDL test cases.
Effective FHIR validation means starting and pre-populating a FHIR validator which can be time-consuming. As having this overhead per test session is impractical, a better approach is to do this once and reuse the same instance across all tests. As such, rather than use a built-in FHIR validator component the best approach is to have this set up as a separate service that is accessible via the standard GITB validation (for the validator) and processing (for utilities) APIs. The service would likely be deployed alongside the ITB core components (e.g. in the same Dockerised service or Kubernetes cluster), but this could also be full remote.
Note that currently the extension services are managed via SOAP service APIs and XML messages. To simplify implementation in the FHIR validator, a prerequisite for this will be to provide an official REST/HTTP/JSON equivalent.
Once the APIs are supported in the validator, the official TDL documentation will also be extended to define precisely what is supported, and how to use the validator in test cases.
This issue is about providing the possibility to trigger validation of FHIR resources and use other FHIR-related utilities from GITB TDL test cases.
Effective FHIR validation means starting and pre-populating a FHIR validator which can be time-consuming. As having this overhead per test session is impractical, a better approach is to do this once and reuse the same instance across all tests. As such, rather than use a built-in FHIR validator component the best approach is to have this set up as a separate service that is accessible via the standard GITB validation (for the validator) and processing (for utilities) APIs. The service would likely be deployed alongside the ITB core components (e.g. in the same Dockerised service or Kubernetes cluster), but this could also be full remote.
Note that currently the extension services are managed via SOAP service APIs and XML messages. To simplify implementation in the FHIR validator, a prerequisite for this will be to provide an official REST/HTTP/JSON equivalent.
Once the APIs are supported in the validator, the official TDL documentation will also be extended to define precisely what is supported, and how to use the validator in test cases.