Operated function · authorisation
The submission went in without one code, or on the wrong form version, or to a portal that changed last month. It comes back denied, somebody resubmits, and a procedure that was already on a schedule is now inside a window nobody is watching.
Every payer is a different operation. Different portal, different form, different required fields, different definition of urgent, different response window, and a set of rules that changes without a version number or an announcement anybody sees. Staff carry the differences in their heads and the newest person carries none of them.
Submission is a form-filling exercise where the cost of one wrong or missing field is a denial and a full round trip. The denial rarely says which field — it says a category, and somebody has to work out what was actually wrong by comparing against a submission that worked.
The clock belongs to the payer and nobody on your side sees it. A request submitted on Tuesday is expected back at some point, and whether it is late is a judgement somebody makes when they happen to look — which is not a system, it is a person remembering.
Meanwhile the procedure gets scheduled, because scheduling and authorisation run on separate tracks and the schedule cannot wait indefinitely. So the two clocks race, and when authorisation loses, somebody is cancelled at short notice — the worst outcome available for everybody involved.
And the same field is missing repeatedly, on the same payer, on the same procedure type, because nothing records the pattern and each denial is handled as an individual event.
Authorisation response windows are set and held by the payer, and most operations have no continuous view of where each request stands against its window — so lateness is discovered by a person happening to look.
That single gap produces most of the damage. A request that is going to be late is knowable long before it becomes urgent, and knowing early converts a short-notice cancellation into a rescheduling conversation held calmly a week out.
Making it visible needs only three things per request: which payer, when it was submitted, and what that payer’s window is. The third is the part that lives in people’s heads, and writing it down — payer by payer, versioned, with an owner — is the unglamorous work that makes everything else possible.
The second gain is in submission completeness. The required-field set per payer and procedure type is knowable, patterned, and exactly the kind of thing a person checks partially under time pressure. Checking it exhaustively before submission removes the denial that was never about clinical judgement at all.
And the denial pattern is the permanent fix. When one field is missing repeatedly for one payer, that is a template correction made once rather than a resubmission made fifty times.
What is never delegated is anything clinical. Medical necessity, the content of a clinical justification, and any decision about whether a procedure is appropriate belong to your clinicians. This operation submits, tracks and chases — it does not argue clinical merit.
Requests visible against their own payer window — measured by open requests with time-remaining known, against a baseline where lateness was found by looking.
Denials attributable to a missing or wrong field — measured by denials by cause, separating administrative from clinical — a split most queues cannot produce.
Resubmissions per authorisation — measured by submissions required to reach a decision, against your own baseline.
Short-notice cancellations caused by authorisation — measured by procedures cancelled inside your defined window for authorisation reasons, before and after.
Elapsed time from requirement identified to decision received — measured by days split into our preparation, payer response, and time lost to resubmission.
Repeating field failures by payer — measured by denial cause frequency per payer and procedure type, which points at a template fix rather than a resubmission.
any clinical judgement, any assertion of medical necessity, and any influence on whether a procedure is appropriate. Nothing here writes or edits clinical justification, argues merit with a payer, or participates in a peer-to-peer review. Those are your clinicians’ and a system that did otherwise would be practising medicine.
Orders, coverage and scheduling state come from your existing systems through documented interfaces, and the authorisation record lives where your revenue cycle team already works. No second authorisation record is created — two places holding whether a procedure is authorised is a patient-safety and billing problem at once.
Payer submission uses each payer’s own channel, whichever it is. Where a payer offers only a portal with no interface, that limitation is stated rather than worked around by automating its screens, because a screen-driven submission breaks silently at the next portal change and it breaks on somebody’s procedure.
The payer rule set is yours, versioned and owned. It is the asset the operation produces, and it keeps working if the engagement ends.
Authorisation work involves protected health information, and where it does, a Business Associate Agreement governs it and the obligations attach because that agreement exists. We do not claim HIPAA certification, and no vendor can: HHS does not certify business associates and a business associate cannot self-certify.
The clinical boundary is enforced by scope rather than by instruction. Clinical justification content is prepared by your clinicians and attached; it is not composed, edited or summarised here, and a request that would require arguing medical merit escalates rather than proceeding.
Every submission and every payer interaction carries a receipt: what was sent, to whom, when, and what came back. That record is what answers a payer dispute and what an audit asks for.
Operational access is not permission to train. Clinical and authorisation data does not become material improving anything serving another organisation.
Clinical leadership must see and agree the boundary before anything is connected. The sentence that matters to them is that no clinical content is composed, edited or argued here, and that anything requiring medical judgement escalates by rule.
Privacy reviews the minimum-necessary access model for the authorisation queue specifically, which is narrower than the patient record as a whole.
Where an obligation attaches through an agreement, a payer contract or a data class, it is marked applicability-gated rather than presented as already in force.
A single payer and procedure type over one trailing period — read-only, nothing submitted — measuring denial cause, resubmission count, and time against that payer’s window.
Observation submits nothing. It produces the denial-cause split — administrative against clinical — which is the number that decides whether this operation has anything to offer. Where denials are genuinely clinical, no amount of completeness checking helps and the conversation belongs with your clinicians and the payer.
It also produces the payer rule set as a by-product, because establishing why submissions failed requires writing down what that payer actually requires. That document is worth having regardless.
If you continue, the first delegation is completeness checking before submission on that one payer and procedure type, with the clinical boundary live and clinical attachments still prepared entirely by your staff.
The clinical part cannot and is not. Medical necessity, the justification content and any peer-to-peer review stay with your clinicians, and a request that would require arguing merit escalates rather than proceeding. What is delegated is the administrative wrapper: which fields this payer needs, whether they are all present, where the request currently stands, and chasing it. If your denials are predominantly clinical, the first phase will show that and you should not proceed.
They do, and that is the argument for writing them down with a version and an owner rather than holding them in the heads of the staff who have been there longest. The change problem does not go away — what changes is that when a payer moves, the correction is made once in a versioned rule set instead of being rediscovered by three people across ten denials.
Then the submission step may stay with your staff and the scope narrows to requirement assembly, completeness checking and clock tracking — which is where most of the avoidable loss is anyway. What will not be done is automating a portal’s screens: that breaks silently at the next change and it breaks on a patient’s procedure. Where a payer has no interface, the limitation is stated in scope rather than engineered around.
Which is the strength and the exposure at once. That knowledge is real, it is why the operation works, and it is unversioned and leaves with them. The first phase writes it down — payer by payer, with an owner and a version — and that artefact belongs to you whether or not anything is ever delegated. It is also what lets a new hire be useful in weeks rather than months.