DICOM Capacitor

DICOM Capacitor is a store and forward DICOM gateway with queued-send and recover capability.

When PACS isn’t listening

There are a number of common contexts within which a storage to PACS is less than reliable. These include:

  • Mobile units, where connectivity to your institutional network is established only periodically, or at the end of the day.
  • Remote sites, where available bandwidth is inadequate and large transfers must be scheduled.
  • Unreliable networks, where frequent network drops can result in an ever growing list of aborted transmissions.
  • Poor vendor implementations. Sometimes hung transfers cause hung applications, and that can have a big impact on your schedule.

These situations call for a local store and forward gateway; a DICOM application that can silently forward things to PACS without placing constraints on technologist time.

Capacitor can help

Merely point your device to it, point it to your PACS, and let the Capacitor handle the rest.

We’ve been in the DICOM field since 2004, and are known the world over for our dedication to low-maintenance and high performance tools.

Capacitor has been written using our own DICOM Multi-tool engine, which powers a host of applications including Capacitor, Shrinkinator, and as well as all our other integration gateways. The same engine provides core DICOM functionality for several diagnostic instruments.

How does it work?

Capacitor sits between your device and the PACS, this can be either on the same machine, or a locally-placed server.

  • Your instrument is configured to point to the Capacitor instead of the PACS
  • Capacitor queues the studies it receives and attempts storage either when the PACS is available, or during a pre-scheduled block of time.
  • Once studies are stored to PACS, Capacitor will either delete its own copy right away, or after a set time interval, where additional safety is required.

From the perspective of your device, storage to Capacitor is analogous to storage to PACS, creating an uninterrupted workflow.

What is the impact on staff?

Rather widespread:

  • Storage is fast, freeing up the device workstation, and the technologist, to complete her work.
  • Technologists only have to initiate storage once. Capacitor will automatically re-attempt until everything has been delivered to PACS.
  • Mobile units get to operate without any consideration of the availability of networks and PACS.
  • Throttling and scheduling mean that both reading and general office work are no longer negatively impacted by large transfers.
  • Redundancy is created automatically. Since a copy of each study resides in the Capacitor queue, then data loss is exponentially less likely to result in permanent loss.

Typical applications include:

  • Storage from remote, poorly-connected, sites
  • Re-transmission of studies from mobile units upon returning to institutional LAN
  • Creating redundancy within organizations
  • Dealing with poor vendor DICOM implementations

Legendary performance

Capacitor has been written using our own high-performance C++/Qt DICOM framework.

  • Memory use is low, and can be strictly limited.
  • Capacitor will automatically throttle connections to stay within operating norms.
  • Capacitor optimizes its operation to release the modality within the shortest possible time.
  • Zero-configuration updates; most can be performed within a matter of minutes using a single installer. You should never putt off upgrades out of fear of their impact.

Automated cache management

Capacitor is imbued with several features to help it safely manage storage:

  • Memory is used by default, and storage to disk is only performed if data cannot immediately be passed along to PACS.
  • Disk storage is kept within limits by first reducing the rate at which studies are accepted, and then rejecting them completely. In no case will – Capacitor ever drop studies it has accepted.
  • If Capacitor does run out of space, it can be configured to notify users using network-based pop-up messages.

How to get in touch

Please contact us for a demonstration copy at [email protected].

Supported Modalities

  • Any modality that outputs DICOM

Supported PACS Systems

  • All of them

Network Services

  • US, CT, DR, MR, SC, RAW Storage SCU/SCP
  • SR Storage SCU/SCP
  • Verification SCU/SCP

Basic Specifications

  • Windows executable, runs as a system service
  • Receives instances as a Store SCP
  • Transmits to PACS when scheduled or possible

System Requirements

  • x86 or x64 CPU at 2 GHz minimum
  • 2 GB memory for 32-bit and 4 GB for 64-bit operation
  • Windows XP SP3, Vista, 7, 8, 2003 Server, or 2008 Server
  • 500 GB of storage, for log files and a sizeable cache
  • TCP access to both modality and destination PACS system