How it works

Fourteen stages, no magic step.

Every stage is a durable job with its own row, its own retry policy and its own idempotency key. Nothing is chained inside one request, so a replay against a corrected crosswalk costs a rerun and nothing else.

  1. 01

    Ingest

    Fax, email, upload, or a phone. The bytes are stored exactly as received and never modified. Everything downstream derives from that original.

  2. 02

    Normalize

    Pages are rendered and a text layer is extracted where one exists. Native text is far more accurate than re-reading pixels, so it is used alongside the image rather than instead of it.

  3. 03

    Reassemble

    Transmission headers are located and stripped, and a packet that arrived as three separate faxes is put back together in page order.

  4. 04

    Decode

    Barcodes and machine readable marks are read where present. Where no reader is wired, the stage reports that honestly rather than claiming it looked.

  5. 05

    Triage

    Blank pages, duplicates and cover sheets are separated from pages that carry intake value.

  6. 06

    Split

    One transmission becomes one packet per patient, using document boundaries rather than a fixed page count.

  7. 07

    Classify

    Each document is identified by type, form family and revision. An unrecognized revision extracts against its family and is flagged, never dropped.

  8. 08

    Extract

    Fields are read against the canonical schema for that document type. The model is never asked for a derived value, so it cannot invent one.

  9. 09

    Resolve

    Values from different documents are reconciled by a precedence table. Conflicts that cannot be settled by rule are raised, not averaged.

  10. 10

    Derive

    Codes that follow from other codes are computed by crosswalk. A procedure plus a confirmed laterality selects a kit, and the kit selects the HCPCS.

  11. 11

    Validate

    Payor rules, documentation requirements and code checks run as configuration. Each finding names the rule that produced it.

  12. 12

    Readiness

    The order is either submittable or it is not, and the reason is a list of named gaps rather than a score.

  13. 13

    Review

    Anything the system declined to decide is presented to a human with the page and region it came from, so the check takes seconds.

  14. 14

    Deliver

    A complete order is written into the destination system, with the response recorded against the case.

The canonical schema

One vocabulary, and mapping happens at the edge.

Every customer's forms are different and every destination system wants different names. If you let either of those reach the middle of the product, you end up writing code per customer, which is the failure this category is known for.

IntakeLinx has one canonical schema. Documents map into it on the way in, destinations map out of it on the way out, and the middle never changes. The schema itself is data rather than table structure, so adding a field is a row, not a migration and a deploy.

The value envelope

A canonical field is not a string. Each one carries what was literally on the page, what that normalized to, whether it was present at all, how it was resolved when documents disagreed, whether a human has confirmed it, how confident the read was, which document and region it came from, and how it was derived if it was not read.

Those are separate axes and they are never collapsed. "Not on the document", "illegible" and "nobody has looked at it yet" are three different states, and a system that stores all three as empty cannot tell you which one you are looking at.

See it run on a real packet.

Yours, redacted, or one of ours.

Book a walkthrough