Patient portal testing services

What breaks in a patient portal that does not break in the rest of your estate?

The assumption that the operator was trained. Every other class of health software you own is driven by staff the organisation selected and onboarded, on equipment it issued, with somebody down the corridor to ask. A patient portal is driven by the person the record is about, on whatever device they already have, and there is no second attempt once they give up. A defect a clinician routes around silently becomes abandonment here, and the result the patient was meant to read stays unread.

The identity path takes the first hit, because it is walked once, by someone who has never seen it, using details a registration clerk typed months earlier. Each branch in that path is somewhere a patient can be stranded: the activation code has expired, the date of birth on the form disagrees with the record, the address on file belongs to a spouse, the phone that receives the second factor was replaced after discharge. A portal that locks out the patient it was built for has failed clinically as well as commercially, and every unit test can still be green. Person or entity authentication at section 164.312(d) of the HIPAA Security Rule is a required standard with no implementation specifications under it, and it asks you to verify that whoever seeks access is the one claimed, which makes the obligation coverage of every route into the account rather than a named factor on one of them.

Delegated access is where the access-control defects gather, and the reason is that the rule governing it says less than portal teams believe it says. section 164.502(g)(1) of the HIPAA Privacy Rule carries the whole of the effect: a covered entity must "treat a personal representative as the individual for purposes of this subchapter". It never says who qualifies. A case-insensitive search of the definitions at 45 CFR 164.501 and 45 CFR 160.103 returns no occurrence of "personal representative", of "emancipated" or of "in loco parentis", and the numeral 18 and the phrase "age of majority" appear nowhere in 164.501, 164.502, 164.508, 164.514, 164.524, 164.526 or 164.528. Each of those terms is qualified where it does appear by "under applicable law". There is no federal age at which a parent loses a child's portal account, so whatever age a product enforces came from a state statute, from case law, or from somebody's recollection, and the code cannot tell you which.

Three consequences follow, and each of them is testable. section 164.502(g)(2) limits an adult's representative to the information relevant to that representation, so authority granted over a single decision does not reach the whole chart and an all-or-nothing proxy switch cannot express the difference. Under section 164.502(g)(3)(i) a parent, guardian or person acting in loco parentis is the representative of an unemancipated minor by default, and the three situations that displace them attach to a health care service rather than to the minor's record, so the same minor can have a parent as representative for one encounter and not for the encounter beside it. Then section 164.502(g)(3)(ii) defers outward in both directions: state or other law, "including applicable case law", may independently permit disclosure to a parent or prohibit it. A single national configuration of adolescent proxy access is unreachable from the regulation, which makes eligibility a variable in the product rather than a constant in the code.

The Security Rule still runs underneath all of this. section 164.312(a)(1), Access control reaches "those persons or software programs that have been granted access rights", so the delegation table sits inside the standard, and section 164.312(b), audit controls decide whether anyone can say afterwards which of two people opened the chart.

Then there is the record itself, which the portal does not own. The portal is a window onto data held somewhere else, and a window misinforms without ever erroring: a result released to the clinician and not yet to the patient, a medication stopped at the last visit and still listed, an ordering by receipt time where the source orders by collection time, an amended note whose original is still on screen. None of that raises an exception, so nothing in the pipeline reports it. The check is a comparison between what the source system holds and what the screen renders, for the same patient, at the same moment. What breaks on the far side of that comparison is covered in EHR and EMR testing.

Which rules actually reach a patient portal?

Accessibility law reaches it in a way it reaches no other product class on this site, and HIPAA reaches it from two directions at once. A portal's users are the general public, so the instruments written for public-facing digital services apply to it directly rather than by analogy. HIPAA itself is several rules inside one part: subpart C of 45 CFR part 164 is the Security Rule and governs the safeguards on electronic data, subpart E is the Privacy Rule and runs 164.500 through 164.535, and subpart D is the Breach Notification Rule. A scope that opens with "HIPAA requires" is usually wrong at the level of detail it needs to be right at, because the subparts oblige different parties to different things.

US federal instruments that reach a patient portal, showing which WCAG version and level each accessibility rule adopts and what the HIPAA rules require.

