Tags, Reasons, and Tasks in Pending QC

What these objects do in Pending QC

When a study stalls in Pending, the case may already show what is wrong: an issue tag, an incomplete reason for exam, or an open task or support request. Each object answers a different question about readiness. The tag describes context, the reason explains why the exam was ordered, and the task records follow-up.

That is why PACS admins own the last mile. Radiologists feel the cost when an unfinished record reaches dictation, but operations teams typically manage the tags, statuses, source corrections, and follow-up needed to clear it.

Tags: classification and issue context, not ownership

Depending on the PACS or RIS configuration, tags or equivalent flags may mark case type, verification state, holds, restricted-reader context, or a known problem. They can affect what the queue shows, which automation runs, and what an admin sees at a glance.

What they do not do on their own is finish the work. Applying an issue tag without a remediation path leaves the study parked. Clearing a tag without re-checking the affected fields can release a study that is still incomplete. Useful tag practice looks like this:

• Use the approved catalog. Inventing ad-hoc labels breaks filters, reports, and any automation that depends on known codes.
• Preserve required context. Set-based updates should not strip verification or restricted-reader tags the site still needs.
• Pair every blocker tag with follow-up. The tag names the problem. An owned task or support request can record who will fix it and whether the work is closed.

Vendor screens name these objects differently. The ops question stays the same: does the tag set tell you whether the study is classified correctly and whether an open issue still blocks reading?

Reason for exam: a completeness field, not a diagnosis

Reason for exam, indication, or clinical history is one of the checks in what makes a study read-ready. The admin is not asking what the images show. The question is whether the record carries the context required by site policy for that case type and reading workflow.

An empty, unreadable, or generic value may be insufficient under site policy. A copied phrase that does not match the performed exam also needs review. The required context may come from an order feed, a tech sheet, or an approved note field, depending on the site. HL7 vs non-HL7 outpatient imaging QC explains that difference.

Moving a study forward without the required reason can create more work for the reader and operations team, including clarification calls, corrections, and delayed turnaround. Checking the field in Pending puts that work before the reading handoff.

Tasks: ownership for the blocked branch

When a readiness check fails, the study should not simply age in Pending. Someone may need to retrieve a prior, fix laterality at the source, obtain a missing form, or clarify an order. A task, support request, or equivalent handoff can give that work an owner and a trackable state.

1. One owned path per blocker. Duplicate tickets on the same gap create noise and false closure.
2. Resolution is confirmed, not assumed. Closing the task does not make the study read-ready until the affected checks run again against current source state.
3. Do not treat every object as interchangeable. Some systems separate a support request from a task. Site policy decides which one creates the durable remediation record.

Without that loop, a queue can collect labeled problems with no clear path to resolution. With it, clean studies move forward and blocked studies stay visible until the source record changes.

How Corena uses the same objects

Corena is designed to run operational Pending QC before reading. It checks current status, approved tags, reason-for-exam sufficiency, holds, and open remediation against site policy. During initial rollout, a human reviews every proposed external write. Corena uses approved tag catalogs, does not generate clinical findings, and keeps vendor-specific task behavior in site policy.

To review real Pending cases using your existing tags, reasons, and owned tasks, request a demo. Start with writes disabled, following the approach in read-only before writeback.