Why healthcare identity governance starts with role changes, not headcount
A hospital IT leader whose clinicians rotate between units, residency programs, agency staffing pools and satellite sites will tell you the same thing: the EHR access lags behind the schedule. The control problem is the gap between a role change and the removal or addition of EHR permissions, and that gap is where ePHI exposure builds up. The HIPAA Security Rule's technical safeguards in 45 CFR 164.312 require unique user identification, access control, audit controls that record and examine activity in systems holding ePHI, and person or entity authentication. Regulators also look at how access is granted, not only whether a policy exists. In September 2026, the CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34, citing external access to its patient record system without VPN or multi-factor authentication and access rules that ignored the care team's need to know.
For the platform choice, the short answer is that midPoint handles the lifecycle and certification layer: it can drive joiners, movers and leavers from the authoritative HR or staffing source, map roles to EHR and directory entitlements through connectors, and keep certification decisions as evidence. It does not act as the single sign-on server, since Evolveum states that midPoint does not implement the server side of OAuth2, OpenID Connect or SAML, so authentication for external and agency users belongs with a separate component such as Keycloak or authentik, and credentials for interface accounts belong in a secrets manager. Before scoping, confirm which HR or credentialing source is authoritative for agency and rotating staff, and which EHR roles can be expressed as midPoint roles without manual exceptions.
Which HIPAA and related requirements shape the access design
This table maps the HIPAA technical safeguards, the business associate flow-down and the NIS2 health scope to specific midPoint and connector design choices. Read each row as a requirement, the design decision it drives and the evidence an assessor or regulator is likely to ask for. The main takeaway is that most HIPAA access expectations are met by how roles, connectors and leaver workflows are built, not by a single product feature.
| Requirement | Design choice in midPoint and connectors | Evidence to keep |
|---|---|---|
| Unique user identification (164.312(a)(2)(i), required) | Give every clinician, resident and agency worker one identity object in midPoint, linked to one HR or sponsor source, with no shared logins created by connectors | Identity records, correlation rules and a report of any accounts that lack a unique owner |
| Emergency access procedure (164.312(a)(2)(ii), required) | Model a break-glass role with named approvers, a time limit and alerting, and provision it through a separate, reviewed workflow | Approval records, activation logs and a post-event review of each emergency grant |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Set session timeouts in the SSO and EHR layer; midPoint governs the entitlement, not the session, so confirm the timeout owner in writing | Configuration baselines for each EHR and SSO application and the decision record if an alternative is chosen |
| Audit controls (164.312(b), standard) | Ensure every provisioning, role change and certification decision is written to midPoint's audit trail and forwarded to the log platform | Exported audit records showing who changed access, when and under which approval |
| Person or entity authentication (164.312(d), standard) | Tie midPoint identities to the authoritative authentication source and confirm that MFA is enforced by the SSO or directory, which midPoint does not itself perform | Authentication policy configuration and sample login records for privileged and remote users |
| Encryption and transmission security (164.312(a)(2)(iv) and (e)(2)(ii), addressable) | Use encrypted connections for every connector, including LDAP over TLS and HTTPS for SCIM2, and document where any connector cannot meet this | Connector configuration exports and a list of exceptions with compensating controls |
| Business associate flow-down (164.314(a)(2)(i)) | Provision contractors and agency staff under a sponsor-owned lifecycle with end dates, and require subcontractors who touch ePHI to be covered by the same terms | Signed business associate agreements linked to each external identity population and incident reporting paths |
| NIS2 health sector scope (Annex I) for EU providers | Scope the identity estate to the entities in scope and align leaver and review controls with the NIS2 obligations that apply to them, confirmed with counsel | Scoping memo, responsible owners and the control mapping agreed with the entity's legal team |
| Pending Security Rule revision (proposed 6 January 2025) | Design for the current rule and add flexibility for stricter controls such as more frequent reviews, then confirm the final text with counsel once published | Dated change log of design decisions and a counsel review record for each open proposal item |
Which open source platforms fit healthcare identity governance and why
Healthcare identity governance usually splits across four jobs: lifecycle and certification, workforce login in front of clinical apps, secrets for integrations, and audit logs that show who touched patient data. The platforms below cover those jobs, and each one needs confirmation against the specific EHR, directory and logging estack in your environment before a design is fixed.
midPoint as the lifecycle engine
midPoint handles joiner, mover and leaver rules, role assignment and access certifications, so it is the system that decides who should hold EHR roles. Its repository is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states there is no enterprise edition. For clinical staff whose roles change often, the key check is whether your EHR and staffing sources have a supported or community connector, and how role mapping from EHR security classes is modeled. Plan on the 4.8 long-term support release, supported until 17 October 2028, for stability.
Keycloak or authentik for workforce SSO
midPoint is an identity management system, not an SSO or access management server, so it does not issue OpenID Connect or SAML tokens to EHR apps. A separate SSO server such as Keycloak or authentik must sit in front of clinical applications, enforce multi-factor authentication for remote and external access, and federate with the directory midPoint provisions into. Confirm that your EHR supports the protocol you choose (SAML 2.0 or OpenID Connect) and that the pairing is tested for role claims and deprovisioning timing.
OpenBao for integration secrets
Interfaces between the EHR, lab systems, identity connectors and reporting jobs use service accounts and API keys. Those credentials are a common path to patient records when they are stored in configuration files and never rotated. OpenBao, licensed under MPL-2.0 and hosted under the OpenSSF, can store, issue and rotate these secrets so midPoint connectors and interface engines read them at runtime. Confirm which connectors can fetch secrets from an external store and who owns rotation during staff turnover.
Wazuh for audit log collection
HIPAA technical safeguards require audit controls that record and examine activity in systems containing ePHI, so logs from the EHR, directory, midPoint and the SSO server must reach a central store. Wazuh collects and correlates these logs under GPL version 2 and can alert on access patterns such as after-hours record views or accounts that remain active after a leaver date. Check that each EHR audit log can be forwarded in the format you need, and set retention to match your policy and state rules.
How clinical role changes differ from a standard HR lifecycle
In a hospital, the mover event is the common case, not the exception. Residents rotate through services every few weeks, float nurses cover different wards by shift, locum physicians and agency staff arrive with short contracts, and each change alters which patient records a person needs. A standard HR lifecycle that treats a transfer as a single department change will miss most of this. In midPoint, the practical answer is to model clinical access as roles tied to care-team membership, such as ward, service, rotation and assignment, and to drive those roles from the scheduling or rostering system that the clinical operations team already maintains, with HR as the source for employment status. Confirm with your EHR and rostering owners which system is authoritative for ward and rotation assignments before you design the mapping.
Care-team need to know should be expressed in roles, not granted by ticket. When access is requested case by case, the access record drifts away from who is actually treating patients, and the CNIL's September 2026 decision against Hopital Prive de la Loire, which found that access control ignored the care team's need to know, shows how regulators read that gap. Temporary assignments such as locum cover, agency contracts and rotation blocks should carry an end date at the moment of provisioning, so that the removal happens by configuration rather than by someone remembering to close the ticket. Ask your EHR administrators to confirm how role assignments are represented in the EHR and whether end dates can be enforced there or only in the identity layer.
Break-glass emergency access needs its own path. Clinicians sometimes must reach records outside their care team during an emergency, and the HIPAA Security Rule requires an emergency access procedure as a required implementation specification under 45 CFR 164.312. Model break-glass as a separately approved entitlement with a short, defined duration, a mandatory reason, notification to the privacy or security officer, and an audit trail that is reviewed after the event. It should not be a general role that everyone holds by default. Confirm with your privacy office how break-glass requests are approved, who reviews them and how long the logs are retained.
How a healthcare identity governance rollout moves from inventory to certification
The sequence turns scattered accounts and EHR roles into a documented, reviewable model of who can reach patient data, and proves that model holds through a first certification campaign. Each phase closes with a named output that the next phase depends on.
Inventory sources and entitlements across the estate
The team catalogs authoritative HR feeds, the EHR and its security tables, Active Directory or LDAP directories, and any clinical applications, shared drives or agency staffing systems that grant access. Each source is recorded with its owner, its update frequency and the entitlements it holds. The phase closes with a source and entitlement inventory that the clinical and security owners have reviewed and signed off as complete. Gaps, such as local accounts or shared logins, are logged as open findings rather than left out.
Build the role model from actual access
Rather than starting from job titles in an HR system, the team clusters the access patterns that people actually hold and tests them with clinical leads, nurse managers and compliance staff. Roles are drafted for clinicians, residents, rotating staff and agency workers, with the EHR security classes mapped to each role. The output is an approved role catalog that records who owns each role, which entitlements it grants and which combinations need an exception. Roles that cannot be explained to a clinical lead are sent back for redesign.
Build connectors and test in a sandbox
The team configures midPoint connectors for the directories and target systems in scope, using the ConnId framework and the connectors documented for LDAP, Active Directory, SCIM2 or the EHR's supported interface. Provisioning rules for joiners, movers and leavers are run against a non-production copy of each target. Test cases cover role changes, rehires, temporary assignments and failed downstream updates. The phase closes when test results show each rule producing the expected account state in every sandbox system, with the results retained as test evidence.
Reconcile and clean up orphaned accounts
Before cutover, the team compares target accounts against the HR source and flags orphaned accounts, duplicate identities, dormant accounts and accounts holding access that no approved role explains. Each finding is assigned to a named owner for disposition: retain with a documented reason, disable, or remove. Emergency or break-glass accounts are documented separately and kept under the controls the HIPAA technical safeguards require. The output is a reconciled baseline, with the decisions and their approvers recorded, so the first midPoint run does not inherit unexplained access.
Go live with joiner, mover and leaver by unit
Automated provisioning is enabled one clinical unit or workforce group at a time, starting with a group whose roles are most stable. Each cutover includes a hold period for manual review of changes, a rollback path, and a check that leaver removals reach every connected system, including the EHR. Movers are tested closely because an old unit's access must be removed when a clinician transfers. The phase closes when the unit's provisioning logs show approved changes matched to HR events and no unexplained grants or removals remain open.
Run the first certification campaign
The first access certification campaign covers the migrated units and asks department managers and system owners to approve or revoke each entitlement, with revocations applied through midPoint. The team confirms that reviewers can see the role, the reason it was granted and the last activity on the account. Decisions, reviewer identities, timestamps and remediation tickets are stored as the campaign record. The output is a completed campaign report, with an exceptions list that feeds the next review cycle. Confirm with your compliance lead which evidence the assessor expects before the campaign is designed.
What auditors and OCR reviewers ask for and which component produces it
This table maps the records that OCR reviewers and assessors typically request for healthcare access management to the component that produces each one: midPoint, the SSO server, the log platform or the HR feed. Use it to confirm where each record originates before an audit, since HIPAA has no certification and evidence supports OCR compliance reviews and any optional HITRUST assessment.
| Evidence requested | Produced by | What the reviewer checks |
|---|---|---|
| Role definitions for clinical, resident and agency roles | midPoint role and policy rules, documented in change records | Each role maps to a defined EHR access need, with owners and review dates |
| Approval records for access grants and changes | midPoint access request and approval workflow | Who approved, what was requested and whether the approver had authority over the system |
| Joiner, mover and leaver provisioning logs with timestamps | midPoint audit and task logs, fed by the HR source | Access was granted on start, changed on role moves and removed on departure |
| Timely removal of access for departed staff | midPoint deprovisioning events, cross-checked against EHR and SSO session records | Removal happened promptly after the separation date, including agency and contract staff |
| Periodic access review decisions and reviewer sign-offs | midPoint certification campaigns, retained as exported reports | Reviews covered all EHR roles, reviewers acted on excess access and the decisions were retained |
| Authentication events for ePHI system access | SSO server logs such as sign-ins, MFA challenges and failures | Unique user identity, MFA use for remote access and no shared accounts |
| Audit records of ePHI system access and changes | Log platform collecting EHR, SSO and database audit logs | Logs are retained, reviewed and tied to unique user IDs, as the audit controls standard requires |
| Business associate agreement records and vendor account inventory | Organization contract register, with vendor accounts tracked in midPoint | Agreements require Security Rule compliance and incident reporting, and vendor accounts are reviewed |
What do healthcare teams ask before hiring an identity governance partner?
What drives the cost of an identity governance project for a hospital?
The main drivers are the number of target systems and connectors, how complex the EHR role model is, how much data cleanup the directories need, and how long support runs after go-live. midPoint has no license fee and no enterprise edition, so the spend is professional services and infrastructure rather than per-user software licensing. One-time work includes connector build, role modeling, data cleanup, testing and training. Recurring costs include hosting, database operations, upgrades and support, which may be delivered under a retainer. Ask any partner for a fixed-scope quote that lists each connector, each role family and each source feed separately, so you can see what each line item covers.
How long does healthcare identity governance take to deliver?
The pace is set by the number of systems to connect, the state of the HR and EHR data, and how quickly clinical and security owners can sign off on roles. A project with a clean authoritative HR feed and a small set of target systems moves faster than one that must reconcile years of shared accounts across several directories. No duration is fixed in this guide, so ask the partner to tie the timeline to a written scope with named milestones for source feeds, role approval, pilot provisioning and the first access review. Treat any timeline that does not list its dependencies as an estimate, not a commitment.
What does the hospital need to supply before the work starts?
The hospital needs to supply four things: a reliable authoritative source from HR or the staffing system that records starts, role changes, leaves and agency contract end dates; administrative access to the EHR and the other target systems in test and production; named clinical and operational owners who can approve role definitions; and a security owner who signs off on access policy. Agency and locum staff often sit outside the HR system, so the owner of that contractor data should be identified early. If these inputs arrive late, the schedule moves, and the partner should state that dependency in the scope.
Can our internal team run identity governance after handover?
Yes, if the handover is planned for it. A partner can document the connector configuration, role model, workflows, certification campaigns and runbooks, and train named administrators to operate them. Internal teams usually need skills in Java-based application operations, PostgreSQL administration, directory services and EHR account administration. Ask the partner what documentation, training and knowledge transfer are included in the fixed scope, and whether ongoing support or upgrades will be handled through a separate retainer. Confirm that your team can read and maintain the role logic before go-live, because roles are the part that changes most often.
How does midPoint licensing compare with commercial identity governance suites?
midPoint is licensed under the European Union Public License 1.2 or later, with Apache 2.0 as a secondary license, and Evolveum states that it has no enterprise edition. The software itself carries no license fee, so your costs shift to implementation, support and hosting. Evolveum sells Product Support subscriptions, which provide bug resolution with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. Commercial IGA suites often price per user and bundle lifecycle and governance modules. Request a line-by-line comparison that covers software fees, subscriptions, implementation, hosting and internal staffing over the same period.
How are midPoint LTS upgrades planned for a clinical environment?
Plan around the support window of the release you run. midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and midPoint 4.9 support ends 18 October 2026. A healthcare team should move off unsupported releases on a schedule that includes a test environment, a regression pass over connectors and role logic, and a change window agreed with clinical operations. midPoint 4.11 requires Java 25 according to the system requirements, so runtime upgrades need their own test cycle. Ask the partner for the upgrade calendar, the test evidence it produces and who approves each production change.
What should we check first in a healthcare identity governance partner?
Start with evidence of work on the same kind of environment: EHR role mapping, joiner and leaver automation tied to HR or staffing records, and access reviews that a clinical manager can complete. Ask how they handle shared and generic accounts, emergency access, and removal of access when staff leave or move. Check whether they can produce records that show who approved each role and when access was removed, since HIPAA access control and workforce termination rules depend on that history. Note that HIPAA has no certification, so any claim of certification should be treated as a red flag. Ask the partner to describe what it will document and what the hospital's compliance team must still verify.
What to ask an implementation partner before signing
Start with the clinical role model, because it decides whether midPoint enforces need-to-know or just mirrors whatever was granted before. Ask the partner how they derive roles from existing EHR access: whether they export entitlements from the EHR and directory, cluster users by actual use, and bring clinical leads in to confirm each role before it is built. Ask which EHR and agency staffing connectors they have run in production, not only in a lab, and which ConnId connectors they expect to write themselves. The connector list in the written scope should name each target system and its status, so you can see what is supported, what is community maintained and what is custom work.
Next, ask how the partner handles agency and locum accounts with fixed end dates, and how break-glass access is approved and logged. Ask for the exact lifecycle rule that expires an agency account on its contract end date, what happens when the agency extends the contract, and how the disabled account is removed from the EHR rather than only from the directory. For break-glass, ask who may request emergency access, which approver is required after the fact, how the event is written to the audit trail, and how it feeds the review of ePHI access that 45 CFR 164.312 expects. Ask how certifications are routed to clinical managers when a manager is on leave or has moved units. Confirm that the SSO server, such as Keycloak, handles authentication and multi-factor enforcement while midPoint provisions and reviews accounts, since midPoint does not act as the SSO server.
Finally, request a written, fixed scope that lists systems, connectors, roles, certification campaigns, deliverables and acceptance tests, plus the upgrade plan. Ask how the partner moves from midPoint 4.8, the long-term support release supported until 17 October 2028, toward 4.10 or later, including the Java and PostgreSQL requirements for each target version and how they test connectors after each upgrade. Confirm who handles support after go-live and whether it is a retainer. Ask for evidence that a regulator-facing record can be produced without a rebuild, and confirm with your privacy and legal teams which obligations apply, since DeployOpen prepares controls and records for assessments but does not issue audit reports or certifications.
How DeployOpen scopes and supports healthcare identity governance
This sequence turns a healthcare identity governance idea into a written, fixed-scope plan that covers the source systems, EHR roles and evidence your team needs before any midPoint configuration begins. It also sets out how the platform is supported after go-live.
Confirm the scope and the compliance boundary
DeployOpen, a Chainscore Labs company, starts with a discovery session with your security, compliance, HR and clinical informatics leads. The team agrees which workforce groups, EHR and clinical systems, directories and regions are in scope, and which controls the work is meant to support. The output is a written scope statement that names what is included and excluded. The step is complete when your sponsor signs off on that statement.
Map authoritative sources and joiner-mover-leaver events
The DeployOpen team documents where identity truth lives, such as the HR system, credentialing records, agency staffing feeds and the EHR, and which event triggers each joiner, mover or leaver action. Your team confirms the owner of each source and how temporary or rotating clinicians are represented. The output is a source and event register that you approve. The step is complete when every access-changing event has a named source and an owner.
Design the healthcare role model and EHR mapping
Working with your clinical and application owners, DeployOpen drafts roles that tie clinician, resident and agency job functions to EHR security classes, departments and care-team relationships. The design records which access requires an approver and which access must be removed when a role ends. The output is a role catalogue with approval rules, reviewed by application owners. The step is complete when each EHR role has a documented business purpose and approver.
Assess target systems and connector coverage
DeployOpen inventories each target system and checks whether midPoint has a supported connector, a community connector or no existing path, using the connector documentation as the starting point. Where a connector is missing, the team describes the integration work and the testing it needs. Your platform owners confirm the vendor interfaces they permit. The output is a connector assessment table. The step is complete when every in-scope system has a documented integration method and an owner.
Build the deployment in your environment
The team installs midPoint with its database, directories and connectors inside your cloud accounts, data centers or private networks, following the vendor's system requirements for Java and PostgreSQL. DeployOpen hardens the environment, sets up backups and documents configuration, administration and recovery procedures. The output is a tested non-production environment and an install record. The step is complete when your operators can run a recovery test from the runbook.
Test provisioning and certification evidence
DeployOpen runs test joiner, mover and leaver scenarios against non-production target systems, including a sample of EHR role changes and a test access review. Your compliance lead checks that the logs, approvals and certification decisions can be retrieved and explained. The output is a test report with defects, fixes and retest results. The step is complete when your compliance lead accepts the evidence sample.
Hand over, document and go live
Before production cutover, DeployOpen delivers the design documents, configuration records, operating procedures and training material agreed in the scope statement. Your team runs the first production changes with DeployOpen support in the agreed window. The output is the handover pack and a signed acceptance record. The step is complete when the written deliverables are accepted in writing.
Support, upgrade and prepare ongoing evidence
After go-live, support and upgrades can be covered by a retainer agreed in writing, which may include patching, midPoint upgrades, connector maintenance and periodic testing. DeployOpen prepares evidence for your assessors, but independent auditors and certification bodies issue any audit report or certification. The output is a service schedule and an evidence calendar. The step is complete when both parties have signed the retainer or ongoing support terms.
