How to Build a Patient Portal App

What is a patient portal app

A patient portal app is a mobile application that gives patients direct, secure access to their own health information and to the people who provide their care. Through it, a person can read their medical records, view lab and test results, send a message to a nurse or doctor, book an appointment, request a prescription refill, and pay a bill. It is the front door that a clinic, hospital or practice offers to patients who want to manage their care from a phone instead of a waiting room or a phone queue.

What sets a patient portal apart from most healthcare software is who it serves. Many clinical systems are built for staff. A portal is built for patients, which means it exposes protected health information directly to the individual it belongs to. That single fact shapes almost every design decision that follows. The app has to prove who a person is before it shows them anything sensitive. It has to present clinical information in a way an ordinary person can understand. And it has to do all of this while meeting the privacy rules that govern health data in whichever country the practice operates in.

In our work with a US gastroenterology practice, the portal is often the first place a patient looks after a procedure. They want to know when their pathology results will be ready, whether they need to change anything before their next visit, and how to reach the care team without sitting on hold. A good portal answers those questions calmly and clearly. A poor one creates more phone calls than it prevents, which defeats the entire purpose of building it.

Who uses a patient portal, and why it matters

It helps to remember that the audience is broad. A patient portal is used by young and old, by people who are comfortable with technology and people who are not, by patients managing a single issue and by patients living with several chronic conditions at once. Some users are caregivers acting on behalf of a parent or a child. The design has to work for all of them, which is why plain language, large touch targets, and clear next steps matter more here than visual flair.

• Patients checking results, booking visits, and messaging their care team.
• Caregivers and proxies managing care for a child, a parent, or a dependent adult.
• Clinical staff who respond to messages, release results, and manage appointment requests from the other side.
• Billing staff who post statements and answer questions about balances and coverage.

Because a portal touches all of these groups, it is never only a patient facing app. There is always a staff facing side, whether that lives inside the existing electronic health record or in a companion tool you build alongside the portal. Treating the portal as a two sided product from the start avoids a common trap, which is shipping a beautiful patient app that quietly buries the staff in unmanageable work.

Core features to include

Patients arrive at a portal with a short list of things they want to do, and they judge the whole product by how easily they can do them. Meeting these expectations is the baseline. The features below are the ones users have come to expect from any modern patient portal app, and skipping any of them tends to generate the exact phone calls the portal was meant to reduce.

Records access

Patients want to see their own chart: diagnoses, medications, allergies, immunizations, visit summaries, and care instructions. Records access is the heart of the product because it is what a portal fundamentally exists to provide. The challenge is presenting clinical data, which is written for clinicians, in a way a patient can read without alarm or confusion. Good portals add plain language explanations, link medical terms to trustworthy definitions, and make it obvious what a patient is expected to do next.

Lab and test results

Results are the single most requested feature in most portals. People are anxious about a pending result and they check obsessively until it appears. The portal should show results clearly, mark what falls outside the normal range, and where appropriate include a short note from the ordering provider that puts a number in context. We will return to how results release works in its own section, because the timing of that release is one of the more delicate decisions in the whole build.

Secure messaging with the care team

Messaging lets a patient ask a question without a phone call and lets the care team answer on their own schedule. Done well, it reduces call volume and gives patients a written record of the answer. Done poorly, it becomes an unfiltered inbox that overwhelms clinical staff. The design has to guide patients toward the right kind of message and set clear expectations about response time and what messaging is not for, which is emergencies.

Appointments

Patients want to see upcoming visits, request or book new ones, reschedule, and receive reminders. Even a simple version, where a patient requests a time and staff confirm it, removes a great deal of phone traffic. A fuller version shows real availability from the practice schedule and lets the patient self book within rules the practice sets. If scheduling is the main problem you want to solve, our guide on how to build a doctor appointment app goes deeper on that piece.

Billing and statements

A portal that shows balances, itemized statements, and a way to pay saves the billing office a large volume of calls. Patients also want to see what their insurance covered and what they owe, presented in language that does not require a billing degree to understand.

Prescription refills

Refill requests are a natural fit for a portal. A patient selects a current medication, requests a refill, and the request routes to the right person for approval. This is convenient for patients and, because it arrives as structured data rather than a voicemail, it is easier for staff to process accurately.

A quick feature comparison

Not every practice needs every feature on day one. The table below sorts common portal features into what most portals launch with and what tends to come later, so you can plan a first release that is useful without being enormous.

