Hi- We're going to have a broader product with an integrated EHR interface, and for the EHR-part I'm currently building a system that creates email-free users in Medplum so that I can use Medplum's RBAC and on-behalf-of to control access to resources in a MSO environment as well as give better auditing. We're planning on eventually using the paid Medplum plans so I don't need to fight with self-hosting. After doing a bit of research, I discovered that it's possible for this key (as well as our admins) to permanently delete records in Medplum. And it doesn't look like there is a way to block all admins and credentials from having that permission. Nor does it look like there is a way to prevent anyone with access to the account from seeing the secret for that account. Is it possible to have a service account with this permission that does not have a viewable secret that I don't use for anything, and then deny access to that functionality for everyone/everything else on the project, but still give them other administrative permissions? Or to backup a paid prod account with all my Medplum projects to an immutable datastore of some sort such as my BAA-covered AWS account on a regular basis (which would make this a bit less of a problem, and probably be better in general)?

@NickCat , have you taken a look at this - https://www.medplum.com/docs/access/access-policies#resource-type

Specifically, you can allow / disallow specific FHIR interactions: https://www.medplum.com/docs/access/access-policies#fhir-interactions

Yeah, but my impression is that you need “Admin” rights on the project to create and add Medplum users to projects (which is not a FHIR api I don’t believe, it’s an internal Medplum one.) Would access policies still work here? I cannot create a client credentials token that does not have admin rights to the project which can do user management

@NickCat I'm not an expert but one approach: if you want to restrict user permissions in any way do not make them admins and use access policies; if you need admin-only functionality like user management, you can put these functions in a bot with an admin client application and call that.

I guess what I’m getting at is that the bot approach doesn’t totally solve the underlying concern for me, which is that there’s a plaintext admin credential that can hard delete PHI, and I’d still need to use that credential as part of normal user management. Moving it to a bot just puts that key in one more place where it could be accessed. So I’m mainly trying to figure out whether there’s a way for me to handle day-to-day user management without needing a credential with full delete permissions floating around, or whether there’s a supported path to regularly back up our project data into something immutable on our side (S3 object lock, etc). If the answer is "no, most customers rely on Medplum’s internal backup and restore process," that’s totally fine. I just want to make sure I’m designing around what’s actually available instead of guessing. Really appreciate the guidance here and thank you for the help.

When you say plaintext, an admin user can have username/password credentials for interactive login, but you can also assign a client application to be an admin user, in which case you'd be using a client ID and secret for API calls. You're not putting credentials into a bot, you instead configure the bot with system access or create a dedicated admin service account and run it as that. There's also a system secrets store so you'd never be hardcoding plaintext secrets in a bot. But I take your point that it might be nice to have config for the super admin eg Project Admins can not delete X - but the problem then becomes determining which resource may contain PHI, and that's where the policies provide the fine-grained control. For our projects, we only give Admin accounts to technical staff members if they need to occasionally look under the hood, so if they were to accidentally go and delete resources we'd have to take the backup/restore path which would be a headache for sure. Again I'm no medplum expert so someone from the team might have a better solution/guidance for you!