Operations · Access Management
Eight roles. Every endpoint enforces. No exceptions.
From administrator to patient, every role has defined boundaries enforced at every endpoint. No shared logins. No manual overrides.
HIPAA mapping
What this satisfies in the Security Rule.
5 citations, each with the specific Access Management behavior that satisfies it. The mapping is the receipt — what you can show an auditor without assembling anything new.
§164.308(a)(3)Workforce security
Implements policies and procedures to ensure all workforce members have appropriate access. The role model is that policy, made operational.
§164.308(a)(4)Information access management
Implements policies and procedures for authorizing access to ePHI. Role authorization plus endpoint enforcement covers the standard.
§164.312(a)(1)Access control
Implements technical policies and procedures to allow access only to authorized persons. The endpoint-level checks are those technical controls.
§164.312(a)(2)(i)Unique user identification
Assigns unique identifier for each user. Every workforce member has a unique account; no shared logins are permitted.
§164.502(b)Minimum necessary
Roles are scoped to the minimum access each function requires. The architecture doesn't permit role assignments that exceed function need.
What it does
Role-based access without the shortcuts.
Most platforms talk about role-based access control. Most platforms also have shortcuts — admin overrides, shared accounts, “just this once” exceptions. The shortcuts produce the breaches. A workforce member with broader access than their role requires is the textbook §164.502(b) minimum-necessary violation.
Patient Protect's access model has no shortcuts. Eight roles, each defined precisely. Every endpoint checks role before serving content. No admin override grants access beyond the admin's own role definition. The minimum-necessary standard is architectural, not policy.
The architecture also includes the ePHI Restricted flag — a per-member toggle that further restricts a member's access without requiring a role change. Useful for staff in investigation, transitioning roles, or in roles where ePHI access isn't needed by default. The flag is durable, audit-logged, and enforced at every endpoint.
How it works
6 mechanisms keep Access Management working.
Eight precisely-defined roles.
Office Administrator, Office Staff, Security Officer, Privacy Officer, Medical Care Staff, Primary Care Provider, Referred Care Provider, Patient. Each role is documented down to the permission level. The numeric codes (100, 200, 500, 525, 700, 800, 850, 999) make access checks fast and unambiguous.
Endpoint-level enforcement.
Every page request, every API call, every action is checked against the requesting role. The check is architectural — implemented in middleware, not in application code. There is no “forgot to add the check” path because the check happens before application code runs.
No admin override.
The Office Administrator's broad access does not include the ability to grant other workforce members access beyond their role. Role changes go through the Personnel module's audit flow. The administrator can change roles; they cannot grant exceptions to existing roles.
Unique user identification.
Every workforce member has a unique account. Shared logins are not permitted by the platform — there is no mechanism for a shared credential. Sessions are tied to specific accounts; audit logging captures the specific workforce member behind every action.
ePHI Restricted flag for narrow exceptions.
Where a member's role would normally permit ePHI access but their specific function doesn't require it, the Restricted flag applies. Restricted members can perform their non-ePHI duties without seeing patient records. Useful for support staff, contract administrators, and members in investigation periods.
AppSensor on every endpoint.
Unexpected input — requests outside the role's normal pattern, malformed payloads, attempted privilege escalation — is caught by AppSensor on the endpoint. The platform doesn't just deny the request; it logs the attempt as a security event for investigation.
Who this is for
Built for the practices that need it most.
Every practice.
Access management is foundational. There is no practice on Patient Protect that doesn't use it. The differentiator is how the controls hold up under stress — staff transitions, vendor relationships, shared workstations, audit inquiries.
Practices that have inherited messy permissions.
Practice acquisitions often arrive with ad-hoc permissions accumulated over years — the workforce member who got broader access during a project and never had it removed, the contractor who shared a login with the office staff. The platform's role model doesn't permit those patterns; migration onto the platform forces clean assignment.
Practices recovering from access-related incidents.
Post-incident, access tightening is typically required. The platform's architecture is what tight access looks like as a default; recovery is mostly about confirming role assignments are accurate.
Connected to
No module is an island.
Access Managementworks because it's connected. Every signal feeds another module; every closure becomes evidence somewhere else.
Defense layer
ePHI Audit Logs
Every access decision is logged in the audit; access controls and audit controls work together.
Learn moreOperations layer
Workforce Training
Role determines required training; training tracking is role-aware.
Learn moreNetwork layer
Patient Management
Patient-record access is role-scoped; the eighth role (Patient) accesses only their own record.
Learn moreWhat you get
6outcomes you'll feel in week one.
Eight precisely-defined roles.
No fuzzy permissions, no ad-hoc exceptions.
Endpoint-level enforcement.
Checks at the request boundary, not in the UI.
No shared logins.
Unique user identification under §164.312(a)(2)(i) by architecture.
ePHI Restricted flag.
Narrow scope-limiting without requiring role change.
Minimum-necessary architecture.
§164.502(b) handled by the role model itself.
AppSensor protection.
Privilege-escalation attempts detected and logged.
Can I create custom roles?
What if I need a workforce member to have access across roles?
Can I grant temporary elevated access?
How does the Patient role work?
What's the Ninja role?
How are role changes audited?
Continue exploring
Related features in the platform.
Defense
ePHI Audit Logs
Immutable per-session, per-tab audit trail. OCR-ready by default. No assembly required when the auditor calls.
Learn moreOperations
Workforce Training
HIPAA training inside the platform — assigned by role, completed by deadline, evidence generated by default. The first documentation auditors ask for, ready when they ask.
Learn moreNetwork
Patient Management
One place for patient records. Role-based access. Every view, edit, export logged automatically. The audit trail builds itself while you do the work.
Learn moreNext step
Eight roles. Every endpoint enforces. No exceptions.
The default access model is what tight access looks like. Most practices configure their workforce roles inside the first week.
No contracts. No consultants. Starting at $39/mo.