AI triage on the worklist: IHE POWR
The most useful thing triage AI can do is not draw a box on an image. It is to change the order in which a radiologist opens studies. A head CT with a bleed should not sit at position 40 behind routine knee MRIs just because it arrived later.
That sounds simple. In practice, every triage AI vendor ends up needing a way to tell the worklist "move this one up", and every worklist has its own idea of how to receive that. Herman Oosterwijk's recent article The power of the POWR profile for AI results explains the IHE answer to this in under 500 words. I read it the week it came out. This post goes a bit wider, with our view as people who build a worklist that radiologists use every day.
What POWR is
POWR stands for Prioritization Of Worklists for Reporting. It is an IHE Radiology supplement, published for Trial Implementation in August 2023 (the early proposal is on the IHE wiki). Its job is narrow: define how information that affects reading priority, including an AI triage result, reaches the system that orders the reporting worklist.
Herman puts the point of it in one sentence:
On what POWR is for
"Instead of semi-proprietary APIs, the POWR IHE profile specifies a standard HL7v2 transaction to exchange this information."
That is the whole value. Not new technology, a common way of saying something everyone already says differently.
The actors
POWR reuses actors that radiology IT people already know:
- ADT: patient registration and demographics, usually the HIS
- Order Placer: where the order is entered, the HIS or EMR
- Order Filler: the RIS, which schedules, assigns the accession number and feeds the modality worklist
- Image Manager/Archive: the PACS or VNA
- Procedure Reporter: sends results about the procedure; for triage, this is the AI application
- Prioritizer: collects all of this and decides the order of the reading worklist
The Prioritizer is the new and important one. It could be a dedicated AI orchestration engine, a PACS worklist, or the RIS. What matters is that one actor owns the decision.
What the Prioritizer weighs
In POWR, the AI triage result is one input to the Prioritizer, not the boss.
This is the part I like most about the profile. The AI result is one input among several, not the boss.
| Factor | Why it matters in a real queue |
|---|---|
| Indication / reason for study | "Trauma, fall from height" and "routine follow-up" should not read at the same speed |
| Patient type / ordering department | An emergency or ICU patient waits differently from an outpatient |
| Order priority | The STAT flag set by the clinician |
| Ordering provider | Some referrers or contracts carry specific turnaround commitments |
| Modality / procedure type | A non-contrast head CT and a screening mammogram have different urgency profiles |
| AI triage result | Finding present or absent, with severity and certainty |
| Exam complete / images available | No point prioritising a study whose images have not all arrived |
In Indian practice the STAT flag is often unreliable, because when everything is marked urgent nothing is. An AI finding with a certainty value is a second opinion on urgency that does not depend on who ticked which box. But if the worklist trusts it blindly, a model with a high false-positive rate will push genuinely urgent cases down by crowding the top. A good Prioritizer needs to use all the factors together, and a centre should be able to see why a study moved. (Reading order is also only one part of turnaround; see Radiology turnaround time for the other stages.)
The message: OMI with OBX segments
The key transaction is [RAD-145] Send Procedural Observation, from the Procedure Reporter to the Prioritizer. According to the POWR supplement it is an HL7 2.5.1 Imaging Order message, OMI^O23. The accession number travels in IPC-1, the patient identifier in PID-3, and the ORC segment carries the order control and status codes. The AI result itself goes in OBX segments.
The fields that matter most:
| OBX field | What it carries for triage |
|---|---|
| OBX-2 Value type | CE (coded), NM (number) or TX (text) |
| OBX-3 Observation identifier | What was looked for, as a code (SNOMED CT, LOINC, RadElement and similar) |
| OBX-5 Observation value | Present or absent, or a measured value |
| OBX-8 Abnormal flags (interpretation codes) | Normal, abnormal, critical; POWR also uses this for triage category |
| OBX-9 Probability | A probability, confidence or signal strength, with a meaning specific to each algorithm; the Prioritizer must be configured for it rather than treating it as a universal certainty |
Herman's article includes a full pneumothorax example from the profile, with a coded finding, a measured pleural separation in millimetres, a criticality code and the algorithm identity. It is worth reading just to see how much can be carried in two OBX lines.
Insist on coded OBX-3 values. If one vendor sends "ICH" as text and another sends a SNOMED code for intracranial haemorrhage, the Prioritizer has to guess, and guessing is exactly what a standard is meant to remove.
Why a standard beats per-vendor APIs
Today, adding one triage AI often means one more custom integration. The AI vendor learns the worklist's API, or the worklist team writes a connector for that vendor. With two or three AI tools, that is two or three slightly different integrations, each with its own failure mode and each broken by the next upgrade on either side.
POWR changes the shape of that work. The worklist side implements one receiving interface. Any AI that sends conformant RAD-145 messages can plug in. Herman makes the same argument, and it gets stronger as more AI tools show up.
There is a local angle too. HL7 v2 is the format an HIS integration engineer in India is most likely to already know, and most interface engines handle it (we walked through the common messages in Connecting radiology to the HIS). Asking a hospital's IT team to accept one more HL7 v2 feed is a much easier conversation than asking them to host a vendor's custom API bridge.
How we think about it
At SOMATIQ, RIS, PACS and reporting are one platform, covering registration, scheduling, billing, acquisition, reporting and report delivery, so the worklist sits right next to the order data, the image availability and the reports. We have also built a voice-controlled, agentic worklist, where radiologists can talk to the worklist and move through it hands-free. Building that made us think hard about what ordering a queue really means, because when a radiologist says "next study", the system has to be confident about which study that is.
That experience is why POWR reads sensibly to us. The factors it lists are the ones a reading room already argues about. What we look for, when we evaluate any triage integration, is:
- The AI result arrives as structured, coded data with a certainty value, not a free-text flag.
- The worklist can explain why a study moved up.
- The AI result never removes a study from the queue; it only reorders.
- The integration does not depend on one vendor's private API.
The second point deserves a word. Our own experiments with AI on wrist X-rays showed a workflow whose structured label and written report disagreed (When AI agents read wrist X-rays together). A Prioritizer acting on a label like that would reorder the queue on the wrong answer, which is why being able to see the reason for a move matters as much as the move itself.
In conclusion, POWR does not make triage AI smarter. What it does is give every triage tool the same, well-understood way to say "this study may be urgent, and here is how sure I am", and give one actor the job of weighing that against everything else a reading room already knows. For a centre adding its first or second triage tool, asking the vendor whether they can send RAD-145 is a short question that saves a long integration later.
Related reading
- Talking to the worklist — what building a voice-controlled worklist taught us about queue order.
- Connecting radiology to the HIS — the HL7 v2 messages POWR builds on.
- Radiology turnaround time — where worklist order sits among the seven stages of turnaround.
- FHIR for AI results — how AI findings reach the reporting system, as opposed to the worklist.
- The AI results checklist we hold our viewer to — the IHE profile for displaying AI results once the study is open.
FAQ
What is the IHE POWR profile?
POWR (Prioritization Of Worklists for Reporting) is an IHE Radiology profile that defines how information affecting reading priority, including AI triage results, reaches the system that orders the radiologist's worklist, using standard HL7 v2 messages.
What is the Prioritizer actor?
The Prioritizer collects inputs such as indication, patient type, order priority, ordering provider, procedure type, AI triage result and image availability, and decides the worklist order. It can be an AI orchestration engine, a PACS worklist or a RIS.
Which HL7 message does POWR use for AI results?
The [RAD-145] Send Procedural Observation transaction uses an HL7 2.5.1 OMI^O23 Imaging Order message, with the AI findings in OBX segments.
Does POWR mean AI decides the reading order?
No. The AI result is one factor. The Prioritizer weighs it alongside clinical urgency, order priority and turnaround commitments.
Ready to see your workflow on one platform?
We will walk you through the whole workflow, from registration to signed report.