A growing outpatient network called our admission ops team after three consecutive months of admits-versus-billing reconciliation issues. Their Sunwave EMR held one version of admit counts. Their Dazos CRM held another. The gap was roughly 15 percent.
The team assumed the platforms were broken. The audit surfaced something different. Sunwave’s built-in CRM-adjacent features (intake, referral tracking, some admissions workflow) were running in parallel with the Dazos CRM. Coordinators were populating fields in both systems, sometimes with different information. Neither system was wrong. Both were incomplete.
This piece walks the operational picture of Sunwave integration at treatment center admissions. Which fields matter, where PHI boundaries live, when to use Sunwave’s built-in intake features versus a downstream CRM, and how Sunwave compares to Kipu as the EMR anchoring the admissions stack.
Disclosure: Webserv is a Dazos implementation partner. This article evaluates Sunwave integration architecture across CRM platforms on operational merits. Sunwave, Kipu, Dazos, Salesforce, and HubSpot are trademarks of their respective owners; use here is nominative and editorial only.
Key Takeaways
- Sunwave is a behavioral-health-native EMR that ships with more CRM-adjacent functionality than Kipu (intake, referral tracking, some admissions workflow). The extra functionality is a feature and a source of confusion depending on how the stack is scoped.
- The right integration architecture is bidirectional sync between Sunwave and the admissions CRM on a defined set of fields. Do not run Sunwave’s built-in intake features alongside a separate CRM without deciding which system owns which fields.
- The 12-field mapping that works for Kipu also works for Sunwave: seven fields forward at admit, five fields back on the ongoing cadence.
- Sunwave versus Kipu comparison. Kipu has broader adoption and more mature integrations. Sunwave has a cleaner UI and more built-in admissions-adjacent functionality. Facilities running Dazos as CRM find both EMRs integrate cleanly. Facilities running Salesforce or HubSpot as CRM face a similar middleware layer with either EMR.
- PHI boundaries are the same for Sunwave as for Kipu. Sync operational metadata (admit status, LOC, admit date, discharge date). Do not sync clinical notes, treatment plans, or medication records. Every tool needs BAA coverage that references 42 CFR Part 2, not just HIPAA.
- The scoping decision that matters most on a Sunwave stack. Which system owns intake and referral tracking, Sunwave or the CRM. Running both in parallel is where the coordinator reconciliation problem starts.
What Sunwave Actually Does
Sunwave is a cloud-native behavioral health EMR designed for outpatient and residential treatment centers. The platform holds the clinical record: assessments, treatment plans, clinical notes, medication administration, group therapy attendance, discharge summaries.
Sunwave also ships with intake, referral tracking, and some admissions-workflow functionality built into the same platform. This is the feature that separates Sunwave from Kipu operationally.
The scoping question every facility running Sunwave has to answer. Is Sunwave the system of record for admissions intake, or is a downstream CRM (Dazos, Salesforce, HubSpot) the system of record with Sunwave holding the clinical layer only.
Both models work. Running both in parallel does not. That is the failure mode most Sunwave audits surface.
Behavioral health treatment access is heavily influenced by intake workflow quality (SAMHSA, National Survey of Substance Abuse Treatment Services).
A clean scoping decision between Sunwave’s built-in intake and a downstream CRM is what keeps admissions operations from fragmenting across two systems.
Why the CRM to Sunwave Integration Matters
Same three operational failures that show up when any EMR-CRM integration is broken, plus a Sunwave-specific fourth.
Coordinators re-enter data manually. The CRM lead record moves to admitted. The Sunwave patient record has to be created from scratch. Names get misspelled. Dates get transcribed wrong. Every manual step is a data quality erosion event.
Reporting fragments. Admits by source lives in the CRM. Clinical outcomes live in Sunwave. Marketing attribution against admits requires stitching two systems together weekly.
Discharge status never routes back to marketing. Marketing spend gets calibrated against admit count, not admit quality. Cost per completed treatment stays a mystery.
Sunwave-specific: parallel intake systems. When Sunwave’s built-in intake features run alongside a separate CRM’s intake pipeline, coordinators populate both. The two systems drift. The 15-percent reconciliation gap the operator in the opener saw was this exact problem.
The fix is a scoping decision plus a bidirectional integration. Decide which system owns intake and referral tracking. Wire the integration to reflect that decision.
DEFINITION
Sunwave field mapping is where the CRM-to-EMR integration surface gets specified: lead source, insurance identifier, level of care, and admit date sync from CRM into Sunwave. Group therapy scheduling, MAT dosing detail, and clinical notes stay Sunwave-only.
The Field Mapping That Actually Works
Same 12-field mapping that works for Kipu works for Sunwave. Seven fields forward at admit. Five fields back on the ongoing cadence.
CRM to Sunwave (forward push at admit).
- Patient name, DOB, contact information
- Admit date and scheduled LOC
- Referral source and campaign attribution
- Insurance payer, plan, member ID, alpha prefix (for BCBS)
- Prior-auth status and days authorized
- Expected LOS based on payer approval
- Primary admissions coordinator owner
Sunwave to CRM (backward push after admit).
- Admit confirmation (Yes/No)
- Current LOC (may change from scheduled during treatment)
- Days in treatment
- Discharge date
- Discharge type (completed, AMA, transferred, administrative)
The mapping is the same across Kipu and Sunwave because the operational needs on the admissions side are the same. What changes is the API surface each EMR exposes for the integration. Both work. Both require configuration.
The LOC field should follow ASAM’s standard levels of care so the mapping stays clinically coherent on both sides (ASAM Criteria).
Sunwave and the major admissions CRMs all support ASAM-shaped LOC picklists. Facilities running Dazos as the behavioral-health-native admissions CRM get the cleanest picklist alignment when Sunwave sits downstream on the clinical side.
Bidirectional Sync vs One-Way Sync
The architecture question is the same as with Kipu. One-way sync produces reporting fragmentation. Bidirectional sync produces a working system.
One-way sync (CRM to Sunwave at admit). The CRM pushes patient record and admit metadata into Sunwave when the admit fires. Sunwave never pushes back. The CRM lead record stays frozen at “Admitted” and never updates as treatment progresses. This is the architecture that produces the reconciliation problem.
Bidirectional sync (CRM ↔ Sunwave on scheduled cadence). The CRM pushes forward at admit. Sunwave pushes admit confirmation, LOC changes, days in treatment, and discharge status back to the CRM on a scheduled cadence, usually every 4-6 hours.
The scheduled cadence matters. Real-time sync creates race conditions when a coordinator updates a field in one system while the other system is mid-sync. Every 4-6 hours is fast enough for admissions decisions and slow enough to avoid conflicts.
Facilities running Sunwave with a downstream CRM should default to bidirectional sync. The same principle applies as with Kipu integration architecture.
PHI Boundaries: What Should Sync and What Shouldn’t
The compliance layer for Sunwave integration is the same as for Kipu. Both EMRs hold SUD patient records subject to 42 CFR Part 2.
What should sync. Operational metadata that admissions needs to make decisions. Admit status, LOC, admit date, discharge date, discharge type. Every field in the 12-field mapping above is defensible under Part 2 as necessary for admissions operations.
What should not sync. Clinical notes. Treatment plans. Medication administration records. Assessment scores. Progress notes. Group therapy attendance. Any clinical detail in the CRM is a compliance exposure and rarely produces operational value that the four load-bearing fields (admit status, LOC, admit date, discharge date) do not already carry.
Every tool in the integration path (CRM, Sunwave, middleware if used, any downstream reporting tool) needs a BAA that references 42 CFR Part 2 confidentiality standards. Standard HIPAA business-associate language alone is not enough. The Part 2 layer is what governs SUD patient records specifically.
The Sunwave scoping question adds one more compliance consideration. If Sunwave’s built-in intake features are the system of record, more coordinator data lives inside Sunwave. If a downstream CRM is the system of record, more coordinator data lives in the CRM.
The compliance surface shifts accordingly. Both are defensible with the right BAAs and access controls. Neither is defensible without them.
Integration Architecture: Native vs Middleware
Native and middleware architectures both work for Sunwave. Same tradeoffs as Kipu with some Sunwave-specific notes.
Native connector. The CRM vendor and Sunwave maintain a direct integration. Field mapping happens inside the CRM configuration. Sync frequency is set at the connector level. Maintenance burden is low.
Dazos supports native Sunwave integration alongside its native Kipu integration. This is one of the operational reasons Dazos scales well at facilities where the EMR anchor is either Sunwave or Kipu.
Middleware. A third-party integration platform (Zapier, Workato, MuleSoft, or a custom connector) sits between the CRM and Sunwave. This is the architecture required for Salesforce and HubSpot integrations to Sunwave.
The middleware maintenance layer is the same as for Kipu. Every time Sunwave updates its API, every time the CRM updates its API, the middleware needs verification. Facilities running Salesforce or HubSpot with Sunwave sign up for that maintenance layer as part of the ongoing cost.
Sunwave vs Kipu
The operator-friendly comparison based on published product documentation as of 2026-07.
Adoption and maturity. Kipu has broader adoption across behavioral health, particularly at longer-tenured facilities. Sunwave has grown faster among newer facilities and cloud-first operators.
User interface. Sunwave ships a cleaner, more modern UI. Kipu’s UI is more mature and function-dense, which is a feature for power users and friction for new coordinators.
Built-in admissions functionality. Sunwave ships with more intake, referral tracking, and admissions-workflow functionality inside the EMR. Kipu is more focused on the clinical layer. This is where the Sunwave scoping decision matters.
CRM integration ecosystem. Kipu has native Dazos integration and mature middleware paths for Salesforce and HubSpot. Sunwave has native Dazos integration and comparable middleware paths.
Pricing. Both platforms price on facility size and user seats. Neither publishes public pricing. Facilities evaluating both should get quotes for the specific admit volume and coordinator headcount.
Best fit. Kipu fits facilities that want the deepest EMR feature set and are running a separate admissions CRM downstream. Sunwave fits facilities that want a cleaner UI, more built-in admissions functionality, and are willing to make the scoping decision about which system owns intake.
Neither EMR is objectively better. Both work. The choice depends on the facility’s operating profile and the CRM stack downstream.
COMMON MISTAKE
Treating Sunwave the same as Kipu on the integration surface. Sunwave has a thinner API and a different reporting model than Kipu. Middleware that worked for a Kipu integration will not necessarily map cleanly to Sunwave. Scope the specific fields against the Sunwave data model before quoting integration timelines.
Common Sunwave Integration Failure Modes
Five failure modes that show up on Sunwave integration audits.
Parallel intake systems. Sunwave’s built-in intake features run alongside a separate CRM’s intake pipeline. Coordinators populate both. Records drift. Reconciliation problems accumulate. This is the Sunwave-specific failure mode not seen with Kipu.
Set-and-forget. The integration was configured 18 months ago and nobody has looked at it since. The sync fires on some records and silently drops others. Data quality erodes without alerting anyone.
One-way sync accepted as finished. The CRM pushes forward at admit. Sunwave never pushes back. Reporting fragments. Coordinators build a manual reconciliation habit.
Over-syncing PHI. The integration was built to sync everything Sunwave holds. Clinical notes, medication records, and treatment plans end up in the CRM. Compliance exposure grows quietly.
No ownership. Nobody in the org owns the integration health. When something breaks, nobody notices until a report goes sideways or a coordinator raises it in a huddle.
The pattern under the last four is the same as with Kipu. Treat the integration as an operational system that needs weekly attention, not a one-time install. The Sunwave-specific first failure mode requires an explicit scoping decision on top of that operational discipline.
What a Webserv Engagement Looks Like
The 6-week Admission Ops sprint includes Sunwave integration configuration as part of Pillar 2 (CRM and Workflow Optimization) and Pillar 3 (VOB and Insurance Ops).
Week 1, Onboard and Audit. Current-state map of the Sunwave integration if it exists. Field mapping inventory. Scoping review (Sunwave’s built-in intake vs downstream CRM as system of record). PHI boundary review.
Week 2, Lead Tracking. Call tracking, form and chat capture, source mapping into CRM. The layer that populates the fields pushing into Sunwave.
Week 3, CRM Pipeline. Pipeline stages built. Automations for status changes. Sunwave integration configured against the 12-field mapping. Native connector or middleware setup depending on CRM platform.
Week 4, VOB Workflow. VOB object built out. Prior-auth flags. Status tracking. The upstream layer that determines what pushes into Sunwave at admit.
Weeks 5-6, Training and Launch. Coordinator training on the new sync architecture. Weekly integration health monitoring cadence installed. Scoping decision documented so the parallel-intake failure mode does not creep back in.
Pricing. One-time setup runs $7,500 to $15,000 depending on center size, CRM complexity, and integration scope. Sunwave integration configuration is included when the facility already runs Sunwave.
Ongoing retainer tiers by location count: $3,500 to $5,000 per month for 1-2 locations, $5,000 to $8,000 per month for 3-5 locations, $8,000 to $15,000 per month for 6+ locations.
The Fast-Track Diagnostic is the low-friction entry: $3,000, credited 100 percent toward month one if the facility moves forward. Two-week audit of the current Sunwave integration health, scoping review, and firm proposal.
The perspective in this article comes from 9 years working exclusively inside behavioral health.
We are a team built by people in recovery who understand that behind every admission is someone asking for help. If that resonates, get to know us.
Frequently Asked Questions
For the fuller admissions technology stack, see behavioral health marketing guide and Salesforce for admissions teams. It’s also worth pairing with HubSpot for treatment center admissions.
How do I integrate Sunwave with my admissions CRM?
The integration architecture depends on the CRM. Dazos has a native Sunwave connector that syncs on a scheduled cadence. Salesforce and HubSpot both require middleware (Zapier, Workato, or a custom connector).
The right integration is bidirectional. The CRM pushes patient record and admit metadata forward at admit. Sunwave pushes admit confirmation, LOC changes, days in treatment, and discharge status back to the CRM on a 4-6 hour cadence.
Before configuring the integration, make the scoping decision. Which system owns intake and referral tracking. Sunwave’s built-in intake features can be the system of record, or a downstream CRM can. Running both in parallel is where reconciliation problems start.
Should I use Sunwave’s built-in intake features or a separate CRM?
Depends on the facility’s operating profile. Small facilities under 15 admits per month can often run Sunwave’s built-in intake as the system of record and skip a separate CRM entirely. Sunwave holds intake, referral tracking, and the admissions workflow alongside the clinical record.
Larger facilities running heavy paid media, referral partner attribution, and coordinator-level admissions ops usually benefit from a purpose-built admissions CRM downstream (Dazos, Salesforce, or HubSpot). The CRM handles intake and admissions. Sunwave handles the clinical record from admit forward.
The failure mode is running both systems in parallel without a clear scoping decision. Coordinators populate fields in both systems, the records drift, and the reconciliation problem accumulates over months. Whatever the scoping decision is, document it and enforce it.
How does Sunwave compare to Kipu for behavioral health admissions?
Both are behavioral-health-native EMRs. Kipu has broader adoption and a more mature integration ecosystem. Sunwave has a cleaner UI and more built-in admissions-adjacent functionality.
The choice depends on the facility’s operating profile. Facilities that want the deepest EMR feature set with a separate admissions CRM downstream often pick Kipu. Facilities that want a modern UI and more built-in admissions functionality often pick Sunwave.
Both integrate cleanly with Dazos through native connectors. Both require middleware for Salesforce or HubSpot integration. The CRM stack decision is more consequential than the EMR choice for most admissions operations.
What fields should sync between Sunwave and my CRM?
Twelve fields. Same mapping as Kipu. Seven push forward from the CRM to Sunwave at admit: patient name and DOB, contact information, admit date and scheduled LOC, referral source and campaign attribution, insurance payer and plan and member ID and alpha prefix, prior-auth status and days authorized, expected LOS, and primary admissions coordinator owner.
Five push back from Sunwave to the CRM on the ongoing cadence: admit confirmation, current LOC (which may change during treatment), days in treatment, discharge date, and discharge type.
Do not sync clinical notes, treatment plans, medication records, assessment scores, or progress notes. Anything clinical stays in Sunwave. The CRM only needs the operational metadata that admissions and marketing use to make decisions.
Does Dazos integrate with Sunwave natively?
Yes. Dazos supports native Sunwave integration alongside its native Kipu integration. Field mapping happens inside Dazos configuration. Sync frequency is set at the connector level. Maintenance burden is low because both vendors update the connector as their APIs change.
This is one of the operational reasons Dazos scales well at facilities where the EMR anchor is either Sunwave or Kipu. The alternative is Salesforce or HubSpot with a middleware layer, which works but adds ongoing maintenance overhead.
Facilities running Dazos with Sunwave get the cleanest architecture available today when Sunwave is the EMR of choice.
What breaks most often on Sunwave integrations?
The Sunwave-specific failure mode is parallel intake systems. Sunwave’s built-in intake features run alongside a separate CRM’s intake pipeline. Coordinators populate both. Records drift. Reconciliation problems accumulate over months.
The fix is a scoping decision. Decide which system owns intake and referral tracking. Configure the integration to reflect that decision. Document the decision so the parallel-intake failure mode does not creep back in when new coordinators start.
The other failure modes are the same as any EMR-CRM integration. Set-and-forget silent drift. One-way sync accepted as finished. Over-syncing PHI. No ownership. All fixable with weekly integration health monitoring by one accountable person.
How do I decide between Sunwave and Kipu when picking an EMR?
Three questions decide it. Does the facility want more built-in admissions functionality in the EMR, or is admissions handled downstream in a purpose-built CRM. What is the coordinator team’s UI preference, cleaner and modern versus function-dense and mature. What is the integration ecosystem with the CRM the facility already runs or plans to run.
Two or three yeses on Sunwave-friendly answers point to Sunwave. Two or three yeses on Kipu-friendly answers point to Kipu. Neither answer is universally better.
Whichever EMR the facility picks, the same integration disciplines apply. Bidirectional sync on the 12-field mapping. PHI boundaries respected. One person accountable for integration health. Weekly monitoring cadence. The EMR choice matters less than the operational discipline around the integration.
Closing Note From the Admission Ops Floor
Sunwave is a strong behavioral health EMR. The scoping decision it requires (intake in Sunwave versus intake in a downstream CRM) is where most Sunwave stacks succeed or fail.
Make the scoping decision explicitly. Configure the integration to reflect it. Put one person on the hook for integration health. Run bidirectional sync on the twelve fields that matter. Respect the PHI boundary.
If you are running Sunwave alongside Dazos, Salesforce, or HubSpot and the sync feels wrong (coordinators re-entering data, reconciliation problems, discharge status missing from marketing attribution), the audit is worth running.
Start with the $3,000 Fast-Track Diagnostic. Credited 100 percent toward month one whichever way the audit points.
Jim Malcom is the Director of Admission Ops at Webserv. He has spent his career inside behavioral health admissions operations (call floors, VOBs, CRMs, and the reporting stack that ties them together) and now leads the Webserv admission ops practice for treatment center operators nationwide.
