Teleradiology RIS integration: orders in, reports back

It is a little past seven in the morning and the overnight work is finished. Every study sent out last night came back signed by a subspecialist.

The reports exist. Your radiology information system does not agree.

The status column on the overnight list still reads "exam completed", because nothing ever wrote back to it. A hospitalist calls the front desk asking where the head CT result is. Someone opens a second browser tab, signs into the vendor portal, finds the PDF, prints it, and walks it upstairs.

It works. It also happens every single morning, it leaves no timestamp anyone can audit, and it parks a human being between a signed report and the clinician waiting on it.

Teleradiology RIS integration exists to delete that walk. It is two flows and one shared identifier: an order message going out so the provider reads with the right patient, priority, and clinical history, and an HL7 ORU^R01 result message coming back that files the signed report against the exact accession your RIS already issued.

Order entry stays yours. The worklist stays yours. The MRN stays yours.

This page is written for the person who has to specify and test that, which is usually an interface analyst, a RIS administrator, or an imaging director standing between the two. It names the message types, the fields that carry the identifiers, the status codes that drive your worklist, and the specific configuration mismatch that breaks more go-lives than every other cause combined.

What does teleradiology RIS integration involve?

Two HL7 interfaces and one identifier convention. Outbound: a copy of the order, so the provider knows the patient, the procedure, the priority, and the reason for the exam. Inbound: the signed report as an ORU^R01 result, filed to the accession your RIS issued.

Everything else stays exactly where it is today. That is the whole scope, and it is smaller than most vendor pages imply.

Your RIS is not being replaced, extended, or migrated. It is receiving a result feed from one more source, in the same message format it already accepts from the lab.

Layer	Who owns it after integration	What changes
Order entry and scheduling	You, in your RIS	Nothing
MRN and accession assignment	You, in your RIS	Nothing
Technologist worklist at the modality	You, in your RIS and PACS	Nothing
Image transport	Your PACS routing rule, outbound	One destination entry
Order data to the provider	Outbound HL7 order, or the DICOM header alone	New interface, or no interface
Signed report back	Inbound HL7 ORU or FHIR DiagnosticReport	New interface
Report status states	Your RIS, driven by the inbound message	Status updates stop being manual

The image side and the order side are separate builds, and they are commonly done by different people on your team. Images leave through your PACS, which is covered in detail in how your PACS connects to a teleradiology provider. Orders and results leave and arrive through your interface engine.

Confusing the two is the most common reason a project stalls in week one, because the PACS administrator and the interface analyst each assume the other one has it. Assign both owners in the same meeting.

One boundary is worth stating early. A report cannot file itself into a RIS that never knew the exam existed. If your outside reads are studies your RIS never had an order for, second opinions on outside films being the usual case, there is nothing to match against and portal retrieval is the correct answer for that stream.

The two flows: your order out, the signed report back

Outbound is an order message. Inbound is a result message. Both are ordinary HL7 version 2 traffic over MLLP, acknowledged in both directions, and both will be familiar to anyone who has built a lab interface.

Direction	Message	What it carries	Key segments
Your RIS to the provider	ORM^O01 or OMI^O23	Patient identity, procedure code, priority, ordering physician, reason for exam, accession	MSH, PID, PV1, ORC, OBR
Provider to your RIS	ORU^R01	Signed report text, result status, signing radiologist credentials, timestamps, accession	MSH, PID, OBR, OBX
Modern equivalent, out	FHIR ServiceRequest	The same order content as a resource	ServiceRequest, Patient, Encounter
Modern equivalent, back	FHIR DiagnosticReport	Report with the signed document in presentedForm	DiagnosticReport, Observation

The outbound order is optional and worth having anyway. Without it, the provider works from the DICOM header alone: patient name, MRN, accession, study description, and whatever the technologist typed into the study comments field.

