Technical Bulletin: Flux Box for Mobile Imaging Fleets

Abstract

Mobile imaging programs usually have three competing requirements: the acquisition device must stay simple, every visited facility needs its own PACS and worklist behavior, and studies must not cross institutional boundaries when the unit moves. Flux Box addresses that by making the modality talk to one local DICOM endpoint while Capacitor activates the correct downstream profile for the current site.

Design Pressure in Mobile Fleets

Reference Architecture

Flux Box can sit beside the existing coach router instead of replacing every network function. In that model, the router continues to provide facility connectivity or remote-support paths, while Flux Box owns the DICOM workflow boundary between the modality and facility systems.

The edge can also span two nodes when a program wants delivery to continue after the coach leaves: a workstation on the vehicle captures and caches studies at LAN speed, paired with an in-building gateway that owns facility-side delivery while the unit is on site (modality → on-coach Flux Box → gateway → PACS). Single-node and paired-gateway deployments use the same profile and safety model.

Site Profiles

A site profile is the complete operating definition for one facility or program location. It can include:

• Facility identity, expected network evidence, and activation policy
• PACS, VNA, AI, CAD, viewer, archive, and secondary destinations
• Modality Worklist source and query behavior
• DICOM AE titles, IPs, ports, and destination aliases
• Routing rules by modality, SOP Class, body part, procedure, series, institution, or downstream requirement
• Tag normalization, institution-name mapping, station-name changes, accession handling, and vendor compatibility rules
• Compression, conversion, batch size, retry, bandwidth, and delivery schedule
• Release-review policy for patients missing from the active worklist
• Cache retention, encryption, isolation, and replay policy
• Monitoring, audit, support, and rollback metadata

Profile Lifecycle

1. Prepare - Build or update the facility profile in Configatorium or Flux engineering tooling.
2. Validate - Confirm DICOM endpoints, worklist behavior, routing rules, and downstream acceptance with test studies.
3. Package - Create a deployable profile package for the unit.
4. Deploy - Push remotely when connectivity exists, or stage offline for locked-down environments.
5. Detect - Use geofence, network, service, schedule, or operator evidence to select the expected profile.
6. Preflight - Optionally run a location-change safety check before storage opens.
7. Activate - Bring the profile online and expose the correct local DICOM behavior.
8. Seal - Stop the profile and keep its cache isolated when the unit leaves.

Site Detection and Activation

Detection is endpoint-agnostic — the modality is never reconfigured between sites. When the facility-side link comes up, Flux Box confirms which site it is on by probing the endpoints that profile expects; a DICOM C-ECHO to a known node is treated as positive confirmation, which holds even where hospital networks block ICMP. Coarse geolocation can act as an optional pre-filter, and an unrecognized network fails closed: no profile is activated and no storage port is opened.

Scanner Configuration Model

The scanner should not need a new PACS node for every stop. In a Flux Box deployment, the modality can be configured with stable local targets:

This is especially useful for coaches that rotate across many sites. A technologist can send to the same local destination everywhere, while the profile translates that action into the correct facility routing.

DICOM Dataflow

Acquisition and Local Ingest

The modality sends studies to Flux Box using standard DICOM C-STORE. Because the first hop is local, acquisition can finish at LAN speed even if the upstream facility link is slow, offline, or scheduled for later delivery. Capacitor accepts and writes acknowledged DICOM objects locally, tracks SOP Instance identity for delivery, and places the study into a persistent queue.

Worklist Proxy and Cache

The modality can query Flux Box as its local Modality Worklist endpoint. Capacitor can serve the last known good worklist, refresh against the active facility when connectivity allows, and apply profile-specific cleanup for downstream compatibility. This keeps the modality workflow usable even when a mobile link is unavailable during patient intake.

Store-Forward Delivery

Capacitor delivers queued studies asynchronously according to profile policy:

• Immediate delivery when wireless or wired connectivity is sufficient
• Scheduled delivery after patient hours or during a known docked window
• Manual release from a portal when an operator wants a deliberate send step
• Scripted triggers, including power state, site network evidence, or fleet policy
• Retry and resume behavior based on acknowledged DICOM instances

A study should remain queued until the intended destination acknowledges the required SOP Instances. If an association drops, Capacitor can use destination acknowledgements and SOP Instance tracking to resume with undelivered objects instead of forcing the technologist to resend the exam from the scanner.

Routing, Transformation, and Compression

Mobile fleet profiles often need more than one destination. A single exam may need PACS storage, AI processing, viewer-specific header compatibility, archive delivery, and selective exclusion of dose reports, raw projections, or unsupported SOP Classes. Capacitor can apply those rules at the edge:

• Fan-out to multiple destinations
• SOP Class and series filtering
• Institution, station, procedure, and description normalization
• Viewer-specific compatibility rules
• JPEG 2000 or other transfer-syntax policies where supported
• Large-study compression for DBT, CT, MR, and similar workflows

Safety Controls

Per-Site Cache Isolation

Each site profile can keep its own cache, queue, and routing state. When a unit leaves Facility A and activates Facility B, Facility A data should not remain visible to the active Facility B workflow. This model supports encrypted local storage, inactive-profile shutdown, and profile-scoped replay.

