Patient Portal Development: A Practical Guide

TL;DR: Patient portal development is the work of building a secure web (and often mobile) app where patients view records, message clinicians, book appointments, pay bills and manage prescriptions. The hard parts are not the screens — they are EHR/EMR integration via HL7/FHIR, identity and access, and compliance (HIPAA in the US, GDPR/UK GDPR in Europe). Expect a realistic MVP in roughly 3–6 months, with integration and compliance driving most of the cost.

What is a patient portal, and what should it actually do?

A patient portal is a patient-facing application that gives people secure access to their own health information and lets them transact with a provider. Good patient portal development starts by narrowing scope to the workflows patients and staff use every week, not a wish-list of everything a hospital might want someday. The features tend to fall into three tiers: core (why portals exist), workflow (reduces staff load) and advanced (defer until the core is stable).

Tier	Capability	Why it matters
Core	View lab results, visit summaries, medications, immunisations	The primary reason patients log in; drives adoption
Core	Secure messaging with the care team	Replaces phone tag; must be auditable and access-controlled
Core	Appointment booking and reminders	Cuts no-shows and reception workload
Workflow	Bill view and online payment	Faster collection; brings in PCI-DSS obligations
Workflow	Prescription refill requests, intake forms	Removes repetitive front-desk tasks
Advanced	Telehealth video, wearable data, proxy/caregiver access	Valuable but adds real complexity — phase these in

A common mistake is treating the portal as a standalone product. In practice it is a thin, secure interface over one or more clinical systems of record — a framing that determines almost every technical decision that follows.

How do you integrate a patient portal with an EHR/EMR?

Integration is where portals live or die. The relevant standards are HL7 v2 (still ubiquitous for messaging like admissions and lab results) and HL7 FHIR, the modern REST/JSON API standard most new integrations target. In the US, the ONC's information-blocking rules and the USCDI data set have pushed major EHRs toward standardised FHIR APIs, making read access far more feasible than a decade ago.

How you connect depends on the environment you are integrating with:

• Vendor FHIR APIs let you register an app and pull FHIR resources such as Patient, Observation, MedicationRequest and Appointment using SMART on FHIR OAuth 2.0 scopes.
• HL7 v2 interfaces, usually via an integration engine, when the source predates FHIR or the data you need is not exposed over the newer API.
• Direct database or flat-file feeds — avoid unless there is no alternative; they are brittle and bypass the source system's access controls.

A practical rule: start read-only. Displaying data is far lower risk than writing appointments or messages back into a clinical system, where a bad write has patient-safety consequences. We cover the standards in depth in our EHR/EMR integration guide on HL7 & FHIR. If your portal is part of a larger consultation product, the telemedicine app guide covers the video and scheduling layer.

What are the compliance and security obligations?

A patient portal handles protected health information, so compliance is not optional and it is not a feature you bolt on at the end. The obligations vary by region:

• United States — HIPAA. You need administrative, physical and technical safeguards: access controls, audit logging, encryption of data in transit and at rest, and a signed Business Associate Agreement (BAA) with every vendor that touches PHI (hosting, email, SMS, error tracking).
• UK & Europe — UK GDPR / GDPR. Health data is a special category requiring a lawful basis, data-minimisation, a DPIA for high-risk processing, and honouring data-subject rights such as access and erasure.
• Australia. The Privacy Act and Australian Privacy Principles govern health information, with additional rules where you connect to national infrastructure.
• If you take card payments, PCI-DSS applies to the billing flow — the cleanest path is to keep card data entirely inside a processor like Stripe so your servers never store it.

SOC 2 is not a legal requirement, but many providers and enterprise buyers will ask for a SOC 2 report before they trust you with data. Treat it as a commercial gate rather than a regulatory one. For the concrete controls, work through our HIPAA compliance checklist for software teams, and if you are validating the idea first, the HIPAA-compliant MVP guide shows how to stay compliant without over-building.

