Dividing the work between the rule engine, AI and people

The work is split across three roles

Large language models are good at reading text, summarizing it and answering questions. But in reimbursement, pre-authorization or pharmacy workflows, an assessment only counts if it rests on the right rule, gives the same result for the same input every time and can be defended afterwards. A language model that works probabilistically cannot guarantee those three conditions on its own.

That is why the architecture separates the roles. A rule engine with explicitly defined rules carries out the assessment. AI explains, in plain terms, why the assessment came out the way it did and which document and which rule it rests on. The final decision is made by the physician or medical reviewer. For a reimbursement request, the flow looks like this:

1. The request and the attached clinical documents are structured; diagnosis, procedure and medication information is separated into its own fields.
2. The rule engine assesses these fields against policy rules and SUT, the SGK Healthcare Implementation Communiqué; the result is produced together with the rule that was triggered.
3. AI explains the result: why a given rule was triggered, which information in the document corresponds to that rule, and what appears to be missing.
4. The reviewer reads the assessment and the explanation together and makes the decision.

For the reviewer, the difference is considerable. A screen that only says “not eligible” and a screen that shows which rule was triggered by which information in which document do not create the same workload. With the first, the reviewer rebuilds the reasoning; with the second, they read it and verify it.

Every answer shows document and inference separately

For an explanation to be trustworthy, the reader must be able to tell what comes from a source and what is interpretation. That is why every answer clearly separates two layers: what the documents say, and what the system infers from them. The diagnosis and findings in a discharge summary, for example, are marked as document content; the clinical assessment drawn from those findings is shown separately as inference.

This separation does two things. The reviewer can see the underlying document before accepting an inference. And information that is not in the document is not presented as established fact; the system states clearly what it knows and what it has inferred. The same separation helps in audits: the document behind a decision does not have to be traced afterwards, because it is already visible in the answer.

Asking as you would ask a colleague

Physicians and medical reviewers can question the system not only through menus and forms but also the way they would ask a colleague: “What should I not miss in this patient?” The question is asked in free text; the physician does not need to remember a particular menu or code. The system answers using the data in the patient's profile. The answer brings together the findings that need attention, the relevant rules and the sources relied on. An allergy or chronic condition recorded in an earlier discharge summary, for example, can be raised as something to weigh alongside the newly planned treatment.

That answer is not a decision. It is a reasoned list of points worth attention, and the separation between document and inference applies here too. The physician reads the list alongside their own clinical judgment and decides what matters.

A separate rule for each pharmacy rejection type

Pharmacy is one of the places where the rule-engine approach is most concrete. In prescription assessment, a rejection is not treated as a single generic “not eligible” result. A separate rule is defined for each of the six rejection types. When a prescription is assessed, it is clear which rule was triggered, and AI explains why that rule applied and which information in the prescription does not match it.

This separation has a practical consequence. When one of the rules changes, only that rule is updated, and the effect of a change on results can be traced. For every rejection, the pharmacist or reviewer sees on the same screen which rule it hit and why. Because prescriptions of the same type pass through the same rules, the reasoning behind a rejection does not vary from person to person.

Verified data and physician oversight

The data behind an explanation must also be verified. The model works with data that has passed through masking compliant with KVKK, Türkiye's personal data protection law. The data stays in the institution's own environment, and the institution itself is the data controller; Opinion AI does not collect personal data.

Auditability is not only a technical feature. The model's clinical accuracy and ethical boundaries are reviewed regularly by the Physician Ethics and Advisory Board, made up of physicians from 15 specialties. When a transparent rule engine, AI explanations and physician oversight work together, it is possible to trace afterwards why each output was produced and on what basis.

The responsible AI principle

One principle sits behind this structure: people make the decision; AI shows its rationale and source, and every output can be audited. The rule engine makes the assessment consistent and AI makes it understandable, while the physician or medical reviewer has the final word. That is also where the operational value comes from: routine checks run in the system, while accountability is not handed over from people to the system. It is the approach we follow when working with insurance companies and healthcare institutions in real operations.

To assess how a rule engine and AI explanations could work together in your own processes, use the POC Request form.