That is enough to read a chest X-ray. It is thin for a follow-up MRI where the clinical question changes the report, and with an order message the reason for exam, the ordering physician, and the priority arrive as structured fields instead of a free-text guess.

Priority deserves a specific mention because it drives both turnaround and money. In an HL7 order, priority rides in ORC-7 or OBR-27 as S for STAT, A for ASAP, and R for routine.

If your RIS sends every exam as R because nobody ever mapped the field, your STAT head CT enters the provider's queue as a routine study, and both the clinical outcome and the invoice line are wrong. Map the priority field, then test it with a real STAT order before go-live. The difference between the tiers is spelled out in STAT, preliminary, and final reads.

The inbound result is where the report text lives. The narrative sits in one or more OBX segments, usually as TX or FT value type, split at a line length your RIS tolerates.

The signing radiologist's credentials ride in OBR-32, the principal result interpreter field. Timestamps ride in OBR-7 and OBR-22. Those four things, text, signer, status, and timestamps, are the entire deliverable of the inbound interface.

Accession numbers and MRNs: the field that breaks first

Everything above works or fails on two identifiers agreeing across three systems. Your RIS issues an accession number when the order is placed. Your PACS writes that accession into DICOM tag (0008,0050) on the study. The provider reads it from the header, carries it through their system, and echoes it back in OBR-2 or OBR-3 on the result message. If any hop in that chain alters the value, pads it, strips a prefix, or substitutes its own internal identifier, your RIS receives a report it cannot file. The best outcome is an error queue somebody checks. The worst outcome is a RIS configured to match loosely, which attaches a report to a different order and produces exactly the kind of event your safety committee writes a policy about afterwards. This is worth an hour of testing with real production formatting, including a study whose accession contains a leading zero and one whose MRN was recently merged. Almost nobody tests those two cases, and both of them fail in the field.

Patient identity has a parallel problem in the opposite direction. Your MRN is unique inside your institution and stops being unique the moment it lands at a provider reading for many facilities. Two hospitals both numbering from 1000000 will collide within days.

Identifier	Where it lives	The failure it causes
Accession number	RIS order, DICOM (0008,0050), OBR-2 and OBR-3	Report cannot file, or files to the wrong order
MRN	RIS, DICOM (0010,0020), PID-3.1	Two facilities' patients merge into one record
Assigning authority	PID-3.4, DICOM Issuer of Patient ID (0010,0021)	The qualifier that makes an MRN globally unique
Study Instance UID	DICOM (0020,000D)	Duplicate study creation on re-send
Placer order number	ORC-2, OBR-2	Round trip cannot close without an outbound order

Three practical rules follow. Populate the issuer field on both the DICOM and HL7 sides, which qualifies your MRN with the institution that issued it and costs nothing. Require the provider to namespace every incoming study by source facility, so identity is the pair of facility plus MRN.

Confirm that demographic mismatches route to a human reconciliation queue instead of auto-merging on a partial match. Those questions belong in the same conversation as the ones in verifying teleradiology vendor claims.

What changes for your technologists and your front desk?

Almost nothing at the modality, and two things at the desk. Technologists complete the study the way they always have, and the PACS routing rule fires on its own. The front desk needs to know where results now come from and what the downtime path is when the interface stops.

Your technologists keep their worklist, their protocols, and their completion step. No new application opens on the acquisition console, and nobody is asked to upload anything once the DICOM route is live.

The one habit worth reinforcing is completing the study promptly in the RIS. That completion timestamp is what your entire turnaround measurement will later be built on.

The front desk and the reading room see more change. Reports appear in the RIS on their own, which removes the print-and-walk step from the opening scene.

When somebody calls asking about a result, the answer is now the same answer as for any in-house exam: look at the order. Status states tell the truth without a phone call.

Then there is the part vendor pages skip. Interfaces stop: a certificate expires, a change window drops a firewall rule, an engine restarts and the listener does not come back. Write the downtime procedure before go-live and post it where the night staff can see it:

