Patient portal development is the process of building a secure web application where patients can book appointments, view records and test results, message their care team, pay bills, and complete intake forms online. A good portal connects to your EHR through standards like HL7 and FHIR, builds HIPAA technical safeguards in from day one, and is simple enough for patients of any age to use. Most projects typically take several months, depending on scope and integrations.
This guide covers what to include, how security and integrations work, which technologies fit, and what a realistic build looks like. It is written for practice owners, product managers, and health tech founders, not only developers.
What is a patient portal and who is it for?
A patient portal is a secure, logged-in space where patients interact with a clinic, hospital, lab, or health plan. It is also a staff tool. Front desk teams, nurses, billing staff, and providers use the same system from the other side to answer messages, confirm appointments, and review submitted forms.
Some organizations use the portal that comes with their EHR. Others build a custom portal when the default one is hard to use, does not match their workflows, or needs to combine data from several systems.
What features should a patient portal have?
Start with the features patients use most, then add extras once the core works well.
Appointment scheduling
Patients should be able to see open slots, book, reschedule, and cancel, with reminders by email or text. Scheduling must sync with the EHR or practice management system to avoid double booking.
Health records access
Patients expect to view visit summaries, medications, allergies, immunizations, and care plans, and to download or share them. In the US, federal information blocking rules make timely electronic access to this data an expectation, not a bonus.
Secure messaging
Messaging lets patients ask non-urgent questions without phone calls. It needs routing to the right staff member, clear response time expectations, and a visible notice that it is not for emergencies.
Test results
Lab and imaging results should appear with plain-language context where possible. Many practices also let providers add a short note to a result so patients understand what it means.
Billing and payments
Patients should see statements, balances, and payment history, and pay online. Use a payment processor that handles card data so your portal does not store it directly.
Digital intake forms
Online intake, consent, and insurance forms cut paperwork and waiting room time. Submitted data should flow into the EHR rather than being retyped by staff.
Useful extras
- Telehealth visit links
- Proxy access for parents, guardians, and caregivers
- Prescription refill requests
- Multilingual interface
- Patient education content tied to conditions or procedures
What makes a healthcare portal HIPAA compliant?
HIPAA compliant web development is about more than hosting. The HIPAA Security Rule lists technical safeguards for systems that handle electronic protected health information (ePHI). This section explains how those safeguards usually show up in a portal. It is not legal advice. Always confirm your compliance approach with qualified healthcare counsel and your compliance officer, especially since HHS has proposed updates to the Security Rule.
Access control and authentication
- Unique user accounts for every patient and staff member
- Multi-factor authentication, at least for staff and admin users
- Role-based permissions so each person only sees what their job requires
- Secure account recovery and clear proxy access rules
Audit logs
The system should record who viewed, created, changed, or deleted records, and when. Logs should be protected from tampering, retained according to your policy, and reviewed regularly.
Encryption in transit and at rest
All traffic should use current TLS. Databases, file storage, and backups should be encrypted at rest, with encryption keys managed through a proper key management service.
Automatic logoff
Sessions should end after a period of inactivity, with a warning first. This protects patients on shared computers and staff at busy workstations.
Business associate agreements (BAAs)
Any vendor that stores, processes, or transmits ePHI for you, such as a cloud host, email or SMS provider, or analytics tool, generally needs to sign a BAA. Major cloud providers like AWS, Microsoft Azure, and Google Cloud offer BAAs for eligible services, but you still have to configure those services correctly. Avoid adding tracking scripts or third-party tools to logged-in pages without reviewing them first.
How does a patient portal integrate with an EHR?
Integration is often the hardest part of EHR portal work, so plan for it early.
- HL7 v2 is an older messaging standard still widely used for things like admissions, orders, and lab results.
- FHIR (Fast Healthcare Interoperability Resources) is a modern, API-based standard. Many certified EHRs in the US now provide FHIR APIs, partly because of federal interoperability rules.
- SMART on FHIR adds a standard way for apps to authorize and launch against an EHR using OAuth 2.0, so patients or clinicians can sign in and share data securely.
Major EHR vendors such as Epic, Oracle Health, and athenahealth run developer programs with documentation and sandbox environments. Access rules, approval steps, and fees vary by vendor, so confirm them before you commit to a timeline. When a direct API is not available, an integration engine or interface partner can bridge the gap.
What tech stack works well for healthcare portal development?
There is no single correct stack. The table shows common options and what to check for each layer.
| Layer | Common options | What to check |
|---|---|---|
| Front end | Angular, React | Accessibility, form handling, long-term maintainability |
| Back end | Node.js, .NET, Java, Laravel (PHP) | Auth, audit logging, FHIR libraries, team skills |
| Database | PostgreSQL, SQL Server, MySQL | Encryption at rest, backups, access controls |
| Hosting | AWS, Azure, Google Cloud | BAA coverage, HIPAA-eligible services, monitoring |
| Identity | Managed identity provider or custom auth | MFA, SSO for staff, BAA if it handles ePHI |
We often recommend Angular for the front end of portals because they are form-heavy, role-based, and maintained for years. Angular’s built-in forms, strong TypeScript typing, and consistent structure suit that kind of work. React is also a solid choice, especially if your team already uses it.
How do you design a portal that patients and staff will actually use?
For patients
- Design mobile-first, since many patients will open the portal on a phone.
- Use plain language instead of medical or billing jargon.
- Follow WCAG accessibility guidelines for contrast, text size, keyboard use, and screen readers.
- Keep sign-up and login simple while still secure.
- Make the top three tasks (book, message, pay) reachable in one or two taps.
For staff
- Build clear work queues for messages, forms, and requests.
- Show patient context on one screen to reduce clicking between systems.
- Match existing clinic workflows before trying to change them.
- Involve front desk and clinical staff in testing, not just managers.
What does the patient portal development process look like?
- Discovery and compliance planning: define users, features, integrations, and security requirements, and bring in your compliance team early.
- UX and prototyping: map patient and staff journeys, then test clickable prototypes with real users.
- Architecture: choose the stack, hosting, identity approach, and integration method, and confirm BAAs.
- Build in sprints: deliver working features in short cycles with regular demos.
- Integration testing: test against EHR sandbox environments, then with real workflows.
- Security testing: run code reviews, vulnerability scans, and an independent penetration test before launch.
- Pilot launch: start with one location or patient group, gather feedback, and fix issues.
- Support and maintenance: apply security patches, monitor logs, and keep integrations current as EHR vendors change their APIs.
A focused first version with one EHR integration typically takes several months. Larger builds with multiple locations, integrations, or a mobile app can take a year or more. The timeline depends on scope, vendor approvals, and how quickly decisions get made.
Frequently asked questions
Should we build a custom portal or use our EHR’s portal?
If your EHR’s portal meets your needs and patients use it, keep it. Build custom when you need better usability, workflows the default portal cannot support, or one experience across several systems.
Does using a HIPAA-eligible cloud host make our portal compliant?
No. A compliant host is only one part. Your application’s access controls, logging, encryption, vendor agreements, and policies all matter. Confirm your approach with healthcare counsel.
What is the difference between HL7 and FHIR?
HL7 v2 is an older message-based standard used for exchanging events like lab results. FHIR is a newer, web API-based standard that is easier for modern apps to work with. Many portals use both.
Can a patient portal have a mobile app?
Yes. Many teams launch a responsive web portal first, then add a mobile app that uses the same back-end APIs once the core features are proven.
Patient portal development works best when security, integrations, and usability are planned together from the start. See how we approached this in our EHR portal development case study, or explore our Angular development services and back-end development services. You can also review our UI/UX design services, or contact us to discuss your portal.
