Security
Written for the person who has to sign off on it
DICOM Assist is deployed inside the customer's own infrastructure and handles protected health information on every path it touches. The controls below are what the product enforces, not a description of a hosting provider's controls.
In transit
In transit
How data moves, and who is allowed to send it.
TLS and mutual TLS
TLS and mTLS for inbound DICOM receive, inbound HL7 MLLP receive, outbound DICOM destinations, and outbound query/retrieve. TLS posture is set per interface, so a partner-facing listener can require client certificates while an internal one does not.
Outbound-only remote sites
The Remote Gateway dials out to HQ over mTLS. A remote site opens no inbound port, publishes no listener to the internet, and needs no VPN ingress - which removes the firewall exception that is usually the longest part of a connection project.
Source allow-lists
Each DICOM interface carries calling-AE and address allow-lists, and refuses a called AE title it does not answer. A listener no longer accepts any title that arrives.
Access
Access
Who can operate the appliance, and what is recorded.
Identity, RBAC and MFA
Role-based access control with multi-factor authentication, scoped API keys, and IP whitelisting for the management interface and the API.
Single sign-on
Microsoft Entra ID (Azure AD) over OpenID Connect, and LDAPS. Sign-in is delegated to the identity provider the organisation already runs.
Audited by default
A full audit log covering configuration changes, routing decisions, and administrative actions. Reading application logs in the console is itself audited, because those lines carry study and accession identifiers.
Data handling
Data handling
What the appliance does and does not do to a study.
Self-hosted, single tenant
The appliance runs on infrastructure the customer controls. There is no multi-tenant service, and no copy of a study leaves the environment except to a destination the customer configured.
Pixel data is never modified
Tag modification is metadata-only and in transit. An instance that nothing modified is stored exactly as it was transmitted, not re-serialized. DICOM Assist is a routing and integration appliance - it does not perform diagnostic interpretation and its reference viewer is structurally non-diagnostic.
De-identification fails closed
Research de-identification runs per instance on the way out. If it fails, that instance's send is blocked. It is never allowed to fail open and ship an un-scrubbed study.
Anonymize and Pseudonymize are separate modes
A profile declares one. Anonymize is irreversible and retains nothing - it never writes a crosswalk row or a correlation tag. Pseudonymize is reversible and writes an audited crosswalk row, with encrypted demographics, expiring mappings, and every lookup audited including the misses.
Unmatched results are held, not delivered
A returning result is matched by an ordered resolver, never by demographics. Anything that does not match at or above the route's confidence floor goes to Unmatched Returns for an operator to review rather than to the destination.
Operations
Operations
Keeping it healthy once it is in production.
Certificate management
Certificates for DICOM TLS, HL7 MLLP over TLS, and gateway identity are managed in the console with visible expiry, rather than being files someone remembers to replace.
Health and alerting
Every component reports by the stage of the path a study takes. Alerts are delivered by email and by webhook subscription. There is no SMS or paging integration.
No PHI in webhook payloads
Webhooks are HMAC-signed and carry event identifiers, not patient data, so an integration endpoint does not become a second place PHI lives.
The regulatory line
DICOM Assist is a networking and routing appliance. It does not modify pixel data, provide diagnostic viewing, or perform clinical interpretation. The built-in reference viewer is structurally non-diagnostic - reduced fidelity, always-on watermark, scoped to one study - and that is a compliance boundary, not a styling choice.
Common questions
Answers a reviewer usually needs
Is DICOM Assist a cloud service?
No. It is self-hosted on infrastructure you control - a Windows service backed by PostgreSQL. It is not a multi-tenant SaaS, and there is no vendor copy of your data.
Do remote sites need an inbound firewall rule?
No. The Remote Gateway makes an outbound mutually-authenticated TLS connection to your HQ install, and HQ never opens a connection to the site. The gateway's listeners are on the site LAN for its own modalities; nothing is published to the internet. To be precise about what this does and does not claim: the gateway uses the site's normal outbound path, with whatever source NAT already applies to it. What is not needed is an inbound rule - no port forward, no published NAT entry, no VPN ingress.
If nothing comes inbound, how does HQ send anything back?
Over the connection the gateway already opened. It is a long-lived bidirectional stream, so work travelling toward the site - a study to dispatch to the site's own PACS, a configuration change, a query to run against a PACS only the site can reach - is sent down that existing session. Return traffic is part of a flow the site originated, which is why the site's stateful firewall passes it without a rule being written.
Does DICOM Assist modify images?
It modifies metadata in transit when a rule or a destination says to, and never modifies pixel data. An instance nothing modified is stored exactly as it was transmitted.
What happens if de-identification fails on one instance?
That instance is not sent. De-identification fails closed by design; it is never permitted to fall through and deliver an un-scrubbed instance.
Which single sign-on providers are supported?
Microsoft Entra ID (Azure AD) over OpenID Connect, and LDAPS. Both are in production use. Ask us directly about anything else - we would rather tell you what is verified than what is written in the code.
Where do you keep your security documentation?
Architecture detail, deployment hardening guidance, and the current capability statement are provided under NDA during evaluation. Ask for them through the contact form and we will send them with a named contact.
Send us your security questionnaire
We would rather answer it early than discover a blocker in week six. Architecture detail and deployment hardening guidance are available under NDA.
Contact us