HL7 ORU or FHIR: how signed reports reach your EHR

Somewhere in the last integration meeting, someone said that HL7 version 2 is legacy and FHIR has replaced it. That is the most repeated wrong fact in radiology integration, and it is wrong in the expensive direction. HL7 v2 is still how the overwhelming majority of radiology results move between systems in the United States, the message is an ORU^R01, and FHIR runs alongside it for a different set of jobs. Believe the replacement story and you scope an API project your EHR vendor has not scheduled, while the interface engine down the hall has been accepting outside result messages for fifteen years. The actual answer is short. A signed teleradiology report reaches your EHR as an HL7 ORU^R01 result message, as a FHIR DiagnosticReport exchanged over an API, or as a PDF retrieved from a secure portal. All three file the report where clinicians already look, and none of them installs a viewer.

This page is written for the person who owns the interface engine and for the person who has to tell a committee how long teleradiology HL7 FHIR integration will actually take. It names the message, the segments, the fields that break, who owns each one, and what a teleradiology vendor can honestly commit to about a system it does not run.

How does a signed teleradiology report get into your EHR?

It arrives as a result, filed against the order it belongs to, in the same lane your outside lab results already use. Three transports carry it: an HL7 ORU^R01 message into your interface engine, a FHIR DiagnosticReport exchanged over an API, or a PDF downloaded from a portal and attached by a person. Everything else here hangs off that choice.

Route	What you build	Where the report lands	Typical analyst effort
Portal retrieval	Nothing	Vendor portal, downloadable as a PDF, attached to the chart by staff	Hours
HL7 ORU^R01	An inbound interface, a listener, and a field mapping in your engine	Filed against the order in your RIS and EHR	1 to 3 weeks, spread across your queue
FHIR DiagnosticReport	An endpoint, credentials, and a subscription or scheduled pull	Into the EHR as a structured resource with the signed report attached	Comparable, with more coordination on the EHR vendor's side

You can change your mind later, and most facilities should plan to. Portal retrieval starts the week you sign and proves the clinical relationship works before anyone spends political capital on an interface slot. The interface gets built in parallel and cuts over when per-study handling time exceeds the build cost. Facilities running low or irregular volume often never leave the portal. That is a legitimate permanent answer, and it is not a stalled project.

One boundary worth naming early: none of these routes changes where images live. Studies leave your PACS by DICOM send or portal upload, which is a separate configuration with a separate owner, covered in detail in how your PACS connects to a teleradiology provider. Images out, report back. Two directions, two builds, and they can be sequenced independently.

HL7 ORU: the message your RIS already knows how to accept

ORU^R01 is the HL7 version 2 observation result message. It has carried radiology results since before anyone used the word interoperability in a budget meeting, and your engine almost certainly processes hundreds of them a day from reference labs. A teleradiology report is one more inbound result feed, built the way you have built every other one.

Six segments do the work.

Segment	Carries	Why it matters for a radiology result
MSH	Sending application and facility, receiving application, message type, control ID	Your engine routes on these. A wrong MSH-4 files a report under the wrong site in a multi-facility client
PID	Patient identifier list, name, date of birth	PID-3 carries your MRN with its assigning authority. Without the authority, the identifier is only unique inside your building
PV1	Patient class, visit number, attending and referring provider	Decides whether the result posts to the ED encounter or an outpatient one, and who gets the in-basket notification
ORC	Order control code, placer and filler order numbers, ordering provider	Ties the result back to the order and to the physician waiting on it
OBR	Universal service ID, accession, observation date, result status, principal interpreter	The spine of the result. OBR-4 is the procedure, OBR-25 is the status, and the interpreter field is where the signing radiologist appears
OBX	The report text itself, in repeating segments	Clinical history, technique, comparison, findings, and impression arrive here as formatted text

Result status is the field people underestimate. OBR-25 and OBX-11 both carry status codes, where F marks a final result and C marks a correction to a result already sent. If a vendor sends preliminary interpretations, you receive a P first and an F later, and your engine has to supersede the first with the second in a way your EHR displays correctly. AstraRad has no preliminary tier, so the first message you receive is already F and signed. That difference matters more to your build than it sounds, and the clinical side of it is laid out in STAT, preliminary, and final reads.

Transport is boring and should stay that way. Messages move over MLLP inside a site to site VPN tunnel, or over MLLP with TLS. Your engine acknowledges each one with an ACK, and an unacknowledged message queues and retries. Every one of those mechanics already exists in your environment, which is exactly the point.

The order round trip closes the loop. If your system sends an outbound order message, either an ORM^O01 or the imaging-specific OMI^O23, the returning result matches its order automatically on the filler order number. Without an outbound order, the vendor matches on accession alone, which works reliably as long as your accession numbers are stable and unique. Decide which model you are running before the first test message, because retrofitting order matching after go-live means reprocessing everything already filed.

