Security and audit

Roles

Role	May
Viewer	See monitoring, nodes, configuration, alerts and reports.
History viewer	Also see anything naming patients: the history, dead letters, quarantine, prior-study requests, AI jobs, the reconciliation queue, HL7 messages and the worklist.
Operator	Run things without changing the configuration: drain and resume nodes; retry, skip and resend; re-queue or purge dead letters; route or delete quarantined instances; work the reconciliation queue; test destinations. Where these show patients (resends, the problem queues, reconciliation, HL7 messages) the history role is needed too. Downloading instances stays with administrators.
Administrator	Change the configuration and act on nodes, queues and problems. Downloading instances and changing patient data also need the history role.

How people sign in, and how roles are given, is under Console sign-in.

Protecting patient data

In transit: the console and node API over HTTPS; DICOM, HL7 and DICOMweb over TLS where you choose.
At rest: nodes close their data and log folders to ordinary local users, and can encrypt what they keep (see below); secrets (passwords, tokens, keys) are stored encrypted and never shown again, exported or kept in the version history.
Senders: sources should name senders’ addresses as well as AE titles; Answer C-ECHO only from senders matching a route stops the router answering anyone. DICOMweb senders each have their own token, kept only as a hash.
Nodes: each has its own key; new nodes wait for an administrator’s approval (by default); keys can be reset or revoked.
Scripts: API tokens (Configuration › Node enrollment › API tokens) let scripts see nodes and drain or resume them, for updates, and nothing else: no configuration, no patient data. Shown once, kept as hashes, revocable, expiring after a year by default; what they do is in the audit log under their names.
De-identification for destinations that must not receive identities.

Encryption at rest

With Settings › Encrypt traffic kept on nodes on, nodes encrypt what they keep on disk that names patients: received instances, queues, the resend cache, held studies, the reconciliation queue, quarantine, dead letters, instances retrieved through the router, HL7 messages, procedure steps, queued history, patient ID maps and the worklist.

How: AES-256-GCM, each file with its own key derived from the node’s key, in 64 KB chunks each authenticated with its place in the file, so a file that is altered, reordered or cut short is refused rather than sent on. Records are encrypted one at a time. The cost is small next to the network and the disk.
The node’s key is data.key in its data folder, made the first time encryption is turned on and protected like the node’s other secrets: by Windows for the service account (DPAPI), or off Windows by the protection key, which should then come from ROUTES_PROTECTION_KEY rather than the disk. A copy of the data folder, a backup of it, or a disk taken from the machine is unreadable without it.
On or off at any time: the setting applies to what is written from then on. Files already on disk stay as they were until they are delivered or removed, and nodes read both.
Not encrypted: file names (instance UIDs and keys), the queues’ journals, logs, and the node’s configuration copy. The central database is protected by its own server (SQL Server TDE, or encrypted PostgreSQL storage).
If the key is lost (the service account changes on Windows, or ROUTES_PROTECTION_KEY changes), what it encrypted cannot be read: the node says so and sets those files aside rather than deleting them (instances it cannot send become dead letters), and keeps the old key file as data.key.<time>.unreadable, in case the account or key comes back.

It does not replace full-disk encryption (BitLocker, LUKS), which also covers logs and the operating system; it is for where that is not enough or not possible, or when policy asks for application-level encryption of patient data.

Two-person approval of changes

With Settings › Changes need a second administrator’s approval on, a change one administrator makes to the configuration is not applied straight away: it waits under Configuration › Pending changes, with a line saying what it does (“Change destination ‘PACS’: host, port”) and the change itself (passwords and secrets hidden), until another administrator approves it, which applies it exactly as it was asked for, or someone rejects it. Its proposer can withdraw it, but not approve it.

Held: sources, destinations, routes and their order, settings (scripts, de-identification profiles, HL7 routing, AI workflows and the rest), alert settings, the enrollment key and policy, the metrics token, de-identification key renewals, imports and restores of the configuration.
Not held: operations (draining nodes, queues, dead letters, resends, node keys), patient ID map entries, and user accounts.
The audit log names both: the change is recorded as made by “alice, approved by bob”, and the proposal, approval or rejection each have an entry of their own. A change that no longer fits the configuration when it is approved (say, its destination was deleted meanwhile) is not applied, and says why.
Turning approval off is a change like any other, so it needs approval too. It needs at least two administrators: if the only other one is gone, set DisableChangeApproval to true in the central service’s settings (registry or environment) on one server, restart it, turn the setting off in the console, and remove DisableChangeApproval.

The audit log

The Audit log tab records:

every configuration change, with who made it, and node actions (drain, resume, keys, approvals);
every sign-in;
every look at patient data: history searches, opened studies, lists of dead letters, AI jobs, HL7 messages and the rest, and every download;
every search and retrieval through the router by viewers and workstations;
HL7 messages received for the worklist and MPPS reports (who sent what, never the patient);
actions in the reconciliation queue and patient ID maps.

Entries that name patients (searches and retrievals through the router) are visible only to history viewers. Entries written by the console never include the search text, since it may name a patient.

The log is kept six years by default (Settings › Audit log retention), as HIPAA asks of audit records.

The audit repository (IHE ATNA)

Hospitals collect audit trails from every system in one audit record repository or SIEM. With Settings › Audit repository set, every audit log entry also goes there as a DICOM audit message (PS3.15 A.5), over syslog:

Entry	Audit message
Sign-in	User Authentication (Login)
Users, two-factor, passwords	Security Alert (User Security Attributes Changed)
Node keys, the enrollment key, the metrics token, approvals	Security Alert (Security Configuration)
Sources, destinations, routes, settings, nodes	Security Alert (Network Configuration)
History searches, queries through the router	Query
Opened studies and lists naming patients	DICOM Instances Accessed
Resends and retrievals through the router	DICOM Instances Transferred
Downloads, patient ID map exports, emailed reports	Export
HL7 messages for the worklist, MPPS, worklist changes	Patient, Procedure or Order Record

Each names who did it, this system, and the study (by its UID) or the part of the configuration it concerned; never a patient ID.

Transport: TLS (RFC 5425, the default), presenting the central server’s certificate for the mutual authentication ATNA asks for; or TCP, or UDP (which can lose messages). The repository’s certificate must be trusted by the operating system, or listed by thumbprint.
Nothing skipped: messages go in order, from where sending left off, by whichever central server leads. While the repository cannot be reached they wait, and an alert is raised after 15 minutes. Sending starts from when the repository is set (or changed), not from the beginning of the log.

Never in production

Never run the central service with ASPNETCORE_ENVIRONMENT=Development: that mode signs everyone in as an administrator, for developers only.