Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T04:06:07Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:36, 6 July 2026
Line 76:		Line 76:

	Roles are granted through organization, facility, and patient memberships, and permissions cascade down the organization tree — a role held at a higher level applies to the facilities and teams beneath it.		Roles are granted through organization, facility, and patient memberships, and permissions cascade down the organization tree — a role held at a higher level applies to the facilities and teams beneath it.

			{{Navbox access governance}}

	{{Related}}		{{Related}}
			Wiki: ohcnwiki.tellmey.fyi

Admin: OHC identity seed

2026-07-04T22:43:00Z

OHC identity seed

New page

{{Doc header
|type=concept
|domain=access-governance
|title=User
|order=4
|introduced=3.0
|concept=Concepts/Patient
|reference=References/User & Skills
}}

A '''user''' in Care is an account that a person — or an automated integration — uses to sign in and act on the platform. It is the identity behind every action in the record: the doctor who writes a note, the nurse who records an observation, and the operator who registers a patient all do so as a user.

== What it represents ==

In Care's FHIR-aligned model, a user corresponds most closely to the '''Practitioner''' resource — the person delivering or supporting care. The account captures:

* '''Identity''' — name (with a prefix such as "Dr."), username, gender, date of birth, and a profile photo
* '''Contact''' — the phone number and email used for sign-in and notifications
* '''Credentials''' — qualification, medical council registration, and working hours, for staff who provide care
* '''Account context''' — the user's geographic organization, who created the account, and whether it is human or automated

A user is not the same as their permissions. The account holds ''who someone is''; what they are allowed to do comes from the roles they hold in organizations and facilities — see [[Concepts/Roles & Permissions|Access control]]. Granting or removing a role changes a user's reach without touching their identity, which is why the same account can move between facilities or change duties without being recreated.

== Types ==

Not every account belongs to a person logging in by hand:

* '''Human accounts''' — clinicians and operators who sign in with a username and password, and optionally a one-time code
* '''Service accounts''' — machine or integration identities used by other systems to call Care's API on a defined, auditable basis rather than as a person

Both leave the same accountable trail; the distinction matters for how they sign in and for telling automated activity apart from human activity in an audit.

== How it connects ==

A user is the actor that ties the rest of the record together:

* '''Authorship''' — encounters, observations, orders, and notes record the user who created or updated them, giving every entry an accountable owner
* '''Organization & facility''' — a user is granted roles inside [[Concepts/Organization|organizations]] and [[Concepts/Facility|facilities]]; these memberships decide which patients and data the user can reach
* '''Scheduling''' — clinician users back [[Concepts/Schedule & Availability|schedules]] and [[Concepts/Appointment Booking|bookings]], so credentials and working hours shape who can be booked
* '''Account creator''' — each account records the user who created it, preserving an onboarding trail

== Sign-in and security ==

Care protects accounts with layered sign-in controls:

* '''Password''' — every human account sets a password that must pass a strength check; service accounts may sign in without one
* '''Multi-factor authentication''' — users can enable a time-based one-time code (TOTP) from an authenticator app, with single-use backup codes for recovery
* '''Verification''' — accounts carry a verified status, and a user can be reached for a password reset through their registered username

== Permissions ==

User permissions govern who can create other accounts and assign their roles. They do not control what a user can do clinically — that flows from the roles a user holds. Listing and retrieving user accounts are not gated by a dedicated permission in the viewset, and updating or deleting an account is restricted to the account owner or a superuser rather than to a role permission.

{| class="wikitable"
|-
! Permission
! Description
! System Roles
|-
| <code>can_create_user</code>
| Create a new human user account
| Admin, Facility Admin, Administrator
|-
| <code>can_create_service_account</code>
| Create a new service (machine) account
| Admin, Facility Admin, Administrator
|-
| <code>can_manage_organization_users</code>
| Assign the requested roles to the new account within an organization
| Admin, Administrator, Facility Admin, Admin (role org)
|-
| <code>can_manage_connected_role_organizations</code>
| Assign roles in a connected role organization when onboarding the account
| Admin (role org), Manager (role org)
|}

Roles are granted through organization, facility, and patient memberships, and permissions cascade down the organization tree — a role held at a higher level applies to the facilities and teams beneath it.

{{Related}}

Concepts/User - Revision history

Admin: Automated edit (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed