EthiCompass
← Healthcare

Case · Health plans and social health insurers

Provider claims review.
The written layer, verified first.

A health plan receives invoices from providers for procedures performed on its members and decides on each one. Much of that decision is already automated: the management system validates membership, plan, codes, caps and rates against tables. What falls outside lives in prose — the medical order, the report, the protocol, the consent, the agreement with the provider, the internal audit manual.

Check verifies that written layer against the requirements that apply to it, cites the fragment behind every conclusion, and hands the auditor a pre-analysed file. The auditor decides.

EthiCompass CheckRequirement-driven verificationFounded opinion, never a verdictImmutable audit trail
How Check works →

The operating context

Two kinds of verification
over one file.

Structured data · membership, plan, schedule

Member active and current, plan in force on the date of the procedure, valid code, cap, co-payment and the rate set in the agreement.

Resolved today by the rules engine of the management system. Automated and auditable.

Written documents · order, report, protocol, agreement

Whether what was prescribed matches the condition described, whether the report sustains the procedure billed, whether the certifications are complete and consistent, whether the agreement contemplates that case.

Resolved today by the auditor reading, file by file, with no record of how much was covered.

No declared scope

Each documentary review covers what time allowed, and that scope is never recorded.

Dispersed criteria

Two auditors facing the same file may observe different things, and the organisation has no way to measure how much.

Flat time

The trivial file and the complex one consume the same initial attention, because reading starts from zero in both.

None of this depends on the quality of the team. The first layer is resolved in most organisations. The second concentrates the specialist's time and the risk of overpaying, of rejecting badly, and of having no backing when a claim is appealed.

The unit of work

The requirements that live
in a sentence.

A regulatory or contractual requirement is rarely expressed as a field. It is expressed as a drafted condition that has to be recognised inside a document that is also drafted. That is the unit Check works on: the atomized requirement, held against the text of the file, with the exact citation that sustains it or the record that it does not appear.

Prescription and medical order

Correspondence between the condition described and the procedure indicated. Presence of the data the requirement demands. Consistency between what was prescribed and what was billed.

Study or procedure report

That the report sustains the procedure billed. That the conclusions are supported by the body of the report. That no mandatory section is missing.

Protocol and clinical record

Traceability between indication, execution and billing. The records required for high-cost procedures or special coverage.

Consent and certifications

Completeness, validity, correspondence with the procedure performed and with the practitioner who performed it.

Provider agreement

Whether the billed case is contemplated, under what conditions, and with what documentary requirements the agreement sets on its own.

Internal audit manual

The plan's own criteria, which today live in a document and are applied from memory.

A rules engine compares a value against an expected value. A drafted requirement demands locating the relevant statement inside free text, deciding whether it sustains what the requirement asks for, and leaving a record of where it was read. Check works on that second class of verification, with textual anchoring as a condition of emission.

Where it sits

After the rules engine.
Before the auditor.

Check consumes the file the platform has already assembled, adds verification of the written layer, and returns a pre-analysis to the same flow. The rules engine keeps its function and its governance.

Layer 1 · already running

Rules engine

Structured data. Membership, plan, codes, caps, rates. Unchanged.

Layer 2 · the new layer

Check — requirements against text

Every atomized requirement held against the written documents of the file, each conclusion anchored to the fragment and its location. Reads from the KB-brain.

Layer 3 · where the decision stays

Auditor

Criteria and decision, taken on a file that now arrives with its backing cited.

Feeds layer 2 · KB-brain

The catalogue Check verifies against, composed in three layers with defined precedence.

Universal pack

Documentary verification requirements common to every regulated industry. Curated and versioned by us.

Health grounded pack

Requirements of the health sector, atomized one by one, available as a selectable preset.

The plan's own grounded pack

Audit manual, circuits, agreements and internal criteria. Owned by the plan, on its own infrastructure.

Where the plan's own criterion is stricter than the general one, the plan's prevails. The whole catalogue is versioned and verifiable, so it can always be established which version of which requirement a file was analysed against.

The output

What the auditor
receives.

An illustrative file, constructed to explain the shape of the output. Reimbursement file, high-complexity procedure.

Correspondence between indication and procedure

Satisfied

The order records the condition the requirement demands for the procedure billed. Fragment cited, medical order, body.

Support in the report

Observed

The report concludes on a study other than the one billed. Fragment cited, report, conclusions section.

Record required by the agreement

Observed

The agreement requires a record that does not appear in the file. Requirement cited, agreement clause.

Completeness of consent

Not verifiable

The document was filed as an image with no readable text. Declared reading scope: partial.

Pre-analysis result: with observations — 2 observed, 1 not verifiable. The decision belongs to the auditor.

Asymmetric vocabulary

The result never states that a file complies. An absence of observations can mean real compliance, a requirement out of scope, or text that could not be read, and those three cases are reported separately. No compliance percentage is published: a single figure would mix all three, and a figure like that gets quoted later in rooms where it has to be sustained.

