by Format-3

Share article

{
"@graph": [
{
"@type": "Article",
"image": {
"url": "https://media.babylovegrowth.ai/blog-images/organization-13731/1790799596030_Patient-using-portal-at-clinic-reception.jpeg",
"@type": "ImageObject",
"caption": "Patient using portal at clinic reception"
},
"author": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"headline": "Patient Portal Design That Drives Adoption in 90–180 Days for Clinics",
"publisher": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"inLanguage": "en-GB",
"description": "Design patient portals patients actually use. Prioritise results, secure messaging and one touch scheduling; use co design, a HIPAA documented risk...",
"dateModified": "2026-09-30T20:22:21.212Z",
"datePublished": "2026-09-30T20:22:21.212Z"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"item": "https://format-3.co",
"name": "Format-3",
"@type": "ListItem",
"position": 1
},
{
"item": "https://format-3.co/patient-portal-design",
"name": "Patient Portal Design That Drives Adoption in 90–180 Days for Clinics",
"@type": "ListItem",
"position": 2
}
]
}
],
"@context": "https://schema.org"
}

Patient Portal Design That Drives Adoption in 90–180 Days for Clinics

Design patient portals to enable a few high value tasks well: results, secure messaging, and scheduling, then measure whether people actually use them. The strongest early signals are task-first UX, a documented HIPAA risk analysis, and interoperability testing that goes beyond a vendor’s word. A quick pilot suits narrow, well-understood workflows; deep custom builds earn their cost only when the workflow itself is genuinely unusual.

TL;DR:

Format-3

Build Better Healthcare Experiences

Format-3 designs, develops, and scales user-centric digital products for healthcare organizations through strategy, design, engineering, and growth.

Explore Format-3

Table of Contents

Choosing between EHR native, custom build or a component platform
Ship the tasks that drive adoption first
User research and co-design methods that lower launch risk
Turning HIPAA requirements into engineering tasks
What to test before trusting a vendor’s FHIR claims
A 90/180 day rollout that earns its next phase
Perspective from Format-3’s healthcare practice
Designing for the device a patient actually has
Building for patients who don’t read your primary language
Privacy obligations that start where HIPAA stops
Planning for growth before the load forces the issue
Keeping the portal improving after launch without breaking trust
Why adoption metrics matter more than feature parity
How Format-3 can help teams building this properly
Sources
FAQ

Choosing between EHR native, custom build or a component platform
Most healthcare organisations approach this decision backwards. They ask which platform looks most impressive in a vendor demo, rather than asking what their patients actually need to do and how unusual that need really is. Four questions settle the matter faster than any procurement scorecard.

Is the workflow genuinely unique to your organisation, or a variation on something every hospital handles? A community clinic scheduling routine follow ups has little reason to reinvent what an EHR module already does adequately. A specialist network coordinating multi-provider care plans might not have that luxury.

How deep does the integration need to run? Surface level tasks like viewing results tolerate a thinner integration. Billing reconciliation, multi-system scheduling or PGD import demand a much closer relationship with underlying clinical data, and that closeness is expensive to build and maintain.

How fast do you need to demonstrate value? Boards and funders rarely grant unlimited runway. A component or platform approach, built on a vendor’s existing patient engagement layer, can produce a working pilot in weeks rather than the year or more a fully custom build often requires.

Who owns the roadmap in three years? EHR native portals inherit the vendor’s release cycle, for better or worse. Custom builds put the organisation in charge of every future decision, and every future bug.

• EHR native modules: lowest upfront cost, fastest time to a baseline experience, but limited room to differentiate and dependent on the vendor’s own release schedule.
• Component or platform approach: moderate cost and timeline, strong middle ground for organisations that need customisation without full ownership of the underlying engineering.
• Fully custom build: highest cost and longest timeline, justified only when workflows are genuinely distinctive or when long-term platform control outweighs the delivery risk.

Before committing to the heavier end of that spectrum, run a pilot. A pilot’s job is to answer one question cheaply: will patients actually use this if we build it properly? Track task completion on the two or three flows that matter most, watch weekly active use over four to six weeks, and set a threshold before you start, not after the results come in. If a pilot cannot clear a modest usage bar on a handful of core tasks, a deeper EHR integration will not fix that. The problem is rarely plumbing. It is usually relevance.

Ship the tasks that drive adoption first

