Provider matching depends on explicit routing signals
The orchestrator should never route only on a free-text study description. Good assignment decisions combine exam type, urgency, credentialing, queue depth, service level objective, shift status, and sometimes geography or network considerations.
That matching logic only works reliably when the control plane has already made the study state durable, recoverable, and publishable. Routing should consume trustworthy workflow state, not try to guess around broken upstream transitions.
Common routing inputs for provider matching
| Signal | Example | Reason |
|---|---|---|
| Study classification | Neuro MRI or trauma CT | Matches the case to the right sub-specialty pool |
| Urgency and SLA | Stroke triage versus routine follow-up | Changes escalation windows and queue priority |
| Provider status | On-call, available, or over threshold | Prevents assignments into unavailable or overloaded queues |
Routing decision inputs
Loading diagram...
The directory model should optimize for assignment access patterns
The matching database is not a generic data warehouse. It is an operational lookup path. That means the design should optimize for the exact reads the routing engine must perform, such as which qualified readers are available for a given queue or which active studies already belong to a given worklist.
Access patterns the matching store should support directly
| Operational question | Primary key path | Reason |
|---|---|---|
| Who is available for neuroradiology right now? | Specialty and status-oriented index | The router needs a candidate pool without scanning every provider record |
| What is already assigned to this provider? | Provider-oriented worklist read | Load and fairness calculations depend on current queue state |
| Which studies are aging past their SLA? | Priority or time-sorted worklist view | Escalation should be driven by explicit queue state rather than guesswork |
Provider matching access pattern flow
Loading diagram...
This is intentionally shown as access-pattern flow instead of as a relational ERD. For an operational routing store, the read and write questions matter more than pretending the design behaves like a normalized transactional schema.
Relational modeling best practices in DynamoDB
AWS guidance on access-pattern-driven modeling, which is essential when designing a fast provider-matching store.
Review DynamoDB relational modeling guidanceGlobal secondary indexes in DynamoDB
AWS documentation for alternate query paths such as specialty-, status-, or queue-oriented lookups.
Review GSI designWorklist policy should make escalation and fairness explicit
A unified worklist becomes dangerous when it is treated as a dumping ground. The orchestrator should keep assignment, queue aging, rebalancing, and timeout rules explicit so that operators can see when the system is drifting away from the intended operating model.
Representative assignment event
A simplified assignment record showing the routing evidence a unified worklist should preserve for operators and auditors.
Click on an annotation to highlight it in the JSON
- Define how long urgent cases can wait before forced escalation.
- Record why the study was assigned to a given reader or queue.
- Separate advisory AI triage from final assignment authority.
- Keep manual override actions auditable.
IHE AI Workflow for Imaging supplement
IHE supplement showing how AI-influenced worklist changes should still happen through explicit actors and workflow steps.
Review the AIW-I supplementKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.