Telegnost PACS

Problem

Radiologists, technologists, registration staff and administrators needed one system to receive DICOM studies, keep patient records, work through radiology worklists, view images, write reports and request second opinions. It serves several organisations from one deployment, so every study, report and search result belongs to a tenant.

Constraints

• Tenant isolation has to hold in the interface, the API and the DICOM archive.
• The imaging layer already existed: DCM4CHEE as the archive and an OHIF/Cornerstone viewer. The application integrates with them rather than replacing them.
• Patient data falls under privacy rules, and every access to a clinical record is audited.
• The work ran against a fixed launch date.

What I owned

• Technical direction and delivery, and leading the team.
• The Next.js portal: worklists, tenant-aware navigation, search and reporting.
• The NestJS services: tenancy, audit, DICOM imports and the archive integration.
• The OHIF viewer fork and its bridge to the portal.
• Database, automated checks and deployment infrastructure.

Leadership

I lead 6 engineers at Craft Crew, across Telegnost PACS, Telegnost LMS and CTMS.

Keeping the portal's security policy strict

Situation

Segmentations wouldn't load in the PACS viewer under the portal's strict Content Security Policy: a library deep in the imaging stack generated code at runtime, which the policy blocks.

What I decided

I ruled out loosening the policy for the whole portal and had us replace the library instead, with build checks that fail if the original ever comes back.

What happened

Segmentations load under script-src 'self' with no exception in the policy, and the forked viewer became the PACS viewer on 11 October 2026.

Hardest problem

Running the OHIF viewer inside the portal

The viewer is a fork of OHIF in a sandboxed iframe. Both sides check the sender's origin and window and accept only known message shapes; image requests go through a backend proxy that checks access to each study on the user's PACS session; and segmentations load under a strict Content Security Policy after I replaced a library that generated code at runtime. The article covers it in detail.

Setting up tenants in a slow archive

Each new tenant needs its own configuration in the DICOM archive, and those writes take about a minute. Tenant setup doesn't trust a timeout: it reads the configuration back to confirm each write, retries a failed reload on the next pass so the tenant's HL7 receivers come up, and takes its lock before reading tenants, so a startup check can't undo a rename or a suspension.

Related article: Running a DICOM viewer under a strict Content Security Policy ↗