How to build a patient portal
What a patient portal needs, how it connects to clinical systems, the privacy and access rules behind it, and an order to build it in.
What a patient portal does
A patient portal lets patients see their results, book and change appointments, message their care team, request prescriptions and download their record, without phoning the clinic.
The hard parts are not the screens. They are showing results with the right context and timing, letting family members act for a patient under clear rules, and keeping the portal in step with the clinical systems behind it.
The modules you need
Most teams need all of these in the end. The phased plan below sets the order.
Sign-up and identity
Account creation tied to a verified patient record, with strong login and recovery.
Results and records
Lab results, letters and summaries released by rule, some immediately and some after a clinician has spoken to the patient.
Appointments
Booking, changes and cancellations against the clinic's real calendar, with reminders.
Secure messaging
Messages routed to the right team, with response times and escalation for urgent issues.
Prescriptions and requests
Repeat prescription requests, forms and documents sent to the right queue.
Proxy access
Parents, carers and family members acting for a patient, with limits by age and consent.
Payments
Bills, co-pays and payment plans, where the clinic charges patients.
Record export
The patient downloads or shares their record in a standard format.
How the parts fit together
- 01
Thin portal over clinical systems
The EHR stays the source of truth. The portal reads and writes through an integration layer.
- 02
Release rules engine
Which results and documents appear when, configured by clinicians, not coded.
- 03
Identity service
Verified accounts, proxy relationships and their limits, separate from the clinical record.
- 04
Message routing
Queues per team with service levels and escalation.
- 05
Notification service
Email, SMS and push that say something is ready without putting health data in the message.
Data model sketch
- 01
Account and patient link
The portal account, the verified patient it belongs to, and how it was verified.
- 02
Proxy relationship
Who acts for whom, with scope, start and end dates, and consent.
- 03
Released item
Each result or document shown, with the rule that released it and when.
- 04
Message thread
Messages, team, assignee, status and response time.
- 05
Appointment and request
Bookings and requests with their status in the clinical system.
Systems it has to talk to
- 01
EHR
Patient record, results, documents and appointments over FHIR or the EHR's API.
- 02
Scheduling
The clinic's calendar, often in a separate system from the EHR.
- 03
Identity verification
ID checks or national e-ID for sign-up and proxy access.
- 04
Payments
A payment provider for bills and co-pays.
- 05
Messaging channels
Email, SMS and push providers, under the right agreements for health data.
Rules to design for
Which rules apply depends on your market and product.
- 01
Right of access
Patients have the right to a copy of their record under HIPAA, the GDPR and national laws. A portal is often how clinics meet it.
- 02
Proxy and minors
Rules on what parents, carers and guardians may see change with age and capacity, and vary by country.
- 03
Health data protection
Vendors that hold the data need a BAA in the US and a processing agreement under the GDPR.
- 04
Accessibility
WCAG and accessibility laws apply, and patients are often older or unwell.
From prototype to production
Build in this order so something real is in users' hands early.
- 01
Clickable prototype
Results, booking and messages, tried by real patients, including older users and carers.
- 02
First release
Verified sign-up, results with release rules, and appointment viewing, connected to the EHR.
- 03
Requests and messaging
Booking changes, prescription requests and secure messages, with team queues.
- 04
Proxy access and payments
Family and carer access with its rules, bills and payments, and record export.
What drives the cost
These decide most of the budget. For a number based on your own scope, use the cost tool. OceanLab bills $30-50/hr or per milestone.
- 01
EHR integration
How open the EHR's API is decides much of the cost.
- 02
Identity verification
Remote ID checks or national e-ID, and the support process when they fail.
- 03
Proxy rules
Each type of proxy relationship adds rules and testing.
- 04
Languages and accessibility
Each language and the accessibility testing behind it.
- 05
Mobile apps
Native apps on top of the web portal, and their release process.
Product builds that match this guide
Tavor - Member Portal for an Israeli Health Fund with Family Proxy Access
Designed and built a clickable member portal for an Israeli health fund: one login for a member and the children and parents they look after, referrals and tofes 17 commitments with an honest status, and test results with plain-language explanations, held results and teen confidentiality built in.
Baken - Lab Results Portal with Critical Value Calls and Read-Back
Designed and built a clickable lab console for an ISO 15189 accredited laboratory in Zuid-Holland: follow every order and sample from collection to storage, read validated results with flags, EUCAST susceptibility and release state, and phone critical values against a deadline with a logged call chain and a read-back check.
Lyrebird - Patient Booking and Intake Platform with Clinician-Routed Risk Flags
Designed and built a clickable booking and intake platform for a group of GP, physiotherapy and psychology clinics in regional Victoria and southern NSW: a day calendar by practitioner or room, pre-visit forms reviewed before the visit, and a clinician-only queue that puts every risk answer in front of a clinician against a response target.
Sutura - HIPAA-Compliant Patient Data Hub over HL7 and FHIR
Designed and built a clickable patient data hub for a US health system running Epic, Oracle Health, athenahealth and eClinicalWorks: a live monitor for every HL7 v2, FHIR and HIE feed, one matched enterprise patient with a provenance-tagged record, and a duplicates queue where a person decides every uncertain match.
Two ways to work with OceanLab
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
Questions
Should results appear in the portal straight away?
Some can, and some should wait until a clinician has spoken to the patient. We make it a rule clinicians configure, and check it against the access rules where you operate.
How do family members get access?
Through a proxy relationship that is verified, limited in scope and time, and consented to by the patient where they can consent. Every proxy action is logged.
Can the portal work with our existing EHR?
Usually yes, through FHIR or the EHR's own API. We check what it exposes early, because that shapes what the first release can do.
