Least privilege, enforced in the application
Access control in JamEMR starts from a simple rule: a user or service gets the access its job requires, and nothing more. This is enforced in the application itself, not left to convention.
What is in place today
Role-based access control for people
- Every user operates under a role with least-privilege permissions.
- Roles map to real clinic jobs. A concrete example: front-desk staff can manage scheduling and demographics but cannot access clinical AI functions such as ambient documentation. That boundary is enforced by the application and returns a denial, not a warning.
- Clinical actions carry clinical accountability: ambient-note drafts are reviewed, edited, and signed by the responsible clinician, and each of those steps is audited.
Registered tokens for services
- Service-to-service calls require a registered API token. Tokens are issued through a registry, scoped to their purpose, and revocable. A caller presenting no token — or an unregistered one — is rejected.
- This closes a common gap: internal services authenticate the same way external ones do, rather than being trusted by network position alone.
Approval gates for privileged change
- Privileged operational changes — the kind that alter how the system runs — require explicit human approval before they take effect. Administrative power is deliberate, not ambient.
Accountability
- Designated Privacy Officer and Security Officer roles are assigned and active, and access decisions that need governance have named owners.
On our roadmap
- Documented access-management policy pack (in progress): formal, auditable procedures for role assignment, access review cadence, and offboarding, turning current practice into written policy.
- Third-party penetration testing before general availability, including testing of role boundaries and token enforcement.
- Expanded authentication options for practices with specific identity requirements, evaluated as pilot feedback dictates. We will document specifics here when they are implemented.
Verifying it yourself
Pilot practices can — and should — test these boundaries directly: log in as a front-desk role and attempt a clinical AI action; the request will be denied and the attempt logged. We prefer controls a customer can verify over controls they have to take on faith. Questions: security@jamemr.com.