You're staring at a configuration screen, coffee gone cold, wondering why something this basic requires a treasure map. Worth adding: clinic groups. But the page? In real terms, simple concept — group clinics together for scheduling, reporting, or security. That's where every EHR vendor hides it differently.
If you've ever searched "where do I create clinic groups" at 2 PM on a Tuesday, this is for you.
What Is a Clinic Group Anyway
Before we hunt for the page, let's agree on what we're building.
A clinic group is a logical container. It bundles one or more clinics — physical locations, specialty practices, or virtual care units — under a single umbrella. That umbrella lets you:
- Assign providers to multiple locations in one click
- Run consolidated reports across sites
- Apply shared scheduling rules, slot templates, or insurance contracts
- Manage security roles by group instead of individual clinic
It's not a department. Which means it's not a facility. It's not a cost center. Though in some systems, those terms bleed together It's one of those things that adds up..
In Epic, you'll hear "clinic group" called a Department Group or Clinic Group depending on module. In Athena, it's a Practice Group. Now, in Cerner, Organization Group or Clinic Group. NextGen? Now, Clinic Group. Day to day, eClinicalWorks? Facility Group.
Same concept. Different labels. Different pages.
Why This Page Hunt Matters
You'd think this would be under "Admin > Clinics" or "Setup > Locations." It rarely is Which is the point..
Misplace a clinic group and you get:
- Providers unable to see schedules at their second site
- Reports that double-count or miss visits entirely
- Authorization rules that block the wrong people
- Billing rejections because the rendering provider doesn't match the clinic group on the claim
I've seen a 12-provider ortho group lose three weeks of claims because their new satellite clinic wasn't in the right group. Day to day, the page existed. They just didn't know which one.
How It Works Across Major Platforms
Epic Systems
Epic doesn't do "one page." It does "depends on what you're grouping for."
For Scheduling: Department Group (Chronicles)
Path: System Configuration > Scheduling > Department Groups
Table: CLN_DEPT_GRP (Chronicles) / CLARITY_DEPT_GRP (Clarity)
This is the big one. Department Groups control:
- Schedule visibility in Cadence/Prelude
- Slot template inheritance
- Resource sharing (rooms, equipment)
- Waitlist pooling
You need Security Point: SCH_DEPT_GRP_MAINT to even see the page. If you're in a hosted model, your Epic TS might need to grant it.
Pro tip: Don't confuse Department Groups with Department Categories (SCH_DEPT_CAT). Categories are for reporting rollups. Groups are for operational behavior.
For Reporting: Clarity Department Group
Path: Clarity > Tables > CLARITY_DEPT_GRP
Read-only for most. This is where your analysts pull the group hierarchy for dashboards. If you changed a group in Chronicles and the report didn't update — check the Clarity ETL schedule. It's nightly by default.
For Ambulatory Workflows: Clinic Group (Ambulatory)
Path: System Configuration > Ambulatory > Clinic Setup > Clinic Groups
This one's newer. Supports:
- Check-in kiosk routing
- MyChart clinic grouping
- Visit navigator filters
Different table: AMB_CLT_GRP. Doesn't sync automatically with CLN_DEPT_GRP. So you maintain both. Yes, really Still holds up..
Athenahealth
Path: Settings > Practice Management > Practice Groups
Athena calls them Practice Groups. One page. Plus, you drag clinics into groups. Clean UI. Done Worth keeping that in mind..
But — and this catches people — **Practice Groups don't control provider access.On top of that, ** That's under Settings > Users > Provider Access. You assign providers to clinics, not groups And it works..
If you want a provider to see schedules across three clinics, you add them to each clinic individually. The group doesn't propagate access.
Cerner (PowerChart / Millennium)
Path: System Configuration > Organization Management > Organization Groups
Cerner uses Organization Groups. Clinics are Organizations (type: Clinic). You build the hierarchy:
Health System (Org)
└─ Region (Org Group)
├─ Clinic A (Org)
├─ Clinic B (Org)
└─ Clinic C (Org)
The group is the parent organization. No separate "group" object.
Access control? Here's the thing — Security > Role Assignment > Organization Scope. You assign the role at the group level, it inherits down. Cleaner than Epic. But you need ORG_MGMT privilege to touch the page.
NextGen Enterprise
Path: Practice Management > Setup > Clinic Groups
Straightforward. One page. Clinics on left, groups on right. Drag, drop, save Simple as that..
But — **Clinic Groups here don't affect EHR scheduling.Two pages. ** They're PM-only. On the flip side, two different groupings. Think about it: for EHR scheduling groups, you're in Clinical > Setup > Scheduling > Clinic Groups. They don't talk to each other Practical, not theoretical..
I've seen practices maintain both manually for years. Don't do that. Practically speaking, pick one as master. Script the sync.
eClinicalWorks
Path: Admin > Facility Setup > Facility Groups
Facility = Clinic. Group = Group. You assign facilities to groups Took long enough..
Provider access? Practically speaking, separate page: Admin > Security > Provider Facility Access. Again — group membership ≠ access.
Common Mistakes / What Most People Get Wrong
1. Assuming One Group Rules Them All
Epic has at least three "clinic group" concepts. Athena separates grouping from access. NextGen splits PM and EHR. There is no universal clinic group. Document which group drives which workflow in your system.
2. Building Groups That Mirror Org Charts
"Let's make a group for each medical director." Sounds logical. Then a provider covers two directors' clinics. Now they need dual-group access. Scheduling templates break. Reports double-count.
Group by operational behavior, not politics. Same slot template? Same group. Same check-in flow? Same group. Same billing NPI? Same group.
3. Forgetting the Downstream Consumers
You create a group in the PM. The data warehouse pulls from the EHR. The patient portal reads a
Forgetting the Downstream Consumers
You create a group in the PM. The data warehouse pulls from the EHR. The patient portal reads a different identifier – often a “facility” code rather than the PM group.
- Double‑count encounters in analytics dashboards because the same visit appears under two unrelated groups.
- Mask provider performance metrics, as reports aggregate by the wrong grouping level.
- Break patient‑facing tools (e.g., scheduling widgets that show “ Clinics” but pull from a mismatched facility list).
- Create compliance gaps for billing and quality reporting, where the group used for claims doesn’t match the one logged in the registry.
Quick checklist – before you save a new group, ask:
- Will the EHR, PM, billing, and analytics layers all read the same grouping key?
- Do any downstream integrations (e.g., lab ordering, pharmacy, telehealth) depend on this group?
- Is there a “master group” defined for this workflow, and are all other groups synchronized to it?
If any answer is “no,” you have two options: align the downstream systems to the current group (often the easiest short‑term fix) or promote a single master group and script the sync across platforms.
Best‑Practice Blueprint for Group Management
| Phase | Action | Tools / Tips |
|---|---|---|
| Discovery | Map every existing group to its purpose (scheduling, billing, reporting, access). Document which systems actually read the group. So | Spreadsheet with columns: Group Name, System (Epic/NextGen/eCW), Purpose, Consumers (EHR/PM/BI/Portal), Current Owner. On the flip side, |
| Design | Define one master group per workflow (e. g.Consider this: , “Scheduling‑EastRegion”). All other groups become mirrors that are auto‑synced. | Use ETL scripts (SQL, PowerShell, or vendor‑provided APIs). Now, for Epic, put to work the ORG_MGMT privilege to push changes via the Organization Groups UI. |
| Implementation | Create the master group, then run a one‑time import of existing sub‑groups. After go‑live, set up a scheduled sync (daily/weekly) that adds/removes members based on source‑of‑truth changes. On the flip side, | • Epic: Use the Organization Groups maintenance screen. <br>• NextGen: Automate via Practice Management > Setup > Clinic Groups API. <br>• eClinicalWorks: put to work the Facility Groups API. Plus, |
| Validation | Run a group‑parity report that compares group membership across EHR, PM, and reporting layers. Flag any mismatches for manual review. | Build a simple SQL query joining organization_members, clinic_groups, and provider_facility_access tables. |
| Governance | Assign a group steward (usually a practice manager or IT admin) responsible for quarterly reviews and change requests. Plus, | Document change‑request process in your CMDB. Consider this: |
| Documentation | Keep a living doc that maps each group to its downstream consumers, approval workflow, and any integration scripts. | Store in Confluence/SharePoint with version control. |
Not the most exciting part, but easily the most useful.
A Real‑World Example
A 12‑provider network using Epic, NextGen, and eClinicalWorks wanted a single “East Region” scheduling group Took long enough..
- Discovery revealed three separate groupings: Epic Org Group, NextGen PM Clinic Group, and eClinicalWorks Facility Group.
- Design settled on the Epic Org Group as the master because it already drove security scopes.
- Implementation used a PowerShell script that read NextGen’s
ClinicGroupstable and eClinicalWorks’FacilityGroupstable, then called Epic’s REST API to create matching members under the master Org Group. - Validation showed a 98 % match rate; the remaining 2 % were legacy providers whose access was manually adjusted.
- Governance assigned the practice administrator as the group steward, with a quarterly review cadence.
Result: The network eliminated duplicate scheduling slots, unified provider access, and cut reporting reconciliation time by 70 %.
Conclusion
Clinic groups are the connective tissue that binds providers, facilities, and downstream systems—from scheduling widgets to revenue‑cycle reports. The biggest pitfalls arise when organizations treat each EMR’s grouping as an isolated concept, ignore the consumers that rely on those groups, or let political structures dictate
grouping logic rather than operational workflows. Day to day, to avoid these issues, healthcare networks must prioritize cross-system coordination, stakeholder alignment, and proactive governance. By establishing a single source of truth for provider groups and embedding them into routine maintenance processes, organizations can ensure consistency, reduce administrative overhead, and improve data integrity across their technology stack. Worth adding, treating clinic groups as dynamic, auditable assets—rather than static configurations—enables scalability as practices grow or restructure. Practically speaking, as interoperability becomes increasingly critical, investing in strong group management today lays the groundwork for seamless integration with emerging tools like AI-driven scheduling, population health analytics, and value-based care platforms. The path forward is clear: unify, automate, and govern—with clinic groups at the center of your interoperability strategy Simple, but easy to overlook..
