I am currently working on an OIDC-based authentication integration that allows OpenEMR users to sign in through Keycloak. Since Keycloak can broker authentication to multiple identity providers, the goal is to support login through different enterprise identity providers while keeping the OpenEMR integration based on standard OIDC.
I have a working implementation with Keycloak, but I would like to make the approach generic so that OpenEMR can work with other OIDC-compliant identity providers as well.
I would appreciate feedback on areas such as:
The preferred architecture for external OIDC authentication in OpenEMR
User provisioning or shadow-user creation
Mapping external identities to existing OpenEMR users
Role and ACL management
Handling technical or service accounts
Compatibility with different enterprise identity providers
The broader reason I started this project is to test an idea for adding AI capabilities to enterprise applications with minimal application-specific changes. I have developed an AI integration layer and am currently testing it with OpenEMR, with a strong focus on security, privacy, identity, authorization, and controlled access to patient data.
Feedback on the AI integration would also be very valuable, especially regarding:
Useful AI use cases for OpenEMR
Security and privacy concerns
Auditability and access control
Clinical workflow integration
Areas where AI assistance could provide the most value without creating additional risk
Any comments, suggestions, or technical insights from the OpenEMR community would be greatly appreciated.
I’ve been working in the opposite direction. My app is the client, with OpenEMR as the OIDC provider. I went through the same “make this generic” exercise (but in the opposite direction) when integrating my app with multiple EMR instances. For me, the most important change was moving the connection config out of env vars and into a per-user database row. Each user has their own server URL, client id, encrypted client secret, etc with the env values as a fallback.
Identity mapping was where I got burned. When a user who is already signed in links an external identity, the auth framework builds a fresh token from the provider profile before your callback runs, without the existing local user id. That caused this issue: attempt to match on provider profile email → email doesn’t match with client email → second account created for the same user. My fix: decode the existing session separately → thread that user id into the callback → restore the local client identity over the provider values.
Regarding AI, I gave the AI layer no identity of its own. Every API call rides the signed-in user’s bearer token, so the model can only see and touch what the user can. An AI layer with its own service account would have to reimplement your ACL model and could eventually drift from it. This approach doesn’t solve auditability. Writes trace to the user, so an audit can’t distinguish human vs. AI edits. Would like to hear any of thoughts/suggestions about this. For “value without additional risk,” my approach was to gate all chart writes for doctor approval (human in the loop).
Hi @banchanattu and @Andy.Le . We discussed this thread on the community call the other day and you can find a recap of that in the detailed summary of the meeting. We invite you to join us at an upcoming meeting if you can and we can update this thread as we progress.