How your PACS connects to a teleradiology provider

"Do we have to replace our PACS, and how big is the integration project, really?" Every PACS administrator asks some version of this before their facility signs with a teleradiology provider. The short answer: PACS integration for teleradiology replaces nothing you already own, and for most facilities there is no project. No PACS migration, no archive conversion, no second viewer on your technologists' desktops. Studies leave your PACS one of two ways, a DICOM send to the provider's receiving node or a browser upload to a secure portal, and AstraRad accepts both. Signed final reports come back over HL7 or FHIR into your RIS or electronic health record (EHR), or through the portal if you'd rather skip interfaces entirely.

Vendor pages promise painless integration and stop there, which is useless to the person who has to open the firewall ticket. This page names the protocols, the configuration objects, the owner of each one, and a realistic timeline.

How do studies get from our PACS to a teleradiology provider?

Studies reach a teleradiology provider either by an automated DICOM send from your PACS or by a person uploading them through a secure portal. Everything else on this page is a detail hanging off that choice.

	DICOM send from PACS	Portal upload
Work required at your facility	One destination entry, one firewall rule	None
Who touches it per study	Nobody, routing rules fire automatically	A technologist or coordinator
Time to first study	Days, gated by your change process	Same day
Best for	Recurring volume, night and weekend coverage, overflow that runs continuously	Trials, occasional second opinions, facilities with no PACS, backlog batches
Failure mode	A route silently stops and nobody notices until reports go missing	Someone forgets to upload

The right first move for most facilities is both, in sequence. Start on portal upload the week you sign; it proves the clinical relationship works before anyone spends political capital on a firewall change. Configure the DICOM route in parallel and cut over once volume justifies automation. Facilities clearing a backlog often never leave portal upload at all: an 8,000-study backlog clears in under 30 days without a single configuration change on your side.

One honest boundary before going further: if your security policy will never allow imaging data to leave your network in any form, teleradiology is the wrong tool for your facility, and no integration cleverness changes that.

If your volume is X-ray and ultrasound overflow arriving in unpredictable bursts, the pattern is described in more detail on X-ray and ultrasound overflow. If you're earlier than that and still establishing what teleradiology is, start with what is teleradiology.

DICOM push teleradiology: sending straight from your PACS

DICOM push teleradiology means your PACS opens a C-STORE association to the provider's receiving node and sends the study itself, with no appliance installed and no agent running at your facility. It is the lightest topology available and the one most imaging centers should ask for first.

Two conditions have to hold. Your PACS must be permitted to open an outbound connection to a host outside your network, and it must support the transport your security team requires, which in practice means TLS on the association or a site-to-site VPN carrying plain DICOM. Older PACS builds sometimes support neither, and that is the single fact worth confirming before anyone promises a go-live date.

Routing rules decide what actually goes. Most facilities scope the rule by modality, by ordering location, and by priority, so overnight volume routes out automatically while the day list stays in-house. AstraRad accepts a push from any PACS or modality that can be configured with a destination, and installs nothing on your side.

Teleradiology gateway appliance: when PACS cannot reach the internet

A teleradiology gateway appliance is a small server or virtual machine inside your network that receives studies from PACS over the LAN and forwards them outbound on your behalf. Security teams favor it for two reasons: the PACS itself never opens a connection beyond the local subnet, and the appliance gives them one auditable egress point to monitor.

The cost is one more component to patch, monitor, and write into your downtime plan. A gateway that fills its local cache during a WAN outage stops accepting studies from PACS, and the failure surfaces as studies that quietly never left, with no alert attached to them. Ask who owns patching, who watches queue depth, and what the alert threshold is, in writing, before go-live.

A gateway changes nothing the radiologist sees. The same DICOM arrives at the same receiving node, and the four configuration objects below still have to agree.

Does teleradiology require a PACS migration?

No. A teleradiology provider is a DICOM destination, so your archive, your viewer, your worklist, and your storage contract all stay where they are. Nothing is exported, converted, or re-indexed. A DICOM send transmits a copy of the study while the original stays in your archive under your own retention policy.

