TL;DR: Most mid-to-large independent practices and MSOs on ModMed should buy referral intake automation, not build it. Reading a fax is the easy part. The expensive part is keeping up with referrer quirks, ModMed write-back, patient matching, and exception handling year after year. Build only if you have a dedicated engineering team, very high volume, and a reason to own the workflow. Otherwise, buy and pilot on your own referrals.
Should you build or buy referral intake automation for ModMed?
For most practices, buy. That's the short answer, and the reasoning is about maintenance, not technology.
A weekend prototype can read a clean fax with an OCR engine and a language model and pull out a patient name, a diagnosis, and a referring provider. It looks like 80% of the job. But the last 20% is where referral intake lives: the fax of a fax, the handwritten insurance card, the patient with three near-duplicate charts, the referring office that sends the same packet twice. Your staff will hit those cases on day one.
Building also means you own the integration. When ModMed ships an update, your team fixes whatever broke. When a payer changes what a complete referral needs, your team changes the rules. That's a permanent line item, not a project with an end date.
None of this means building is never right. It means the bar is higher than most teams assume, and the decision deserves real numbers instead of an engineer's optimism.
What does it really cost to build?
The visible cost is engineering time. The hidden costs are what sink most internal builds. Walk through each one before you commit.
- Engineering. You need people who can build document ingestion, extraction, patient matching, a review queue, and an audit trail. That's several skill sets, and they have to stay on the project after launch.
- Model tuning and evaluation. Extraction accuracy on your own referral mix needs a labeled test set, regular re-testing, and a plan for when accuracy drifts. Someone has to own that.
- Security and compliance. Anything that touches referrals touches protected health information. You'll need a BAA with every vendor in your stack (OCR, model provider, hosting), access controls, logging, and a security review.
- EHR write-back. Reading data out of ModMed is one task. Writing structured referral data and documents back into the right chart, safely, is another. Duplicate charts and wrong-patient filing are the failure modes that hurt.
- Maintenance. Referrer formats change, payers change, ModMed changes. Budget ongoing engineering time, not a one-time build.
- Opportunity cost. Every engineer on referral intake is not working on something that differentiates your practice. For most practices, fax parsing isn't that.
A useful test: write down the full annual cost, including the share of each person's time and the compliance overhead, and compare it to a vendor quote. Teams that do this honestly often find the build costs more and arrives later.
What do ModMed's native tools and APIs cover?
ModMed has invested in interoperability. Its synapSYS platform provides FHIR-based APIs so outside applications can exchange data such as patient demographics, insurance information, and documents with the EHR, in both directions. That's good news if you're considering a build, because it gives you a documented way in.
But an API is a pipe, not a workflow. It doesn't read a fax, decide whether a packet is complete, match a misspelled name to the right chart, route a referral by urgency, or chase the referring office for a missing face sheet. Those pieces are what you'd be building on top of it.
Before you decide either way, ask ModMed (and any vendor) what you actually get: which data you can read, which you can write, what rate limits and approval steps apply, and what support exists when the integration misbehaves. The answers shape both the build estimate and the vendor evaluation.
When does a lightweight in-house or RPA approach make sense?
Sometimes it does. A narrow, low-risk version can be reasonable in a few situations.
- Very low volume. If you receive a handful of referrals a day from a few known offices, a shared inbox, a checklist, and a trained coordinator may beat any software.
- A single standardized source. If most referrals arrive as structured data from one partner system, you may only need a simple import, not AI document reading.
- A strong internal IT team with spare capacity. If you already run automation projects and have the compliance machinery in place, a small scoped build can work, especially for routing and task creation rather than extraction.
- A bridge while you evaluate vendors. A simple rule-based filter that sorts faxes into queues can cut chaos while you run a proper pilot.
Robotic process automation (scripts that click through screens the way a person would) deserves a caution. It's fast to prototype and brittle in production, because a screen change in the EHR can break the script without warning. If you go that route, make sure someone owns monitoring and repair.
How should you decide? A simple framework
Two inputs matter most: referral volume and IT capacity. Add a third, strategic fit, as a tiebreaker.
Low volume, limited IT. Skip both. Fix the process first: one queue, a required-data checklist, aging alerts. Revisit when volume grows.
Moderate to high volume, limited IT. Buy. This is where most mid-to-large independent practices and MSOs land. The volume justifies automation, and you don't have the engineering depth to maintain it.
High volume, strong IT. This is the only quadrant where building is a serious option. Even here, price the full cost, and consider buying the extraction and matching layer while building the workflow around it.
Very high volume across many locations, strong IT, and a strategic reason to own the workflow. Build, or build on top of a vendor's components, and staff it like a product.
A few other signals push toward buying: you want to be live in weeks rather than quarters, you want one vendor accountable for accuracy, or you'd like to extend automation to other back-office work (prior authorization, fax triage, benefits verification) without starting a new project each time.
Signals that favor building: you have unusual workflows no vendor supports, you have regulatory or contractual reasons to keep data in-house, or you're confident you can staff the maintenance for years.
What should you ask vendors if you buy?
Buying isn't a free pass. A weak vendor can cost you as much as a weak build. Use the same discipline you'd apply to your own project.
- Test on your own referrals. Send 100 real ones from last month, including the ugly ones, and get field-level accuracy and patient-match results.
- Ask how they write to ModMed. Do they use the official APIs? What do they read and write? What happens when ModMed ships an update?
- See the exception queue. How a product handles hard referrals tells you more than its demo does.
- Get timelines in writing. One vendor serving ModMed practices, Calvient, says most practices go live in under 10 weeks. Ask every vendor for a written plan and what they need from you.
- Check BAA and security terms. Require a signed Business Associate Agreement before any referral data moves.
- Understand pricing and exit. Ask about implementation fees, per-location charges, volume tiers, and how you get your data and configuration back if you leave.
Vendor-published results are claims, not benchmarks. Medsender, for example, advertises faster turnaround and higher referral conversion than manual intake. Use numbers like these as hypotheses for your pilot.
Honey Health's Referral Intake agent is one example of the buy path. It reads inbound referrals from fax and other channels, extracts the structured data, and files it so staff work from a clean queue with exceptions routed to people. The same platform also covers fax triage, prior authorization, and benefits verification, which matters if you'd rather not run a separate vendor search for each workflow. Ask exactly which ModMed data its agents read and write, as you would with anyone.
How do staffing and cost pressure change the math?
The labor market is part of the build-or-buy decision. In an October 2024 MGMA Stat poll, 53% of medical group leaders said finding candidates was their top staffing challenge. If it's hard to hire a front-desk coordinator, it's harder to hire and keep the engineers a build requires.
The broader trend points the same way. The 2025 CAQH Index estimates about 21 billion dollars in savings remain across U.S. healthcare from fully automating transactions that are still manual or partly manual, and reports that more than 25% of provider organizations already use AI tools in administrative workflows. Document-heavy intake isn't a payer transaction, but it's the same kind of manual work, and your referral sources are likely sending patients to practices that process them faster.
Fax remains the backbone. A 2019 MGMA Stat poll found 89% of healthcare leaders said their organization uses a fax machine, so a solution that can't handle fax well isn't a solution for most specialty practices.
What does a low-regret path look like?
If you're torn, you don't have to pick a side on day one. A staged approach keeps your options open and costs little.
Start by measuring. Pull a month of referrals and record time to first touch, percentage incomplete, and referral-to-completed-visit rate. You'll need this baseline whether you build or buy, and it often shows that process fixes alone recover a meaningful share of lost referrals.
Next, run a four-week vendor pilot on one location with a written scorecard. Keep humans in the loop for low-confidence matches. If the pilot beats your baseline and the vendor handles your messiest faxes, you have your answer. If it doesn't, you've learned what a build would need to beat, which makes any internal estimate far more realistic.
Finally, revisit the decision once a year. Volume, staffing, and vendor offerings all change, and a choice that was right at 40 referrals a day may not be right at 200.
Frequently Asked Questions
Is it cheaper to build or buy referral intake automation?
Buying is usually cheaper once you count engineering time, model evaluation, compliance work, and ongoing maintenance on a build. Building can win at very high volume with a strong IT team, but only if you price the full multi-year cost honestly.
Can ModMed's APIs handle referral intake on their own?
No. ModMed's synapSYS APIs let outside applications exchange data with the EHR, but they don't read faxes, match patients, check completeness, or route referrals. Those workflow pieces have to come from a vendor or your own build.
How long does it take to build referral intake automation in-house?
A working prototype can take weeks, but a production system with patient matching, exception handling, EHR write-back, and security review typically takes months. Maintenance continues indefinitely. Ask your team for a plan that includes post-launch support.
What's the risk of using RPA for referral intake?
RPA scripts mimic clicks on a screen, so a change to the EHR interface can break them silently. They can work for narrow tasks, but they need monitoring and a named owner who can fix them quickly.
What should we pilot before committing?
Run one location or service line for four weeks on real referrals. Measure field accuracy, patient-match accuracy, share needing human review, and time from receipt to a scheduling-ready record, and compare against your baseline.
