Halcyon DME Ops: from a fragile spreadsheet to a tracked order
In 30 seconds
A small medical-supply distributor runs every order through one fragile Excel file. The exercise: frame the problem, compare three approaches, pick one and prototype it. I chose to make the order, not the form, the unit the system manages. The prototype is a clickable demo with simulated integrations (listed below) and takes about three minutes to explore.
The business in 60 seconds
A therapist treating lymphedema or breast-cancer patients prescribes a compression garment. The distributor handles everything that follows: it records the order, checks that insurance covers it, gets a manager’s approval for certain product codes, collects the patient’s signed consent and payment, places the order with the manufacturer, who ships it straight to the patient, and finally gets the patient’s signed proof of delivery.
Today that chain spans Excel, SharePoint, DocuSign, Stripe, manufacturer ordering portals and email.
Glossary. HCPCS code: US billing code that identifies a product type; some require manager approval. Payer: the insurer. Patient responsibility: the part the patient pays after insurance. POD: proof of delivery.
BriefClient facts
What the client said
Three pains, in her words: the spreadsheet “has become too complex to scale”; “it’s fragile. If one field breaks, the whole sheet goes haywire”; and her team “has to re-enter everything manually in the vendor portals, even though the info is already in the spreadsheet.”
What she asked for: a web tool with two tables (products and fee schedules) that auto-populates an order form.
Stated as aspirational, not core: auto-sending orders to the right vendor (“that’s the dream”) and tracking which items need prior authorization (“I’d love to eventually”).
Not known from the conversation: order volume, how clinics send their orders, how insurance is verified, and what her “internal system” is.
Decision thenAugust 2026
The problem I chose
The order has no single reliable home. It is typed by hand when it arrives, retyped when it goes to the vendor, and in between it lives in a file that mixes records, reference data and formulas.
Decision thenAugust 2026
Three approaches
| Dimension | Order Desk | Control Tower | Draft & Review |
|---|---|---|---|
| Bet | The math is what's broken | The handoffs are what's broken | The unstructured input and unwritten rules are what's broken |
| What it is | Exactly what she asked for: two tables, one auto-calculating form | The order becomes a tracked record with an explicit lifecycle | AI reads the therapist's order document and drafts the order; the team reviews |
| Employee's job | Fill the form reliably | Work a queue, clear exceptions | Review a draft |
| Gains | Fastest, lowest risk, minimal adoption friction | Cuts re-entry, makes stalled orders visible, builds on the same two tables | Highest ceiling; makes undocumented prior-authorization knowledge explicit |
| Costs | Leaves vendor re-entry untouched: a better spreadsheet | Bigger build; vendor-integration and change-management risk | Rests on an unverified premise (that orders arrive as readable documents); errors are costly in billing; needs a data agreement with the AI provider; cost not estimable from the brief |
| Would win if | Volume is low and calculation errors dominate | Handoffs and status-chasing dominate | Documents are messy and high-volume, and missed prior authorizations cost real money |
A fourth idea, a therapist-facing intake form, was set aside because the client said the tool is “just for us”, and because it would require partner clinics to change how they order.
Decision thenAugust 2026
The decision
I chose Control Tower, which includes Order Desk as its foundation. Four reasons:
- It is the only option that touches all three pains she named.
- It extends her own instinct (separate reference data from records) instead of overriding it.
- It is deterministic engineering; the core needs no AI.
- It produces the operational data the open questions need.
Draft & Review was sequenced second, not rejected. Three reasons: it rests on an assumption I could not check (that orders arrive as readable documents), it targets what she explicitly deprioritized, and it is the wrong first thing to ask a team to trust.
One decision I left with the client: she said the tool is internal-only, which keeps manual intake alive. Revisiting that boundary may offer a simpler fix than AI reading. I put that question to her instead of deciding it quietly.
What the prototype does about each pain
| Her words | What the prototype does | Status |
|---|---|---|
| “Too complex to scale” | The order is the unit: one card per order across seven stages, with overdue flags for payment and delivery. | Real |
| “It’s fragile” | Products and fee tables stay separate from the order record. The payer and patient split is computed per line item, not typed. | Real |
| “Re-enter everything manually” | Each line item knows its vendor, and placement is tracked per line with the vendor’s order number. Nothing is sent to the vendor; the portal button is inert. | Tracking is real, sending is simulated |
What is real and what is simulated
| Real in the prototype | Simulated or not built |
|---|---|
| Live price split (payer vs patient) per line item, from product and fee tables | Fee schedule and coverage percentages are invented; brand and payer names are real, prices are not |
| HCPCS-based routing: a gated product stops at Pending Approval until Approve Order is clicked | No login; one demo user plays employee and manager |
| Insured / Self-pay with no default; no amounts until chosen | DocuSign consent, Stripe payment link and POD signature: previews plus a “Prototype control” button |
| Vendor placement, delivery and receipt tracked per line item; the order advances only when all lines do | “Open Portal / Email Vendor” does nothing; no order is sent anywhere |
| Overdue flags for payment due dates and expected delivery dates | Address autocomplete is a fixed list; no validation service |
| Encounter Form generated and downloadable | State lives in memory; reloading resets it |
| No AI anywhere in the prototype, by design |
A three-minute path
Home: the unit of work is the order 30 s
Open Orders. Seven stages, read-only cards. Two orders are flagged: HAL-1045 (payment overdue) and HAL-1058 (expected delivery overdue). Switch on “Needs Attention”. Before, knowing where an order stood meant opening several tools.
Place New Order: the rules do the work 90 s
Choose Insured, Aetna, 80%, and Juzo Compression Wrap Calf. A measurement-form upload appears because that product requires one. The split computes live: payer $76, patient $19. Submit Order stayed disabled until every required field was complete. After submitting, the order stops at Pending Approval and does not move until Approve Order is clicked (as manager Taylor Brooks). Consent and Payment then appears, with a dashed “Prototype control” box that says what is simulated.
HAL-1044: one order, two vendors 60 s
In Ready for Vendor, the JOBST line is already placed and the Juzo line is not. The system knows which vendor each product belongs to, so nobody has to remember it or retype data. “Mark as placed” asks for the vendor’s order number. The portal button is inert, by design of the demo.
Explore after
The demo is live and clickable. State lives in the browser session, so reloading the page resets everything to its starting data.
Open the prototypeReflection todayLooking back
Reflections today
- One conversation was the base. Everything above rests on a single client conversation. The first two steps I proposed before building anything real (watch one order end to end, and ask the highest-volume vendors whether they accept structured orders) were written down as pending validation.
- Fact, inference, assumption. I labeled every claim in the working documents. Where the transcript gave no evidence, such as filtering by therapist and vendor, the spec records it as an assumption, not a requirement.
- The internal-only boundary. I left it as the client’s decision. Today I see one more tradeoff: a therapist portal could sit beside the ops view behind a role-based home, but it would make the flow harder to explain and to follow in a demo.
How the exercise was made
I used Claude throughout as a thinking and execution partner, switching models for judgment versus execution. ChatGPT handled targeted domain research; Lovable set up the prototype’s visual foundation, and I moved the code into Claude to iterate, test and publish it. I treated AI output as something to challenge, not ground truth; product judgment and final decisions stayed with me. The product itself uses no AI. Where AI would earn a place later is the genuinely ambiguous part: reading what clinics send.