Brightree Integration: How to Automate DME Order Intake

Brightree order intake automation is a custom sync that takes referrals, faxes and portal orders from outside Brightree, normalizes them, and creates the patient and sales order records inside it, then pushes status back out to your CRM and billing tools. This guide is for DME and home medical equipment operators who already know they need a build and want to know what Brightree actually allows, where the limits are, and how we would structure the integration. It covers the API access path, the intake architecture, the build steps, and the failure points we design against.

One definition up front: DME order intake automation is the process of capturing a referral from any source, extracting the clinical and demographic data, validating it against payer and documentation requirements, and creating a complete order in the supplier's system of record without re-keying.

The problem it solves

A typical home medical equipment supplier receives orders through several channels at once: faxed referrals, e-prescribing or referral-network feeds, email attachments, and phone calls. Each one ends up with an intake coordinator who reads the document, finds or creates the patient in Brightree, builds the sales order, attaches the paperwork, and chases missing items. The work is not complex. It is repetitive, and every re-keyed field is a chance for a billing rejection later.

The question for most operators is which path to automation they actually have. Here is how the real options compare for Brightree.

The honest read: if your only pain is faxes, start with the native document tool. If your pain is that orders arrive from five places and your CRM and billing stack never hear about them, you need a custom sync, and that runs through the API.

What does the Brightree API actually expose?

Brightree does not publish a self-service developer portal that we could verify, so most of the surface has to be confirmed with Brightree during scoping. What we can say from Brightree's own materials is limited but useful.

Brightree's Additional Terms and Conditions for Modules state that the Web Services API is available only if purchased on the Order Form, and that integrators need resources familiar with SOAP based web services. A Brightree Summit session, Mechanics of the Brightree Customer API, describes the different web services Brightree has developed and offers integration best practices.

What we cannot confirm, and will not guess at: the base URL, the authentication method, rate limits, whether any webhooks or scheduled exports exist, and the exact list of operations. Those are the first things we ask Brightree for: the WSDL, the auth method, and the transaction and message-size limits for your contract. A sample license clause we reviewed also suggests Brightree can restrict access if usage goes beyond the stated application, so the integration should be described to them accurately up front.

How the automation works

The architecture is a thin middleware service that sits between your intake channels and Brightree. Nothing is written into Brightree until the order passes validation, and every write is logged so it can be replayed.

• Intake collectors: One adapter per channel (fax or email inbox, referral-network feed, web form). Each one drops a raw document or payload into a queue with its source and timestamp.
• Extraction and classification: An AI step classifies the document (referral, prescription, face-to-face note, insurance card) and extracts structured fields. Low-confidence fields are flagged rather than guessed.
• Validation and matching: Rules check that required documentation exists for the item ordered, and match the patient to an existing record using Brightree's primary key where we have it, so we do not create duplicates.
• Brightree writer: A SOAP client creates or updates the patient and sales order through the Web Services API, then stores the returned keys in our own mapping table.
• Status and sync-out: Order status and missing-document flags are pushed to your CRM, referral source, or billing tools on a schedule, because we do not assume Brightree will push events to us.

Step-by-step: how to build it

Step 1: Confirm API access and scope with Brightree

Before any code, confirm the Web Services API is on your Order Form and request the WSDL, authentication details, and your transaction limits in writing. Define the operations you need: find patient, create patient, create sales order, attach document, read order status.

Scoping checklist for Brightree
- WSDL location and environments (test vs production)
- Auth method and credential ownership
- Transaction count and message size limits
- Operations for patient, sales order, document attach, status read
- Approval of our described use case

The gotcha: a test environment is not guaranteed by default. Ask for one explicitly, because your first writes should never be against live patient data.

Step 2: Build the intake queue

Every channel writes to one queue table with a stable idempotency key, so a re-delivered fax does not become two orders.

CREATE TABLE intake_queue (
  id UUID PRIMARY KEY,
  source TEXT NOT NULL,
  received_at TIMESTAMPTZ NOT NULL,
  content_hash TEXT NOT NULL UNIQUE,
  status TEXT NOT NULL DEFAULT 'new',
  raw_uri TEXT NOT NULL
);

The gotcha: hash the document content, not the filename. Fax vendors reuse names.

Step 3: Classify and extract

Send the document to a model with a strict schema and require a confidence value per field. Anything under threshold goes to a human review queue.

{
  "doc_type": "referral",
  "patient": {"first": "", "last": "", "dob": ""},
  "items": [{"hcpcs": "", "qty": 0}],
  "referring_provider": {"name": "", "npi": ""},
  "confidence": {"patient.dob": 0.0}
}