FHIR DiagnosticReport: the same report, addressable by API

A FHIR DiagnosticReport carries the identical signed report as a structured JSON resource your EHR can read, reference, and render. Nothing clinical changes. What changes is that the report becomes addressable by URL, versioned explicitly, and testable with the same tools your team uses for every other API.

Element	Value for a radiology report	Notes
status	final, later amended	The direct analogue of OBR-25
category	RAD	Separates imaging results from laboratory results
code	LOINC code for the study performed	Your EHR usually maps this to its own procedure master
subject	Reference to a Patient resource	Resolved by identifier plus the system that issued it
encounter	Reference to the Encounter	Drives where the result posts and who is notified
effectiveDateTime	When the study was acquired
issued	When the report was signed	The timestamp your turnaround measurement should use
performer	The signing radiologist and the practice
conclusion	The impression, as text
presentedForm	The signed report as an attachment	Base64 PDF or plain text
imagingStudy	Reference to the ImagingStudy	Links the report to the images it describes

The federal standards work has caught up with imaging here, which is useful leverage when you are asking an EHR vendor for a build slot. The ASTP/ONC United States Core Data for Interoperability page for Diagnostic Imaging defines a Diagnostic Imaging Report data element as the "interpreted results of imaging test that includes the study performed, reason, findings, and impressions," including both structured and unstructured narrative components. That is your radiology report, named as a required data class rather than an optional extra.

On the certification side, the Standardized API for patient and population services test method for 45 CFR 170.315(g)(10) requires conformance to the HL7 FHIR US Core Implementation Guide, and the certification companion guidance names the US Core DiagnosticReport Profile for Report and Note Exchange explicitly. Read the criterion carefully before you plan around it. That certified API is a read interface exposing data your EHR already holds. Accepting an inbound DiagnosticReport written by an outside practice is a separate capability your EHR vendor may or may not enable, and it is the single question that decides whether a FHIR route is weeks of work or a change request with no delivery date. Ask your EHR representative that exact question before you ask any teleradiology vendor anything.

HL7 or FHIR: which one should you ask for?

Ask for whichever one your interface engine runs in production today. For most US hospitals and imaging centers that is HL7 v2, because the engine, the mapping conventions, the error queue, and the analyst who can read a raw message all exist right now. Ask for FHIR when your EHR team already supports an inbound write path.

	HL7 v2 ORU^R01	FHIR DiagnosticReport
Install base in US imaging	Nearly universal	Growing, uneven by EHR and by version
Who builds it on your side	Interface analyst, on a platform they know	Interface analyst plus EHR vendor engagement
Testing	Send a message, watch the queue, read the ACK	HTTP status codes and JSON, easy to script and repeat
Error visibility	The message sits in a queue your team already monitors	Depends entirely on how the endpoint reports failures
Attachments	Report text in OBX, PDFs handled by convention	presentedForm handles attachments natively
Versioning of corrections	Status codes and local convention	Explicit resource versioning
Cost of a later change	Remap a field, redeploy the interface	Usually a smaller change, sometimes a vendor ticket

FHIR genuinely wins on testability. A developer can exercise a DiagnosticReport endpoint from a laptop in an afternoon, and the failure messages are readable by someone who has never seen a pipe-delimited message. HL7 v2 wins on the thing that decides most projects: it works today, on a platform you already own, without a third party's roadmap in the critical path. Both carry the same signed report from the same radiologist, so the standard is a delivery decision, and the clinical product is unchanged either way. Plenty of facilities run both, HL7 for results into the RIS and FHIR for a downstream analytics or patient-access consumer.

Five fields that have to agree, or the message rejects

Interface builds fail on identity and matching far more often than they fail on transport. Five fields do almost all the damage.

What has to agree	HL7 v2 location	FHIR location	Failure when it disagrees
Patient identifier and issuing authority	PID-3	Patient.identifier.system and .value	The report files to no chart at all, or to the wrong one
Order number or accession	ORC-2, ORC-3, OBR-2, OBR-3	DiagnosticReport.basedOn to ServiceRequest.identifier	The result orphans and lands in an error queue nobody watches overnight
Procedure code	OBR-4	DiagnosticReport.code	The report posts under the wrong study name and breaks prior comparison
Result status	OBR-25 and OBX-11	DiagnosticReport.status	A correction duplicates the original instead of superseding it
Sending facility	MSH-4	performer and the linked Organization	A multi-site client cross-files reports between its own locations

