Scanned Claims PDF Intake in 2026 (Privacy, Retention, and Signing Evidence)

Short answer: a US/EU SaaS should use three asynchronous PDF endpoints for scanned claims intake: acceptance, state inspection, and authorized derivative retrieval, with immutable original bytes and links from every review decision and generated invoice to hashes, policy versions, and signature evidence.

At 09:17, the page says INVOICE_EVIDENCE_GAP: an approved marketplace claim has reached invoice generation, but the signer cannot prove that the order adjustment came from the same PDF rendition a reviewer saw. The renderer is healthy. Retrying it would only make the queue older.

That is a synthetic drill, not a production incident, and it exposes the selection criterion that endpoint checklists usually miss. A scanned-claims pipeline doesn't merely convert files. It turns disputed source material into a decision and then into a signed invoice. The least complex acceptable design preserves that chain without making the caller wait for page rendering, extraction, review preparation, and signing in one request.

What should PDF endpoints expose for US/EU scanned claims intake?

Expose three logical capabilities: accept an original, inspect processing state, and retrieve one named derivative. They can live in one deployment. They shouldn't be fused into an “upload and return everything” call, because admission has a short and predictable job while scan processing has variable work per page.

The acceptance contract needs tenant, region, retention class, media type, an idempotency key, and the byte stream. Its receipt needs a stable document ID, an accepted state, and an acceptance time. State inspection should report named stages such as validation, rendering, extraction, review preparation, approval, and release. Retrieval should name the artifact being requested rather than returning an ambiguous “current PDF”: original evidence, page rendition, extracted fields, or the invoice produced from approved order data.

These are owned contracts, not prescribed public URL paths. That distinction matters. Callers depend on stable document states and evidence fields; an adapter can move rendering or extraction between implementations without forcing every application to learn a new workflow.

Keep that boundary explicit.

package claims

import (
    "context"
    "io"
    "time"
)

type IntakeRequest struct {
    TenantID       string
    Region         string
    RetentionClass string
    IdempotencyKey string
    MediaType      string
    Body           io.Reader
}

type Receipt struct {
    DocumentID string
    State      string
    AcceptedAt time.Time
}

type Evidence struct {
    DocumentID    string
    ArtifactName  string
    ContentHash   string
    PolicyVersion string
    ProducedAt    time.Time
}

type Intake interface {
    Accept(context.Context, IntakeRequest) (Receipt, error)
    State(context.Context, string) (string, error)
    OpenArtifact(context.Context, string, string) (io.ReadCloser, Evidence, error)
}

For browser selection and display, keep binary data binary. The Web Blob interface represents immutable raw data; it can be read as text or an ArrayBuffer, and it can be converted into a readable stream. A Blob is therefore a reasonable client-side container for a selected PDF. A Blob URL is still a browser convenience, not a durable identity, an audit event, or evidence that the reviewer and signer used the same artifact.

The distinction is small in code and large on call.

Prove the invoice before optimizing the scan

Start with the final assertion: “this signed invoice was generated from this approved order revision, whose adjustment was authorized after review of this claim artifact.” Each noun needs an identifier, each transition needs a timestamp and actor, and each artifact needs a content hash. The chain should connect the immutable original, the specific page rendition shown for review, the extraction or structured fields used to assist that review, the decision, the order revision, the invoice template version, the produced invoice, and its signature record.

A derivative never silently replaces its predecessor. If the rendering policy changes, the new rendition gets a new hash, production time, and policy version. If the order is amended, invoice generation points at the new approved revision. This is less convenient than a mutable latest.pdf, but mutability destroys the answer to the first question an auditor or incident commander will ask: which bytes did the reviewer actually see?

An evidence check can remain deliberately boring:

package claims

import "errors"

type Link struct {
    SubjectID   string
    SubjectHash string
    Action      string
    ObjectID    string
    ObjectHash  string
    Policy      string
}

func ValidateRelease(review, invoice Link) error {
    if review.Action != "approved" || invoice.Action != "generated" {
        return errors.New("release evidence is incomplete")
    }
    if review.ObjectID != invoice.SubjectID || review.ObjectHash != invoice.SubjectHash {
        return errors.New("approved revision does not match invoice input")
    }
    if review.Policy == "" || invoice.Policy == "" {
        return errors.New("policy version is missing")
    }
    return nil
}

The code does not verify a cryptographic signature; that belongs behind a signing boundary appropriate to the system. It verifies the application-level relationship that must exist before signing is permitted. Don't ask a signer to repair missing provenance. By then, the useful evidence may already have been overwritten.

This changes the alert path. The page should identify region, tenant cohort, SLO window, queue age, and the first evidence transition that failed to complete. “PDF failed” merges malformed input, slow processing, blocked review, expired evidence, and signing delay into one useless symptom. Document IDs belong in traces and controlled audit storage, not metric labels; claim text, names, addresses, and raw filenames don't belong in either general metrics or routine logs.

Work backward from invoice availability. A signature-stage page should have been preceded by an alert on growing age in the release queue, which should have been preceded by claims stalled in review preparation or approval. In the 09:17 drill, the on-call first checks whether accepted claims are accumulating before review, whether approved revisions are accumulating before release, and whether only one region is affected; those three answers separate processing capacity, workflow ownership, and regional eligibility without opening a claim or reading personal data. Instrument every state transition with opaque document ID, tenant, region, stage, attempt, input byte count, page count when known, policy version, and timestamps. A multi-window SLO burn alert plus a queue-age guard gives the on-call both customer impact and an actionable location. Paging on one slow document is usually noise; waiting until the oldest document violates the customer objective is late.

One counter isn't enough.

Fidelity and latency belong to different budgets

Scans make “accepts PDF” almost meaningless as a fidelity requirement. A source can include photographed pages, rotation, faint marks, annotations, and mixed dimensions. Extracted text may be adequate for routing and still be inadequate as evidence, so review should render from the exact evidence version it approves, while structured fields remain a named derivative with provenance.

Use two latency budgets. Admission authorizes tenant and region, validates the envelope, records policy, durably accepts bytes, and returns a receipt. Rendering, extraction, classification, and review preparation continue asynchronously. This keeps variable page work out of the caller's timeout and lets idempotency collapse retry attempts into one logical intake.

Capacity planning needs arrivals, bytes, pages, service time, and retry demand. Consider a planning input of 30 documents per second, an assumed burst factor of 4, and an observed workload estimate of 8 pages per document: admission must be tested near 120 documents per second and page workers near 960 pages per second before retries. Those numbers are arithmetic examples, not benchmarks. Replace every one of them with measured distributions from the actual claim mix, especially tail page counts and page-processing time, then size each regional pool against its SLO and failure reserve.

Backpressure must be visible in the contract. Bound bytes and pages, preserve idempotency at admission, cap attempts by stage, and quarantine work whose automated processing cannot complete without copying sensitive contents into a general-purpose diagnostic queue. I'm not sure a fixed extraction-confidence threshold can transfer between medical forms, repair estimates, and handwritten attachments. A labeled sample from the intended claim population, reviewed against the actual business decision, is what would settle it.

Test artifacts, not just task completion. Compare page count, dimensions, orientation decisions, hashes, and production policy. Then run a release drill in which a rendering version changes between two claims; the older approval must continue to point to the older rendition, and the newer rendition must not inherit approval merely because its document ID matches.

Make privacy and retention part of the state machine

“Process in the EU” is not an operable control. Region selection has to constrain every copy created by the workflow: original storage, processing queues, temporary page images, extracted fields, audit evidence, backups, and support access. If a processor is ineligible for a document's region, dispatch should leave the bytes where they are and keep the item pending for an eligible worker.

Retention also needs explicit transitions. Assign policy at acceptance, calculate expiry per artifact, enqueue deletion durably, verify it, and keep only the minimal tombstone needed to show policy execution. A legal hold, when required by the SaaS's own obligations, is an authorized state change with an audit event. A late retry must not recreate an artifact after its deadline.

Short-lived retrieval authorization should identify one artifact, not grant broad document access. Support tooling should expose metadata before content and record why content was opened. Opaque correlation IDs make access review possible without scattering claim details through free-form logs.

The catch is capacity isolation. Regional worker pools lose some statistical multiplexing, releases need region-aware gates, and one region can queue while another is idle. A global processor is not suitable when contractual policy requires regional confinement. A managed regional capability is also a poor fit when it cannot export the evidence needed to prove artifact lineage and deletion; self-hosting may offer tighter control, but it transfers patching, scaling, processing operations, and incident response to the platform team.

No row has a universal winner. Stick with the existing implementation when it can pass the evidence drill, meet the regional SLO under measured burst load, and prove deletion without adding another on-call surface. Change ownership only where a failed criterion is important enough to fund migration and operations.

Close the loop with alert tuning. Run duplicates, pause one regional pool, change a rendering policy, request deletion during processing, and regenerate an invoice from the same approved order revision. The expected result is one logical intake, explicit queue growth, immutable evidence links, policy-respecting deletion, and a repeatable invoice relationship. Set burn and queue thresholds from the service objective and measured traffic, then review pages that caused no action. Too sensitive, and the team learns to ignore the evidence alert; too loose, and the first useful signal is the unsigned invoice the alert was meant to prevent.

References

• https://developer.mozilla.org/en-US/docs/Web/API/Blob