Loading Viewer Data

This page is for companies and platforms that want to host the Avara Viewer in their product, or that are not using Avara PACS as their archive. If the DICOM files live in your system, you wire how the viewer gets them. If Avara PACS is the archive, Avara handles ingest and fetch — the same launch model still applies.

Modalities still send studies into an archive the way they always have — C-STORE (and the rest of DIMSE) from the scanner into Avara PACS or yours. That path is ingest. It is not how the viewer opens a study.

The Avara Viewer does not speak DICOMweb and does not run C-MOVE, C-GET, or other DIMSE retrieve. When a study launches, the viewer is handed a list of presigned HTTPS URLs into blob storage (S3-compatible object storage, or Avara’s archive). It GETs those objects and parses them just in time — frames become usable as they arrive, not after a full study lands on disk. That is more secure than handing the browser a DICOM node, much faster than retrieve-over-DIMSE, and a better reading experience.

How those URLs are minted depends on who holds the pixels.

Avara PACS

If Avara PACS is the archive, Avara handles DICOM node setup with the facilities and sites — AE titles, routing, worklist, and C-STORE from the modalities into Avara storage. You do not stand that up yourself.

Once the objects are in the archive, opening a study is a different path. The viewer session is authorized, short-lived GET URLs are issued against Avara storage, and pixels stream in. You do not implement Study Data or Secondary Capture for image fetch. Leave those blank — see What webhooks should I configure.

Your archive

If your PACS (or platform) is the archive, you store the DICOM files. Modalities still C-STORE into your nodes the usual way. When a viewer instance launches, Avara POSTs study.access_requested to your Study Data webhook. Your backend looks up that study and returns presigned GET URLs into your blob storage for the DICOM objects (and optional non-DICOM media). The viewer then fetches those URLs directly. Avara never takes over your archive in that model.

Implement the webhook on What webhooks should I configure and the language pages under Viewer → Webhooks. Return authorized: false to deny a study; authorized: true with an empty urls list means no data, not a denial.

Secondary capture is the reverse direction: Avara asks for presigned PUT URLs so a new series can be written back to your storage. Annotations save in Avara without that webhook.

Server to server

The browser never sees your storage keys, and it never talks DICOMweb to your PACS.

1. Avara already knows which study and which session is opening (a logged-in Avara user, or a temporary access view you minted).
2. Avara calls your HTTPS endpoint. The body is signed with Standard Webhooks (webhook-id, webhook-timestamp, webhook-signature). You verify with unwrap() and AVARA_WEBHOOK_KEY — a forged or replayed POST does not pass.
3. Your server decides if that study may be read, then mints short-lived, object-scoped GET URLs (typical blob signing: verb, key, expiry). Those URLs are useless after they expire and are not a master key to the bucket.
4. The viewer GETs the objects over TLS. Avara’s API key never ships to the client.

That is why a leaked viewer tab does not equal a leaked archive: the session can only fetch what you just signed, for a short window.

Who authenticates the human

Two ways in. Both end in the same webhook-and-presigned-URL path for pixels.

Avara login — You invite the user; they set a password and sign into the Avara dashboard (or the product UI). Avara holds the session. When they open a study, Avara already knows usr_… and stu_… before it asks your archive for URLs. Stolen dashboard cookies are still bound to that user and that org’s studies — not to your bucket credentials.

Temporary access views — The user never logs into Avara. They are already authenticated in your app. Your backend (API key stays on the server) calls rerouteURL / reroute_url and gets a one-time, short-lived link. You open that link in a new window. The API key never reaches the browser; the user cannot mint a second study URL without going through you again. Same Study Data webhook after that for pixels. See Viewer temporary access views (or AutoScribe if they are dictating).

In both cases the pixel path is server-to-server then short-lived blob GET. The person path is either Avara’s login or a link only your servers can create.

For how loading feels in the product (drag and drop, streaming, hanging protocols), see Loading Data.