Role model
Provider and practice access are separate.
provider_userA verified user mapped to a specific provider and SCP. Used for provider-scoped catalog, availability, booking, proof-of-service, and EHR-link work.scp_adminA verified user mapped to an SCP or practice. Can manage multiple providers for the same organization when role permissions allow it.provider_agentA delegated provider/SCP token for headless operational integrations. It must carry the relevant provider permissions.workforce_adminInternal support/remediation actor. Useful operationally, but not the default provider onboarding product model.SCP roles
Practice roles determine organization-level permissions.
scp_ownerFull SCP authority: prepare onboarding, manage catalog and availability, view bookings, submit proof of service, manage EHR links.scp_adminSame operational authority as owner for v1 route policy.clinicianPrepare onboarding, manage availability, view bookings, submit proof of service, manage EHR provider links.schedulerPrepare onboarding, manage availability, and view bookings.billingView bookings for billing and reconciliation work.read_onlyView bookings only.Provider roles
Provider roles are scoped to one provider within an SCP.
clinicianPrepare onboarding, manage catalog and availability, view bookings, submit proof of service, manage EHR provider links.schedulerPrepare onboarding, manage availability, and view bookings.billingView bookings.read_onlyView bookings only.Activation authority
Production activation requires a mapped provider or SCP actor.
The activation route accepts approved OIDC identity sessions that resolve to provider access or workforce access, and provider-agent tokens where route policy allows delegated provider authority.
curl https://api.opendoc.com/provider-onboarding/activate \
-X POST \
-H "Authorization: Bearer $OPENDOC_PROVIDER_OR_SCP_TOKEN" \
-H "Content-Type: application/json" \
-d '{ ... }'
Why this matters: public NPI data proves that a provider exists. It does not prove that the current caller is allowed to publish prices, availability, or front-office contact details for that provider.
Verification checklist
Minimum v1 verifier before bookable activation.
1
Resolve identity.The caller authenticates through an approved identity provider.
2
Map protocol access.OpenDoc maps the identity subject to provider_user or scp_admin rows.
3
Check scope.The providerId or scpId on the action must be inside the caller's active membership scope.
4
Check permission.Route policy checks permissions such as provider.manage_catalog, scp.manage_catalog, or provider.manage_availability.
5
Activate only after gates pass.Bookable service, cash price, availability, and front-office contact are required for live activation.