Declared scope

Every analysis reports what it was able to read. An absence requirement over a partially read document is reported as not verifiable, with the same criterion an auditor uses when declaring sampling scope.

Language of the findings

When a reference cited in a document does not appear in the KB-brain it was analysed against, the finding says exactly that, naming the base. It never states that the reference is false, because it could exist outside the scope analysed.

What makes the result hold

Four rules govern what enters
the evidence chain.

The reasonable question to ask of an automatic analysis of text is what makes its result verifiable. The answer is in what the design refuses to emit.

Mandatory textual anchoring

No conclusion exists without the literal fragment that sustains it and its exact location. A statement without an anchor is not emitted.

Propose and dispose

The language model locates and anchors candidates inside the text. The deterministic engine resolves whether the requirement is met. Interpretive judgement is marked and kept separate from the evidence.

Nothing is discarded in silence

Where there is doubt, the result is reported as not verifiable or as a declared coverage gap. A file never loses a requirement without leaving a record.

Frozen analysis

Each analysis is fixed to the exact version of the document and of the requirement it ran against. Two runs over the same input are comparable, and a difference always has an explanation.

Boundary of independence

Check emits verifiable evidence and a founded opinion, never a verdict. The coverage decision stays with the auditor and with the organisation. That separation is what sustains the backing in front of the member, the provider, the regulator or a court.

How it was adopted

Passive first.
Then in the circuit.

Stage one

Observe and calibrate

Check receives a copy of the files and analyses them in parallel, without entering the circuit. The auditors keep working exactly as before.

  • A deviations board with what the pre-analysis marks, by requirement, provider, procedure and plan.
  • Contrast against the auditor's real decision, case by case, to measure precision by type of requirement.
  • Calibration of the KB-brain, taking in the plan's own criteria until the agreed precision is reached.

Stage two

Connect to the circuit

With precision validated, the pre-analysis connects to the management system. When an auditor picks up a case, the analysis is already done and visible.

  • Service-interface integration with the existing platform. The auditor does not change tools.
  • Queue prioritisation driven by the pre-analysis, so the team's time follows real exposure.
  • An immutable audit trail linking pre-analysis and decision.

The order matters. The passive stage produces precision measured on the plan's own files, and a baseline of the current process. With those two figures in hand, the active stage is approved on the organisation's internal evidence.

Operating view

The audit desk

Queue by exposure

Files ordered by the number and severity of observed requirements.

Most observed requirements

What is missed over and over, and in which document it appears.

Unreadable documents

Files whose reading scope came back partial, with the document that caused it.

By provider

Which providers concentrate observations, and of what kind.

By auditor

Equivalent cases decided differently, grouped by requirement.

False positives

Observations the auditor marked as a tool error, with the reason. Feeds calibration.

Executive view

The board

Documentary exposure

What share of the amount reimbursed rests on files with open observations.

Concentration by provider

Which providers explain most of the observations, in amount and in volume.

Cycle time

How long a file takes from intake to decision, and how much that varies.

Reversal on appeal

What share of rejections comes back on appeal and ends up approved.

Review coverage

What share of the flow passed through pre-analysis, and with what declared reading scope.

Closing of observations

Observations closed, reopened and persistent across periods.

The two kinds of dismissal have different owners. A false positive judges whether the tool got a specific case wrong, and anyone with context on the file can mark it. Out of scope judges whether the requirement governs that type of file at all, and it is made effective by whoever holds the signature. Dismissing requires authority; reopening does not. And dismissals are declared in the result: a file with no observations and three dismissed observations is reported with that note.

Outcomes

What changed
in the process.

No client figures are published here. What follows is what the organisation can now do that it could not do before.

A pre-analysis where there was none

The written layer of a file used to reach the auditor unread by anything. It now arrives with its requirements already verified and each conclusion cited to the fragment that sustains it.

Work the team can organise

Audit and legal plan against a triage rather than against a queue of undifferentiated files. The trivial file and the complex one no longer open the same way.

Priorities that follow exposure

When the pre-analysis marks a deviation with enough confidence, legal returns the file to the provider for correction early, instead of after the decision has been made.

A board that sees the circuit

Directors read the state of the reimbursement process close to real time, on what the pre-analysis reports, rather than on a period-end summary.

Capacity redirected

No role was automated away. The specialist's reading time moved to the files that need judgement. The gain is in how the process is run, not in how many people run it.

What Check does not do

It does not approve or reject reimbursements. It does not stand in for medical audit. It does not modify the management system. It prepares the evidence, points at the deviations, and leaves a record. Files carry health data, so in the on-premise arrangement the analysis runs inside the organisation's own infrastructure, with role-based access control, encryption, access logging and retention policies agreed with its data officer.

Start on files you have
already decided.

An assessment over an agreed sample of files your team has already resolved, verified against the applicable KB-brain. Around fifteen days, no integrations. It produces the initial precision by type of requirement, the deviations found, and the calibration plan.