• Who notices: someone watching an error queue or an alert, with a named backup on nights and weekends.
• What the fallback is: portal retrieval, which works whether or not the interface does.
• Who to call: one contact on your side, one on the provider's, both with after-hours numbers.
• How the backlog gets filed: replay the queued messages once the path is restored, then reconcile against the studies you sent.
• How long you tolerate it: the threshold at which someone escalates instead of waiting for morning.

Facilities running overnight coverage should rehearse this once, at night, before they need it. The pattern is the same one described for nighthawk radiology coverage, where the interface failing at 2am and being discovered at 8am is a six-hour hole in results delivery.

Report status, addenda, and versioning inside the RIS

Two HL7 fields drive every status state your RIS displays for an outside read. OBR-25 carries the result status for the order, and OBX-11 carries the observation status for each result segment.

F means final, P means preliminary, C means corrected. Your RIS maps those to its own vocabulary, and that mapping is a decision your build team makes deliberately.

Where a provider sends preliminary overnight reads, your RIS receives a P message at 2am and an F message the following afternoon, and every downstream process has to handle the overwrite: the clinician who read the prelim, the billing trigger, the quality audit that now has two documents for one exam. AstraRad signs final reports on every study at every tier, including overnight, so the P stage does not exist and the first message your RIS receives is the last one it needs.

HL7 status	Meaning	What your RIS should do
OBR-25 = P, OBX-11 = P	Preliminary result	Display as preliminary, keep the order open
OBR-25 = F, OBX-11 = F	Final signed report	Close the order, release to the chart
OBR-25 = C, OBX-11 = C	Corrected report	Version the document, flag the change, notify the ordering clinician
OBR-25 = A, OBX-11 = A	Appended addendum	Attach as a new version, preserve the original

Corrections and addenda are the case worth designing for, because the default RIS behavior is often silent replacement. A finalized report is immutable at a competent provider, so a change arrives as a new versioned addendum in a fresh message, and the original stays intact and viewable.

If your RIS shows only the latest version with no indication that an earlier one existed, a clinician who acted on the first report has no way to learn that something changed. Configure it to keep both, and configure a notification on the corrected status.

That notification requirement is more than a preference. The ACR Practice Parameter for Communication of Diagnostic Imaging Findings sets out what a final report contains, clinical history, technique, comparison, findings, and impression, and it treats delivery to the ordering physician as part of the interpretation itself, with separate expectations for findings that suggest a need for immediate intervention and for findings discrepant with a preceding interpretation of the same examination.

The status states in your RIS are the evidence that those expectations were met. If your worklist says "final" and the ordering clinician never saw the report, that status state is documentation of a gap.

Auditing turnaround against your own RIS timestamps

Your RIS already holds both ends of the clock. The exam completion timestamp is the moment the last image was acquired and pushed, and the result filed timestamp is the moment the signed report landed. The interval between them is your turnaround, measured on your system, with no vendor reporting involved.

That distinction matters more than any number a provider prints. A vendor turnaround report is computed on the vendor's clock, from an event the vendor defines, and there is no rule requiring that event to be the one you care about.

Some clocks start when a study finishes transferring. Some start when a radiologist opens it. Once you can measure the interval yourself, the vendor's report becomes a cross-check on yours.

AstraRad publishes tiers of STAT under 4 hours, with 2-hour and 1-hour STAT available on request at a higher multiplier, routine 24 to 48 hours, and stroke protocol under 30 minutes, each measured from last-image arrival to radiologist signature, with the SLA methodology and measurement definitions published in full. That definition is deliberately close to what your RIS can reconstruct, which is the point. A measurement you cannot reproduce is a marketing claim.

Build the audit as a standing monthly report from your RIS:

