Teleradiology PACS and HL7

Short answer: MiniPACS has no HL7 interface of any kind. No ORM order feed in, no ORU results feed out, no interface engine. If your teleradiology workflow has to exchange orders and results with a hospital RIS or EHR, you need an HL7-integrated enterprise platform, the category where Ambra and Intelerad operate, and MiniPACS is the wrong product. At single-clinic scale, the two jobs HL7 usually performs are handled inside standards MiniPACS does speak: the signed report travels inside the DICOM study itself as an Encapsulated PDF, and referral intake runs through Vendo, which is FHIR-native. This page lays out both cases so you can tell which one you are in.

What HL7 does in a teleradiology workflow

HL7 v2 is the messaging standard that wires healthcare information systems together, and in imaging it mostly does two jobs. Inbound, an ORM order message tells the imaging side that an exam has been ordered: the order is placed in the RIS or EHR, the message crosses an interface engine, and the receiving system creates the expected exam and populates the modality worklist so the technologist selects the booked patient instead of retyping demographics. Outbound, an ORU results message carries the signed report back the other way, so the referring physician finds it in the chart where the order was placed.

In a hospital teleradiology chain both feeds matter. The reading platform learns what is coming before the study arrives, matches images to orders, and posts results back into each facility's record system when the radiologist signs. An interface engine sits in the middle of all of it, translating each system's HL7 dialect, and it is monitored infrastructure in its own right. For the broader picture of how the order side and the image side split between two systems, see RIS vs PACS.

Who genuinely needs it

• Hospital RIS and EHR integration. When orders originate in the hospital EHR and results must post back to the chart, HL7 is not optional plumbing, it is the requirement. A reading workflow that cannot consume ORM and emit ORU does not connect to that world.
• Multi-facility order routing. A reading group covering many hospitals, each with its own RIS and its own HL7 dialect, needs a platform whose job is to normalize those feeds, route orders to the right reader, and return each result to the right chart.

Here is the honest part: MiniPACS has no HL7 interface of any kind and is not the fit for either case. Not a partial one, not a roadmap one, none. If you are buying for a hospital or a multi-facility reading operation, the enterprise players built around HL7-integrated workflows, Ambra, now part of Intelerad, and Intelerad itself being the commonly named examples, are the right category, and you should evaluate inside it. Nothing below changes that answer.

The same two jobs, without an interface engine

At single-clinic scale the calculation is different. An independent imaging center, an urgent care, or a mobile X-ray operator sending studies out for remote reading, the setups described in what is teleradiology, has the same two underlying needs, results delivery and order intake, but no hospital RIS on the other end of a feed. MiniPACS handles both inside standards it does speak:

• Results ride inside the study. The signed report is rendered as a DICOM Encapsulated PDF, SOP class 1.2.840.10008.5.1.4.1.1.104.1, and stored in the study itself. It travels on the same C-STORE transfer as the images, so any DICOM node that receives the study receives the report, and any viewer that opens the study opens the report. There is no second results channel to reconcile against the archive, because the archive is the channel.
• Ordering goes through Vendo instead of an ORM feed. Referring offices submit orders and book slots in a portal rather than faxing, and Vendo is FHIR-native, built on Medplum, so order data lives in a current healthcare standard instead of piped v2 messages. That is portal intake, not an interface feed, and it is described honestly in referral management software.
• There is no HL7 feed to break. The classic failure in interfaced imaging is the patient standing at the desk while the scheduled exam is missing from the worklist, because the HL7 feed hiccuped overnight and nobody noticed until a human hit the gap. An interface engine is a monitored moving part; at single-clinic scale, removing the interface removes that entire failure class.

None of this makes HL7 bad. It makes HL7 a hospital-scale tool, and duplicating it at one clinic means running hospital-scale infrastructure to move data between systems that could have shared a standard in the first place.

The transport story teleradiology actually runs on

Strip away the messaging layer and teleradiology is a transport problem: studies out to a reader, reports back, nothing exposed to the internet that does not need to be. This is where a DICOM-native system earns its keep:

• Browser reading from anywhere. The radiologist opens the worklist and viewer in a browser over an outbound-only tunnel. The server dials out; nothing dials in, and no inbound port waits on the public internet.
• C-STORE in and out, engineered for real networks. Sends are preceded by a C-ECHO pre-test, run as asynchronous jobs, and retry on failure rather than silently dropping a study. For what those services are, see DICOM server.
• DICOM TLS. Peer-to-peer DICOM connections can run encrypted rather than trusting the wire.
• A zero-inbound gateway for remote sites. A small agent at the remote site receives C-STORE from local equipment on the LAN, relays studies over outbound HTTPS to the central server, and delivers studies back to local nodes via C-STORE. No VPN, no port forwarding, no firewall exceptions at the site.
• Signed reports with addenda. Reports are signed, and corrections land as addenda rather than silent edits.
• Critical results with acknowledgement. A critical finding can go out by email with a tokenized acknowledgement link, so the sending side can see who confirmed receipt and when.
• Share links with expiry, PIN and QR. Studies can be shared outward under links that expire, require a PIN, and open from a QR code, instead of burning discs.

This is not a paper design. Production MiniPACS archives have moved millions of images over exactly this C-STORE path.

HL7-integrated platform vs DICOM-native, honestly

Both columns are real, and the table is a fork, not a ranking. The left column is the correct answer for hospital-connected work, and no amount of DICOM elegance substitutes for an ORU message a hospital chart requires. The right column is the correct answer when there is no chart to post to, and paying for an interface engine would mean maintaining a feed with nothing on the other end.

Where that leaves you

Ask one question first: does a hospital RIS or EHR need to send you orders or receive your results over HL7? If yes, shortlist inside the HL7-integrated enterprise category and do not look back. If no, you are a single clinic or a small reading setup, and the DICOM-native path gives you the same outcomes with fewer moving parts and an archive you own; how that ownership model works is covered in self-hosted PACS. MiniPACS is $300 per location per month flat, billed yearly, or $640 per location per month together with Vendo, with no per-study fees. For a live demo you can click through and the full pricing picture, see the landing.

FAQ