The distinction matters because "integration" gets used for two very different projects. Replacing a PACS is a migration: data conversion, an archive move measured in terabytes, retraining, and a cutover weekend. Connecting to a teleradiology provider is a configuration change on equipment you already own, which is why the rest of this page counts configuration objects instead of project phases.

The document to hand your PACS administrator here is the ACR-AAPM-SIIM Technical Standard for Electronic Practice of Medical Imaging, which sets the professional expectation that systems used for electronic transmission and interpretation conform to the DICOM standard, and that relevant prior studies and reports be available to the interpreting physician. Both are configuration questions on your side. Neither is a reason to move your archive. AstraRad is DICOM conformant and reads with priors attached when your routing rule sends them.

Four objects a DICOM route needs to agree on

A DICOM route is a C-STORE association between two nodes, and it works when four configuration objects agree. Each one has an owner.

Object	What it is	Who sets it
Calling AE title	The identifier your PACS presents when it opens the association	You, and you tell the provider
Called AE title	The identifier of the provider's receiving node	Provider, and they tell you
Host and port	The address your PACS sends to, typically a hostname so the provider can move hardware without breaking your route	Provider
Network path	Firewall rule permitting outbound traffic on that port to that host	You

The provider whitelists your calling AE title and your source address on its end. If either doesn't match what your PACS presents on the wire, the association is rejected. That mismatch, not bandwidth, is the most common cause of a failed first test.

Transport security. PHI leaving your network travels encrypted, full stop. The transmission security standard at 45 CFR 164.312(e)(1), published by the Department of Health and Human Services as part of the HIPAA Security Rule and codified at 45 CFR 164.312, requires technical measures that guard electronic protected health information against unauthorized access while it moves over an electronic communications network, with encryption named as an addressable implementation specification underneath it. Two accepted patterns exist: TLS on the DICOM association itself, or a site-to-site VPN tunnel with plain DICOM inside it. Either satisfies the requirement; pick whichever your security team already operates. That citation is the one to paste into your security review, because it names the standard your reviewer is testing against. AstraRad's handling of PHI in transit and at rest is documented on the compliance page.

Where latency matters. Transfer latency affects how long a study takes to arrive: seconds to a couple of minutes for a large CT on a business-grade connection. It has no effect on the radiologist's viewing experience, because the study transfers once and the reader works from a local copy on a diagnostic workstation. Latency becomes a problem in the opposite architecture, where remote readers log into your PACS over a tunnel and the experience degrades the further they sit from the access point. Sending studies out avoids that entirely.

Bandwidth, concretely. A routine chest X-ray study is a few megabytes, a multiphase CT can be several hundred, and a 100 Mbps outbound link is comfortable for most imaging centers. Compression policy matters more than raw bandwidth: send the full diagnostic series. Lossy compression to save transfer time is a false economy on a study a physician is about to sign their name to.

How long does a DICOM route take to stand up?

A DICOM route stands up in one to three weeks at most facilities, and nearly all of that elapsed time is a firewall change request sitting in a queue. The configuration work itself is a few hours spread across two teams. The table names every object, who owns it, and how long that piece honestly takes.

Step	Owner	Typical elapsed time
Firewall rule permitting outbound traffic to the provider host and port	Client	2 days to 3 weeks, your change process governs
PACS destination entry and routing rule	Client	1 to 2 hours
Calling AE title decided and sent to the provider	Client	Minutes, once someone settles on the string
Called AE title and receiving node assigned	Provider	Same day
Port assignment and hostname published to you	Provider	Same day
TLS certificate installed on the receiving node, or VPN tunnel built	Provider, with your network team on the VPN option	1 to 3 days
DICOM association test against a test study	Both, on a scheduled call	1 hour once the path is open
First live study sent and confirmed on the provider worklist	Both	Same day as the association test

Two rows cause most of the delay. The firewall rule is the one your team does not fully control, so submit it the day AE titles are exchanged instead of holding it until everything else is ready. The TLS certificate is the one people forget has an expiry date: put the renewal in the same change record, because an expired certificate on a DICOM listener presents as a route that worked for a year and then stopped overnight, with no configuration change to explain it.

Whatever that elapsed time turns out to be at your facility, portal upload covers the gap. Studies move on day one while the route is still in a queue, which is why nothing on this page puts clinical coverage behind a firewall ticket.