The accession is where most go-lives actually break, and it deserves the full walkthrough. Your PACS sends a study outbound carrying an accession number generated by your RIS. The vendor receives that study, reads it, signs a report, and returns an ORU quoting the accession back in OBR-3. That round trip only closes if the accession your PACS puts on the wire is the same string your RIS expects to receive, and in a surprising number of shops it is not, because a modality worklist, a broker, or a decades-old prefix convention has been quietly rewriting it since before anyone currently employed arrived. The mismatch never shows up in the DICOM test, because the study transfers perfectly. It shows up on the first live report, which files nowhere, sits in an error queue, and gets noticed when a clinician calls asking where the result went. The fix is nearly always trivial once found, either a mapping rule in the engine or a configuration change on the sending side. Finding it is the expensive part. So verify what your PACS actually sends, on the wire, with a real study, before you build anything on top of the assumption. One captured message on day one saves a week of debugging in production.

What a teleradiology vendor can and cannot promise about your EHR

A vendor can promise the message it sends, the fields it populates, the values it uses, the test cycle it will run with you, and the person who answers when a message rejects at 3 a.m. It cannot promise behavior inside a system it does not run, and any vendor that does is either confused or selling.

What a teleradiology vendor can commit to in writing:

• A conformant ORU^R01 or FHIR DiagnosticReport built to your specification, with every populated field documented.
• A sample message generated from your own study types, before you commit analyst time.
• A non-production endpoint, credentials, and a named engineer available during your build window.
• The result status codes it will use for finals and for corrections, and how addenda reference the original.
• Turnaround measured to the signature, which is the issued timestamp in FHIR and the observation timestamp in HL7. AstraRad's tiers are STAT under 4 hours (2-hour and 1-hour STAT on request at a higher multiplier), routine 24 to 48 hours, and stroke protocol under 30 minutes, measured from last-image arrival to radiologist signature, and both the tiers and the measurement method sit on the SLA page.

What no teleradiology vendor can commit to:

• How your EHR renders the report. Epic, Cerner, Meditech, and Athena are destination systems that accept an inbound result, and what happens after the message is accepted belongs to your build and your display rules.
• Your interface engine's configuration, your firewall change process, or your EHR vendor's project queue.
• A certified integration with a named EHR. Certification programs apply to health IT modules, not to reading practices, so treat that phrase as a claim to verify. Our guide to verifying teleradiology vendor claims has the question set.

We hold this line about our own posture too, which is worth stating because the alternative is an unpleasant discovery during security review. AstraRad is HIPAA aligned and operates as a business associate under a signed BAA, with controls built to the HIPAA Security Rule safeguard categories and DICOM conformant transfer. AstraRad holds no SOC 2 attestation, no ISO 27001 certificate, no HITRUST certification, and no Joint Commission accreditation, and says so plainly. AstraRad also performs no AI pre-read, no AI triage, and no AI-drafted report text, and no client image trains any model. A fellowship-trained subspecialist reads the study and signs the report. The full documentation set is on the compliance page, and the things we decline to claim are listed on the facts page.

Going live without an interface project

The claim that teleradiology needs no integration project is accurate and narrower than it sounds. Nothing installs at your facility, nothing replaces your PACS, no proprietary viewer reaches a clinician's desktop, and no schema needs mapping to a private format, because DICOM in and HL7 or FHIR out are standards your systems already speak. What remains is real work with real owners.

Stage	Task	Owner	Typical elapsed time
1	Portal access provisioned, first study uploadable and readable	Vendor	Same day
2	Exchange interface specification and a sample message built from your study types	Both	1 to 2 days
3	Confirm what your PACS sends on the wire: accession, MRN, assigning authority	You	1 hour with a captured study
4	Decide the route: portal only, HL7, or FHIR	You	Depends on your queue, and it is reversible
5	Build the inbound interface and map the five fields above	You	1 to 3 weeks of analyst time
6	Test finals, corrections, and a deliberately malformed message	Both	2 to 3 days
7	Enable production, then reconcile studies sent against reports received	You	2 weeks

Stage 7 is the one that gets skipped, and it is the one that catches the routing rule quietly excluding a modality. Reconcile for a full two weeks. Stage 6 deserves the same discipline: test a correction and a bad message on purpose, because both will happen, and the time to learn how your engine behaves is not the night it happens for real.

Sequencing matters more than speed. Portal delivery gives you coverage on day one while the interface waits for a build slot, which decouples a clinical decision from an IT calendar. AstraRad commits to a first signed report within 10 business days of countersignature on that basis, and the onboarding commitment is dated on the same SLA page as the turnaround tiers. If you are replacing an incumbent, the interface question shifts slightly: the engine work is usually a new inbound feed beside the old one, run in parallel until reconciliation is clean, which is the pattern described in switching teleradiology providers. The full onboarding sequence, including credentialing and routing, is on how we work, and the reading side of the arrangement is on subspecialty teleradiology services.

Integration is the easiest part of a teleradiology decision and the part that gets the most meeting time, which is backwards. The protocols are settled, your systems already speak them, and the only steps that deserve ceremony are verifying what your PACS actually sends and testing what happens when a correction arrives. Everything else is configuration. When you are ready to scope it, tell us which interface engine you run and you will have a sample message built from your own study types to hand your analyst.