Feature lists are seductive and mostly beside the point. What drives portal utilisation is a small set of tasks, executed with enough clarity that a worried, distracted, possibly unwell person can finish them without help. Research on person-centred design, including the Opal portal’s participatory co-design work, points to the same short list: viewing results with context, sending and receiving messages, and booking or changing appointments.

1. Contextualised results. A number without meaning creates anxiety, not information. Opal’s approach paired lab values with tailored education linked directly to the result, turning a bare figure into something a patient could act on.
2. Secure messaging with quick replies. Most patient messages are short, practical questions. Quick reply templates and clear turnaround expectations reduce both patient frustration and staff message volume.
3. One touch scheduling. Appointment booking that requires navigating five screens loses people at every step. The best flows collapse date, time and provider selection into a single, short interaction, with appointment specific advice surfaced automatically, as Opal’s design did.
4. Billing and payment visibility. Confusion about what is owed and why is one of the most common reasons patients abandon a portal entirely, even when the clinical features work well.

Older adults consistently gravitate to a narrower version of this list. A JMIR study using the Technology Acceptance Model found that older patients with multiple chronic conditions favoured email, pharmacy requests and lab results, and struggled with logins, small fonts and multi-step appointment flows. That is not a reason to simplify the whole product. It is a reason to promote the handful of features that already work for this group rather than burying them under advanced functionality nobody asked for.

Pro Tip: Launch with fewer tasks done well rather than a full feature set done adequately. Adoption data will tell you what to build next far more reliably than a requirements workshop.

Advanced features, including AI-assisted triage, symptom checkers or device integrations, belong in a later phase, gated behind evidence that the core four tasks are working. Stage them with the same discipline you’d apply to any clinical intervention: a defined hypothesis, a measurable outcome, and a willingness to abandon the feature if it does not move usage. An AI summary of a lab result is only useful if patients trust it, and trust here is earned slowly, not assumed because the technology is capable. For teams exploring how personalised content and context can be woven into results screens, there’s useful groundwork in how digital storytelling shapes patient engagement more broadly.

User research and co-design methods that lower launch risk

The organisations that get adoption right tend to share a working method, not just a design sensibility. The participatory co-design model behind Opal identifies six elements worth treating as a checklist rather than inspiration.

• Equal co-leadership between patients, clinicians and the technical team, so no single group’s priorities dominate the brief.
• Structured patient preference determination, asking directly what patients want to see and do, rather than inferring it from clinical workflows.
• Legal and security input from the earliest design stages, not bolted on before launch.
• A continuous feedback loop that persists after go-live, not a single round of testing before the build starts.
• Staff input from the people who will field the calls and messages the portal generates.
• End-user testing with real patients performing real tasks, scored against objective measures rather than opinion.

That last point matters more than most teams assume. A large usability study of a national patient portal surveyed Thousands of respondents reported a high average System Usability Scale score, with information quality and gaps identified as the biggest drivers of both satisfaction and frustration. SUS alone will not tell you whether a portal succeeds commercially, but paired with task completion rates and abandonment data, it gives you an honest, comparable signal across design iterations.

Recruitment should include older adults, people with limited English proficiency, and low-bandwidth users deliberately, not as an afterthought once the core design is locked. Scenario-based sessions, where a participant is asked to complete a realistic task like rescheduling an appointment rather than simply reacting to a screen, surface far more usability problems than open-ended feedback.

Accessibility is not a compliance checkbox here, it is an adoption strategy. Mobile performance on low-end devices, screen reader support, and interface translation determine whether entire patient populations can use the portal at all. Adolescent and proxy access adds another layer of complexity: caregivers managing a relative’s account need clearly scoped permissions, and the Health IT Playbook’s guidance on inclusion treats proxy access and multilingual support as core adoption levers rather than edge cases.

Pro Tip: Test with the people who struggle most, not the people who adapt most easily. A portal that works for a seventy-year-old on a three-year-old phone will work for almost everyone else.

Turning HIPAA requirements into engineering tasks

Compliance work that starts with a checklist instead of a risk analysis tends to protect the wrong things. HHS guidance is explicit that the first compliance task is a documented risk analysis, mapping specific threats and vulnerabilities to the safeguards that address them, before a single line of access control code gets written.

The Security Rule’s documented risk analysis requirement is the starting point for every technical decision that follows, according to HHS guidance on HIPAA risk analysis. That sequencing matters: a team that builds encryption and access control first and documents the reasoning afterwards has usually protected the easy things and missed the hard ones.

From there, a concrete engineering checklist follows naturally:

• Unique user identification and role-based access control for every account, including staff proxies and caregiver logins.
• Audit logs detailed enough to reconstruct who accessed what, and when, without relying on inference.
• Transmission protection using TLS 1.2 or 1.3, with encryption at rest for anything containing protected health information.
• Automatic logoff after inactivity, balanced against the friction it introduces for patients on shared or mobile devices.
• Emergency access procedures that do not quietly weaken the access controls the rest of the system relies on.

Authentication deserves particular attention because it sits at the exact point where security and usability collide. Multi factor authentication reduces risk substantially, but token lifetimes and offline access behaviour need real thought: a token that expires mid-session during a slow mobile connection creates the kind of friction that pushes patients back to the phone line. Operationally, penetration testing, vulnerability scanning and a rehearsed incident response plan are not optional extras, they are the evidence that the risk analysis produced working safeguards rather than a document nobody revisited.

None of this needs to feel punitive to the patient. Consent screens, explainability around what data is shared and why, and clear patient preference settings for things like proxy access can all be designed as part of the product experience rather than a legal afterthought. Teams building this work in house sometimes underestimate how much of it, particularly the initial risk analysis and remediation, benefits from outside specialists; firms such as Tatem Web’s HIPAA compliance services exist precisely because this work is easy to under-scope internally.

What to test before trusting a vendor’s FHIR claims

“We support FHIR” is a sentence that means almost nothing on its own. Interoperability maturity varies enormously between vendors, and the only reliable way to know what you are actually getting is to test specific resources and behaviours rather than accept a general claim.

1. Confirm read and search support for the resources your workflows actually depend on: Patient, Observation, Encounter, DocumentReference and Provenance, each tested with realistic, messy data rather than a clean demo dataset.
2. Run a full SMART on FHIR authorisation flow end to end, including token refresh, and check what happens when a refresh token expires mid-session rather than assuming graceful failure.
3. Stress-test patient matching across systems with deliberately ambiguous records, similar names, shared addresses, missing identifiers, because matching errors here are a patient safety issue, not just a data quality one.
4. Verify that Provenance data survives when records are combined from multiple sources, so a patient viewing a lab result can see which system actually produced it.
5. Check consent handling explicitly: does the system respect a patient’s choice to withhold certain data from certain viewers, or does combining sources quietly override that choice?

ONC’s data briefs on hospital patient engagement capabilities show rising app and FHIR based access across hospitals, driven partly by Cures Act requirements, but uneven adoption of more advanced capabilities like data import and patient-generated data support. Treat that unevenness as the default assumption, not the exception, when scoping integration work. For teams new to the standards themselves, a plain-language grounding in what HL7 actually covers is worth the half hour before the first vendor call.

A 90/180 day rollout that earns its next phase

A launch plan without measurement gates is just hope with a timeline attached. The metrics worth tracking from day one are System Usability Scale scores, task completion rates on the core flows, weekly and monthly active users, secure messaging turnaround time, the share of appointments booked through the portal rather than by phone, and support contact volume as a proxy for friction.

In the first 90 days, the priority is narrow and disciplined: launch the core task set to a limited population, instrument everything, and resist the urge to add features before the data justifies them. Staff need prompts built into their existing workflow, not a separate training manual nobody reads twice. A helpdesk service level agreement, even an informal one, gives the rollout team an early warning system for friction before it shows up as churn.

By day 180, the question shifts from “does it work” to “does it scale.” That means a governance loop, patients, clinicians, legal and operations reviewing the same dashboard on a fixed cadence, deciding together what gets built next based on evidence rather than the loudest internal voice.

• Watch WAU/MAU ratio as the clearest single signal of whether the portal has become a habit rather than a novelty.
• Treat rising support contact volume as a usability defect to fix, not a training problem to lecture patients about.
• Expect clinician resistance if staff workflows were not redesigned alongside the patient-facing screens, and plan for it explicitly.
• Revisit the original pilot thresholds at 180 days. If the portal has not cleared them, further investment needs a harder conversation, not more features.

Perspective from Format-3’s healthcare practice

Most portal failures we encounter trace back to a single decision made early and never revisited: treating feature parity with a competitor’s product as the goal, instead of treating a handful of measurable patient behaviours as the goal. Format-3’s working position, shaped through discovery sprints and embedded delivery across healthcare and other regulated sectors, is that governance loops and adoption metrics outperform feature checklists almost every time.