If you want help deciding what belongs in your first release, our team maps features to effort during a short discovery call. You can read more about how we approach healthcare software, see the wider picture in our overview of healthcare app development, or browse our full services to see how a portal fits alongside the rest of a practice's software.

Records and results release

Showing a patient their own records sounds simple until you consider that some information is sensitive, some is easy to misread, and some arrives before anyone has had a chance to explain it. How and when a portal releases records and results is one of the most consequential parts of the design, and it is an area where clinical judgment and patient rights have to be balanced carefully.

The patient right of access

In the United States, patients have a clear right to access their own health information, and rules discourage practices from blocking or unreasonably delaying that access. This has pushed most portals toward releasing results to patients quickly, often as soon as they are finalized. The upside is transparency and speed. The trade off is that a patient may see a result before their provider has reviewed it or had the chance to call and explain what it means.

In our work with a US gastroenterology practice, this tension shows up constantly around pathology and imaging. A patient who reads a report full of unfamiliar terms, with no context, can spiral into worry over something that turns out to be routine. So the portal has to do two things at once: honor the patient's right to see their information promptly, and soften the experience so that raw data does not land like a cold shock.

How results release usually works

Most portals implement a release policy that treats different result types differently. Routine results might publish automatically. More sensitive categories might hold briefly so the ordering provider can add a note or make a call first. The exact rules are a clinical and legal decision that the practice owns, not one a developer should invent. The developer's job is to build a system flexible enough to express whatever policy the practice and its counsel decide on.

• Immediate release for routine results, so patients are not left waiting.
• Short hold windows for categories a practice chooses to review first, configured by result type.
• Provider notes attached to a result to give context in plain language.
• Clear labeling of what is normal, what is outside range, and what needs follow up.

Making results readable

A number on its own means little to most people. A strong portal presents a result with a reference range, a plain marker for whether it is in or out of range, and, where the practice allows, a short explanation. Trends matter too. Seeing a value move over several tests tells a more useful story than a single reading. None of this replaces a conversation with a clinician, and the portal should say so, but thoughtful presentation turns anxiety into understanding.

Document handling

Records access also means documents: visit summaries, discharge instructions, referral letters, and scanned files. Patients should be able to view and often download these. On the staff side, there needs to be a controlled way to decide which documents become visible in the portal and when. Building that control panel is as important as building the patient view, because it is what lets the practice manage the flow responsibly.

Secure messaging with the care team

Secure messaging is the feature patients love and staff worry about, and both reactions are reasonable. For patients, it removes the friction of phone tag and gives them a written answer they can refer back to. For staff, an open channel to every patient can become a flood if it is not designed with care. The goal is a messaging system that is genuinely useful to patients and genuinely manageable for the people answering.

What makes messaging secure

Messaging in a health context is not the same as texting. The content is protected health information, so it must be encrypted in transit and at rest, kept inside the portal rather than sent through ordinary email or SMS, and tied to a verified identity on both ends. Notifications that a new message is waiting should never contain the clinical content itself, only a prompt to log in and read it. These are not optional niceties. They are what separate secure messaging from a privacy incident waiting to happen.

Routing and triage

The difference between messaging that works and messaging that drowns a practice is routing. A message about a billing question should not land in a nurse's clinical queue. A message describing a possible emergency needs to be caught and redirected immediately. Good portals ask a patient a simple question or two up front to route the message to the right team, and they make it unmistakable that the portal is not for emergencies and that anyone facing one should call emergency services.

• Category selection so a message reaches billing, scheduling, or clinical staff correctly.
• Emergency warnings shown clearly before a message is sent.
• Response time expectations so patients know when to expect a reply and do not send duplicates.
• Assignment and status on the staff side so nothing falls through the cracks.

Keeping the staff side workable

In our experience building for busy practices, the patient facing message box is the easy half. The hard half is the staff experience: a shared queue, clear ownership of each thread, the ability to reassign, and a way to close the loop so a patient knows their question was answered. If the staff tools are weak, messages pile up, replies slow down, and patients lose trust in the whole portal. We treat the staff console as a first class part of the messaging feature, not an afterthought bolted on at the end.

Attachments and history

Patients often want to send a photo or a document with a message, and clinicians sometimes need to share instructions back. Handling attachments securely, scanning them, and storing them against the right record adds work but greatly increases the usefulness of messaging. A clear, searchable message history also matters, because both patients and staff frequently need to look back at what was said and when.

EHR integration with FHIR and HL7

