The problem
Referral packets, clinical notes, lab reports, and prior-auth correspondence still arrive as faxes, scans, and portal downloads, and somebody on your intake team re-keys them into the EHR and the billing system by hand. That is slow, expensive, and error-prone, and every downstream 2026 rail (prior-auth APIs, eligibility, clean claims) presumes structured data your fax machine does not produce.
The usual fix (a generic OCR vendor) hands you raw text and walks away. The clinical structure, the FHIR shape, the validation, and the PHI handling are all still your problem, and a silent misread lands straight in the chart.
How it works
You hand the digitizer a document (fax, scanned PDF, portal download). From there the span does the work:
- ingests the raw document into the processing cabinet under a consent gate (no token, no run),
- classifies it against a medical intake taxonomy (referral packet, clinical note, lab result, imaging report, and so on),
- extracts the text layer from the scan or native PDF,
- runs medical-specific structured extraction (diagnoses, medications, orders, dates, provider identity),
- normalizes the result to FHIR resources (or a flat field map if you prefer),
- validates the structured output against the source, field by field, with a confidence score on each,
- de-identifies PHI on anything leaving the consent boundary.
The whole thing is composition on AYA's verification spine (seven existing capabilities wired together as data, no bespoke black box). Low-confidence fields are flagged and routed to human review, never silently asserted.
What you get
Per document: a validated structured record (FHIR bundle or flat fields), a field-level validation report with confidence scores, the low-confidence fields flagged for a human, and PHI scrubbed from anything that leaves the boundary. In plain terms, a data feed you can defend field by field, instead of a re-keying backlog and a prayer.
Who it is for
Specialty clinics, MSOs, and referral-heavy practices with fax-first intake, RCM and intake-outsourcing vendors, and digital-health companies onboarding paper records. It lands hardest where referral volume and prior-auth documentation have made manual re-keying the bottleneck, and it sits directly upstream of the Luigi prior-auth, eligibility, and clean-claim lines.
Pricing
Pricing is a set of hypotheses we are validating, not a committed price sheet.
- Batch digitization, a one-time pass over your backlog (per document or flat batch fee), with the validation report per document.
- Value-metered, per validated document processed monthly, priced below the loaded cost of the manual re-keying it replaces.
- Platform, continuous intake wired to the fax line and portal drops, feeding prior auth, eligibility, and clean claims directly.
Proof (dogfood)
We run the digitizer on ourselves first. AYA feeds its own synthetic medical-document corpus (synthetic referral packets, notes, and lab PDFs from the Luigi test fixtures) through the exact deliverable a customer would buy: ingest, classify, extract, FHIR-normalize, validate, scrub. All of it as a structural dry run on synthetic documents, with no real patient data anywhere.
What is actually true today: the deliverable pattern (AYA-3SPN-LUIGI-MEDICAL-DOCUMENT-DIGITIZER-v1) is on disk, PQS-scored at 91 (Grade A), and all seven of its composed capabilities resolve to existing atoms, including the Luigi-owned medical extraction and FHIR normalization atoms already in the healthcare estate.
Honest note
This is a structural build, not a live-customer result. Extraction accuracy on real-world scan quality is unmeasured until we run a design-partner corpus, and we will publish what we measure rather than a marketing number. The validation step exists precisely because OCR is not perfect: bad scans surface as flagged fields, not silent errors. EHR write-back is deliberately out of scope (the output is a validated feed; pushing into an EHR is a separate, explicitly gated integration). Real runs need a consented document corpus and a booted system. We would rather tell you that than sell you a text dump.
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*