Hospitals, clinics and payers make a huge number of administrative decisions: which requests are complete, which claims are clean, who works which shift. Helixor handles the routine part of those decisions consistently and hands anything clinical to a clinician.
These are examples, not a complete list. A decision usually fits when it has written criteria, pulls from several systems, happens often, and someone may later ask why it went the way it did. Pick one to jump to it.
A prior authorization request brings the order, diagnosis and procedure codes, the member's plan and eligibility, clinical notes, and the payer's policy for that service. Staff check whether the request is complete and whether it meets the criteria that allow it to move without clinical review. Incomplete requests bounce back and forth for days.
Helixor routes each request to one of three places: complete and ready for review, missing information (with a list of exactly what's missing), or clinical review. It never decides medical necessity. What it does is make sure a clinician's time goes to the requests that need clinical judgment, and that the office sending the request knows what to fix the first time.
{
"request_id": "PA-55210",
"receipt": "hx_proof_a41be09c77d3f2e85b10c6d4",
"pack": "acme.pa_routing.imaging v7",
"action": "missing_information",
"rules": ["PA-DOCS-CONSERVATIVE-TX", "PA-CODE-MATCH-01"],
"input_sha256": "51d0...9be2",
"remedy": ["attach: 6 weeks conservative treatment notes", "confirm CPT for laterality"],
"logged_at": "2026-09-28T09:41:37Z"
}Before a claim goes out (or before a payer pays it), someone checks codes, modifiers, units, dates of service, provider IDs and the payer's edits. Every denial that comes back costs rework and weeks of cash, and many of them are for things that could have been caught up front.
Helixor checks each claim against your consistency rules before submission and returns ready, fix and resubmit, or hold for coding review. The remedy spells out the fix. Denials that still come back are captured as outcomes and linked to the receipt, so the next pack version catches that pattern.
Nurse managers build schedules around coverage targets, skill mix, rest rules, union agreements, credentials and personal requests. It takes hours every period, and then someone calls out and the whole thing gets patched by phone. Overtime and agency spend creep up because the quickest fix is rarely the cheapest one.
Coverage targets, rest rules, credentials and contract terms go into the pack. The solver builds the roster, and when there's a call-out it looks for the smallest set of changes that fixes the gap without breaking anything else. Every proposed roster and swap is checked by the decision core and gets a receipt. The manager approves it. The pack holds the hard rules and the goal. The solver searches for the best plan that satisfies every hard rule, working from the same typed state the decision core uses. If no plan can satisfy them all, it tells you so instead of quietly breaking one. The solvers are built for GPUs, and that's where large plans solve fastest. Solvers are in Preview today.
| Decision | What Helixor decides |
|---|---|
| Capacity planning | Room, bed and appointment availability, with solvers and reasoning for the exceptions. |
| Referral routing | Send each referral to the right clinic and slot type based on the order and the payer. |
| Workload | Pattern |
|---|---|
| Routing and claims | In-process or loopback sidecar next to the practice or claims system |
| Scheduling and escalations | Hybrid, with hosted solvers |
| Restricted networks | Air-gapped |
Helixor does not diagnose, recommend treatment or decide medical necessity. A clinician is always in the loop for clinical decisions. A good place to start is one administrative decision, like prior authorization for one service line, with every denial and reroute linked to its receipt.
Go deeper on helixor.dev: Industry guide ↗ • Deployment patterns ↗ • Core concepts ↗ • Receipts ↗
Bring a written policy and a handful of past cases. We'll turn it into a pack and run it next to your current process so you can compare.