RTFM · Medical healthchecks
lb.saphira.dicom.stow: store over HTTP (STOW-RS, opt-in)
The DICOMweb write verb, tested with a synthetic image generated at check time. Guard-gated like its classic C-STORE sibling: nothing is written anywhere unless a human turned the key.
What it proves
The STOW-RS store path: a multipart/related POST of a real (if tiny) DICOM object returns one of the accepted store statuses: 200, 201 or 202. Combined with the synth generator this certifies the archive's HTTP intake pipeline end to end.
Safety class: DEEP / opt-in. Hard-refuses (exit 2) unless LB_SAPHIRA_STATE_CHANGING=1 AND the STOW URL is configured. Never a high-frequency default.
How it works
The synth generator produces the synthetic Secondary Capture object (no upstream sample files exist); curl posts it as multipart/related with type="application/dicom", the exact media type a real client sends, and the status is matched against 200/201/202.
Configuration
| Variable / positional | Default | Meaning |
|---|---|---|
| LB_SAPHIRA_STATE_CHANGING | 0 | Must be 1: the guard gate |
| $6 or LB_SAPHIRA_DICOM_STOW_URL | (required) | Full studies URL for the POST |
| LB_SAPHIRA_DICOMWEB_TLS_VERIFY | 0 | 1 = enforce certificate verification |
| LB_SAPHIRA_TIMEOUT | 3 | Transaction deadline |
Wiring it up
# /etc/saphira/lb-healthchecks.d/dicom.stow.conf
LB_SAPHIRA_STATE_CHANGING=1
LB_SAPHIRA_DICOM_STOW_URL=https://pacs.internal/dicomweb/aets/ACPACS/studiesRun it by hand
LB_SAPHIRA_STATE_CHANGING=1 LB_SAPHIRA_DICOM_STOW_URL='https://pacs/dicomweb/aets/ACPACS/studies' \
/var/lib/lb/saphira/lb.saphira.dicom.stow pacs 8081 192.168.20.23 8081
echo $?
# 0 = store accepted (200/201/202)
# 1 = store refused or transport failed
# 2 = guard or URL missingFailure modes
- 4xx on a previously-passing check; the intake endpoint's auth or AE policy changed
- 2xx but from a gateway: check the response provenance in the archive's own logs; the balancer verdict is about the HTTP contract
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.