The most expensive compliance mistake is architectural: choosing a vendor that will not sign a BAA, or logging PHI into a system you cannot audit. Fixing it after launch means re-plumbing, not patching.

Identity is the sharpest edge

Getting the right record to the right person is the highest-stakes problem in a portal. You need strong identity verification at enrolment, multi-factor authentication, and carefully scoped proxy access so a parent or carer sees only what they are permitted to. Role-based access control and complete audit trails are table stakes.

Should you build a custom portal or buy an off-the-shelf one?

Many EHRs ship with a bundled patient portal. Buying it is fast and cheap, but you inherit its look, its limits and its roadmap. Building custom gives you control over experience and workflow but costs more and puts integration and compliance squarely on you.

Factor	Bundled EHR portal	Custom build
Time to launch	Fast	Slower (months)
Upfront cost	Low	Higher
UX & branding control	Limited	Full
Custom workflows	Constrained	Unconstrained
Multi-system / multi-clinic	Often single-vendor	Can aggregate several sources
Ongoing ownership	Vendor-managed	You maintain it

Choose custom when the portal is core to your product's value — a multi-clinic platform, a condition-specific experience, or a startup whose differentiation is the patient experience. Choose the bundled option when you are a single practice that mainly needs record access and messaging.

What tech stack and architecture make sense?

There is no single right stack, but a pragmatic modern choice is a TypeScript codebase with React/Next.js on the front end, a Node.js API layer, and PostgreSQL for application data (with clinical data staying in the systems of record wherever possible). What matters more than framework choice is the discipline around it:

• Encrypt everything, and keep PHI out of logs, analytics and third-party tools that have not signed a BAA.
• Put an anti-corruption layer between the portal and each EHR so a change in one source system does not ripple through your app.
• Log every access to PHI with who, what and when — you will need it for audits and incident response.
• Host in a region matching your regulatory footprint (data residency matters under GDPR).

This is where a QA-first, compliance-aware partner earns its keep. At CodeVix Labs we build these healthtech products — FHIR integrations, HIPAA-aligned architecture and the boring-but-critical audit and access layers — as you can see across our healthtech practice and portfolio.

How much does patient portal development cost, and how long does it take?

Every quote depends on scope, integrations and compliance depth, so treat the following as broad, clearly-labelled industry estimates rather than a price. As a rough guide, a focused MVP — secure login, record viewing over a single FHIR source, messaging and appointment booking — typically takes around three to six months. Cost is driven far more by integration count and compliance evidence (audits, penetration testing, SOC 2 readiness) than by the number of screens.

The biggest cost multipliers are the number of distinct systems you integrate, whether you write data back to clinical systems, telehealth video, and the level of formal compliance attestation buyers demand. For a structured breakdown, see our cost to build a healthtech app guide, then get a tailored estimate on our pricing page or via contact.

Frequently asked questions

What is the difference between a patient portal and an EHR?

An EHR (electronic health record) is the clinician-facing system of record where care is documented. A patient portal is the patient-facing window into a subset of that data, plus self-service actions like messaging and booking. The portal reads from and sometimes writes to the EHR; it does not replace it.

Do I need to be HIPAA compliant if I am outside the US?

HIPAA applies to US protected health information. If you operate in the UK, EU or Australia, GDPR/UK GDPR or the Australian Privacy Principles apply instead. If you serve US patients or partner with US providers, HIPAA applies regardless of where your company is based. Map your obligations to where your patients and data actually are.

Can a patient portal work without full EHR integration?

Yes, for early validation. You can launch with self-entered data, forms and messaging to prove demand, then add FHIR read access and eventually write-back as you mature. Just be transparent that records are not yet synced from their provider.

Is FHIR enough, or do I still need HL7 v2?

For new, read-oriented integrations FHIR is usually the right target and is increasingly well supported. But many hospital systems still exchange core data over HL7 v2, so real-world integrations often use both — FHIR for the modern API surface and v2 (via an integration engine) for legacy feeds.