Preventing patient ID and accession collisions

Collisions are prevented by qualifying your MRN with its issuer, namespacing every incoming study by source facility, and routing demographic mismatches to a human for reconciliation. Here's why all three matter. Your MRNs and accession numbers are unique inside your institution. They stop being unique the moment they land at a provider reading for hundreds of facilities. Two facilities both numbering accessions sequentially will collide within days. A collision at the identity layer means one patient's study can merge into another patient's record, and every downstream safeguard, from prior comparison to critical-results callback, then operates on the wrong chart. Nothing in your PACS configuration prevents it; prevention lives entirely on the provider's side. That's why an experienced auditor probes this first, and why it's almost never addressed on vendor integration pages.

A competent provider uses all three mechanisms:

1. Issuer of Patient ID. DICOM tag (0010,0021) qualifies the patient ID with the institution that issued it. Populated correctly, it makes your MRN globally unique without changing it.
2. Per-facility namespacing on receipt. The provider tags every incoming study with the source AE title and facility identifier, and treats identity as the tuple of facility plus MRN.
3. Human reconciliation on mismatch. When demographics fail to match an existing record, the study routes to a reconciliation queue for a person to resolve. Auto-merging on a partial match is how one patient's history ends up in another patient's report.

Ask any provider you're evaluating to explain which of the three they use. The answer tells you a great deal about their operational maturity, which is one of the qualification questions in how to choose a teleradiology company.

Getting results back: HL7, FHIR, or portal

Finalized reports return through one of three channels: portal retrieval, an HL7 ORU result message, or a FHIR DiagnosticReport. They're ordered here by integration effort, lightest first.

Channel	What you build	Where the report lands
Portal retrieval	Nothing	Provider's web portal, downloadable as PDF
HL7 ORU^R01	An inbound interface in your engine	Directly into RIS or EHR as a result
FHIR DiagnosticReport	An API endpoint or subscription	Into a modern EHR as a structured resource

HL7 ORU results interface

An HL7 ORU results interface is still the workhorse of report return in US imaging, and most RIS and EHR systems already accept an ORU^R01 result message. The provider sends it, your interface engine receives it, and the report files against the right order. The field that makes this work is the placer or filler order number carried in OBR, which is why the accession number your PACS sends outbound has to be the one your RIS expects back.

If you also send an ORM or OMI order message outbound, the round trip closes cleanly and the report matches its order automatically. Without one, the provider matches on accession, which works reliably as long as accessions are stable.

Three things get agreed in writing before the first live result: the message type, the endpoint and port it is delivered to, and the acknowledgement behavior when your engine is unavailable. The third is where interfaces fail quietly. An interface that drops a message on a failed ACK loses a signed report, and nobody finds out until a clinician goes looking for it.

FHIR DiagnosticReport return

A FHIR DiagnosticReport return delivers the signed report as a structured resource with the report document attached, which is cleaner to build than an HL7 interface and easier to test. It's the direction most new integrations take where the EHR supports it.

Your side exposes an endpoint or a subscription, the provider posts the resource against the order, and the attached document carries the signed narrative your clinicians read. AstraRad supports HL7 and FHIR. Test a DiagnosticReport with the same discipline you would apply to an HL7 interface: push one signed report through to the correct queue and the correct ordering provider before production routing is enabled.

The destination system is your EHR, reached through the standard. ORU^R01 and DiagnosticReport are published interoperability standards, so a conforming receiver files a conforming message. In US imaging that receiver is usually Epic, Cerner, Meditech, or Athena, and it is reached through the interface engine or API gateway your organization already runs. AstraRad sends the standard message to the endpoint you expose. We hold no certified integration, no partnership, and no app-store listing with any EHR vendor, and none is required for an ORU result or a DiagnosticReport to land against the right order. What that means for your build: the work is a message mapping exercise your interface analyst has done before, and it is measured in days, with the endpoint, the message type, and the acknowledgement behavior agreed in writing before the first live result moves.

