# @radicalimaging/static-wado-plugins

> Plugins to support the static-wado project

Latest version **1.7.10** (published 2026-10-14) · ISC license · 0 weekly downloads

## Install

```sh
npm install @radicalimaging/static-wado-plugins
pnpm add @radicalimaging/static-wado-plugins
yarn add @radicalimaging/static-wado-plugins
bun add @radicalimaging/static-wado-plugins
```

## Health

**Score 65/100 (B)** — status: active.

Positive: esm support; no vulnerabilities; has provenance; recently updated; high maintenance score.

Warnings: low downloads; no types.

## Facts

| | |
|---|---|
| Version | 1.7.10 |
| Published | 2026-10-14 |
| First published | 2022-09-20 |
| Weekly downloads | 0 |
| License | ISC |
| TypeScript types | none |
| Module format | ESM + CommonJS |
| Node | >=14.18.1 |
| Dependencies | 4 |
| Unpacked size | 15.1 KB |
| Known vulnerabilities | 0 (+1 in 1 direct dependencies) |
| Install scripts | no |
| Provenance | attested (GitHub Actions) |
| GitHub stars | 66 |
| Maintainers | wayfarer3130, sedghi, pedrokohler-radical |
| Keywords | StaticWado, DICOM, DICOMweb |

## Links

- npm: https://www.npmjs.com/package/@radicalimaging/static-wado-plugins
- Repository: https://github.com/RadicalImaging/Static-DICOMWeb
- Homepage: https://github.com/radicalimaging/static-dicomweb#readme
- Issues: https://github.com/radicalimaging/static-dicomweb/issues
- npm.io page: https://npm.io/package/@radicalimaging/static-wado-plugins

## Dependencies (4)

