How to test a patient portal

Direct answer

Shipped untested, a patient portal routes a medical records request to a general inbox nobody owns, so the record is released late, which can count as information blocking, and shows lab results and appointment slots a blind patient cannot read or select, in the records and booking flows. 8 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with end-to-end functional tests: a records request, a secure message and a proxy invitation must each reach the right staff queue or account, and a revoked proxy must lose access to results.

8 mandatory testsfirst: end-to-end functional tests

What counts as a patient portal

A patient portal here means the web and mobile front door where patients view records and results, book appointments, message their care team and request records, often with proxy access for guardians and caregivers. It counts when the portal shows PHI from a provider's record system. The clinician-facing record system itself is out of scope, and so is an app that runs live video visits.

Adjacent product types not covered here

  • electronic health record system: The record system is used by clinicians and carries order routing and downtime risks, while the portal carries proxy access and tracking tags on patient-facing pages.
  • telemedicine app: A telemedicine app runs live visits and prescribes, adding appointment-slot load and controlled-drug refill risks the portal does not carry.
  • pharmacy delivery app: A pharmacy delivery app takes card payments and dispenses medicine, while the portal has no bill pay and moves records and messages.

Risk map

4 risks attached to patient portal with evidence. Sorted by severity.
RiskGradeNoteEvidence
Accessibility complaint or lawsuit
accessibility-liability
legalprimaryA blind patient cannot read a lab result rendered as an image or pick an appointment slot from the calendar with a keyboard.
Fine or enforcement by a regulator
regulatory-penalty
legalprimaryA request for medical records sent through the portal lands in a general inbox nobody owns, and the record is released late, which can count as information blocking for a portal on certified health IT.
Personal or sensitive data exposed
data-breach
dataprimaryA proxy link set on the wrong account lets an unrelated adult read a child's visit summaries, and a pixel on the signed-in results page reaches an ad network.
User actions lost on bad networks or devices
lost-actions
trustsecondaryA secure message to the care team shows as sent in the portal but never reaches the clinician's inbox or the chart, so the symptom it reports goes unanswered.

Mandatory tests (8)

  1. Step 1: release smoke tests

    Why:lost-actions

    Done when: After each release, a test patient signs in, views a test result, sends a message and sees it arrive in the test clinician's inbox.

    Tool class: browser automation. Who usually runs it: QA engineer.

  2. Step 2: end-to-end functional tests

    Why:lost-actionsregulatory-penaltydata-breach

    Done when: A records request, a secure message and a proxy invitation each reach the right staff queue or account, and a revoked proxy can no longer open the patient's results.

    Tool class: browser automation. Who usually runs it: QA engineer.

  3. Step 3: analytics and event tracking tests

    Why:data-breachregulatory-penalty

    Done when: A network capture of sign-in, results, messages and appointment pages shows no request to an advertising or analytics domain carrying a name, result, page path or signed-in flag.

    Tool class: proxy. Who usually runs it: QA engineer.

  4. Step 4: accessibility testing

    Why:accessibility-liability

    Done when: A screen reader user signs in, reads a lab result, books an appointment and sends a message without sighted help.

    Tool class: accessibility checker. Who usually runs it: accessibility specialist.

  5. Step 5: compliance checks

    Why:regulatory-penalty

    Done when: A reviewer confirms that a records request made through the portal is logged with a due date and that a test patient can download their record in a standard format.

    Tool class: test management. Who usually runs it: product manager.

  6. Step 6: security scanning

    Why:data-breach

    Done when: The scan report for the portal web app, mobile apps and API lists no open high-severity finding that exposes results, messages or proxy documents on the release date.

    Tool class: DAST scanner. Who usually runs it: security specialist.

  7. Step 7: penetration testing

    Why:data-breach

    Done when: A tester signed in as one patient or proxy cannot open another patient's results, messages or documents by changing an ID or replaying a link.

    Tool class: proxy. Who usually runs it: security specialist.

  8. Step 8: integration tests

    Why:lost-actions

    Done when: Every message type sent from the portal appears in the EHR inbox for the right care team and is filed to the patient's chart.

    Tool class: API client. Who usually runs it: developer.