A patient portal is only as good as the data behind it, and that data lives in the electronic health record. Integration with the EHR is what lets the portal show real results, real appointments, and a real medication list rather than a disconnected copy that quickly falls out of date. This is usually the most technically demanding part of a portal build, and it is where a partner who has done it before saves a great deal of time.

The two standards you will meet

Health data exchange runs on standards, and two names come up constantly. The older one is HL7 version 2, a message based standard that has moved clinical data between systems for decades. The newer one is FHIR, which stands for Fast Healthcare Interoperability Resources, a modern web friendly standard built around resources and APIs. Most new portal work targets FHIR where it is available, while still meeting older systems on HL7 version 2 where that is what they speak. You can read the official specification at hl7.org/fhir.

How integration actually happens

Common electronic health record systems, including the large hospital platforms and the systems used by independent practices, generally expose some way to connect. Increasingly that is a FHIR based API, sometimes through an app marketplace or developer program that a portal has to register with and pass review to use. In other cases integration runs through an interface engine that translates HL7 messages between systems. Which path you take depends entirely on the EHR the practice already runs, which is why the first question in any portal project is always which EHR you are connecting to.

Mapping data is the real work

Even with a modern API, the hard part is mapping. A code for a lab test in one system has to line up with how your portal labels and displays it. Identifiers for a patient in the EHR have to be matched safely to the account in your app so nobody ever sees the wrong person's data. Time zones, units, and status codes all have to be handled correctly. This mapping is careful, unglamorous work, and rushing it is how portals end up showing wrong or confusing information. Budget real time for it.

Health data on the device

Beyond the EHR, mobile platforms offer their own health data frameworks that a portal can connect to when it makes sense, such as syncing readings from a phone or wearable. Apple documents its approach for developers at developer.apple.com/health-fitness, and Google documents the Android side at developer.android.com/health-and-fitness. These are optional additions rather than core to a portal, but for the right practice they add real value, for example bringing home blood pressure or glucose readings into the picture.

Security and access control

Because a patient portal shows protected health information directly to patients, access control is not one feature among many. It is the spine of the whole product. The core question the app answers, over and over, is a simple one: is this person allowed to see this information right now. Getting that right protects patients, protects the practice, and is the difference between a portal you can trust and one you cannot.

Proving identity before granting access

Before a portal ever shows a record, it has to be confident the person logging in is who they claim to be. That starts at enrollment, where a practice verifies a patient's identity before issuing access, often tied to an in person visit or a controlled invitation process. It continues at every login with strong authentication.

• Strong authentication, including multi factor authentication so a password alone is never enough.
• Biometric login such as fingerprint or face recognition for convenient day to day access.
• Session controls that time out inactive sessions and handle lost or shared devices sensibly.
• Careful account recovery, since a weak password reset can undo every other protection.

Roles and least privilege

On the staff side, not everyone should see or do everything. A scheduler needs different access than a nurse, who needs different access than a billing clerk. Role based access control assigns each person only the permissions their job requires, following the principle of least privilege. This limits the damage if any single account is ever compromised and keeps access aligned with actual responsibilities.

Audit logs

Every meaningful action in a health system should leave a trace: who viewed a record, who released a result, who changed a permission, and when. Audit logs are both a security tool and a compliance requirement. They let a practice investigate concerns, demonstrate accountability, and detect unusual patterns of access. Building thorough logging in from the start is far easier than retrofitting it later, and regulators expect it to be there.

Proxy and caregiver access

One of the more delicate parts of access control is proxy access, where one person is authorized to act in the portal on behalf of another. A parent managing a child's care, an adult child helping an aging parent, or a caregiver for a dependent adult all need this. The rules get genuinely complicated, especially as a child ages into the years where privacy rules give them control over their own information. A portal needs a way to grant, limit, and revoke proxy access, and to change it as circumstances and law require. This is an area where the practice's policies and legal guidance drive the design.

Encryption and data protection

All of this sits on a foundation of encryption. Health data must be protected when it is stored and when it moves across a network. Sensitive information should be collected only when there is a reason to, kept only as long as it is needed, and shielded by tight controls on who and what can reach it. Data you never collect is data that can never leak, so restraint in what you gather is itself a security measure.

Compliance: HIPAA and PHIPA

Compliance is where a patient portal separates itself from an ordinary app, and it is an area where accuracy matters, because the rules differ by country and even by province or state. What follows is a general orientation, not legal advice. Any real portal project needs qualified legal counsel who knows health privacy law in the specific jurisdiction where the practice operates. With that firmly stated, here is the landscape.

HIPAA in the United States

