Patient portal development: what clinics actually need
Most clinics have thought about building a patient portal at some point. The idea is obvious: give patients a place to log in, see their records, book appointments, and communicate with the clinic. Reduce phone calls. Reduce paperwork. Improve patient satisfaction.
But the execution is where things get complicated.
A poorly built patient portal is either so locked down that patients cannot do anything useful, or so open that it creates HIPAA compliance problems. Getting the balance right requires thinking carefully about data access, authentication, document security, and the actual patient experience.
This page covers what patient portal development really involves, what decisions you need to make upfront, and what a production-grade portal looks like in practice.
What patients actually want from a portal
Before getting into the technical requirements, it helps to be clear about what patients actually need from a portal. Because most patient portals are designed for what the clinic wants, not what the patient needs.
Patients want
- To see their appointment date and time without calling the front desk
- To access their documents (reports, invoices, referrals) without waiting for a mailed copy
- To send a message to the clinic without sitting on hold
- To know what happened at their last visit before their next one
- To sign or complete forms before showing up
They do not want
- To reset their password three times before getting in
- A wall of medical jargon they cannot understand
- A portal that works on desktop but breaks on their phone
- To upload a document and have no confirmation it was received
That list sounds basic. But most patient portals fail on at least two of those points. Design the portal around actual patient behavior and you will see adoption. Design it around what looks impressive in a demo and you will see patients calling the front desk anyway.
The security requirements for a HIPAA-compliant patient portal
Patient portals handle Protected Health Information. That means HIPAA's Security Rule applies. Specifically, the technical safeguards:
Access controls
Patients must authenticate before accessing any data. Authentication needs to be strong enough to prevent unauthorized access. This typically means username and password with optional two-factor authentication. For some portal types, magic link authentication (a one-time login link sent to a verified email) works well.
Automatic logoff
Sessions should expire after a period of inactivity. The HIPAA-recommended maximum is 15 to 30 minutes for healthcare applications, though this varies by use case. A patient leaving a portal open on a public computer should not expose their records to the next person who sits down.
Audit trails
The system should log every time a patient accesses their records, downloads a document, or sends a message. This is partly for HIPAA compliance and partly for clinical tracking.
Encrypted document storage
Documents that patients can download — reports, invoices, imaging results — should be stored encrypted and served via time-limited signed URLs. The URL should expire after a short period so a shared link does not become a permanent open door to the document.
Role isolation
A patient should only be able to see their own data. No shared identifiers, no URL parameters that could be incremented to access another patient's record.
Document access in a patient portal
One of the highest-value features in a patient portal is document access. Patients want to download their medical records, see their invoice status, access their referral letters. This is what reduces the most phone calls. But document access in healthcare is not as simple as linking files in a folder. There are several design decisions:
Document classification
Not all documents should be patient-accessible. Internal billing notes, staff-only audit records, and draft documents are not appropriate for patient-facing portals. You need a classification system for documents that marks which ones are patient-accessible.
Access control at download time
When a patient clicks to download a document, the system should check: does this patient have permission to access this document? Not just at the list level, but at the moment of download. Using signed URLs from AWS S3 with 15-minute expiry handles this well. The URL only works for 15 minutes after it is generated, and it is only generated when the appropriate patient requests it.
Version management
Medical documents sometimes get updated. A physician amends a report. An invoice is revised. The portal should show the current version, not outdated drafts.
Notification on new documents
Patients should receive an email or SMS notification when a new document is added to their portal. Waiting for them to remember to log in is a poor experience.
SMS and messaging in patient portals
The phone call problem is real. Clinical staff spend significant time answering patient questions that could be handled through asynchronous messaging. A patient portal with messaging reduces this.
Medico SMS module
The Synectus Medico platform includes an SMS communication module with a chat-style interface. Clinical staff see all patient conversations in a thread view. Patients can be messaged individually or via templates for common communications like appointment reminders or document requests.
Two-way messaging design
For a patient-facing portal, messaging should work in both directions. Patients can send messages to the clinic from the portal. Clinical staff respond from their dashboard. The conversation is logged for compliance purposes.
Technical considerations for patient portal messaging:
- Message delivery via Twilio or similar SMS provider for SMS-based communication
- Real-time delivery status (sent, delivered, read)
- Template management for common clinic messages
- Role-based staff access so only appropriate staff can view and respond to patient messages
Role isolation: what patients see vs what staff see
One of the most important design decisions in a patient portal is role isolation. Different users see different versions of the same data. When a physician looks at a patient record, they see everything. Clinical notes, billing status, internal flags, staff comments, the full history. When the patient logs into their portal, they should see a carefully filtered view.
Physician view — full access
- Clinical notes
- Billing status
- Internal flags
- Staff comments
- Full history
Patient portal — carefully filtered view
Patients see
- Appointment dates and times
- Their own documents
- Their invoice status (but not the internal billing negotiation)
- A messaging interface
They should not see
- Internal clinical notes marked for staff only
- Other patients' data
- Billing reduction negotiation details
- Staff comments or flags meant for internal use
This filtering happens at the API level. The patient's JWT token contains their role and patient ID. Every API call is pre-filtered server-side based on these values. It is not enough to hide fields in the UI. The underlying API must enforce the access rules regardless of how requests are made.
Mobile-first design for patient portals
Patients access portals primarily on mobile. Not desktop. This should drive every UI decision.
That means:
- Large touch targets for buttons and form fields
- Single-column layouts that scroll vertically on small screens
- Fast loading on mobile data connections (3G or 4G)
- No multi-step wizards that require a large screen to navigate
- Native-feeling interactions where possible (swipe, tap, not hover)
A patient portal that looks great on desktop but requires pinching and zooming on mobile will see low adoption. Clinical staff often have desktop access and will tolerate suboptimal mobile UX. Patients will not. If you are building a patient portal, test it on an actual Android phone on a 4G connection before considering it done.
Patient intake vs ongoing patient portal access
There is an important distinction between a patient intake tool and an ongoing patient portal.
Intake tool
Used once — before or during the first visit
- Collects demographics, insurance information, medical history, and consent forms
- Does not require a login (usually)
- Gets embedded in a website or sent as a link
Ongoing portal
Used repeatedly throughout their care
- They check appointment status
- They download documents
- They message the clinic
Many portals try to do both. That works, but the UX flows are different. First-time completion of an intake form has different requirements than a returning patient accessing their records. Design them separately even if they live in the same application.
What a patient portal project looks like in practice
A realistic patient portal project for a specialty clinic (personal injury, physical therapy, chiropractic) typically involves:
Authentication and patient identity
Secure login, session management, password reset, optional SMS two-factor authentication. Connecting the portal user account to the existing patient record in the EMR.
Record access
Patient summary view, appointment history, document download with signed URL delivery, invoice status display (filtered view, not full billing detail).
Communication
Secure messaging between patient and clinic. Notification system (email or SMS) when new documents or messages arrive.
Forms and intake
Pre-visit intake forms, consent forms, insurance capture. Document upload for insurance cards or referral letters.
Each phase is typically 4 to 8 weeks depending on complexity. A basic portal (phases 1 and 2 only) can be built in 6 to 10 weeks. A full-featured portal with messaging and forms takes 16 to 24 weeks.
Frequently asked questions
A patient portal is one of the highest-ROI features a clinic can add to their software stack. Done right, it reduces phone calls, improves patient satisfaction, and keeps documentation flowing without manual intervention.
Done poorly, it creates security risks, confuses patients, and drives them back to calling the front desk anyway.
The difference is in the design decisions: what data patients can access, how authentication works, how documents are served securely, and whether the mobile experience is actually good.
If you are building a patient portal for your clinic or as part of a healthcare SaaS product, a conversation about your specific requirements will help figure out the right scope and approach.
Get a Portal Estimate