Pular para o conteúdo principal

Orders, Reports and Interfaces (HL7)

Problems with orders and reports crossing between OmegaAI and connected systems - your EMR/HIS (Epic, Athena, and others), reporting systems, and fax/distribution. Interface fixes usually require RamSoft, so these entries focus on what you can check first and exactly what to collect so the fix is fast.

Tip: checking what OmegaAI supports

If you need to confirm which message types, fields, or DICOM services OmegaAI supports, the DICOM and HL7/FHIR Conformance Statements are published on the Resources page. These are the reference your EMR/HIS or modality vendor will usually ask for.

A report from our reporting system isn't attaching to the study​

Symptoms

  • Reports sent from a dictation/reporting system never appear on the study in OmegaAI
  • The interface shows the message was rejected

Likely causes

  1. Two studies exist with the same accession number in OmegaAI - inbound report processing fails when the accession is ambiguous. This is the most common self-servable cause.
  2. The sending system used a slightly different accession or patient identifiers than the order
  3. An interface fault (needs RamSoft)

What to try

  1. Search OmegaAI by the accession number. If two studies share it, merge the duplicate first: select both study cards in the main Worklist grid (they must belong to the same patient and the same managing organization) and right-click Link & Merge > Merge Studies - this only appears if your role has the Merge/Unmerge Studies permission, it's a manual action you take, not something OmegaAI flags for you automatically. If the option doesn't appear, check that permission with your administrator, or contact RamSoft Support to merge them manually. Then ask support to reprocess the report message.
Patient safety: verify before you merge

Before merging, confirm the patient name, date of birth, and a third identifier (Patient ID, address, or phone) all match. Merging combines all series, measurements, and reports into a single record, and there is no self-service undo, unwinding a wrong merge requires RamSoft and may not restore everything downstream.

  1. Confirm the report's accession exactly matches the order's.
  2. If no duplicates exist, contact support with the accession number and the approximate send time. RamSoft can check the interface engine logs for the rejection reason, these inbound logs aren't visible from within OmegaAI.

An order placed in the EMR never appears anywhere in OmegaAI​

Symptoms

  • An order placed in the EMR/HIS doesn't show up in OmegaAI at all, not in the Worklist and not in a global search - this is different from the order existing but not reaching the modality worklist (see below)
  • Only some order types, locations, or departments are missing while others come through fine

Likely causes

  1. The inbound HL7 ORM message was never sent by the EMR/HIS for that order
  2. The ORM message arrived but failed field mapping (for example, an unrecognized location, procedure code, or provider) and was rejected before OmegaAI created the order
  3. An interface fault on the inbound channel (needs RamSoft)

What to try

  1. Ask your EMR/HIS team to confirm the ORM message was actually generated and sent for that order, including the exact time it was sent.

    Note: the in-app HL7 log will not help here

    OmegaAI's built-in HL7 log shows outbound messages only. Inbound messages from your EMR/HIS (including orders that were rejected on arrival) do not appear there, so an order being absent from that log tells you nothing about whether it reached OmegaAI. Confirming inbound receipt and any rejection reason requires RamSoft to check the interface engine logs.

  2. Confirm with your EMR/HIS team that the fields OmegaAI expects (location, procedure code, provider) are populated on the message, an unrecognized value in one of these is a common rejection cause.

  3. Contact support with 2-3 example accession/order numbers, the order creation time, and your EMR/HIS team's confirmation that the ORM was sent, support can then check whether it arrived and why it was rejected.

Orders from the EMR aren't reaching the modality worklist​

Symptoms

  • The order already exists in OmegaAI, but it never shows up on the modality's worklist (MWL) - if the order isn't in OmegaAI at all, see the entry above instead
  • Orders from one location or department consistently missing while others work

Likely causes

  1. The modality queried the worklist before registration/order completion, or after an order change it hasn't refreshed
  2. The order was created under a different imaging organization than the modality queries (common with multi-site setups)
  3. An interface mapping issue (needs RamSoft)

What to try

  1. Refresh the modality worklist after the order is fully registered, and always after order changes.
  2. Check whether the missing orders share a pattern - same referring location, department, or procedure type. That pattern is exactly what RamSoft needs to diagnose the interface issue.
  3. Contact support with 2-3 example accession numbers, the order creation time, and the modality/location that can't see them.

"XR" studies or order sets behave unexpectedly (invalid DICOM modality)​

Symptoms

  • Order sets or studies using XR as the modality produce non-conformant objects or don't route correctly

Why: XR is not a valid DICOM modality. The DICOM standard uses CR or DX for X-ray; "XR" is fine as descriptive text in an order-set name, but not in the actual modality field.

