What happened
What this says
Current to 11 Oct 26Trent needed guidance on modelling many-to-many relationships between physicians and hospital groups. Olivia recommended ingesting three source tables as separate connectors and building a dashboard with hospital group as the primary filter.
Problem: Trent was setting up data for the referral-relations team and needed to model physicians who affiliate with multiple hospitals, ensuring activity history stayed linked to the person while current affiliations determined the primary grouping.
Handling: Olivia clarified the source data structure, confirmed it was a standard many-to-many pattern the brain handles well, and recommended ingesting the three tables (physicians, hospital affiliations, hospital groups) as separate connectors. She suggested building a single dashboard with hospital group as the top-level filter and offered a template from a similar customer.
Watch: Strong adoption signal; hands-on technical engagement during onboarding shows Trent's team is thinking deeply about use cases.
Details
Updated 9 Oct 26Trail
- created · Trent Nakamura 12 May 2026 16:05Hi, I'm working through the implementation and I have a question about data structure. Our referral data includes physicians identified by NPI number, and we need to group them by their affiliated hospital networks. The challenge is that some physicians work for multiple hospitals. I'm looking for the best way to set this up so that when the referral-relations team searches for a hospital group, they see all affiliated physicians and their recent calls and referrals pulled together. Our source data has three tables: physicians (with NPI), hospital groups, and a many-to-many affiliation table. How should I model this in the brain? Cheers, Trent
- public_reply · Olivia Grant 12 May 2026 22:38Hi Trent, just so I've got this right: you're ingesting physician records with NPI numbers, and you want to navigate from a hospital group to all affiliated physicians and their activity. And those relationships can be one-to-many, a physician affiliated with multiple hospitals. Can you walk me through your current data structure? I need to understand how the physician-hospital relationship is stored in your source system so I can suggest the right way to model this in the brain. Cheers, Olivia
- public_reply · Trent Nakamura 14 May 2026 12:32Yes, exactly. The EHR has a physician master table with NPI and demographics, a many-to-many affiliation table linking each physician to their hospital affiliations, and a separate hospital groups table with group IDs. One physician can have multiple rows in the affiliation table if they work for multiple hospitals. When we run our own reporting, we join across all three tables. We want the brain to do the same: filter by hospital group, see affiliated physicians, then see their recent calls and referrals from the CRM and call logs.
- public_reply · Olivia Grant 15 May 2026 10:38Perfect, that's exactly the structure the brain handles well. Here's what I'd recommend: configure the brain to ingest all three tables as separate connectors. The brain will handle the joins based on your natural keys (NPI to hospital ID). Then build a dashboard that starts with hospital groups, includes a physician filter for that group, and pulls in calls and CRM records. It's a standard many-to-many pattern and works smoothly. I can share a template from a similar customer if that helps. Does that direction work for you?
- status_change · 30 May 2026 23:59