Patient Portal Development for Multi-Location Clinics: Problems and Solutions

Why the patient portal makes or breaks a multi-location clinic

Walk the front desk of an eight-location orthopedic group at 8:05 on a Monday morning. Three schedulers are working the hold queue, the Updox fax inbox holds 30 inbound referrals, and a medical records clerk is printing a 40-page chart to fax to a referring primary care office, for the second time, because the first fax never arrived. The group technically has a patient portal. It has three, actually: healow tied to the eClinicalWorks instance the group has run since 2016, athenaPatient inherited with the two clinics acquired last year that still sit on athenahealth, and the Quest portal patients get pointed to for lab results. Patients cannot remember which login does what, so they do the rational thing. They call.

That call volume is the hidden invoice. Put four schedulers at $21 an hour on phones across eight locations and you are spending over $170,000 a year answering questions a working portal would absorb: when is my appointment, what do I owe, did my results come back, can you resend the referral. None of that work generates revenue. All of it generates hold music, and the patients who give up on hold become the no-shows and the one-star reviews.

Executives at this scale usually frame the decision as healow versus MyChart versus adding Klara on top. The real decision is different: keep stitching together vendor slices that each own a fifth of the patient relationship, or build the single layer that sits on top of all of them. This guide walks through the five problems that layer has to solve, what it costs, and when building it is the wrong move.

Problem: patients juggle three logins, so they pick up the phone

A patient of the acquired clinics has an athenaPatient login for her chart, gets Phreesia texts for intake, checks Quest for labs, and once replied to a Klara thread she can no longer find. When her password reset email lands in spam, she stops trying. Multiply her by your whole panel and the portal adoption number your EHR vendor reports becomes fiction: accounts exist, usage does not.

The incumbents cannot fix this because each one only shows its own slice. healow displays what lives in that eClinicalWorks database and nothing else. If your group runs two EHR instances, or an EHR plus a separate imaging or lab system, no configuration setting merges them. The vendors are structurally unable to build the cross-vendor view, because the cross-vendor view makes them replaceable.

A custom portal starts with one identity. A single account, verified against your patient list, connects to every backend through the FHIR R4 APIs that ONC-certified EHRs are now required to expose: Patient and Appointment for demographics and visits, DocumentReference for records, Observation for results. The patient sees one timeline across every location and every system you have ever acquired. Your staff stops explaining which website does what, and password resets stop being a front-desk job.

Problem: the phone line is still the scheduling system

Most groups this size have tried self-scheduling and turned it off. The built-in healow booking let new patients grab slots reserved for post-op follow-ups, or double-booked the injection room, so the clinical director killed it after two weeks and the schedulers took the load back. Off-the-shelf booking engines offer a handful of visit types and duration settings. They cannot encode the real rules: Dr. Mehta sees new knees only Tuesday and Thursday at the Riverside location, ultrasound-guided injections need a 15-minute room block plus a tech, workers comp visits require an authorization on file before booking.

A custom build treats scheduling as a rules engine, not a form. A short decision tree asks what the patient needs, checks payer and referral status against what is already in the chart, and only then shows slots that are actually bookable, writing the appointment back through FHIR or an HL7 SIU interface so the EHR schedule stays the source of truth. Add a waitlist that automatically offers cancelled slots by text and you recover appointments that today evaporate. Groups we have built this for watch Monday morning call volume fall by roughly a third within a quarter, which is a scheduler position redeployed to prior authorizations.

Problem: referrals and records still move by fax

The records release workflow at most clinics is a 1998 process wearing a 2026 badge: print from the EHR, count pages, fax through Updox or a physical machine, log it in a spreadsheet, field the call when the receiving office says nothing arrived. Referrals inbound are worse, arriving as unstructured fax pages someone re-keys into the EHR. Patients wait days for something that is legally theirs on demand.

Portal vendors bolt on document viewing but not document exchange, because exchange crosses organizational boundaries their product does not own. A custom portal makes release a self-service flow: the patient or the referring office requests records, signs the release electronically, and the system assembles the chart from DocumentReference resources and delivers it as a secure download or Direct message, with an audit log of who requested and received what. Inbound referrals land in a structured queue with the demographics and insurance already parsed, so intake starts the day the referral arrives, not the day someone works the fax pile. For a specialty group, referral turnaround time is revenue: every day a referral sits in a fax queue is a day the patient can end up at the competitor across town.

