AI for Orthotic Clinics: Tracking Fittings and Insurance Follow-Up

An AI agent for an orthotic or prosthetic clinic is a supervised assistant that tracks where each fitting order stands, flags missing documents, and keeps insurance follow-up from stalling, while licensed clinicians and billing staff make every clinical and financial decision. Clinics get the most value by starting with one narrow role, such as following custom device orders from prescription to delivery, and widening access only after approval boundaries and success checks are working. This playbook explains where to start, what the agent should and should not touch, and how to judge when more capability is worth giving it.

Key takeaways

• Start with one stage of the order flow, such as orders waiting between measurement and fitting, not the whole practice.
• Give the agent read access to order records and draft authority for routine messages, but keep clinical measurements, device choices and payer submissions with licensed staff.
• Write the approval boundary for every action before connecting any tool or inbox.
• Measure success with a short list of observable checks, such as every open order having a named owner and a next step.
• Treat growing capability as a reason to review permissions, not a reason to widen them automatically.

Where fitting orders actually get stuck

An orthotic or prosthetic order usually passes through several hands: prescription intake, measurement or casting, fabrication, fitting, adjustment and delivery. Delays tend to happen between those hands. A prescription is missing a side or a dimension, a measurement is waiting on a signature, or a fitting is moved without the fabrication record being updated. The front desk, technicians and billing each hold part of the picture, and rarely does anyone see the whole order at once.

Insurance follow-up adds a second clock. Payers may ask for additional documentation, issue a determination, or request a correction, and each request comes with its own format and deadline. Requirements differ by payer and by region, so an agent should never infer coverage from a past pattern. Its useful job is to notice that something is open, show what it is waiting for, and put it in front of the person who can resolve it.

What an agent should own and what it must never decide

A simple split keeps the boundary clear. The agent may read order status, compare records for missing fields, draft reminders, prepare a follow-up packet for review, and log each change with a timestamp and its source. It should not choose a device or material, change a measurement, interpret a clinical note, tell a patient whether a device is medically appropriate, or submit a claim or appeal without an authorized person approving it.

• May draft: appointment reminders and status messages built from approved templates.
• May flag: an order with an empty prescription field, a measurement that fails the clinic's own age rule, or a payer request with no response after the internal deadline.
• May prepare: a follow-up packet listing the documents, dates and open questions for a clinician or billing lead to review.
• Must not do: edit clinical data, select designs or materials, give coverage statements to patients, or send payer submissions without human approval.

The same logic applies to adjacent stages. Practices that already run recall or intake workflows, such as the ones described in AI Agent for a Chiropractic Practice: Intake and Visit Recalls, tend to find that reminders are the easiest first task, while anything touching diagnosis stays with the clinician.

A five-step plan for the first workflow

The first workflow should be small enough that one lead can review every agent output in the early period. Work through these steps in order.

• Step one: choose one stage. Write the start state and end state in one sentence each, for example, orders with a completed measurement but no fitting date.
• Step two: list the records the agent needs and name the owner of each: the order file, the fabrication log, the appointment calendar and the payer correspondence folder. Remove anything the task does not require.
• Step three: write the approval boundary. Mark each action as automatic, requiring one named reviewer, or prohibited.
• Step four: define the success check. A useful example is that every open order has an owner and a next-step date, reviewed by the clinic lead each morning.
• Step five: run a supervised period in which staff review every output, log every disagreement, and adjust the rules before any permission is widened.

Write the boundaries down in plain language that a new receptionist could follow. If a rule cannot be explained that way, it is not yet ready to be given to software.

What a supervised workflow looks like in practice

Illustrative scenario: a small clinic receives a prescription for a custom ankle orthosis, but the form does not specify the side. The agent flags the order, drafts a message to the referring office asking for the missing detail, and places the order in the clinician's review queue. Once the clinician confirms the side, the agent records the answer with its source and the fabrication step resumes. At no point does the agent choose the device, adjust a measurement or give the patient any clinical instruction.

The value in this example is not speed alone. The order no longer depends on someone remembering that a form was incomplete, and the clinician sees one clear item instead of a pile of unlabeled messages.

Handling insurance follow-up without guessing

Keep a status log for each payer request with a few fixed fields: the request received, the document asked for, the responsible person, the internal due date, the response sent and the determination received. The agent keeps the log current and raises any item that passes its deadline. Claims language, billing codes and appeal arguments belong to trained billing staff, and the agent should never be the author of a position the clinic will defend.

An important habit is to treat the payer's written request as the source of truth. The agent may summarize a letter to help a reviewer, but the reviewer checks the summary against the original document before anything is sent. This habit catches the most expensive kind of error, which is a confident summary of a rule that does not actually apply to the case in front of the team.

Protecting patient information and tool access

Patient information needs the same care as any clinical record. Give the agent the smallest set of records the task requires, use separate credentials rather than a shared staff login, and check that each permission matches the job. The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a practical reference for designing those checks. Agents that read incoming emails or uploaded payer letters also face prompt injection, where text inside a document tries to issue instructions. Treat every inbound document as data to be read, never as a command to be followed. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) gives a useful structure for naming these risks and assigning owners to them.

Be Human designs the role, memory, tools, permissions and approval boundaries for a clinic, then operates the setup with monitoring, recurring evaluations, permission reviews and incident response, with decisions staying under the clinic's control.

Deciding when more capability is justified

Newer models may read longer documents, draft more complete summaries or handle more steps in one task. A stronger model does not change who is accountable for a clinical or billing decision, and it does not remove the need for permission reviews. Expand the agent only when three things are true: its outputs on real but de-identified cases match what your reviewers would accept, staff trust its flags enough to act on them, and the permission list reflects the current job. The [Anthropic guidance on building effective agents](https://www.anthropic.com/engineering/building-effective-agents) makes a similar point: begin with simple, well-bounded patterns and add complexity only where it clearly earns its place. If you want to find the first task in your clinic worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent submit insurance claims for an orthotic clinic? In a sound setup, the agent prepares and checks the packet, but submission stays with an authorized billing person who reviews the payer requirements and the documents. The agent's role is to catch missing fields, track responses and raise overdue items. Anything that argues a position with a payer should be written and approved by trained staff.

Does the agent need access to the full clinical record? No, and it should not have it by default. Start with the fields needed for the single workflow, such as order status, prescription completeness and appointment dates. Add access only when a reviewer can explain why a specific field is necessary for the task.

What should we measure during the first supervised period? Choose a few checks that a lead can verify quickly, such as whether every open order has an owner, whether each flag was acted on or explicitly dismissed, and how often a reviewer had to correct the agent's draft. Log disagreements and use them to refine the approval boundaries before widening access. Avoid vanity measures that do not show whether an order moved forward.

Is this approach suitable for prosthetic clinics as well as orthotic ones? The workflow logic is similar, since both involve custom orders, measurements, fittings, adjustments and payer documentation. The specific fields, documentation rules and clinical boundaries will differ, so the role, records and approvals must be defined for each clinic rather than copied. Teams that handle similar scheduling and records work can also compare notes with AI for Orthodontists: Aligner Tracking and Recalls when designing their own tracking logs.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.