RBAC Permission Design in the Codeape Chronic Disease Cloud Management System

The article introduces the permission design of the Codeape chronic disease cloud management system, focusing on how role‑based access control (RBAC) is applied to manage user, role, and permission relationships.

Five classic permission models are listed (ACL, DAC, MAC, ABAC, RBAC), with RBAC being the primary model used in the system.

RBAC Core Elements : Users, Roles (a collection of permissions such as administrator, developer, audit admin), and Permissions (menus, buttons, CRUD operations). Users acquire permissions by being assigned appropriate roles.

User Table (codeape/sys_user) stores user information such as user_id , username , hos_id , dept_id , etc. Important fields include username (unique per hospital), hos_id (tenant identifier), and dept_id (department/ward identifier).

Role Table (codeape/sys_role) defines roles with fields like role_id , role_name , role_code , and role_desc . The many‑to‑many relationship between users and roles is stored in codeape/sys_user_role .

The system defines seven built‑in roles (administrator, system administrator, doctor, nurse, etc.) and stores them in the role table.

Permission Types :

Menu permissions – control visibility of client menus.

Button/API permissions – control actions such as adding a patient.

Department/Ward permissions – restrict doctors and nurses to data belonging to their own departments or wards.

Button and API permissions are identified by codes like inhos_patinfohot_get . Spring Security’s @PreAuthorize annotation is used to enforce these permissions, e.g.:

@Operation(summary = "分页查询在院患者", description = "分页查询在院患者")
@GetMapping("/page")
@InjectAuth
@PreAuthorize("@pms.hasPermission('inhos_patinfohot_get')")
public R
> getPatInfoHotPage(Page
page, PatInfoDTO dto) {
    return R.ok(patInfoHotService.listPage(page, dto));
}

The underlying PermissionService checks the current Authentication object, extracts the authority list, and matches it against the required permission codes.

Department/Ward permissions are stored in codeape/sys_user_dept and the hierarchical relationship between departments and wards is kept in codeape/sys_dept_relation . When a user logs in, their department/ward permissions are loaded into the security context.

For data filtering, a base DTO com.code.ape.codeape.common.core.entity.BaseParam contains fields hosId , userId , and dataAuth . The @InjectAuth AOP aspect automatically populates these fields from the logged‑in user (or device) before controller execution.

Device (PDA) permissions combine the device’s department settings with the user’s permissions. The system supports online and offline modes; in offline mode the device caches only the data it is authorized to access, based on the selected department and associated wards.

Overall, the article demonstrates a comprehensive RBAC implementation that integrates role‑based permissions, department/ward scoping, Spring Security annotations, and AOP‑driven authentication injection to secure a healthcare SaaS platform.

Conclusion : Understanding the RBAC design and department/ward permission logic is essential for building secure medical systems, as most healthcare applications follow a similar pattern.