Problem: portal messages land in an inbox nobody owns

A patient sends a medication question through healow at 4 pm Friday. It sits in a shared inbox until Tuesday because no one is assigned to it, then a medical assistant answers in Klara, which does not write to the chart, so she re-types a summary into eClinicalWorks. Two systems, one conversation, zero accountability, and a clinical question that aged four days.

Off-the-shelf messaging is a single undifferentiated inbox per practice. A custom build routes by intent: refill requests go to the refill queue with the med list attached, billing questions to the billing team, clinical questions to the right care team by provider and location, each queue with a response-time timer and escalation when the timer runs out. Every thread writes back to the chart as a note through the EHR API, so the conversation and the record never diverge. Practice managers get a dashboard of message volume and response times per location, which is how you find out that one clinic answers in four hours and another in four days before a patient complaint tells you.

Problem: patients cannot see or pay a balance, so AR ages

After the acquisitions, your patients can receive statements from two different billing systems, mailed 30 to 45 days after the visit, formatted differently, sometimes for the same episode of care. The patient does not know what she owes in total, so she pays nothing and calls billing, and your AR over 90 days grows every quarter.

A custom portal consolidates the balance across every practice management system into one number with a plain-language breakdown, then makes paying it a two-tap action: card on file, payment plans with automatic installments, and text-to-pay links in reminder messages, with payments posting back to the correct billing system automatically. Real-time eligibility checks through a 270/271 clearinghouse connection let you show cost estimates before the visit, which is when patients actually decide whether to keep the appointment. Collecting at the moment of engagement instead of 45 days later is usually the line item that pays for the entire build.

What patient portal development costs and how long it takes

Across 2,000+ delivered projects, Digital Heroes sees this category land in two bands. A focused first release, one login, self-scheduling with a real rules engine, routed messaging, wired to a single EHR, typically runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform, multiple EHR and billing integrations, records exchange, consolidated payments, native iOS and Android apps, runs $150,000 to $400,000 phased over 6 to 12 months, with the phasing deliberate: scheduling and messaging first because they cut the most calls, records and payments next.

What pushes this category toward the top of the band: each additional EHR or practice management integration, since every acquisition adds one and each vendor has its own interface fees and sandbox approval timeline; patient identity matching when one human has two medical record numbers across systems; scheduling rule complexity, which is the most underestimated line in every scope we review; native mobile apps instead of responsive web; and the compliance artifacts hospital partners increasingly demand, like SOC 2 reports and annual penetration tests. The single most common schedule risk is EHR vendor paperwork, so API access requests should go out the week the contract is signed, not week six.

Build vs buy: when healow or MyChart is genuinely enough

If you run one EHR instance across one or two locations and your patients mostly need visit summaries and refill requests, do not build. healow, athenaPatient and MyChart are included in what you already pay, and configuring them well plus adding a reminder tool like Luma Health will cover you for years. Building at that scale is buying a custom suit for a body that is still growing.

The signals flip when the workarounds become payroll. Build when two or more of these are true: you operate multiple EHR or billing systems and consolidation onto one is not happening within two years; scheduling calls justify dedicated headcount at every location; the top three reasons patients call are things your current portal theoretically does but practically cannot; inbound referrals arrive by fax in volume; or you plan further acquisitions, because every acquisition makes the vendor-portal path worse and the unified-layer path more valuable. Our position after building these repeatedly: multi-location groups on mixed systems should build the patient-facing layer and never build the EHR. The chart stays in eClinicalWorks or athenahealth. The experience becomes yours.

How to choose a developer for patient portal development

Vet on four things, in this order. First, integration depth with your specific EHR: ask which FHIR resources and HL7 interfaces they have written to, not just read from, because displaying data is easy and booking an appointment that survives the EHR's rules is the actual job. Ask for a reference client on your exact system. Second, patient identity: ask how they handle one patient with different medical record numbers in two systems. If the answer is not a concrete matching strategy with a human review queue for uncertain matches, they have not done multi-system work. Third, compliance engineering: they must sign a business associate agreement, host on infrastructure covered by one, and show you audit logging, role-based access and their most recent third-party penetration test rather than a paragraph about taking security seriously. Fourth, ownership: full source code in your repositories, infrastructure in your cloud accounts, no per-patient or per-provider fees, and a documented handover path. A developer who hesitates on any of the four is quoting you a dependency, not a platform.