>
build 2.4.5 · aes-256-gcm / ml-kem-768 · eu/de · ram only
Healthcare · NEN 7510 · GDPR

DICOM files delivered.
Then destroyed.

Send MRI, CT, and X-ray files via post-quantum encrypted relay. Client-side encryption, burn-on-read, Merkle audit trail. Zero persistent storage. EU only.

Request access → Setup guide ↓
NEN 7510-1/2 GDPR Art. 32 EU jurisdiction — Hetzner DE ML-KEM-768 (FIPS 203) Burn-on-read Data Processing Agreement available

The problem with DICOM transport

DICOM files carry the most sensitive patient data there is: images, metadata with BSN, birth date, diagnosis codes, referring physician. Every transfer is a compliance event.

RequirementRegulationLegacy solutions fail because...
End-to-end encrypted transportGDPR Art. 32 · NEN 7510-2SFTP encrypts the channel, not the file. Email is plaintext. WeTransfer has no E2E.
No persistent storage of patient dataGDPR Art. 5(1)(e) · NEN 7510-1Cloud shares, email attachments, and SFTP all retain copies indefinitely.
Tamper-evident audit trailNEN 7510-1 §9.4 · WGBOSFTP logs are mutable. Email headers are forgeable. WeTransfer provides no audit export.
EU jurisdiction onlyGDPR Art. 46Most SaaS solutions route through US infrastructure (AWS, Azure, GCP).
Post-quantum readiness by 2030NCSC PQC migration guidelineNo widely deployed file transfer tool uses ML-KEM or equivalent today.

Architecture

All encryption happens on the client. The relay sees only opaque ciphertext. The file is destroyed after the first authorised download.

[PACS / radiology workstation / MRI scanner export] │ ▼ encrypt client-side — ML-KEM-768 + ECDH P-256 → AES-256-GCM paramant-sender.py │ ▼ ciphertext only — relay has zero plaintext access health.paramant.app (Hetzner Frankfurt DE · RAM only · no disk write) │ ▼ burn-on-read — destroyed after first download paramant-receiver.py │ ▼ decrypts client-side, forwards to PACS [Destination PACS / reading station / archive] │ ▼ Merkle leaf hash recorded in CT log — proof of delivery, no content health.paramant.app/v2/ct/log

