Tennr vs. automating your existing DME platform

The short answer

Tennr and a custom automation layer solve the same problem in structurally different ways. Tennr replaces your intake layer with its own platform. A custom automation layer leaves your existing DME platform in place and automates the workflows around it.

Neither is universally better. The question is not which product is stronger — it is whether your intake operation should be rebuilt on a new system or repaired on the one you already run. That depends on how well your current platform serves you, how much process you have already built inside it, and what you can absorb operationally over the next year.

What Tennr is

Tennr is a New York–based healthcare AI company founded in 2021 that automates patient referral and document intake. Its technology reads inbound referrals — largely faxed — extracts structured data, and checks them against payer criteria. The company raised a $101M Series C led by IVP in June 2025 at a reported $605M valuation, with participation from a16z, Lightspeed, GV, and ICONIQ, and reports processing roughly 10 million documents per month. It positions itself as a patient orchestration platform rather than a point solution.

It is a serious, well-capitalized product with real engineering behind it. Nothing on this page should be read as suggesting otherwise. (Figures above are public as of July 2026 and will change.)

The structural difference

The distinction that matters is where the system of record lives.

This is why the two approaches attract different buyers. A replacement platform is bought by an operation ready to change how intake works. An automation layer is bought by an operation that likes how intake works in principle and cannot afford the hours it consumes in practice.

When a platform like Tennr is the better choice

There are real situations where replacement wins, and pretending otherwise would not help you:

• Your intake process is broken end to end, not just slow. If referrals are lost rather than merely delayed, patching the edges will not fix it.
• You are already planning a platform change. If migration is happening anyway, evaluate purpose-built intake as part of that decision rather than automating a system you are about to leave.
• Referral volume is very high and highly variable. At sufficient scale, a vendor amortizing an ML team across many customers can invest more in extraction accuracy than any single supplier can justify building.
• You want a vendor to own the outcome. A platform contract puts accuracy and uptime on someone else's balance sheet. That is a legitimate thing to buy.
• You have no internal technical owner and no appetite for one. Custom automation needs someone on your side who can make decisions about workflow rules.

When automating your existing platform is the better choice

• Your DME platform basically works. If Brightree, WellSky, or NikoHealth is serving you and the pain is the manual work around it, replacing the system solves a problem you do not have.
• Intake is not your only problem. Referral intake is one workflow. Prior authorization follow-up, resupply outreach, proof-of-delivery chasing, and pre-claim validation are separate leaks, and they are often larger. A layer can address all of them; an intake platform addresses intake.
• You have years of history and configuration in your current platform that would be expensive or impossible to carry across.
• You cannot absorb a migration right now. Platform changes consume management attention for months. Some years you have that capacity; some years you do not.
• You want to start small and prove it. Automating one workflow for a fixed price is a smaller commitment than adopting a platform, and it produces evidence before you scale.

Questions worth asking either way

Whichever direction you lean, these questions separate a real evaluation from a demo reaction:

1. What does the failure mode look like? Every document-reading system has an exception path. Ask specifically what happens to a document the model cannot read confidently, and who works that queue.
2. What is the extraction accuracy on your documents? Not benchmark documents. Your worst third-generation photocopies from your highest-volume referral source.
3. What happens to the data if you leave? Ask about export format and retention before signing, not after.
4. Who owns payer rule changes? Coverage criteria change constantly. Clarify whether updates are included, and how fast they land.
5. What is the total cost over three years, including implementation, ongoing fees, and the internal staff time to run it?
6. What is the measured baseline? If you cannot state today's cost in hours or denied dollars, you will not be able to prove either approach worked.

You may not have to choose

These approaches are not mutually exclusive. A supplier can run a purpose-built intake platform and still need automation for prior authorization follow-up, resupply outreach, and pre-claim documentation validation — workflows that sit downstream of intake and inside the DME platform.

If intake is genuinely your biggest leak, fix intake first with whatever tool fits. If intake is one of several leaks, measure them all before committing to a solution shaped for only one.

Common questions

Is Tennr a good product?

Yes. Tennr is a well-funded healthcare AI company that raised a $101M Series C led by IVP in June 2025 at a reported $605M valuation, and it processes roughly 10 million documents per month. The question for a DME supplier is not product quality but fit: Tennr replaces your intake layer with its own platform, which is the right move for some operations and the wrong move for operations whose existing DME platform is working fine.

What is the difference between Tennr and a custom automation layer?

Tennr is a platform you adopt; a custom automation layer is software that sits on top of the platform you already run. With Tennr, intake moves onto Tennr's system. With an automation layer, Brightree, WellSky, or NikoHealth remains the system of record and the automation reads from and writes back to it. The practical differences are migration (required vs none), retraining (new interface vs same screens), and reversibility.

Do I have to replace my DME platform to automate referral intake?

No. Fax and referral intake can be automated on top of an existing DME platform using documented APIs, HL7/FHIR interfaces, secure read-only database access, and UI-level automation where no API exists. A single-workflow build typically takes 4 to 8 weeks, compared with a 6 to 18 month platform migration. Replacement is warranted when the platform itself genuinely cannot support the business, not merely because it does not automate.

Which approach costs less?

It depends on scale and time horizon, and neither is reliably cheaper. A platform is an ongoing subscription that scales with usage; an automation layer is a fixed-scope build followed by maintenance. SynergyIQ prices single workflows at $2,000 to $8,000 and multi-workflow operational builds at $10,000 to $40,000. Compare over a three-year horizon including implementation and internal staff time, not on headline price.

Can I use both?

Yes, and some suppliers do. A purpose-built intake platform handles referral capture while a separate automation layer handles prior authorization follow-up, resupply outreach, and pre-claim documentation validation inside the DME platform. Intake is one workflow; the downstream leaks are often larger and are not addressed by an intake product.