1. Interval: result filed timestamp minus exam completed timestamp, per exam.
2. Segments: by priority, by modality, by shift, and by day of week.
3. Statistic: report the median and the 90th percentile together, because the mean hides the tail that generates complaints.
4. Exceptions: pull every exam past its tier and read the reports, since the cause is usually a missing prior or an incomplete order.
5. Reconciliation: count studies sent against reports received for the same window, which is how you find the routing rule that quietly excludes a modality.

Run that monthly and put it beside the provider's own figure. AstraRad's tiers are defined on the SLA page, and the useful version of any compliance number is the one where your report and the provider's describe the same population of exams.

Where they diverge, the reason is almost always definitional, and finding the definition is the whole exercise. Report content quality is a separate audit with a separate method, covered in how to run a radiology report quality audit.

Can we run teleradiology with no RIS interface at all?

Yes. Signed reports are retrievable from a secure portal as PDFs, and a coordinator files, prints, or attaches them. The report is the same report, read by the same subspecialist, delivered against the same turnaround commitment.

Thousands of facilities operate this way permanently and the clinical outcome is identical. What you give up is automation and evidence.

Every report passes through a person, which means it moves at the speed of that person's attention and stops entirely when they are off. Status states in the RIS stay manual, so the worklist tells you what somebody last remembered to update. The timestamp evidence for the audit described above never exists either, because the filed time records when a human uploaded a document.

	Portal retrieval	HL7 ORU interface
Build effort on your side	None	1 to 3 weeks of interface analyst time
Time to first live report	Same day	After a change window and testing
Who touches each report	A coordinator, every time	Nobody
RIS status updates	Manual	Automatic, driven by OBR-25
Auditable timestamps	Upload time only	Signature to file, per exam
Failure mode	Somebody forgets	Queue stalls silently until someone checks
Best fit	Low or irregular volume, trials, second opinions, backlog batches	Nightly coverage, ED volume, anything measured

The honest recommendation is sequential. Start on the portal the week you sign, because it proves the clinical relationship works before anyone spends political capital on a change request.

Build the interface underneath the live service once volume justifies it. Facilities clearing a one-time backlog frequently never build the interface at all, and they are right.

Both failure modes in that table are real, and the interface one is sneakier. A person who forgets to file a report notices by lunchtime. A stalled inbound queue looks exactly like a quiet night.

How AstraRad connects to the RIS you already run

We connect to the RIS you have. DICOM in from your PACS or a browser upload, HL7 or FHIR out to whatever receives results in your building.

If that is your RIS, the ORU lands there. If your electronic health record is the system of record, reports land in Epic, Cerner, Meditech, or Athena the same way any other result does, through a standard ORU^R01 message or a FHIR DiagnosticReport your integration team routes.

Every report we return is a final signed report with the reading subspecialist's credentials in OBR-32, matched to your study by modality and body part before interpretation begins. There is no preliminary stage, which removes an entire class of RIS reconciliation work: one message, one status transition, one document in the chart.

The step-by-step path a study takes is documented in how we work, and the study types and subspecialty routing are on the teleradiology services page. Neither requires anything to be installed at your facility.

On the governance side, the connection runs under a signed business associate agreement, with transport over TLS or a site-to-site VPN, encryption at rest, and an append-only audit log of every state change on a study. AstraRad is HIPAA aligned and DICOM conformant, and holds no SOC 2, ISO 27001, HITRUST, or Joint Commission certification, which we would tell you on the security review call anyway.

The full posture, including what we do not hold, is on the compliance page. Send it to your security reviewer before the first call and the review stops being the thing that delays go-live.

The interface specification is a document, and you can have it before you commit to anything. It names the message types we send, the fields we populate, the acknowledgment behavior, the test harness, and what we need from your side.

If you are moving off an incumbent, the sequencing questions are covered in switching teleradiology providers. The short version is that you keep both result feeds running in parallel until reconciliation is clean.

Start with the specification and a test message against your engine. To request the interface spec and a per-report rate card, use contact, and a complete rate card lands in your inbox within one business day.