Release Review for Unmatched Patients

Mobile programs need a safe path for walk-ins, add-ons, and event-day patients who are not present on the active worklist. Flux Box can hold those studies for review instead of releasing them automatically. The review workflow is scoped to the active profile, so an add-on patient at one facility is not silently routed under another facility profile after a move.

Optional Location-Change Gate

The highest-risk transition is a facility change. Flux Box can be configured to run a DICOM C-FIND preflight against the local acquisition system before Capacitor opens the storage port for the new site.

1. A site change is detected.
2. The expected profile is selected but not fully opened.
3. Flux Box queries the local acquisition system.
4. If prior patients remain, storage for the new profile stays closed.
5. The operator clears the acquisition system.
6. Capacitor opens storage under the new profile after a clear result.

This control does not clean the scanner database itself. It prevents new-site storage until the local patient list is clear enough for the configured safety policy.

Manual Sends Without Manual Site Logic

Manual transmission still matters for radiologist-requested resends or exception handling. The safer pattern is to keep manual targets generic on the modality and map those targets through the active profile. That preserves ad-hoc flexibility without asking technologists to remember site-specific DICOM nodes.

Network and Security Posture

Fleet Operations Model

Flux Box is not only a DICOM router on a truck. In a fleet deployment, it becomes an operations surface for profile control.

Configatorium is the Flux profile-management portal for this model. It is where operators can create and maintain profiles, review the profile-management workflow, and prepare updates for the fleet. The public page can be paired with a customer-specific Configatorium walkthrough during implementation.

Deployment Patterns

Facility Overflow and Renovation Coverage

A coach parked outside a hospital can behave like an extension of that facility while local construction, equipment replacement, backlog relief, or event coverage is underway. The modality still sends locally; the active profile makes the unit match the facility.

Multi-Site Rotation

A shared trailer can rotate across facilities with different PACS, worklists, institution names, and downstream routing requirements. Flux Box keeps those differences out of scanner setup.

Screening Events and Walk-Ins

Release review is useful when patients may arrive outside the scheduled worklist. The box can hold the study, show the review state, and require deliberate release.

Standby and Spare Trailers

Standby units can carry the same profile model as production units. When a spare replaces a failed coach, the fleet team activates the correct site profile instead of rebuilding scanner configuration.

Multi-Vendor Downstream Workflows

Mobile programs often feed PACS, AI, CAD, viewer, archive, and router systems at the same time. Capacitor can apply profile-specific fan-out, SOP filtering, compression, and header rules so each destination receives the format it expects.

Non-Mammography Mobile Imaging

The architecture is modality-agnostic. It can support mammography, MR, CT, ultrasound, radiography, ophthalmology imaging, and other DICOM-producing devices when the workflow benefits from local DICOM services, site-aware routing, and controlled delivery.

Implementation Checklist

1. Site and Fleet Intake

• List every facility, trailer, scanner, router, PACS, worklist source, and downstream destination.
• Decide which destinations are default, secondary, ad-hoc, AI, archive, or viewer-specific.
• Capture AE titles, IPs, ports, transfer syntax support, SOP Class requirements, and firewall constraints.
• Define site detection evidence and the fallback manual selection process.
• Define retention, encryption, remote-support, and audit requirements.

2. Profile Build

• Create one profile per facility or operating mode.
• Configure routing, tag normalization, worklist behavior, compression, and delivery policy.
• Configure hold/release behavior for patients missing from worklist.
• Configure optional location-change gate if scanner database clearance is part of the safety model.
• Package the profile for remote or offline deployment.

3. Lab Validation

• Send test studies through every profile.
• Verify worklist query behavior.
• Verify downstream acceptance for PACS, viewer, AI, archive, and router destinations.
• Test link loss, retry, resume, duplicate handling, and scheduled delivery.
• Test profile stop/start and cache isolation between sites.

4. Field Pilot

• Install the box with stable scanner-side addressing.
• Confirm the modality sends to the same local endpoint at every stop.
• Validate one low-risk site move under supervision.
• Confirm operator response to holds, unmatched patients, and location-gate stops.
• Record the rollback path.

5. Fleet Rollout

• Publish the approved profile set.
• Train operators on profile state, release review, and support escalation.
• Monitor queues, failed associations, held studies, and worklist sync health.
• Add new facilities through the same profile lifecycle rather than scanner-side changes.

Boundary Conditions

Flux Box is intentionally narrow about ownership:

• It is not the legal patient identity authority; RIS, EHR, and facility worklist systems remain authoritative.
• It does not silently clear the acquisition system; a location gate can block storage until clearance happens.
• It does not remove the need for facility firewall, VPN, or network approval.
• It does not make every downstream system accept every transfer syntax or SOP Class; profiles encode those compatibility rules.
• It should not be used to hide unresolved workflow ambiguity. If patient or facility context is uncertain, the safer behavior is to hold.

Why This Matters

Mobile imaging fleets fail operationally when site-specific logic leaks into the scanner, technologist memory, or one-off router scripts. Flux Box moves that logic into versioned profiles, keeps the modality endpoint stable, and adds safety controls around the moments that matter: patient release, site changes, cache boundaries, and delivery over unreliable networks.