Why Does Your Multi-Specialty Practice Need 3 EHR Systems to Do One Job?

A practice administrator at a 12-specialty group described their situation to us in five words: “We’re running three different systems.”

Cardiology on one EHR. Behavioral health on another (because 42 CFR Part 2 compliance forced it). Primary care on a third. The patient record lives in all three. The billing team reconciles across all three. Nobody has a complete view of anyone.

KLAS Research (2025) measured a 30-point satisfaction gap between the most satisfied specialty (hospital medicine) and the least (ophthalmology) on the same EHR platform. That gap isn’t about software quality. It’s about fit. An EHR built for hospital medicine workflows doesn’t model visual field charts, IOP tracking, or imaging comparisons. And the ophthalmology workarounds create friction for every other department sharing the same system.

This is the piece for CIOs and practice administrators who’ve hit this wall.

I. What Makes Multi-Specialty EHR So Much Harder?

It’s not one problem. It’s five problems that compound each other.

• Specialty-specific documentation templates. Cardiology needs stress test interpretation fields. Dermatology needs lesion mapping with body diagrams. Behavioral health needs PHQ-9 scores and treatment plans with 42 CFR Part 2 segmentation. An EHR built for one specialty forces others to click through irrelevant fields. Sutter Health found its nurses were making 400,000 unnecessary EHR clicks per day before workflow optimization.
• Shared patient records across departments. A patient seeing both cardiology and endocrinology needs one unified record, not two parallel charts. But the documentation needs of each specialty are different. The EHR must present the same patient data through different lenses depending on which clinician is looking.
• Unified billing with specialty-specific codes. Cardiology bills CPT 93000-93352 for diagnostic procedures. Behavioral health bills E/M codes with add-on psychotherapy codes. Oncology bills infusion administration with complex drug coding. A single billing engine needs to handle all of these without manual routing and without errors.
• Internal referral workflows. When the PCP refers to in-house cardiology, the referral shouldn’t leave the system. The cardiologist should see the PCP’s notes, relevant labs, and the reason for referral without a fax or a phone call. Most EHRs handle external referrals. Few handle internal cross-specialty handoffs cleanly.
• Specialty-specific device and imaging integration. Cardiology needs ECG device integration. Pulmonology needs spirometry data feeds. Radiology needs PACS connectivity. Each specialty brings its own device ecosystem, and each device speaks a different protocol.

The compound effect: When 3+ specialties each have 2-3 workarounds, the practice is running on 15-20 workarounds that nobody designed but everyone depends on. That’s not an EHR. That’s technical debt masquerading as a workflow.

II. What Are the EHR Options for Multi-Specialty Practices?

Four approaches, each with a different cost-complexity tradeoff.

The trap most practices fall into: They start with Option 1 (enterprise off-the-shelf), realize it doesn’t fit 2-3 specialties, add workarounds, bolt on third-party tools for the gaps, and end up spending more than Option 3 or 4 would have cost – with worse results.

I read through the KLAS Arch Collaborative satisfaction data last month. The pattern is consistent: practices report highest satisfaction when the EHR was designed for (or heavily customized to) their specialty. Generic platforms configured at the department level consistently underperform. Epic dominates multi-specialty at 35%+ market share, but that dominance is driven by budget and ecosystem effects, not by specialty-specific satisfaction.

III. When Does a Multi-Specialty Practice Need Custom EHR?

Not every multi-specialty practice needs a custom build. Here’s the decision framework:

Custom likely makes sense if:

1. You have 5+ specialties with distinct documentation requirements, and your current EHR forces workarounds in 2+ departments
2. Your existing EHR vendor charges $50-$500/hour for professional services to customize templates – and you’re paying that bill quarterly
3. You need specialty-specific clinical decision support at the point of care (not just documentation templates – actual CDS rules that differ by specialty)
4. Device integration is specialty-specific and your EHR doesn’t support your cardiology ECG system or your pulmonology spirometer natively
5. Revenue is leaking from billing complexity across specialties – coding errors, manual routing, missed charges from department-specific fee schedules

Custom probably doesn’t make sense if:

• You have 2-3 specialties with similar workflows (e.g., internal medicine + family medicine + pediatrics)
• Your patient volume is under 50 patients/day across all specialties
• Off-the-shelf templates cover 90%+ of your documentation needs
• Budget is under $100K, and timeline is under 3 months

The real trigger, from conversations with dozens of practice groups: “The 10% of workflow that our EHR doesn’t cover is our specialty’s core workflow.” That’s the line between configuration and custom. For a deeper build vs buy analysis, we covered the full decision framework.

IV. What’s the Architecture Pattern That Actually Works?

This is the part no competitor article covers. Everyone lists features. Nobody explains the architecture.

The pattern: shared FHIR-native backend + specialty-specific frontend modules.

Here’s what that means:

A. The Shared Backend (One For All Departments)

• FHIR R4 data layer storing all patient data in standard resources (Patient, Encounter, Observation, Condition, MedicationRequest, etc.)
• Unified patient identity – one patient, one record, regardless of which department creates data
• Shared auth and access controls – role-based, department-aware (behavioral health clinicians see behavioral health notes; cardiologists see cardiology notes; PCPs see everything)
• Unified billing engine – CPT/ICD mapping by department with specialty-specific fee schedule support
• Single API layer – every department writes to and reads from the same FHIR API

A headless EHR platform like Medplum provides most of this out of the box. If you need more control, you can build it custom on a FHIR server. Either way, the backend is one system.

B. The Specialty Frontends (One Per Department)

Each specialty gets its own UI module tailored to its workflow:

• Cardiology module: Stress test interpretation, ECG viewer, cardiac catheterization reports, device integration
• Dermatology module: Lesion mapping with body diagrams, image capture and comparison, biopsy tracking
• Behavioral health module: PHQ-9/GAD-7 assessments, treatment plans, session notes, 42 CFR Part 2 segmentation
• Orthopedics module: Imaging viewer, surgical planning, post-op protocol tracking, rehab milestone monitoring
• Primary care module: Standard E/M documentation, preventive care reminders, chronic condition management

Each module reads from and writes to the same FHIR backend. The patient record is unified. The clinical experience is specialty-specific.

Why this works: Adding a new specialty doesn’t require rebuilding the system. You add a frontend module and map it to existing FHIR resources. The backend scales without per-specialty modifications. It’s the difference between building one flexible system and maintaining five rigid ones.

V. What Does This Look Like in Practice?

Three different multi-service builds, each solving a different version of the multi-specialty problem.

A. National Health Records System – Multi-Service at Country Scale

A government health ministry needed a single clinical platform for their entire public healthcare infrastructure – primary care, maternal health, lab services, pharmacy, and specialty referrals all in one system.

• FHIR-native architecture from day one
• $131K for a country-scale clinical platform
• Patient management, clinical documentation, lab integration, pharmacy workflows, ONC-aligned data models
• The multi-service design meant each department had appropriate workflows while sharing one patient record

B. Behavioral Health Network – 7 Systems Consolidated to 1

A behavioral health network had accumulated 7 separate clinical data sources – each department had adopted its own tool over the years. Patient data was fragmented. No unified view existed.

• 4-week discovery to assess the landscape and determine viability
• Built a modern data aggregation layer consolidating 7 sources into 15 clinical cards in a unified patient dashboard
• 99% uptime in the first 30 days post-launch
• The consolidation pattern: don’t necessarily replace every system. Aggregate into a unified view layer that each department can access.

C. Obstetric Specialty Module – Custom Clinical Tool Inside Epic

For organizations already on Epic that need deeper specialty capability, we’ve built custom clinical modules that integrate via SMART on FHIR:

• Custom obstetric prediction module integrated with Epic
• Specialty-specific clinical decision support that Epic’s native templates don’t offer
• 15% delivery rate improvement, 76% fewer coding denials
• Proof that custom specialty modules can work inside enterprise EHR, not just as replacements

The OB/GYN EHR market alone is $2.17 billion in 2025, projected to reach $5.33 billion by 2035 at 9.4% CAGR. That’s one specialty. Multiply across 5-10 specialties in a multi-specialty practice, and you see why this is the fastest-growing segment of custom EHR development.