Ask most DME and HME teams where intake time goes, and the answer is rarely the clinical review itself. Clinical review is the part everyone trained for. The time goes to everything that has to happen before that review can start.

A document arriving in the queue and a document your team can work are two different states. The distance between them is where intake capacity quietly disappears.

What review-ready actually means

A document is review-ready when a person can open it and immediately begin making clinical and coverage decisions, rather than beginning an investigation. That is a higher bar than it sounds, and almost nothing arrives meeting it.

Before review can start, four questions have to be answered:

• What is this document? An order, a chart note, a face-to-face evaluation, a delivery confirmation, or several of those stapled together.
• Who is it for? Matched to the correct patient record, not a patient with a similar name.
• What is being ordered? The equipment, the quantity, whether it is rental or purchase, and the supporting diagnosis.
• What is missing? The documentation that has to be present before this can move forward.

None of those questions is difficult on its own. All four, on every inbound document, in a queue that refills daily, is a different problem.

Extraction and verification are not the same step

This is the distinction that separates an intake process that holds up from one that merely moves quickly.

Reading a code off a page tells you what the page says. It does not tell you whether the code is valid, whether it is the right code for the equipment being ordered, or whether coverage rules treat it the way the ordering provider assumed. A number can be transcribed perfectly and still be wrong.

Treating those as one step is how errors travel. The document gets read, the values get carried forward, and the problem surfaces later — at billing, at audit, or in a denial that has to be worked backward to a document nobody has looked at in weeks.

Treating them as two steps means the reading happens, and then the checking happens against a source rather than against an assumption.

Uncertainty is information, not failure

There is a temptation to build intake so that every field comes back filled in and confident. It presents well. It is also the least useful thing you can hand a reviewer.

A reviewer who receives a fully populated intake with no indication of which parts are solid has to check all of it, because they have no way to tell the difference. A reviewer who can see which details were read cleanly and which are uncertain knows exactly where to spend attention.

The same principle applies when a reference source cannot be reached. Marking something unverified is honest and actionable. Marking it invalid because it could not be checked creates a problem that did not exist. Those are meaningfully different states, and an intake process that collapses them into one is throwing away the information a reviewer most needs.

The messy realities are the normal case

Intake processes tend to be designed around the clean document and then patched for everything else. In practice, the exceptions are routine:

• A single inbound fax containing paperwork for more than one patient
• Pages for the same patient that are not next to each other in the file
• The same referral arriving twice through two different channels
• Handwriting that is legible to a clinician and ambiguous to everyone else
• A document that belongs on an existing patient's file and needs no new order at all

An intake workflow that treats these as edge cases will spend most of its time in the edge cases. Designing for them is not defensive engineering; it is designing for the actual mail.

What changes when intake is a workflow

When the path from arrival to review-ready is explicit, a few things follow.

The queue becomes orderable. If the work carries some sense of what it is and how urgent it looks, it can be sorted by something more useful than arrival time, and it can reach the right person rather than the next available one.

Corrections stop evaporating. When a reviewer fixes a misread value, that correction should hold — not be quietly overwritten the next time the document is processed. A correction that does not persist is a correction that has to be made again.

And the handoff gets cleaner. Approval becomes the point where verified information becomes a record, rather than the point where somebody starts retyping.

Where to start

You do not need to rebuild intake to improve it. You need to know where the time actually goes.

Take a week of inbound documents and mark, for each one, what had to happen before clinical review could begin. Often, the friction starts before the review itself.

That is the part worth designing deliberately — and that is the kind of workflow clarity Curasev is built to support.