​
Why this step exists

Two reasons, and both come back to a constraint on how large language models work. 1. LLMs have a fixed reading window. Every time you ask a question, the model has to be handed both the question and whatever source material it should read. That window is finite — large enough for a memo, far smaller than a 600-page medical record. If we tried to stuff a whole big doc into every question, the model would either reject the request, run unaffordably slow, or skim past most of it. Preparation solves this by reading the document once, page by page, and producing a compact, structured per-page summary that captures the substance of each page. From then on, your questions are answered against that compact index instead of the raw PDF — fast, focused, and citable back to the source page. 2. We don’t let our LLM provider keep your data. Bob is run under a HIPAA Business Associate Agreement and Zero Data Retention with our LLM provider — meaning none of your case data is stored, logged, or used for training on their side. The trade-off: nothing we send is remembered between requests. Every question is a fresh transaction; whatever the model needs to see, we have to send. That makes context efficiency critical. Without preparation, every Ask query for a large doc would re-upload the entire PDF, every time — slow, expensive, and unsustainable. With preparation, we send only the small, indexed slices that are relevant. Same answer quality, a fraction of the context, no data sitting on someone else’s server. One-time cost, ongoing benefit. Preparation is the up-front cost that buys you a queryable doc. Run it once, ask as many questions as you want — including questions nobody on your team has thought of yet.

​
What it is

Small documents are read directly when you ask a question. Large documents are first turned into a per-page index — that’s preparation. Once a doc is prepared, future questions are fast and don’t repeat the work. You’ll usually only see preparation the first time someone in your org opens a large doc in Ask.

​
What gets captured per page

Preparation reads every page and records a structured summary of it. For each page:
  • Topic — a one-line label (e.g. “History of present illness”, “Lab results: CBC”, “Operative report — knee”).
  • Summary — a short narrative of what the page shows and what it tells you.
  • Key points — the specifics worth knowing: abnormal lab values, dosages, decision points, conclusions, dates of significance.
  • Page transcription — a faithful, structure-preserving copy of the page in markdown. Headings stay headings, tables stay tables, forms keep their label-value pairs, checkboxes ([x] / [ ]) are preserved. Handwriting and unreadable regions are marked rather than guessed at.
  • Structure tags — hints like table, list, form, narrative, procedure, diagram, spec so pages can be filtered by what they visually contain.
  • Medical entities — every distinct item visible on that page, grouped by type:
    • Diagnoses with ICD codes when printed
    • Medications with dose, route, frequency, and NDC when printed
    • Procedures with CPT codes and dates when printed
    • Providers with role and NPI when printed
    • Encounters (visit dates, type, facility)
    • Body parts referenced
    • Dates (raw and ISO-normalized when unambiguous, with kind: encounter, service, result, etc.)
    • PII (names, DOBs, MRNs, addresses, phones, emails, insurance IDs)
  • Complexity flag — when the model isn’t fully confident it captured a page (dense lab table, handwriting, low-quality scan), it marks the page as complex with a short reason. Today this is informational; see What’s coming below.
Everything is keyed to the page it came from, so any answer or filter can point you back to the exact page.

​
What this unlocks today

  • Faster, more grounded Ask answers. Questions that used to need re-reading the whole doc now read the per-page index — answers come back faster and with page-level citations.
  • Works on docs of any size. Documents that were too large for inline answering are queryable as soon as preparation finishes.
  • Stable across re-runs. Prepared output is cached. Re-running on the same doc with the same settings is instant — no duplicate cost or wait.

​
What’s coming

The per-page captures are designed to drive features beyond Ask. Planned uses:
  • Page picker / page-level navigation. Jump straight to “the four pages that mention this medication”, “every page with abnormal lab flags”, or “all operative-report pages in this record”.
  • Entity filters and roll-ups. Per-doc and per-Client-File summaries built from the structured entities — e.g. every diagnosis ever recorded across every prepared doc, with citation back to the source page.
  • Automated CRM field capture. Entities like provider names, encounter dates, and diagnoses can pre-fill Client File fields and surface for review rather than being typed by hand.
  • Cross-document timelines. Encounter and date entities across all prepared docs in a record, ordered chronologically, with click-through to the page that contains each event.
  • Targeted re-look on complex pages. Pages flagged as complex will be re-read with stronger settings to fill in gaps the first pass missed — without re-doing the whole document.
  • Smarter Ask retrieval. Answers will draw on entity types that match the question (e.g. drug questions consult only pages that mention drugs), rather than scanning every page summary.

​
What you’ll see

While preparation is running:
  • A chip appears in the footer with the document name, a spinner, and a progress bar.
  • In the chat, “Preparing this document…” shows with a live N/M pages counter.
When preparation is done:
  • The footer chip turns green and “Ready” — clicking it jumps back to the doc.
  • The chat unblocks and you can ask questions.

​
How long it takes

Roughly a few minutes per 50 pages, depending on the document and current load. The chat header shows a live page counter so you can see progress.

​
Can I leave the page?

Yes. The footer chip keeps tracking the run; when you come back, the doc will either be ready (green chip) or still preparing. Closing the browser doesn’t cancel the run.

​
Troubleshooting

​
”Almost ready” sits there

“Almost ready” means every page has finished and the system is finalising. The transition to “Ready” is normally instant. On rare occasions the very last “done” signal can be missed by the live connection. When this happens:
  • The app rechecks the true status every ~10–15 seconds in the background and will flip the chip to green and unblock the chat on its own. You normally don’t have to do anything.
  • A page reload always shows the true state — useful if you don’t want to wait.

​
The page counter stops advancing for several minutes

That’s different from the brief “Almost ready” pause described above — it suggests the run actually stalled. Reload the page. If it still shows preparing after a reload, contact your admin: the run may have failed.

​
I don’t see a “Prepare” button on a small doc

Small documents are answered directly without a preparation step, so there’s no button to press. Just ask your question.

​
Getting help

  1. Use the help button in the lower-right corner of the app (when your org has it enabled).
  2. Contact your organization admin.