WO2022052682A1 - 医疗***及其权限管理方法 - Google Patents

医疗***及其权限管理方法 Download PDF

Info

Publication number
WO2022052682A1
WO2022052682A1 PCT/CN2021/110561 CN2021110561W WO2022052682A1 WO 2022052682 A1 WO2022052682 A1 WO 2022052682A1 CN 2021110561 W CN2021110561 W CN 2021110561W WO 2022052682 A1 WO2022052682 A1 WO 2022052682A1
Authority
WO
WIPO (PCT)
Prior art keywords
administrator
level
user
level administrator
hospital
Prior art date
Application number
PCT/CN2021/110561
Other languages
English (en)
French (fr)
Inventor
魏薇
王琼莹
Original Assignee
京东方科技集团股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京东方科技集团股份有限公司 filed Critical 京东方科技集团股份有限公司
Priority to US17/788,623 priority Critical patent/US20230021770A1/en
Publication of WO2022052682A1 publication Critical patent/WO2022052682A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices

Definitions

  • the present application is based on the CN application number 202010953741.7 and the filing date is September 11, 2020, and claims its priority.
  • the disclosure content of the CN application is hereby incorporated into the present application as a whole.
  • the present disclosure relates to the technical field of medical system management, and in particular, to a medical system and a method for managing rights thereof.
  • Medical system is an edge science that integrates various disciplines such as medicine, information, management and computer, and has been widely used.
  • the medical system is the necessary technical support and infrastructure for the operation of modern hospitals.
  • the purpose of realizing the medical system is to strengthen the management of the hospital with more modern, scientific and standardized means, improve the work efficiency of the hospital, and improve the quality of medical care.
  • a method for managing rights of a medical system including: establishing a second-level administrator for a hospital in response to a role setting operation of a first-level administrator corresponding to a medical group layer, and Assign corresponding menus, functions and data access rights to the second-level administrator, wherein the hospital is a subordinate institution of the medical group layer; and in response to the role setting operation of the second-level administrator, to the second level administrator.
  • a user assigns menus, functions and data access rights corresponding to the user.
  • the hospital includes: a first hospital and a second hospital different from the first hospital, and the second level administrator includes a first administrator and a different hospital than the first administrator A second administrator, wherein menus, functions, and data access rights corresponding to the first administrator are different from menus, functions, and data access rights corresponding to the second administrator.
  • the users include: a first user and a second user different from the first user, wherein menus, functions and data access rights corresponding to the first user are different from those of the first user Two user corresponding menus, functions and data access rights.
  • the rights management method further includes: in response to an organization maintenance operation of the first-level administrator, adding, deleting or modifying organizational structure information in the medical system.
  • the rights management method further comprises: adding, deleting or modifying department information in the architecture of the hospital in response to the department maintenance operation of the second-level administrator.
  • the rights management method further comprises: in response to an information configuration operation of the first-level administrator, configuring administrator information of the second-level administrator; and in response to the second-level management User information configuration operation to configure the user information of the user.
  • the rights management method further includes: in response to a menu setting operation of the first-level administrator, configuring a plurality of menu functions, wherein each menu function is related to the first-level administrator, all The second-level administrator corresponds to a role identifier of at least one of the users.
  • the organizational structure information is in the form of a tree menu, and the organizational structure information includes regions and hospitals; wherein, the regions include subcategories, and the subcategories include the hospital or the next level. area, the hospital is the last node of the organizational structure information.
  • the rights management method further includes: in the process of modifying the organizational structure information, modifying the parent organization corresponding to the currently adjusted organization, and ensuring that the address identifier of the currently adjusted organization remains unchanged, wherein, The historical medical data of the currently adjusted institution is stored in the address identifier.
  • a medical system comprising: a receiving module configured to receive a role setting operation of a first-level administrator corresponding to a medical group layer or a second-level administrator corresponding to a hospital The role setting operation, wherein, the hospital is a subordinate institution of the medical group layer; and the role management module, in response to the role setting operation of the first-level administrator, establishes a second-level administrator for the hospital, assigning corresponding menus, functions and data access rights to the second-level administrator, and assigning menus, functions, and data access corresponding to the user to the user in response to the role-setting operation of the second-level administrator permissions.
  • the medical system further includes: an organization management module, configured to add, delete or modify organizational structure information in the medical system in response to an organization maintenance operation of the first-level administrator.
  • the medical system further includes: a department management module for adding, deleting or modifying department information in the architecture of the hospital in response to department maintenance operations by the second-level administrator.
  • the medical system further includes: a user management module configured to configure administrator information of the second-level administrator in response to an information configuration operation of the first-level administrator, and in response to the information configuration operation of the first-level administrator The information configuration operation of the second-level administrator is performed to configure the user information of the user.
  • a user management module configured to configure administrator information of the second-level administrator in response to an information configuration operation of the first-level administrator, and in response to the information configuration operation of the first-level administrator The information configuration operation of the second-level administrator is performed to configure the user information of the user.
  • the medical system further includes: a menu management module, configured to configure a plurality of menu functions in response to a menu setting operation of the first-level administrator, wherein each menu function is related to the first The role identifiers of at least one of the first-level administrator, the second-level administrator and the user correspond.
  • a menu management module configured to configure a plurality of menu functions in response to a menu setting operation of the first-level administrator, wherein each menu function is related to the first The role identifiers of at least one of the first-level administrator, the second-level administrator and the user correspond.
  • a medical system comprising: a memory; and a processor coupled to the memory, the processor configured to perform as before based on instructions stored in the memory the method described.
  • a non-transitory computer-readable storage medium having computer program instructions stored thereon, the instructions implementing the aforementioned method when executed by a processor.
  • FIG. 1 is a flowchart illustrating a rights management method of a medical system according to an embodiment of the present disclosure
  • FIG. 2 is a flowchart illustrating a rights management method for a first-level administrator of a medical system according to an embodiment of the present disclosure
  • FIG. 3 is a flowchart illustrating a rights management method for a second-level administrator of a medical system according to an embodiment of the present disclosure
  • FIG. 4 is a flowchart illustrating a rights management method of a medical system according to another embodiment of the present disclosure
  • FIG. 5 is a schematic structural diagram illustrating a medical system according to an embodiment of the present disclosure.
  • FIG. 6 is a schematic structural diagram illustrating a medical system according to another embodiment of the present disclosure.
  • FIG. 7 is a schematic structural diagram illustrating a medical system according to another embodiment of the present disclosure.
  • FIG. 8 is a schematic structural diagram illustrating a medical system according to another embodiment of the present disclosure.
  • FIG. 9 is a schematic diagram illustrating an organization management interface of a medical system according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic diagram illustrating a department management interface of a medical system according to an embodiment of the present disclosure
  • FIG. 11 is a schematic diagram illustrating a role management interface of a medical system according to an embodiment of the present disclosure
  • FIG. 12 is a schematic diagram illustrating a user management interface of a medical system according to one embodiment of the present disclosure
  • FIG. 13 is a schematic diagram illustrating a menu management interface of a medical system according to an embodiment of the present disclosure.
  • the inventors of the present disclosure found that, in the related art, the medical system has weak support for group management, and for large and medium-sized medical institutions, basically each medical institution is managed as an individual individual. Although some medical systems provide organizational structure and authority management functions, there are too many restrictions and the functions cannot be distributed. As a result, every time a system is launched, more operation and maintenance work will be added to the system. Over time, the operation and maintenance of the system itself is very cumbersome.
  • the embodiments of the present disclosure provide a rights management method for a medical system, which can minimize the burden of operation and maintenance.
  • FIG. 1 is a flowchart illustrating a rights management method of a medical system according to an embodiment of the present disclosure. As shown in FIG. 1 , the rights management method includes steps S102 to S104.
  • step S102 in response to the role setting operation of the first-level administrator corresponding to the medical group layer, a second-level administrator is established for the hospital, and corresponding menus, functions and data access rights are assigned to the second-level administrator.
  • the hospital is a subordinate institution of the medical group level.
  • the function corresponding to the second-level administrator is the function that the second-level administrator can implement through the medical system (for example, it may include: log in to the system, view information, department settings, role settings and other functional operations, etc.); These features are visualized for second-level administrators to select and click.
  • the system will create a first-level administrator (or super administrator) account in the database, so that the first-level administrator can log in and configure the menu permissions corresponding to this account.
  • the first-level administrator is the group-level administrator.
  • a medical group can include different hospitals, that is, a hospital is a subordinate institution at the group level.
  • the first-level administrator logs into the medical system by entering an account number, a password and a verification code.
  • the medical system can return the corresponding menu authority according to the authority of the current account.
  • the first-level administrator may establish role identifications of the first-level administrator and the second-level administrator through the medical system. For example, the administrator of each hospital acts as a second-level administrator, and the second-level administrator can select the corresponding hospital.
  • the role identifier is a mark used to identify the role.
  • the role identifiers include: the role identifier of the first-level administrator, the role identifier of the second-level administrator, and the role identifier of the user. After a role is selected, the role ID can be set for that role. Each role ID is set with corresponding menu permissions.
  • the medical system responds to the role setting operation, creates a second-level administrator for the corresponding hospital, and assigns corresponding menus, functions and data access rights to the second-level administrator .
  • the medical system may issue menus, functions and data access rights corresponding to the second-level administrator to the sub-system corresponding to the hospital. Due to the selection of specific function menus, the second-level administrator can see these function menus after logging in to the system, and click to see the specific function pages.
  • step S104 in response to the role setting operation of the second-level administrator, the user is assigned the menu, function and data access authority corresponding to the user.
  • the function corresponding to the user is the function that the user can implement through the medical system (for example, it may include functional operations such as logging in to the system and viewing information, etc.); the menu can visualize these functions for the user to select and click.
  • the medical system can return the corresponding menu authority according to the authority of the current account.
  • the second-level administrator can establish role identifications of the second-level administrator and users (eg, roles such as staff, customers, or patients) through the medical system. Roles can include a variety of roles, such as follow-up doctors, chronic disease doctors, nurses, or marketers, etc.
  • the second-level administrator can select the corresponding hospital and configure the permissions (ie, the selection of the function menu). In the case of selecting specific function menus, the second-level administrator can see these function menus after logging in to the system, and click these function menus to see the specific function pages.
  • the medical system in response to the role setting operation, assigns menus, functions and data access rights corresponding to the user to the user.
  • the method includes: in response to the role setting operation of the first-level administrator corresponding to the medical group layer, establishing a second-level administrator for the hospital, and assigning corresponding menus, functions and data access rights to the second-level administrator; and, in response to the role setting operation of the second-level administrator, assigning menus, functions and data access rights corresponding to the user to the user.
  • the medical system adopts the method of assigning corresponding menus, functions and data access rights to the lower-level administrator or user in response to the role setting operation of the upper-level administrator, which facilitates operation and maintenance management and minimizes the Small operation and maintenance burden.
  • the hospital may include a first hospital and a second hospital different from the first hospital.
  • the second-level administrator may include a first administrator and a second administrator different from the first administrator.
  • the menus, functions and data access rights corresponding to the first administrator are different from the menus, functions and data access rights corresponding to the second administrator.
  • different second-level administrators can be established for different hospitals, and different menus, functions, and data access rights can be assigned to different second-level administrators. In this way, diversified settings for the second-level administrator can be realized, and the management level can be improved.
  • the users may include: a first user and a second user different from the first user.
  • the menus, functions and data access rights corresponding to the first user are different from the menus, functions and data access rights corresponding to the second user.
  • different users may be assigned different menus, functions and data access rights. This can realize diversified settings for users and improve the management level.
  • the rights management method may further include: adding, deleting or modifying organizational structure information in the medical system in response to an organizational maintenance operation of the first-level administrator.
  • organizational structure information can be added, deleted, or modified in the medical system before a second-level administrator is established for the hospital.
  • the organizational structure information may be in the form of a tree menu.
  • the organizational structure information may include regions and hospitals.
  • the area includes sub-categories, and the sub-categories include hospitals or lower-level areas, and the hospital is the last node of organizational structure information.
  • FIG. 9 is a schematic diagram illustrating an organization management interface of a medical system according to one embodiment of the present disclosure.
  • the regions may be: North China, East China, and the like.
  • an upper-level institution refers to an upper-level institution (ie, a parent node) of the current institution.
  • Institution name refers to the name of the current institution, such as North China, etc.
  • FIG. 9 shows a business unit, and the business unit may be an organization at the same level as the region, for example, as shown in FIG. 9 of the present embodiment. In other embodiments, the business unit may be a lower-level institution in the region and an upper-level institution of the hospital.
  • the information of the currently added institution can be filled in on the right side of Figure 9, and the parent institution, institution name, contact number and remarks of the current institution can be filled in.
  • Filling in the parent institution can clarify which institution is the parent institution of the current institution
  • filling in the institution name can clarify what the current institution is
  • filling in the contact number can facilitate personnel to contact the institution by phone
  • the remark information can be any information that needs to be remarked.
  • the contact number and remarks information here can also be omitted.
  • the interface for selecting "Hospital” here is similar to the interface for selecting "Region/Business Department", and it also includes the parent institution, institution name, contact number, and remarks.
  • the first-level administrator can set the organizational structure of the entire medical system through the medical system.
  • the organizational structure can take the form of a tree menu.
  • the organizational structure is divided into two categories: regions (or divisions) and hospitals.
  • the hospital is a leaf node, that is, the lowest layer of nodes, so the hospital has no subclass, and only the region (or business department) can establish the next-level node. In this way, the organizational structure setting of the medical system by the first administrator is realized.
  • the parent organization of any node in the organizational structure can be modified, and if there is a subclass under the node, the subclass can also be modified together. For example, as shown in Figure 9, move the mouse to a certain institution, such as "North China”, click on the institution, and then click "Edit”, then the information on the "North China” (that is, the superior institution) can be obtained. , organization name, contact number and remarks) to modify.
  • Delete in Figure 9 is used to delete a certain mechanism. For example, move the mouse over an institution, click on the institution, and when "Delete" is clicked, the institution can be deleted. If the deleted node contains subclasses, all of its subclasses will also be deleted. For example, if “North China” is deleted, then "XX Hospital” under “North China” will also be deleted.
  • the rights management method may further include: adding, deleting or modifying department information in the architecture of the hospital in response to the department maintenance operation of the second-level administrator.
  • department information can be added, deleted, or modified in a hospital's schema before users are assigned corresponding menus, functions, and data access rights.
  • the departments here can be different departments, etc.
  • FIG. 10 is a schematic diagram illustrating a department management interface of a medical system according to one embodiment of the present disclosure.
  • the departments may include: Geriatrics Outpatient Department, Urology Department, Urology Outpatient Department, Internal Medicine Outpatient Department, and Surgery Outpatient Department.
  • the superior department refers to the superior department of the current department.
  • the department name refers to the name of the current department. For example, the current department is Urology Clinic, and the parent department of this current department is Urology.
  • the information of the currently added department can be filled in on the right side of Figure 10, and the parent department, department name and department description of the current department can be filled in.
  • Filling in the superior department can clarify which department is the superior department of the current department
  • filling in the department name can clarify what the current department is
  • the department description can be any information that needs to be described (such as the department's contact information, etc.).
  • Delete in Figure 10 is used to delete a department. For example, move the mouse over a department (such as "urology”), click on the department, and when "delete” is clicked, the department (such as "urology”) can be deleted. If the deleted department contains subclasses, all of its subclasses will also be deleted. For example, delete “urology”, then “urology clinic” under “urology” is also deleted.
  • the second-level administrator sets the departmental structure of the hospital through the medical system.
  • the department structure can take the form of a tree menu.
  • the department structure can be set at multiple levels, and the superior department of any node can be modified. If the node has a subclass, the subclass can also be modified. If the node is deleted, all its subclasses will be deleted as well. This realizes the setting of the hospital department by the second-level administrator.
  • the rights management method may further include: in response to an information configuration operation of the first-level administrator, configuring administrator information of the second-level administrator.
  • the first-level administrator can establish administrator information of different second-level administrators through the medical system (for example, it may include account number, password, identity information (such as ID number), and applet permissions, etc.) .
  • the first-level administrator can add the account, password, identity information (such as ID number), and applet permissions of a second-level administrator by adding on the user management interface. For example, as shown in Figure 12, after clicking "Add", an add window can pop up, and the above information can be added in the add window. In this way, the configuration of the administrator information of the second-level administrator is realized.
  • Each second-level administrator can log in to the system according to the established account and password. After the second-level administrator logs in, the system can see the menus, functions and data access rights corresponding to this account.
  • the medical system can be loaded on the mobile communication terminal in the form of a small program.
  • Both administrators and users have applet permissions, that is, both administrators and users can use the applet to log in and use the medical system. This can be more convenient to use and improve the convenience of the medical system.
  • a first-level administrator may be predefined in the medical system when the medical system is first used. For example, the information of the first-level administrator can be written into the medical system.
  • FIG. 11 is a schematic diagram illustrating a role management interface of a medical system according to one embodiment of the present disclosure.
  • the role management interface contains some role information, while the user information of the second-level administrator, such as the account, password, identity information, and applet permissions, belongs to the administrator, and the two are different.
  • the role information may include: serial number, role name, role identifier, role description, hospital to which it belongs, creation time, and operation.
  • the serial number is the serial number of a character.
  • a role name is the name of a role.
  • the role ID refers to the role ID corresponding to a role.
  • the role ID whose role name is doctor is the first-level administrator (ie, the super administrator in Figure 11), and the role ID whose role name is XX hospital administrator is the second-level administrator (ie, the role ID in Figure 11). hospital administrator).
  • a role description is a brief description of the role.
  • the role ID of a role is the first-level administrator, then the role description of the role can be the first-level administrator.
  • the role description here can be any description about the role, which can make it convenient for people to understand some attributes of the role.
  • the affiliated hospital refers to the hospital to which the current character belongs. Creation time refers to the time the role was created. Actions include: Edit, Delete, and Permissions.
  • edit is used to modify the relevant content of a role (for example, it can include information such as serial number, role description, role ID, role description and hospital to which it belongs), and "delete” is used to delete a role.
  • Permission is used to set the permissions of a role. For example, when you click "Permissions", you can see all the permissions corresponding to the role ID to which the role belongs, and then you can set the corresponding permissions for the role by checking them.
  • the authority of the first-level administrator includes: system management, patient center, follow-up center, AI (Artificial Intelligence, artificial intelligence) intelligence and data statistics
  • the second-level administrator includes: system management, patient center, follow-up center, AI (Artificial Intelligence, artificial intelligence) intelligence and data statistics
  • the permissions that is, the menu that the second-level administrator can manage
  • the user's permissions that is, the menu that the user can manage
  • patient center follow-up center
  • AI intelligence Artificial Intelligence, artificial intelligence
  • the rights management method may further include: in response to an information configuration operation of the second-level administrator, configuring user information of the user.
  • the second-level administrator may establish user information of different users through the medical system (for example, may include account numbers, passwords, identity information, and applet permissions, etc.).
  • the second-level administrator can add a user's account, password, identity information (such as ID number), and applet permissions on the user management interface by adding. For example, as shown in Figure 12, after clicking "Add", an add window can pop up, and the above information can be added in the add window.
  • Each user can log in to the system according to the established account and password. After the user logs in, the system can assign corresponding menus, functions and data access permissions according to the permissions of the account.
  • FIG. 12 is a schematic diagram illustrating a user management interface of a medical system according to one embodiment of the present disclosure.
  • the user's information may include: serial number, user name, name, mobile phone number, gender, affiliated hospital, affiliated department, role, status, and operation.
  • the serial number is the serial number of a certain user.
  • Username is the name of a user.
  • the mobile number is the mobile number of a user.
  • the affiliated hospital is the hospital to which a user belongs.
  • the hospital to which the user whose serial number is "00000030" belongs is XX hospital.
  • the owning department is the department to which a user belongs.
  • the department of the user whose serial number is "00000030" is Gastroenterology.
  • a role is the role of a user.
  • the role of the user whose serial number is "00000030" is XX hospital administrator.
  • Status indicates whether a user's status is valid. "Valid” means that the corresponding user can log in to the system, and "locked” means that the corresponding user cannot log in to the system.
  • Actions can include edits and deletions. Edit is an action used to modify content related to a user. For example, by clicking "Edit" behind a user, you can modify the user's serial number, username, name, mobile phone number, gender, hospital, department, role, and status. "Delete” is used to delete the action of a user.
  • the rights management method may further include: in response to a menu setting operation of the first-level administrator, configuring a plurality of menu functions.
  • Each menu function corresponds to a role identification of at least one of a first-level administrator, a second-level administrator, and a user.
  • multiple menu functions may be configured in response to a menu setting operation of a first-level administrator before establishing a second-level administrator for a hospital and after adding, deleting, or modifying organizational structure information in the medical system.
  • FIG. 13 is a schematic diagram illustrating a menu management interface of a medical system according to an embodiment of the present disclosure.
  • the menu may include: system management, patient center, follow-up center, AI intelligence and data statistics, etc.
  • a menu can be added, edited, or deleted as needed. For example, select the "System Management" menu with the mouse, and then click "Add" to add a lower-level menu to the "System Management" menu. When adding a lower-level menu, you can set the parent node and title of the lower-level menu. and permission ID.
  • the parent node refers to the upper-level menu of the lower-level menu
  • the title refers to the name of the lower-level menu
  • the permission identifier refers to which one of the first-level administrator, the second-level administrator, and the user Or which ones have the authority of this lower level menu.
  • the three role labels of the first-level administrator, the second-level administrator and the user can pop up, and select the first-level administrator by checking. which one or more of the first-level administrator, second-level administrator, and user has the authority to this menu.
  • the icon, resource path, request method, type, order, front-end component and front-end address of the next-level menu can also be set.
  • the resource path may be a URL (Uniform Resource Location) of a menu function.
  • the request method can be selected as the post method or the get method.
  • Type is the resource request type.
  • the ordering is the sequence number of the added menu, which can be entered manually, for example.
  • the description content of the menu can be input in the box behind "Front-end Components", for example, it can be any description content.
  • the front-end address is the address of the added menu. Through the front-end address, you can directly reach the menu page corresponding to the address.
  • the first-level administrator can set all function menus of the entire medical system through the medical system.
  • Each function menu corresponds to its role ID (that is, which role IDs have the right to see this function menu, and only have the right to select this menu).
  • Menu management can be dynamically configured. Through the configuration operation, the medical system can directly correspond to the front-end page, and then when the role permissions are selected, the corresponding function page can be displayed according to the selected menu. Therefore, the medical system has good flexibility and scalability.
  • FIG. 2 is a flowchart illustrating a rights management method for a first-level administrator of a medical system according to an embodiment of the present disclosure. As shown in FIG. 2, the method may include steps S202 to S208.
  • step S202 in response to the organizational maintenance operation of the first-level administrator, add, delete or modify organizational structure information in the medical system.
  • the organizational structure can be maintained by the first-level administrator, using a tree-like hierarchical structure, and the number of layers can be unlimited.
  • the hospital level may have an identifier, which can identify this level as a hospital.
  • the rights management method may further include: in the process of modifying the organizational structure information, modifying the parent organization corresponding to the currently adjusted organization, and ensuring that the address identifier of the currently adjusted organization remains unchanged.
  • the historical medical data of the currently adjusted institution is stored in this address ID.
  • the parent organization that is, the upper-level organization
  • the address identification (ID) of the currently adjusted organization can be ensured unchanged, so as not to affect the Store the historical medical data identified at this address.
  • the organizational structure may be a one-level structure of a single hospital, a second-level hierarchical structure of medical groups and hospitals, or a four-level hierarchical structure of medical groups, regions, business divisions, and hospitals.
  • a medical group is the parent organization of a region
  • a region is the parent organization of a business unit
  • a business department is the parent organization of a hospital.
  • regions and divisions may be the same level of organization.
  • step S204 a plurality of menu functions are configured in response to the menu setting operation of the first-level administrator.
  • the medical system may select a role identifier corresponding to the newly added menu.
  • step S206 in response to the role setting operation of the first-level administrator, a second-level administrator is established for the hospital, and corresponding menus, functions and data access rights are assigned to the second-level administrator.
  • the medical system may create a role, and the role may have a role identity (including a first-level administrator, a second-level administrator, and a user).
  • the first-level administrator can also authorize the role after creating it.
  • the medical system can display the corresponding menu according to the role ID, and then the first-level administrator selects the specific menu from it, and completes the role authorization after saving.
  • step S208 in response to the information configuration operation of the first-level administrator, the administrator information of the second-level administrator is configured.
  • the medical system may configure the hospital to which the second-level administrator belongs and the corresponding second-level administrator role, and then set the login name and password.
  • the medical system may also generate an administrator list including administrator information of second-level administrators of each hospital.
  • a rights management method for a first-level administrator of a medical system is provided.
  • the medical system adds, deletes or modifies organizational structure information in the medical system in response to the organization maintenance operation of the first-level administrator; then, the medical system responds to the first-level administrator's organizational maintenance operation.
  • the menu setting operation of the first-level administrator configures menu functions, and each menu function can correspond to at least one role identifier; then, the medical system responds to the role setting operation of the first-level administrator, assigns the second-level administrator to the hospital, and The corresponding menu, function and data access rights are assigned to the second-level administrator pair; next, the medical system configures the administrator information of the second-level administrator in response to the information configuration operation of the first-level administrator. In this way, the corresponding setting of the medical system in response to the relevant operations of the first-level administrator is realized, which can facilitate the maintenance and management of the group.
  • the role management step (S206) may be performed after the organization management step (S202) and the menu management step (S204), and the user management step (S208) may be performed after the role management step.
  • the role management step may depend on the organization management step and the menu management step
  • the user management step may depend on the role management step.
  • FIG. 3 is a flowchart illustrating a rights management method for a second-level administrator of a medical system according to an embodiment of the present disclosure. As shown in FIG. 3, the method may include steps S302 to S306.
  • step S302 in response to the department maintenance operation of the second-level administrator, department information is added, deleted or modified in the structure of the hospital. That is, after the second-level administrator logs in to the system, he can maintain the department structure of the corresponding hospital.
  • step S304 in response to the role setting operation of the second-level administrator, the user is assigned the menu, function and data access authority corresponding to the user.
  • the medical system may maintain the roles of the hospital (eg, doctor, nurse, administrator, etc.), and authorize the role after the role is created.
  • the medical system can display the corresponding menu according to the role ID, and then the second-level administrator selects the specific menu from it, and completes the role authorization after saving.
  • the second-level administrator cannot select the role ID of the first-level administrator when creating a role, nor can he see the menu corresponding to the role ID of the first-level administrator, and cannot operate the first-level administrator. has the function.
  • step S306 the user information of the user is configured in response to the information configuration operation of the second-level administrator.
  • the medical system may maintain the users of the hospital where the second-level administrator is located. For example, the second-level administrator can select the department to which the user belongs and the corresponding role, and then set the login name and password.
  • the medical system may generate a user list including user information of the hospital.
  • a rights management method for a second-level administrator of a medical system is provided.
  • the medical system responds to the department maintenance operation of the second-level administrator to add, delete or modify department information in the hospital's architecture; then, the medical system responds to the second-level administrator's department maintenance operation.
  • the role setting operation of the first-level administrator assigns the user corresponding menus, functions and data access rights; next, the medical system configures the user information of the user in response to the information configuration operation of the second-level administrator. In this way, the corresponding setting of the medical system in response to the relevant operations of the second-level administrator is realized, which can facilitate the maintenance and management of the group.
  • the user management step (S306) may be performed after the department management step (S302) and the role management step (S304).
  • the user management step may depend on the department management step and the role management step.
  • the first-level administrator is responsible for organizational settings, menu settings, and specific role settings and user settings of the entire system, and a second-level administrator for each hospital can be set.
  • First-level administrators can create first-level administrators and second-level administrators through the medical system.
  • the second-level administrator is responsible for department settings, role settings, and user settings for each hospital.
  • Second-level administrators can create their own hospital administrators and users (eg staff) through the medical system.
  • the user can be in different roles. Different roles have different business system menus, functions and data access rights. After entering the system, users with different roles can have different system menus, functions and data access rights.
  • the staff of each hospital can only see the relevant functions and data of their own hospital.
  • FIG. 4 is a flowchart illustrating a rights management method of a medical system according to another embodiment of the present disclosure. As shown in FIG. 4 , the method may include steps S402 to S416.
  • step S402 the first-level administrator first enters the organization management interface to set the organization structure of the entire medical system.
  • step S404 the first-level administrator establishes the role of the second-level administrator, and assigns corresponding menus, functions and data access rights to the second-level administrator.
  • step S406 the first-level administrator establishes different administrator information for the second-level administrator, such as account numbers, passwords, ID cards, and applet permissions.
  • step S408 the second-level administrator inputs the account number, password and verification code to log in to the system.
  • step S410 the second-level administrator enters the department management interface to maintain the department structure of the hospital in charge.
  • step S412 the second-level administrator enters the role management interface, and establishes the role identification of the user.
  • step S414 the second-level administrator performs user maintenance, selects roles and departments for the users, and establishes user information for different users, such as account numbers, passwords, ID cards, and applet permissions.
  • step S416 the user logs in to the system, and can see the system menus, functions, data access rights assigned to him, and functions and data related to his own hospital.
  • the doctor's professional title level for example, chief physician, deputy chief physician, or attending physician, etc.
  • the medical system can provide doctors with options for service types (eg, graphic consultation, medical report interpretation, and video consultation, etc.).
  • service types eg, graphic consultation, medical report interpretation, and video consultation, etc.
  • a patient selects a service through a mobile communication terminal as a user, a corresponding doctor list can be obtained, and information about each doctor's professional title and professional expertise can be viewed. Therefore, the medical system can obtain the service applied by the user according to the type of service provided to the user, and respond or interpret accordingly.
  • a doctor can have PC-side authority and applet-side authority, that is, the doctor can perform corresponding processing through the program on the PC-side or the applet on the mobile communication terminal; the patient has the applet-side authority but not the PC-side authority, that is, the patient can only communicate through mobile communication
  • the applet on the terminal performs corresponding processing.
  • the authorization management method of the medical system is provided.
  • the rights management method it is possible to learn the things that the first-level administrator, the second-level administrator and the user are respectively responsible for and related operations that can be performed.
  • Such a system setup facilitates the maintenance of the medical system.
  • the first-level administrator at the group level is responsible for maintaining the organizational structure, creating a second-level administrator for the hospital, and giving the second-level administrator the authority function to manage the hospital.
  • the second-level administrator logs in to the system, he/she manages the department, role, user and authority of his own hospital. After logging in the system, the user can use the system functions normally.
  • this method not only satisfies the requirements of group management, but also enables the hospital to be managed as an individual individual, stratifies the management authority, and distributes the work of each administrator in a balanced manner, thereby reducing the system operation and maintenance work.
  • the above method also provides the user with operable functions.
  • the organization management step may be performed first, then the department management step may be performed, then the menu management step may be performed, then the role management step may be performed, and then the user management step may be performed.
  • the department management step may depend on the organization management step
  • the role management step may depend on the organization management step and the menu management step
  • the user management step may depend on the department management step and the role management step.
  • the first-level administrator when the hospital does not have a corresponding second-level administrator, can also be given the management authority of the corresponding hospital to perform hospital-level data maintenance. After maintaining the hospital's department and user data, the organizational structure at the group level can automatically obtain the hospital's department and number of users.
  • FIG. 5 is a schematic structural diagram illustrating a medical system according to an embodiment of the present disclosure. As shown in FIG. 5 , the medical system may include a receiving module 502 and a role management module 504 .
  • the receiving module 502 is configured to receive the role setting operation of the first-level administrator corresponding to the medical group layer or the role setting operation of the second-level administrator corresponding to the hospital.
  • the hospital is a subordinate institution of the medical group level.
  • the role management module 504 is configured to establish a second-level administrator for the hospital in response to the role setting operation of the first-level administrator, assign corresponding menus, functions and data access rights to the second-level administrator, and respond to the first-level administrator.
  • the role setting operation of the secondary administrator assigns the user the corresponding menu, function and data access rights.
  • the role management module 504 can be used to design the roles of each hospital, and configure the menus, functions and data access rights corresponding to the roles.
  • the medical system includes a receiving module and a role management module.
  • the receiving module is configured to receive the role setting operation of the first-level administrator corresponding to the medical group layer or the role setting operation of the second-level administrator corresponding to the hospital.
  • the role management module is used for assigning a second-level administrator to the hospital in response to the role setting operation of the first-level administrator, and assigning corresponding menus, functions and data access rights to the second-level administrator, and responding to the second-level administrator.
  • the role setting operation of the level administrator assigns the menu, function and data access rights corresponding to the user to the user.
  • the medical system can facilitate the operation and maintenance management of the system, and minimize the burden of operation and maintenance of the system.
  • FIG. 6 is a schematic structural diagram illustrating a medical system according to another embodiment of the present disclosure. As shown in FIG. 6 , the medical system may include a receiving module 502 and a role management module 504 .
  • the medical system may also include a tissue management module 606 .
  • the organization management module 606 is used to add, delete or modify organizational structure information in the medical system in response to the organization maintenance operation of the first-level administrator.
  • the organizational management module 606 can be used to organize the definition, design, and maintenance of hospitals.
  • the medical system may further include a department management module 608 .
  • the department management module 608 is used to add, delete or modify department information in the hospital structure in response to the department maintenance operation of the second-level administrator. Therefore, the department management module 608 can be used for the definition, design and maintenance of various departments within each hospital.
  • the medical system may further include a user management module 610 .
  • the user management module 610 is configured to configure the administrator information of the second-level administrator in response to the information configuration operation of the first-level administrator, and configure the user information of the user in response to the information configuration operation of the second-level administrator.
  • the user management module 610 can be used to create each hospital's user, identity information, role information (the role has been assigned PC (Personal Computer, personal computer) permissions) and mobile permissions information, etc., and can set valid or locked, etc.
  • the medical system may further include a menu management module 612 .
  • the menu management module 612 is used to configure a plurality of menu functions in response to the menu setting operation of the first-level administrator.
  • Each menu function corresponds to a role identification of at least one of a first-level administrator, a second-level administrator, and a user.
  • the menu management module 612 can be used for the configuration, design, maintenance of each menu function in the system, and configuration of the corresponding relationship with the front-end page.
  • data related to role management module 504, organization management module 606, department management module 608, user management module 610, and menu management module 612 may be stored in a database.
  • the medical system may include at least one of a PC terminal system and a mobile communication terminal (or called applet terminal) system.
  • a PC terminal system can be used by hospital personnel
  • the small program on the mobile communication side can be used by hospital personnel and customers.
  • the medical system can be set only on the PC end, or only on the mobile communication end, or can also be set on the PC end and the mobile communication end.
  • a user on the PC side can have three role identifications: a first-level administrator, a second-level administrator, and a hospital employee (a type of user). It should be noted that the role identifier here is not equal to the role, and the role identifier can distinguish the functional modules that can be seen for selection.
  • the roles of the PC side can be set by the first-level administrator and the second-level administrator, and the number is not limited, and can be configured according to the specific needs of each hospital.
  • the first-level administrator can establish the first-level administrator and the second-level administrator, and the second-level administrator can establish the administrators and users of his own hospital. For example, users can be employees, and employees can be in various roles.
  • the first-level administrator is responsible for the organization management module, menu management module, role management module and user management module.
  • the second-level administrator is responsible for the department management module, role management module and user management module.
  • the applet can be applied to 4 types of roles: administrator, doctor/nurse, tourist/client and marketer.
  • employees, doctors/nurses, tourists/customers, and marketers are all users of specific functions.
  • Employees can see function pages corresponding to specific menus (for example, chronic disease card, follow-up management, health prescription, graphic consultation, widgets and statistics).
  • each second-level administrator can set various roles of his own hospital, and assign different permissions to the roles to meet the needs of different hospitals that may have different roles and different permissions.
  • the data of each hospital does not interfere with each other.
  • Each user can have multiple roles, and there is no need to set individual permissions for the user. Different role permissions can be assigned according to the role characteristics set by the user to achieve the final user permission setting.
  • the roles and permissions of users on the PC and mobile communication terminals (such as mobile phones) are separated and can be adjusted according to their needs, thereby increasing the flexibility and scalability of the system.
  • the administrator of each hospital can set the department level of his own hospital. Departments and various functional data between hospitals do not affect each other, thus making the system setup more flexible.
  • the above medical system can fully meet the expansion and change adjustment of the multi-level organizational structure, without any restrictions, and does not affect the historical medical data.
  • permissions are managed hierarchically, and corresponding functions are issued, so that management work can be distributed in a balanced manner and the difficulty of operation and maintenance can be reduced.
  • each piece of medical data can be made to correspond to the organization code, so that the group level can achieve unified access to the operation data of each organization.
  • FIG. 7 is a schematic structural diagram illustrating a medical system according to another embodiment of the present disclosure.
  • the medical system includes a memory 710 and a processor 720 . in:
  • Memory 710 may be a magnetic disk, flash memory, or any other non-volatile storage medium.
  • the memory is used to store the instructions in the embodiment corresponding to at least one of FIGS. 1 to 4 .
  • the processor 720 is coupled to the memory 710 and may be implemented as one or more integrated circuits, such as a microprocessor or microcontroller.
  • the processor 720 is used to execute the instructions stored in the memory, which can facilitate the operation and maintenance management of the system and minimize the operation and maintenance burden of the system.
  • the medical system 800 includes a memory 810 and a processor 820 .
  • Processor 820 is coupled to memory 810 through BUS bus 830 .
  • the medical system 800 can also be connected to an external storage device 850 through a storage interface 840 to call external data, and can also be connected to a network or another computer system (not shown) through a network interface 860, which will not be described in detail here.
  • the data instructions are stored in the memory, and then the above-mentioned instructions are processed by the processor, which can facilitate the operation and maintenance management of the system, and minimize the operation and maintenance burden of the system.
  • the present invention also provides a non-transitory computer-readable storage medium on which computer program instructions are stored, and when the instructions are executed by a processor, implement the corresponding functions of at least one of FIG. 1 to FIG. 4 .
  • the steps of the method in the examples may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects.
  • the present invention may take the form of a computer program product embodied on one or more computer-usable non-transitory storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein .
  • computer-usable non-transitory storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions
  • the apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • Biomedical Technology (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本公开提供了一种医疗***及其权限管理方法。该权限管理方法包括：响应于与医疗集团层对应的第一级管理员的角色设置操作，为医院建立第二级管理员，并向所述第二级管理员分配对应的菜单、功能和数据访问权限，其中，医院为医疗集团层的下属机构；以及响应于第二级管理员的角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限。本公开可以方便***的运维管理，尽量减小***的运维负担。

Description

医疗***及其权限管理方法
相关申请的交叉引用
本申请是以CN申请号为202010953741.7，申请日为2020年9月11日的申请为基础，并主张其优先权，该CN申请的公开内容在此作为整体引入本申请中。
技术领域
本公开涉及医疗***管理技术领域，特别涉及一种医疗***及其权限管理方法。
背景技术
医疗***是一门集医学、信息、管理和计算机等多种学科为一体的边缘科学，已经得到了广泛的应用。医疗***是现代化医院运营的必要技术支撑和基础设施。实现医疗***的目的是为了以更现代化、科学化、规范化的手段来加强医院的管理，提高医院的工作效率，改进医疗质量。
发明内容
根据本公开实施例的一个方面，提供了一种医疗***的权限管理方法，包括：响应于与医疗集团层对应的第一级管理员的角色设置操作，为医院建立第二级管理员，并向所述第二级管理员分配对应的菜单、功能和数据访问权限，其中，所述医院为所述医疗集团层的下属机构；以及响应于所述第二级管理员的角色设置操作，向用户分配与所述用户对应的菜单、功能和数据访问权限。
在一些实施例中，所述医院包括：第一医院和与所述第一医院不同的第二医院，所述第二级管理员包括：第一管理员和与所述第一管理员不同的第二管理员，其中，与所述第一管理员对应的菜单、功能和数据访问权限不同于与所述第二管理员对应的菜单、功能和数据访问权限。
在一些实施例中，所述用户包括：第一用户和与所述第一用户不同的第二用户，其中，与所述第一用户对应的菜单、功能和数据访问权限不同于与所述第二用户对应的菜单、功能和数据访问权限。
在一些实施例中，所述权限管理方法还包括：响应于所述第一级管理员的组织维护操作，在所述医疗***中添加、删除或修改组织架构信息。
在一些实施例中，所述权限管理方法还包括：响应于所述第二级管理员的部门维护操作，在所述医院的架构中添加、删除或修改部门信息。
在一些实施例中，所述权限管理方法还包括：响应于所述第一级管理员的信息配置操作，配置所述第二级管理员的管理员信息；以及响应于所述第二级管理员的信息配置操作，配置所述用户的用户信息。
在一些实施例中，所述权限管理方法还包括：响应于所述第一级管理员的菜单设置操作，配置多个菜单功能，其中，每个菜单功能与所述第一级管理员、所述第二级管理员和所述用户的至少一个的角色标识相对应。
在一些实施例中，所述组织架构信息采用树形菜单的方式，所述组织架构信息包括区域和医院；其中，所述区域包括子类，所述子类包括所述医院或者下一级的区域，所述医院为所述组织架构信息的最末层节点。
在一些实施例中，所述权限管理方法还包括：在修改组织架构信息的过程中，修改当前被调整机构对应的父级机构，并确保所述当前被调整机构的地址标识不变，其中，所述当前被调整机构的历史医疗数据存储在所述地址标识。
根据本公开实施例的另一个方面，提供了一种医疗***，包括：接收模块，用于接收与医疗集团层对应的第一级管理员的角色设置操作或与医院对应的第二级管理员的角色设置操作，其中，所述医院为所述医疗集团层的下属机构；以及角色管理模块，用于响应于所述第一级管理员的角色设置操作，为医院建立第二级管理员，并向所述第二级管理员分配对应的菜单、功能和数据访问权限，以及响应于所述第二级管理员的角色设置操作，向用户分配与所述用户对应的菜单、功能和数据访问权限。
在一些实施例中，所述医疗***还包括：组织管理模块，用于响应于所述第一级管理员的组织维护操作，在所述医疗***中添加、删除或修改组织架构信息。
在一些实施例中，所述医疗***还包括：部门管理模块，用于响应于所述第二级管理员的部门维护操作，在所述医院的架构中添加、删除或修改部门信息。
在一些实施例中，所述医疗***还包括：用户管理模块，用于响应于所述第一级管理员的信息配置操作，配置所述第二级管理员的管理员信息，以及响应于所述第二级管理员的信息配置操作，配置所述用户的用户信息。
在一些实施例中，所述医疗***还包括：菜单管理模块，用于响应于所述第一级管理员的菜单设置操作，配置多个菜单功能，其中，每个菜单功能与所述第一级管理员、所述第二级管理员和所述用户的至少一个的角色标识相对应。
根据本公开实施例的另一个方面，提供了一种医疗***，包括：存储器；以及耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器的指令执行如前所述的方法。
根据本公开实施例的另一个方面，提供了一种非瞬时性计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现如前所述的方法。
通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征及其优点将会变得清楚。
附图说明
构成说明书的一部分的附图描述了本公开的实施例，并且连同说明书一起用于解释本公开的原理。
参照附图，根据下面的详细描述，可以更加清楚地理解本公开，其中：
图1是示出根据本公开一个实施例的医疗***的权限管理方法的流程图；
图2是示出根据本公开一个实施例的医疗***的用于第一级管理员的权限管理方法的流程图；
图3是示出根据本公开一个实施例的医疗***的用于第二级管理员的权限管理方法的流程图；
图4是示出根据本公开另一个实施例的医疗***的权限管理方法的流程图；
图5是示出根据本公开一个实施例的医疗***的结构示意图；
图6是示出根据本公开另一个实施例的医疗***的结构示意图；
图7是示出根据本公开另一个实施例的医疗***的结构示意图；
图8是示出根据本公开另一个实施例的医疗***的结构示意图；
图9是示出根据本公开一个实施例的医疗***的组织管理界面的示意图；
图10是示出根据本公开一个实施例的医疗***的部门管理界面的示意图；
图11是示出根据本公开一个实施例的医疗***的角色管理界面的示意图；
图12是示出根据本公开一个实施例的医疗***的用户管理界面的示意图；
图13是示出根据本公开一个实施例的医疗***的菜单管理界面的示意图。
应当明白，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。此外，相同或类似的参考标号表示相同或类似的构件。
具体实施方式
现在将参照附图来详细描述本公开的各种示例性实施例。对示例性实施例的描述仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。本公开可以以许多不同的形式实现，不限于这里所述的实施例。提供这些实施例是为了使本公开透彻且完整，并且向本领域技术人员充分表达本公开的范围。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、材料的组分、数字表达式和数值应被解释为仅仅是示例性的，而不是作为限制。
本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的部分。“包括”或者“包含”等类似的词语意指在该词前的要素涵盖在该词后列举的要素，并不排除也涵盖其他要素的可能。
本公开使用的所有术语(包括技术术语或者科学术语)与本公开所属领域的普通技术人员理解的含义相同，除非另外特别定义。还应当理解，在诸如通用字典中定义的术语应当被解释为具有与它们在相关技术的上下文中的含义相一致的含义，而不应用理想化或极度形式化的意义来解释，除非这里明确地这样定义。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。
本公开的发明人发现，在相关技术中，医疗***对集团化管理的支撑较弱，对于大中型医疗机构，基本上每家医疗机构作为一个单独的个体进行管理。一些医疗***虽然提供了组织架构与权限管理功能，但限制太多，功能无法下发，导致每上线一家***，***就会增加较多的运维工作。久而久之，***自身的运维工作非常繁琐。
鉴于此，本公开的实施例提供一种医疗***的权限管理方法，可以尽量减小运维负担。
图1是示出根据本公开一个实施例的医疗***的权限管理方法的流程图。如图1所示，该权限管理方法包括步骤S102至S104。
在步骤S102，响应于与医疗集团层对应的第一级管理员的角色设置操作，为医院建立第二级管理员，并向该第二级管理员分配对应的菜单、功能和数据访问权限。医院为医疗集团层的下属机构。这里，与第二级管理员对应的功能即为第二级管理员可以通过医疗***实现的功能(例如可以包括：登录***、查看信息、部门设置和角色设置等功能操作等)；菜单可以将这些功能可视化，供第二级管理员选择和点击。
例如，初始时***会在数据库建立一个第一级管理员(或者称为超级管理员)的 账号，以便第一级管理员登录，并配置此账号对应的菜单权限。该第一级管理员即为集团层的管理员。医疗集团可以包括不同的医院，即医院为集团层的下属机构。该第一级管理员通过输入账号、密码和验证码来登录该医疗***。该医疗***可以根据当前的账号的权限返回对应的菜单权限。该第一级管理员可以通过该医疗***建立第一级管理员和第二级管理员的角色标识。例如，每个医院的管理员作为一种第二级管理员的角色，且第二级管理员可以选择对应的医院。
需要说明的是，角色标识是用于标识角色的标记。角色标识包括：第一级管理员的角色标识、第二级管理员的角色标识和用户的角色标识。在某个角色被选择后，就可以为该角色设置角色标识。每种角色标识被设置有对应的菜单权限。
在第一级管理员进行角色设置操作后，医疗***响应于该角色设置操作，为对应的医院创建第二级管理员，并向该第二级管理员分配对应的菜单、功能和数据访问权限。例如，医疗***可以将与该第二级管理员对应的菜单、功能和数据访问权限下发给与该医院对应的分***。由于选择了具体的功能菜单，第二级管理员在登录***后，可以看到这些功能菜单，点击后就可以看到具体的功能页面。
在步骤S104，响应于第二级管理员的角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限。这里，与用户对应的功能即为用户可以通过医疗***实现的功能(例如可以包括：登录***和查看信息等功能操作等)；菜单可以将这些功能可视化，供用户选择和点击。
例如，第二级管理员(或者称为医院管理员)通过输入账号、密码和验证码登录***后，该医疗***可以根据当前账号的权限返回对应的菜单权限。第二级管理员通过医疗***可以建立第二级管理员和用户(例如员工、客户或者患者等角色)的角色标识。角色可以包括多种角色，比如随访医生、慢病医生、护士或市场人员等等。第二级管理员可以选择对应的医院，并进行权限的配置(即功能菜单的选择)。在选择了具体的功能菜单的情况下，第二级管理员在登录***后，可以看到这些功能菜单，点击这些功能菜单后就可以看到具体的功能页面。在第二级管理员进行角色设置操作后，医疗***响应于该角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限。
至此，提供了根据本公开一些实施例的医疗***的权限管理方法。该方法包括：响应于与医疗集团层对应的第一级管理员的角色设置操作，为医院建立第二级管理员，并向该第二级管理员分配对应的菜单、功能和数据访问权限；以及响应于第二级管理 员的角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限。在该方法中，医疗***采用了响应于上一级管理员的角色设置操作，向下一级管理员或用户分配相应的菜单、功能和数据访问权限的方式，因而方便运维管理，尽量减小运维负担。
在一些实施例中，医院可以包括：第一医院和与该第一医院不同的第二医院。第二级管理员可以包括：第一管理员和与该第一管理员不同的第二管理员。例如，与该第一管理员对应的菜单、功能和数据访问权限不同于与该第二管理员对应的菜单、功能和数据访问权限。在该实施例中，可以针对不同的医院建立不同的第二级管理员，并且可以向不同第二级管理员分配不同的菜单、功能和数据访问权限。这样可以实现针对第二级管理员的多样化设置，提高管理水平。
在一些实施例中，用户可以包括：第一用户和与该第一用户不同的第二用户。例如，与该第一用户对应的菜单、功能和数据访问权限不同于与该第二用户对应的菜单、功能和数据访问权限。在该实施例中，可以向不同用户分配不同的菜单、功能和数据访问权限。这可以实现针对用户的多样化设置，提高管理水平。
在一些实施例中，所述权限管理方法还可以包括：响应于第一级管理员的组织维护操作，在医疗***中添加、删除或修改组织架构信息。例如，可以在为医院建立第二级管理员之前，在医疗***中添加、删除或修改组织架构信息。例如，该组织架构信息可以采用树形菜单的方式。该组织架构信息可以包括区域和医院。该区域包括子类，该子类包括医院或者下一级的区域，该医院为组织架构信息的最末层节点。
例如，图9是示出根据本公开一个实施例的医疗***的组织管理界面的示意图。例如，如图9所示，区域可以为：华北地区、华东地区等。在图9中，上级机构是指当前机构的上一级机构(即父级节点)。例如，当前机构为华北地区，则上级机构为XXX公司。机构名称是指当前机构的名称，例如华北地区等。此外，图9中示出了事业部，该事业部可以是与区域同一级的机构，例如本实施例的图9所示。在另一些实施例中，事业部可以是在区域的下一级机构且为医院的上一级机构。
如图9所示，当点击“添加”时，可以在图9中的右侧填写当前添加的机构的信息，可以填写当前机构的上级机构、机构名称、联系电话和备注信息。填写上级机构可以明确当前机构的上级机构是哪个机构，填写机构名称可以明确当前机构是什么机构，填写联系电话可以方便人员通过电话联系该机构，备注信息可以是需要备注的任何信息。这里联系电话和备注信息也可以不填写。这里选择“医院”的界面与选择“区域/事 业部”的界面类似，也是包括上级机构、机构名称、联系电话和备注等。在上述实施例中，第一级管理员可以通过医疗***设置整个医疗***的组织架构。该组织架构可以采用树形菜单的方式。该组织架构分为两大类：区域(或事业部)和医院。医院是叶子结点，即最下面的一层节点，所以医院是没有子类的，只有区域(或事业部)可以建立下一级节点。这样实现了第一管理员对医疗***的组织架构设置。
在本公开的一些实施例中，该组织架构中的任一节点的上级机构是可以修改的，如果该节点下面有子类，该子类也可以一并被修改。例如，如图9所示，将鼠标移到某个机构上，例如移到“华北地区”上，点击该机构，然后点击“编辑”，就可以对该“华北地区”的信息(即上级机构、机构名称、联系电话和备注信息)进行修改。
图9中的“删除”用于删除某个机构。例如，将鼠标移到某个机构上，点击该机构，当点击“删除”时就可以删除该机构。如果删除的节点包含子类，那么其所有的子类会一并被删除。例如，删除“华北地区”，那么“华北地区”下面的“XX医院”也一并被删除。
在一些实施例中，所述权限管理方法还可以包括：响应于第二级管理员的部门维护操作，在医院的架构中添加、删除或修改部门信息。例如，可以在向用户分配对应的菜单、功能和数据访问权限之前，在医院的架构中添加、删除或修改部门信息。例如，这里的部门可以是不同的科室等。
例如，图10是示出根据本公开一个实施例的医疗***的部门管理界面的示意图。如图10所示，部门可以包括：老年病科门诊、泌尿科、泌尿科门诊、内科门诊和外科门诊等。上级部门是指当前部门的上一级部门。部门名称是指当前部门的名称。例如，当前部门为泌尿科门诊，该当前部门的上级部门是泌尿科。
如图10所示，当点击“添加”时，可以在图10中的右侧填写当前添加的部门的信息，可以填写当前部门的上级部门、部门名称和部门描述。填写上级部门可以明确当前部门的上级部门是哪个部门，填写部门名称可以明确当前部门是什么部门，部门描述可以是需要描述部门的任何信息(例如该部门的联系方式等)。
当需要修改某个部门的信息时，如图10所示，可以将鼠标移到某个部门上，例如移到“泌尿科门诊”上，点击“泌尿科门诊”，然后点击“编辑”，就可以对该“泌尿科门诊”的信息(即上级部门、部门名称和部门描述)进行修改。
图10中的“删除”用于删除某个部门。例如，将鼠标移到某个部门(例如“泌尿科”)上，点击该部门，当点击“删除”时就可以删除该部门(例如“泌尿科”)。如果删除的 部门包含子类，那么其所有的子类会一并被删除。例如，删除“泌尿科”，那么“泌尿科”下面的“泌尿科门诊”也一并被删除。
在上述实施例中，第二级管理员通过医疗***设置医院的部门结构。例如，该部门结构可以采用树形菜单的方式。该部门结构可以被多层级设置，且任一节点的上级部门是可以修改的。如果该节点有子类，该子类也可以一并被修改。如果删除该节点，那么其所有的子类会一并被删除。这样实现了第二级管理员对医院部门的设置。
在一些实施例中，所述权限管理方法还可以包括：响应于第一级管理员的信息配置操作，配置第二级管理员的管理员信息。在上述实施例中，第一级管理员可以通过医疗***建立不同的第二级管理员的管理员信息(例如，可以包括账号、密码、身份信息(例如身份证号)和小程序权限等)。例如，第一级管理员可以在用户管理界面通过添加的方式添加某个第二级管理员的账号、密码、身份信息(例如身份证号)和小程序权限等。例如，如图12所示，当点击“添加”后，就可以弹出添加窗口，在添加窗口中添加上述信息。这样实现了对第二级管理员的管理员信息的配置。每个第二级管理员可以根据建立的账号和密码登录***。第二级管理员在登录后***可以看见此账号所对应的菜单、功能和数据访问权限等。
这里，医疗***可以采用小程序的方式从而被加载在移动通信端上。管理员和用户都具有小程序权限，即管理员和用户都可以使用小程序来登录和使用医疗***。这样可以更加方便使用，提高医疗***的便利性。
在一些实施例中，在初次使用医疗***时，可以在医疗***中预先定义第一级管理员。例如，可以将第一级管理员的信息写入医疗***中。
例如，图11是示出根据本公开一个实施例的医疗***的角色管理界面的示意图。这里，角色管理界面包含一些角色的信息，而前面的第二级管理员的账号、密码、身份信息和小程序权限等属于管理员的用户信息，这两者是不同的。具体地，如图11所示，角色的信息可以包括：序号、角色名称、角色标识、角色描述、所属医院、创建时间和操作。序号为某个角色的序号。角色名称是某个角色的名称。角色标识是指某个角色所对应的角色标识。例如角色名称为doctor(医生)的角色标识是第一级管理员(即图11中的超级管理员)，角色名称为XX医院管理员的角色标识是第二级管理员(即图11中的医院管理员)。角色描述是对该角色的简单描述。例如某个角色的角色标识是第一级管理员，则该角色的角色描述即可为第一级管理员。这里的角色描述可以是关于该角色的任何描述，可以方便人员了解该角色的一些属性等。所属医院是 指当前角色所属的医院。创建时间是指创建该角色的时间。操作包括：编辑、删除和权限。这里，“编辑”用于修改某个角色的相关内容(例如，可以包括序号、角色描述、角色标识、角色描述和所属医院等信息)的操作，“删除”用于删除某个角色的操作，“权限”用于设置某个角色的权限。例如，在点击“权限”，可以看到该角色所属的角色标识所对应的所有权限，然后可以通过勾选的方式为该角色设置相应的权限。
例如，第一级管理员的权限(即第一级管理员可以管理的菜单)包括：***管理、患者中心、随访中心、AI(Artificial Intelligence，人工智能)智能和数据统计，第二级管理员的权限(即第二级管理员可以管理的菜单)包括：患者中心、随访中心、AI智能和数据统计，用户的权限(即用户可以管理的菜单)包括：患者中心、随访中心和AI智能。
在一些实施例中，所述权限管理方法还可以包括：响应于第二级管理员的信息配置操作，配置用户的用户信息。
在上述实施例中，第二级管理员可以通过医疗***建立不同用户的用户信息(例如，可以包括账号、密码、身份信息和小程序权限等)。这样实现了对用户的用户信息的配置。例如，第二级管理员可以在用户管理界面通过添加的方式添加某个用户的账号、密码、身份信息(例如身份证号)和小程序权限等。例如，如图12所示，当点击“添加”后，就可以弹出添加窗口，在添加窗口中添加上述信息。每个用户可以根据建立的账号和密码登录***。在用户登录后，***可以根据此账号的权限，分配对应的菜单、功能和数据访问权限。
例如，图12是示出根据本公开一个实施例的医疗***的用户管理界面的示意图。如图12所示，用户的信息可以包括：序号、用户名、姓名、手机号、性别、所属医院、所属部门、角色、状态和操作。序号为某个用户的序号。用户名是某个用户的名称。手机号是某个用户的手机号。所属医院是某个用户所属的医院。例如，序号为“00000030”的用户所属的医院是XX医院。所属部门是某个用户所属的部门。例如，序号为“00000030”的用户所属的部门是消化科。角色是某个用户的角色。例如，序号为“00000030”的用户的角色是XX医院管理员。状态表示某个用户的状态是否有效。“有效”表示相应的用户可以登录***，“锁定”表示相应的用户不能登录***。操作可以包括编辑和删除。“编辑”用于修改某个用户的相关内容的操作。例如，点击某个用户后面的“编辑”，就可以修改该用户的序号、用户名、姓名、手机号、性别、所属医院、所属部门、角色和状态等信息。“删除”用于删除某个用户的操作。
在一些实施例中，所述权限管理方法还可以包括：响应于第一级管理员的菜单设置操作，配置多个菜单功能。每个菜单功能与第一级管理员、第二级管理员和用户的至少一个的角色标识相对应。例如，可以在为医院建立第二级管理员之前且在医疗***中添加、删除或修改组织架构信息之后，响应于第一级管理员的菜单设置操作，配置多个菜单功能。
例如，图13是示出根据本公开一个实施例的医疗***的菜单管理界面的示意图。如图13所示，该菜单可以包括：***管理、患者中心、随访中心、AI智能和数据统计等。可以根据需要添加、编辑或删除某个菜单。例如，鼠标选择“***管理”菜单，然后点击“添加”，就可以为“***管理”菜单添加下一级菜单在添加下一级菜单时，可以设置该下一级菜单的父级节点、标题和权限标识。这里，父级节点是指该下一级菜单的上一级菜单，标题是指该下一级菜单的名称，权限标识是指第一级管理员、第二级管理员和用户中的哪一个或哪几个具有该下一级菜单的权限。例如，在设置某个菜单功能的过程中，当点击权限标识的添加框时，就可以弹出第一级管理员、第二级管理员和用户三个角色标识，通过勾选的方式选择第一级管理员、第二级管理员和用户中的哪一个或哪几个具有该菜单的权限。
另外，如图13所示，在添加下一级菜单时，还可以设置该下一级菜单的图标、资源路径、请求方法、类型、排序、前端组件和前端地址等。这里，资源路径可以是某个菜单功能的URL(Uniform Resource Location，统一资源定位符)。请求方法可以被选择为post方法或get方法。类型为资源请求类型。排序为所添加菜单的序号，例如，该序号可以人工输入。可以在“前端组件”后面的方框中输入该菜单的描述内容，例如可以是任何描述内容。前端地址为所添加菜单的地址。通过该前端地址可以直接到达该地址所相应的菜单页面。
当需要修改某个菜单功能时，可以通过鼠标选择某个菜单功能，然后点击“编辑”，就可以修改该菜单功能。当需要删除某个菜单功能时，可以通过鼠标选择某个菜单功能，然后点击“删除”，就可以删除该菜单功能。
在上述实施例中，第一级管理员可以通过医疗***设置整个医疗***的所有功能菜单。每个功能菜单对应其角色标识(即，哪些角色标识有权限看到这个功能菜单，才有选择此菜单的权限)。菜单管理可以是动态配置的。通过配置操作，医疗***可以直接与前端页面对应，之后在进行角色的权限选择时，可以根据选择的菜单展示相应的功能页面。因此，该医疗***具有比较好的灵活性和可扩展性。
图2是示出根据本公开一个实施例的医疗***的用于第一级管理员的权限管理方法的流程图。如图2所示，该方法可以包括步骤S202至S208。
在步骤S202，响应于第一级管理员的组织维护操作，在医疗***中添加、删除或修改组织架构信息。
这里，组织架构统可以由第一级管理员维护，采用树形分层结构，可以不限制层数。在该组织架构中，医院层级可以具有标识，能够识别出该层级为医院。
在一些实施例中，所述权限管理方法还可以包括：在修改组织架构信息的过程中，修改当前被调整机构对应的父级机构，并确保该当前被调整机构的地址标识不变。当前被调整机构的历史医疗数据存储在该地址标识。
在该实施例中，当组织机构调整时，可修改当前被调整机构对应的父级机构(即上一级机构)，并确保该当前被调整机构的地址标识(ID)不变，从而不影响存储在该地址标识的历史医疗数据。
在一些实施例中，该组织架构可以是单个医院的一层结构，也可以是医疗集团和医院的二级分层结构，还可以是医疗集团、区域、事业部和医院的四层分级结构。例如，医疗集团是区域的上一级机构，区域是事业部的上一级机构，事业部是医院的上一级机构。在另一些实施例中，区域和事业部可以为同一级机构。
在步骤S204，响应于第一级管理员的菜单设置操作，配置多个菜单功能。
例如，当新增菜单时，响应于第一级管理员的菜单设置操作，医疗***可以选择与该新增的菜单对应的角色标识。
在步骤S206，响应于第一级管理员的角色设置操作，为医院建立第二级管理员，并向该第二级管理员分配对应的菜单、功能和数据访问权限。
例如，响应于第一级管理员的角色设置操作，医疗***可以创建角色，角色可以拥有角色标识(包括第一级管理员、第二级管理员和用户)。第一级管理员在创建角色后还可以为该角色授权。在为该角色授权时医疗***可以根据角色标识显示对应的菜单，然后第一级管理员从中勾选具体菜单，保存后完成角色授权。
在步骤S208，响应于第一级管理员的信息配置操作，配置第二级管理员的管理员信息。
例如，响应于第一级管理员的信息配置操作，医疗***可以配置该第二级管理员所属医院和对应的第二级管理员角色，然后设置登录名和密码。医疗***还可以生成管理员列表，该管理员列表包括各个医院的第二级管理员的管理员信息。
至此，提供了根据本公开一些实施例的医疗***的用于第一级管理员的权限管理方法。在该方法中，在第一级管理员在登录***后，医疗***响应于第一级管理员的组织维护操作，在医疗***中添加、删除或修改组织架构信息；然后，医疗***响应于第一级管理员的菜单设置操作，配置菜单功能，每个菜单功能可以对应至少一个角色标识；然后，医疗***响应于第一级管理员的角色设置操作，向医院分配第二级管理员，并向该第二级管理员对分配应的菜单、功能和数据访问权限；接下来，医疗***响应于第一级管理员的信息配置操作，配置第二级管理员的管理员信息。这样实现了医疗***响应于第一级管理员的相关操作的对应设置，可以便于集团的维护管理。
在上面的实施例中，可以在组织管理步骤(S202)和菜单管理步骤(S204)之后，执行角色管理步骤(S206)，在角色管理步骤之后，执行用户管理步骤(S208)。换言之，角色管理步骤可以依赖于组织管理步骤和菜单管理步骤，用户管理步骤可以依赖于角色管理步骤。
图3是示出根据本公开一个实施例的医疗***的用于第二级管理员的权限管理方法的流程图。如图3所示，该方法可以包括步骤S302至S306。
在步骤S302，响应于第二级管理员的部门维护操作，在医院的架构中添加、删除或修改部门信息。即，第二级管理员登录***后，可以维护对应医院的部门架构。
在步骤S304，响应于第二级管理员的角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限。
例如，响应于第二级管理员的角色设置操作，医疗***可以维护本医院的角色(例如，医生、护士和管理员等)，创建角色后为该角色授权。在为角色授权时医疗***可以根据角色标识显示对应的菜单，然后第二级管理员从中勾选具体菜单，保存后完成角色授权。
在一些实施例中，第二级管理员在创建角色时不可选择第一级管理员的角色标识，也不能看到第一级管理员的角色标识对应的菜单，也不能操作第一级管理员具有的功能。
在步骤S306，响应于第二级管理员的信息配置操作，配置用户的用户信息。
响应于第二级管理员的信息配置操作，医疗***可以维护第二级管理员所在医院的用户。例如第二级管理员可以选择该用户所属部门和对应的角色，然后设置登录名和密码。该医疗***可以生成用户列表，该用户列表包括该医院的用户信息。
至此，提供了根据本公开一个实施例的医疗***的用于第二级管理员的权限管理 方法。在该方法中，在第二级管理员登录***后，医疗***响应于第二级管理员的部门维护操作，在医院的架构中添加、删除或修改部门信息；然后，医疗***响应于第二级管理员的角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限；接下来，医疗***响应于第二级管理员的信息配置操作，配置用户的用户信息。这样实现了医疗***响应于第二级管理员的相关操作的对应设置，可以便于集团的维护管理。
在上面的实施例中，可以在部门管理步骤(S302)和角色管理步骤(S304)之后，执行用户管理步骤(S306)。换言之，用户管理步骤可以依赖于部门管理步骤和角色管理步骤。
在一些实施例中，第一级管理员负责整个***的组织设置、菜单设置、以及具体的角色设置和用户设置等，可以设置每个医院的第二级管理员。第一级管理员可以通过医疗***创建第一级管理员和第二级管理员。第二级管理员负责每个医院的部门设置、角色设置和用户设置。第二级管理员可以通过医疗***建立本医院管理员和用户(例如员工)。该用户可以是不同的角色。不同的角色具有不同的业务***菜单、功能和数据访问权限。不同角色的用户在进入***后，可以具有不同的***菜单、功能和数据访问权限。在一些实施例中，每个医院的员工只能看到自己医院的相关功能和数据。
下面结合图4详细描述这些管理员和用户的管理流程。
图4是示出根据本公开另一个实施例的医疗***的权限管理方法的流程图。如图4所示，该方法可以包括步骤S402至S416。
在步骤S402，第一级管理员先进入组织管理界面，设置整个医疗***的组织架构。
在步骤S404，第一级管理员建立第二级管理员的角色，为第二级管理员分配对应的菜单、功能和数据访问权限。
在步骤S406，第一级管理员为第二级管理员建立不同的管理员信息，例如，账号、密码、身份证和小程序权限等。
在步骤S408，第二级管理员输入账号、密码和验证码以登录***。
在步骤S410，第二级管理员进入部门管理界面，维护所负责医院的部门结构。
在步骤S412，第二级管理员进入角色管理界面，建立用户的角色标识。
在步骤S414，第二级管理员进行用户维护，为用户选择角色和部门，建立不同用户的用户信息，例如，账号、密码、身份证和小程序权限等。
在步骤S416，用户登录***，可以看到分配给自己的***菜单、功能、数据访问权限以及与自己医院相关的功能和数据。
例如，当用户为医生时，可以选择医生的职称等级(例如主任医师、副主任医师或主治医师等)和维护医生的专业擅长领域。医疗***可以为医生提供服务类型的选项(例如，图文咨询、体检报告解读和视频问诊等)。又例如，当患者作为用户通过移动通信端选择服务时，可以获取对应的医生列表，以及查看每一个医生的职称和专业擅长信息。因此，该医疗***可以根据为用户提供的服务类型获取用户申请的服务，并进行相应答复或解读。例如，医生可以具有PC端权限和小程序权限，即医生可以通过PC端的程序或移动通信端的小程序来进行相应的处理；患者具有小程序权限而没有PC端权限，即患者仅能通过移动通信端的小程序进行相应的处理。
至此，提供了本公开另一个实施例的医疗***的权限管理方法。通过该权限管理方法，可以获知第一级管理员、第二级管理员和用户分别负责的事物和可执行的相关操作。这样的体系设置便于医疗***的维护。
在上述医疗***的权限管理方法中，处于集团层的第一级管理员负责维护组织架构，为医院创建第二级管理员，并赋予第二级管理员管理医院的权限功能。第二级管理员登录***后，管理自己医院的部门、角色、用户和权限。用户登陆***后可以正常使用***功能。这样，该方法不仅满足集团化管理的要求，又可以使医院作为单独的个体进行管理，对管理权限进行分层分级，均衡的分配每位管理员的工作，从而减轻***运维工作。而且，上述方法也为用户提供了可操作的功能。
在一些实施例中，可以先进行组织管理步骤，然后执行部门管理步骤，然后执行菜单管理步骤，然后执行角色管理步骤，然后执行用户管理步骤。换言之，部门管理步骤可以依赖于组织管理步骤，角色管理步骤可以依赖于组织管理步骤和菜单管理步骤，用户管理步骤可以依赖于部门管理步骤和角色管理步骤。
在一些实施例中，当医院没有对应的第二级管理员时，也可以对第一级管理员赋予对应医院的管理权限，进行医院级的数据维护。在维护医院的部门和用户数据后，集团层面的组织架构可以自动获取医院的部门和用户数。
图5是示出根据本公开一个实施例的医疗***的结构示意图。如图5所示，该医疗***可以包括接收模块502和角色管理模块504。
接收模块502用于接收与医疗集团层对应的第一级管理员的角色设置操作或与医院对应的第二级管理员的角色设置操作。医院为医疗集团层的下属机构。
角色管理模块504用于响应于第一级管理员的角色设置操作，为医院建立第二级管理员，并向该第二级管理员分配对应的菜单、功能和数据访问权限，以及响应于第二级管理员的角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限。这里，角色管理模块504可以用于设计每个医院的角色，并配置角色对应的菜单、功能和数据访问权限。
至此，提供了根据本公开一些实施例的医疗***。该医疗***包括接收模块和角色管理模块。接收模块用于接收与医疗集团层对应的第一级管理员的角色设置操作或与医院对应的第二级管理员的角色设置操作。角色管理模块，用于响应于第一级管理员的角色设置操作，为医院分配第二级管理员，并向第二级管理员分配对应的菜单、功能和数据访问权限，以及响应于第二级管理员的角色设置操作，向用户分配与该用户对应的菜单、功能和数据访问权限。该医疗***可以方便***的运维管理，尽量减小***的运维负担。
图6是示出根据本公开另一个实施例的医疗***的结构示意图。如图6所示，该医疗***可以包括接收模块502和角色管理模块504。
在一些实施例中，如图6所示，该医疗***还可以包括组织管理模块606。该组织管理模块606用于响应于第一级管理员的组织维护操作，在医疗***中添加、删除或修改组织架构信息。因此，该组织管理模块606可以用于组织医院的定义、设计和维护。
在一些实施例中，如图6所示，该医疗***还可以包括部门管理模块608。该部门管理模块608用于响应于第二级管理员的部门维护操作，在医院的架构中添加、删除或修改部门信息。因此，该部门管理模块608可以用于每个医院里面各个部门的定义、设计和维护。
在一些实施例中，如图6所示，该医疗***还可以包括用户管理模块610。该用户管理模块610用于响应于第一级管理员的信息配置操作，配置第二级管理员的管理员信息，以及响应于第二级管理员的信息配置操作，配置用户的用户信息。例如，用户管理模块610可以用于创建每个医院的用户、身份信息、角色信息(角色已经分配PC(Personal Computer，个人电脑)端权限)和移动端权限信息等，且可以为用户设置有效或锁定等状态。
在一些实施例中，如图6所示，该医疗***还可以包括菜单管理模块612。该菜单管理模块612用于响应于第一级管理员的菜单设置操作，配置多个菜单功能。每个 菜单功能与第一级管理员、第二级管理员和用户的至少一个的角色标识相对应。这里，菜单管理模块612可以用于***中各个菜单功能的配置、设计、维护以及与前端页面的对应关系配置。
在一些实施例中，角色管理模块504、组织管理模块606、部门管理模块608、用户管理模块610和菜单管理模块612的相关数据可以存储在数据库中。
在一些实施例中，该医疗***可以包括PC端***和移动通信端(或者称为小程序端)***的至少一个。例如，在PC端上的***可以供医院人员使用，在移动通信端上的小程序端可以供医院人员和客户使用。当然，本领域技术人员能够理解，该医疗***可以仅设置在PC端上，或者也可以仅设置在移动通信端上，或者，也可以设置在PC端和移动通信端上。
PC端的使用者可以具有3种角色标识：第一级管理员、第二级管理员和医院员工(用户的一种)。需要说明的是，这里的角色标识不等于角色，该角色标识可以区分能够允许看到的功能模块，以便进行选择。PC端的角色可以由第一级管理员和第二级管理员设置，不限数量，根据各个医院的具体需要配置即可。第一级管理员可以建立第一级管理员和第二级管理员，第二级管理员可以建立自己医院的管理员和用户。例如，用户可以是员工，员工可以是各种不同的角色。第一级管理员负责组织管理模块、菜单管理模块、角色管理模块和用户管理模块。第二级管理员负责部门管理模块、角色管理模块和用户管理模块。
小程序端可以适用于4类角色：管理员、医生/护士、游客/客户和市场人员。这里，员工、医生/护士、游客/客户和市场人员都是具体功能的使用者。员工可以看到具体的菜单对应的功能页面(例如，慢病卡、随访管理、健康处方、图文咨询、小工具和统计)。
在上述医疗***中，每个第二级管理员可以设置自己医院的各种角色，给角色赋予不同的权限，以满足不同医院可能有不同角色和不同权限的需求。每个医院的数据互不干扰。每个用户可以有多个角色，且不需要对于用户进行单独的权限设置。可以根据用户所设置的角色特征分别赋予不同的角色权限以达到最终的用户权限设置。PC端和移动通信端(例如手机)用户的角色权限是分开的，可以根据需求自行调整，从而增加***的灵活性和可扩展性。每个医院的管理员可以设置自己医院的部门层级。医院之间的部门以及各种功能数据互不影响，因而使得***设置更加灵活。
上述医疗***可以充分满足多层级组织架构的扩充与变化调整，可以不受任何限 制，也不影响历史医疗数据。在该医疗***中，权限分层级管理，并下发对应功能，从而可以均衡分配管理工作，降低运维难度。另外，可以使得每一条医疗数据对应组织机构编码，这样集团层面可实现对各机构的运营数据统一获取。
图7是示出根据本公开另一个实施例的医疗***的结构示意图。该医疗***包括存储器710和处理器720。其中：
存储器710可以是磁盘、闪存或其它任何非易失性存储介质。存储器用于存储图1至图4中的至少一个所对应实施例中的指令。
处理器720耦接至存储器710，可以作为一个或多个集成电路来实施，例如微处理器或微控制器。该处理器720用于执行存储器中存储的指令，可以方便***的运维管理，尽量减小***的运维负担。
在一些实施例中，还可以如图8所示，该医疗***800包括存储器810和处理器820。处理器820通过BUS总线830耦合至存储器810。该医疗***800还可以通过存储接口840连接至外部存储装置850以便调用外部数据，还可以通过网络接口860连接至网络或者另外一台计算机***(未标出)，此处不再进行详细介绍。
在该实施例中，通过存储器存储数据指令，再通过处理器处理上述指令，可以方便***的运维管理，尽量减小***的运维负担。
在另一些实施例中，本发明还提供了一种非瞬时性计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现图1至图4中的至少一个所对应实施例中的方法的步骤。本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(***)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
至此，已经详细描述了本公开的各实施例。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。
虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改或者对部分技术特征进行等同替换。本公开的范围由所附权利要求来限定。

Claims (16)

  1. 一种医疗***的权限管理方法，包括：
    响应于与医疗集团层对应的第一级管理员的角色设置操作，为医院建立第二级管理员，并向所述第二级管理员分配对应的菜单、功能和数据访问权限，其中，所述医院为所述医疗集团层的下属机构；以及
    响应于所述第二级管理员的角色设置操作，向用户分配与所述用户对应的菜单、功能和数据访问权限。
  2. 根据权利要求1所述的权限管理方法，其中，
    所述医院包括：第一医院和与所述第一医院不同的第二医院，
    所述第二级管理员包括：第一管理员和与所述第一管理员不同的第二管理员，
    其中，与所述第一管理员对应的菜单、功能和数据访问权限不同于与所述第二管理员对应的菜单、功能和数据访问权限。
  3. 根据权利要求1所述的权限管理方法，其中，
    所述用户包括：第一用户和与所述第一用户不同的第二用户，
    其中，与所述第一用户对应的菜单、功能和数据访问权限不同于与所述第二用户对应的菜单、功能和数据访问权限。
  4. 根据权利要求1至3任意一项所述的权限管理方法，还包括：
    响应于所述第一级管理员的组织维护操作，在所述医疗***中添加、删除或修改组织架构信息。
  5. 根据权利要求1至3任意一项所述的权限管理方法，还包括：
    响应于所述第二级管理员的部门维护操作，在所述医院的架构中添加、删除或修改部门信息。
  6. 根据权利要求1至3任意一项所述的权限管理方法，还包括：
    响应于所述第一级管理员的信息配置操作，配置所述第二级管理员的管理员信息； 以及
    响应于所述第二级管理员的信息配置操作，配置所述用户的用户信息。
  7. 根据权利要求4所述的权限管理方法，还包括：
    响应于所述第一级管理员的菜单设置操作，配置多个菜单功能，其中，每个菜单功能与所述第一级管理员、所述第二级管理员和所述用户的至少一个的角色标识相对应。
  8. 根据权利要求4所述的权限管理方法，其中，
    所述组织架构信息采用树形菜单的方式，所述组织架构信息包括区域和医院；
    其中，所述区域包括子类，所述子类包括所述医院或者下一级的区域，所述医院为所述组织架构信息的最末层节点。
  9. 根据权利要求4所述的权限管理方法，还包括：
    在修改组织架构信息的过程中，修改当前被调整机构对应的父级机构，并确保所述当前被调整机构的地址标识不变，其中，所述当前被调整机构的历史医疗数据存储在所述地址标识。
  10. 一种医疗***，包括：
    接收模块，用于接收与医疗集团层对应的第一级管理员的角色设置操作或与医院对应的第二级管理员的角色设置操作，其中，所述医院为所述医疗集团层的下属机构；以及
    角色管理模块，用于响应于所述第一级管理员的角色设置操作，为医院建立第二级管理员，并向所述第二级管理员分配对应的菜单、功能和数据访问权限，以及响应于所述第二级管理员的角色设置操作，向用户分配与所述用户对应的菜单、功能和数据访问权限。
  11. 根据权利要求10所述的医疗***，还包括：
    组织管理模块，用于响应于所述第一级管理员的组织维护操作，在所述医疗***中添加、删除或修改组织架构信息。
  12. 根据权利要求10所述的医疗***，还包括：
    部门管理模块，用于响应于所述第二级管理员的部门维护操作，在所述医院的架构中添加、删除或修改部门信息。
  13. 根据权利要求10所述的医疗***，还包括：
    用户管理模块，用于响应于所述第一级管理员的信息配置操作，配置所述第二级管理员的管理员信息，以及响应于所述第二级管理员的信息配置操作，配置所述用户的用户信息。
  14. 根据权利要求10所述的医疗***，还包括：
    菜单管理模块，用于响应于所述第一级管理员的菜单设置操作，配置多个菜单功能，其中，每个菜单功能与所述第一级管理员、所述第二级管理员和所述用户的至少一个的角色标识相对应。
  15. 一种医疗***，包括：
    存储器；以及
    耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器的指令执行如权利要求1至9任意一项所述的方法。
  16. 一种非瞬时性计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现如权利要求1至9任意一项所述的方法。
PCT/CN2021/110561 2020-09-11 2021-08-04 医疗***及其权限管理方法 WO2022052682A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/788,623 US20230021770A1 (en) 2020-09-11 2021-08-04 Medical System and Authority Management Method Therefor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010953741.7A CN112100658A (zh) 2020-09-11 2020-09-11 医疗***及其权限管理方法
CN202010953741.7 2020-09-11

Publications (1)

Publication Number Publication Date
WO2022052682A1 true WO2022052682A1 (zh) 2022-03-17

Family

ID=73752357

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/110561 WO2022052682A1 (zh) 2020-09-11 2021-08-04 医疗***及其权限管理方法

Country Status (3)

Country Link
US (1) US20230021770A1 (zh)
CN (1) CN112100658A (zh)
WO (1) WO2022052682A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112100658A (zh) * 2020-09-11 2020-12-18 京东方科技集团股份有限公司 医疗***及其权限管理方法
CN112632500A (zh) * 2020-12-30 2021-04-09 绿盟科技集团股份有限公司 一种数据管理方法和电子设备
CN112635036B (zh) * 2021-03-10 2021-06-22 白杨智慧医疗信息科技(北京)有限公司 一种自动角色识别的医疗信息智能显示方法和***
US20220327235A1 (en) * 2021-04-05 2022-10-13 Tamerlan Rakhimbekov Accident and/or bodily injury management and monitoring application for law firms, medical providers, insurance companies, process, system, apparatus, and a method of using same
CN113704812A (zh) * 2021-07-16 2021-11-26 杭州医康慧联科技股份有限公司 用户访问浏览权限动态配置方法
CN115983807A (zh) * 2023-03-20 2023-04-18 江苏橙智云信息技术有限公司 一种基于物联网的智能建筑权限模块化管理方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104050401A (zh) * 2013-03-12 2014-09-17 腾讯科技（深圳）有限公司 用户权限管理方法及***
CN106302435A (zh) * 2016-08-11 2017-01-04 上海泛微网络科技股份有限公司 一种基于集团化分级分权管理***
CN109948350A (zh) * 2019-01-18 2019-06-28 深圳市万睿智能科技有限公司 一种层级组织结构账号权限分配方法及其***与存储介质
CN110957025A (zh) * 2019-12-02 2020-04-03 重庆亚德科技股份有限公司 一种医疗卫生信息安全管理***
CN111079127A (zh) * 2019-11-20 2020-04-28 武汉达梦数据技术有限公司 一种信息***的用户分级授权管理方法和装置
CN112100658A (zh) * 2020-09-11 2020-12-18 京东方科技集团股份有限公司 医疗***及其权限管理方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105373726A (zh) * 2014-08-18 2016-03-02 南京普爱射线影像设备有限公司 一种用户权限管理***
CN104657928B (zh) * 2015-02-14 2016-04-06 张晓� 一种医疗合作***
US10720232B2 (en) * 2016-04-13 2020-07-21 Accenture Global Solutions Limited Distributed healthcare records management
KR101729143B1 (ko) * 2016-08-05 2017-04-21 주식회사 파인인사이트 의료프로세스 관리시스템
CN106952205A (zh) * 2017-03-22 2017-07-14 首都医科大学附属北京天坛医院 一种基于互联网的移动远程医疗综合服务***

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104050401A (zh) * 2013-03-12 2014-09-17 腾讯科技（深圳）有限公司 用户权限管理方法及***
CN106302435A (zh) * 2016-08-11 2017-01-04 上海泛微网络科技股份有限公司 一种基于集团化分级分权管理***
CN109948350A (zh) * 2019-01-18 2019-06-28 深圳市万睿智能科技有限公司 一种层级组织结构账号权限分配方法及其***与存储介质
CN111079127A (zh) * 2019-11-20 2020-04-28 武汉达梦数据技术有限公司 一种信息***的用户分级授权管理方法和装置
CN110957025A (zh) * 2019-12-02 2020-04-03 重庆亚德科技股份有限公司 一种医疗卫生信息安全管理***
CN112100658A (zh) * 2020-09-11 2020-12-18 京东方科技集团股份有限公司 医疗***及其权限管理方法

Also Published As

Publication number Publication date
CN112100658A (zh) 2020-12-18
US20230021770A1 (en) 2023-01-26

Similar Documents

Publication Publication Date Title
WO2022052682A1 (zh) 医疗***及其权限管理方法
US10474646B2 (en) Systems and methods for creating a form for receiving data relating to a health care incident
CN110443010B (zh) 一种在信息***中权限可视化配置控制方法、装置、终端及存储介质
US11461491B2 (en) Unifying interface for cloud content sharing services
CN110457891B (zh) 一种权限配置界面显示方法、装置、终端以及存储介质
CN113692582B (zh) 用于建立数据隐私管线和合约协议以共享数据的用户接口
US9177168B2 (en) Method of modifying access control for web services using query languages
US8539575B2 (en) Techniques to manage access to organizational information of an entity
EP3084590B1 (en) Controlling access to a software application
US20140289829A1 (en) Computer account management system and realizing method thereof
US20060218394A1 (en) Organizational role-based controlled access management system
JP5893791B1 (ja) 多施設統合文書管理システム
US20130332891A1 (en) Techniques to manage access to organizational information of an entity
KR20020084184A (ko) 사용자 정보 관리 방법 및 시스템, 사용자 커뮤니티위임형 관리 제공 방법, 사용자 커뮤니티 관리 제어인에이블링 방법, 사용자 커뮤니티 관리 툴, 컴퓨터 판독가능 매체
CN115868144A (zh) 经由安全发现框架的临时云提供商凭据
CN111339561B (zh) 数据处理方法、电子设备与存储介质
CN116018779A (zh) 面向软件即服务租户的基于策略的基因组数据共享
US8095970B2 (en) Dynamically associating attribute values with objects
CN115543428A (zh) 一种基于策略模板的模拟数据生成方法和装置
JP2000155715A (ja) コンピュータのディレクトリアクセス制御システム及び方法
US11238030B2 (en) Issue tracking systems and methods for a configurable project hierarchy
Okediran et al. A Framework for a Cloud-Based Electronic Health Records System for Developing Countries
US20230044881A1 (en) Coordinated processing and scheduling for surgical procedures
Chi et al. Implementation of a security access control model for inter-organizational healthcare information systems
CA2940291A1 (en) System and method for multi-tenant healthcare relationship management

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21865738

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21865738

Country of ref document: EP

Kind code of ref document: A1