Coordinate imaging bookings and report delivery without clinical automation
For Diagnostic/specialty operations director · Compare approaches
TL;DR — what you’ll learn
- Track the appointment, examination, report authorisation and delivery as separate events.
- A performed examination does not establish that a report is ready to send.
- Link each delivery attempt to the authorised report version and permitted recipient.
- Give released-but-undelivered reports an owner, age and next action.
An imaging appointment is marked complete at 11:10. The front desk sees a completed visit and tells the recipient that the report has been sent. The reporting queue still shows an unsigned document, while the delivery service has no attempt recorded.
Imaging workflow management needs separate states for booking, performed examination, authorised report and delivery. Link them through the order or accession reference, but do not use one completed flag to stand for all four. The administrative question is which event remains open and who can resolve it.
Build a chain of records rather than a single status
For this administrative model, keep booking, performed examination, authorised report version and delivery as separate source references. Ask radiology, operations and the system owner to identify the actual authority and event behind each. The coordinator may follow an open handover; the guide gives neither the booking system nor the delivery service permission to release a report.
Bahmni describes imaging orders and DICOM viewing. Those features are narrower than report authorisation and recipient delivery. Request separate evidence of supported release/version events, correction links and delivery results in the proposed RIS/PACS connection. Keep delivery integration disabled where that evidence or authority is unresolved.
The minimum coordination record connects the booking ID, order/accession, current examination state, report version, release reference and delivery task. Avoid copying the report contents into every administrative screen. A coordinator often needs to know that an authorised version is available and an action is due, rather than seeing the underlying clinical material.
Follow one synthetic report through a failed delivery
For accession I-34, the examination is recorded as performed at 11:10. Version R1 is authorised at 14:00. A permitted delivery attempt at 14:05 fails. At 14:20, the queue should therefore say “released; delivery unresolved,” with an age of 20 minutes from release and an assigned follow-up owner.
Scroll horizontally to see all columns.
| Event | Evidence retained | Administrative consequence |
|---|---|---|
| Examination performed, 11:10 | Source event and accession | Reporting task remains open |
| R1 authorised, 14:00 | Version and authorised release reference | Delivery can enter its permitted workflow |
| Attempt fails, 14:05 | Attempt ID, channel and failure result | Follow-up remains open |
| R2 later authorised | Correction and supersession relationship | Owner reviews communication of the correction |
The 20-minute age is elapsed time in a synthetic case, not a turnaround requirement. Before implementing delivery, obtain the provider’s authorised recipient checks, channels, correction process and definition of completion. Test failed and uncertain communications against that definition. A service accepting a message does not itself establish recipient receipt or comprehension.
Compare a shared queue with an integrated delivery service
A small centre can use a reviewed work queue if the RIS exports a stable accession reference and version state. A coordinator records the permitted delivery action and evidence. This is easier to inspect initially, but it requires clear ownership and reliable reconciliation with the source.
An integration can create delivery tasks from supported release events. It adds the need to handle duplicated events, late corrections, retries and unknown delivery results. A booking export alone is insufficient because it cannot establish the authorised report version.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepBooking linked to accession
- B · StepPerformed examination recorded
- C · DecisionAuthorised report version available
- D · StepReporting owner retains open task
- E · DecisionRecipient and delivery route permitted
- J · StepHold delivery for authorised review
- F · StepRecord version-specific delivery attempt
- G · DecisionDelivery evidence satisfies approved definition
- H · StepAssign follow-up with age and failure reason
- I · StepClose delivery task with evidence
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Booking linked to accession | Continue | B: Performed examination recorded |
| B: Performed examination recorded | Continue | C: Authorised report version available |
| C: Authorised report version available | No | D: Reporting owner retains open task |
| C: Authorised report version available | Yes | E: Recipient and delivery route permitted |
| E: Recipient and delivery route permitted | No or uncertain | J: Hold delivery for authorised review |
| E: Recipient and delivery route permitted | Yes | F: Record version-specific delivery attempt |
| F: Record version-specific delivery attempt | Continue | G: Delivery evidence satisfies approved definition |
| G: Delivery evidence satisfies approved definition | No | H: Assign follow-up with age and failure reason |
| G: Delivery evidence satisfies approved definition | Yes | I: Close delivery task with evidence |
Challenge the handover before connecting it
Test a no-show, a cancelled examination, a performed examination without a released report, and an authorised report with an invalid recipient route. These should produce different work items. Also test a corrected report after an earlier version was delivered: the earlier event stays in history, and a new communication obligation follows the approved correction process.
Ask the demonstrator to replay the same release message twice, interrupt the delivery response and restore service. Acceptance means one intended task remains identifiable, failed or unknown attempts remain visible, and the system never promotes a draft report into an authorised state. Verify that the supported interfaces expose the necessary version and correction fields.
A useful imaging queue explains what is waiting without implying a clinical conclusion. Keeping release and delivery separate gives reporting staff and front-desk coordinators an accurate handover and makes unresolved communication visible.
Next actions
- Map the authoritative source and owner for booking, performance, report release and delivery.
- Reconstruct I-34 with a failed attempt and a subsequent authorised correction.
- Evaluate a reviewed queue or integration against version-specific evidence and explicit unresolved states.
Discuss this workflow
Request a workflow assessment focused on this question: Where should an imaging centre track a booking that is completed but whose authorised report has not been delivered?
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- Authorised radiologist, imaging operations lead and RIS/PACS owner: Approved report authorisation/correction procedure and event ownership map.
- Radiology lead and privacy/security owner: Approved communication policy, access permissions and evidence needed to close delivery tasks.
- RIS/PACS integration owner: Version-specific interface documentation and tests for duplicate events, failed delivery and superseded reports.
References
- Bahmni PACS integration — Interface scope only; does not prove report release authority, recipient permissions or delivery.
Topics: radiology workflow management · radiology workflow software · imaging report delivery · RIS appointment management