Security overview

Deployment model

• On-premises. PrismLink is installed on a server owned and controlled by the healthcare organization, inside its own network, alongside the imaging and reporting systems it connects. There is no multi-tenant or vendor-hosted deployment.
• Four isolated Windows services. DICOM intake, HL7 intake, runtime processing and the reporting-system connector run as separate Windows services, one for each job, each under its own dedicated Windows service identity. There is no shared service account, and no service password to store or rotate.
• Least privilege by role. File permissions follow the service split: intake services write the study archive but cannot touch the outbound spool; the connector delivers the spool but cannot modify the archive; and only the connector's identity can decrypt the reporting-system credential, which is sealed to the machine with Windows DPAPI. The services still coordinate through shared local databases today; a physical per-service database split is planned.
• Installed inert, activated deliberately. Setup provisions the services stopped and disabled, with no listener configuration, no credentials and no firewall rules. A site administrator turns them on explicitly through Studio, confirming with a Windows administrator (UAC) prompt; activation creates exactly two inbound firewall rules, each tied to its own service.
• No inbound access from outside the organization is required for normal operation.

What data PrismLink receives

• DICOM Structured Reports from imaging modalities, and HL7 ORU result messages from information systems. Both contain protected health information — patient identifiers and clinical measurements.
• Report field values written to the reporting system, and — where a site enables it — signed report text retrieved from the reporting system for validation purposes.
• PrismLink does not require, and does not request, data beyond what is needed to map and deliver the study.

How data is persisted

• Received documents are retained. Each received DICOM SR or HL7 message is written byte-for-byte into a content-addressed archive on the local filesystem, under the program data directory. Originals are never modified in place.
• Two local databases. An authoritative store holds study identity, configuration decisions and delivery state; a second, rebuildable cache holds derived analysis. Both use embedded SQLite — there is no separate database service to deploy or secure.
• Both the archive and the databases contain PHI and should be treated accordingly: restricted ACLs, excluded from general-purpose file shares and from workstation backup scope.
• Encryption at rest is provided by the host, not by the application. PrismLink does not encrypt its own database files or archive. Deployment guidance is to place them on an encrypted volume (for example BitLocker). Application-level encryption at rest is [In progress] — if your policy requires it rather than volume-level encryption, tell us during evaluation.
• Retention. Received studies and decision history are retained indefinitely by default so that any delivered value remains auditable. A configurable retention and purge policy is [In progress]; today, retention is managed by the site.

Network communications

Inbound

• DICOM receiver and HL7 MLLP listener, on ports chosen by the site, reachable only from the modalities and systems the site permits. Both are provisioned disabled and listen only after explicit activation by an administrator, behind firewall rules bound to the specific service.
• Studio, the browser configuration interface, is served by the application itself and binds to localhost by default. Exposing it beyond the host is a deliberate configuration change, and the software warns — or, with PRISMLINK_AUTH_STRICT set, refuses to start — if it is bound off-loopback without authentication enabled.

Outbound

• To the reporting system, to deliver field values. This carries both the application credential and PHI, and runs over HTTPS with the server certificate verified against the system trust store by default. Sites using an internal certificate authority supply their CA bundle. Disabling verification is possible but is an explicit, logged opt-in intended for isolated test endpoints, and is not appropriate for production.
• To the update service, to check for and download signed software updates over HTTPS. No study data is transmitted.
• To an AI model provider — during configuration only. See below.

The one external data flow, stated plainly

During setup, PrismLink can use an AI model to propose how a particular scanner's encoding maps onto report fields. To make that proposal, the contents of structured reports from that scanner are sent to the AI provider.

• This happens during configuration and review, not during live study processing. Once a mapping is accepted it is executed by local, deterministic code, and no external service is contacted to deliver a study.
• Every proposal is reviewed and accepted by a person before it takes effect.
• What is sent is minimized and audited. Everything sent to an AI provider leaves through a single control point. Known patient-identifier fields — names, record numbers, accession numbers, unique identifiers and similar — are removed before sending. The control refuses AI providers the site has not explicitly approved, never switches silently to another provider or endpoint, and records an audit entry — with no clinical content — for every request. This removes known identifiers; it is not certified de-identification: what is sent must still be treated as potentially containing protected health information, and the step is operated under an appropriate agreement with the AI provider. Validating the removal against a documented de-identification process is [In progress].
• Usage is bounded. AI calls during configuration run under an installation-wide limit on how many may run at once.
• External AI can be switched off by deployment policy. A deployment configured with AI disabled refuses every outbound AI request, and Studio shows the restriction read-only. Mappings can then be configured by hand; the resulting runtime behaviour is identical.

Authentication and access control

