The short answer
“Ask an experienced coder why a claim got denied and you will often hear that a payer always wants it that way. That sentence holds a lot of value and a lot of risk. It is knowledge that never made it into a manual. It lives in someone’s head, gets passed along over coffee, and walks out the door when that person changes jobs. A Playbook is how that knowledge becomes software.”
The Problem, and What a Playbook Is
Coding rules are not one rulebook. They are layers, and the layers do not always agree. A coder holds all of this in working memory while reading a chart. A good one does it well, but it does not scale, it does not update itself, and it cannot be audited in any systematic way. When the rule changes, you hope everyone heard.
The layers of a coding rule
Specialty
Cardiology bills differently from orthopedics, and behavioral health differently from wound care.
Payer rules
Each payer's own contract terms, modifier preferences, documentation expectations and quirks.
Coverage policies
National and local policies that say when a service is considered medically necessary.
National standards
ICD-10, CPT and HCPCS code sets, plus federal edits that stop unbundling or implausible service counts.
A Playbook is a structured rule set for one specialty, one payer or one condition. It turns what experts know into something a machine can apply consistently, and it is written down, versioned and reviewed like any other business asset. In Grelin’s model, the people who write the rules are domain experts: coders, clinicians and billing specialists who have worked thousands of patient histories. They state a rule in plain language, and the engine turns that statement into working software and tests it against real patient records before it goes live.
What Is Inside a Playbook
A typical Playbook covers four kinds of logic. The examples here are illustrative, not a description of any specific payer’s real policy.
Baseline coding rules
Valid code sets for the date of service, edits that prevent unbundling, plausible unit limits, and national or local coverage requirements.
Specialty rules
The usual procedures, the diagnoses that support them, the modifiers that apply, and what a well documented encounter looks like for that specialty.
Payer rules
Where the that payer always wants it that way knowledge lives: modifier requirements, prior authorization conditions, documentation thresholds, place of service and filing limits.
Workflow rules
What happens when a check fails: flag it for a coder, ask the provider a question, hold the claim, or let it through. A rule without a next step is just a warning.
A simple example
One payer covers a procedure only after the patient has tried conservative treatment for a set period, and the record must show it. Written in plain language, that rule is short. Turned into a working check, it reads the patient’s history, looks for evidence of the conservative treatment and its duration, and reports whether the requirement is met. If it is not, the Playbook produces a gap: here is what the policy requires, and here is what the record does not show yet. Notice what that check needs. It needs the patient’s whole history, not just today’s note.
Why this beats keeping knowledge in people’s heads
Consistency
The same rule, applied the same way, to every chart, at every location, on every shift.
Visibility
Because the rules are written down, you can read them, question them and improve them.
Maintainability
When a payer changes a policy, you update one rule in one place rather than retraining a team.
Auditability
If someone asks why a chart was flagged, the answer points to a specific rule, not to a hunch.
Speed to new settings
Adding a specialty means adding its Playbook. The reading and reasoning machinery stays the same, so a new Playbook ships in weeks.
How AI Learns the Rest
Playbooks handle what can be written down. But clinical text is messy, and payers have habits that are not fully documented anywhere. An AI system does not absorb payer logic just by reading notes. It works from several sources, under human governance, and the general pattern looks like this.
Explicit rules come first
The organization encodes known payer policies, contract terms and coding edits. The payer's policy is the authority. The AI enforces it consistently rather than guessing at it.
Historical data fills in the patterns
Systems are tuned on past charts and claims, connecting how providers write to the code combinations payers have historically accepted.
Denial patterns point to weak spots
Grouping denials by payer, reason, procedure family and specialty reveals where rules are missing or too loose.
Documentation is checked against the note
A language model reads the narrative and asks whether it actually supports the diagnosis, procedure, level of service and modifier, telling apart ruled out from confirmed, planned from performed.
Human feedback tunes the system
When a coder accepts, edits or rejects a suggestion, that decision adjusts rules and confidence settings over time.
Everything refreshes continuously
Payer policies, code sets and state rules change constantly. A system accurate at launch drifts if nobody maintains it.
The catch:
Learning from history has a trap. If past coding contained mistakes, a model trained on it can repeat them smoothly and at scale. Historical approvals show what a payer paid, not necessarily what was correct. A claim that slipped through is not proof it was right. That is why explicit rules anchor the system, data fills in the parts rules cannot capture, and human review keeps both honest.
Chart.ai’s approach is built around expert authored Playbooks rather than a model quietly tuning itself on whatever it sees. Each rule change is made centrally and checked by a certified coder and a clinician before it goes live. Learning still happens, but through the front door: results are measured against the customer’s own reviewers, and a live customer adds payer and specialty rules over time. The system improves through governed rule changes people can inspect, not through opaque drift.
Chart.ai Core Coding
Chart.ai is the Healthcare Intelligence layer Grelin built on its Playbook engine. It does not just suggest a CPT code. It answers a harder, more useful audit question: does this record actually support this code, this level of service, this modifier and this charge, for this patient and this payer?
How Chart.ai works through a chart
Gather
Pulls in notes, letters, reports, results and history from every source, not just the encounter being coded.
Assemble
Builds one picture of the patient across every condition, setting and year, so a conservative treatment trial documented months ago is not missed.
Reason
Checks that picture against the clinical and payer rules in the relevant Playbook, where specialty, payer and baseline logic do their work.
Produce
Generates findings, care and coverage gaps, a risk rating, and suggested codes with draft wording, each linked to the rule and the patient text behind it.
Deliver
Sends that into the EHR, billing tool or care program, so a human can act on it where they already work.
Every finding carries its evidence
A sentence in the note and a rule in the Playbook, not the system said so
Traceable
The evidence trail is the point
Every finding traces to a sentence in the record and a rule in the Playbook. In an audit or an appeal, the system said so is not an answer. This sentence and this rule is.
Fast enough to matter
Checks finish in about a second. The most useful moment to catch a gap is before the provider signs the note. After that, the same fix means an addendum, a query and a delay.
A human has the final word
Chart.ai produces intelligence. It never diagnoses, never writes to the chart on its own, and never acts in its own name. A coder or provider reviews and signs.
For a coder, the practical effect is a shift in where time goes. Less goes to hunting through a chart for context, because the layer has already assembled the history. Less goes to remembering which payer wants what, because that is in the Playbook. More goes to judgment: reviewing flagged gaps, deciding on edge cases, correcting rules that are out of date, and making sure the output holds up under audit. It also puts a premium on the coders who know the rules well enough to write them, which is exactly who authors the Playbooks.
How to judge any tool that claims to do this
Whichever vendor you are considering, a few questions separate substance from marketing.
Where do the rules come from, and who checks them?
Look for named expertise and a review process, not just a claim that the model learned it.
Can every finding be traced to a rule and a sentence in the record?
If the trace is missing, the output cannot be defended in an audit or an appeal.
What does the tool look at: one visit, or the whole patient history?
A single visit view cannot see the evidence documented months ago in another setting.
How are payer and code set updates handled, and how fast?
Rules change constantly, so ask how a change is made and verified before it ships.
How is accuracy measured, and against whom?
The right benchmark is your own certified coders on your own charts, not a vendor headline.
What happens when a payer changes a policy mid year?
A good answer describes a central, reviewed rule change, not a scramble across teams.
Who has the final word on a code?
A person should review and sign. The tool produces intelligence, the human decides.
The bottom line
Rules without reading cannot handle real documentation, and reading without rules drifts from what payers require. Chart.ai puts them together so people can check: experts write the rules, the engine applies them across the whole patient, every finding comes with its evidence, and a human decides.
Frequently Asked Questions
What is a Playbook in healthcare coding software?
A Playbook is a structured rule set for one specialty, one payer or one condition. It captures what correct coding and documentation look like in that context, including code and edit rules, payer requirements, and what to do when a check fails. In Grelin's model, domain experts write the rules in plain language, and the engine turns them into working software that is tested against real patient records before it goes live.
How do Playbooks encode payer specific logic?
They record the rules a payer actually applies, such as modifier requirements, prior authorization conditions, documentation thresholds and place of service rules. Because these are written down and versioned, the same check runs the same way for every chart, and a policy change is made once in one place instead of relying on people to remember it.
How does AI learn payer specific coding rules?
Generally through a combination of sources: explicit payer policies encoded as rules, historical charts and claim outcomes, analysis of denial patterns, checking documentation against the clinical note, and feedback from coders who accept or correct suggestions. The payer's actual policy remains the authority, and the system needs regular updates because rules change.
Can AI just learn payer rules from past claims?
Not safely on its own. Past claims show what a payer paid, not necessarily what was correct, so a model trained only on history can repeat old mistakes at scale. The more reliable approach anchors the system in explicit rules, uses data to fill in patterns, and keeps humans reviewing the output.
What does Chart.ai core coding do?
Chart.ai reads a patient's full history, checks it against the relevant clinical and payer rules in a Playbook, and produces findings, gaps, risks and suggested codes with draft wording. Each one is linked to the rule and the patient text behind it. In effect it answers whether the record supports a given code, level of service, modifier and charge for that payer.
How does Chart.ai keep its rules current?
Rule changes are made centrally, and each one is checked by a certified coder and a clinician before it goes live. A live customer can also add payer and specialty rules over time, and new Playbooks ship in weeks rather than requiring a rebuild of the engine.
Does Chart.ai replace coders?
No. Chart.ai produces intelligence for a human to act on. It never diagnoses, never writes to the chart on its own, and never acts in its own name. Coders and providers review and sign. What changes is where their time goes: less searching and remembering, more judgment on flagged gaps, edge cases and audit defensible decisions.
Related Article
AI-Assisted vs Autonomous Medical Coding