In the United States, the central framework is HIPAA. It governs protected health information, often shortened to PHI, and it includes several parts that a portal has to respect. The Privacy Rule sets out how protected health information may be used and disclosed and establishes the patient's right to access their own records. The Security Rule sets standards for protecting health information that is stored or transmitted electronically, covering administrative, physical, and technical safeguards. The Breach Notification Rule requires notifying affected individuals and authorities when a breach of unsecured protected health information occurs.

One HIPAA concept comes up in almost every portal build: the business associate agreement, or BAA. When a practice works with a vendor that will handle protected health information on its behalf, whether that is a hosting provider, a messaging service, or a development partner that operates the system, a business associate agreement sets out each side's obligations to protect that data. If you build or run any part of a portal that touches protected health information, expect a business associate agreement to be part of the arrangement, and choose infrastructure and service providers that will sign one.

Because a portal hands protected health information straight to patients, HIPAA's right of access and its security safeguards both sit at the center of the design. The patient's right to see their records pushes toward prompt release, while the Security Rule pushes toward strong authentication, access control, and audit logging. A well built portal satisfies both at once.

PHIPA and privacy law in Canada

Canada has a different structure. In Ontario, health information is governed largely by PHIPA, the Personal Health Information Protection Act, which sets rules for how health information custodians collect, use, and disclose personal health information, and which gives patients rights over their own information. Other provinces have their own health privacy statutes that play a similar role in their jurisdictions. At the federal level, PIPEDA, the Personal Information Protection and Electronic Documents Act, governs personal information in the course of commercial activity, and it can apply depending on the organization and the province. The details of which law applies to a given practice depend on where it operates and what it does, which is exactly why local legal advice is not optional.

It is important not to blur these frameworks together. HIPAA is a United States law and does not apply in Canada. PHIPA and the other provincial acts, along with PIPEDA, are the Canadian frameworks, and they use their own terms and their own rules. A portal serving Canadian patients is built to Canadian requirements, and a portal serving American patients is built to HIPAA. A product that serves both has to satisfy each set of rules for the patients it applies to.

Building compliance into the project

The practical takeaway is the same on both sides of the border. Bring compliance in at the start, not the end. Involve legal counsel during planning so that the release policy for results, the rules for proxy access, the choice of infrastructure, and the vendor agreements are all decided before code is written around them. Document your decisions so the practice can show how it protects patients and meets its obligations. Compliance shaped into the first design is far cheaper than compliance bolted onto a finished product, and in health software the cost of getting it wrong is measured in trust as well as money.

The build process step by step

Building a patient portal app follows the familiar arc of any serious software project, with extra weight placed on the early planning and the later testing, because of everything the compliance and integration work adds. Here is how a portal project typically unfolds when it is run well.

1. Discovery and compliance mapping. Define exactly what the portal will do, which EHR it connects to, and which privacy framework applies. Bring in legal counsel and, where relevant, arrange the business associate agreement or equivalent Canadian agreements. Decide the release policy for results and the rules for proxy access with the practice.
2. Planning and scope. Choose the smallest useful first release, usually records, results, messaging, and appointment requests, and defer heavier features. Pick the integration path based on the EHR, and select infrastructure and service providers that will meet the compliance requirements.
3. Design and prototyping. Design flows in plain language for a wide range of patients, then test them with real people, paying special attention to enrollment, identity verification, and how results are presented.
4. Integration and development. Build the patient app and the staff facing tools together, wire up the EHR integration over FHIR or HL7, and bake security practices into every step rather than saving them for the end.
5. Testing and security review. Run thorough functional testing plus dedicated security testing, including an independent review of authentication, access control, and data protection. Verify that the wrong patient can never see another patient's data.
6. Pilot launch. Release to a limited group first, often a subset of patients or a single clinic, and watch closely for confusion, integration errors, and staff workload before expanding.
7. Rollout and ongoing care. Expand access, keep the portal secure and compliant as rules and systems change, and add features based on what patients and staff actually need.

Why the early and late stages carry more weight

In an ordinary app, discovery is mostly about features. In a portal, discovery also settles compliance and integration, the two things most likely to derail a project if they are discovered late. In an ordinary app, testing checks that features work. In a portal, testing also has to prove that access control holds and that no patient can ever reach another patient's information. These extra layers are exactly why portal projects need more planning and testing time than a simple consumer app, and why cutting those stages short tends to be a false economy.

Start narrow, then grow

