Analyzer Bridge -> OpenELIS FHIR forwarding: HAPI-0287 on webapp /fhir, mTLS required on external-fhir-api - which is the intended path?

Community Ask OpenELIS
1

Hi all,

I’m integrating two veterinary lab analyzers (via ASTM) through the
openelis-analyzer-bridge (legacy image: itechuw/astm-http-bridge:3.0.4)
into a self-hosted OpenELIS Global 2 instance deployed via the official
openelis-docker Compose setup (image tag 3.2.1.11). I’ve got the
following working already:

  • Bridge successfully authenticates to the webapp’s REST API
    (https://oe.openelis.org:8443/OpenELIS-Global/rest/analyzer/analyzers)
    and pulls the analyzer registry correctly (confirmed via bridge logs:
    “Bootstrap complete: pulled 2 analyzers from OE”).
  • A simulated ASTM message (ENQ/ACK handshake, framed STX/ETX records)
    sent to the bridge’s ASTM listener is correctly received, parsed, and
    converted into a FHIR Bundle by the bridge.

Where I’m stuck is the actual result forwarding step. The bridge takes
that Bundle and POSTs it to:

https://oe.openelis.org:8443/OpenELIS-Global/fhir

(i.e. the main webapp container’s own /fhir path, derived automatically
by the bridge from the same base URI used for the REST registry pull).

This returns HTTP 400 with:

{"resourceType":"OperationOutcome","issue":[{"severity":"error",
"code":"processing","diagnostics":"HAPI-0287: This is the base URL
of FHIR server. Unable to handle this request, as it does not
contain a resource type or operation name."}]}

I noticed the deployment also runs a separate, dedicated FHIR container
(external-fhir-api / itechuw/openelis-global-2-fhir), so I tried POSTing
the same Bundle directly to that instead:

https://fhir.openelis.org:8443/fhir

But this container appears to require mutual TLS - the TLS handshake
includes a “Request CERT” step, and since curl didn’t present a client
certificate, the server responded with a “bad certificate” TLS alert.

My questions:

  1. For analyzer-bridge result forwarding, is the intended target the
    main webapp’s own /fhir path, or the standalone external-fhir-api
    container?

  2. If it’s the webapp’s own /fhir path - is HAPI-0287 here a sign that
    the transaction Bundle provider isn’t registered/enabled by default
    in this deployment, and if so, what’s the config to enable it?

  3. If it’s meant to be the standalone external-fhir-api container - how
    are client certificates for internal/mTLS calls normally provisioned
    in this stack? Is there a documented CA or cert-generation step for
    internal service-to-service calls (I see a “certgen” container in
    the Compose file - is that related)?

Happy to share full bridge/webapp logs, my configuration.yml, and
docker-compose.yml if useful. Thanks in advance for any pointers!