What to do

  1. Use CR or DX in the modality field; keep "XR" only in the order-set description if you use it there.
  2. If a device is sending "XR" in the modality tag, RamSoft can apply a DICOM script to remap it on ingestion - report the sending station.

Reports aren't reaching the EMR ("Selected studies queued for distribution")​

Symptoms

  • Signed reports don't arrive in the EMR/HIS
  • Attempting to resend shows "Selected studies queued for distribution" and nothing else happens
Tip: check the scope first, it decides which problem you have

Before working through this entry, establish whether it's all reports or only some:

  • All reports, all physicians, all destinations - a stalled outbound queue, continue with this entry.
  • Only one physician's reports - most likely their NPI, not the interface. See A physician ended up as two separate accounts, a report can't transmit without the physician's NPI, and that case has a fix you can run yourself. If their NPI is present and correct in OmegaAI, ask the receiving side to confirm the physician is also set up in their systems (the EMR and any dictation/reporting system in between) - OmegaAI can be sending correctly, with the interface acknowledging delivery, while the report is dropped further downstream.
  • Only one destination - that destination's configuration rather than the queue.

Scope is the fastest discriminator here and it saves escalating something self-servable.

Where to look: select the studies in the Worklist, open the Send drawer, choose the Send Report tab, and send with the HL7 method. "Selected studies queued for distribution" appears as a confirmation message. It confirms only that the report entered the outbound queue - it does not confirm delivery.

If you don't see this message at all when resending, the send didn't start, which is a different problem from a stalled queue. Check that studies were actually selected, and that your role's User Type is set (a blank User Type disables a range of Worklist actions, see Worklist actions are missing).

What that message means: the report is sitting in the outbound interface queue. Delivery from that queue is handled by the integration layer - if the queue is stalled, resending from the UI adds it to the same stalled queue. This requires RamSoft.

Checklist: if you need to contact support, send this
  • 2-3 example accession numbers
  • The date range affected, and whether it's all reports or only some - one physician? one destination? one report type? (the scope is the biggest clue)
  • The destination system name (Epic, Athena, etc.)
  • When it started, and whether anything changed at your site around then (network, EMR, or an on-premise interface machine if you run one) - support checks the cloud/interface side

Once the interface is fixed, RamSoft can bulk-resend the backlog - confirm receipt on a couple of accessions afterwards.

Outbound faxes are failing​

Symptoms

  • Reports set to fax show failed delivery attempts
  • One recipient consistently fails while others work

Likely causes

The fax log shows a numeric error code and a short description for each failed item, and the description is the fastest clue. Most fall into three groups:

  • Something about the receiving line, wording such as busy, no answer, number not operational, call rejected, or a fax-machine incompatibility. These point at the recipient rather than at OmegaAI. 6017 (busy) is the most common of these and often clears on retry.
  • A generic telephony error, most often code 9951. This one does not identify which end failed, so don't treat it as proof the receiving office is at fault.
  • Quota, rendering, or internal errors, which are on RamSoft's side rather than the recipient's.

What to try

  1. Check the error code in the fax/distribution log for the failed items (left-side navigation panel > Logs; see OmegaAI's built-in logs).
  2. If the description points at the receiving line, contact the receiving office, confirm the fax number is correct and current, and ask them to check their machine.
  3. Otherwise, including 9951 and anything you can't place, contact support with the code, its description, the accession number, and the destination. RamSoft can look up the exact meaning.
  4. Once their line is fixed, ask support to bulk-resend the failed faxes if there are many.

Study statuses don't match between connected sites​

Symptoms

  • "Studies show Completed on our side but the reading group says they're Signed" (or vice versa)
  • Studies you expected to be sent automatically never went

Likely causes

  1. The studies genuinely haven't been read/signed yet at the other site - status sync is working, the work just isn't done
  2. Your Workflow Automation send trigger fires on a different status than you expect (for example, it sends on VERIFIED, but the studies sit in IMPORT or PRIOR status)

What to try

  1. Confirm with the other site what status the study is really in on their side before suspecting the interface.
  2. Review your Workflow Automation send rules: which status triggers the send, and do the studies in question ever reach that status? Your PACS administrator can add a Workflow Automation trigger for the status you actually use.
  3. Note: Send Study transmits whatever image objects currently exist on the study - if a workflow pulls priors and sends in the same automation, it can fire before the pulled images have actually arrived, so it won't work reliably; use two automations (one pulls, one sends on the resulting status). See Design rules worth knowing first for the full explanation.

Still stuck? Provide example accessions and both sides' expected vs actual statuses.