[FHIR] Support implementation guides, custom operations, and extensions

[lmsurpre]

There's multiple different extension points for extending the IBM FHIR Server with custom functionality:

• Interceptors
• IGs
• Operations

Currently, users wishing to extend the server in this way must extend the server image with their own layer that adds the needed jar files to the userlib directory.

Potential ideas for improving on the current story:

• Prepackage EVERYTHING in our base image. Use config to enable/disable the extra functionality.

  • folks bringing their own extensions would still need to fall back to the current story (add a layer to docker image)

• Prepackage just the fhir-smart interceptor (and its dependencies) and enable/disable that via config

  • A. keep it as a generic add-on and introduce some generic config for enabling/disabling interceptors (and maybe controlling order?)
  • B. weave it tighter into the server and enable/disable it right from the fhirServer/security section of the config
  • folks would need to fall back to the current story (add a layer to docker image) for everything else

• Support/document usage of volumes for installing the extensions

  • Can we put the jar files in ConfigMaps and mount those?
    • A. they provide us with a ConfigMap name that follows our documented pattern and we resolve that
    • B. they provide us with some files somewhere and we somehow create a ConfigMap from those?
    • conflicting answers at https://stackoverflow.com/questions/55123261/hosting-jar-files-on-kubernetes-configmap ...seems to be a bit of a stretch--maybe a size limit of 1MB
    • as an example, see https://github.com/Alvearie/health-patterns/blob/main/helm-charts/fhir/chart/templates/configmap.yaml#L13-L17 which then gets mounted from the deployment

• Some kind of feature manager that would install the extensions during startup

  • Can we piggyback on the Liberty feature manager?
    • would probably require us to package the extensions as "liberty features".
    • would still need a way for users to pass server.xml / configDropins (see [FHIR] Support configDropins #35)
    • assumption: we could host the features somewhere (maven central?) and then liberty would be able to download and install them

[chgl]

Similar to point 3 and the one stackoverflow comment: the airflow Helm Chart allows loading custom plugins and workflow definitions (dags) from git repositories by syncing them to local files via a sidecar container: https://github.com/bitnami/charts/tree/master/bitnami/airflow#loading-plugins

In case of binary jars, an s3/cos endpoint that is polled/watched may be more appropriate though.