The single most reliable way to keep a portal project on track is to resist the urge to build everything at once. A focused first release that does records, results, and messaging well, and does them safely, gets real patients using the portal sooner and teaches you what they actually want next. A sprawling first launch that tries to include real time self booking, full medication management, in app payment, and granular proxy consent from day one multiplies both the risk and the timeline. Narrow and solid beats broad and shaky every time in health software.

Timeline and team

A patient portal generally takes longer to build than a simple consumer app, because of the integration and compliance work involved. A focused first release commonly lands in the range of a few months, while a fuller portal with deep EHR integration, real time booking, billing, and payment can run considerably longer. The biggest single factor is the EHR you connect to and how its integration works, followed by how many features you include in the first release. The most effective way to shorten the path is to keep that first release narrow.

Who you need on the team

• A product strategist who understands both patient needs and the constraints of health software.
• Designers who can make clinical information clear and calm for a wide range of patients.
• Mobile and backend engineers experienced with secure, data heavy applications and health data standards.
• An integration specialist comfortable with FHIR and HL7 and with the specific EHR in play.
• A security specialist involved throughout, not brought in at the end.
• Legal and compliance advisors who know the health privacy law of the relevant jurisdiction.
• Quality assurance testers focused on both function and, critically, access control.

You do not need every role working full time for the whole project, but you do need genuine access to each skill. The health data, integration, security, and compliance expertise is what separates a team that can build a portal from a general app team that will learn these lessons the expensive way. In our work with a US gastroenterology practice on retainer, having that mix of skills available on an ongoing basis is what keeps the portal current as the EHR, the rules, and the practice's needs all shift over time.

What drives the timeline

If you want a realistic sense of how long your specific portal will take, the honest answer is that it depends on scope, and the only accurate number is a quote for your exact idea. An MVP costs far less and ships far sooner than a full build. Getting a quote is free and never hurts, and you can see how we structure engagements on our pricing page or start a conversation from the quote form. You own the code we write, there is no lock in, and the work is done by senior engineers rather than handed off.

Common challenges

Portal projects run into a recognizable set of difficulties. None of them should scare you off, but knowing them in advance lets you plan around them instead of being caught out midway through.

Underestimating EHR integration

The most common surprise is how much work the EHR connection turns out to be. Teams assume a modern API means plug and play, then discover that mapping codes, matching patients safely, and handling the quirks of a specific system takes real time and care. Naming the EHR and understanding its integration path in the very first week is the best defense. If your development partner cannot speak clearly about FHIR, HL7, and the specific system you run, that is a warning worth heeding.

Getting results release wrong

Release timing is a genuine balancing act. Release too slowly and you frustrate patients and risk running against their right of access. Release too fast, with no context, and you hand people frightening raw data with no one to explain it. The answer is a configurable policy, decided by the practice and its counsel, that treats different result types appropriately and attaches provider context where it helps. Building that flexibility in from the start avoids a painful rework later.

Overwhelming the staff

A portal that delights patients but buries staff is not a success, because the staff experience determines whether messages get answered and results get released on time. Weak staff tooling is one of the most common reasons portals disappoint after launch. Treating the staff console as a first class product, with good queues, routing, and clear ownership, is what keeps the whole system healthy.

Identity and proxy access complexity

Verifying identity at enrollment and managing proxy access are harder than they first appear, especially the rules around minors and the transition as a child gains control of their own information. These edge cases multiply quickly. The practical approach is to build flexible controls, lean on the practice's policies and legal guidance, and accept that this area needs careful thought rather than a quick default.

Keeping up as rules and systems change

Health privacy rules evolve, EHR platforms update their APIs, and security threats never stop shifting. A portal is never truly finished. Ongoing investment in security, compliance, and integration maintenance is simply the cost of running one responsibly over the long term. This is one reason a number of practices keep a development partner on retainer rather than treating the portal as a one time build, so there is always someone ready to adapt it as the ground moves.

Choosing the right partner

Because a patient portal carries so much weight around privacy, security, and integration, who you build it with matters more than in most categories. A partner who has shipped health software before will know the questions to ask, the standards to follow, and the mistakes to avoid. During early conversations, notice whether they raise compliance, access control, and EHR integration on their own or wait for you to bring them up. A team that treats these as central from the first meeting understands what building a patient portal app actually requires.

None of these challenges is a reason to hold back. A patient portal is demanding precisely because it touches people's health and their most private information, and that same difficulty is what protects a well built portal from careless competition. Plan for the hard parts, bring in the right expertise, start with a focused first release, and you will build something patients trust and staff can actually run. When you are ready, tell us about your idea and we will map out a realistic plan together through our contact page.