That is the count we started from, and it is the whole reason Injury Docs exists. An email thread has no status, no owner, no clock and no history — so the moment the ask leaves your office, it stops being a thing anybody can point at.
The systems personal-injury firms use today publish their own back office on their contact pages. Read one properly and you find thirteen named request types, twelve shared mailboxes and a phone tree — and exactly one of the thirteen with a screen behind it. Everything else is an inbox somebody has to remember to open.
Records, bills, balances, final balances, payoffs, affidavits, certifications, no-lien representations, MedPay/PIP, case status, claim status, paid-to-facility and procedure requests. Twelve of those thirteen are a shared inbox or a phone prompt. They are not thirteen different problems. They are one problem thirteen times, and nobody had given it a shape.
Not a slow answer — no answer. Somebody opens an email thread and reads it. When the paralegal who sent it is on holiday, nobody knows where the ask stands, and the only escalation available is to send the same email again. You cannot escalate on an email that has not been replied to. You can escalate on a state.
They live in three places, arrive at three times, and get reconciled by hand at the worst possible moment — while the demand is being drafted. Nobody notices the chart was incomplete until it is needed. That is not a discipline failure. It is what happens when the system of record is a mailbox.
From our own walkthrough of how personal-injury firms run records today, 11 September 2026. We are describing a published contact page, not a benchmark.
Everything a paralegal does all day is the same shape: ask a clinic for something, and find out later whether it came. So there is one Request in this product, and the named asks are types of it, riding one state machine, one clock and one audit trail. The firm and the clinic are not two products with a sync between them — they are two navigations over one transaction, which is why they can never disagree about what was asked for.
A number you can reproduce beats a number you have to trust.
Every state, every ranking and every figure in this product is computed by a rule you could check by hand. There is no model in the loop deciding what a request is worth or where it belongs in a queue, because when a balance is disputed nine months later the question is what happened — and the answer has to be on the record rather than in somebody’s recollection.
Every figure is exact to the cent and rendered to two decimals. There is no rounding anywhere in the product, on either side’s screen.
Counted from the build on 24 September 2026. These are facts about what exists, not claims about what it will save you. We have no customer figures yet, and we would rather print none than print a guess.
Each of these names a different Omnis AI product, or a deliberate absence. Being clear about the edges is how you can trust the middle — a product that claims every adjacent job is a product that has not decided what it does.
Injury Docs finds gaps in treatment and turns them into records requests — that is the loop it owns. Writing the medical narrative out of the records is MedChron, a different Omnis AI product. We keep the two apart deliberately, so neither one has to pretend to be the other. Nothing in Injury Docs drafts a word of the medical story.
The Patients screen on the clinic side is records: the people whose charts have been asked for, and every request standing against each one. Scheduling, clinical notes and encounter documentation for a practice are CarePro, a different Omnis AI product. A clinic can work the Injury Docs queue without changing anything about how it runs its day.
Nothing in this product advances money to an injured person, offers them anything against their case, or puts a financial product of any kind in front of them. It moves records and reconciles the bills attached to them. There is no login here for an injured person, and none planned — the people whose records move through this exchange are represented by counsel, and that is who we build for.
Injury Docs is the exchange between the case system you already run and the clinic. It does not want your matters, your calendar or your intake. Settings carries the destination for connecting the system you have — that destination is on the plan and it is not wired to anything yet, because nothing is. Ask us and we will answer at exactly this level of detail.
Injury Docs is new. The screens, the engines and every figure they compute are real and you can watch them run. The backend that would let you actually send, accept or pay is not built, and we are not going to write a page that implies otherwise.
Twenty-six destinations across three audiences, thirty-four domain engines, 4,991 passing tests. Every pricing, SLA, lien, ledger and exception rule is real, and every figure on screen is computed from the request log rather than stored. Watch a state change and watch the ledger and the reports move with it.
Records requests now run between real organisations on the web app: a firm sends one to a clinic on Injury Docs, and the clinic accepts it, works it and says how the records went, every step on both desks. Not built yet: the records themselves still travel the clinic’s usual way (secure email, fax, portal) rather than through Injury Docs, most screens beyond requests are not live on the web and say so, and there is no mobile version. The connection to the case system you already run is a destination in the product, on the plan, wired to nothing so far.
Press Send today and the request reaches the clinic you chose, and every step either of you takes is recorded to an append-only, hash-chained log. A screen that is not live on the web says so, instead of showing you somebody else’s data. That is the same discipline it applies to a blocked request, and it is the thing to watch for when you see it demonstrated.
Injury Docs is built by Omnis AI, which builds software for the desks either side of a personal-injury case — the law firm’s and the treating clinic’s. That is why the boundaries above are drawn where they are: the adjacent jobs already have products, so this one does not have to stretch to cover them.
It is also why Injury Docs is one system rather than two. Most tools in this space pick a side: a records-release pipe built for clinics, or a firm portal with an off-platform back office behind it. Both sides then argue about whose copy of the balance is right. We built the exchange itself, so that the firm and the clinic sign into the same record and read the same derivation — which is only possible because status is computed from one log rather than stored in two places.
We will walk your worst-stuck case through the exchange — the requests, the clock, the exceptions and the ledger — and show you exactly where the product ends and the plan begins.
Are you a clinic? Read the provider side →