Portal retrieval is a legitimate permanent answer. The report is the same signed final report, delivered against the same service level, timestamped against the same SLA. Small imaging centers and urgent care groups run this way for years, because building an interface would cost more than it saves. If interface work is what's blocking you from getting coverage, skip the interface and take the coverage.

Prior studies and why they change the report

A radiologist reading a follow-up chest CT without the prior is doing a different, worse job than one reading it with the prior. Stability is the single most valuable finding in a large share of oncologic and chest imaging, and stability can only be assessed against a comparison.

Priors reach the reader three ways:

• Sent with the current study. Configure your PACS routing rule to include relevant priors when it forwards, either automatically by body part and modality or by a technologist attaching them.
• Fetched on request. The reader flags that a prior is needed, and your PACS admin or technologist sends it. This costs turnaround time, sometimes a lot of it on nights and weekends when nobody is available to send.
• Query/retrieve access. You permit the provider's node to C-FIND and C-MOVE against your PACS for that patient. This is the best clinical outcome and the largest security conversation.

The pragmatic default is to push relevant priors alongside the current study for any modality where comparison matters: CT, MRI, mammography, and PET-CT. It costs a routing rule and some bandwidth, and it removes the most common cause of a report that hedges when it didn't need to.

What your PACS administrator still owns

Three tasks land on the PACS administrator's desk, and none of them requires software, a schema mapping, or a consultant. You're configuring standard DICOM and standard HL7, which your systems already speak.

• A firewall change request, which in a hospital may take longer than everything else combined.
• A destination entry and a routing rule in the PACS, scoped by modality, ordering location, and priority.
• Verifying the accession and MRN your PACS actually presents on the wire, which is sometimes a surprise to the people who run it.

Everything else on the go-live list belongs to somebody outside the server room, and each item should be assigned by name in the same week: the inbound interface if you want reports filed into your RIS or EHR automatically, a written downtime procedure naming portal upload as the fallback and the number to call at 2 am, your own credentialing and clinical governance work, and a signed business associate agreement. The BAA is not optional paperwork: 45 CFR 164.308 permits a covered entity to let a business associate create, receive, maintain or transmit electronic protected health information on its behalf only once it has obtained satisfactory assurances that the information will be appropriately safeguarded. Budget the firewall ticket and the interface build honestly. Everything else is measured in hours.

A PACS integration go-live checklist

The realistic sequence runs from signed agreement to reconciled production traffic in nine stages, and portal upload can begin on day one regardless of where the DICOM work stands. Stages 3 to 5 are the DICOM route broken out object by object in the owner table above; the stages below place that work inside the whole engagement.

Stage	Task	Typical elapsed time
1	Request rate card and confirm modality mix and volume	Within 1 business day
2	Portal access provisioned, first study uploadable	Same day
3	Exchange AE titles, hostname, port, security model	1 to 2 days
4	Submit firewall change request	2 days to 3 weeks, your process governs
5	DICOM association test with a test study, both directions verified	1 hour once the path is open
6	Send 5 to 10 live studies, verify demographics and accession on the provider side	1 day
7	Result route: portal only, or build the HL7 or FHIR interface	0 days, or 1 to 3 weeks for an interface
8	Enable production routing rules by modality and priority	1 day
9	Run 2 weeks, reconcile every report against every study sent	2 weeks

Stage 9 is the one people skip. Reconcile sent studies against returned reports for the first two weeks and you'll catch the one routing rule that quietly excludes a modality. Skip it and you find out from a clinician.

Before you enable production routing, confirm two things. First, that the radiologists signing your reports are licensed in the state where your patients are located, which 42 CFR 482.22 states outright for hospitals whose patients receive telemedicine services. Second, that the turnaround tiers in your agreement match how your facility runs overnight. AstraRad routes each study to a fellowship-trained subspecialist who signs the final report, holiday nights included. The protocols on this page are standard, and your PACS already speaks every one of them. The only step that deserves ceremony is the association test: a route you've tested is infrastructure, and a route you've assumed is a missing report.

PACS integration for teleradiology is a configuration job with a known shape, and the timeline belongs to your firewall queue more than to any vendor. To set up a test association or get pricing for your facility, book a coverage consultation. The rest of the onboarding and integration guides live in the teleradiology resource library.