Recommended and optional tests

  • exploratory testingrecommended

    Becomes mandatory when staff assign proxy access by hand or adolescents get their own accounts.

  • data integrity and migration testingrecommended

    Becomes mandatory when the portal moves to a new record system or migrates message history.

  • resilience and failure testingrecommended

    Becomes mandatory when the record system behind the portal has planned or unplanned downtime during patient hours.

  • performance and load testingrecommended

    Becomes mandatory when results release in batches and patients sign in together after a notification.

  • device and browser compatibilityrecommended

    Becomes mandatory when analytics show a large share of patients on older phones or browsers.

  • unit testsoptional

    May help on the rules that decide which results a proxy or adolescent account can see.

  • regression suiteoptional

    May help once portal releases follow the record system's upgrade schedule.

  • usability testingoptional

    May help when patients phone the clinic because they cannot find results or the message form.

Not needed and why

  • localization testing

    Not needed while the portal serves one language. Becomes recommended when a second language is offered to patients.

  • offline and poor-network testing

    Not needed while every portal action is online and refused when offline. Becomes recommended when the mobile app queues messages for later sending.

  • payment and money-flow testing

    Not needed while the portal has no bill pay. Becomes recommended when patients can pay statements or copays in the portal.

Order of work

First release

  1. release smoke tests: Sign in as a test patient, view a test result, send a message and confirm it arrives in the test clinician's inbox.
  2. end-to-end functional tests: Send a records request, a secure message and a proxy invitation, confirm each reaches the right staff queue or account, then revoke the proxy and check it can no longer open results.
  3. analytics and event tracking tests: Capture network traffic on sign-in, results, messages and appointment pages and look for any name, result, page path or signed-in flag sent to an advertising or analytics domain.
  4. accessibility testing: Have a screen reader user sign in, read a lab result, book an appointment and send a message without sighted help.
  5. compliance checks: Make a records request through the portal and confirm it is logged with a due date, then download a test patient's record in a standard format.
  6. security scanning: Scan the portal web app, mobile apps and API and clear every open high-severity finding that exposes results, messages or proxy documents before the release date.
  7. penetration testing: Sign in as one patient or proxy and try to open another patient's results, messages or documents by changing an ID or replaying a link.
  8. integration tests: Send every message type from the portal and confirm each lands in the EHR inbox for the right care team and is filed to the patient's chart.

Ongoing cadence

Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of patient portal (web, ios, android). Not recommendations.

38 tools shown

release smoke tests

  • Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
  • TestRailTest case and run management. webiosandroidapicommercial
  • XrayTest management inside Jira. webiosandroidapicommercial

end-to-end functional tests

  • AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • CypressBrowser-based end-to-end testing with a visual runner. webfreemium
  • DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
  • EspressoAndroid UI testing framework from Google. androidopen-source
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • MaestroMobile UI flows written in YAML. iosandroidfreemium
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source
  • XCTestApple's framework for unit and UI tests. iosopen-source

analytics and event tracking tests

  • AvoTracking plan and event validation. webiosandroidfreemium
  • Segment ProtocolsTracking plan validation for Segment events. webiosandroidcommercial

accessibility testing

  • Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
  • axe-coreAccessibility rules engine for automated checks. webopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • Pa11yCommand-line accessibility testing. webopen-source

security scanning

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium
  • mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
  • MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
  • OWASP ZAPDynamic application security scanner. webapiopen-source
  • SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
  • SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium

penetration testing

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium

integration tests

  • Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
  • JestJavaScript test runner with mocking and snapshots. webapiopen-source
  • JUnitTest framework for the JVM. apiandroidopen-source
  • VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
  • XCTestApple's framework for unit and UI tests. iosopen-source

