RTFM · Medical healthchecks
lb.saphira.dicom.move: the full retrieve pipeline (C-MOVE, opt-in)
The deep check: ask the archive to actually send images somewhere, and prove they go. Guard-gated and only meaningful with a dedicated receiving SCP; movescu alone proves nothing, and this check refuses to pretend otherwise.
What it proves
The C-MOVE retrieve pipeline end to end: the archive accepts the move request, contacts the configured move destination, and pushes the retrieve through it. This is the only check in the family that exercises the transfer direction patients ultimately depend on; images arriving where they are needed.
Safety class: DEEP / opt-in. The check hard-refuses (exit 2) unless BOTH LB_SAPHIRA_STATE_CHANGING=1 AND a dedicated move destination are configured. It is never a high-frequency default: run it on demand before go-live, after maintenance, or on a long interval against a dedicated health-check SCP.
The C-MOVE rule
A C-MOVE has two halves: the instruction ("send me that patient's studies") and the delivery (the archive connecting OUT to the move destination and streaming). Running movescu alone validates only the first half. The check therefore requires a dedicated receiving SCP, for example a health-check storescp instance, configured via LB_SAPHIRA_DICOM_MOVE_DEST (or the $6 positional), and fails closed without one.
Configuration
| Variable / positional | Default | Meaning |
|---|---|---|
| LB_SAPHIRA_STATE_CHANGING | 0 | Must be 1: the guard gate |
| $6 or LB_SAPHIRA_DICOM_MOVE_DEST | (required) | AE title of the dedicated receiving SCP |
| LB_SAPHIRA_DICOM_AET / AEC | SAPHIRA-HC / ANY-SCP | Association identities |
| LB_SAPHIRA_DICOM_PATIENT_ID | synthetic | The synthetic query key |
Wiring it up
# ldirectord.cf - opt-in, long interval
virtual = 21
protocol = fwm
scheduler = rr
real = 192.168.20.21:104 gate 1
checktype = external
checkcommand = "/var/lib/lb/saphira/lb.saphira.dicom.move"
checkinterval = 300# /etc/saphira/lb-healthchecks.d/dicom.move.conf
LB_SAPHIRA_STATE_CHANGING=1
LB_SAPHIRA_DICOM_MOVE_DEST=SAPHIRA-HC-SCPRun it by hand
LB_SAPHIRA_STATE_CHANGING=1 LB_SAPHIRA_DICOM_MOVE_DEST=SAPHIRA-HC-SCP \
/var/lib/lb/saphira/lb.saphira.dicom.move ct-pool 104 192.168.20.21 104
echo $?
# 0 = retrieve pipeline executed against the receiving SCP
# 1 = the move pipeline failed
# 2 = guard not set or no destination configured - the check refuses to runFailure modes
- Move instruction accepted, delivery stalls; the archive cannot reach the destination: network policy, wrong AE map, exactly the class of failure the instruction-only tests miss
- exit 2: unconfigured: the guard is doing its job
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.