Patient portal proxy access should identify the person signing in, the patient whose records are involved and the permitted scope of access. Avoid sharing a patient's credentials as a proxy mechanism. Relationship verification, authority, duration and revocation need an approved organisational policy before the software can implement them correctly.
Let’s plan your portal access model.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Separate identity from relationship
A portal user may manage their own information and hold approved access to another person's records. Keep those identities distinct. Display the active patient context clearly so a message or appointment is not created under the wrong person.
Requirements can vary with relationship and circumstances. Have the responsible clinical, privacy and legal teams define eligibility, verification and any age-related transitions. This guide does not determine who is legally entitled to access a patient's information.
Create a proxy-access register
| Decision | Requirement to record | Acceptance scenario |
|---|---|---|
| Identity | Who is the signed-in person? | No shared credentials required |
| Relationship | What verified basis supports access? | Supporting decision can be traced |
| Scope | Which records and actions are permitted? | Restricted material remains unavailable |
| Context | Which patient is currently selected? | Switching changes the visible workspace clearly |
| Duration | When does access expire or need review? | Expired access cannot continue silently |
| Revocation | Who can end the relationship? | Existing sessions respect the changed authority |
Use the register to drive server-side access checks. A hidden navigation item does not prevent someone opening a copied record link.
Design communication attribution
Show whether a message was sent by the patient or an authorised proxy. Keep the actor and patient references separate in the audit history. Staff should not need to infer authorship from message wording.
For a hypothetical family portal, appointment reminders may need different destinations from private messages. Apply the approved scope to notifications as well as to the portal screens. A restricted record can still leak information through an overly detailed preview.
Test relationship changes
Exercise revocation, expiry, an incorrect relationship and a user managing more than one authorised context. Check downloaded exports, pending notifications and cached data according to the approved design.
Include a support process for disputed relationships. Support staff should have a permitted verification and escalation path rather than an unrestricted impersonation shortcut.
Proxy-access questions
Is one family login simpler?
It obscures individual identity and action history. Evaluate separate accounts and explicit approved relationships instead.
Should a proxy automatically receive every notification?
No. Apply the authorised scope and communication preferences to each category.
Use the healthcare permission checklist and review the relationship model with Drema's healthcare team after the responsible policy owners define it.