performance and load testing

  • ArtilleryLoad testing with YAML scenarios. apiwebfreemium
  • GatlingLoad testing with Scala, Java or Kotlin scenarios. apiwebfreemium
  • JMeterLoad testing tool from the Apache Foundation. apiwebopen-source
  • k6Load testing scripted in JavaScript. apiwebopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • LocustLoad testing scripted in Python. apiwebopen-source

device and browser compatibility

  • AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source

What to send to the person who will test

Send the checklist and the brief below. The printable checklist for patient portal has the same 8 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the patient portal is accepted when a records request, a secure message and a proxy invitation each reach the right staff queue or account, and every portal message appears in the EHR inbox for the right care team. A revoked proxy cannot open the patient's results, and no request from signed-in pages carries a name, result or signed-in flag to an advertising or analytics domain.

Brief

# Test brief: patient portal

Product type: patient portal. Patient-facing access to records, appointments and messages.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/patient-portal/
Printable checklist: https://howtotestaproduct.com/checklists/patient-portal/

Run these 8 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: lost-actions). Tool class: browser automation. Usually run by: QA engineer.
   Done when: After each release, a test patient signs in, views a test result, sends a message and sees it arrive in the test clinician's inbox.
2. end-to-end functional tests (risks: lost-actions, regulatory-penalty, data-breach). Tool class: browser automation. Usually run by: QA engineer.
   Done when: A records request, a secure message and a proxy invitation each reach the right staff queue or account, and a revoked proxy can no longer open the patient's results.
3. analytics and event tracking tests (risks: data-breach, regulatory-penalty). Tool class: proxy. Usually run by: QA engineer.
   Done when: A network capture of sign-in, results, messages and appointment pages shows no request to an advertising or analytics domain carrying a name, result, page path or signed-in flag.
4. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist.
   Done when: A screen reader user signs in, reads a lab result, books an appointment and sends a message without sighted help.
5. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: product manager.
   Done when: A reviewer confirms that a records request made through the portal is logged with a due date and that a test patient can download their record in a standard format.
6. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The scan report for the portal web app, mobile apps and API lists no open high-severity finding that exposes results, messages or proxy documents on the release date.
7. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist.
   Done when: A tester signed in as one patient or proxy cannot open another patient's results, messages or documents by changing an ID or replaying a link.
8. integration tests (risks: lost-actions). Tool class: API client. Usually run by: developer.
   Done when: Every message type sent from the portal appears in the EHR inbox for the right care team and is filed to the patient's chart.

Acceptance criteria wording:
A release of the patient portal is accepted when a records request, a secure message and a proxy invitation each reach the right staff queue or account, and every portal message appears in the EHR inbox for the right care team. A revoked proxy cannot open the patient's results, and no request from signed-in pages carries a name, result or signed-in flag to an advertising or analytics domain.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

Questions about testing a patient portal

What testing does a patient portal need?

8 mandatory tests cover the 4 risks in the map: proxy and tracking-tag exposure, late records requests, results and calendars blind patients cannot use, and secure messages that never reach the clinician. They run as release smoke, end-to-end, analytics tracking, accessibility, compliance, security scanning, penetration and integration tests. Exploratory testing of proxy combinations becomes mandatory when staff assign proxy access by hand or adolescents get their own accounts.

What does HIPAA mean for testing a patient portal?

The risk map cites the information blocking enforcement alert, not a HIPAA rule, for records requests: a request that lands in an unowned inbox and is released late can count as information blocking for a portal on certified health IT. The mandatory compliance check confirms a portal records request is logged with a due date and that a test patient can download their record in a standard format. It applies while the portal is run by or for a HIPAA covered entity or on certified health IT.

Which tests in a vendor test plan for a patient portal are not needed?

Localization, offline and payment tests are marked not needed while the portal serves one language, refuses actions offline and has no bill pay. Payment testing becomes recommended when patients can pay statements or copays in the portal.

How is the audit trail tested in a patient portal?

The compliance check confirms each records request made through the portal is logged with a due date. The integration test confirms every message type sent from the portal is filed to the patient's chart in the record system, so the care team's record shows what the patient sent.

What should I send to the person who will test a patient portal?

Send the 8 mandatory tests with their done conditions, test patient accounts including guardian and caregiver proxies, and access to the test clinician's EHR inbox. Include the list of third-party tags and SDKs on signed-in pages for the analytics tracking test.

Evidence

  1. ev-0016standardprimary

    Web Content Accessibility Guidelines (WCAG) 2.2, W3C

    WCAG 2.2 is the W3C standard that accessibility law and procurement rules reference; level AA is the usual target.

    published undated · verified 2026-10-07

  2. ev-0081regulatorprimary

    Enforcement Alert, Assistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

    Information blocking enforcement alert: developers of certified health IT that interfere with access, exchange or use of electronic health information face civil money penalties from OIG. Supports regulatory-penalty for EHR systems and for patient portals that sit on certified health IT and must release records to patients and other systems.

    published 2025-09-04 · verified 2026-10-07

  3. ev-0124post-mortemprimary

    Privacy Matter | Kaiser Permanente, Kaiser Permanente

    Certain online technologies (commonly known as cookies or pixels) installed on our websites and mobile applications may have transmitted personal information to our third-party vendors Google, Microsoft Bing, and X (Twitter)

    Official notice from a health system: pixels on its member websites and apps sent names, signed-in status, navigation and health encyclopedia searches to ad and search companies. Supports data-breach for patient portals, where the signed-in state itself reveals that the person is a patient.

    published 2024-05-06 · verified 2026-10-07

  4. ev-0125post-mortemprimary

    Breach Name: Inappropriate Access (notification letter, reference 23-045KV), University of Rochester Medical Center

    The other patient who viewed your MyChart account was assigned in error.

    Official breach notification: an unrelated patient was set as proxy on a minor's portal account and could read the child's appointments, messages and visit summaries until the proxy reported it. Supports data-breach for patient portals with proxy or guardian access.

    published 2023-03-23 · verified 2026-10-07

  5. ev-0142regulatorprimary

    Proposed FTC Order will Prohibit Telehealth Firm Cerebral from Using or Disclosing Sensitive Data for Advertising Purposes, and Require it to Pay [amount], U.S. Federal Trade Commission

    The FTC complaint describes pharmacy and prescription information sent to third parties through tracking tools, a patient portal access method that exposed medications to other patients, a failure to block former employees from accessing medical records, and a cancel-anytime promise contradicted by a multi-step, often multi-day cancellation process during which consumers kept being charged. The first two transfer to pharmacy delivery apps; the cancellation finding transfers to any recurring subscription sold online.

    published 2024-04-15 · verified 2026-10-07

  6. ev-0127regulatorsecondary

    Healthcare Inspection - Poor Follow-Up Care and Incomplete Assessment of Disability, VA San Diego Healthcare System San Diego, California, U.S. Department of Veterans Affairs, Office of Inspector General

    Government inspection report: a patient's secure messages to his primary care provider through the VA patient portal were mostly not reflected in the health record, and OIG recommended guidance on what portal messages must be documented. Supports lost-actions for patient portals whose messages do not land in the chart.

    published 2016-01-05 · verified 2026-10-07

  7. ev-0128regulatorsecondary

    Care Coordination Deficiencies after the New Electronic Health Record Go-Live at the Mann-Grandstaff VA Medical Center in Spokane, Washington, U.S. Department of Veterans Affairs, Office of Inspector General

    Patient portal and secure messaging being inaccessible

    Government inspection report listing an inaccessible patient portal and secure messaging among the care coordination problems after an EHR go-live. Supports lost-actions for patient portals that depend on the record system behind them, and for EHR systems whose go-live cuts the portal off.

    published 2022-03-17 · verified 2026-10-07

Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.