Who Can Help California Practices Connect Referrals Across EHR Systems? 5 Companies to Consider
This guide helps California practice groups and healthtech leaders compare partners for sending, receiving, tracking, and completing referrals when the organizations involved use different EHRs.
A referral can be marked “sent” in one EHR while the receiving practice is still looking for the chart notes it needs to book a visit. The patient calls both offices. Neither team can see the same status, and a specialist’s report may eventually arrive as a fax that never reaches the referring clinician’s work queue.
Connecting referrals across EHR systems means more than transferring an order. It means giving the receiving team enough information to act, showing the sender what happened, and making sure the consultation results reach the right clinician. California practices often look for help when:
- Referring and specialty teams use different EHRs or work across separate organizations.
- Referrals arrive through a mix of electronic orders, portals, secure messages, and fax.
- Scheduling staff must chase missing records or authorizations before offering a slot.
- The sending practice cannot tell whether the patient was contacted or seen.
- A growing network needs one view of referrals without replacing every participating EHR.
Who should you consider? Luma Health is a strong first look if a configurable referral and patient access platform fits your workflow. TATEEDA is well suited to a custom connection between existing clinical systems, referral queues, and staff processes. Folio3 Digital Health has particularly relevant experience joining an EHR with referral portals. Taction Software suits environments with many interfaces to manage, while Sidebench can help when specialty intake and scheduling need as much attention as the data exchange.
The companies below offer different products and services, so their order is not a ranking. TATEEDA publishes this article and is one of the options. The comparison centers on what each could help your team accomplish, not on a promise that any one vendor can connect every EHR with identical access.
Table of Contents
What should a connected referral workflow show?
Before discussing platforms, agree on the milestones that matter to both practices. A specialist appointment is progress, but it does not tell the referring clinician what happened at the visit. For a truly closed loop, the consultation report needs to reach the referring side and be available for follow-up.
| Referral milestone | What staff need to know | Where an integration can fail |
|---|---|---|
| Sent | The request, patient, destination, reason, and supporting records are identifiable | The receiving team gets an order without the clinical information it needs |
| Received and reviewed | Someone accepted the request or asked for missing information | “Delivered” is mistaken for “ready to schedule” |
| Scheduled or declined | The patient has an appointment, chose another destination, or could not be reached | The sending practice sees no change after the referral leaves its EHR |
| Visit completed | The referred service took place | A booked appointment is treated as proof of a completed visit |
| Report returned | The referring clinician receives the specialist’s findings and recommendations | The report arrives in a separate portal or fax queue with no link to the original referral |
The exact messages, records, and write-back permissions differ by EHR and organization. A vendor should show how it will match the same referral across the sender’s system, the receiving team’s workflow, and any shared platform. Ask what staff see when a destination declines, a patient reschedules, or a document cannot be matched.
California referral integration options at a glance
| Company | California location | Best starting point | Delivery model | Main question for your team |
|---|---|---|---|---|
| Luma Health | San Francisco | Referrals tied to patient outreach and scheduling | Configurable healthcare platform | Can it return the statuses and clinical documents your senders need? |
| TATEEDA | San Diego | A custom path across existing EHRs, referral worklists, and CRM | Scoped software and integration project | Which referral handoff should the first release complete? |
| Folio3 Digital Health | Belmont | An EHR connected to several referral portals or operational dashboards | Custom middleware and applications | Which portals, records, and status updates are in scope? |
| Taction Software | Sacramento | Routing and monitoring referrals among different EHR interfaces | Custom interfaces and integration engine support | Who owns the failed-message queue and status mapping? |
| Sidebench | Los Angeles | Specialty referrals complicated by intake, authorization, and scheduling | Workflow design and custom product development | Is the missing piece an interface, a staff application, or both? |
Luma Health: a referral platform that stays close to scheduling
Best fit: A provider group that wants a ready platform to manage referral intake through patient scheduling and can validate the return statuses it needs across its EHRs.
Luma Health approaches referrals as part of the patient access journey. Its platform can bring incoming requests, including faxed material, into staff workflows, help teams act on them, contact patients, coordinate appointments, and track the next step. Its EHR integration offering covers Epic, Oracle Health, eClinicalWorks, MEDITECH, and athenahealth; it also works with partners including NextGen, Nextech, Greenway Health, and PCC.
That is useful when the receiving practice’s problem is not merely getting a referral into its EHR. Perhaps the referral arrives, but the patient is never reached, the available specialty slot is hard to find, or staff have to work from several inboxes. Luma gives those steps a product home instead of requiring a clinic to commission each screen and outreach rule separately. Its San Francisco base also makes it a relevant California option for groups looking for a platform provider.
The distinction to test is how far the return path goes. A demo might show that a patient booked an appointment; your referring clinicians may also need a declined referral reason or the completed consultation report in their own EHR. Bring both a sending and receiving workflow to the demonstration and ask to see each status in the system where its user works. Luma is a product choice, so teams with unusual cross-network rules should check how much can be configured before assuming a custom extension is available.
| California presence | San Francisco headquarters; 3 East 3rd Ave, Suite 401, San Mateo, CA 94401 for correspondence |
| Product type | Referral, patient access, outreach, scheduling, and operational workflow platform |
| EHR ecosystem | Epic, Oracle Health, eClinicalWorks, MEDITECH, athenahealth; partnerships include NextGen, Nextech, Greenway Health, and PCC |
| Referral inputs | Electronic workflows and fax to workflow processing, depending on configuration |
| Useful functions | Intake review, patient contact, scheduling, staff actions, and referral follow-up |
| Engagement | Platform demonstration, configuration, integration, and subscription terms by proposal |
| Homepage | https://www.lumahealth.io/ |
TATEEDA: build a referral path around the systems already in use
Best fit: A California practice group that needs referral exchange shaped around its existing EHRs and a specific cross-organization workflow, with room to add more specialties or destinations later.

