Patient portal security needs a permission check for each clinical document. Signing in identifies the account; it does not establish access to every patient record.

A clinic product can serve patients, doctors, reception staff, and external laboratories. Each needs a different view of the same care process.

This guide helps builders map those relationships and test document access. It focuses on software design, not clinical decisions or compliance certification.

A patient portal breach reached clinical documents

A Health New Zealand review describes the December 2025 ManageMyHealth breach. It reports a compromised legitimate account and an exploited API vulnerability that exposed clinical documents.

The review records a US$60,000 extortion demand received on 31 December. It does not establish payment in the passage cited here. Read the review, pages 15–16.

The event is a documented reason to examine document APIs after login. It does not prove that a different identity provider would have prevented the breach.

Map patient relationships before choosing roles

Use a hypothetical clinic portal to define access. A job title alone rarely describes every permitted action.

Actor	Proposed access	Boundary to define
Patient	Their own released documents	Account-to-patient link and release status
Doctor	Records needed for assigned care	Current care relationship and permitted purpose
Reception staff	Scheduling and relevant contact details	Exclude clinical documents by default
Laboratory user	Assigned requests and authorised results	Referral, organisation, and task scope
Delegate or guardian	Specifically permitted patient access	Verified authority, scope, and expiry
Support operator	Sanitised troubleshooting information	No routine clinical-content access

These are design examples. Your clinical, privacy, and operational owners must approve the actual rules.

Separate appointment administration from access to clinical content. Avoid giving every clinic employee one broad patient-data role.

Treat guardian access as its own workflow. A shared email address does not, by itself, establish authority over another person's records.

Check document access at the server

An identifier in a URL tells the server which record the caller requested. It does not prove that the caller may read it.

OWASP's authorization guidance calls for request-level permission checks, including access to static resources.

For a proposed document download, review this sequence:

Verified account and current application session
                    |
                    v
Server-side link to patient, clinic, or approved delegate
                    |
                    v
Permission for the requested document and action
                    |
                    v
Release status and current access restrictions
                    |
                    v
Controlled download and audit event

Load the patient relationship from trusted server-side records. Do not accept a submitted patient identifier as evidence of membership.

Protect thumbnails, previews, search results, and bulk exports through the same policy. An unprotected preview can disclose the information a download route protects.

If you use signed storage links, define their lifetime. A link may remain usable until expiry even after the portal removes access.

Choose a delivery method that meets your revocation requirement. Document the remaining exposure when immediate revocation is unavailable.

Design shared-device use around individual accounts

A reception computer may serve several staff members during one shift. A shared device should not require a shared identity.

Give each person an individual account. Provide a clear sign-out route and define how inactivity ends access on shared devices.

Avoid leaving patient details visible after a staff handover. Include downloaded files and browser history in the operating procedure.

Require fresh authentication for selected sensitive changes where supported. Reauthentication should confirm the actor without creating additional clinical permissions.

Review passkey sign-in and autofill behaviour against your supported devices. Account recovery needs the same attention as routine sign-in.

For urgent clinical access, define a separate emergency process with clinical leadership. Record its justification, scope, and review requirements.

Do not invent an emergency override inside a general support role. Availability and misuse risks need an explicit decision.

Recheck asynchronous work and account changes

A report export may run after the person who requested it loses access. Define when the job rechecks authority and who can retrieve its result.

Changing a care-team assignment must affect future requests. Clearing one screen is insufficient if another API still uses an old permission cache.

Account recovery also changes who can reach sensitive records. Verify the recovery process before reconnecting an account to patient information.

Use your identity provider's documented account identifier. Review account linking separately from changes to contact details.

Keep clinical content out of authentication logs. Your application audit can reference document identifiers without copying reports into another system.

Test patient and staff boundaries

Use synthetic clinical records for these proposed acceptance checks. Do not use real patient files in a public demonstration.

Test	Expected result
Patient A requests Patient B's document identifier	Access is denied without exposing document contents
A receptionist calls a clinical download endpoint	The clinical permission is checked
An expired delegate requests a new download	The server rejects access
A removed doctor retries an old application session	Current care access is enforced
A background export finishes after access removal	Retrieval follows the defined current-access policy
A document remains unreleased	Patient access follows the approved release rule
A signed link survives portal sign-out	Its documented expiry matches the accepted exposure

Download the patient portal review sheet to assign a technical and clinical owner to each decision.

Review application sessions and revocation when implementing account removal.

Discuss your medical software integration with NamoID

NamoID Customer Identity provides hosted authentication, passkeys, TOTP MFA, and identity-session controls.

Our engineers can help you review sign-in, recovery, and the boundary between identity and patient permissions.

Your product still owns clinical access, care relationships, document delivery, and application sessions. Sector obligations require their own review.

Contact the NamoID team in Slack for an early response. Share your stack, actor list, and a sanitised access diagram.

Keep patient information and incident evidence out of the community channel. We can help identify a practical next integration step.