- [dcmjs-dimse](https://npm.io/package/dcmjs-dimse.md) 0.1.31
- [config-point](https://npm.io/package/config-point.md) 0.8.0
- [http-proxy-middleware](https://npm.io/package/http-proxy-middleware.md) 2.0.9
- [@radicalimaging/static-wado-util](https://npm.io/package/@radicalimaging/static-wado-util.md) >=1.7.10

## Recent versions

- 1.7.10 (latest) — 2026-10-14
- 1.7.9 — 2026-10-13
- 1.7.8 — 2026-10-13
- 1.7.7 — 2026-10-08
- 1.7.6 — 2026-04-28
- 1.7.4 — 2026-04-21
- 1.7.3 — 2026-03-03
- 1.7.2 — 2026-02-19
- 1.7.0 — 2026-01-27
- 1.6.12 — 2026-01-08
- 1.6.11 — 2025-12-23
- 1.6.10 — 2025-11-04
- 1.6.9 — 2025-10-27
- 1.6.8 — 2025-06-20
- 1.6.7 — 2025-05-12
- … 11 more at https://npm.io/package/@radicalimaging/static-wado-plugins/versions

## README

# Static DICOMweb aka `static-wado`

The Static DICOMweb project is a project to create a web-centric PACS system optimized for DICOMweb.  
The project was started out of some scripts that converted binary DICOM files into static wado (DICOMweb) files, but has been extended to cover additinal areas.

The goals of the project are to:

1. Optimize serving of DICOMweb files needed for OHIF viewing
   - Serve required DICOMweb files straight from disk
   - Compress data files on disk to minimize storage
2. Support fully distributed, eventually consistent data model
   - Incoming data can be distributed amongst any number of nodes
   - Serving of data can be done by distributing the storage of data, with or without replication
   - Network fault tolerance is supported by updating study data once network recovers
3. Deploy to a variety of cloud providers
   - AWS is currently the only one supported
   - Local current-machine provider is also done
4. Demonstrate enhanced metadata structures
   - Easier to parse/understand than DICOMweb metadata
   - Smaller than DICOMweb metadata, sometimes as small as 1/100th of the size
   - Faster to parse/display first image

See [Design](./packages/static-wado-creator/docs/design.md) for more details on the general design of Static DICOMweb.

See [File Structure](./file-structure.md) for more details on the file structure used for static-dicomweb.

# General Installation

There are two ways to install Static DICOMweb. First, the command line tools are available published in npm. This is easiest if you are just running locally. The second option is to install from source code, locally.
A third option is to run the tools and deployment in a docker container.

## Prerequisite
The command line tools run on [bun](https://www.npmjs.com/package/bun), so install it for either the pre-built version or a source build:
```bash
npm install -g bun
```

A source build also needs Node.js 22.13 or later and [pnpm](https://pnpm.io) 12, which manages the workspace:
```bash
npm install -g pnpm@12
```

## NPM Install

To install the command line tools, you need to have a current version of node and npm installed, then run:

```bash
npm install -g @radicalimaging/static-wado-creator
npm install -g @radicalimaging/static-wado-webserver
npm install -g @radicalimaging/static-wado-scp
```

## Source Install

You can install locally using git, pnpm and bun:

```bash
git clone https://github.com/RadicalImaging/Static-DICOMWeb.git static-wado
cd static-wado
pnpm install
pnpm run build
pnpm run link:exec
```

The build runs packages one at a time (`--workspace-concurrency=1`). For a faster build, use `pnpm run build:parallel`.

## Docker Usage

Released images are on Docker Hub as `braveheartsoftware/static-dicomweb`, with an `X.Y.Z` tag and `latest`.
From 1.7.7, the images are multi-arch (linux/amd64 and linux/arm64); earlier images are linux/amd64 only.
Releases after 1.7.7 are also on GHCR as `ghcr.io/radicalimaging/static-dicomweb`.

An npm release does not publish an image. A maintainer publishes the image of a release tag with the `Publish Docker images` workflow (Actions > Run workflow).
A reviewer of the `docker-hub` environment must approve each push to Docker Hub; the reviewer can be the maintainer who started the run. GHCR has no such approval: any workflow of this repository with `packages: write` can write to the GHCR image.

A local build gets the tag `static-dicomweb:dev` (`static-dicomweb:dev-arm64` for arm64), never the Docker Hub name, so that a local build cannot replace a release by accident.
`pnpm run docker:build:arm` builds a linux/arm64 image. On an amd64 host, that build needs QEMU emulation, which Docker Desktop includes, and it is slow.

There are scripts in the root package to create a new docker deployment and to run it, with port 25080 linked to the DICOMweb endpoint. The image has no DIMSE SCP (`dicomwebscp`). To create/start this, run:

```bash
pnpm run docker:build
pnpm run docker:run
```

This will drop you into a bash shell and you can run mkdicomweb create or other
commands such as dicomwebserver to convert dicom data.  The /dicom directory
will have been mounted from `/a/dicom` as an available mount point.

You can then run the dicom websererver using:

```bash
pnpm run docker:dicomwebserver
```

Another option is to use the [dcm4che](https://sourceforge.net/projects/dcm4che/files/dcm4che3/5.33.1/) stowrs command, like this:

```bash
stowrs --url http://localhost:25080/dicomweb/studies DICM_FILES
curl http://localhost:25080/dicomweb/studies
```

You can also run a docker build directly for various purpose. There are some general options that you might
want to know first:

### Persistent Data Sharing

There are a number of shared directories and files used to configure various settings, added as bind mounts.

```

// Bind mount for DICOMweb directory
--mount type=bind,source=/dicomweb,target=/dicomweb

// Bind mount for DICOM input files
--mount type=bind,source=/dicom,target=/dicom

// Bind mount for AWS credentials
--mount type=bind,source=/users/userName/.aws,target=/root/.aws,readonly

// Bind mount for persistent storage of AWS configuration
--mount type=bind,source=/dicomweb,target=/dicomweb

```

```bash
// Deploy the default build image
docker run  --mount type=bind,source=/dicomweb,target=/dicomweb -p 25080:5000 -d braveheartsoftware/static-dicomweb:latest
```

That will result in an instance running on port 25080 for dicomweb.

## Deployment to AWS

There are deployment scripts in src/s3-deploy which will create an S3 bucket for DICOMweb and optionally for OHIF as well.

# Using Static DICOMweb

- [Convert DICOM Part 10 to/from DICOMweb](./packages/static-wado-creator/README.md)
- [Deploy Static DICOMweb to AWS](./packages/s3-deploy/README.md)
- [Deploy OHIF Viewer Accessible Static DICOMweb](./packages/s3-deploy/README.md#deploy-ohif)
- [Storing Files to/from Cloud Server](./packages/static-wado-deploy/README.md)
- [Run local DICOMweb webserver](./packages/static-wado-webserver/README.md)
- [Run local SCP Server](./packages/static-wado-scp/README.md)
- [Serve off Nginx HTTP Server](./docs/nginx.md)
- ~~[Proxy DICOMweb to DICOM DIMSE](./packages/static-wado-webserver/dimse-proxy.md)~~
- ~~[Proxy Static DICOMweb to DICOMweb](./packages/static-wado-webserver/dicomweb-proxy.md)~~

# Configuration System for Static DICOMweb

The configuration system is based on a combination of [config-point](http://github.com/OHIF/config-point) and commander for the command line settings. The config-point definitions allow mixing default configuration values, with custom settings files, and then over-riding values with command line settings. There is a custom command line setting to load a specific additional configuration file, which is the `-c` setting, applied like this:

```
mkdicomweb -c tests/static-wado-remote.json5 create ...
```

Configuration files are JSON5 files, which allows for additional flexibility by adding comments and using more relaxed syntax.
The default configuration file is the first one found of `./static-wado.json5` and `~/static-wado.json5`
The configuration files are loaded before the remainder of the command options are generated or parsed, so that the defaults come form the configuration file.

The config-point design allows for inheritance in the configuration. There are these basic configuration settings:

- staticWadoConfig containing the default overall configuration settings
- mkdicomwebConfig containing the mkdicomweb specific configuration
- aeConfig containing AE definitions
- dicomWebServerConfig containing the configuration for the web service, inheritting from staticWadoConfig
- dicomWebScpConfig containing the configuration for the scp service, also inheritting from staticWadoConfig

The idea is that shared values can be set inside staticWadoConfig, while values specific to the other servers are located in the other configuration settings. All of them share the aeConfig values. There isn't anything special about the configuration values, they are just a set of values, so it is entirely possible to not use those, and just create the full configuration settings programatically for other purposes.  
An example configuration file, would be:

```
{
  staticWadoConfig: {
    rootDir: "/dicomweb",
  },
  dicomWebServerConfig: {
    proxyAe: "myProxyAe",
  },
  aeConfig: {
    myProxyAe: {
      description: "A proxy AE to use",
      host: "proxyAe.hospital.com",
      port: 104,
    },
  }
}
```

defines a shared root directory `/dicomweb`, used by all of mkdicomweb, dicomwebserver and dicomwebscp. However, the SCP and the mkdicomweb commands will write to the root dir, but won't proxy queries to `myProxyAe`, and thus reply with local data only. The dicomwebserver command, however, will access the proxyAe for retrieving missing data.

Additionally, this definition defines the proxy PACS AE configuration.

## Config Settings

### rootDir

The root dir defines the path for the created static DICOMweb files, and is used both for reading and writing.

### proxyAe and queryAe

The proxyAe is the AE name of a dimse service to fetch DICOM data from. This defaults to requiring a series level query in order to retrieve the study. That is, if the query `http://host/dicomweb/studies/1.2.3/series?...` is made, it will trigger a query to
`proxyAe`, to compare the current data in dicomweb with the data from the proxyAe. The queryAe is the name of the PACS system to use for querying, and will often be the same as proxyAe. This ae will also be used for studies level queries, to provide a complete list of study information.

### staticWadoAe

The static wado AE name is the name that static-wado uses when running `dicomwebscp` as the SCP name. As such, it provides both a C-Store as well as a C-Find SCP. It is also the name of the SCU used for outgoing queries to the queryAe or the proxyAe.

---
_Source: https://npm.io/package/@radicalimaging/static-wado-plugins · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._