TATEEDA is a San Diego healthcare software development company that can work on the connection itself and the staff workflow around it. Its EHR services cover Epic, Oracle Health/Cerner, athenahealth, and Allscripts/Veradigm. Its healthcare CRM development work includes referral tracking, follow-up, messaging, and audit trails connected through FHIR endpoints and secure webhooks.
For a group whose practices will keep different EHRs, a reasonable first project is one referral route. The referring practice sends the request and approved records; the receiving team sees what is missing, accepts or declines the referral, and updates the sender. After the visit, the specialist’s report returns to the right patient and referral record. TATEEDA could build the integration, mappings, permissions, and worklist around that path without asking the entire network to change platforms. The actual write-back must be agreed with each EHR owner.
This option is particularly relevant when a packaged referral product does most of the job but leaves an important gap, or when no single product fits the network’s routing and access rules. The San Diego team can draw on engineering resources in Latin America and Eastern Europe as the integration expands. A custom build also needs an owner after launch: ask who will monitor undelivered referrals, update directory or routing rules, and maintain each connection.
| San Diego office | 7220 Trade Street, Suite 103, San Diego, CA 92121 |
| Business profile | Custom healthcare software, EHR integration, and connected CRM workflows |
| EHR environment | Epic, Oracle Health/Cerner, athenahealth, Allscripts/Veradigm; other vendor APIs assessed for the project |
| Referral functions | Routing, status tracking, staff worklists, patient or provider follow-up, and audit trails within a defined build |
| Technical options | FHIR, HL7, REST APIs, OAuth2, webhooks, and custom middleware as the connected systems require |
| First engagement | One referral path with agreed source, destination, statuses, and exception handling; minimum project $20,000 |
| Homepage | https://tateeda.com/ |
Folio3 Digital Health: connect referral portals and EHR workflows
Best fit: A specialty provider or network that wants existing referral portals and the EHR to share information through a usable staff dashboard.

Folio3 Digital Health is a strong candidate when a team already uses several referral portals and wants the EHR to stay in step with them. Its healthcare integration work includes middleware that exchanges referral details between an EMR and external portals through APIs, with a dashboard for staff to see status and work that needs attention. That is a more specific starting point than asking for a general “interoperability platform.”
Imagine an infusion center receiving requests from multiple sources. Its coordinators need to know which referral has the required documentation, whether a patient can be scheduled, and whether an update in one portal made it back to the clinical record. Folio3’s combination of healthcare integration and custom application development could support that kind of shared operational view. Across its wider EHR work, the company addresses Epic, athenahealth, eClinicalWorks, and Oracle Health with APIs, HL7, and FHIR; the referral system’s actual interfaces still depend on the selected products.
A dashboard should not become another place where staff must re-enter everything. Show Folio3 the existing referral queues and decide which system owns each status. Ask it to trace a changed appointment, missing document, and declined referral back to the original record before settling the design.
| California office | 1301 Shoreway Road, Suite 160, Belmont, CA 94002; additional office in Pleasanton |
| Business profile | Healthcare software development, EHR integration, middleware, and staff-facing applications |
| EHR ecosystem | Epic, athenahealth, eClinicalWorks, Oracle Health/Cerner; referral integration also involving AlayaCare |
| Referral connections | EHR to portal data exchange, status visibility, and operational dashboards |
| Technical options | REST APIs, HL7 v2, FHIR, SMART on FHIR, and custom mapping according to the source systems |
| First engagement | Map one EHR and its referral portals, then quote the middleware and staff view by scope |
| Homepage | https://digitalhealth.folio3.com/ |
Taction Software: make the interfaces and return messages dependable
Best fit: A group whose referral process crosses several EHRs and needs reliable message delivery, transformation, and ongoing interface support.

