Revenue integrity · claim pre-check
Shield. See rejection risk before the claim is submitted.
Invoice
F-2026-0413
Pre-check 3/5
- Out-of-package supply₺1,280In review
- Chest CT₺2,340Verified
- Outpatient visit₺640Verified
- Physiotherapy session₺410Checking
- Biochemistry panel₺520Waiting
Submission record
Verified items
- F-2026-04124 items · ₺4,980
- When the check runs
- Pre-claim
- Risk score
- 0–100
- Who decides
- Specialist
- Audit log
- Append-only
Problem
A rejection found after submission doubles the work.
A large share of rejected claims come from preventable errors: missing documents, code mismatches, exceeded limits. These can be caught before submission, by a rule, with a reason.
Rejections arrive late
A rejection usually comes after the claim has been sent. Appeal, correction and resubmission delay payment and take up the team's time.
The rules change often
SUT (Turkey's Health Implementation Communiqué), package definitions and payer contracts are updated often. Tracking them from personal experience means the same item is handled differently by different people.
A score without a reason is not useful
A score that does not say why an item is risky does not tell the team what to do, and cannot be defended in an audit.
How it works
A check layer in front of your billing system.
Shield does not replace your billing system. It runs just before submission, checks each line item against rules and shows the questionable ones to a specialist.
- 01
Claim and authorisation data
Service lines, diagnosis and procedure codes, pre-authorisation and document status are collected before submission.
- claim lines
- ICD-10
- SUT annex
- authorisation status
- 02
Pre-check
Versioned rules check code consistency, missing documents, limits and duplicate lines.
- versioned rule set
- reproducible result
- 03
Risk score
The score is the sum of the contributions of the rules that fired. Each contribution is shown with its rule ID.
- Σ rule contributions
- 0–100
- 04
Review queue
Items above the threshold go to the specialist's queue. Shield never decides on submission by itself.
- threshold ≥ 40
- HITL
- 05
Decision
The specialist approves, sends for correction or holds the submission. The decision and reason are stored with the item.
- approve
- correct
- hold
- 06
Record
Score, rule version, who decided and when are written to an append-only log.
- append-only
- digest chain
Risk score and review queue
A readable reason behind every score.
The risk score is the sum of the contributions of the rules that fired. The specialist sees how much each rule moved the score and decides on that basis.
Select a claim in the queue; the rules behind its score are listed.
Approve it, send it for correction or hold the submission.
Your decision is added to the audit log as a new row and cannot be undone.
Pre-check queue
4| Claim | ICD-10 | SUT annex | Amount | Risk | Status |
|---|---|---|---|---|---|
| CLM-24817Chest CT | M54.5Low back pain | EK-2BFee-for-service | ₺4,820 | 78 | In review |
| CLM-24822Appendectomy package | K35.8Acute appendicitis, other | EK-2CDiagnosis-based package | ₺38,150 | 61 | In review |
| CLM-24830Biochemistry panel | E11.9Type 2 diabetes, without complications | EK-2BFee-for-service | ₺1,240 | 34 | Below threshold |
| CLM-24836Emergency care | R07.4Chest pain, unspecified | EK-2BFee-for-service | ₺2,960 | 12 | Below threshold |
Rule engine matches · CLM-24817
ruleset v3.8.1
- R-112Diagnosis–procedure mismatch+34
- R-047Prior authorisation missing+26
- R-203Procedure repeated within 30 days+18
Specialist decision
Risk threshold 40 exceeded; the submission decision is left to the specialist.
Audit trail
Append-only · each entry includes the previous hash
| Seq | Time | Actor | Event | Claim | Hash |
|---|---|---|---|---|---|
| 1044 | 09:12:06 | system | BELOW_THRESHOLD | CLM-24836 | 84ccf5a1…4818 |
| 1043 | 09:12:05 | system | QUEUED_FOR_REVIEW | CLM-24822 | 0aa4aeeb…e0b4 |
| 1042 | 09:12:05 | system | QUEUED_FOR_REVIEW | CLM-24817 | 65bd85e9…a866 |
| 1041 | 09:12:04 | system | SCORE_COMPUTED | CLM-24817 | d90f8ccb…c066 |
Example · fictional claims. ICD-10 codes are real; the SUT column shows the relevant annex of Turkey's Health Implementation Communiqué.
Audit log
Who decided what, under which rule.
To defend a decision, you have to show in full which data, which rule version and which person it was made with.
Append-only
Once written, an entry cannot be changed or deleted. Even a correction is added as a new entry.
Full context
Each entry holds the rule set version, a digest of the input, the score components, who decided and when.
Reproducible
A past decision can be reproduced exactly, with that day's rule version and data, and shown in an audit.
Exportable
Entries can be exported in a structured format for internal and external audit.
Access and isolation
The institution's data stays with the institution.
Each institution works in its own space. Queries, queues and logs cannot reach another institution's data, and roles decide who can see what.
- Isolation
- Each institution's data, queue and log are kept separate
- Query scope
- Institution ID required on every query
- Access
- Role-based, least privilege
Example roles
Institution admin Sets up users, roles and thresholds | Admin |
Revenue analyst Sees the queue, reports and trends | Read |
Review specialist Decides on items in the queue | Decide |
Auditor Reviews logs and decision history | Read-only |
Roles are configured to fit the institution. Shield does not diagnose or make treatment decisions; it works only in billing and pre-authorisation.
Demo and pilot
See Shield on your own claims.
We can run a demo on the rejection reasons you see most often. For a pilot, we write the scope together in a non-binding Letter of Intent (LOI).
- Hospital billing and revenue cycle units
- Pre-authorisation and SGK reimbursement teams
- Healthcare groups with several hospitals