Discovery sprints earn their cost by surfacing clinician resistance before a single screen is built, rather than after launch when the workflow is already broken in production. Design research conducted alongside, not after, engineering tends to cut the rework that otherwise eats the back half of a delivery timeline. The pattern holds across the industries we work in: the projects that succeed are the ones where measurement was designed in from the first sprint, not added once leadership started asking hard questions.

Designing for the device a patient actually has

A portal designed on a large monitor and tested on a flagship phone will disappoint most of the people who actually open it. Patients arrive on a wide range of devices, older Android handsets, shared family tablets, browsers with ad blockers that quietly break embedded widgets, and the design needs to survive all of it gracefully.

Responsive layout is the baseline, not the achievement. Touch targets need to be large enough for someone with limited dexterity or a shaking hand to hit reliably. Forms should default to appropriate input types, a numeric keypad for a date of birth field, rather than forcing a full keyboard onto a small screen. Heavy image assets and unoptimised scripts punish patients on slower mobile connections disproportionately, and those are often the patients who most need the portal to work.

Performance budgets matter more on mobile than almost anywhere else in the product. A results page that takes eight seconds to load on a train connection will be abandoned before the number ever appears. Testing on genuinely low-end devices, not just simulated throttling in a desktop browser, catches problems that desktop-first teams routinely miss. The JMIR study on older adults’ portal use found that small fonts and complex multi-step flows were named specifically as barriers, and both of those are mobile problems as much as they are design problems.

Building for patients who don’t read your primary language

A portal that only speaks one language quietly excludes a share of the population it was built to serve, and that exclusion rarely shows up in a feature specification. Internationalisation has to be a structural decision, not a late addition of a language toggle bolted onto finished screens.

Practically, that means separating content from code from the start, so that adding a language does not require touching interface logic, and choosing a translation approach, professional translation rather than automated, for anything touching clinical meaning, consent language or medication instructions. Date formats, units of measurement and even colour conventions carry cultural assumptions that a literal translation will not fix on its own.

The Health IT Playbook’s guidance on patient engagement names multiple language support explicitly as an adoption lever, alongside mobile friendliness and assistive technology support, rather than treating it as a nice-to-have. That framing is the right one. A patient who cannot read the results screen in a language they understand has, in practical terms, no portal at all, regardless of how well the underlying engineering performs.

Privacy obligations that start where HIPAA stops

HIPAA sets a floor for protected health information within the United States healthcare system, but it is not the only privacy framework a portal will need to satisfy, particularly for organisations with any international patient base or ambitions of one. GDPR, where it applies, introduces obligations HIPAA does not: explicit, granular consent, a genuine right to access and correct personal data, and a right to erasure that has no direct HIPAA equivalent.

Consent management deserves to be a product feature in its own right, not a one-time checkbox buried in onboarding. Patients should be able to see what data is shared, with which parties, and revoke specific permissions without needing to contact support to do it. That kind of granular control is exactly what the participatory co-design work behind Opal built into its governance input from the earliest design stages, treating legal and security considerations as design inputs rather than constraints applied afterwards.

The practical takeaway for engineering teams is to design the consent and data access layer to the stricter of whichever frameworks actually apply, rather than building two parallel systems. A single, well-designed consent model that satisfies the more demanding standard tends to be simpler to maintain than two separate compliance layers bolted together after the fact.

Planning for growth before the load forces the issue

A portal that works well for a thousand active users can fall over at ten thousand in ways that have nothing to do with the original design decisions. Performance problems at scale are rarely a single bottleneck. They are usually the accumulation of small inefficiencies that were invisible at pilot volume.

Database query patterns that felt fine during a 90 day pilot often need rethinking once messaging volume and appointment traffic both climb simultaneously. Caching strategies for frequently accessed, rarely changing data, provider directories, clinic hours, can absorb a meaningful share of load without touching the core architecture. Horizontal scaling of the application layer needs to be planned for from the architecture stage, not retrofitted under pressure during a usage spike nobody predicted.

Monitoring deserves the same seriousness as the features themselves. Response time percentiles, not just averages, reveal the experience of the unluckiest users, often the ones on the weakest connections who can least afford a slow portal. Load testing against realistic, not idealised, traffic patterns, including the surges that follow a results notification going out to thousands of patients at once, catches the scaling problems that a steady-state test will miss entirely.

Keeping the portal improving after launch without breaking trust

The temptation after a successful launch is to keep shipping features at the same pace that got the product out the door. That instinct, unchecked, is how portals accumulate the feature bloat that made the original decision framework necessary in the first place.

