Testing patient portal authorisation beyond login

Make the permission model explicit

Patient access, family proxies, treating clinicians, support staff and administrators often follow different rules. Write those relationships as actor, object and action before looking at payloads. Include expired proxy access and staff transferred between provider organisations; these lifecycle states often reveal gaps hidden by happy-path testing.

Compare decisions on the same object

Keep the object constant while changing the principal, then keep the principal constant while changing the object owner. Check the server response and downstream audit event. A hidden button is not an access control, and an unpredictable record identifier does not replace an authorisation decision.

Inspect secondary interfaces

A portal’s document download, export job or mobile API may apply different checks from the main record page. Test each permitted route with the same synthetic role matrix. Export creation, status polling and download retrieval are separate operations and may need separate permission checks.

Make the fix verifiable

Recommend a server-side policy at the object and operation boundary, then retest both permitted and forbidden access. Capture the principal, test record, request ID and result. The aim is a clear access decision without breaking legitimate care access, rather than simply suppressing an error message.

Use paired accounts and paired records

Prepare two patients with separate synthetic appointments, messages and documents. Establish the legitimate baseline for each account, then repeat a single agreed operation against the other account's canary object. Keep the request type and object state comparable. This isolates the ownership decision from unrelated validation failures. Include a delegated account only where the portal supports it, with a clearly documented relationship and expiry. Avoid assuming that family access to one type of record grants access to all records.

The same comparison is useful for clinicians who work across practices: one account may legitimately see records in two contexts, while another may have access to only one. The expected result must come from the service owner, not from a tester's guess about the intended care relationship.

Test the lifecycle of an existing permission

Access can be correct at creation and wrong after a relationship changes. Agree checks for revocation, transfer between organisations and expiry of a delegated role. Examine whether a previously issued document link, queued export or active session still exposes the synthetic material. Use a small number of prepared objects and record the point when the policy change should take effect. Do not conclude that a control failed merely because the product documents an intentional, approved delay; compare the observation with the actual requirement.

Our tenant isolation guide explains why request rejection and downstream state should be examined together. That method transfers well to portals with asynchronous document generation.

Write a finding that the product team can fix

Evidence should identify the requesting role, the intended owner, the operation and the exact permission that should have prevented it. Capture a redacted request and response alongside the synthetic object identifier and a server-side audit reference where available. State whether the observation demonstrated read access, modification or merely object discovery. These are different impacts. A screenshot of a patient page without identity context is weak evidence and can unnecessarily expose sensitive material.

Retesting should repeat the failed comparison, confirm that legitimate access still works and check the nearest equivalent endpoint. If the issue involves an integration used by a hospital, our EHR and imaging integration testing guide helps identify the additional service identities that need attention.

Put the guidance to work

Use the readiness checklist to document assumptions, or inspect the fictional Healthcare AG report for evidence and treatment-plan examples. Contact Atlant Security with a non-sensitive description of your scope.