The short answer
Adding a location turns previously local choices into organization-wide governance decisions: how locations and entities are modeled, which configurations are shared, who may access each record, how clients transfer between programs, how measures are defined, and who owns rollout decisions. A governed core may reduce inconsistency, but it still requires validation of local requirements and contingencies for migration, access errors, interface failures, and downtime.
Why expansion changes the operating model
A new site can introduce additional programs, payer arrangements, staffing models, licensing obligations, access boundaries, billing configurations, and reporting dimensions. Some functions may remain centralized, while particular records, episodes, or workflows may legitimately remain separate. The important question is how work and data should cross those boundaries.
Treat expansion as a structured test of the existing operating model. Check whether current tools and controls support the added locations, jurisdictions, roles, data exchanges, local exceptions, and reporting needs; then document what can be reused, what must be reconfigured, and what requires a new control.
Decide what is shared and what stays local
Use the following decisions to define the governed core, permitted local variants, and approval path before launch. Revisit them during rollout when testing reveals a legitimate program, payer, population, or jurisdictional difference.
| Governance decision | What to define and test |
|---|---|
| Location and entity model | Name each entity, facility, program, service location, and level of care; document how those dimensions affect records, billing, scheduling, and reports |
| Templates and workflow configuration | Identify the governed core, permitted local variants, approval owner, version history, effective date, test method, and rollback process |
| ASAM-based SUD placement and transition processes | Use a governed framework while preserving individualized assessment and documenting population-, program-, payer-, and jurisdiction-specific requirements; qualified clinical leaders should approve each site’s workflow |
| Access, privacy, and record ownership | Define authorized cross-site access, role boundaries, staff coverage, record ownership, segregation of duties, and provisioning and removal responsibilities |
| Cross-site transfer and identity matching | Specify how identities are matched, records are exchanged or linked, responsibilities are handed off, updates are reconciled, and work continues during an interface or platform outage |
| Reporting definitions and controls | For each selected measure, document its owner, source fields, denominator, calculation, reporting period, exclusions, correction process, location filters, access rules, and reconciliation to site-level results |
Documenting and testing these decisions can reveal gaps earlier and clarify what the new site may inherit or must localize. Include failure cases—for example, an unmatched client identity, an authorization attached to the wrong location, or a report that does not reconcile—as tests rather than assumed outcomes.
Evaluate architecture by behavior, not by label
Organizations may operate separate systems with centralized exchange and reporting, a shared platform with location boundaries, or a hybrid of the two. Use the following questions to compare architectures by their demonstrated behavior rather than their labels.
| Verify | If sites use separate systems | If sites use a shared platform |
|---|---|---|
| Record exchange and authorized access | Test identity matching, interface or export coverage, synchronization timing, error handling, permissions, and the receiving site’s ability to use the information | Confirm whether records actually span tenants, entities, programs, and modules; test permissions, duplicate handling, ownership, and location-specific restrictions |
| Capacity and census visibility | Verify how site feeds are combined, how often they refresh, which status definitions are mapped, and how discrepancies are reconciled | Verify location filters, status definitions, update latency, concurrent edits, audit history, and behavior during outages |
| Configuration consistency | Compare templates, codes, field mappings, release schedules, local changes, and the process for keeping approved standards aligned | Test inheritance, local overrides, version control, effective dates, approvals, and whether a central change could disrupt a site-specific workflow |
| Consolidated reporting | Verify mappings to a common data model, refresh schedules, duplicate handling, calculation consistency, and reconciliation to source reports | Verify shared definitions, entity and location dimensions, access restrictions, adjustments, drill-down capability, and reconciliation to each site’s results |
| Adding a location | Estimate configuration, migration, interface, validation, training, support, and cutover work; identify which components can be reused | Test what can be inherited safely, what must be localized, who approves changes, how data will be migrated, and what contingency applies if launch criteria are not met |
| Staff working across locations | Assess sign-in and identity management, training differences, access provisioning, workflow variation, and support responsibilities | Assess location context, least-privilege roles, cross-site scheduling and documentation, local workflow differences, and the risk of acting in the wrong site |
Estimate total implementation and operating cost under the organization’s actual site model. For separate systems, include interfaces, mappings, reconciliation, identity management, vendor coordination, and consolidated reporting. For a shared platform, include configuration, local validation, migration, training, support, upgrades, access governance, and contingency planning. Either cost profile may change as sites and requirements are added.
Evaluate vendors with the same two-site test
Vendor product pages can define a demonstration starting point, but they do not establish how a particular deployment, bundle, integration, or configuration will behave. Ask each vendor to run the same scripted multi-site scenario and record any prerequisites, manual steps, module boundaries, and configuration limits.
| Vendor-described starting point | Multi-site proof request |
|---|---|
| Sunwave’s EMR page describes one patient file spanning admissions, assessments, treatment plans, and billing, as well as configurable templates and scheduling. | Demonstrate entity and location boundaries, configuration inheritance and exceptions, cross-site identity and record handling, report reconciliation, audit history, integration failure handling, and cutover controls. |
| Kipu’s EMR page describes provider-, location-, and group-based scheduling, occupancy, outcomes reporting by program and location, and claims-data connections to Kipu RCM or other billing products. Its RCM page describes eligibility, utilization, claims, payments, and reporting workflows. | Demonstrate identity handling across modules, interface timing and errors, shared and local configuration, location-level access, consolidated definitions, reconciliation to source records, and downtime procedures. |
A practical sandbox test can follow this sequence:
- Model two entities, two locations, and several programs, including one shared template and one approved local exception.
- Provision a single-site role, a cross-site coverage role, and a reporting role; verify allowed and denied actions in each location context.
- Admit a synthetic client at one site, transfer or refer the client to another, and inspect identity matching, record ownership, permissions, handoff status, and audit history.
- Change a governed definition, produce site and consolidated reports, and reconcile both outputs to their source records.
- Exercise an interface outage or failed launch criterion and have the vendor show the documented downtime, escalation, rollback, and recovery path.
Sources
Sources reviewed September 9, 2026.
