Implementation blueprint
Healthcare patient identity with proofing and HIPAA controls
For: Teams building patient portals and digital health apps that touch electronic protected health information (ePHI).
Updated 2026-07-19
Problem context
Patient portals serve a broad, often non-technical population, so authentication must be accessible, but they expose ePHI, so it must be assured. The tension is real: you cannot bury patients in friction, yet you cannot let weak identity reach medical records.
The answer is layered: proof identity to IAL2 at enrollment, authenticate with AAL2 (MFA) with step-up for sensitive actions, enforce minimum-necessary role-based access, and log everything for the HIPAA audit trail. Any vendor processing ePHI is a business associate and must sign a BAA.
Reference architecture
Core flows
Strong patient authentication
MFA is the baseline for ePHI access; offer accessible factors and reserve step-up for sensitive actions like viewing records or changing contact details.
Identity proofing to IAL2
At enrollment, verify the patient's identity (document plus liveness, or knowledge-based fallback) so the account can be trusted with medical records.
Data objects & boundaries
- Patient identity
- Proofed to IAL2 at enrollment; the trust anchor for ePHI access.
- Proofing record
- Evidence of identity verification, retained per policy.
- Role / access grant
- Minimum-necessary access to records; may include delegate/caregiver access.
- Audit event
- Every ePHI access and auth event, immutable and retained for the HIPAA audit trail.
- Consent / authorization
- Patient authorizations for data sharing and delegate access.
Required standards & protocols
- OpenID Connect (OIDC) for patient authentication
- NIST SP 800-63 IAL2 proofing and AAL2 authentication
- Identity verification / proofing integration
- Audit logging aligned to HIPAA Security Rule
Build-vs-buy decisions
| Decision | Build if | Buy if |
|---|---|---|
| Identity proofing (IAL2) | You have an existing proofing vendor and integration expertise. | You want proofing wired into enrollment without building it. |
| HIPAA-ready hosting + BAA | Never build this yourself. | Always, choose a vendor that signs a BAA and documents its controls. |
| Audit logging | You have a compliant logging pipeline already. | You want immutable, exportable identity audit logs out of the box. |
Weigh the whole picture with the build-vs-buy worksheet.
Anti-patterns
Skipping identity proofing
Without proofing, you cannot trust that the account belongs to the patient, a real risk for medical records.
SMS-only MFA for ePHI
SMS is weak; proposed HIPAA updates push toward stronger, phishing-resistant MFA. Offer app-based and WebAuthn factors.
Over-broad access to records
Access must be minimum-necessary; broad grants fail HIPAA and expand breach blast radius.
No signed BAA
Processing ePHI without a BAA is a compliance violation regardless of technical controls.
Implementation checklist
- Proof patient identity to IAL2 at enrollment
- Enforce MFA (AAL2) with accessible factors
- Add step-up for viewing records and sensitive changes
- Enforce minimum-necessary, role-based access to ePHI
- Support delegate / caregiver access with explicit authorization
- Write immutable audit logs of every ePHI access
- Execute a BAA with every vendor that touches ePHI
What to require of a platform
- Identity proofing / verification to IAL2
- MFA including app-based and WebAuthn factors
- Minimum-necessary RBAC
- Immutable, exportable audit logs
- Delegated / caregiver access model
- Signed BAA and documented HIPAA controls
Related guides
Head-to-head comparisons
Compliance
Industry context
FAQ
- Does a HIPAA-compliant CIAM vendor make my app compliant?
- No. You need a signed BAA plus correctly configured access controls, MFA, audit logging, and identity proofing in your tenant. The vendor enables compliance; your configuration achieves it.
- Do I need identity proofing for a patient portal?
- For access to medical records, yes, proof identity to around NIST IAL2 at enrollment. Without proofing you cannot trust that the account belongs to the patient, which is a real risk for ePHI.