The gotcha: never let the model fill in a missing NPI or date of birth. A blank field and a review task beats a plausible wrong value.

Step 4: Validate against documentation requirements

Encode per-item rules: which documents must accompany which equipment category. Some items fall under Medicare's DMEPOS prior authorization program, where CMS states the standard review is no more than 7 calendar days effective January 1, 2025, with expedited requests at 2 business days. Intake should flag these items early so the clock starts as soon as the order is complete.

if item.hcpcs in PRIOR_AUTH_LIST and not order.has("face_to_face_note"):
    order.hold(reason="missing documentation")

The gotcha: keep the prior-authorization item list in configuration, not code, because it changes.

Step 5: Write to Brightree over SOAP

Generate a client from the WSDL and wrap each operation with retries and logging. Store the Brightree keys returned for each patient and order.

from zeep import Client
 
client = Client(WSDL_URL_FROM_BRIGHTREE)
# operation names come from the WSDL Brightree provides
result = client.service.CREATE_OPERATION(**payload)
mapping.save(intake_id, result.key)

The gotcha: operation and field names must come from the WSDL you are given. Do not assume them from another vendor's pattern.

Step 6: Sync status out to CRM and billing

On a schedule, read order status for open orders and push changes to the CRM, the referral source, or your billing tool. Use the mapping table so each update targets the right record.

schedule: every 15 minutes
for_each: open_orders
actions:
  - read_status_from_brightree
  - update_crm_deal_stage
  - notify_referrer_if_docs_missing

The gotcha: respect your transaction limits. Poll only open orders, and back off on errors.

Where it gets complicated

Access is a contract question first. The API is a paid add-on, so the first dependency is a conversation with Brightree, not a line of code. Budget calendar time for it.

SOAP is its own skill set. Brightree's terms call for resources familiar with SOAP based web services. Schema-heavy envelopes, namespace handling and WSDL versioning trip up teams used to REST.

Duplicate patients are the expensive mistake. Matching on name and date of birth alone will eventually merge or split the wrong people. We match on stored Brightree keys first and send ambiguous cases to a human.

Limits are set by Brightree. Usage boundaries on message size and transaction counts mean batching and polling cadence are design decisions, not afterthoughts.

Overlap with native tools. If you already use Brightree's fax document automation, our build should leave that lane alone and handle the channels it does not cover, rather than creating two writers for one inbox.

What this actually changes

A custom intake sync removes re-keying from the path between a referral arriving and an order existing, and it gives your CRM and referral sources a status feed they otherwise have to phone for. We have not run this exact build against Brightree for a client, so we are not quoting results. The structural value is that coordinators spend their time on exceptions (missing documents, unclear referrals) instead of data entry, and that the prior-authorization clock starts when the order is complete rather than when someone gets to the pile.

On cost and timeline, the honest answer is that it depends on the Brightree side: API licensing is priced by Brightree, and access scoping can take longer than the build. Our typical shape for a mid-sized operator is a scoping call, a test-environment build in a few weeks, and a supervised go-live where humans approve every order before the writer runs unattended.

Frequently asked questions

Does Brightree have an API?

Yes, but it is a paid add-on rather than a public developer program. Brightree's module terms say the Web Services API is available only if purchased on the Order Form, and that integrators need SOAP experience. We could not verify public documentation, so request the WSDL and auth details from Brightree.

Can Zapier or Make connect to Brightree?

We found no confirmed Brightree connector for either. Treat any no-code claim as unverified until the vendor shows it. Even with a generic SOAP module, you would still need the paid Web Services API and its documentation.

What does a Brightree integration cost?

There are two costs: Brightree's API licensing, which they set, and the build. We scope the build after seeing your WSDL and channels, so we do not publish a flat number. Expect the Brightree access conversation to be the longest lead-time item.

How long does it take to build?

Once API access and a test environment exist, a focused intake sync is typically a matter of weeks, followed by a supervised period. Delays almost always come from access approval and documentation requirements, not from the code.

Can it handle faxed referrals?

Yes, though Brightree also offers its own document automation for referral faxes that creates patient records and sales orders. We would use that where it fits and build around it for the channels it does not cover.

Will the sync break Brightree's usage terms?

It should not if you describe the use accurately and stay inside your transaction limits. A sample license clause we reviewed lets the vendor restrict access for use beyond the stated application, so we document the use case with Brightree before building.

If you run a DME or home medical equipment operation and orders arrive from more channels than your team can key by hand, our workflow automation service covers exactly this kind of build. For a similar pattern on another closed system, see how we approach home care referral intake. When you are ready to scope it, book a 20 minute call and we will tell you what to ask Brightree for first.