Step-by-step setup

  1. 1

    Install the paramant client

    Runs on any Debian/Ubuntu system, including Raspberry Pi and embedded Linux. No Python environment needed — the .deb bundles everything.

    # Debian / Ubuntu (amd64 or arm64)
    curl -fsSL https://paramant.app/install-client.sh | bash
    
    # Or manual .deb install
    wget https://github.com/Apolloccrypt/paramant-relay/releases/latest/download/paramant-client_amd64.deb
    sudo dpkg -i paramant-client_amd64.deb
    
    # Verify
    paramant-sender.py --version
    # paramant-client 2.4.5
  2. 2

    Configure

    Request a pgp_ API key at privacy@paramant.app. Keys for healthcare are issued against the health.paramant.app sector.

    # Interactive setup
    paramant-setup
    # Relay:  health.paramant.app
    # Key:    pgp_xxxxxxxxxxxxxxxx
    # Device: mri-001
    
    # Or write config directly
    mkdir -p ~/.paramant
    cat > ~/.paramant/config.json <<EOF
    {
      "relay":  "https://health.paramant.app",
      "key":    "pgp_xxxxxxxxxxxxxxxx",
      "device": "mri-001",
      "sector": "health"
    }
    EOF
  3. 3

    Send a DICOM file

    Files are encrypted before leaving the machine. The relay only sees ciphertext.

    # Single file
    paramant-sender.py --key pgp_xxx --device mri-001 --sector health scan.dcm
    # → Uploaded: https://health.paramant.app/v2/blob/abc123
    # → CT leaf:  3fa7b2c4d8e1...
    # → Expires:  burn-on-read (no TTL)
    
    # Watch folder — auto-send new DICOM files as they appear
    paramant-sender.py \
      --watch /dicom/outbox/ \
      --device mri-001 \
      --sector health \
      --key pgp_xxx

    Persistent watch with systemd

    # /etc/systemd/system/paramant-dicom.service
    [Unit]
    Description=Paramant DICOM sender
    After=network.target
    
    [Service]
    ExecStart=/usr/local/bin/paramant-sender.py \
      --watch /dicom/outbox/ \
      --device mri-001 \
      --sector health \
      --key pgp_xxx
    Restart=always
    RestartSec=10
    User=paramant
    
    [Install]
    WantedBy=multi-user.target
    sudo systemctl enable --now paramant-dicom
  4. 4

    Receive and forward to PACS

    The receiver polls the relay, decrypts locally, and forwards the raw DICOM bytes to your PACS.

    # STOW-RS compatible endpoint
    paramant-receiver.py \
      --key pgp_xxx \
      --sector health \
      --forward http://pacs.hospital.nl:11112/api/dicom
    
    # DICOM DIMSE (C-STORE SCU)
    paramant-receiver.py \
      --key pgp_xxx \
      --sector health \
      --forward-dcm pacs.hospital.nl:11112 \
      --forward-aet DESTINATION_AET
  5. 5

    Verify delivery in the CT log

    Every transfer creates a Merkle leaf hash. The log proves delivery at a specific timestamp without storing any patient data.

    curl https://health.paramant.app/v2/ct/log?limit=5 \
      -H "X-Api-Key: pgp_xxx" \
      | python3 -m json.tool
    # Example response
    {
      "ok": true,
      "root": "3fa7b2c4...",
      "entries": [
        {
          "index": 47,
          "leaf_hash": "3fa7b2c4d8e1...",
          "tree_hash": "9b4c1a2e...",
          "device_hash": "a1b2c3...",
          "ts": 1744649123
        }
      ]
    }

Compliance summary

How Paramant maps to the NEN 7510 and GDPR requirements for DICOM transport.

AspectImplementationStandard
EncryptionML-KEM-768 (FIPS 203) + AES-256-GCM, client-side onlyNEN 7510-2 A.10.1 · NCSC PQC
StorageZero bytes on relay — RAM only, destroyed after first readAVG Art. 5(1)(e) · NEN 7510-1
JurisdictionHetzner Falkenstein, Germany — no US sub-processorsAVG Art. 46
Audit trailMerkle CT log — SHA-256 leaf hashes, append-onlyNEN 7510-1 §9.4 · WGBO
Relay identityML-DSA-65 self-signed relay certificateFIPS 204
DPAData Processing Agreement (GDPR Art. 28) available on requestAVG Art. 28

FAQ

Does the relay store the DICOM file?
No. Ciphertext is held in RAM only. It is destroyed immediately after the first authorised download. No disk write occurs at any point. The CT log records only a hash — never the content.
Can we run paramant on-premise within the hospital network?
Yes. The relay is open source (BUSL-1.1). Deploy it in your own infrastructure. The sender and receiver apply client-side encryption regardless of where the relay runs — even an on-premise operator has zero plaintext access.
What happens if the receiver doesn't download the file?
By default, files are burn-on-read with no TTL — they wait in RAM until downloaded. You can set an optional TTL (Professional tier). If the relay restarts, RAM-only blobs are lost — configure disk persistence for resilience in critical workflows.
DICOM files are often larger than 5 MB — how do you handle that?
The relay currently pads all transfers to 5 MB and enforces a hard limit per blob. For large CT/MRI series, split by series UID or use the Enterprise streaming mode which supports up to 500 MB via WebSocket chunking.
Is there a verwerkersovereenkomst?
Yes. Required under GDPR Art. 28 when patient data is processed by a third party. Available on request: privacy@paramant.app

Start sending DICOM files today

Request a pgp_ key for the healthcare relay. Verwerkersovereenkomst included.