Four hundred requests. The blast radius first.
A caseload is planned as rows before it is sent as requests. Every row comes back ready, needs review or blocked — with the reason named — and the total is shown before you commit. When a run goes partly, it says what went, what did not, and why. It never says “complete” unless it was.
At three hundred rows, every small dishonesty becomes a large one
A records specialist raising one request can see what is wrong with it. A case manager raising three hundred on the Tuesday after a cohort signs cannot, and the systems firms use today are built for the first person. These are the three ways that goes wrong.
The invoice is how you find out what it cost
Three hundred rows across five states, and seventeen of them are in a jurisdiction nobody has a fee schedule for. The ordinary total either prices those at zero, so the partner approves a figure nobody computed, or shows nothing at all because one row in Florida hid the other two hundred and eighty-three. Either way the real number arrives three weeks later, on paper.
Ninety-six clients, one release each, and the paper is misread
The ordinary mass tort instrument is one page per client granting disclosure to “any and all healthcare providers”. A system that can only hold a release naming one practice reads that page as naming the wrong one, and blocks every row. A system that fixes this by treating an empty grantee line as “anyone” has just turned every unread and badly scanned page into a universal authorisation. Both are wrong, in opposite directions.
“Bulk order complete” over thirty-eight rows that never happened
Of three hundred rows, some clinics are unreachable the moment the batch goes, some releases expired between the plan and the send, and two rows collided with a request another paralegal raised ninety seconds earlier. A result shaped as a tick and a count invites the screen to draw the tick. On a Friday afternoon every screen does, and the thirty-eight are found in the demand phase.
Six mechanisms, built for the person raising three hundred at once
A bulk order is a plan before it is an act, and a one-row suggestion is a bulk order with one row. Both go through the same gate. The one-row case is the one people click without thinking, so it does not get a lighter check.
The caseload is planned as rows, and every row comes back
Hand the planner a cohort and every row you gave it comes back exactly once, in the order you gave it, with one of four verdicts: ready, needs review, blocked, or dropped by a named person with a reason. A preview that quietly drops the rows it did not like is the same failure as one that quietly creates rows nobody saw — either way you cannot count what is about to happen.
- A blocked row names the blocker and the remedy: no release on the matter names this clinic; the release is defective, in the vault’s own words; the clinic was merged into another and the request must name the survivor; the clinic has no route anything can be sent by
- A row that needs review is asking you a question: it could not be priced, it repeats a request the clinic already refused, or a field was guessed at low confidence and somebody has to look
- Approve refuses while any row is still asking a question, and names the first one. It does not refuse over blocked rows — those are facts, and they ride along as skipped
The sentence above the button says how many of the rows will be raised, to how many providers across how many matters; then the cost; then how many need review, how many would duplicate a request that is already open, and how many cannot be raised at all. It names what will not happen, and a partner can read it out loud.
The cost is shown before you commit, and an unknown is never zero
Across three hundred rows in five states, some will have no price — a jurisdiction nobody has onboarded, a schedule that lapsed, a clinic pinned to a contract this matter is not on. That is the normal case. So there is exactly one totalling function, it returns the money and the count of unpriced rows in the same value, and no screen can receive the money without the holes.
- A total resting on unknowns says “at least”, and names how many rows are not in that figure, in the same sentence
- Nearly every bulk row is an estimate, because nobody has pulled a chart yet. An estimate is counted separately and never blocks; a row with no price at all asks a question and does
- The clinic’s share and the Omnis share ride with the total, summed from the same lines, so the answer to “what is your cut” always agrees with the figure it came from
To the cent: a bulk total is a whole number of cents or it is not a total. Three hundred quotes are summed without drift, and a budget cap cannot be checked while any row is unpriced — it says so rather than passing.
A blanket release is read as written. A blank is not a blanket.
The grantee line of a release has three possible readings, and the product holds all three rather than resolving them for you. It names a practice. It grants to a class — “any and all healthcare providers” — and the words are carried verbatim, because the words are what a custodian and a court read. Or somebody read the line and it names nobody. The third one blocks, exactly as it always has.
- Nothing is treated as a blanket unless the page says so. No empty field means “class”, no fallback lands there, and no default produces it: a person or an extraction had to read the line and record what it said
- The right release for a row is the one naming that row’s clinic. Where none does, a blanket release on the matter carries the row instead — and the row records that it rests on a class grant, and which page, so “what authorised this” is answerable after the plan is gone
- A clinic that only acts on its own form still blocks its own rows, blanket or not. Lawfulness and intake policy are separate facts, and merging them would tell you a request was going out when it was about to bounce
Why this is hard to get right: the two readings of an empty line differ by a client’s entire medical history. Software that fills the blank in is writing a term into a document your client signed.
Duplicates are graded across the whole caseload, not guessed
A duplicate is never raised silently and never dropped silently. It is a blocker with a named match — the open request, its state, how long ago it was raised, and a sentence saying why they collide. The check runs against everything already open and against the other rows in the same order, which is the collision a person cannot see in three hundred lines.
- Three strengths: the same ask, where both sides state a window and the windows overlap; partly outstanding, where the clinic has already sent part and still owes the rest; and unprovable, where the open request records no dates and the product says which field is missing rather than deciding either way
- Two years of prior history and the six months after the collision, at the same clinic for the same client, are two legitimate requests and are not called duplicates
- Clearing one takes a recorded decision naming who. One act can cover many rows, but it has to enumerate them — a firm clears a few hundred rows in a handful of acts, each one on the record
What this means for you: the second request for the Reyes chart is stopped on Tuesday, not discovered on the clinic’s invoice in November.
A partial run is reported as what it was
A bulk order’s result is never “succeeded” or “failed”. It is three hundred outcomes and a summary folded from them. The clean outcome has one field — how many were raised — and no fields for refusals, skips or rows still going. So the summary physically cannot report a clean run while anything failed; there is nowhere to put the numbers.
- Six outcomes, each with its own sentence: not started; in flight; complete; partial (for example, “38 of 300 did not happen — 12 refused, 26 never attempted. 262 raised.”); nothing raised at all; and stopped part-way, with the rows that never went still outstanding rather than quietly marked skipped
- The run is scored over every row the approver saw, not the rows the sender tried. A run that reported only on the 241 it attempted would say “all raised, clean” while 59 blocked rows silently did not happen
- Two failures a retry loop actually produces are caught by name: the same row raised twice, and a row raised that the plan had blocked. The sender saw a success both times; the fold holds the approved set beside what was reported and sees the difference
And the committed cost is over what was actually raised, not what was planned — with its own unpriced rows counted, like every other total here.
One clinic, four spellings, one id
Across a cohort, a firm types “Auldmere Spine and Sport”, “Auldmere Spine & Sport LLC”, “AULDMERE SPINE + SPORT (South)” and “Auldmere Spine” and usually means one organisation. Sometimes it means two, because the South location was acquired last year and still bills under its own NPI. Every spelling resolves to one canonical row, so turnaround, exceptions and the preferred list all join — and the row’s ids from other systems, including your case system, are kept on it by system name.
- Two NPIs are two entities, whatever the names say. The same name at a different address is never called the same — it is a review, and a ten-second phone call is cheaper than a misrouted request
- A merge nobody confirmed is a candidate, not a fact. There is no code path that collapses two clinics on a score alone; a merge needs a named human on the record
- A name that was merged away still resolves — to the survivor, with a sentence saying so. Every candidate carries the reason it matched, written to be read out loud, not a bare score
Why it matters at scale: a false merge sends a release naming one custodian to a different one, and the records come back unusable weeks later. A false split files half a clinic’s history under a twin nobody looks at. Both cost money and neither is recoverable by the person who made it.
What a 339-row cohort looked like before and after the blanket ruling
These figures are from a fixture cohort measured on 12 September 2026 — a demonstration caseload built to exercise every refusal path, not a customer’s. We have no customer outcome figures and will not print a guess. What we can print is what the planner did with a realistic shape of work.
The rows that stayed blocked after the ruling are the point, not a defect. On a cohort with ordinary named releases, roughly half the rows could not be raised on the day the fixture was signed — a firm signing ninety-six clients in a fortnight has not papered them all, and the honest thing is to say which ones and why. Every blocker in that cohort carries a remedy somebody can act on: no ready row names paper nobody holds, no ready row names a release written to a different facility, and no ready row points at a clinic nothing can be sent to.
Three screens that change shape when the caseload is hundreds of rows
The firm rail has fourteen destinations. These three are the ones a records specialist, a case manager and an owner live in when the work is a cohort rather than a case. Captured from the running build on fixture data.
Exceptions, ranked by what each one costs
Across hundreds of rows, a queue sorted by how many findings a clinic generated tells you which clinic has noisy paperwork. This one is sorted by consequence: in the capture, a single row worth $4,800.00 at one surgical centre sits above the imaging group’s rows at $1,844.00 each, however many of them there are, because a queue exists to say what the morning is for.
- One queue over the findings six engines already produce, projected rather than re-detected, each row naming the engine and the code it came from and carrying that engine’s remedy verbatim
- Three findings from two engines about one phone call are one row. An overdue request is never its own row when something else is wrong with it — it is late because the release is defective, and one instruction is better than two
- The count reconciles out loud: how many findings arrived, how many were carried on rows, how many absorbed, how many the queue does not claim. You can check it by hand
- Every row has an owner, a priority, a next action and a resolution code. A blocking exception is never ranked below a warning, and an unpriced row sorts under the priced rows of its tier rather than pretending to be a zero or a maximum
Reachability across the whole caseload, before anything is sent
A cohort of a hundred matters touches a few dozen clinics, and some of them have no route to their records desk at all. Surfacing twelve discovered clinics without saying four of them cannot be ordered from is how a firm plans a week around records that were never obtainable. So every provider answers one question first: by what route would an order reach their custodian?
- Four answers: direct, where the clinic takes orders on Injury Docs; extended, where a records vendor under contract releases for them; managed, where the Omnis retrieval desk works it by fax, portal, post or telephone; and no route, which is an unregistered clinic rather than a failed search
- “Find where a client treated” asks outside networks about a named person, so it needs paper, and the paper is checked before the search runs — not after, with the results hidden. A blanket release reaches the network; a blank one does not, and the screen says which page would
- Every discovered clinic is a candidate, never a finding. A signal too weak to name is counted and withheld, with the clinic’s name stripped, because a wrong answer about where somebody was treated is a disclosure even when it is wrong
Every request the run raised, and where each one is now
Once a bulk order is raised, each row becomes an ordinary request on the same machine as a request raised one at a time: twenty-one states, fifteen actions, one clock. The run answers “what happened to the three hundred I raised on Tuesday”; this screen answers “where is this one”. The two are kept apart because they are different questions.
- Records, itemised bills, current and final balances, payoffs, certifications, affidavits, no-longer-represented and MedPay/PIP asks all sit in one list — thirteen ask types on one state machine
- The clock column says whose delay it is. A request waiting on a correction from your side reads “waiting on the requester”, and that interval does not count against the clinic
- No status is stored anywhere. Every state on this screen is derived from the append-only log of what happened, so this list and the run summary cannot disagree
The plan is the same object on every desk that touches it
A cohort passes through a records specialist who builds it, a case manager who answers its questions, and an owner who approves the figure. Each of them reads the same rows, the same verdicts and the same total, because there is one plan and it is recomputed on every click.
Nothing about a row’s identity — the matter, the client, the clinic — is ever inferred. Those come from your case system and are shown as read. A planner that could guess a provider could quietly send a client’s chart to the wrong clinic, so a suggestion whose clinic it cannot resolve is refused, with the next act named, rather than guessed at.
Create your firm accountFour things bulk ordering deliberately is not
Being clear about the edges is how you can trust the middle, and at three hundred rows the edges are where the money goes.
Not a way past the authorisation gate
Volume does not loosen the check. A release is never modified by software — not trimmed, not re-dated, not filled in from the request. Reading a class grant as a class grant is reading a different instrument, not a weaker test, and the blank page still blocks in the same words it always did.
Not a second detector
The one-row suggestions that feed a bulk order — a bill with no records behind it, a referral never followed up — arrive as inputs carrying the finding engine’s own code and sentence. Bulk ordering does not re-detect anything, because a second detector that can disagree with the first is worse than none: people act on the queue.
Not the thing that sends
The planner’s job ends at a plan somebody approved. The run is folded from what the sending side reports back, never asserted — which is exactly what lets it notice a row raised twice, or a row raised that the plan had refused. A module that did its own sending could not see either.
Not a case system, and not a medical summary
Matter, client and their identifiers come from your case system and are shown as read, never retyped. Injury Docs finds treatment gaps and turns them into requests; writing the medical narrative out of the records that come back is MedChron, a different Omnis product.
The six that come up first
Our clients each signed one release to “any and all healthcare providers”. Does that work?
Yes, as the instrument it is. A page that affirmatively grants disclosure to a class of providers is read as exactly that, with the words carried verbatim, and it carries a row to any clinic on the matter that no other release names. What does not work is a release whose grantee line is blank, illegible or unread. That blocks, and the remedy says a blank cannot be filled in here. A blank is not a blanket.
What if a clinic only accepts its own release form?
Then its rows block with that reason, blanket release or not. Whether a page is lawful and whether a facility will act on it are two facts, and the product keeps them separate so you see both: the row says the disclosure would rest on a class grant, and that this clinic returns anything but its own form unread.
How do we know what the run will cost before we approve it?
The total is above the button, to the cent, over the rows that could still be created. If any row could not be priced the figure says “at least” and names how many rows are not in it; if rows are estimates because no page count exists yet, it says how many. The clinic share and the Omnis share are shown beside it, summed from the same lines. After the run, a second figure shows what was actually committed, over the rows actually raised.
Two of our paralegals raised overlapping cohorts. What happens?
Each row is checked against every open request and against the other rows in its own order. A provable collision is a blocker naming the open request and how long ago it was raised. Where the open request records no dates, the answer is “unprovable” and it says which field is missing, rather than deciding either way. Clearing a duplicate takes a recorded decision naming who, and it can cover many rows if it lists them.
Half the run went and half did not. What do we see?
A sentence with the denominator in it: how many were planned, how many raised, how many refused, how many never attempted, and for each row the reason. The rows that were blocked at plan time are in the report as skipped, carrying their blocker’s own remedy, because the run is scored over everything you saw when you approved it. The word “complete” only appears when every approved row was raised and nothing was blocked, refused or dropped.
We have the same clinic spelled four ways across a hundred matters. Will that split our history?
The four spellings reduce to one key and find the same canonical row, so turnaround, exceptions and the preferred list join. What the key throws away — a location in brackets, a legal suffix — is handed back separately, so a search can say “there are two, and they differ by location” instead of picking one. Two rows are only made one by a named person; two different NPIs are never merged at all.
Bring the cohort that signed last fortnight.
Create your firm account and plan it as rows — and see, before anything is sent, which clients are papered, which clinics can be reached, what the run would cost, and exactly what would not go and why.
Raising one request at a time? Records requests → · Reducing the liens afterwards? Liens and reductions → · A clinic on the other side? Read the provider side →