RTFM · Medical healthchecks

lb.saphira.fhir: is the record server serving its own manual? (FHIR)

Every healthy FHIR server can answer one question about itself: what can you do? The check requests the CapabilityStatement, the server's self-description, and demands it as FHIR JSON. The polite, safe, always-correct way to health-check a records API.

What it proves

The FHIR endpoint answers its /metadata path with HTTP 200 and content type application/fhir+json. The CapabilityStatement is static-but-mandatory: every conformant FHIR server must serve it, so a pass means the FHIR stack is alive, and a fail means the stack behind the port is broken even when plain HTTP checks pass. Continuous-safe.

How it works

curl issues a GET with Accept: application/fhir+json to <base>/metadata (trailing slash on the base URL is stripped for you). Both the status and the Content-Type header are verified; the content-type assertion is what distinguishes "FHIR answered" from "a web server answered".

Configuration

Knobs
Variable / positional	Default	Meaning
$6 or LB_SAPHIRA_FHIR_URL	(required)	FHIR base URL, e.g. https://host:port/fhir
LB_SAPHIRA_FHIR_TLS_VERIFY	0	1 = enforce certificate verification
LB_SAPHIRA_TIMEOUT	3	Transaction deadline

Wiring it up

ldirectord

# ldirectord.cf - FHIR gateway pool
virtual = 203.0.113.10:8443
    protocol = tcp
    scheduler = wlc
    real = 192.168.20.35:8443 gate 1
    checktype = external
    checkcommand = "/var/lib/lb/saphira/lb.saphira.fhir"

Per-service base URL

# /etc/saphira/lb-healthchecks.d/fhir/records.conf
LB_SAPHIRA_FHIR_URL=https://records.internal:8443/fhir
LB_SAPHIRA_FHIR_TLS_VERIFY=1

Run it by hand

Manual run

LB_SAPHIRA_FHIR_URL='https://records.internal:8443/fhir' \
  /var/lib/lb/saphira/lb.saphira.fhir records 8443 192.168.20.35 8443
echo $?
# 0 = CapabilityStatement served as FHIR JSON
# 1 = non-200, wrong content type, or connection failure
# 2 = no base URL configured

Failure modes

200 with application/json (not fhir+json); something in front is answering; the FHIR app is not
Timeout on /metadata while TCP passes; the app server's worker pool is exhausted

Did we miss something?

If this page left something unanswered, found an error, or there is another subject you would like documented, tell us. Saphira’s documentation grows from real problems people need to solve.

Send feedback or request a new section →

Prefer not to do it yourself?

Everything needed to do the work yourself is documented here and remains free; we charge for human time, not for withholding knowledge. Sometimes the missing resource is simply time. The same people who build Saphira can provide paid professional help with implementation, migration, troubleshooting and administration.

Ask about professional support →