Specialized engine · SR routing The structured-report specialist. Receive DICOM SR from modalities, AI vendors, voice-recognition platforms, and reporting systems; transform with template awareness; fan out to PACS, VNA, dose-tracking platforms, EMR, and the ACR Dose Index Registry. A standalone licensable subset of the Router optimized for SR-specific workflows.
Same platform features as the rest of the router-pattern family — keyed-hash pseudonymization, built-in honest-broker capability, shared admin shell, family-wide site encryption key for cross-product anon-ID consistency.
Capabilities
What SR Engine adds beyond Router’s general DICOM routing: template awareness, dose-SR specialization, CAD- finding routing, and the AI-finding round-trip pattern. All of it with the same platform features as the rest of the router-pattern family.
Receive DICOM SR objects from any conformant producer — modalities, voice-recognition platforms, AI applications, reporting platforms.
SR-specific transformations that respect template structure rather than treating SR as opaque DICOM. Required for cross-vendor SR cleanup and template upgrades.
A single SR object often needs to land in multiple downstream systems — PACS, VNA, dose-tracking platforms, EMR, reporting / dictation platforms. SR Engine fans out without the producer having to, and translates SR into HL7 or FHIR for consumers that don't take DICOM SR natively.
Radiation Dose SR (RDSR, TID 10001) is the highest-volume SR type in many imaging departments. SR Engine handles the routing; the customer's ACR / state requirements may be satisfiable in several different ways depending on what other systems they have.
Honest scope boundary. SR Engine is an SR-routing and format-translation product. The analytical / monitoring features that some customers expect from dose-tracking platforms live elsewhere.
AI vendors increasingly deliver findings as SR objects (rather than HL7 or proprietary formats). SR Engine receives, transforms, and routes those findings to the right downstream systems.
Same admin surface and platform features as the rest of the router-pattern family.
Architecture
A specialized variant of the router-pattern shape — narrower than the general Router, deeper on SR-specific logic. The producer / consumer landscape for SR is its own ecosystem of modalities, AI vendors, dose-tracking platforms, and EMR targets.
Use cases
Most SR Engine deployments fit one or two of these primary patterns. Multi-pattern deployments are common in larger institutions where dose tracking, CAD, and AI findings all flow through the same SR layer.
Modalities emit Radiation Dose SR (RDSR). What the institution does with it depends on what other systems they have. SR Engine routes to whichever destination(s) match the institutional requirements — without forcing a particular dose-tracking platform.
Flow
Most EMRs (Epic, Cerner, others) want HL7 ORU or FHIR DiagnosticReport — not raw DICOM SR. SR Engine translates SR content into the format the consumer expects, so producers (modalities, AI vendors, reporting platforms) can keep emitting SR and the EMR side gets what it expects without the producer having to know which downstream wants what.
Flow
Mammography CAD, Chest CAD, and other CAD applications produce SR-formatted findings. SR Engine routes those findings to PACS for diagnostic review, to reporting / dictation platforms as template inputs, to EMR via SR-to-HL7 translation where applicable, and to dose-tracking systems where dose-related CAD findings need to be visible.
Flow
AI vendors produce findings as SR. For vendors who don't take BAA scope, SR Engine handles the PHI-shielded round-trip via keyed-hash pseudonymization — same family-wide mechanism as the Router.
Flow
Ultrasound, echo, and other modalities produce SR-formatted measurement reports (TID 5200 cardiac echo, TID 5310 pediatric echo, etc.). SR Engine routes them to PACS, reporting platforms, and CVIS / cardiology PACS where applicable.
Flow
Modern reporting platforms emit the final radiologist report as a Comprehensive SR object. SR Engine routes the final report to all downstream consumers — PACS, EMR (via SR-to-HL7 translation), referring physician portals, image-sharing platforms.
Flow
Integration points
System requirements & sizing
SR objects are small (typically less than 100 KB each) but high-volume in dose-tracking and AI-finding deployments. Sizing reflects SR object count and consumer fan-out, not full study volume.
| Tier | SR volume | CPU | RAM | Storage | Typical site |
|---|---|---|---|---|---|
| Small (single facility) | < 1,000 SR / day | 2 vCPU | 4 GB | 100 GB (queue + audit) | Imaging center, single-modality dose-tracking deployment. |
| Medium (community hospital) | 1,000 – 10,000 SR / day | 4 vCPU | 8 GB | 500 GB | Single hospital with full modality mix, CAD deployment, dose tracking. |
| Large (academic / multi-site) | 10,000 – 50,000 SR / day | 8 vCPU (HA pair) | 16 GB per node | 1 TB per node | Academic medical center, multi-hospital, multiple AI vendors. |
| Enterprise (national / IDN) | > 50,000 SR / day | 16 vCPU (HA cluster) | 32 GB per node | 2 TB per node | Large IDN with enterprise dose tracking + multi-vendor AI. |
Licensing
Core handles ingest + basic forwarding. Transform adds template-aware migration and dose-SR specialization. Enterprise unlocks AI-vendor PHI shielding, ACR DIR submission, and HA pairing.
The base package — SR ingest, basic forwarding, audit log. Suited for single-purpose deployments.
Adds template-aware transformation, dose-SR specialization, and CAD-finding routing rules.
Everything, plus AI-vendor PHI-shielded round-trip, ACR DIR submission, and HA pairing.
Per-deployment licensing, not per-SR-object. Multi-product bundles (SR Engine + Router + VNA family) get bundle pricing and shared site-key provisioning.
Documentation
Every SR Engine deployment ships with the documents below, all managed under SynthQMS document control. The DICOM Conformance Statement is publicly available; the rest are shared under mutual NDA.
| Document | Title | Notes |
|---|---|---|
| DOC-2026-061 | Hardware & Software Requirements (SR Engine) | Sizing, OS support, dependencies |
| DOC-2026-077 | DICOM Conformance Statement (SR Engine) | Public — full SOP class + transfer-syntax matrix |
| DOC-2026-067 | EULA Annex (SR Engine) | Annex to the Synthology Master EULA (DOC-2026-063) |
| DOC-2026-079 | Penetration Test Results (SR Engine) | Available under NDA |
| DOC-2026-092 | QA Runner Manual (SR Engine) | Internal QA + customer-validated test runs |
| DOC-2026-083 | User Guide (SR Engine) | Operator + administrator workflows |
| DOC-2026-072 | Installation Guide (SR Engine) | Includes MSI deploy + Linux tarball install |
Frequently asked
Two reasons. First: footprint -- many customers (single-purpose dose-tracking deployments, CAD-finding distributors, AI-finding aggregators) need only the SR-specific slice of router-pattern capabilities. Deploying the full Router for them is overkill on cost and on operational surface. Second: specialization -- SR Engine is template-aware in ways that the general Router is not. Treating an RDSR or a Mammography CAD SR as opaque DICOM works, but losing the template awareness loses cross-vendor normalization quality and dose-tracking conformance. SR Engine optimizes for the SR workflow specifically.
Yes -- common pattern. Router handles general DICOM routing; SR Engine handles the SR slice with specialized transformation. Router can forward SR objects to SR Engine for specialized handling, then SR Engine fans out to dose-tracking, CAD, reporting, etc. A customer running both gets the platform consistency benefit (shared admin shell, shared audit, shared site encryption key for the keyed-hash pseudonymization).
Often no. SR Engine routes the RDSR; what destination satisfies your requirements depends on what your institution has. Three common shapes: (a) Epic Radiant institutions: Epic's Radiology module has integrated dose tracking, ACR DIR submission, automatic RDSR capture, and XR-29 / XR-25 Dose Check alerts. SR Engine forwards RDSR to Epic Radiant and Epic handles ACR compliance + abnormality alerting -- no separate dose-tracking platform required. (b) Non-Epic-Radiant institutions wanting full dose-abnormality monitoring + longitudinal tracking + QI reports -- you need a dose-tracking platform (Bayer Radimetrics, Sectra DoseTrack, Siemens teamplay), and SR Engine forwards to it. (c) Institutions whose only requirement is ACR Dose Index Registry submission -- SR Engine submits encrypted to the registry directly, no separate platform required. SR Engine's value is the routing flexibility; the analytical / monitoring features themselves live in Epic Radiant or in dedicated dose-tracking platforms, not in SR Engine.
Yes. For consumers that want HL7 ORU rather than DICOM SR (common for EMR-side integration), SR Engine transforms the SR content into HL7 ORU and emits HL7 messages. Same for FHIR -- SR Engine produces FHIR DiagnosticReport / Observation for FHIR-aware downstreams. The producer doesn't have to know or care which destination expects which format; SR Engine handles the per-destination shape.
Yes. Voice-recognition / dictation platforms take SR content as template inputs to populate the radiologist's draft report. This includes the established platforms (Microsoft Nuance PowerScribe, Jacobian M*Modal Fluency for Imaging) and the rapidly-expanding field of AI-driven dictation systems (DAX Copilot, Abridge, Nabla, Suki, Heidi, and a steady stream of new entrants). SR Engine routes to whichever platform(s) the institution uses, alongside the other consumer destinations. A single RDSR or measurement SR can land in the dictation platform (template input) AND the dose-tracking platform (compliance) AND the PACS (image-context retrieval) simultaneously. The dictation-platform landscape is moving fast; SR Engine's job is to keep routing to whatever the institution picks without constraining the choice.
SR Engine is a routing and format-translation engine. It does NOT track dose abnormalities, does NOT do longitudinal dose tracking per patient, does NOT generate QI / radiation-safety reports, does NOT do clinical decision support on SR content. Those are the analytical / monitoring features that dose-tracking platforms (Bayer Radimetrics, Sectra DoseTrack, Siemens teamplay) or EMR-native dose-tracking (Epic) provide. SR Engine's job is making sure the right SR content gets to the right destination in the right format.
Template-version migration is a core capability. Older modality firmware emits older versions of TID 1500, TID 5200, and other templates; current consumers expect newer versions. SR Engine recognizes the source template version and migrates forward to the consumer-expected version, preserving the measurement / finding semantics. The transformation is audit-trailed.
No -- SR Engine is an ingest / transform / forward engine, not an SR-creation tool. If your reporting platform produces free-text reports rather than SR, the place to address that is the reporting platform itself or the integration layer between reporting and PACS. SR Engine handles the routing and transformation of SR objects that already exist somewhere in the workflow.
Same family-wide mechanism as the Router and the VNA siblings. SR Engine uses keyed-hash pseudonymization on the way out (to the AI vendor), retains the source ↔ anon-ID mapping, and re-identifies AI-returned findings on the way back. AI vendor sees only anon-IDs; findings get linked to the right patient. A multi-product customer's site encryption key is shared, so anon-IDs from SR Engine are consistent with anon-IDs from the Router or VNA Migration in the same deployment.
Non-device software under FD&C Act §520(o)(1)(D), the 21st Century Cures Act §3060 carve-out for software that transfers, stores, converts, or displays device data without interpreting or analyzing it. No FDA Device Listing required. Same framework as Router, VNA Repository, and VNA Migration -- SR Engine handles storage and forwarding of SR objects without modifying clinical interpretation. Tag transformations are constrained to non-interpretive scope (template migration, anonymization, normalization).
Yes -- Windows and Linux, same as the rest of the router-pattern family. MSI installer for Windows, self-contained Linux tarball for Linux. Both supported equally.
Dose tracking? CAD findings? AI-finding distribution? Comprehensive-SR final reports? Tell us the SR-specific workflow you’re building and we’ll come back within one business day with a proposed architecture.