A method and apparatus for controlling management authority of a clinical research project
Patent Information
- Application Number
- CN202311685709.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-12-08
- Publication Date
- 2026-10-13
- Estimated Expiration
- 2043-12-08
AI Technical Summary
[0020]本申请的目的是针对现有技术中的不足,提供一种临床研究项目管理权限的控制方法、装置、计算机设备和计算机可读存储介质,以至少解决相关技术中RBAC模型存在的角色权限控制混乱的问题
[0049]本申请采用以上技术方案,与现有技术相比,本申请实施例提供的临床研究项目管理权限的控制方法,通过对用户标识、租户信息、业务类型、服务范围、系统、项目、中心、角色等进行组合,根据预先建立的映射关系,确定该组合对应的权限,以达到对不同资源的访问控制,解决了相关技术中RBAC模型存在的角色权限控制混乱的问题,实现了临床研究项目管理权限的统一控制的目的。
Smart Images

Figure CN117648707B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of clinical research project management technology, and in particular to a method and apparatus for controlling the management authority of clinical research projects. Background Technology
[0002] The management of existing clinical research projects requires overseeing the entire process, including project creation, acceptance, initiation, staffing, task management, center addition, staffing, center management, visit management, participant management, planning, document management, project initiation process management, monitoring, and a series of other process controls, content management, process management, and historical tracking. Clinical research project management generally exhibits the following characteristics:
[0003] 1. Disciplinary Diversity: This typically involves multiple disciplines, including medicine, biology, ethics, statistics, and even clinical research on medical devices. Managers need to coordinate cooperation among all parties throughout the management process to ensure the project proceeds smoothly, stably, effectively, and correctly.
[0004] 2. Regulations and Ethics: Clinical research projects must strictly comply with and meet the requirements of regulations and ethics to ensure patient safety and their rights.
[0005] 3. Time Accuracy: Clinical studies typically have strict and clearly defined time requirements. During project management, everything from task execution and visit scheduling to medication timing requires rigorous management.
[0006] 4. Records and Documentation: A large number of documents, records, case studies, and pathology records will be generated throughout the clinical research process.
[0007] 5. Data Management and Analysis: The entire clinical research process requires the collection and analysis of large-scale data. Therefore, the accuracy, completeness, and security of the data become paramount; data accuracy is essential to ensure the validity and reliability of the clinical research results.
[0008] Existing RBAC model components include:
[0009] Role: A role is a set of permissions. Users are typically assigned to one or more roles, allowing them to obtain a combination of permissions when roles are combined.
[0010] Permissions: Permissions refer to the rights to access and manipulate resources (such as files, functions, data, etc.). Each account logging into the system is assigned a set of roles.
[0011] User: System users and temporary system visitors. Users need to obtain or be assigned relevant permissions to access specific resources.
[0012] Authorization Policy: The authorization policy defines which resources different roles can access and specifies how roles and permissions are allocated and managed.
[0013] Based on the existing RBAC role authorization model, the following shortcomings exist in current projects:
[0014] 1. Once a user logs in and authorizes, their role permissions are determined and cannot be changed.
[0015] 2. The same user may participate in different business roles in different projects.
[0016] 3. The same user may have a role in a project, or a role in a research center under the project. That is, the user may have multiple different roles in a project.
[0017] 4. Different types of projects have different business characteristics and business scopes.
[0018] The existing RBAC model can only achieve a simple one-level mapping of roles and resources to control the current role's permissions. However, for SaaS-based clinical research project collaboration management platforms, SaaS-based tenant elements have been added, as well as more detailed classifications and resource control such as "system layer," "project layer," and "center layer." Therefore, the existing RBAC model is difficult to meet the needs of the scenario and business, which will lead to permission confusion at different levels, or rather, the inability to obtain the permissions that should be obtained.
[0019] Currently, no effective solution has been proposed to address the problem of chaotic role and access control in the RBAC model of related technologies. Summary of the Invention
[0020] The purpose of this application is to address the shortcomings of the prior art by providing a method, apparatus, computer device, and computer-readable storage medium for controlling access permissions in clinical research projects, so as to at least solve the problem of chaotic role and access control in the RBAC model of related technologies.
[0021] To achieve the above objectives, the technical solution adopted in this application is as follows:
[0022] In a first aspect, embodiments of this application provide a method for controlling access permissions in clinical research project management, including:
[0023] When a user's login request is detected, the user's identification information, as well as the tenant information, business type, and service scope of the user's login are obtained.
[0024] The resource level accessed by the user is determined, and the resource level includes: system, project, and center;
[0025] Determine the user's role at the accessed resource level;
[0026] The user's permissions are determined based on the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
[0027] In some embodiments, it also includes:
[0028] Establish and store a first mapping table, wherein the first mapping table is used to indicate the mapping relationship between a first combination and user permissions, and the first combination includes: user identifier, tenant information, business type, service scope, role, and resource level.
[0029] In some embodiments, the user's permissions are determined based on the resource level accessed by the user, the user's role at that resource level, the user's identification information, and the tenant information, service type, and service scope of the user's login, including:
[0030] Based on the first mapping table, determine the permissions corresponding to the target combination of the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the user's login tenant information, business type, and service scope.
[0031] In some embodiments, it also includes:
[0032] When at least one of the target combinations changes, the target combinations are updated to obtain the updated target combinations;
[0033] Based on the first mapping table, the permissions corresponding to the updated target combination are redefined.
[0034] In some embodiments, at least one of the following is also included:
[0035] A second mapping table is established and stored, wherein the second mapping table is used to indicate the mapping relationship between a second combination and user permissions at the system level, and the second combination includes: tenant information and roles;
[0036] Establish and store a third mapping table, wherein the third mapping table is used to indicate the mapping relationship between a third combination under the project level and user permissions, and the third combination includes: tenant information, role, and project identifier;
[0037] Establish and store a permission information table, wherein the permission information table is used to store at least one of the following information: permission name, permission type, permission resource type, permission identifier, and permission parent identifier.
[0038] Secondly, embodiments of this application provide a control device for managing access to clinical research projects, comprising:
[0039] The acquisition unit is used to acquire the user's identification information, as well as the tenant information, business type, and service scope of the user's login, when a user's login request is detected.
[0040] The first determining unit is used to determine the resource level accessed by the user, the resource level including: system, project, and center;
[0041] The second determining unit is used to determine the role of the user in the accessed resource level;
[0042] The third determining unit is used to determine the user's corresponding permissions based on the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
[0043] In some embodiments, it also includes:
[0044] The first establishment unit is used to establish and store a first mapping table, wherein the first mapping table is used to indicate the mapping relationship between a first combination and user permissions, and the first combination includes: user identifier, tenant information, business type, service scope, role, and resource level.
[0045] In some embodiments, the third determining unit includes:
[0046] The determination module is used to determine, based on the first mapping table, the permissions corresponding to the target combination of the resource level accessed by the user, the role of the user in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
[0047] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the control method for clinical research project management permissions as described in the first aspect above.
[0048] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the control method for clinical research project management permissions as described in the first aspect above.
[0049] This application adopts the above technical solution. Compared with the prior art, the method for controlling the access permissions of clinical research project management provided in this application combines user identifiers, tenant information, business types, service scopes, systems, projects, centers, roles, etc., and determines the permissions corresponding to the combination according to the pre-established mapping relationship, so as to achieve access control of different resources. This solves the problem of chaotic role and permission control in the RBAC model in related technologies and achieves the goal of unified control of access permissions for clinical research project management.
[0050] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description
[0051] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0052] Figure 1 This is a structural block diagram of a mobile terminal according to an embodiment of this application;
[0053] Figure 2 This is a flowchart of a method for controlling access to clinical research projects according to an embodiment of this application;
[0054] Figure 3 This is a schematic diagram of the table relationships according to an embodiment of this application;
[0055] Figure 4 This is a schematic diagram of the front-end execution process according to an embodiment of this application;
[0056] Figure 5 This is a timing diagram of the front-end processing procedure according to an embodiment of this application;
[0057] Figure 6 This is a schematic diagram of the user permission control process according to an embodiment of this application;
[0058] Figure 7 This is a structural block diagram of a control device for managing clinical research project authority according to an embodiment of this application;
[0059] Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application. Detailed Implementation
[0060] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.
[0061] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.
[0062] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.
[0063] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.
[0064] This embodiment provides a mobile terminal. Figure 1 This is a structural block diagram of a mobile terminal according to an embodiment of this application. For example... Figure 1 As shown, the mobile terminal includes: a radio frequency (RF) circuit 110, a memory 120, an input unit 130, a display unit 140, a sensor 150, an audio circuit 160, a wireless fidelity (WiFi) module 170, a processor 180, and a power supply 190, among other components. Those skilled in the art will understand that... Figure 1 The mobile terminal structure shown does not constitute a limitation on the mobile terminal and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0065] The following is combined Figure 1 A detailed introduction to each component of a mobile terminal:
[0066] RF circuit 110 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with processor 180; additionally, it transmits uplink data to the base station. Typically, RF circuitry includes, but is not limited to, antennas, at least one amplifier, transceiver, coupler, low-noise amplifier (LNA), duplexer, etc. Furthermore, RF circuit 110 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.
[0067] The memory 120 can be used to store software programs and modules. The processor 180 executes various functional applications and data processing of the mobile terminal by running the software programs and modules stored in the memory 120. The memory 120 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile terminal (such as audio data, phone book, etc.). In addition, the memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.
[0068] The input unit 130 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the mobile terminal. Specifically, the input unit 130 may include a touch panel 131 and other input devices 132. The touch panel 131, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 131), and drive the corresponding connection devices according to a pre-set program. Optionally, the touch panel 131 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 180, and can receive and execute commands sent by the processor 180. In addition, the touch panel 131 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 131, the input unit 130 may also include other input devices 132. Specifically, other input devices 132 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.
[0069] Display unit 140 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile terminal. Display unit 140 may include a display panel 141, optionally configured as a Liquid Crystal Display (LCD), Organic Light-Emitting Diode (OLED), or similar display panel 141. Further, touch panel 131 may cover display panel 141. When touch panel 131 detects a touch operation on or near it, it transmits the information to processor 180 to determine the type of touch event. Subsequently, processor 180 provides corresponding visual output on display panel 141 based on the type of touch event. Although in Figure 1 In this embodiment, the touch panel 131 and the display panel 141 are two separate components to realize the input and output functions of the mobile terminal. However, in some embodiments, the touch panel 131 and the display panel 141 can be integrated to realize the input and output functions of the mobile terminal.
[0070] The mobile terminal may also include at least one sensor 150, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 141 according to the ambient light level, and the proximity sensor can turn off the display panel 141 and / or backlight when the mobile terminal is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used for applications that identify the mobile terminal's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometers, taps), etc. Other sensors that may be configured in the mobile terminal, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.
[0071] The speaker 161 and microphone 162 in the audio circuit 160 provide an audio interface between the user and the mobile terminal. The audio circuit 160 can convert the received audio data into electrical signals and transmit them to the speaker 161, where the speaker 161 converts them into sound signals for output. On the other hand, the microphone 162 converts the collected sound signals into electrical signals, which are received by the audio circuit 160, converted into audio data, and then output to the processor 180 for processing. After processing, the audio data is transmitted via the RF circuit 110 to, for example, another mobile terminal, or the audio data is output to the memory 120 for further processing.
[0072] WiFi is a short-range wireless transmission technology. Mobile terminals using a WiFi module 170 can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 1 WiFi module 170 is shown, but it is understood that it is not a necessary component of a mobile terminal and can be omitted or replaced with other short-range wireless transmission modules, such as Zigbee modules or WAPI modules, as needed without changing the nature of the invention.
[0073] The processor 180 is the control center of the mobile terminal. It connects various parts of the mobile terminal via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 120, and by calling data stored in the memory 120, it performs various functions and processes data of the mobile terminal, thereby providing overall monitoring of the mobile terminal. Optionally, the processor 180 may include one or more processing units; preferably, the processor 180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 180.
[0074] The mobile terminal also includes a power supply 190 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 180 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.
[0075] Although not shown, mobile terminals may also include cameras, Bluetooth modules, etc., which will not be elaborated here.
[0076] In this embodiment, the processor 180 is configured as follows:
[0077] When a user's login request is detected, the user's identification information, as well as the tenant information, business type, and service scope of the user's login are obtained.
[0078] The resource level accessed by the user is determined, and the resource level includes: system, project, and center;
[0079] Determine the user's role at the accessed resource level;
[0080] The user's permissions are determined based on the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
[0081] In some embodiments, the processor 180 is further configured to:
[0082] Establish and store a first mapping table, wherein the first mapping table is used to indicate the mapping relationship between a first combination and user permissions, and the first combination includes: user identifier, tenant information, business type, service scope, role, and resource level.
[0083] In some embodiments, the processor 180 is further configured to:
[0084] Based on the first mapping table, determine the permissions corresponding to the target combination of the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the user's login tenant information, business type, and service scope.
[0085] In some embodiments, the processor 180 is further configured to:
[0086] When at least one of the target combinations changes, the target combinations are updated to obtain the updated target combinations;
[0087] Based on the first mapping table, the permissions corresponding to the updated target combination are redefined.
[0088] In some embodiments, the processor 180 is further configured to:
[0089] A second mapping table is established and stored, wherein the second mapping table is used to indicate the mapping relationship between a second combination and user permissions at the system level, and the second combination includes: tenant information and roles;
[0090] Establish and store a third mapping table, wherein the third mapping table is used to indicate the mapping relationship between a third combination under the project level and user permissions, and the third combination includes: tenant information, role, and project identifier;
[0091] Establish and store a permission information table, wherein the permission information table is used to store at least one of the following information: permission name, permission type, permission resource type, permission identifier, and permission parent identifier.
[0092] This embodiment provides a method for controlling the management permissions of clinical research projects.
[0093] First, the technical terms in this embodiment will be explained as follows:
[0094] Business type:
[0095] The main business types currently defined in the system are shown in Table 1 below:
[0096] Table 1
[0097] CO (Central Inspection) SMO (Central Management) P (patient) D (Technology Products) O (Other types)
[0098] Service Scope:
[0099] Different service scopes are defined under different business types, each with different functions, pages, configurations, and permissions. Taking the CO business type as an example, as shown in Table 2 below:
[0100] Table 2
[0101]
[0102] Role
[0103] PD: Project Director, manages project access under a tenant, and manages different assigned project managers under the tenant. The director also manages data according to different business scopes. Only PDs with specific business scope jurisdiction can assign project managers to projects under that type.
[0104] PM: Project Manager, who manages clinical research projects under the tenant to which the project manager is located.
[0105] CRA: Clinical Research Monitor. The main function of a CRA is to monitor the entire clinical research trial to ensure that the clinical trial is conducted in accordance with the trial protocol, standard operating procedures, and relevant laws and regulations, and to make relevant records and reports.
[0106] CRC: Clinical Research Coordinator. During clinical research, with the authorization of the principal investigator, CRC assists the investigator in non-medical judgment-related tasks such as project management and coordination.
[0107] Given the nature of clinical research projects, the entire process is lengthy, inevitably involving personnel changes and shifts in project members. This results in changes to project members, center members, and even system members, making the user's role highly dynamic across various system layers. Furthermore, there may be duplicate pages across different business types or service scopes; the research center list page is a consistently accessible resource whether the center is managing or initiating business.
[0108] Similarly, a user can assume different roles across different tenants, projects, and centers. At the project level, they could be a project manager; at another, a CRC (Responsible Currency Controller) within that project's centers. Furthermore, this embodiment can dynamically match user permissions based on changes in business type, service scope (addition or removal of service scope), and personnel changes (departure or onboarding), ensuring that users have access to different resources in different scenarios. Existing RBAC (Responsible Access Control) systems cannot manage such complex business logic permissions. Accurate resource permissions are a guarantee of standardization throughout the entire clinical research trial process, preventing unauthorized individuals from accessing resources they shouldn't.
[0109] This embodiment achieves access control over resources under different relationships by combining tenant (org_id), business type (business_type), service scope (service_scope), system, project, center, role, etc., and establishing a mapping relationship between different combinations and permissions. When a user enters different levels under this system, the permission mapping is obtained according to the obtained combination.
[0110] Figure 2 This is a flowchart of a method for controlling access to clinical research projects according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:
[0111] Step S201: When a user's login request is detected, obtain the user's identification information, as well as the tenant information, business type, and service scope of the user's login.
[0112] Step S202: Determine the resource level accessed by the user, the resource level including: system, project, center;
[0113] Step S203: Determine the user's role at the accessed resource level;
[0114] Step S204: Determine the user's permissions based on the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
[0115] In some embodiments, this embodiment may pre-establish and store a first mapping table, wherein the first mapping table is used to indicate the mapping relationship between a first combination and user permissions, and the first combination includes: user identifier, tenant information, business type, service scope, role, and resource level.
[0116] This embodiment establishes a mapping table between different combinations and permissions in advance. The purpose is to facilitate the quick and accurate determination of the user permissions corresponding to the combination after determining the combination of user identifier, tenant information, business type, service scope, role, and resource level in subsequent use scenarios, thereby improving the efficiency and accuracy of user permission detection.
[0117] In some embodiments, step S204 determines the user's permissions based on the resource level accessed by the user, the user's role at the accessed resource level, the user's identification information, and the user's logged-in tenant information, service type, and service scope, including:
[0118] Based on the first mapping table, determine the permissions corresponding to the target combination of the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the user's login tenant information, business type, and service scope.
[0119] In some embodiments, this embodiment may also update the first mapping table in real time to improve the accuracy of user permission detection.
[0120] In some embodiments, this embodiment can also update user permissions in real time when combined elements such as user roles or accessed resource levels change, specifically including:
[0121] When at least one of the target combinations changes, the target combinations are updated to obtain the updated target combinations;
[0122] Based on the first mapping table, the permissions corresponding to the updated target combination are redefined.
[0123] In some embodiments, this embodiment may establish at least one of the following while pre-establishing the first mapping table:
[0124] A second mapping table is established and stored, wherein the second mapping table is used to indicate the mapping relationship between a second combination and user permissions at the system level, and the second combination includes: tenant information and roles;
[0125] Establish and store a third mapping table, wherein the third mapping table is used to indicate the mapping relationship between a third combination under the project level and user permissions, and the third combination includes: tenant information, role, and project identifier;
[0126] Establish and store a permission information table, wherein the permission information table is used to store at least one of the following information: permission name, permission type, permission resource type, permission identifier, and permission parent identifier.
[0127] This embodiment establishes and stores the aforementioned mapping table and information table to facilitate the maintenance and updating of user permission templates under different resource levels. When a user role changes under a certain resource level, the user permission template under that resource level can be updated directly, saving time and effort and improving the efficiency of user permission update and maintenance.
[0128] In this embodiment, the mapping table and information table are stored in the backend. Specifically, the first mapping table is shown in Table 3 below, the second mapping table is shown in Table 4 below, the third mapping table is shown in Table 5 below, and the permission information table is shown in Table 6 below.
[0129] Table 3
[0130] org_id Tenant ID tpl_type Template type System, Project, Center tpl_scope Business type SSU service, CO service, etc. tpl_services Service Scope SSU center startup, center management, patient recruitment, etc. role_code Character identifier Associated tenants, business types, service scope, and resource levels pmsn_code Permission ID Permissions under this combination
[0131] Table 4
[0132] org_id Tenant ID Tenant Relationship ID role_code Character identifier Associate tenants with roles pmsn_code Permission ID Associate tenants, roles, and permission identifiers
[0133] Table 5
[0134]
[0135]
[0136] Table 6
[0137]
[0138] The relationships between the above tables are as follows: Figure 3As shown, the specific description is as follows: The first mapping table stores the relationship between tenants, business types, service scopes, roles, resource levels, and permission identifiers; the second mapping table stores the relationship between roles and permission identifiers at the system level; the third mapping table stores the relationship between roles and permission identifiers at the project level; and the permission information table stores the specific information of the tree structure of all resources.
[0139] It should be noted that when a tenant adds a new project, the project permission data will be initialized. Based on the default template defined in the first mapping table, the project's permissions are initialized by matching the service scope of the tenant's order with the currently created business type. The specific initialization process includes:
[0140] 1. Copy the system permissions (tpl_type="SYS") to the second mapping table.
[0141] 2. Copy the created project ID, project and center permissions (tpl_type="PROJECT" and tyl_type="SITE") to the third mapping table.
[0142] It should also be noted that when project members change, this embodiment assigns roles to members who have joined the project, specifically including:
[0143] 1. When accessing resources, obtain the corresponding resource permissions based on user tenant information, user role, user project and center information.
[0144] 2. When an employee leaves the company or is removed from their role, they will lose the corresponding resource privileges.
[0145] In this practical application scenario, after the backend provides information based on tenant, project, role, etc., the frontend will request the backend interface to obtain the corresponding permissions. The specific execution logic of the frontend is as follows: Figure 4 and Figure 5 As shown, the specific process includes the following:
[0146] 1. Users log in from the portal website.
[0147] 2. After logging in, the system will obtain a unique user identifier token and return the tenant information, business type, and service scope of the user.
[0148] 3. Transfer the information to the project management collaboration platform PMCP and determine the page resource level (System, Project, Site) accessed in PMCP.
[0149] 4. Based on the accessed page and resource level, call user-svc to obtain the user's bound role under that resource level, such as PM, CRC, CRA, CTA, etc.
[0150] 5. By combining the user's basic information with the business type, service scope, user role, resource level, and calling perm-svc, user permissions are obtained through relevant mapping relationships.
[0151] This embodiment primarily utilizes the Vue, Vuex, and Vue-router suite to implement front-end control of the entire routing and resource permissions. For example... Figure 6 As shown, after a user logs in, some basic information about the logged-in user is cached under the user-store. Based on the user's basic information and the required resource access conditions, relevant access permissions are obtained, specifically including:
[0152] (1) After a user logs in, the backend will return the user's unique identifier token to the frontend;
[0153] (2) The front end requests the back end's permission interface by requesting the token;
[0154] (3) The permission interface will use the user token to obtain the tenant information to which the user information under the current token belongs, as well as the resource level information of the page accessed by the user, and obtain specific permissions through the interface. Each button, each page, and each controllable resource and component on the page will be assigned a unique code (pmsn_code).
[0155] For example, when a user visits the project page, Project Management - Research Center (pmsn_code:P1008), the permission API determines whether the user has the necessary permissions to access the relevant pages and resources based on matching data. The front-end uses a unique identifier for the page and the access permission identifier obtained from the API to determine whether the user can continue accessing the "Research Center" page. If the user lacks permission, they will be redirected to the first accessible page path. For example, if a button resource is not accessible, the button will not be displayed.
[0156] When user roles and permission templates change, the frontend is notified via WebSocket to update the page, re-render, and re-perform permission checks. The specific process includes:
[0157] (1) When permissions change, a communication link between the client and the server is established via WebSocket. When permissions change, the backend sends a WebSocket message to the frontend that is establishing the link. The frontend listens for events via WebSocket.
[0158] (2) WebSocket connects to the backend service by calling the construction method const ws = new WebSocket, passing in the websocket service address of the server, and then listens for messages pushed from the backend through ws.onmessage;
[0159] (3) The backend also needs to use WebSocket service technology to push relevant changes to the frontend;
[0160] (4) When permissions change, if the user's current permissions include the corresponding permissions, the front end will prompt the user that the permissions have changed and ask the user to obtain the latest changed permissions.
[0161] This embodiment defines permissions uniformly, including for files, images, and voice. It uses a unified resource management logic to define different roles under different tenants, resource levels, business types, and service scopes in a consistent manner, maintaining relatively consistent access logic and principles in querying resource access permissions. During development, this embodiment implements unified resource management for pages, files, and operations, simplifying permission definitions, improving development efficiency, reducing the learning cost of permission control, and enabling integrated use across multiple projects and business scenarios to achieve consistent permission management methods.
[0162] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.
[0163] This embodiment provides a control device for managing permissions in clinical research projects. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0164] Figure 7 This is a structural block diagram of a control device for managing clinical research project permissions according to an embodiment of this application, such as... Figure 7 As shown, the device includes:
[0165] The acquisition unit 71 is used to acquire the user's identification information, as well as the tenant information, business type, and service scope of the user's login when a user's login request is detected.
[0166] The first determining unit 72 is used to determine the resource level accessed by the user, the resource level including: system, project, and center;
[0167] The second determining unit 73 is used to determine the role of the user in the accessed resource level;
[0168] The third determining unit 74 is used to determine the user's corresponding permissions based on the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the user's logged-in tenant information, business type, and service scope.
[0169] In some embodiments, the device further includes:
[0170] The first establishment unit is used to establish and store a first mapping table, wherein the first mapping table is used to indicate the mapping relationship between a first combination and user permissions, and the first combination includes: user identifier, tenant information, business type, service scope, role, and resource level.
[0171] In some embodiments, the third determining unit 74 includes:
[0172] The determination module is used to determine, based on the first mapping table, the permissions corresponding to the target combination of the resource level accessed by the user, the role of the user in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
[0173] In some embodiments, the device further includes:
[0174] An update unit is configured to update the target combination when at least one of the target combinations changes, thereby obtaining an updated target combination;
[0175] The fourth determining unit is used to redetermine the permissions corresponding to the updated target combination based on the first mapping table.
[0176] In some embodiments, the device further includes at least one of the following:
[0177] The second establishment unit is used to establish and store a second mapping table, wherein the second mapping table is used to indicate the mapping relationship between a second combination and user permissions at the system level, and the second combination includes: tenant information and roles;
[0178] The third establishment unit is used to establish and store a third mapping table, wherein the third mapping table is used to indicate the mapping relationship between the third combination under the project level and user permissions, and the third combination includes: tenant information, role, and project identifier;
[0179] The fourth establishment unit is used to establish and store a permission information table, wherein the permission information table is used to store at least one of the following information: permission name, permission type, permission resource type, permission identifier, and permission parent identifier.
[0180] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.
[0181] An embodiment provides a computer device. The method for controlling access to clinical research project management, in conjunction with this application embodiment, can be implemented using a computer device. Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application.
[0182] The computer device may include a processor 81 and a memory 82 storing computer program instructions.
[0183] Specifically, the processor 81 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.
[0184] The memory 82 may include a mass storage device for data or instructions. For example, and not limitingly, the memory 82 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 82 may include removable or non-removable (or fixed) media. Where appropriate, the memory 82 may be internal or external to a data processing device. In a particular embodiment, the memory 82 is non-volatile memory. In a particular embodiment, the memory 82 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), Extended Data Out Dynamic Random-Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.
[0185] The memory 82 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the processor 81.
[0186] The processor 81 reads and executes computer program instructions stored in the memory 82 to implement any of the clinical research project management permission control methods in the above embodiments.
[0187] In some embodiments, the computer device may further include a communication interface 83 and a bus 80. For example, Figure 8 As shown, the processor 81, memory 82, and communication interface 83 are connected through bus 80 and complete communication with each other.
[0188] The communication interface 83 is used to enable communication between the various modules, devices, units, and / or equipment in the embodiments of this application. The communication interface 83 can also enable data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.
[0189] Bus 80 includes hardware, software, or both, that couples components of a computer device together. Bus 80 includes, but is not limited to, at least one of the following: data bus, address bus, control bus, expansion bus, and local bus. For example, and not as a limitation, bus 80 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 80 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.
[0190] Furthermore, in conjunction with the control method for clinical research project management permissions in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the control methods for clinical research project management permissions in the above embodiments.
[0191] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0192] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.
Claims
1. A method for controlling management authority in clinical research projects, characterized in that, include: When a user's login request is detected, the user's identification information, as well as the tenant information, business type, and service scope of the user's login are obtained. The resource level accessed by the user is determined, and the resource level includes: system, project, and center; Determine the user's role at the accessed resource level; The user's permissions are determined based on the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login. The control method further includes: Establish and store a first mapping table, wherein the first mapping table is used to indicate the mapping relationship between a first combination and user permissions, and the first combination includes: user identifier, tenant information, business type, service scope, role, and resource level; A second mapping table is established and stored, wherein the second mapping table is used to indicate the mapping relationship between a second combination and user permissions at the system level, and the second combination includes: tenant information and roles; Establish and store a third mapping table, wherein the third mapping table is used to indicate the mapping relationship between a third combination under the project level and user permissions, and the third combination includes: tenant information, role, and project title; When a tenant adds a new project, the project permission data will be initialized. Based on the default template defined in the first mapping table, the service scope in the tenant's order and the project of the currently created business type will be matched to initialize the permissions. Specifically, the user's permissions are determined based on the resource level accessed by the user, the user's role within that resource level, the user's identification information, and the user's logged-in tenant information, service type, and service scope. This includes: Based on the first mapping table, determine the permissions corresponding to the target combination of the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the user's login tenant information, business type, and service scope.
2. The method according to claim 1, characterized in that, Also includes: When at least one of the target combinations changes, the target combinations are updated to obtain the updated target combinations; Based on the first mapping table, the permissions corresponding to the updated target combination are redefined.
3. The method according to claim 1, characterized in that, Also includes: Establish and store a permission information table, wherein the permission information table is used to store at least one of the following information: permission name, permission type, permission resource type, permission identifier, and permission parent identifier.
4. A control device for managing clinical research project authority, used to execute the control method as described in any one of claims 1 to 3, characterized in that, include: The acquisition unit is used to acquire the user's identification information, as well as the tenant information, business type, and service scope of the user's login, when a user's login request is detected. The first determining unit is used to determine the resource level accessed by the user, the resource level including: system, project, and center; The second determining unit is used to determine the role of the user in the accessed resource level; The third determining unit is used to determine the user's corresponding permissions based on the resource level accessed by the user, the user's role in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
5. The apparatus according to claim 4, characterized in that, Also includes: The first establishment unit is used to establish and store a first mapping table, wherein the first mapping table is used to indicate the mapping relationship between a first combination and user permissions, and the first combination includes: user identifier, tenant information, business type, service scope, role, and resource level.
6. The apparatus according to claim 5, characterized in that, The third determining unit includes: The determination module is used to determine, based on the first mapping table, the permissions corresponding to the target combination of the resource level accessed by the user, the role of the user in the accessed resource level, the user's identification information, and the tenant information, business type, and service scope of the user's login.
7. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 3.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 3.
Citation Information
Patent Citations
Enterprise financial data acquisition and processing method and system
CN112950343A
Service processing method, device and equipment based on multi-service system
CN113901496A