Backwork

Code sources

Why each policy code entry has a source, what document and inferred_title_match mean, and how to treat inferred codes

Every code that Backwork links to a policy has a source. It says how Backwork knows that the policy covers the code.

sourceMeaning
documentThe payer's policy document lists the code.
inferred_title_matchThe document does not list the code. Backwork attached it because the policy title names the drug that the code bills for.

Inferred codes come from drug policies whose documents name the drug but do not list its billing codes.

Where you see it

  • API. Code entries in responses carry source, for example each policy in lookupCode with include=policies, the codes of getPolicy with include=codes, and the policies in checkPriorAuth. The reference page of each endpoint that returns it links here.
  • FHIR output. With format=fhir, each coverage item has an extension https://backworkhealth.com/fhir/StructureDefinition/code-source whose valueCode is the source. The item description of an inferred code says so.
  • Agent tools. check_coverage marks a policy matched through an inferred code with source: "inferred_title_match" and adds a known_gaps entry. find_policies lists those codes in inferred_codes. See Agent tools.
  • The Backwork app and public policy pages. An inferred code has the label Inferred from policy title, with the explanation "Not listed in the policy document; attached because the policy title names the drug." A document-backed code has no label. Lists put document-backed codes first, and a list that contains inferred codes says what the label means above it.

How to treat inferred codes

An inferred code is a lead, not a citation. Before you rely on one for a coverage, billing, or prior-auth decision:

  1. Open the policy's source_url and confirm the document covers the drug and the code, for example through its dosing or billing section, or the payer's code list.
  2. If you cannot confirm it, treat the policy as unconfirmed for that code and send the case to a person for review.
  3. Do not present an inferred code to your users as listed in the policy. Label it the way the Backwork app does.

In code, branch on the field:

const confirmed = policies.filter((policy) => policy.source === 'document');
const needsReview = policies.filter((policy) => policy.source === 'inferred_title_match');

The sandbox has an inferred example: the code entries of SBX03 have source: "inferred_title_match".

Grounding

Every code entry also has a grounding. It says whether Backwork found the code in the source text it kept for the policy.

groundingMeaning
groundedThe code is in the retained source text.
not_groundedBackwork's document pipeline read the code, but it is not in the retained source text.
no_source_textBackwork kept no source text to check.
not_checkedNot checked. Every inferred code is not_checked.

Treat a not_grounded code like an inferred one: confirm it in the policy's source_url before you rely on it. The Backwork app and the public policy pages label it Not found in the retained source text and show nothing for the other values. With format=fhir, each coverage item has an extension https://backworkhealth.com/fhir/StructureDefinition/code-grounding whose valueCode is the grounding. find_policies lists these codes in not_grounded_codes.

For when Backwork fetched the policy itself and how accurate its source is, see Source checks.

Last updated on

Error Handling

Understanding API errors and how to handle them

Source checks

When Backwork last fetched a policy, the hash of what it fetched, and the sampled accuracy audits measured for the policy's source

On this page

Where you see itHow to treat inferred codesGrounding