Instrument	What it puts on a patient portal
HHS section 504, 45 CFR part 84 subpart I	WCAG 2.1 Level A and AA, the 5 June 2018 publication, for any recipient of HHS federal financial assistance, public or private, from 11 May 2027 at fifteen or more employees and 10 May 2028 below fifteen
ADA title II, 28 CFR part 35 subpart H	The same version and level, reaching a vendor only through the public entity's duty over content it makes available through a contractual or licensing arrangement, from 26 April 2027 at a total population of 50,000 or more
ACA section 1557, 45 CFR 92.204(b)	Websites and mobile apps to comply with section 504 as interpreted consistent with ADA title II, naming no WCAG version at all, effective 5 July 2024
Medicaid managed care, 42 CFR 438.10(a)	"Readily accessible" defined by WCAG 2.0 AA "and successor versions", the one hook that follows W3C forward instead of freezing
ONC certification, 45 CFR 170.204(a)	WCAG 2.0 of 11 December 2008, cross-referred only at 170.315(e)(1)(i), at Level A with Level AA as an alternative demonstration
HIPAA Security Rule, 45 CFR 164.312	Access control, audit controls, integrity, person or entity authentication and transmission security over the data the portal displays
HIPAA Privacy Rule, 45 CFR part 164 subpart E	Who counts as a personal representative under 164.502(g), the individual's right of access at 164.524, amendment at 164.526, and an accounting of disclosures at 164.528

The version and the level differ by instrument, and a customer who writes "WCAG 2.1 AA" into a contract is usually quoting one row of that table without knowing which. The certification row misleads a portal team most often, because a certificate looks like accessibility evidence and covers an older version at a lower level. The programme publishes the answer either way: under section 170.523(f)(1)(xi) an ONC-ACB reports the standard used for the accessibility-centered design criterion to the Certified Health IT Product List, and a developer that applied none is listed as having applied none. Which instrument reaches a given company, and what each one does to the scope of a claim, is worked through in WCAG 2.1 Level AA accessibility requirements.

The safeguards side runs on the same screens. The data a portal renders is electronic protected health information, so the technical safeguards at 45 CFR 164.312 apply to it and to every environment holding a copy of it, which is why how PHI is handled and what is signed before a test team starts is settled ahead of the work. The Privacy Rule row does something different: it states outcomes and reserves decisions to people. A search across 164.501, 164.502, 164.508, 164.514, 164.524, 164.526, 164.528, 164.402 and 164.404 returns no occurrence of "portal", "proxy", "encrypt", "password" or "multi-factor", so an authentication or encryption requirement attributed to the Privacy Rule has been attributed to the wrong subpart. The clause-level reading of the safeguards is in HIPAA testing requirements for software.

Which patient rights does the portal execute on the organisation's behalf?

Three of them: access to a copy under section 164.524, amendment under section 164.526, and an accounting of disclosures under section 164.528. They carry more weight than their share of a backlog suggests, because section 164.502(a)(2) compels a covered entity to disclose in exactly two situations, and the first is "To an individual, when requested under, and required by 164.524 or 164.528". Almost everything else the Privacy Rule does is permission, and the compulsion lands on your screens. A personal representative carries these rights as well, because 164.502(g)(1) treats them as the individual "for purposes of this subchapter", so every delegation defect above reappears here as a rights defect.

Each right runs on its own clock, and the three clocks are routinely conflated.

HIPAA Privacy Rule deadlines for access, amendment and accounting of disclosures under 45 CFR 164.524, 164.526 and 164.528, and what a portal must do.

Right	Deadline in the rule	What the product has to be able to do
Access to a copy, 164.524	30 days from receipt, one extension of no more than 30 days, the extension notified in writing inside the first 30	Produce the copy in the electronic form and format requested, where that is readily producible
Amendment, 164.526	60 days from receipt, one extension of no more than 30 days	Identify every affected record in the designated record set, then append or link the amendment
Accounting of disclosures, 164.528	60 days from receipt, one extension of no more than 30 days, the first accounting in any 12 month period free of charge	Hold the four elements 164.528(b)(2) requires for each accountable disclosure, including disclosures made by business associates

The scope of all three is the designated record set, and the definition at 45 CFR 164.501 is wider than a portal team expects. Its third limb covers records "Used, in whole or in part, by or for the covered entity to make decisions about individuals", and "record" is defined as "any item, collection, or grouping of information that includes protected health information and is maintained, collected, used, or disseminated by or for a covered entity". A risk-scoring table, a triage queue or a care-management workflow store sits inside that definition, and "maintained by or for" puts a vendor-hosted store in scope alongside the customer's own. section 164.524(e) then turns the boundary into an artefact: the covered entity documents the designated record sets that are subject to access, and the titles of the persons or offices responsible for processing the requests. On a product with several data stores, drawing that inventory is harder than serving any single request.

Form and format is where a portal fails a right it believes it satisfies. section 164.524(c)(2)(ii) requires that where the information is maintained electronically and an electronic copy is requested, the copy be provided "in the electronic form and format requested by the individual, if it is readily producible in such form and format", with the fallback a readable electronic form agreed with the individual rather than paper. "Readily producible" is a property of your system, and it moves when your system moves. A product whose only export is a rendered document has narrowed the test by construction, and the export path is usually the least exercised screen in the estate.

A representative's request travels a different path from the patient's own, and section 164.524(a)(3)(iii) is where the two diverge: access may be denied where the request comes from the individual's personal representative and a licensed health care professional has determined, in the exercise of professional judgment, that providing it is "reasonably likely to cause substantial harm to the individual or another person". No other requester has that ground standing against them. A proxy feature that routes a representative's request down the same code path as the patient's has deleted a distinction the regulation draws. The denial is then reviewable: under 164.524(a)(4) and 164.524(d)(4) the review falls to a licensed health care professional designated by the covered entity who did not participate in the original decision, and the entity must provide or deny access in accordance with that determination. Denial is a state machine with a mandatory second-reviewer transition, and a portal that models it as a boolean does not have one. 164.524(d)(1) adds that the entity must give access "to the extent possible" to the rest of the requested information after excluding what it may withhold, which makes an all-or-nothing denial a defect on its own.

Amendment is append and link, and a product that implements it as an update in place has implemented something else. section 164.526(c)(1) requires the covered entity to make the amendment "by, at a minimum, identifying the records in the designated record set that are affected by the amendment and appending or otherwise providing a link to the location of the amendment". Two capabilities sit inside that sentence: enumerate every affected record across every store, and attach without overwriting. section 164.526(c)(3) then pushes the amendment outward on a reasonable-efforts standard, to persons the individual names and to persons the entity knows hold the information and could foreseeably rely on it, business associates included. A denied amendment carries its own machinery: under 164.526(d) the individual may submit a written statement of disagreement, the entity may write a rebuttal, the request, the denial and both statements are appended or linked to the designated record set, and any subsequent disclosure of the information the disagreement relates to has to carry that material or an accurate summary of it.

The accounting right is the one most often claimed and least often built. section 164.528(a)(1) gives the individual six years of disclosures and then excludes nine categories, beginning with treatment, payment and health care operations and continuing through disclosures to the individual, incidental disclosures, authorized disclosures, and disclosures made as part of a limited data set. What survives those exclusions is a narrow class. An access log answers a different question, because it records uses inside the system, and 164.528(b)(1) extends the accounting to disclosures made by business associates, so that data has to cross the vendor boundary well inside the sixty days.

The text above is what binds today. A proposed rule at 86 FR 6446 of 21 January 2021 would modify the Privacy Rule, including the right of access, and it was still unfinalised on 14 January 2026, when HHS published notice of a tribal consultation on it. A scope written now is written against the current text.

What has to be exercised that a clinician-facing suite never covers?

The paths a first-time user walks exactly once. A suite that signs in as an already-enrolled test account skips the part of the product a patient cannot retry.

Delegated access is tested as a matrix rather than as a feature. The axes are the legal basis for the delegation, the health care service the information belongs to, and the jurisdiction whose law settles eligibility, and the cells that matter are the transitions: the day a service becomes one the minor consented to alone, and the day an authorisation is withdrawn. Testing a transition means moving the clock, which most suites cannot do, so the transition is usually the untested cell. Two adjacent routes get merged in most portals and belong apart in the fixtures. 45 CFR 164.510(b) lets a covered entity disclose to a family member or a close personal friend the information "directly relevant to such person's involvement with the individual's health care", on a standard of agreement, non-objection, or a reasonable inference drawn in professional judgment. A personal representative under 164.502(g) stands in the individual's shoes and exercises the individual's own rights. A portal proxy account is almost always the second thing, granted on evidence appropriate to the first.

Revocation has two shapes and a portal usually implements one of them. section 164.502(g)(5) permits a covered entity to "elect not to" treat a person as personal representative where it holds a reasonable belief that the individual has been or may be subjected to domestic violence, abuse or neglect by that person, or that recognition could endanger the individual, and where it decides in the exercise of professional judgment that recognition is not in the individual's best interest. Both conditions have to be met, and the second is a clinician's decision rather than a rule's, so a product that fires the revocation automatically on the belief signal has skipped it. Ordinary withdrawal is the other shape: a withdrawn delegate has to lose the account, the active session, the mobile token and any export already queued, and each of those is a separate code path.

Anything the portal asks a proxy to sign carries a validity test with it. section 164.508(c)(1) lists the core elements of a valid authorization, and element (vi) belongs to the delegation work: where the authorization is signed by a personal representative, "a description of such representative's authority to act for the individual must also be provided". A signature capture that stores a name and a timestamp produces a defective authorization on every proxy signature it takes.

Accessibility work happens on the authenticated screens, because that is where a patient reads a result and messages a clinician. Screen reader passes on the marketing site prove nothing about the message compose window or the consent overlay. Those screens then have to hold up on the devices patients actually own, which is a wider and older spread than any staff estate, and that part of the work is described in healthcare mobile app testing.

What arrives from systems you do not own?

Everything the portal shows. A patient-facing app is a client of somebody else's API, and the useful question is what that API is obliged to give you. section 170.315(g)(10)(i)(A) requires a certified Health IT Module to respond to requests for a single patient's data according to the standards adopted in 45 CFR 170.215(a) and 170.215(b)(1), and states that all data elements indicated as "mandatory" and "must support" by those standards and implementation specifications must be supported. A suite that asserts on the mandatory elements and stops is testing the smaller half of that sentence.

The portal's own criterion is section 170.315(e)(1), View, download, and transmit to 3rd party, and it carries a testing rule nothing else in the scope carries. Under 45 CFR 170.550(h)(2)(i) a Health IT Module presented for certification to (e)(1) must be separately tested to 170.315(d)(9) Trusted connection, so the transmit path is examined on its own instead of inheriting the attestation that covers the rest of the certification. (e)(1) is also one of the criteria that pull a developer into annual Real World Testing under 45 CFR 170.405(a). Secure messaging, meanwhile, is no longer a criterion at all: 170.315(e)(2) was removed as time limited by the HTI-2 final rule and now reads [Reserved], while 170.550(h)(2)(ii) still carries a carve-out pointing at it. A scope inherited from an older certification plan will name it.

On the FHIR side, a conformance claim covers what the CapabilityStatement declares and nothing outside it, so the first artefact is the served document from each environment, with the fhirVersion string and the canonical URL of every profile under rest.resource.supportedProfile. Must Support means nothing until a profile author writes down what it means; R4 flags no element as mustSupport in the base specification. US Core supplies the rules base FHIR withholds, and one of them belongs directly to a portal screen: a Responder SHALL NOT include an element whose value is absent for an unknown reason, and a Requestor SHALL read a missing element as data not present in the Responder's system. A blank on an allergy list therefore means the source holds nothing there, and a screen that renders it as "None" has made a clinical statement the payload did not.

Maturity decides how much of this can move under you. Patient and Observation carry the Normative marker in R4. Condition, AllergyIntolerance, MedicationRequest, DiagnosticReport and Immunization sit at FMM 3, and Encounter and Consent at FMM 2, where HL7's version management policy says there are "no rules for maintaining any sort of compatibility between versions". The resources a portal draws most of its screens from are the ones carrying no compatibility guarantee, and Consent is one of them. The conformance machinery and what a claim can be tested against are covered in FHIR R4 conformance testing requirements.

Behind the API there is usually still a v2 feed. Result release and demographic updates reach the portal as messages, and the order the patient sees is the order the portal derived from them rather than the order the record holds. That is the mechanism behind a portal showing yesterday's result above this morning's, and it is invisible to any test that reads only the portal's own database.

Where does patient portal testing go wrong?

• The suite signs in as an enrolled account, so every defect between the activation code and the first record view ships untested.
• A parent's access is granted or refused by rule where state law is silent, although 45 CFR 164.502(g)(3)(ii)(C) requires that decision to be made by a licensed health care professional in the exercise of professional judgment.
• Proxy eligibility is hard-coded to an age, although 45 CFR 164.501 and 45 CFR 160.103 define neither "personal representative" nor "unemancipated minor", and 164.502(g)(3)(ii) defers to state law and to the case law within it.
• Proxy scope is one switch over the whole chart, although 164.502(g)(2) limits a representative to the information relevant to the representation and 164.502(g)(3)(i) attaches the minor exception to a health care service.
• A delegate is revoked in the admin screen while the active session, the mobile token and the queued export are never checked.
• A representative's access request runs down the same code path as the patient's, so the reviewable denial ground at 164.524(a)(3)(iii) and the second-reviewer requirement at 164.524(a)(4) have nowhere to fire.
• The record export emits one format, so 164.524(c)(2)(ii) is answered with whatever the product already produced rather than with what was requested.
• Amendment is implemented as an update in place, although 164.526(c)(1) requires the affected records to be identified and the amendment appended or linked.
• An access log is offered as the accounting of disclosures, although 164.528(a)(1) excludes treatment, payment and health care operations and an access log records uses rather than disclosures.
• Accessibility is measured on the public pages and the login screen, and the authenticated screens are outside the scope, although nothing in 28 CFR 35.201 or 45 CFR 84.85 exempts content because it sits behind authentication.
• Individual pages in the enrolment sequence pass while one step fails, which under WCAG section 5.2.3 means no page in that sequence conforms.
• Audit evidence records the account that signed in and not the record that was opened, so an information system activity review under 45 CFR 164.308(a)(1)(ii)(D) cannot say which delegate read the chart.
• Proxy fixtures are copied from production, which puts a live custody arrangement into a test database that inherits none of the 164.312 safeguards.
• The screen is compared against the API response and never against the source record, so a release that never reached the patient view reads as a pass.
• The read path is load-tested against organic traffic, although a portal peak is manufactured upstream, when a batch of results is released or a panel-wide notification goes out. Reproducing that peak is its own exercise, and testing a patient portal against a manufactured peak needs a rig that starts from the upstream event rather than from a traffic curve.

What do we test on a patient portal?

Work starts on the enrolment and identity path, because it is the part of the product with no trained operator behind it and no retry after a failure. From there the delegation matrix is built and its transitions exercised, with the legal basis named per cell and the professional-judgment cases routed to a person; the access, amendment and accounting paths are driven against their own clocks and their own denial rules; the authenticated screens are driven against WCAG 2.1 Level AA as full pages and as complete processes with every responsive variation covered; the API contract is pinned to a served CapabilityStatement and a named profile set; and the rendered screen is reconciled against the source record rather than against the payload that produced it. The technical safeguards behind those screens are exercised as described in PHI security testing.

What that produces is evidence: a conformance claim carrying the components section 5.3.1 requires, an access-control matrix whose transitions each name the build they were exercised on, and the inventory 164.524(e) asks for, naming the designated record sets a request can reach and the store each one lives in. The obligation under section 504, under title II or under 45 CFR part 164 stays with the organisation that operates the portal.

Rule citations, criterion numbers and dates on this page are carried from the standard pages they belong to, where each was read against the eCFR text current to 31 August 2026 and against the WCAG 2.1 Recommendation, the FHIR R4 specification and healthit.gov on 2 September 2026. The Privacy Rule sections quoted here were compared between the CFR annual edition revised as of 1 October 2024 and the eCFR compilation of 31 August 2026, and the two texts are identical.