A better pattern treats every post-launch change as a hypothesis with a measurable outcome, reviewed by the same governance loop, patients, clinicians, legal and operations, that shaped the original build. Feature flags let teams test changes with a subset of users before a full rollout, catching usability regressions before they reach everyone. Communication with patients about upcoming changes, particularly anything touching how results or messages are displayed, reduces the confusion that erodes trust faster than almost any other single factor.

Staff need a voice in this loop as much as patients do. A change that looks like a usability improvement on paper can quietly break a workflow the front desk relies on daily, and that kind of friction shows up in support contact volume long before anyone flags it as a design problem. Version the changes, document the reasoning, and keep the same discipline that governed the initial risk analysis and co-design process applied to every update that follows.

Why adoption metrics matter more than feature parity

The received wisdom in this industry still treats a patient portal as a feature competition, more capabilities, more integrations, a richer dashboard, as if adoption follows naturally from capability. The evidence, including Opal’s participatory co-design results and ONC’s own data on uneven capability adoption, points the other way. Patients adopt a handful of well-executed tasks, not a comprehensive platform, and most of the advanced features hospitals proudly list in procurement documents sit unused.

What gets underestimated is how much of adoption is earned in the first ninety days, through the clarity of a results screen or the speed of a scheduling flow, rather than recovered later through a feature update. A portal that launches confusing rarely redeems itself with a roadmap. The conventional advice to “build for parity with the market leader” mistakes the wrong benchmark: the market leader’s feature list is not what made it succeed, its task completion rate and SUS score are.

If there is one priority worth taking from this, it is to measure before you expand. A governance loop with real patient and clinician input, watching adoption data rather than a competitor’s changelog, will tell you what to build next far more honestly than any procurement exercise.

— Martin

How Format-3 can help teams building this properly

Getting the sequence right, discovery before design, design before engineering, measurement before expansion, is harder to hold to under internal pressure than it sounds on paper. That is usually where an outside partner earns its place, not by replacing internal judgement but by protecting the discipline that a rushed timeline tends to erode.

We work with healthcare organisations across the stages this article has described, providing services such as digital product discovery, design sprints, experience design, full-stack development, and AI implementations for teams ready to build or extend a portal with governance and security foundations in place.

A discovery sprint typically answers the scoping questions this article raises, workflow uniqueness, integration depth, realistic timeline, before committing to a full build. A full engagement carries that work through design, engineering and the measurement loop that keeps the product honest after launch. Details on how these services are structured are on the Format-3 services page, and a conversation about your specific portal challenge costs nothing to start.

Sources

• HHS guidance — risk analysis for HIPAA security
• Design and development of a person-centred patient portal using participatory stakeholder co‑design (JMIR, Opal)
• Patient engagement capabilities among hospitals (ONC brief)

FAQ

What is the most important factor in patient portal design?

Prioritising a small number of high-value tasks, results, secure messaging and scheduling, and measuring how patients actually use them matters more than matching a competitor’s feature list. The Opal participatory co-design study found that person-centred design focused on these core tasks drove adoption during its pilot.

How is patient portal usability typically measured?

Usability is commonly measured with the System Usability Scale alongside task completion rates and abandonment data. A large JMIR usability study of a national portal recorded a mean SUS of 74.3 across 4,719 respondents, with information quality and gaps identified as the main drivers of patient sentiment.

What does HIPAA actually require for a patient portal?

HIPAA requires covered entities to begin with a documented risk analysis identifying threats and vulnerabilities to protected health information, then apply appropriate safeguards. HHS guidance treats this risk analysis as the starting compliance task, ahead of specific technical controls like access management and audit logging.

Should a healthcare organisation build a custom patient portal or use an EHR module?

The right choice depends on how unique the workflow is, how deep the integration needs to run, and how quickly value needs to be demonstrated. EHR native modules suit standard workflows with tight budgets and timelines, while custom builds or component platforms suit organisations with distinctive needs or a long-term ownership requirement.

How does interoperability affect patient portal design?

Interoperability determines whether a portal can reliably pull and display data from multiple clinical systems without errors in patient matching or data provenance. ONC data briefs show that while hospital FHIR and app access has grown, advanced capabilities like data import remain unevenly supported, so specific vendor behaviours need testing rather than assuming general FHIR compliance.

Recommended

• Digital Product Design Tips Healthcare UX
• Digital Storytelling Patient Engagement
• Why Invest in UX Research Healthtech
• CareHive

By Format-3

Press & Media

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms