Healthcare & Disability /Document processing interactive demo field guide · 8 min

Provider Intake Sorter

Reads every inbound referral — GP chronic condition management plan, NDIS plan, My Aged Care RFS, scanned form, email — and lands each one in the right queue with the funding fields already filled.

Open the live demo

theater/demos/healthcare_provider-intake-sorter.html · sandbox · read-only

Open

FIG. 1

The live demo, running on fabricated data. Open it to step through the full flow — every output is shown for a person to approve before anything happens.

How it would work

Reads each inbound referral the way your intake officer does, drafts the structured record field by field, and flags any funding or scope mismatch for a person to resolve before anything is committed.

Input 01

Every inbound referral

The mixed daily intake: GP chronic condition management plan PDFs, NDIS plan extracts, My Aged Care referrals for service, scanned handwritten intake forms, emailed self-referrals.

Agent 02

Reads, drafts, scope-checks

Extracts the identifier and funding fields with a per-field confidence score and source line, then checks the requested support against the practice's registered scope — AHPRA registration, NDIS registration groups, MBS items.

Output 03

A draft, for your review

A drafted intake record per referral with every field, its confidence and a flag summary — the intake officer approves, edits, reassigns or rejects before any record is committed to the practice system.

Where it works well

It does the field-by-field retyping every referral needs, in full, and shows its source.

Best for a multi-disciplinary allied health practice taking referrals across mixed funding: Medicare CDM, NDIS Capacity Building, Support at Home.
The messier and more varied the inbound formats, the more the recaptured time is worth — handwritten scans and free-text emails are where the typing hurts most.
At dozens of referrals a week, the recaptured hours go back into the intake calls and eligibility checks that actually need a person.

The slow, invisible cost of intake is the retyping tax — someone reads a GP chronic condition management plan, an NDIS plan extract, a My Aged Care RFS, a handwritten scan, and keys the same dozen fields into the practice system by hand, one document at a time.

Where it works badly

It is confidently wrong when the scope catalogue it checks against is stale — and a confident wrong flag is worse than no flag.

Weak where reference data is stale — if your AHPRA scope, NDIS registration groups or MBS item rules are a cycle out of date, it will flag eligible referrals or miss ineligible ones.
Weak on genuinely degraded documents — a third-generation fax, faint-pencil handwriting — where the right behaviour is a low-confidence mark or a blank, not a guessed Medicare or NDIS number.

The honest test

Pull twenty of your actual worst referrals, not your cleanest — if a large share are illegible faxes or unstructured emails, the tool hands most of them to a human anyway and the saving is thinner than the clean-PDF case suggests.

The standout moment in the demo is a flag — a handwritten intake requests psychology under NDIS item 15_054_0128_1_3, and the tool flags it because the practice holds Therapeutic Supports for physiotherapy, OT and speech, not psychology. That flag is only correct if your registered scope is loaded and current.

What it doesn't do — and shouldn't

It drafts and flags. A person accepts. That boundary is deliberate.

WHAT IT DOES

Surfaces every extracted field with its confidence and source line

Flags a requested support that falls outside the practice's registered scope

Drafts the full intake record so the officer reviews instead of transcribes

WHAT IT WON’T

Accept a referral or enrol a client

Commit a record to the practice system

Decide whether the client is a clinical or capacity fit

An automated wrong accept has real consequences in clinical healthcare: a record committed under the wrong funding stream is a Medicare or NDIS billing problem, and taking on a client for a support the practice isn't AHPRA- or NDIS-registered to deliver is a registration and duty-of-care problem. The accountable person stays on the decision because the consequence lands on them — not the tool.

What your data has to look like

A current scope catalogue, the identifier fields present on referrals, and a real sample of your messy inbound documents.

Typical readiness

across orgs we see, before the first job

A current catalogue of your registered scope

Needs shaping

Identifier and funding fields present on referrals

Usual weak point

A representative sample of real inbound documents

Needs shaping

Current MBS and NDIS item references

Usual weak point

The real first job

The registration-scope catalogue is usually the weak point — it lives in someone's head or a spreadsheet a registration cycle out of date. Getting it written down, current and structured is usually the real first job: larger and more durable than the extraction layer on top, and a matter of how the information is captured and maintained, not buying a new tool.

Right fit if…

You take referrals across mixed funding — Medicare CDM, NDIS, Support at Home

Dozens of referrals a week across several document formats

You can point to a current catalogue of your AHPRA and NDIS registered scope

Your referrals actually carry the identifier and funding fields

Walk away if…

Your registered-scope catalogue lives in someone's head or a stale spreadsheet

Most of your inbound is illegible faxes or unstructured free-text email

You need a tool that accepts or enrols clients for you

You take a low, uniform trickle of one referral type from one source

Open questions

The worried-buyer questions, answered straight

No — the opposite is the point. The tool drafts the record and flags the mismatch; it never commits anything or accepts a client. In the demo it reads a handwritten intake requesting psychology under NDIS item 15_054_0128_1_3 and flags it because the practice holds Therapeutic Supports for physiotherapy, OT and speech, not psychology. Your intake officer then reassigns or declines. The flag is a prompt for a human decision, not an action the tool takes.

It is built for exactly that mix, but messiness lowers confidence rather than being hidden. Each extracted field gets a confidence score, and a handwritten scan will score lower than a clean PDF — the signal for your officer to check it rather than approve on sight. The honest test: if a field is genuinely illegible, the tool should mark it low-confidence or blank, not invent a plausible Medicare or NDIS number. That behaviour is tuned and tested against your real documents during setup.

It removes the retyping, not the judgement. The intake officer still decides whether to accept the referral, whether a flagged funding or registration mismatch is a real problem, and whether the client is a fit. What changes is that they start from a drafted, field-by-field record instead of a blank form and a stack of PDFs, so the recaptured time goes into the calls and eligibility checks that actually need a person.

Current enough to be true today. The AHPRA registrations and NDIS registration groups you hold, the NDIS support item numbers, and the MBS chronic-condition item rules all change — the CDM framework was rewritten on 1 July 2025 — and the tool’s flags are only as good as the catalogue it checks against. If your registered scope changes or an item is renumbered, that reference has to be updated or the tool will flag eligible referrals or miss ineligible ones. Keeping that catalogue current is part of the setup we help with.

The referral content is read to extract fields and is not used to train any shared model. Architecture and data residency are decided with you up front, because this is Medicare numbers, NDIS participant numbers and clinical referral detail — sensitive health information under the Privacy Act 1988 and the Australian Privacy Principles. Nothing is committed to your practice system until your officer approves the drafted record, and the demo runs entirely on fabricated data.

Every field shows its source line from the original document and a confidence score, so a wrong extraction is visible and checkable rather than buried. Your officer edits the field against the source before approving. Because the draft sits beside the original scan, correcting an OCR slip on a Medicare number or plan date takes seconds — and those corrections are what we use to tune extraction on your document types.

What it takes to build

3–4 weeks · 4 phases

Reused from template~70%

Bespoke to this skin~30%

stack · Claude · Azure Document Intelligence · review UI

What it would cost

Fixed scope, fixed price, fixed dates.

Bite-sized first piece

One contained change, low risk

Pilot build

Most builds land here

Embedded support

Scale on proof

Considering this for your intake desk?

The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where intake hurts; we'll play it back, scope it, and show you what's possible.

Book a call How we work