Skip to content
BuildClub — AI Built in Plain Sight
← Back to Case Studies
BothHealthcare

~20% of credentialing hours recovered; denial appeal turnaround materially reduced

The partition design was the part I didn't appreciate going in. Three teams, three different access scopes, same underlying payer knowledge — and the compliance officer signed off before we shipped V1. That's not a detail. That's the whole reason this works in a regulated environment.

CFO, multi-specialty medical group

Composite example — illustrative of typical Company Brain engagements, not based on a single client.

The starting situation

A multi-specialty medical group with roughly 80 providers across several states, operating on an established EHR, practice management, and clearinghouse stack. Credentialing, prior authorization, and denials management all operate on overlapping payer-specific knowledge — but each team held it in separate folders, separate spreadsheets, and separate institutional memories. Credentialing coordinators couldn't easily access the denial patterns that would have warned them about payer-specific documentation traps. Denial analysts couldn't access credentialing reference materials that would have told them when a payer-provider relationship had just been re-established. The knowledge that would have helped any one of these teams reliably lived in another team's drive. The strategic question: can the same payer knowledge serve all three functions without violating internal access boundaries or PHI handling requirements?

What we built

  • Ingestion: The internal credentialing reference library, denial appeal templates with historical resolution outcomes attached, payer-specific playbooks organized one folder per payer, CDI documentation requirements, fee schedules by payer, and a prior authorization rules library indexed by payer and drug class.
  • Knowledge partitions: Four access-scoped knowledge partitions with strict isolation on PHI-adjacent content. The Credentialing partition holds the credentialing library, CAQH workflow notes, and payer application history. The RCM partition holds denial patterns, appeal templates, and fee schedules. The Prior Auth partition holds per-payer rules and documentation requirements. The Cross-functional partition holds payer-specific playbooks made accessible to all clinical operations teams.
  • Deployment mode: In-tenant inside the medical group's AWS environment. Required for HIPAA compliance and the PHI proximity posture the compliance officer had already established for other applications.
  • Integration points: The EHR (read-only access to clinical documentation), the practice management system, and the credentialing system.
  • Frontend: Claude with a HIPAA-aware configuration; access logging routed to the compliance team's existing audit trail.
  • What the Brain answers: "What's the documentation requirement for this payer's prior authorization on this drug class." "What appeal language has worked for this denial reason with this payer historically." "What's the current fee schedule for this CPT code with this payer, and where have we seen variance."

How it evolved

V1 shipped at 90 days with the credentialing library and denial appeal templates ingested. The Credentialing and RCM partitions went live first because they served the two highest-volume operational clusters and carried the cleanest documentation. Adoption was fastest in the RCM team — denial work is high-frequency and the answers replaced the most repetitive lookups in the analyst day.

V2 landed at six months. Per-payer playbooks and the prior authorization rules library came online; the Prior Auth partition went live, and cross-functional access was opened for the payer playbook content so that any clinical operations team member could query shared payer knowledge without breaching the tighter scope on team-specific materials. V3, at roughly fifteen months, added CDI documentation requirements and the full fee schedule corpus. By that point the Brain had become the operational reference layer for all three functions, and the practice was using it as the canonical answer source for payer behavior questions.

What it changed

  • Roughly 20% of credentialing team operational hours recovered, redirected to provider onboarding velocity and active payer relationship management.
  • Denial appeal turnaround time reduced materially, driven by faster access to historically successful appeal language and supporting documentation.
  • New-provider revenue ramp shortened by weeks, with credentialing applications drafted faster and follow-up cadence templated through the Brain.
  • Cross-team knowledge sharing enabled — denial analysts no longer waited for credentialing to surface payer policy changes; the change landed in the cross-functional partition and was queryable across teams the same day.

What it didn't change

The EHR, practice management system, and clearinghouse all stayed exactly where they were and continued to handle the clinical and revenue cycle transactions of the practice. Clinical documentation still came from clinicians; the Brain did not draft clinical notes and did not make clinical determinations. Denial determinations still came from payers, and appeal decisions still came from payer review committees. The Brain provided structured access to the practice's own internal knowledge — it did not make clinical decisions, payer decisions, or coding determinations. Credentialing applications were still signed by humans.

The composite lesson

In healthcare, partition design matters as much as content. The same payer knowledge feeds credentialing, denials, and prior authorization — but the legal sensitivities, the PHI exposure profile, and the operational scopes differ across those teams. A well-partitioned Company Brain lets the same source material serve multiple teams without violating internal access boundaries or HIPAA expectations. The broader pattern: in any regulated environment where knowledge is shared across functions but access cannot be, the partition structure of the Brain is what makes the deployment legally and operationally durable. Content without partitions is a compliance problem waiting to happen; partitions without content are an empty shell. Both have to be designed together.

Want this for your company?

Request a conversation and we'll show you which roles in your company are ready for a digital employee.