How Consistency checks a packet
See why Consistency shows some repeated text and leaves expected reuse quiet.
A delivered packet costs 6 SCU per page.
Consistency compares documents and checks the facts that came with them. It shows where a copied passage or a detail needs a closer look, so a reviewer can check the source.
flowchart LR
A["Packet in<br/>documents and known facts"] --> B["Compare<br/>documents and facts"] --> C["Plain answer<br/>what may disagree"] --> D["Proof<br/>where to check"]Read a result
A visible problem has a marked location and a plain headline and what_to_check step. Needs review asks a person to inspect that evidence. A repeated passage alone can be an honest template. The playground guide shows examples with a problem and an honest similarity.
For claims reviewers
The healthcare pack permits expected reuse, such as one doctor's template for the same procedure. A copied passage needs an extra sign that it belongs to the other patient before it becomes a visible pair finding. A single document can also disagree with its own claim or supplied facts.
For the Marisol and Desmond sample, compare the copied words with Desmond's recorded facts and claim. The female language, hysterectomy, age, and right-side text give you concrete places to check. Do not treat the count of flags as a verdict.
Technical details
Tells Decide What You See
A tell is a mistake that makes sense only if the text came from the other patient's file. A repeat without a tell is recorded as template_candidate with action none. A repeat with a tell is visible.
Preview uses one kind of tell, the cross-explained tell. It has two forms.
Identity carry-over. Patient Y's note contains a name, ID, or birth date that is wrong for Y and equal to patient X's. A shared surname or a shared birthday does not count. A name must match in full.
A two-attribute contradiction. Y's note contradicts Y on at least two independent attributes, and each wrong attribute fits X. The groups are sex, age band, and side or anatomy.
For example, the note says "he" and "left knee". Y is female, and Y's claim line is for the right knee. Both details fit X, a man with a left-knee claim. That is two groups (sex and side), both explained by X, so the pair is visible as reuse.identity_swap with tell: cross_explained and tell_document naming Y's document.
Each attribute needs a source for the patient's own value:
| Attribute | Where the engine reads the patient's own value |
|---|---|
| Sex | facts.subjects[subject_ref].sex in the manifest |
| Age band | facts.subjects[subject_ref].birth_year, else the birth date on the document, against issued_at |
| Side and anatomy | The patient's own claim lines: the LT, RT, or 50 modifier and the code family |
An attribute with no source is skipped. A packet with no facts and no claim lines can only show a tell through identity carry-over.
One wrong detail by itself is not a tell. A note that says "she" for a male patient is a sloppy note, and honest clinics write sloppy notes at a measurable rate. That note gets a local finding (below) and does not make a template pair visible.
The spec defines three more tells that compare against history: rare values, rare findings text, and a rare shared typo. They need the memory store, which Preview does not have, so they do not fire yet.
Permissions Allow Expected Reuse
The pack says which sections may repeat, and for whom. The healthcare test pack sets:
| Section role | May repeat when |
|---|---|
| Narrative | Same doctor and same procedure family. Patients may differ. |
| Findings | Same doctor and same procedure family. |
| Signature | Same doctor. |
| Attestation | Same encounter. |
| Form boilerplate | Always. |
Dr. Amari uses one personal template for 40 lumbar injections. Every narrative matches every other. The narrative permission covers the pair, so nothing is shown.
A permission counts only when the ref it relies on is trusted. The engine cannot tell a real second doctor from a relabelled one by a ref you send. In Preview no ref is marked trusted yet (that org setting is planned), so an allowed repeat comes back as permitted_only instead of permitted. Both carry action none. Neither is ever shown as a warning.
Tiers Set The Action
| Tier | action on a visible finding | What it means |
|---|---|---|
strong | review | Stands on its own. Send it to a person. |
medium | warn | Needs its locations to be read. Show it to the reviewer. |
weak | none | Supports other findings only. |
Every outcome other than visible carries action none:
outcome | Meaning |
|---|---|
visible | A tell or a local rule opened it. The action follows the tier. |
permitted | The pack allows this repeat under a trusted ref. |
permitted_only | The pack would allow it, but the ref it relies on is not trusted. |
template_candidate | A repeat across a permission with no tell. Probably a shared form. |
values_repeat | The same values (dose, level, side) repeat across patients. Recorded for review. |
pull_forward | A note copied forward for the same patient with only the date changed. |
recorded | Any other quiet record. |
withheld | The match lies outside what your key may see. Only the fact of a match is returned. |
When several rules fire on one pair, the highest tier wins and the others stay as support. A quiet record never replaces a visible finding.
Nothing here produces BLOCK. The response has no document verdict. You decide what review and warn do in your workflow.
Local Rules Check One Document
Some findings need one document and the facts you sent. They do not need a match. In the healthcare test pack:
| Rule | Fires when |
|---|---|
lexicon.pronoun | The note's pronouns contradict facts.subjects[...].sex. |
lexicon.anatomy | The note's anatomy contradicts the document's own claim lines. |
lexicon.in_person_finding | A telehealth visit note describes an in-person exam, such as "on palpation". |
section.required_empty | The findings section is present but empty. |
placeholder.literal | A template placeholder was left unfilled. |
detail.telehealth | A telehealth claim line (modifier 95, or place of service 02 or 10) on codes 99202 to 99215 has a note that lacks a detail the pack requires for telehealth visits. |
The claims and jewelry test packs add checks on fields and numbers the sectioner reads from the page. Some read one document; others compare the same field across the documents of one claim or item. They do not need a tell, because a total that does not add up or one stone with two carats is already a contradiction.
| Rule | Pack | Fires when |
|---|---|---|
check.bill_total | P&C claims | A bill's printed total is not the sum of its own lines, tax, and fees. |
check.dated_before_loss | P&C claims | An estimate, supplement, or invoice is dated before the loss date it prints. |
entity.bill_number_new_claim | P&C claims | One shop's invoice or estimate number appears on two different claims. |
line.bill_on_new_claim | P&C claims | Most of a bill's dated, priced lines repeat on a bill filed under another claim of the same claimant. |
line.billed_twice | P&C claims | The same line (work and amount) appears on two bills of one claim. A supplement that restates the estimate is not counted twice. |
field.loss_account_conflict | P&C claims | Two loss accounts on one claim give a different cause or a different damaged part. A signed correction is not read. |
field.stone_mismatch | Jewelry | One item's documents disagree on the stone's report number, shape, carat, measurements, color, or clarity. The grading report is the record. |
field.report_number_other_stone | Jewelry | A grading-report number already filed under another item appears on a stone with a different shape, carat, or size. |
check.carat_measurements | Jewelry | The stated carat cannot fit the stated shape and measurements. |
check.items_total | Jewelry | A worksheet's priced lines do not add up to its printed total. |
document.type_mismatch | All | The document-type reading of page 1 is not the expected_type you sent. Confusable pairs, such as an estimate and an invoice, do not fire. |
A local finding stands on its own document. It does not open a finding on a template pair, for the reason given under tells.
New rules are evaluated first
Every new rule runs in evaluation mode first. Its results go to a review record. They do not appear in findings, set an action, or change money or cases.
After a weekly blinded sample is reviewed, a rule can become visible if the lower confidence bound on its precision clears 0.80 for medium or 0.90 for strong. A new rule version starts evaluation again, even when it reuses a promoted rule's id.
In Preview no rule is promoted. A normal organization's response therefore has an empty findings list, even when the engine recorded a result. Evaluation runs show those results to test organizations only. The confidence field is null while a rule has no measured precision.
Read the response fields
The API reference lists every field of a finding and its locations, with a worked example.