Patient Portal Development: Custom Build or Off the Shelf

What the off-the-shelf products actually do well

The portal you already own is included in what you already pay, and that single fact decides most of these conversations. Nobody writes a business case against zero marginal cost and wins it easily.

healow, MyChart, athenaPatient, FollowMyHealth and the NextGen portal all deliver, without a project:

• A patient record view fed directly from the chart, with no interface to build, no sandbox approval to chase and no field mapping to maintain.
• Compliance carried by the record vendor, including the standardised application interface criterion that certified systems must expose, and the privacy posture that comes with it.
• Refill requests, visit summaries, statements and results release that satisfy the information blocking expectations under the Cures Act rule without you designing anything.
• Identity, password reset and account recovery, which is unglamorous work and a real running cost when you own it.
• Mobile apps maintained through operating system releases you do not have to track.

If you run one record instance across one or two locations, configure what you have, add a reminder tool such as Luma Health, and stop. Building there is a tailored suit for a body still growing. We turn that work down, and it is the cheapest advice on this page.

Where they stop: three logins and a patient who calls instead

The workflow no portal vendor will fix is the one created by acquisitions.

A patient of the two clinics you bought last year has an athenaPatient login for her chart. She gets intake texts from a separate vendor, checks a laboratory portal for results, and once replied to a messaging thread she can no longer find. When the password reset lands in spam she stops trying, and she does the rational thing. She calls.

Multiply her by the panel and the adoption figure your record vendor reports becomes fiction. Accounts exist. Usage does not.

No incumbent can close this, and the reason is commercial rather than technical. healow shows what lives in that eClinicalWorks database and nothing else. The cross vendor view is the thing that would make each vendor replaceable, so none of them will build it. What makes it possible for you is that certified record systems now expose FHIR R4 interfaces covering the United States Core Data for Interoperability classes, so one account verified against your patient list can read Patient, Appointment, DocumentReference and Observation across every system you have acquired and present one timeline.

Two more places the packaged portals stop. Scheduling, because most groups this size tried self service booking and switched it off after a fortnight when new patients grabbed slots reserved for post-operative follow ups. Built in booking offers visit types and durations. It cannot encode that a surgeon sees new knees only on Tuesdays and Thursdays at one site, that an ultrasound guided injection needs a room block plus a technician, or that a workers compensation visit requires an authorisation on file before it can be booked. A rules engine that checks payer and referral status first, then shows only genuinely bookable slots and writes back through an HL7 SIU message, is a different thing from a booking form.

And records exchange, which at most clinics is a 1998 process wearing a modern badge: print from the chart, count pages, fax, log it in a spreadsheet, take the call when the receiving office says nothing arrived. Portals display documents. They do not exchange them across organisational boundaries, because that boundary is not theirs to own.

The arithmetic: schedulers and record instances, not licences

You cannot run this comparison on subscription cost, because the portal costs you nothing extra today. So price the workaround instead.

Count the positions absorbing portal work. Four schedulers at twenty-one dollars an hour across eight locations is over $170,000 a year answering when is my appointment, what do I owe, did my results come back, and can you resend the referral. None of it generates revenue, and the patients who abandon the hold queue become your no shows.

A first release at $95,000 with 18 percent annual upkeep is about $129,000 across three years, near $43,000 a year averaged. If a working portal absorbs a third of that call volume, which is the shift groups typically see within a quarter of self scheduling going live, the recovered capacity is roughly $57,000 a year. That clears the build.

So the crossover is about three full time scheduling positions, or two record system instances, whichever arrives first. Instance count matters more than headcount, because two systems is the condition no vendor will ever fix and three schedulers is a condition better configuration sometimes will.

Add one line most business cases omit. Accounts receivable over ninety days grows when a patient receives statements from two billing systems in different formats for the same episode and pays neither. Consolidating that into one balance she can settle in two taps is usually the item that pays for the whole build, and it is measurable before you start.

What a custom build actually costs

Digital Heroes sees this category land in two bands across more than 2,000 delivered projects. A focused first release, meaning one login, self scheduling with a real rules engine and routed messaging wired to a single record system, runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform with multiple record and billing integrations, records exchange, consolidated payments and native applications runs $150,000 to $400,000 phased over 6 to 12 months. Phase scheduling and messaging first, because they remove the most calls.

Two costs that rarely appear in a proposal:

• Data migration is 10 to 25 percent of the build, and here it is mostly identity. One human with two medical record numbers across two systems is the central problem, and it needs a concrete matching strategy plus a human review queue for uncertain matches. Get that wrong and a patient sees somebody else's results, which is the worst outcome available in this category.
• Year two is 15 to 20 percent of build cost annually. Each acquisition adds an interface with its own fees and sandbox timeline, record vendors version their interfaces, and hospital partners increasingly ask for a current SOC 2 report and an annual penetration test.

The most common schedule risk is paperwork rather than code. Interface access requests should go out the week the contract is signed, not in week six, and any firm that does not raise this unprompted has not shipped in healthcare.

The four situations where building wins

• Regulatory fit. The information blocking provisions of the Cures Act rule mean patients are entitled to their records without friction, and a fax queue is friction you can be asked about. A portal you own can log who requested what, deliver through a secure download or Direct message, and produce that audit trail on demand, which a fax log in a spreadsheet cannot.
• Scale economics. Every acquisition makes the vendor portal path worse and the unified layer better, because each new practice arrives with its own login and its own patient confusion. If more purchases are planned, the build gets cheaper per site each time.
• A workflow that is your competitive advantage. For a specialty group that is referral turnaround. Inbound referrals landing in a structured queue with demographics and coverage already parsed means intake starts the day the referral arrives rather than the day someone works the fax pile, and every day a referral waits is a day the patient can end up across town.
• Integration sprawl across three or more systems. Two record systems, two billing systems, a laboratory portal and a messaging tool each owning a fifth of the patient relationship is the condition where the front desk becomes the integration layer. Keep the chart where it is and own only the layer patients touch.

How to decide in a week

Code one week of inbound calls. Have every scheduler tag each call with one of six reasons: appointment booking or change, balance or statement, results, records or referral request, refill, and everything else. No new tooling, one shared sheet, five days.

Then sort. If more than half of calls fall into reasons your current portal theoretically handles, your problem is adoption and the fix might be configuration, better reminder wording and a password reset flow that works, all of which cost nothing. If most calls are things no single portal can answer because the information lives in two systems, no configuration reaches it and you are looking at a build.

While that runs, pull your accounts receivable over ninety days and split it by billing system. A patient receiving two statements for one episode is a number, and it belongs in the same case.

Turn the findings into a written specification before anyone quotes. A paid discovery phase with Digital Heroes ends in a signed product requirements document covering identity matching, the scheduling rule set, the interfaces per record system and acceptance criteria. That document is yours regardless of who builds, and it is what makes four proposals comparable instead of four different projects.

We are the wrong firm for single instance practices, for groups without an internal owner, and for anyone who wants developers to start without a specification. We also have no local office anywhere, so if physical presence matters, choose otherwise. Where we fit is multi site groups on mixed systems who want to own the patient facing layer and never the chart. Over fifty specialists, more than 2,000 projects, in house products including ShopScore, HeroCheckout and Section Vault, and a named team you meet before signing. India LLP, US LLC and UK LTD entities so intellectual property assigns under your own law. Verifiable on Clutch, Trustpilot, Fiverr Vetted Pro and D-U-N-S.

Book a 30-minute call with Digital Heroes and get a written plan and a fixed quote within 48 hours.