A ready file for the medical reviewer at pre-authorization
At pre-authorization, a medical reviewer's time often goes less into deciding than into gathering what the decision requires. When the policy, the limit, the file history, SUT rules and the clinical document arrive ready on one page, the reviewer can focus on the real work: the assessment.
The reviewer's time goes into preparing the file
When a pre-authorization request arrives from a hospital, the insurer's medical reviewer looks for answers to several questions at once. Is this procedure within the policy's coverage, has the waiting period ended, does an exclusion apply? Is the remaining limit sufficient? Has the patient been pre-authorized for a similar procedure before, and what amounts were paid? Does the requested procedure comply with SUT, the SGK Healthcare Implementation Communiqué that sets reimbursement rules? Does the clinical document actually support the request?
The answers usually sit in different systems and documents. The policy wording is in one place, limit usage on another screen, earlier pre-authorizations in the archive, and the clinical document is often a scanned file. Each question means another screen and another search. Before deciding anything, the reviewer has to put these pieces together. As request volumes grow, so does this preparation burden. The time spent preparing the file can easily exceed the time left for the assessment itself.
The insurance process from start to finish
The ready-file idea is not limited to pre-authorization. The same clinical and administrative information is reused across successive steps of the insurance process:
- At pre-authorization, coverage and the clinical document are assessed on one screen.
- At policy issuance, coverage, waiting-period and exclusion terms move from the document into the system.
- At the claims stage, earlier pre-authorizations are visible and amounts are compared.
- At reimbursement, limit usage and SUT compliance are checked.
- For medical advisory, the reviewer puts questions to the system through Doctor Assistant and Council Mode.
The steps feed one another. Coverage information structured at policy issuance becomes the basis for the coverage check at pre-authorization. The record created at pre-authorization is used for comparison at the claims and reimbursement stages. When a claim arrives, earlier pre-authorizations and approved amounts sit side by side, so any gap between the amount claimed and the amount approved is visible without a separate search. Each step inherits the data of the previous one instead of gathering it again.
The information the reviewer sees on one page
When a pre-authorization file is opened, the reviewer finds the information needed for the assessment on the same page. Policy analysis shows coverage, the waiting period and exclusions; limit tracking shows the used and remaining limit; and file history shows earlier pre-authorizations and their amounts. The SUT compliance section checks the request against the rules. Clinical context places clinical observations on the same page as the administrative information. The reviewer can also put questions to the system through Doctor Assistant and Council Mode.
The value of this information lies less in each piece than in having it all together. Whether a procedure is covered only makes sense when read alongside its clinical rationale. Whether an amount is reasonable only becomes clear next to earlier pre-authorizations. The limit works the same way: seen alongside the amount requested, the remaining limit shows at once, without extra calculation, whether the request stays within it.
The checks that run when a request arrives
A typical pre-authorization request moves like this. When it comes in from the hospital, the clinical document is read and structured; the diagnosis, the planned procedure and the supporting findings are separated into their own fields. At the same time, the policy terms are scanned: whether the procedure is covered, whether the waiting period has ended and whether a relevant exclusion applies. Limit usage is worked out, the patient's earlier pre-authorizations and paid amounts are added to the file, and compliance with SUT rules is checked.
When the reviewer opens the file, the results of these checks are already there, with missing or inconsistent points flagged. Missing information in the document becomes visible while the request is still under review. If a clinical question comes up, the reviewer can put it to the system in plain language through Doctor Assistant or Council Mode. Every answer shows separately which information comes from the document and which is the system's inference.
Take a request for a planned surgical procedure. The file shows at a glance whether the waiting period the policy sets for this procedure has ended, whether an exclusion applies and whether the remaining limit covers it. If the clinical document offers weak support for the indication, that point is flagged. The reviewer asks Doctor Assistant, “Which finding in the document supports this procedure?”, and the answer shows the wording taken from the document and the system's interpretation separately. The reviewer decides whether to request further documents on that basis.
The reviewer's time is left for complex cases
The ready file does not take the reviewer out of the loop. The final decision always rests with the insurer's medical specialists. What changes is where the reviewer's time goes: routine checks are handled by the system, and the reviewer's attention goes to complex cases that genuinely need assessment. Decisions such as approval, rejection or a request for further documents are based on a recommendation whose reasoning and source are visible, and every output can be audited later. A ready file also brings consistency: requests of the same type go through the same checks, and two reviewers looking at the same file see the same information.
The same principle applies to the data. It stays in the institution's own environment, and the institution itself is the data controller. The model works with data that has passed through masking compliant with KVKK, Türkiye's personal data protection law, and Opinion AI does not collect personal data.
To assess together how your pre-authorization flow could be set up on your own file structure, use the POC Request form.