Most clinics and dental practices do not need a portal built from scratch. They need a thin, well-designed layer over the EHR or practice management system they already pay for. Get that decision right and patient portal app development becomes a four-to-nine-month project with a known budget, not an open-ended rebuild of your clinical system.
This guide covers what we tell practice owners before the first scoping call. It explains the features that matter, the rules that shape the build, the integrations, realistic costs and the mistakes we see most often.
First decide: extend your EHR's portal or build your own
Most EHRs ship a portal. Epic has MyChart, athenahealth has its own patient portal, and many dental systems bundle or partner with scheduling and forms tools. If those cover 80% of what your patients need, configure them and stop there.
A custom portal earns its cost in a few specific cases:
- You run several locations on different systems and want one patient login.
- Your bundled portal works poorly on phones, so patients call the front desk instead.
- You offer services the EHR portal cannot model, such as memberships, treatment financing or remote monitoring.
- You want your own brand in the app stores, not your vendor's.
If none of these apply, a custom build is usually money better spent elsewhere. Saying so early is cheaper for everyone.
If you are unsure which side of that line you are on, it helps to talk to an engineer who has built in your industry before you commit to a scope.
The five features a patient portal must have
1. Online scheduling with reminders
Scheduling is the feature patients use most, and it cuts front-desk calls. It must read live availability from your practice management system, not a copy that drifts out of sync. Pair it with SMS and email reminders about 48 hours and 2 hours before the visit, with one-tap confirm or reschedule.
2. Secure messaging
Patients will message you whether or not you give them a safe channel. A portal inbox keeps health data out of personal email and text threads. Build the staff side with care: routing by provider or role, a response target such as one business day, and an auto-reply that says not to use it for emergencies.
3. Digital intake, forms and consent
Pre-visit forms that write straight into the chart typically save 5 to 10 minutes per new patient at check-in. Include medical history, insurance card photo capture, and signed consents stored with a timestamp and form version. For dental, add treatment-plan review and e-signature, which is often where practices see the clearest return.
4. Access to records, results and documents
Patients have a legal right to their health information. At minimum, show visit summaries, lab results, imaging reports and downloadable documents. Agree with your clinicians how results are released, because blanket delays can count as information blocking unless a defined exception applies.
5. Billing and payments
Statements, balance due, saved cards and payment plans close the loop. For dental, show the insurance estimate next to the patient portion so the number is not a surprise. Many payment processors will not sign a business associate agreement, so send them amounts and invoice IDs, never diagnosis or procedure detail.
The regulations that shape the build
HIPAA Privacy, Security and Breach Notification Rules
Any portal that stores or sends protected health information (PHI) for a clinic falls under HIPAA. The HIPAA Security Rule drives most engineering choices: access controls, audit logs, encryption, integrity checks and automatic logoff. The Breach Notification Rule means your logs must show exactly whose data was exposed if something goes wrong.
Our baseline for a portal looks like this:
- TLS 1.2 or higher in transit, and AES-256 encryption at rest.
- Multi-factor authentication for staff, and as an option for patients.
- Tamper-evident audit logs of every read and write of PHI, commonly kept for six years.
- Staff session timeouts of around 15 minutes.
- No PHI in push notifications, URLs, analytics events or crash reports.
In January 2025, HHS proposed Security Rule changes that would make encryption and MFA firm requirements rather than “addressable”. The rule is not final, but we build to that standard now. Retrofitting it later costs more.
Business associate agreements
Every vendor that touches PHI needs a signed BAA. That includes hosting, your agency, SMS and email services, and your error tracker. AWS, Google Cloud and Azure all sign BAAs, but only specific services are covered, and a non-covered logging tool can quietly collect patient data.
21st Century Cures Act
The Cures Act rules treat unreasonable delays in giving patients electronic access to their records as information blocking. If your portal sits in front of an EHR, it must not become the bottleneck. Pull new results on a short schedule, such as every 15 minutes, or use event feeds where the EHR offers them.
Accessibility
HHS updated its Section 504 rule in 2024. Providers that receive federal financial assistance, such as Medicaid, must make web content and mobile apps meet WCAG 2.1 Level AA. The deadline is May 2026 for organizations with 15 or more employees and May 2027 for smaller ones.
Texting and state privacy laws
SMS reminders fall under the TCPA, so record consent and honor STOP replies. Some states go further than HIPAA, including California's CMIA and Washington's My Health My Data Act. Check where your patients live, not just where your clinics are.
The integrations you will almost certainly need
A portal is mostly integration work. Expect to connect your EHR or practice management system, a payment processor, and SMS and email services that sign a BAA. Many practices also want insurance eligibility checks through a clearinghouse, using X12 270/271 transactions.
The EHR connection is the hard part. There are four common routes.
FHIR APIs
Most certified medical EHRs now expose HL7 FHIR R4 APIs, often with SMART on FHIR for login. They are the cleanest way to read records, but write access for bookings and forms varies widely by vendor. App registration and review can take a few weeks or several months.
HL7 v2 interfaces
These are older but still common for scheduling and results feeds. They are reliable once running. Each interface often carries a vendor setup fee and needs an interface engine to translate messages.
Integration platforms
Services such as Redox put many EHRs behind one API. They shorten the build when you connect several systems. The trade-off is a recurring subscription that grows with volume.
Dental practice management APIs
Dental is less standardized. Open Dental publishes an API, while Dentrix and Eaglesoft work through vendor partner programs. Many dental systems still run on a server in the office, so you may need a small connector service installed on-site.
Timeline and cost for patient portal app development
These are typical ranges for US-based full-stack builds. Your numbers move with the number of integrations far more than the number of screens.
Focused web portal on one system
Scheduling, forms, messaging and payments in a responsive web app, connected to one EHR or practice system. Typically $60,000 to $120,000 and four to six months.
Web plus iOS and Android apps
The same core, plus mobile apps with biometric login and push notifications. Typically $120,000 to $250,000 and six to nine months.
Multi-location, multi-system portal
Several EHRs or practice systems behind one login, with custom reporting. Usually $250,000 and up, and nine months or more.
Plan for running costs too. HIPAA-eligible hosting, monitoring and messaging typically run $500 to $3,000 a month for a single practice group. Maintenance usually adds 15% to 20% of the build cost each year, plus any EHR vendor fees, which you should get in writing first.
Three mistakes first-time buyers make
Rebuilding what the EHR already does
Some practices pay to rebuild charting views or clinical workflows that belong in the EHR. Keep the clinical record in the clinical system. The portal should read from it and write back only what patients create, such as forms, messages and bookings.
Treating EHR access as a formality
Buyers often assume API access is free and instant. In reality, vendor approval, sandbox access and per-practice activation can add weeks or months, and some fees are charged per location. Start the vendor paperwork in week one, before design is finished.
Designing only for patients
A portal creates work for staff: messages to answer, forms to review, payments to reconcile. If the staff side is an afterthought, messages go unanswered and patients drift back to the phone. We spend about a third of design time on front desk and clinical team screens.
Two questions to ask any agency
“Which EHR or practice systems have you integrated with, and what went wrong?”
You want named systems and specific problems, such as rate limits, missing write endpoints or slow vendor approval. A vague answer about “healthcare experience” usually means they have not done the integration you need.
“Will you sign a BAA, and how do you keep PHI out of your own tools?”
A serious agency signs a BAA without hesitation. Ask whether developers ever see real patient data. Then ask how logs, error tracking and staging environments are kept clean.
FAQ
Does a patient portal have to be HIPAA compliant?
Yes, if it stores, receives or sends PHI on behalf of a clinic or dental practice. That means Security Rule safeguards in the software. It also means signed BAAs with every vendor that handles the data.
How much does it cost to build a patient portal?
A focused web portal on one EHR typically costs $60,000 to $120,000. Adding iOS and Android apps usually brings it to $120,000 to $250,000. Integrations, not screens, drive most of the difference.
Can a custom patient portal connect to Dentrix, Open Dental or Epic?
Usually, yes. Open Dental has a published API, Dentrix works through Henry Schein One's partner program, and Epic offers FHIR APIs to registered developers. Each has its own approval process, fees and limits on what you can write back.
