Patient portals give patients one secure place to see their records, message the care team, book visits, pay bills and download their data. For a health system or a digital health company, the portal is often the software patients use most, and also the one that exposes every data quality problem upstream.
This guide covers what a portal has to do, how proxy access and test result release work in practice, how a portal connects to the EHR, and where portal projects tend to stall.
What is a patient portal and what must it do?
Planning a patient portal build?
Agnotic designs and builds patient portals that connect to the client's EHR, with proxy access, messaging and result release planned in.
A patient portal is a secure web or mobile application where patients view their health records, test results and appointments, message their care team and complete forms. For certified EHRs, the portal is also where patients exercise View, Download and Transmit, so it must show the data the EHR is certified to provide.
Portals serve two very different users. Patients want a short path to one task, such as a result or a refill. Care teams want fewer phone calls, and messages that arrive with enough context to act on. A portal that serves only one side ends up unused by the other.
Which features belong in the first portal release?
The first release should cover the tasks patients already phone the practice about: results, appointments, messages, refills, forms and bills. Anything beyond that core can wait until usage data shows what patients look for.
- Records and results: Problems, medications, allergies, immunizations, visit notes and lab results, read from the EHR rather than copied into a separate store.
- Secure messaging: Threads routed to a care team pool, with attachments, a stated response time and a prompt that sends urgent symptoms to the phone instead.
- Scheduling: Self-scheduling for the visit types the practice allows, with rules for new versus existing patients and for visits that need a referral.
- Forms and intake: Pre-visit questionnaires, consent forms and insurance card upload, filed back to the chart as structured data where the EHR accepts it.
- Refills and billing: Refill requests that land in the prescriber's queue, plus statements, online payment and payment plans.
- Download and share: A way to download records and send them to another provider or app, which certified EHRs must offer.
Each feature has an owner in the clinic. Messaging needs a staffing model, scheduling needs template rules, and refills need a protocol. Build a feature only when its clinic owner has agreed how it will run, or plan to ship it switched off.
How does View, Download and Transmit work?
View, Download and Transmit is the ONC certification criterion at 45 CFR 170.315(e)(1). It requires a certified EHR to let patients and their authorized representatives view their health information online, download it, and transmit it to a third party they choose.
For a portal team, the criterion settles three practical questions. The data set is the standard summary the certified product produces, so the portal should show those data classes rather than a smaller hand-picked set. The formats are a human-readable view and a structured document that a receiving system can parse. The destination is chosen by the patient, not by the organization.
A custom portal that sits on a certified EHR is usually not certified itself, but it should not hide what the EHR offers. A common approach is to build the patient experience custom and link to, or embed, the EHR's own download and transmit functions, so the certified path stays intact.
How should proxy access work?
Proxy access should give each caregiver their own login, linked to the patient's record with a defined scope and an end date. Shared passwords hide who did what and make it impossible to remove one person without locking out everyone else.
The HIPAA personal representative rule, 45 CFR 164.502(g), generally treats a person with legal authority to make health care decisions for a patient as the patient for the relevant records, with exceptions such as suspected abuse. State law decides who holds that authority, which matters most for minors.
- Parents of young children: Full proxy access, granted after identity and relationship checks, and reviewed as the child grows.
- Adolescents: Many states let minors consent to some services on their own, so adolescent records often need segmented access in which the parent sees scheduling and billing but not confidential notes.
- Adult caregivers: Access granted by the patient, with a scope the patient picks, such as messages and appointments only.
- Legal representatives: Access backed by a document such as a health care power of attorney, stored with its type and any expiry.
Age is the usual failure point. When a child reaches an age at which state law changes the rules, the portal should narrow the proxy's scope automatically and notify both parties. Without that scheduled job, parents keep access they no longer hold.
When should test results appear in the portal?
Test results should generally appear in the portal once they are final. Under 45 CFR Part 171, holding back or slowing a patient's access to their electronic health information can count as information blocking unless an exception covers it, and the exceptions are narrow, such as a documented risk of harm to a specific patient.
That rule changes the clinical workflow more than the software. Patients may read an abnormal result before the clinician has called them. Portals handle this with plain-language result screens, reference ranges, a clear note that the care team will follow up, and a message button tied to the ordering clinician's pool.
Some patients prefer to hear from the clinician first. A setting that lets a patient choose to see results only after review puts that choice with the patient, instead of an organization-wide hold.
How does a portal connect to the EHR?
A portal connects to the EHR through the vendor's patient-facing APIs, an integration engine, or both. Reads usually go through FHIR. Booking, messaging and refills need a write path, usually vendor-specific APIs or an HL7 v2 interface, since the certified patient API only reads.
- Identity: The portal account links to the EHR patient record through a verified match, never through name and date of birth alone.
- Reads: FHIR R4 calls for records and results, cached briefly and shown with a last-updated time.
- Writes: Booking, message filing and refill requests through vendor write APIs or HL7 v2 messages, each with an acknowledgment the portal checks.
- Documents: Forms and uploads filed to the chart as documents with the right type, so staff can find them later.
- Events: Notices for new results or replies driven by EHR events, not by polling every few minutes.
Identity proofing is the step teams underestimate. When a patient signs up, the portal must find the right chart, and a wrong match exposes someone else's record. Use an activation code issued at a visit, or remote identity proofing that matches demographics and checks a second factor.
Where patient portal projects stall
Portal projects rarely fail on the interface. They stall on activation, staffing and data, and each of these failure points can be tested before launch.
- Activation: Accounts are created but never used, because the sign-up path needs a code the patient never received.
- Message volume: Messaging opens to every patient with no routing rules or staffing plan, so inboxes fill and replies slip.
- Duplicate portals: Each hospital, lab or specialty runs its own portal and login, and patients give up on all of them.
- Accessibility: Screens fail keyboard and screen reader tests, shutting out patients and creating legal exposure for providers that take federal funds.
- Proxy drift: Proxy access has no expiry or age rules, so people keep access after their authority ends.
- Stale data: Records are cached for hours, so a patient sees yesterday's medication list after a change.
- Phone screens: A desktop layout is squeezed onto phones, which makes common tasks slow on the device patients carry.
Should you build a custom portal or use the EHR's?
Use the EHR vendor's portal when one EHR holds the patient relationship and its portal covers the tasks you need. Build custom when patients deal with several systems, when the portal is the main surface of a digital health product, or when the vendor portal cannot support a key workflow.
- One EHR, standard workflows: The vendor portal, configured well, is usually the faster path.
- Several EHRs or practice systems: A custom portal that brings records and tasks into one login.
- Digital health product: A custom portal, because the portal is the product patients see.
- Hybrid: A custom front end for scheduling, intake and education, with links into the vendor portal for records.
How Agnotic can help
A portal earns its place when activation, routing and identity work on day one. Agnotic Technologies builds patient portals for providers and digital health companies: the patient experience on web and mobile, EHR integration through FHIR and vendor APIs, proxy models that follow the client's state rules, and result screens patients can read.
The client's clinical and compliance leaders set the rules for messaging, proxies and result release. Agnotic turns those rules into configuration and tests, so a policy change becomes a settings update rather than a new release.
Build a patient portal people activate and use
See how Agnotic approaches patient portal builds, or browse more guides for healthcare product teams.
Related reading on Agnotic
Continue with patient engagement tools, healthcare UX, US Core data and healthcare software development.
