In most practices, prior authorization is the queue nobody owns. Requests are assembled by whoever has a free moment, submitted through a mixture of payer portals, fax and phone, and checked by hand until something comes back. The person who ends up doing most of it is often a clinician, because the clinician is the one who can answer the payer's questions, and that is the most expensive way a practice can spend a clinical afternoon.
The reason the queue is never fixed is that it is two kinds of work wearing one name, and every attempt to fix it addresses only one of them.
The steps
Follow one request from start to finish and it passes through roughly these steps.
- Deciding that a request is needed, based on the payer, the plan and the procedure.
- Assembling the request from the chart: the codes, the documentation, the demographics, the plan details.
- Submitting it to the payer in the format that payer accepts, which differs from payer to payer.
- Checking the status, repeatedly, until a response arrives.
- Reading the response. An approval is recorded. A request for more information or a denial has to be understood.
- Deciding what the resubmission or the appeal needs, and getting it from the clinician if only the clinician can supply it.
- Calling the payer when the portal cannot answer the question.
- Recording the outcome and telling scheduling whether the procedure can go ahead.
Which parts are rule-based
Steps one through four, and step eight, are rules. Whether a request is needed follows from the payer and the procedure. Assembling it is pulling known fields from the chart. Submitting it is a format problem. Checking the status is polling. Recording the outcome is data entry. None of these needs judgment, all of them are repetitive, and all of them are where a person's day goes.
These steps should be done by software connected to the EMR. The practice's own rules decide when a request is raised, the request is assembled from the chart, it is submitted to each payer the way that payer accepts, and its status is checked automatically. Every response is flagged into one queue with the reason attached.
Which parts need a person
Steps five through seven need judgment. Reading a denial and understanding what it is actually asking for is a skill. Deciding what the resubmission needs, and asking the clinician only for the part the clinician alone can supply, is a skill. Calling a payer and getting an answer is a skill. Software that claims to do these steps needs a person to check it, and that person is usually the same coordinator the software was bought to replace.
These steps should be done by a revenue cycle specialist who works the flagged queue and nothing else. The specialist reads the exceptions, prepares the resubmissions, makes the calls and asks the clinician a short list of questions. Because the rule-based steps are already handled, the specialist's day is spent on the work that needs a specialist.
Why they have to be set up together
A practice that buys the software from one vendor and hires the specialist through another gets two queues. The software flags an exception into its dashboard, the specialist works from a spreadsheet, and things are submitted twice or not at all. The clinician is still asked questions that the chart could have answered.
The two halves have to share one queue, and the specialist has to be trained on the automation before starting. That is what The Medical Engineers and The Medical Staffers do when they set this up for a practice: one queue, one configuration the practice owns, and one specialist who was interviewed by the practice and works inside its EMR. The clinician stops doing either job and answers a short list of questions instead.
What stays with the practice
Every clinical decision. The clinician supplies the clinical information a payer asks for, and nothing is submitted in the practice's name that the practice has not seen. The queue is visible to the practice at any time, and the configuration belongs to it. The division runs the work. The practice runs the care.