Taction Software brings an integration engine perspective to the problem. Its healthcare integration work spans Epic, Oracle Health/Cerner, athenahealth, Allscripts, and other clinical systems, using Mirth Connect, HL7 v2, FHIR, and APIs. It also offers referral management and care coordination development that includes routing and closed-loop tracking.
This is a useful fit when several organizations have working EHRs but the messages between them are inconsistent. One sender includes the referral reason in a field the receiver ignores; another delivers an update that never changes the original order’s status. Taction can map those differences, validate messages as they arrive, and set up monitoring so a failed delivery appears in an actionable queue. The question is not just whether a message was transmitted, but whether the receiving team can recognize it, act on it, and return a useful response.
An integration engine does not decide how your referral coordinators should handle a patient who declines a visit or a specialist who sends a report weeks later. Those workflow rules belong in the scope alongside the technical channels. If the group already has a referral platform, Taction may be most useful for connecting and operating the interfaces around it rather than building another staff application.
| California office | 555 Capitol Mall, Suite 1150A, Sacramento, CA 95814 |
| Business profile | Healthcare integration engineering, interface support, and custom care coordination software |
| EHR environment | Epic, Oracle Health/Cerner, athenahealth, Allscripts, and additional HL7/FHIR-connected systems |
| Technical layer | Mirth Connect, HL7 v2, FHIR, REST/SOAP APIs, routing and field transformation |
| Operating work | Message validation, error queues, replay, logging, and interface monitoring |
| First engagement | One sender to receiver route, including return status and support ownership; quote by scope |
| Homepage | https://www.tactionsoft.com/ |
Sidebench: untangle specialty intake before building the connection
Best fit: A specialty network whose main problem is coordinating people and decisions around referrals, with EHR integration as part of a larger workflow.

For behavioral health and multidisciplinary care, a referral may not be schedulable when it first arrives. The receiving team could need an authorization, a particular clinician, an assessment, or a set of documents before it can offer the patient an appropriate appointment. Sidebench’s healthcare work combines product design, EHR integration, and complex scheduling, including connections involving Epic, Oracle Health/Cerner, athenahealth, CentralReach, and other specialty platforms.
Sidebench is worth talking to when people do not agree on what should happen between “received” and “accepted.” It can help design the staff view and the integration together: what appears in the queue, who can request missing information, how the patient is contacted, and which milestone goes back to the referring practice. That may be more valuable than moving the referral order into another inbox with no clear owner.
The fit changes if you already have a satisfactory referral application and only need a narrow HL7 interface. Sidebench’s broader design and product development approach may be more than that job requires. Conversely, if the receiving team relies on a specialty EHR with limited integration options, discuss those access constraints before designing an ambitious bidirectional workflow.
| Los Angeles address | 149 South Barrington Avenue, Los Angeles, CA 90049 |
| Business profile | Healthcare product strategy, UX design, custom applications, and integration |
| EHR and specialty systems | Epic, Oracle Health/Cerner, athenahealth, CentralReach, CharmEHR, and other specialty platforms |
| Workflow emphasis | Specialty intake, scheduling, authorizations, staff review, and patient communication |
| Technical options | FHIR, HL7 v2, APIs, and custom bridges according to each system’s access |
| First engagement | Map the specialty referral journey and prototype the staff workflow before the wider build; quote by scope |
| Homepage | https://sidebench.com/ |
A useful demonstration is better than a generic feature list
Give each shortlisted company the same small, realistic scenario. A primary care practice on one EHR refers a patient to a specialist on another. The referral has a note and test result, but the receiving team needs one more document. The patient reschedules; the specialist eventually sends a consultation report.
Ask the vendor to show who sees each event, where the referral ID is preserved, and what returns to the sender. Then change one detail: the receiving practice declines because it does not offer the required service. A good design leaves that referral with an owner and a next action instead of calling the transfer “successful.”
For a first release, choose one sending EHR, one receiving team, and one specialty. Agree on a small set of measurable checks: referrals received and matched, requests for missing information delivered, appointments and declines reported, and consultation reports returned to the correct originating record. That scope is easier to test and support than a network-wide launch built around ideal data.
Are Referrals Getting Lost Between EHRs?
Compare five California companies that connect referral intake, scheduling, and follow-up. Find the right approach for your existing systems and staff workflow.
FAQ
Can two practices exchange referrals without using the same EHR?
Yes. They need an agreed way to exchange the request, supporting records, status changes, and consultation report. The available interfaces and write-back options depend on both EHRs and the organizations’ access arrangements. A shared referral platform or custom integration can connect the workflow without an immediate EHR migration.
Does a scheduled appointment close the referral loop?
No. Scheduling tells the referring team that the patient has a planned visit. Completion also requires the referring clinician to receive the specialist’s findings and recommendations. Keep those milestones separate in the work queue and reporting.
Should we choose a referral platform or custom development?
Start with a platform if its intake, outreach, scheduling, and EHR connections meet most of the need. Custom development becomes more useful when the group has unusual routing rules, several incompatible portals, specialty-specific approvals, or a return path that the platform cannot support. You may also need a small custom connector around an otherwise suitable product.
How should faxed referrals fit into the workflow?
They need the same patient matching, document review, ownership, and status tracking as electronic requests. Extraction can help staff sort incoming faxes, but a person should be able to review uncertain details before the referral is routed or the chart is changed.
What should we ask an integration partner before signing?
Ask for a demonstration using both your sending and receiving systems, including a missing document, a declined referral, a reschedule, and a returned report. Agree on which team owns each exception, what each EHR can read or write, and who monitors the connections after launch.
The distinction between booking a visit and receiving the specialist report follows the current referral-loop measure guidance. Vendor capabilities and locations were checked against their service and company information.