• Studio access supports three modes. Open, appropriate only for the default localhost bind. Proxy, the intended production mode, in which an authenticating reverse proxy such as IIS performs Windows Integrated Authentication against Active Directory and PrismLink authorises against a named AD group. Basic, a single-account fallback.
• Human access is intended to be gated by an AD group, so that joining and leaving is managed by existing hospital identity processes rather than by local accounts on the server.
• Credentials are never stored in the application tree. API keys and configuration secrets resolve through a chain of environment variable, then the operating system's secure store (Windows Credential Manager), then a protected file. Secrets are never written to logs; a lookup failure reports where it looked, not what it found.
• The production reporting-system credential is held by one service. It is sealed to the machine with Windows DPAPI and is decryptable only by the delivery connector's service identity. The other services — and Studio itself — never receive it.
• Role-based access control within Studio — distinguishing, for example, a reviewer from an administrator — is [In progress]. Today, access to Studio is access to configuration.

Audit and logging

• Configuration decisions are append-only. Every mapping decision records the actor, the time, and what was decided. Later automated runs cannot silently overwrite a human decision, and superseded proposals are retained rather than replaced.
• Received studies carry an append-only status history — received, processing, processed, held, failed — so the handling of any document can be reconstructed.
• Delivery is tracked to acknowledgement. Each delivery attempt moves through a durable spool; failures are retained for inspection rather than discarded.
• Update history is recorded, including what was installed, when, and by which operator action.
• Operational logs avoid clinical content. Logs identify studies by accession and technical identifiers rather than reproducing patient names or clinical values, and debug output that could carry payloads is disabled by default in production. [In progress] — a formal log-content review and a documented log retention policy are not yet complete.
• Forwarding audit records to a hospital SIEM is [In progress]; today the records are local.

Backup and recovery

• PrismLink provides an explicit backup command that produces a consistent copy of its databases; the destination must be named deliberately, so a backup cannot be written to an unintended location by default.
• Because received documents are retained immutably and derived data is rebuildable, the cache can be discarded and regenerated without loss of decisions or source material.
• Software updates back up the existing installation before replacing it and can be rolled back.
• Backup scheduling, offsite copies and restore testing are the site's responsibility and should be included in the deployment plan. A documented recovery objective is [In progress].

Software integrity and updates

• The installer is self-contained and signed. It carries its own Python runtime and every dependency, pinned by exact version and cryptographic hash at build time; installation downloads nothing onto the customer machine. The installer is Authenticode-signed, and the build refuses to run from a modified source tree.
• Updates are distributed as packages whose manifest is signed with an Ed25519 key held offline. The corresponding public key is pinned into the installation at build time and is never taken from the update server.
• The distribution server is treated as untrusted infrastructure. It serves bytes; it cannot authorise an installation.
• A package is verified before extraction, copied into immutable staging, and verified again there. Release sequence numbers only move forward, so a superseded release cannot be re-offered.
• Checking, downloading and installing are separate operator actions. PrismLink does not install updates automatically.
• An interrupted update — a reboot, a killed helper process — is detected and recovered. Success is recorded only when the installed manifest proves the new version is actually active; otherwise the update is cancelled and the explicit controls return.

How the software is built

• The main branch is protected, and every change passes a required automated security check before it can merge.
• Every release is scanned — the source, its change history, and its dependencies — for secrets, protected health information and customer-confidential content, with an independent secret scanner running alongside.
• Third-party components ship pinned by exact version and hash. A replaced, modified or unexpected component fails the build before packaging begins.
• A formal software bill of materials and a signed release record are [In progress].

Remote access and telemetry

• PrismLink contains no remote access mechanism. There is no built-in remote console, no reverse tunnel and no vendor backdoor. Any support access is arranged through the site's own remote-access process, under the site's control and supervision.
• PrismLink collects no telemetry or analytics. It does not report usage, performance or error data to the vendor. Diagnostic information reaches Circanever Technologies only when a site deliberately sends it.

Subprocessors

• AI model provider — receives structured report content during AI-assisted configuration only, as described above. Not contacted during live study processing.
• Software update distribution — operated by Circanever Technologies to serve signed update packages. It receives no study data and no protected health information.
• No other third party receives data from a PrismLink deployment. A formal subprocessor schedule for contracting purposes is [In progress].

Determinism and clinical safety posture

• No AI model participates in processing a live study. Mapping decisions are made and reviewed during configuration and then executed by audited local code.
• The same study produces the same output every time, and that output can be replayed and compared.
• Where evidence is ambiguous, the field is left empty rather than populated with a guess. Empty fields are expected and are visible to the radiologist.
• When several values could fill one field, PrismLink never simply takes whichever came first. A selection rule — earliest, latest, smallest, average — applies only where the reviewed mapping explicitly chose one.
• Automated review of proposed mappings records what it removed and on what evidence, rather than silently discarding it.

What this page does not claim

PrismLink is in alpha and deployed for evaluation. Circanever Technologies makes no claim on this page of regulatory clearance, certification, or third-party audit. Formal security assessment, penetration testing and independent attestation are [In progress]. Questions about the current state of any item above are welcome and will be answered directly rather than deferred to a datasheet.