Why open source customer identity for healthcare starts with patient access
A health system or provider group that wants patients and caregivers to reach their records online faces a HIPAA access control and authentication problem tied directly to the EHR, not just a login page. Every portal session is a path into electronic protected health information, so the identity layer decides who sees which chart, how a person proves who they are, and what gets logged. Under the HIPAA Security Rule's technical safeguards in 45 CFR 164.312, unique user identification, person or entity authentication and audit controls apply to systems holding ePHI, and a portal that issues accounts to patients falls squarely within that scope. On the platform side, the short answer is Keycloak as the most direct fit, with ZITADEL and Ory as alternatives to evaluate. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, user federation and fine-grained authorization, which map well to patient, proxy and staff roles. The right choice depends on your integration and hosting constraints: which EHR and identity sources you must federate with, whether you need a Kubernetes-based deployment, and how your team will run it. Confirm with each candidate how it handles proxy relationships and identity proofing workflows before you commit. DeployOpen plans, implements and operates these systems inside your own cloud accounts, data centers or private networks, so patient identity data stays under your control. DeployOpen prepares the controls and evidence that support a HIPAA assessment, but it does not issue attestations or certifications, and HHS does not offer a HIPAA certification. Ask any implementation partner to put scope, deliverables and timelines in writing before work starts.
Which HIPAA and related requirements shape a patient portal identity build
This table maps the HIPAA technical safeguards and related rules to specific patient portal identity settings, the evidence an assessor or regulator would ask for, and where builds commonly fall short. Read each row as a requirement paired with the configuration decision it drives. The main takeaway is that HIPAA sets outcomes rather than a product, and there is no HIPAA certification to obtain.
| Requirement | What it asks for in identity configuration | Evidence to keep and where builds usually fail |
|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i), required) | One account per patient, caregiver and staff member, with no shared logins. Map each proxy relationship to its own identity, not to the patient's credentials. | Evidence: user directory exports and account creation logs. Failure point: shared family logins or staff using generic accounts in portal support tools. |
| Emergency access procedure (164.312(a)(2)(ii), required) | A documented break-glass path for clinicians to reach records when normal login fails, with its own logging and post-event review. | Evidence: written procedure, tested break-glass events and review records. Failure point: an emergency account that is never reviewed or disabled after use. |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Session idle timeouts and absolute session lifetimes set in the identity provider, with shorter limits for sessions that reach ePHI. Confirm the values with your risk analysis. | Evidence: configured timeout values and the documented rationale. Failure point: long refresh token lifetimes that keep sessions alive for days. |
| Audit controls (164.312(b)) | Logging of sign-in, failed attempts, MFA events, password and recovery changes, proxy grants and admin actions, retained and reviewed. | Evidence: log samples, retention settings and review records. Failure point: identity logs that stay in the IdP and never reach the security monitoring pipeline. |
| Person or entity authentication (164.312(d)) | Verification that the person logging in is who they claim to be, using MFA or stronger methods, with step-up for sensitive actions such as record access or changing contact details. | Evidence: authentication method configuration and test results. Failure point: knowledge-only logins for portal accounts that can view full records. |
| Transmission security and encryption (164.312(e), addressable) | TLS for all login, token and API traffic between the portal, identity provider and EHR integration layer. Document whether encryption is in place or an alternative is justified. | Evidence: TLS configuration reports and the addressable decision record. Failure point: internal hops between identity and EHR services sent without encryption. |
| Business associate flow-down (45 CFR 164.314(a)(2)(i)) | If a hosted identity vendor or managed service handles ePHI, a business associate contract must require Security Rule compliance, flow-down to subcontractors and incident reporting to the covered entity. Self-hosting inside your own environment changes the vendor scope, so confirm with counsel. | Evidence: signed agreements and subcontractor lists. Failure point: a managed Keycloak or support provider with access to tenant data and no executed contract. |
| Need-to-know access and external access controls (related: CNIL, Hopital Prive de la Loire, 3 September 2026) | The CNIL fined the hospital EUR 500,000 under GDPR Articles 32 and 34 after finding external access to its patient record system lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. Build role and relationship-based access, MFA for every external path and periodic access review. | Evidence: role-to-record mappings, MFA enforcement reports and access review records. Failure point: broad clinician roles that grant every record in the EHR to every member of a unit. |
Which open source identity platforms fit patient portal login
Patient portal login sits on top of identity proofing, caregiver access and audit logging, so the platform choice shapes how much of that work you build yourself. The cards below cover the three open source customer identity platforms most often considered for this role, plus the governance companion that handles clinician and workforce access.
Keycloak for patient login
Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with identity brokering, user federation and fine-grained authorization services. For a patient portal, the question is whether its built-in flows cover identity proofing and caregiver delegation, or whether those need custom authenticators and an identity verification service. Check the supported production databases and the high availability design you will run, because both supported designs require a synchronously replicated database. Confirm the proofing workflow before the platform is chosen.
ZITADEL for passkey-first portals
ZITADEL is licensed under AGPL-3.0 and lists passkeys through FIDO2 and WebAuthn, SAML 2.0, SCIM and multi-tenancy in its README. Patient portals that want passkeys for account recovery-light sign-in, or that serve several affiliated clinics as separate tenants, should test those flows against their own recovery policy. The AGPL obligations apply if you modify and offer the software to users over a network, so have counsel review how your hospital group or vendor will deploy it.
Ory Kratos with Hydra
Ory Kratos handles identity and user management, while Ory Hydra acts as the OAuth 2.0 and OpenID Connect server, and both are licensed under Apache-2.0. This split suits teams that already run a separate login UI and want the token server apart from the user store. The cost is assembly: you own the integration of profile, consent, caregiver scopes and audit events across two services. Confirm who maintains the login pages and how the two components are upgraded together.
midPoint for clinician and staff access
Evolveum midPoint is an identity governance platform licensed under EUPL 1.2 or later, and it handles provisioning, access requests and certifications for workforce and clinician accounts. It does not replace a patient login platform, so pair it with Keycloak, ZITADEL or Ory on the patient side. Its 4.8 Curie long-term support release is supported until October 17, 2028, which matters for planning. Have counsel review the EUPL terms against your hosting and modification plans.
How a patient identity rollout runs in phases
A patient identity rollout moves through eight ordered phases, each closing with a named output that the next phase depends on, so scope, architecture, recovery design, EHR behavior and audit evidence are settled before patients log in.
Define requirements and map patient data
Your team and DeployOpen review which patient portal functions, user types and EHR data flows the identity platform must serve, including patients, caregivers, staff and external systems. The team maps which identifiers, contact attributes and consent records are stored, where they originate and which regulations touch them, including the HIPAA Security Rule's unique user identification and person or entity authentication requirements. The output is a signed scope document and a data map that names the systems of record. This phase is complete when the business and compliance owners sign the scope in writing and the data map has no unassigned attribute.
Decide hosting and high availability design
DeployOpen drafts the architecture for where the identity platform runs, whether in your cloud account, a data center or an isolated network, and how it stays available during node or zone failures. For Keycloak, the documented high availability designs require a synchronously replicated database, so the team confirms the database choice from the supported list and the replication approach with the vendor and its own platform team. The output is an architecture decision record covering hosting, network paths to the portal and EHR, backups and upgrade method. This phase is complete when the record is approved and the open questions have named owners.
Design identity proofing and account recovery flows
The team defines how a new patient account is linked to a verified person record in the EHR, which proofing steps are used, and how a locked-out patient recovers access without exposing another patient's record. Recovery paths are documented for each channel the portal supports, and staff procedures cover cases where the patient cannot complete self-service recovery. The output is a flow specification with decision points and a list of the attributes used for matching. This phase is complete when the specification has been reviewed by privacy and clinical operations and each recovery path has a test case.
Model the caregiver proxy and consent rules
DeployOpen works with clinical, privacy and legal owners to define how a caregiver is granted proxy access, who can approve it, what scope it covers and how it is revoked or expires. Access rules follow the need-to-know principle that the CNIL cited in its 2026 decision on a French hospital, where access control ignored the care team's need to know. The output is a consent and proxy model with its roles, attributes and revocation steps, reviewed by the organization's privacy officer. This phase is complete when every proxy type has an approved scope and a documented revocation path.
Test EHR integration and access enforcement
The identity platform is connected to the portal and to the EHR interfaces the scope names, and the team tests that authentication and authorization decisions match the approved model. Tests cover normal patient access, proxy access, denied access to other records, expired proxies and failover of the identity service during integration traffic. The output is a test report with pass and fail results, defect records and retest evidence. This phase is complete when all critical cases pass and the owners accept any residual defects in writing.
Validate audit logging and retention
The team confirms that logins, failed attempts, proxy grants and revocations, administrative changes and record access events are logged with enough detail to answer who accessed what and when. The HIPAA Security Rule requires audit controls that record and examine activity in systems containing ePHI, so log sources, forwarding to your monitoring platform and retention periods are set and tested. The output is a logging validation report and a list of log events mapped to the controls they support. This phase is complete when a test session can be reconstructed end to end from the logs alone.
Run a controlled pilot with real workflows
A limited group of patients, caregivers and staff use the new identity flows in production under monitoring, with a clear rollback route to the existing portal login. The team tracks failed logins, recovery requests, help desk contacts and any access denials that block legitimate care. The output is a pilot report with issues, decisions taken and go or no-go criteria agreed in advance. This phase is complete when the criteria are met and the operations owner signs the pilot exit.
Cut over and hand over runbooks
Patients are moved to the new identity platform in a planned change window, with the rollback plan rehearsed and the existing login kept available until the owners approve retirement. DeployOpen delivers runbooks for backup and restore, upgrade handling (including the Keycloak Operator's recommended manual approval mode for operator updates), certificate and key rotation, and incident response. The output is the signed cutover record and a runbook set that your operations team has used at least once. This phase is complete when the old login path is retired by an approved change and operations accepts ownership.
What auditors and regulators ask to see from patient identity
This table maps each piece of identity evidence that HIPAA-focused assessors and HHS Office for Civil Rights reviewers typically request to the component that produces it and the common gaps. Use it to plan which logs, configurations and contracts to retain from the start, since independent assessors and HHS OCR make the final determinations.
| Evidence item | Produced by | Common gap to check |
|---|---|---|
| Unique user identification records for patients, caregivers and staff | Identity provider user store (for example, Keycloak realm users and federated identities) | Shared or generic accounts used by staff or proxies, with no mapping to a verified person |
| Access grant and revocation logs for proxy caregivers | Identity governance workflow or admin events in the identity platform, linked to the EHR consent record | Proxy access that persists after a guardian's authority ends or a patient turns adult |
| Authentication policy configuration | Identity platform realm, client and flow settings, exported and version controlled | Policies changed in the admin console with no change history or approval record |
| MFA enrollment and factor usage evidence | Identity platform credential records and authentication event logs | Patient portal users with no second factor, or staff remote access without MFA |
| Audit log samples and periodic review records | Identity platform event logs forwarded to a SIEM such as Wazuh, with review tickets | Logs retained but never reviewed, or no evidence of who examined them and when |
| Encryption configuration for identity data in transit and at rest | TLS settings on the identity endpoints, database encryption settings, and secrets stored in a secrets manager | Certificates or database connections using outdated settings, or keys stored beside the application |
| Business associate contracts covering identity and hosting providers | Contract records maintained by the covered entity and each business associate | Managed identity or support vendors with access to ePHI and no contract on file |
How much work, time and effort does a healthcare patient identity build take
What drives the cost of a healthcare patient identity build?
The cost is driven mostly by scope, meaning how many patient populations, portals and EHR interfaces the identity platform must serve, followed by identity proofing, hosting, and ongoing support. Scope sets the number of integrations to build and test, and each EHR interface adds mapping, testing and validation work. Proofing vendors add per-verification fees that recur with volume. Hosting in your own cloud account or data center adds infrastructure and operations effort, and support and upgrades recur for the life of the platform. Ask any partner for a quote that separates one-time build work from recurring operations, and that names every integration in scope.
How long does a patient identity implementation take?
No supplied figure sets a fixed duration for this work, so treat any timeline as something to confirm in writing. The duration depends on the number of portals, the EHR integration pattern, how many proofing and recovery flows are required, and how much existing patient account data must be migrated. Ask for a phased plan that separates a proof of concept against a non-production EHR, validation of the authentication and audit controls, and production cutover. A fixed written scope should state the milestones and the dependencies on your clinical and EHR teams.
Can a small team build patient identity on open source without outside help?
A small team can run a self-hosted platform such as Keycloak, but a patient identity build needs skills beyond standard login configuration. Those skills include secure federation with EHR and directory systems, identity proofing and account recovery design, HIPAA audit logging, and high availability planning. Keycloak documents supported production databases and high availability designs that require a synchronously replicated database, and its operator is installed through Operator Lifecycle Manager. Teams with that experience may build in house, while teams without it should compare the cost of hiring for those gaps against a partner with a written scope.
What does the healthcare organization need to provide during the build?
The build depends on named people from your organization, and their time is often the constraint. Clinical owners decide which patients, caregivers and care teams need which access, and they approve the proxy access rules. Privacy and compliance owners define the HIPAA authentication and audit requirements and review evidence. EHR analysts provide the patient record interface details, test data and change windows. Security and infrastructure staff own the hosting environment, identity proofing vendor relationships and access to the cloud or data center. Name these owners before the work starts and confirm their availability in the written scope.
How do platform upgrades affect validation work for a patient portal?
Upgrades add recurring validation work, because each change to the identity platform can affect login, proxy access and audit output. Keycloak plans four minor releases a year and says breaking changes in a minor release are opt-in, which reduces surprise but does not remove testing. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Database schema migration runs automatically at startup by default, and manual migration is an option the upgrading guide suggests for large deployments. Ask for a regression test set and a change process in the scope, and confirm who signs off each release in your environment.
Why should the scope be agreed in writing before the work starts?
A written scope sets what is delivered, what is excluded and how the work will be accepted, which protects both the health system and the implementation partner. DeployOpen's engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. For a patient identity build, the written scope should list each EHR interface, each portal, the proofing and recovery flows, the audit evidence to be produced, the hosting environment and the support model after go-live. Changes after that point should go through a documented change request so cost and timing stay visible.
What recurring costs follow a healthcare patient identity platform after launch?
After launch, recurring costs fall into four groups: infrastructure, upgrades and testing, support, and third-party services. Infrastructure covers the database, the clustered identity nodes and monitoring, which must run in a design that supports high availability. Upgrades and regression testing repeat for every release you adopt. Support covers incident response and on-call coverage for patient access. Identity proofing and messaging vendors often bill per transaction, so volume changes the cost. Ask for a quote that prices each group separately and states which items are retainers, which are usage-based and which are one-time.
Does a HIPAA-aligned patient identity build come with a certification?
No. There is no HIPAA certification, and HHS states that no Security Rule standard requires an entity to certify compliance. The build can produce controls and evidence that support a HIPAA risk analysis and an independent assessment, but DeployOpen prepares systems, controls and evidence and does not issue audit reports or certifications. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Ask your implementation partner which evidence it will hand over, such as access configuration, audit log samples and test records, and which parts your own compliance team must produce.
What to ask an implementation partner about patient identity
Start with proxy access, because it is where patient portal identity most often fails an assessor. Ask the partner to show how a caregiver's relationship to a patient is recorded, who approves it, how it expires, and whether the audit trail names both the proxy and the patient on every session. Ask how the design applies the need-to-know principle that the CNIL cited in its September 2026 decision against Hopital Prive de la Loire, and how the proxy model is tested for a caregiver who should lose access after a care episode ends. Ask how identity proofing and account recovery are validated, including which attributes are checked before a portal account is linked to a patient record and what happens when a recovery request arrives from a person who is not the account holder. Request the recovery test cases in writing before any build starts.
Ask how EHR integration is tested against patient matching errors. A wrong match sends one patient's data to another account, so the partner should describe the test data, the matching rules, the duplicate-record scenarios and the manual review path. Confirm how Keycloak upgrades are staged: whether the Operator is set to manual approval mode as its documentation recommends, how the database schema migration runs (automatic at startup by default, or applied manually as the upgrading guide suggests for large deployments), and where a rollback is tested. Finally, ask for business associate terms and a current subcontractor list covering hosting, backup and support staff who can reach ePHI, as 45 CFR 164.314 requires, and ask how the evidence pack for an assessor is organized, mapped to the 45 CFR 164.312 technical safeguards, and kept current after each release.
How hosting and deployment limits change the design
In a cloud account, the main design choices are the database service, the availability zones used and how the Keycloak nodes are deployed. Keycloak documents three high availability architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without an external Infinispan cluster, and the deprecated multi-cluster v1 that used a separate Infinispan cluster per site. Both supported designs require a synchronously replicated database, so a cross-region database that replicates asynchronously does not meet that requirement. Supported production databases include PostgreSQL (14 to 18), Amazon Aurora PostgreSQL, Azure SQL, MariaDB, MySQL, Microsoft SQL Server and Oracle Database, and the default dev-file database is for development only.
- Database replication: Confirm that the managed database runs synchronous replication across the zones you plan to use before you commit to a multi-zone design.
- Availability architecture: Choose the single cluster across zones or the v2 multi-cluster design, and avoid building new work on the deprecated v1 model.
- Operator use: The Keycloak Operator installs through Operator Lifecycle Manager, and its documentation recommends manual approval mode for operator updates.
- Schema migration: Keycloak migrates the schema automatically at startup by default, so decide whether large deployments will apply migrations manually.
- Data residency: Confirm the region for identity data, backups, logs and metrics, since cloud logging services often default to other regions.
Before you approve a cloud design, check with the hosting provider and your compliance team which regions store identity records, audit logs and backups, and whether a business associate agreement covers each managed service.
In a data center, the database and the network are your responsibility. You must provide a database platform that meets Keycloak's support list and a synchronous replication design between sites or racks if you use a high availability model. Load balancers, certificate lifecycle, time synchronization and backup targets all become part of the identity service, and each one affects audit evidence and recovery. Patient-facing portals often sit behind a demilitarized zone, so the placement of the Keycloak nodes relative to the EHR-facing network needs deliberate design.
- Supported database: Standardize on one supported production database engine, such as PostgreSQL within the supported version range, and test failover against it.
- Synchronous replication: Both supported high availability designs require synchronous replication, which constrains how far apart the sites can be and what latency the database can tolerate.
- Network placement: Decide whether Keycloak sits in the public zone, an application zone or an identity zone, and document the flows to the EHR integration layer.
- Operator or packaged install: Choose between a Kubernetes operator, a packaged distribution and a virtual machine deployment based on the skills your platform team already has.
- Backups and restore: Test restoration of the realm configuration and the database together, since restoring one without the other can leave orphaned accounts or clients.
Confirm with your infrastructure team whether the proposed database replication and failover times meet your recovery targets, and document where log and backup copies are kept on premises.
On an air-gapped clinical network, Keycloak cannot depend on internet-hosted services such as external identity providers, hosted email gateways or public container registries at runtime. Every container image, operator bundle, library and update must be brought in through an approved transfer process, and each upgrade requires a planned import. This makes the release cadence and manual migration option more important, because you need time to validate a new version before it reaches clinical systems. Identity federation with hospital directories and EHR systems also has to stay inside the enclave.
- Offline artifacts: Plan how images, operator manifests and dependency sources enter the enclave, and keep a signed record of each import.
- Local identity sources: Use directory federation inside the enclave, such as LDAP or Active Directory user federation, instead of external brokering.
- Upgrade planning: Keycloak plans four minor releases a year and says breaking changes in a minor release are opt-in, which helps staged validation, but you still need a local test environment.
- Logging inside the enclave: Keep audit and access logs in the enclave, with retention that meets your HIPAA audit controls.
- Email and recovery: Account recovery that depends on outbound email or SMS needs an internal relay or an alternate method approved by your security team.
Confirm with the health system's security and biomedical teams which services Keycloak may reach, how artifacts are transferred, and whether any vendor support for the enclave requires remote access that is itself audited.
Integration points between identity and clinical systems
A patient portal identity layer touches the EHR, staff directories, security monitoring, secrets storage and the identity platform's own telemetry. Each connection carries its own access path and evidence trail, so the design should be settled before build starts. The cards below cover the integrations to confirm early and the ones that depend on the EHR vendor's published interfaces.
EHR patient portal connection
Keycloak handles the patient login and issues tokens that the portal back end uses to read or write patient data in the EHR. Decide whether the portal calls the EHR directly with a delegated token, or goes through an integration layer that enforces the care relationship. Confirm with the EHR vendor which SMART on FHIR authorization profile, scopes and patient-context launch options its patient-facing APIs support, and whether they accept tokens from your identity provider.
FHIR and HL7 interfaces to confirm
Identity events such as account creation, identity proofing results and proxy grants may need to reach the patient record, and EHR updates such as demographic changes may need to reach the identity store. Confirm with the EHR vendor which interface the site runs, whether that is a FHIR endpoint, an HL7 v2 feed or a vendor API, and which fields are authoritative for the patient identifier. Do not assume a bidirectional sync is supported without written confirmation.
Staff directory federation
Clinicians and support staff who use the portal's administrative tools or the EHR launch should sign in through the hospital's existing directory rather than through a separate patient-facing store. Keycloak supports LDAP and Active Directory user federation, so the question is which directory is authoritative and how deprovisioning reaches the identity platform when someone leaves. Keep staff and patient realms or user populations separate to avoid cross-population access.
Authentication logs to a SIEM
HIPAA audit controls require activity in systems holding ePHI to be recorded and examined, so Keycloak's login, failed login, admin and token events should flow to the same monitoring stack as the rest of the environment. Wazuh is one open source option for collecting and correlating these events. Confirm the event fields you need, the retention period your compliance policy sets, and whether patient-record access events from the EHR can be correlated with portal login events.
Secrets and keys for integrations
Client secrets for the EHR connection, database credentials and signing key material should not sit in configuration files or container images. OpenBao or Infisical can store and distribute these values with access policies and audit logs. Confirm how the EHR vendor issues and rotates client credentials, and whether its certification process requires a specific key length or rotation schedule before you commit to a secrets workflow.
Keycloak metrics and availability
Keycloak exposes metrics that show login rates, errors and resource use, which helps you size the cluster and spot an authentication outage before patients report it. Connect these metrics to your monitoring stack and set alerts on login failure spikes, since they can signal an attack or a broken EHR connection. Confirm the database and clustering design with your operations team, because the platform's high availability options require a synchronously replicated database.
How DeployOpen scopes and supports patient identity work
A patient identity project starts with a written, fixed scope. DeployOpen plans and implements the self-hosted platform inside your own cloud accounts, data center or private network, and the scope document should name each component in the build: the Keycloak realms and clients for patient and caregiver logins, the identity proofing step or partner integration, the recovery flows, the EHR and portal connectors, the logging pipeline and the environments that will hold ePHI. Deliverables, acceptance criteria and timelines are agreed in writing before work begins, so your security, privacy and clinical stakeholders can review what is in and out of scope. Ask for that document to name who owns each decision, including who approves caregiver proxy rules and who signs off on the account recovery policy.
Hardening and testing run inside that scope, not after it. For a patient portal, this covers the production configuration of the identity server, the TLS and session settings, the administrative console restrictions, the proxy-access authorization paths and the API endpoints that expose patient records. DeployOpen runs security testing of applications, APIs and infrastructure, and it can test the caregiver delegation logic specifically, since that is where unauthorized access to a record most often happens. Evidence is prepared as the work proceeds: configuration baselines, test results, access reviews and logs of administrative changes. DeployOpen prepares this evidence for your compliance assessment. It does not issue audit reports, attestations or certifications, so your auditors or certification body need to be engaged separately.
After go-live, the platform still needs patching, upgrades and monitoring. Keycloak releases arrive on a regular cadence, and the Operator documentation recommends manual approval for operator updates, so the retainer should define who reviews release notes, who tests upgrades in a non-production environment and how database migrations are applied. Ask whether the retainer covers emergency patching, on-call response for identity outages and periodic re-testing after changes to proxy rules. Ongoing support and upgrade retainers are available, and their terms should be agreed in the same written process as the initial scope.
