When radiology departments evaluate AI annotation tools, the clinical team is often ready to move quickly. The IT timeline is a different story. Integration projects that should take two to four weeks stretch to six months or longer — not because the underlying technology is difficult, but because the project gets classified as something it isn't.
We have gone through this process with enough imaging centers to have a reasonable map of where time actually goes. The blockers are not usually what the IT team expects at the start. Understanding them upfront can determine whether a pilot turns into a rapid deployment or a drawn-out procurement cycle.
Why AI-PACS Integrations Get Slow
The most common reason AI tool integrations take too long is that they get treated as full IT infrastructure projects rather than DICOM network additions. There are two architecturally different ways to connect an AI tool to a PACS, and they have radically different time and complexity profiles:
HL7/FHIR integration paths. If an AI tool needs to read from or write to the clinical EHR — pulling patient demographics, writing findings to discrete fields in a clinical note, triggering orders — you are in EHR integration territory. This means interface engine configuration, HL7 message mapping, involvement of your Epic or Cerner implementation team, and potentially a separate HL7 security review. These projects routinely take 3–6 months because they touch systems outside the radiology department's control and require hospital IT sign-off at multiple layers.
DICOM-only integration paths. If an AI tool receives studies via DICOM C-STORE or DICOMweb, processes them, and returns results as a DICOM Structured Report back to the PACS, the scope is entirely different. You are configuring a new DICOM node — the same kind of operation performed when adding a new CT scanner or PACS workstation. This typically requires: AE title and IP assignment, a firewall rule to allow the DICOM port through (default 11112 for DIMSE), and a brief test send of deidentified studies to confirm the connection. Total IT time: 2–4 hours.
Neurmorph operates entirely in the DICOM layer. There is no HL7, no FHIR, no EHR connection required for the core annotation workflow. This is a deliberate architectural choice — not because we couldn't build an EHR integration, but because the DICOM path eliminates the class of blockers that makes integration slow.
The Actual Blockers: What We See in Practice
Even on a DICOM-only integration, projects get delayed. Here is where time usually goes:
Security review classification. Some hospital IT departments classify any external connection as requiring a full security review — vendor questionnaire, penetration test summary review, BAA execution, and sometimes a VPN or site-to-site connection requirement. The review itself may take 2–6 weeks depending on IT backlog. This is understandable and not wrong — imaging data is PHI and external connections to PHI systems warrant scrutiny. The solution is to have the security documentation ready before the conversation starts, not after. For Neurmorph deployments, we provide: a BAA (signed same day), a DICOM conformance statement, a data flow diagram, and a summary of our TLS-in-transit and AES-256-at-rest controls. When an IT team can hand that package to their security team upfront, the review moves much faster.
PACS vendor involvement. Some PACS configurations require the PACS vendor to make changes — adding a new AE title, configuring an auto-routing rule, or enabling DICOMweb. If the PACS vendor is on a support ticket queue with a 2–4 week response time, that becomes the critical path. The workaround is to identify PACS administrator access level early. Many institutions have in-house PACS administrators who can make these changes without involving the vendor. If vendor involvement is required, getting the ticket opened on day one rather than week three saves time.
Modality worklist routing rules. For Neurmorph to process chest CT studies, an auto-routing rule in the PACS must send new chest CT series to the Neurmorph AE address. Setting up the rule correctly requires knowing how chest CT studies are labeled in your RIS — the modality code (CT), the body part examined field (CHEST or THORAX depending on your RIS configuration), and optionally the protocol name. Sites with inconsistent study labeling in their RIS — which is more common than you would expect — sometimes require a short data quality exercise before auto-routing works reliably. We recommend pulling a sample of 100 recent chest CT studies and checking how the body part examined field is populated before configuring the routing rule.
PHI vs. deidentified test data. Some institutions want to run a pilot entirely on deidentified studies before enabling live PHI processing. This is a reasonable starting position. The implication is that the IT team needs to have a deidentification workflow available — either a DICOM anonymization tool already in use, or the time to set one up. If the pilot requirement is deidentified data and the deidentification pipeline doesn't exist yet, that becomes the first project to complete. For Neurmorph pilots specifically, DICOM PS 3.15 Annex E de-identification is sufficient — most institutions that have run any research involving imaging data already have this capability.
The DICOM SR Output: Why It Matters for Integration Speed
The output format of an AI annotation tool has significant downstream implications for integration complexity. There are several ways AI tools deliver results to the radiologist:
- A separate web-based viewer (requires the radiologist to switch windows mid-read)
- An overlay plugin inside the PACS viewer (requires PACS vendor-specific plugin development and testing)
- DICOM SR written back to the PACS (appears automatically alongside the study in the radiologist's existing workflow)
The first two options both require additional software installation or custom PACS configuration work. The DICOM SR approach writes a standard DICOM object — the same file format the PACS already handles — back into the study's DICOM hierarchy. Modern PACS viewers (Epic Radiant, Sectra IDS7, Intelerad IntelePACS, Fuji Synapse) can display DICOM SR content natively. No plugin, no secondary viewer, no interface engine. The radiologist sees annotations in their existing viewer because the annotations are stored as standard DICOM data alongside the original images.
This is why Neurmorph chose DICOM SR as its output format from the start. We are not claiming this is the only valid approach — secondary viewer architectures have their own advantages in terms of custom annotation display and workflow state management. We are saying that for deployment speed and zero-dependency integration, DICOM SR is the right starting point for the majority of imaging centers.
A Realistic Deployment Timeline
For a typical imaging center deploying Neurmorph on chest CT, here is what the timeline actually looks like when the process runs smoothly:
- Day 1: Security documentation package sent to IT team. AE title and IP address assigned by Neurmorph. Routing rule discussion with PACS administrator.
- Days 2–5: IT security review (with documentation pre-provided, this usually takes a business week). BAA countersigned.
- Day 5–7: PACS auto-routing rule configured. Firewall rule enabled. Test send of 5 deidentified studies. Verify DICOM SR returned and displays in viewer.
- Day 7–10: Latency baseline measured on live network. Routing rule scope confirmed (chest CT series only, not all modalities). Read session with a radiologist to verify annotation display and annotation quality on site-specific scanner output.
- Day 10+: Pilot live on deidentified or consented studies.
Total elapsed time: 10 business days when blocking items are resolved in parallel. The 6-month figure comes from serial execution of each step, each step requiring back-and-forth with a separate party. Running the security review, BAA signing, and PACS configuration concurrently — which is possible when you have the documentation ready — compresses most of this overlap.
What IT Teams Should Ask Before the Integration Call
If your institution is evaluating a radiology AI integration, these are the questions worth resolving before the first technical call with any vendor:
- Does the tool require HL7 or FHIR connectivity, or does it operate at the DICOM layer only?
- What is the output format — DICOM SR, secondary viewer, overlay plugin? How does that interact with your existing PACS configuration?
- Does the vendor provide a BAA, DICOM conformance statement, and data flow diagram on request?
- Can your PACS administrator add a new AE title and configure an auto-routing rule without vendor involvement?
- Do you have a deidentification workflow available, or will the pilot require PHI?
The answers determine whether you are looking at a 2-week setup or a 4-month project before the first annotated scan reaches a radiologist. Architecture choices — specifically the HL7/FHIR versus DICOM-only divide — drive that difference more than any other single factor.