A hospital information system access control method and system based on multi-factor authentication

Abstract

This application discloses a method and system for access control of a hospital information system based on multi-factor authentication. The method includes: obtaining a user's access request to the hospital information system and determining the medical data type corresponding to the access request; constructing a set of candidate multi-factor authentication factors; obtaining the privacy intrusion attribute and security contribution attribute of each authentication factor; under the premise of conflict constraints between the privacy intrusion attribute and the security contribution attribute, constructing a partial order relationship between the authentication factors and eliminating authentication factors that are simultaneously dominated by other authentication factors in both the privacy intrusion attribute and the security contribution attribute, to generate a set of non-dominated authentication factors; selecting authentication factors from different attribute types from the set of non-dominated authentication factors to form an authentication factor combination; authenticating the access request based on the authentication factor combination, and controlling access permissions to the hospital information system according to the authentication result. This application achieves access control that balances privacy protection and system security.

Description

Technical Field

[0001] This application relates to the fields of information security and access control technology, and in particular to an access control method and system for hospital information systems based on multi-factor authentication. Background Technology

[0002] With the widespread application of hospital information systems in clinical diagnosis and treatment, medical management, and scientific research analysis, medical data such as electronic medical records, examination reports, and imaging data face high security and privacy risks during their flow within hospitals and across systems. Existing hospital information systems typically employ multi-factor authentication methods based on usernames and passwords, smart cards, biometrics, or combinations thereof to control user access.

[0003] However, existing multi-factor authentication schemes generally suffer from the following problems: the selection of authentication factors is singular and it is difficult to dynamically adjust them according to the privacy sensitivity of different medical data types; some high-security authentication factors may bring high privacy intrusion, while authentication factors with low privacy intrusion may not provide sufficient security. Existing technologies usually handle this through simple weighting or thresholding, which makes it difficult to accurately reflect the conflict between the two; existing schemes mostly adopt a binary control method of "authentication pass / fail", which cannot finely distinguish access permissions based on the actual reliability and privacy impact of the authentication factor combination.

[0004] Therefore, there is an urgent need for a multi-factor authentication method that can strike a reasonable balance between privacy protection and security enhancement, and achieve refined access control in combination with hospital business scenarios. Summary of the Invention

[0005] This application provides a method and system for access control of hospital information systems based on multi-factor authentication, achieving access control that balances privacy protection and system security.

[0006] This application provides the following solution:

[0007] According to a first aspect, a method for access control of a hospital information system based on multi-factor authentication is provided. The method includes: acquiring a user's access request to the hospital information system and determining the medical data type corresponding to the access request; constructing a multi-factor authentication candidate factor set, the multi-factor authentication candidate factor set including multiple authentication factors, the attribute types of the authentication factors including at least identity credential factors, behavioral feature factors, and environmental state factors; acquiring the privacy intrusion attribute and security contribution attribute of each authentication factor respectively; under the premise that there are conflict constraints between the privacy intrusion attribute and the security contribution attribute, constructing a partial order relationship between the authentication factors and eliminating authentication factors that are simultaneously dominated by other authentication factors in both the privacy intrusion attribute and the security contribution attribute, so as to generate a non-dominated authentication factor set; selecting authentication factors from different attribute types from the non-dominated authentication factor set, and constructing an authentication factor combination that satisfies the multi-factor requirements according to the medical data type; authenticating the access request based on the authentication factor combination, and controlling access permissions to the hospital information system according to the authentication result.

[0008] According to one achievable method in this application embodiment, determining the medical data type corresponding to the access request includes: jointly parsing the target resource identifier, request operation type, and user role information in the access request; mapping the access request to at least one medical data semantic category based on a pre-constructed medical data semantic mapping relationship; and determining the medical data type corresponding to the access request according to the medical data semantic category, wherein the medical data type is used to characterize the privacy association features of the medical data involved in the access request in the clinical business process.

[0009] According to one achievable method in this application embodiment, the step of obtaining the privacy intrusion attribute and security contribution attribute of each authentication factor includes: obtaining the personal information exposure method and information reuse count of the authentication factor in the historical authentication process, and determining whether it is necessary to collect new personal information; constructing the privacy intrusion attribute of the authentication factor based on the personal information exposure method, information reuse count, and the need to collect new personal information; obtaining the success rate, abnormal interception rate, and replacement rate of the authentication factor in the historical authentication process; and constructing the security contribution attribute of the authentication factor based on the success rate, abnormal interception rate, and replacement rate.

[0010] According to one achievable method in an embodiment of this application, the step of constructing a partial order relationship between the authentication factors under the premise that there is a conflict constraint between the privacy intrusion attribute and the security contribution attribute includes: for any two authentication factors, comparing their privacy intrusion attribute and security contribution attribute respectively; when one authentication factor is lower than or equal to the other authentication factor in the privacy intrusion attribute and higher than or equal to the other authentication factor in the security contribution attribute, determining that the former dominates the latter in the partial order relationship; when any two authentication factors do not satisfy the dominance relationship, determining that the two are in an incomparable state; based on the dominance relationship and the incomparable state, forming a partial order structure to describe the relative constraint relationship between the authentication factors in privacy protection and security enhancement.

[0011] According to one achievable method in an embodiment of this application, generating the set of non-dominated authentication factors includes: traversing the partial order structure, identifying authentication factors in the partial order structure that are dominated by at least one other authentication factor; removing the dominated authentication factors from the multi-factor authentication candidate factor set, and retaining authentication factors that are not dominated by other authentication factors and authentication factors that are in an incomparable state, to form the set of non-dominated authentication factors.

[0012] According to one achievable method in this application embodiment, the step of selecting authentication factors from different attribute types from the non-dominated authentication factor set and constructing an authentication factor combination that satisfies multi-factor requirements based on the medical data type includes: determining authentication attribute coverage requirements matching the access request based on the medical data type, wherein the authentication attribute coverage requirements are used to limit the minimum number of attribute types that the authentication factor combination needs to cover; constructing authentication factor category coverage relationships based on the attribute types of each authentication factor in the non-dominated authentication factor set; under the constraints of the authentication factor category coverage relationships, preferentially selecting authentication factors from the non-dominated authentication factor set that can simultaneously cover multiple authentication factor attribute categories; when a single authentication factor cannot cover multiple attribute categories, selecting authentication factors from different attribute categories respectively to form the authentication factor combination.

[0013] According to one achievable method in this application embodiment, controlling access permissions to the hospital information system based on the authentication result includes: generating permission usage constraint information corresponding to the access request based on the attribute category of each authentication factor in the authentication factor combination; if authentication is successful, granting the user the functional permissions and data access scope corresponding to the access request according to the permission usage constraint information; if authentication is not fully successful but some authentication factor verifications are met, providing the user with restricted access permissions, and performing full-process auditing and recording of the operation behavior corresponding to the restricted access permissions.

[0014] According to the second aspect, a hospital information system access control system based on multi-factor authentication is provided. The system includes: an access request acquisition unit configured to acquire user access requests to the hospital information system and determine the medical data type corresponding to the access request; a candidate factor set construction unit configured to construct a multi-factor authentication candidate factor set, the multi-factor authentication candidate factor set including multiple authentication factors, the attribute types of the authentication factors including at least identity credential factors, behavioral characteristic factors, and environmental state factors; an authentication factor attribute acquisition unit configured to acquire the privacy intrusion attribute and security contribution attribute of each authentication factor; and a non-dominated authentication factor set generation unit. The authentication factor generation unit is configured to construct a partial order relationship between the authentication factors under the premise that there is a conflict constraint between the privacy intrusion attribute and the security contribution attribute, and to eliminate authentication factors that are simultaneously dominated by other authentication factors in both the privacy intrusion attribute and the security contribution attribute, so as to generate a set of non-dominated authentication factors; the authentication factor combination generation unit is configured to select authentication factors from different attribute types from the set of non-dominated authentication factors, and to construct an authentication factor combination that meets the multi-factor requirements according to the medical data type; the authentication result generation unit is configured to authenticate the access request based on the authentication factor combination, and to control access permissions to the hospital information system according to the authentication result.

[0015] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0016] According to a fourth aspect, an electronic device is provided, comprising: one or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any one of the first aspects.

[0017] According to the specific embodiments provided in this application, the following technical effects are disclosed:

[0018] This application achieves synergistic optimization between security and privacy protection by introducing a multi-factor authentication mechanism that simultaneously characterizes privacy intrusion and security contribution attributes into access control of hospital information systems. Instead of simply stacking authentication factors, this method performs a structured comparison and screening of different authentication factors based on multi-attribute partial order relationships. It automatically eliminates authentication factors that are inferior in both privacy and security dimensions, retains representative non-dominant authentication factors, and combines them from different attribute categories to form an authentication scheme that meets multi-factor requirements. This allows for the dynamic construction of authentication factor combinations that balance security enhancement and minimal privacy intrusion based on the type of medical data and access risks, avoiding privacy leaks and system burdens caused by over-authentication, and improving the refinement, rationality, and adaptability of access control in hospital information systems.

[0019] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a system architecture diagram applicable to the embodiments of this application;

[0022] Figure 2 A flowchart illustrating a hospital information system access control method based on multi-factor authentication provided in this application embodiment;

[0023] Figure 3 A structural block diagram of a hospital information system access control system based on multi-factor authentication provided in this application embodiment;

[0024] Figure 4 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0026] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0027] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0028] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0029] To facilitate understanding of this application, the system architecture on which this application is based will be described first. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: user equipment and a multi-factor authentication-based hospital information system access control system located on the server side.

[0030] Users can input access requests through their user devices, which then send these requests to the server-side multi-factor authentication-based hospital information system access control system. The multi-factor authentication-based hospital information system access control system can employ the method provided in the embodiments of this application to perform access control on access requests.

[0031] User devices can include, but are not limited to, smart mobile terminals, smart home devices, wearable devices, and PCs (Personal Computers). Smart mobile devices can include mobile phones, tablets, laptops, PDAs (Personal Digital Assistants), and connected cars. Smart home devices can include smart TVs, smart refrigerators, and so on. Wearable devices can include smartwatches, smart glasses, virtual reality devices, augmented reality devices, and mixed reality devices (i.e., devices that support both virtual and augmented reality).

[0032] A hospital information system access control system based on multi-factor authentication can be configured as a standalone server, a server cluster, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product within the cloud computing service ecosystem, designed to address the management difficulties and weak service scalability inherent in traditional physical hosts and Virtual Private Servers (VPS) services. Besides... Figure 1 In addition to the architecture shown, the hospital information system access control system based on multi-factor authentication can also be set up on a computer terminal with strong computing power.

[0033] It should be understood that Figure 1 The user devices and multi-factor authentication-based hospital information system access control system shown are merely illustrative. Depending on implementation needs, any number of user devices and multi-factor authentication-based hospital information system access control systems can be implemented.

[0034] Figure 2 A flowchart illustrating a hospital information system access control method based on multi-factor authentication provided in this application embodiment. Figure 2 As shown, the method may include the following steps:

[0035] Step 201: Obtain the user's access request for the hospital information system and determine the medical data type corresponding to the access request.

[0036] Step 202: Construct a multi-factor authentication candidate factor set, which includes multiple authentication factors, and the authentication factors include at least two of the following: identity credential factors, behavioral characteristic factors, and environmental state factors.

[0037] Step 203: Obtain the privacy intrusion attribute and security contribution attribute of each authentication factor.

[0038] Step 204: Under the premise that there is a conflict constraint between the privacy intrusion attribute and the security contribution attribute, construct a partial order relationship between the authentication factors and eliminate authentication factors that are simultaneously dominated by other authentication factors in both the privacy intrusion attribute and the security contribution attribute, so as to generate a set of non-dominated authentication factors.

[0039] Step 205: Select authentication factors from different attribute categories from the set of non-dominated authentication factors to form a combination of authentication factors that meets the requirements of multiple factors.

[0040] Step 206: Authenticate the access request based on the authentication factor combination, and control access permissions to the hospital information system according to the authentication result.

[0041] As can be seen from the above process, this application achieves synergistic optimization between security and privacy protection by introducing a multi-factor authentication mechanism that simultaneously characterizes privacy intrusion attributes and security contribution attributes into the access control of hospital information systems. This method no longer simply superimposes authentication factors, but rather performs a structured comparison and screening of different authentication factors based on multi-attribute partial order relationships. It automatically eliminates authentication factors that are inferior in both privacy and security dimensions, retains representative non-dominant authentication factors, and combines them from different attribute categories to form an authentication scheme that meets the multi-factor requirements. Therefore, it can dynamically construct a combination of authentication factors that balances security enhancement and minimal privacy intrusion based on the type of medical data and access risks, avoiding privacy leaks and system burdens caused by over-authentication, and improving the refinement, rationality, and adaptability of access control in hospital information systems.

[0042] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. First, step 201, namely "obtaining the user's access request for the hospital information system and determining the medical data type corresponding to the access request", will be described in detail with reference to the embodiments.

[0043] By acquiring user access requests to the hospital information system, the initiator of the access behavior and its access intent can be identified, thereby transforming an abstract system operation into an access event with specific semantics, providing a foundation for refined access control.

[0044] During the process of obtaining an access request, the hospital information system receives access instructions from user terminals or business systems. These access requests typically include at least user identification information, access operation type, and target resource identifier. The user identification information distinguishes the accessing entity, the access operation type represents different operation methods such as reading, modifying, or managing, and the target resource identifier points to a specific medical information resource. By parsing the access request, the user's attempted access behavior can be fully reconstructed.

[0045] Based on this, the type of medical data corresponding to the access request is further determined. Hospital information systems typically store various types of medical data, which differ significantly in terms of sensitivity, privacy risks, and security protection requirements. For example, access control policies should not be the same for basic registration information, medical records, imaging data, test results, and personal identification information. By matching the target resource with predefined data classification rules or data mapping relationships, the system can determine the type of medical data involved in the current access request.

[0046] As one feasible approach, determining the medical data type corresponding to the access request includes: jointly parsing the target resource identifier, request operation type, and user role information in the access request; mapping the access request to at least one medical data semantic category based on a pre-built medical data semantic mapping relationship; and determining the medical data type corresponding to the access request according to the medical data semantic category, wherein the medical data type is used to characterize the privacy association features of the medical data involved in the access request in the clinical business process.

[0047] In the specific implementation process, the target resource identifier, request operation type, and user role information in the access request are first jointly parsed. The target resource identifier points to a specific data object or business module in the hospital information system; the request operation type distinguishes different access behaviors such as reading, writing, modifying, or managing; and the user role information reflects the responsibilities and authority boundaries of the accessing entity within the medical business system. Through comprehensive analysis of these three types of information, the usage scenarios of the access request in actual clinical business processes can be reconstructed at the technical level.

[0048] After joint parsing, based on a pre-built medical data semantic mapping relationship, access requests are mapped to at least one medical data semantic category. This medical data semantic mapping relationship is used to establish a correspondence between system resource identifiers and clinical business semantics, enabling technical access requests to be associated with data categories with clear business meanings, such as data related to diagnosis and treatment, patient identity, or medical decision support data. Through this mapping process, discrete system requests can be transformed into data access events with business semantics.

[0049] Subsequently, based on the determined semantic category of medical data, the data type corresponding to the access request is further determined. This data type characterizes the privacy-related features of the medical data involved in the access request within the clinical workflow. Different types of medical data differ in terms of patient privacy sensitivity, legal compliance requirements, and security protection levels. By clearly defining the data type, the system can distinguish data access behaviors with different privacy risk levels during the access control phase.

[0050] By implementing the aforementioned technical features, hospital information systems can not only identify the access object itself when receiving an access request, but also understand its privacy semantic attributes in the medical business process. This provides a refined and interpretable decision-making basis for subsequent screening of multi-factor authentication factors, construction of partial order relationships, and access control.

[0051] The following describes in detail step 202, namely "constructing a multi-factor authentication candidate factor set, wherein the multi-factor authentication candidate factor set includes multiple authentication factors, and the attribute types of the authentication factors include at least identity credential factors, behavioral feature factors, and environmental state factors", with reference to the embodiments.

[0052] By constructing a set of multi-factor authentication candidate factors, the system has sufficient selection space during the authentication phase to adapt to access requests from different access scenarios, different types of medical data, and different risk levels.

[0053] In its implementation, the multi-factor authentication candidate factor set includes multiple authentication factors, each corresponding to a technical means that can be used to verify the legitimacy of the access subject. These authentication factors are not randomly selected, but rather derived from identity verification, behavioral analysis, and environmental awareness technology modules already deployed or available within the hospital information system, thus ensuring the feasibility and system compatibility of the candidate factor set.

[0054] The attribute types of authentication factors must include at least identity credential factors. Identity credential factors directly represent the user's identity itself, typically possessing relatively stable characteristics, and are primarily obtained through user-provided information or pre-configured by the system. Identity credential factors enable basic verification of the legitimacy of the access subject, providing the first layer of security for subsequent access control.

[0055] The authentication factors also include behavioral characteristic factors. Behavioral characteristic factors characterize users' operational habits and interaction patterns when using the hospital information system. Their generation relies on continuous analysis of users' historical access behavior and current operational behavior. Compared to identity credential factors, behavioral characteristic factors are dynamic and difficult to replicate, helping to identify risk scenarios such as credential theft or abnormal operations.

[0056] In addition, authentication factors also include environmental state factors. Environmental state factors reflect the external objective conditions at the time of the access request, such as the terminal device status, network environment characteristics, or access location-related status. By introducing environmental state factors, a judgment on the rationality of the access scenario can be introduced in addition to identity and behavior, thereby further improving the credibility of the authentication results.

[0057] By constructing a multi-factor authentication candidate factor set using authentication factors of at least three attribute types, the subsequent authentication process no longer relies on single-dimensional information but possesses the ability to comprehensively verify access requests from multiple perspectives, including identity, behavior, and environment. This structured candidate factor set provides a clear and stable input foundation for subsequent evaluations based on privacy intrusion attributes and security contribution attributes, the construction of partial order relationships, and the selection of authentication factor combinations.

[0058] The following describes step 203, namely "obtaining the privacy intrusion attributes and security contribution attributes of each authentication factor", in detail with reference to the embodiments.

[0059] By obtaining the privacy intrusion attributes and security contribution attributes of each authentication factor separately, we can avoid selecting authentication factors based solely on experience or fixed rules, thus making the authentication process assessable and explainable.

[0060] In practical implementation, the privacy intrusion attribute is used to characterize the potential impact of authentication factors on users' personal information during use. This attribute reflects the scope, sensitivity, and reuse of personal information involved in the collection, processing, and storage of authentication factors. The acquisition of the privacy intrusion attribute can be comprehensively determined based on factors such as the type of information required by the authentication factor, whether biometric information is involved, and whether continuous collection of user behavior data is required, thereby reflecting the differences in the impact of different authentication factors on user privacy.

[0061] Corresponding to the privacy intrusion attribute, the security contribution attribute characterizes the security effectiveness of authentication factors in preventing unauthorized access, identifying anomalous behavior, and improving overall authentication reliability. This attribute reflects the authentication factor's ability to resist attacks and distinguish legitimate users during the actual authentication process. The security contribution attribute can be obtained by combining historical authentication results, anomaly interception data, and the effectiveness of the authentication factor in different access scenarios, thus demonstrating the actual security value of the authentication factor.

[0062] When acquiring privacy intrusion and security contribution attributes, each authentication factor is analyzed independently, allowing for comparison of different types of authentication factors within a unified evaluation framework. This separate acquisition approach avoids conflating privacy impact with security effectiveness, ensuring that subsequent decision-making clearly distinguishes the advantages and limitations of authentication factors across different evaluation dimensions.

[0063] As an feasible approach, obtaining the privacy intrusion attributes and security contribution attributes of each authentication factor includes: obtaining the personal information exposure methods, information reuse times, and whether new personal information needs to be collected for each authentication factor in historical authentication processes; constructing the privacy intrusion attributes of the authentication factor based on the personal information exposure methods, information reuse times, and new collection status; obtaining the success rate, abnormal interception status, and replacement status of the authentication factor in historical authentication processes; and constructing the security contribution attributes of the authentication factor based on the success rate, abnormal interception status, and replacement status.

[0064] Specifically, in constructing the privacy intrusion attribute, the personal information exposure methods corresponding to the authentication factors in historical authentication processes are first obtained. The personal information exposure methods describe the presentation form and processing path of personal information involved in authentication, such as whether plaintext input is required, whether data is collected on the device side, and whether it is centrally processed on the server side. Different exposure methods correspond to different levels of privacy risk, and this information provides the basis for subsequent determination of the degree of privacy intrusion.

[0065] Simultaneously, the number of times the authentication factor was reused in historical authentication processes is obtained to reflect the repeated use of the same personal information in multiple authentication processes. A higher number of information reuses means that the personal information is accessed multiple times or stored long-term in the system, increasing the potential risks of leakage and misuse. Therefore, incorporating the number of information reuses into the construction of privacy intrusion attributes helps to comprehensively reflect the privacy impact of authentication factors in long-term operation.

[0066] Furthermore, it is necessary to determine whether the authentication factor requires the collection of new personal information during the authentication process. The collection of new personal information typically signifies a further expansion of user privacy boundaries, and its level of privacy intrusion is higher compared to using only existing information. By identifying new collection scenarios, it is possible to distinguish between authentication factors with less impact on privacy and those with higher privacy requirements.

[0067] Determining whether an authentication factor needs to collect new personal information during the authentication process hinges on distinguishing between two different authentication implementation modes: reusing existing information and triggering new information collection. Specifically, firstly, the existing storage status of user-side personal information is considered. Authentication systems typically maintain personal information profiles for users to support subsequent authentication operations. When an authentication factor only calls upon existing personal information data from that user profile during the current authentication process, without introducing new data collection procedures, it can be determined that the authentication factor does not need to collect new personal information. For example, verification based on already bound account passwords, existing device fingerprint features, or historical behavior models all fall under the category of reusing existing personal information. Secondly, the authentication process itself is considered whether it triggers information collection actions. If the system needs to initiate a new information acquisition process during authentication, including but not limited to guiding the user to input new identity information, collecting new biometric data, or obtaining previously unstored device or environmental data, then it can be determined that the authentication factor needs to collect new personal information. Such collection actions typically manifest as new data request interfaces, sensor calls, or user interaction steps.

[0068] Furthermore, the determination can be made by observing changes in the data fields corresponding to the authentication factors. Specifically, the personal information fields used in the current authentication process are compared with the information fields already stored in the user's historical authentication records. If the currently used information field is completely included in the set of historically stored fields, it is determined that no new data has been collected; if a new field appears that does not exist in the historical records, it is determined that new personal information has been collected. This method is highly feasible and suitable for automatic determination at the system level.

[0069] Furthermore, the determination can be made by combining the configuration attributes or policy identifiers of the authentication factors. In the system design, different authentication factors can be pre-configured to be either "static factors" or "dynamic collection factors." Static factors complete information collection during the registration or initial binding phase, and only information matching is performed during subsequent authentication processes; dynamic collection factors, on the other hand, require re-acquiring personal information each time or under specific conditions. By reading this configuration identifier, it is possible to quickly determine whether the current authentication process involves the collection of new personal information.

[0070] Finally, in the comprehensive judgment process, the above-mentioned multiple judgment methods can be used in combination to improve the accuracy and stability of the judgment results. For example, the system can simultaneously detect whether the data collection interface is triggered, whether new data fields are added, and the authentication factor type configuration. When any condition meets the new data collection feature, it is determined that the authentication factor needs to collect new personal information in this authentication process.

[0071] Based on the aforementioned methods of personal information exposure, frequency of information reuse, and new data collection, a privacy intrusion attribute for authentication factors is comprehensively constructed. This attribute reflects the overall impact of authentication factors on user privacy throughout the authentication lifecycle. This privacy intrusion attribute provides a quantitative or semi-quantitative basis for subsequent comparisons and selection among authentication factors.

[0072] In the specific construction of privacy intrusion attributes, the first step is to classify or label the methods of personal information exposure. The system can categorize personal information processing methods during authentication into different levels, such as local processing, temporary transmission processing, or centralized storage processing, and assign corresponding privacy impact weights to each level. These privacy impact weights reflect the potential impact of the exposure method on user privacy and security, thus providing a basis for subsequent comprehensive calculations. Subsequently, the number of times information is reused is statistically analyzed and normalized. By analyzing historical authentication logs, the system counts the number of times personal information related to the same authentication factor is reused within a predetermined time window and maps this number to a standardized numerical range. Normalization eliminates the dimensional differences in the frequency of use of different authentication factors, making them comparable in privacy intrusion assessments.

[0073] Regarding the factor of whether or not new personal information needs to be collected, the system can use a binary or multi-level labeling method for modeling. For example, situations where no new information needs to be collected can be labeled as low privacy intrusion, while situations where new information needs to be collected can be labeled as high privacy intrusion, or the levels can be further subdivided according to the sensitivity of the new information. This labeling result serves as an important input for privacy intrusion assessment.

[0074] After processing the above indicators, the system comprehensively calculates the methods of personal information exposure, the number of times information is reused, and the status of new data collection based on preset weighting rules or aggregation models, thereby generating a unified privacy intrusion attribute value or privacy intrusion level. This attribute value is used to characterize the relative impact of the authentication factor on user privacy during the overall authentication process.

[0075] In the specific construction of security contribution attributes, the first step is to conduct statistical analysis of successful authentication. The system statistically analyzes the number of successful authentication attempts and the total number of authentication attempts for each authentication factor in historical authentication processes, and calculates the success rate accordingly. The success rate reflects the stability of the authentication factor in ensuring the continuity of legitimate access and is one of the basic indicators for security contribution evaluation.

[0076] Next, the anomaly interception situation is analyzed. The system counts the number of times authentication factors successfully identified and blocked abnormal access behavior during historical authentication processes, and weights these counts based on the type and severity of the abnormal events. This analysis allows for the measurement of the actual effectiveness of authentication factors in preventing unauthorized access and attacks.

[0077] Simultaneously, the system tracks instances where authentication factors are substituted. It identifies the frequency with which a particular authentication factor is replaced by another during the authentication process and incorporates this frequency as a negative indicator into the security contribution assessment. Authentication factors with higher substitution frequencies have relatively weaker independent security capabilities and thus receive lower weight in the security contribution assessment.

[0078] After processing successful passes, abnormal interceptions, and cases where alternative methods are used, the system also performs integrated calculations on various security-related indicators based on preset weighted rules or comprehensive evaluation models to form the security contribution attribute value or security contribution level of the authentication factor. This security contribution attribute reflects the relative contribution of the authentication factor to the overall security of the system in actual operation.

[0079] By acquiring the privacy intrusion attributes and security contribution attributes of each authentication factor, the system can establish a trade-off between privacy protection and security enhancement. This lays the foundation for constructing partial order relationships between authentication factors, identifying non-dominant authentication factors, and generating multi-factor authentication factor combinations, thereby minimizing the intrusion on user privacy while meeting security requirements.

[0080] The following describes in detail step 204, namely, "under the premise that there is a conflict constraint between the privacy intrusion attribute and the security contribution attribute, construct a partial order relationship between the authentication factors and eliminate authentication factors that are simultaneously dominated by other authentication factors in the privacy intrusion attribute and the security contribution attribute, so as to generate a set of non-dominated authentication factors," with reference to the embodiments.

[0081] In this invention, authentication factors are screened and ranked under the premise of conflicting constraints between privacy intrusion attributes and security contribution attributes. This aims to reduce the degree of intrusion into user privacy while ensuring authentication security. Since different authentication factors often cannot simultaneously achieve optimal performance in both privacy intrusion and security contribution attributes, it is necessary to construct a reasonable comparison relationship to organize and effectively screen the authentication factors.

[0082] Conflict constraints refer to the inverse relationship between privacy-intrusive attributes and security-contribution attributes. Typically, authentication factors with higher security-contribution attributes often require the collection or use of more personal information, leading to higher privacy intrusion, while authentication factors with lower privacy intrusion may have relatively limited security contributions. Under this conflict constraint, it is difficult to rank authentication factors using a single evaluation index; therefore, this invention uses a partial order relationship to model the authentication factors.

[0083] When constructing the partial order relationship, the values ​​of each authentication factor in the privacy intrusion attribute and security contribution attribute are used as its attribute features to characterize the comprehensive performance of the authentication factor in both privacy protection and security assurance dimensions. By comparing the attribute features of any two authentication factors, it is determined whether there is a dominance relationship between them in the two attribute dimensions, thereby forming a partially comparable and partially incomparable relationship structure between the authentication factors.

[0084] Specifically, when one authentication factor is no higher than another in terms of privacy intrusion and no lower than another in terms of security contribution, it indicates that the former is not inferior to the latter in both privacy protection and security performance, and has a greater advantage from the perspective of system optimization. In this case, the former is considered to dominate the latter in the aforementioned partial order relationship, and the latter is an authentication factor that is suppressed in terms of overall performance.

[0085] When any two authentication factors do not satisfy the aforementioned dominance relationship, they are determined to be incomparable. Specifically, when comparing any two authentication factors, if they do not meet the criteria for determining the dominance relationship—that is, there is no situation where one authentication factor is not higher than the other in terms of privacy intrusion and not lower than the other in terms of security contribution—it indicates that the two authentication factors each have different advantages in the two dimensions of privacy protection and security enhancement. In this case, one may perform better in terms of privacy intrusion, while the other may have a greater advantage in terms of security contribution. A clear overall order of superiority cannot be formed between them, therefore, the two authentication factors are determined to be incomparable.

[0086] Based on the dominance relationships and the incomparable states, a partial order structure is formed to describe the relative constraints between the authentication factors and privacy protection and security enhancement. Specifically, each authentication factor in the multi-factor authentication candidate factor set is first treated as an independent relation node. Based on the aforementioned dominance relationships and incomparable states, the relationships between the authentication factors are organized as a whole to form the partial order structure. This partial order structure imposes partial order constraints on the authentication factors through dominance associations, rather than forcibly ranking all authentication factors, allowing different authentication factors to maintain diverse trade-offs between privacy protection and security enhancement. This partial order structure provides a structured foundation for the subsequent identification of the non-dominated authentication factor set.

[0087] After constructing the partial order structure, this invention further filters the set of multi-factor authentication candidate factors based on the partial order structure to generate a set of non-dominated authentication factors for subsequent authentication strategy construction. This process aims to eliminate authentication factors that are inferior in both privacy protection and security enhancement dimensions, thereby avoiding the inclusion of authentication factors that do not possess comprehensive advantages in the final authentication combination.

[0088] Specifically, based on the partial order structure, a traversal analysis is performed on each authentication factor in the multi-factor authentication candidate factor set. For any authentication factor, it is determined whether there exists at least one other authentication factor that forms a dominant relationship with it in the partial order structure. The dominant relationship indicates that the authentication factor is not superior to other authentication factors in terms of privacy intrusion attributes, nor is it superior to other authentication factors in terms of security contribution attributes, thus being in a passive position in both privacy protection and system security aspects.

[0089] When it is confirmed that a certain authentication factor is simultaneously dominated by at least one other authentication factor in terms of both privacy intrusion and security contribution attributes, it is determined that the authentication factor does not need to be included in the final selection range of authentication factors. Accordingly, the authentication factor is removed from the multi-factor authentication candidate factor set to avoid introducing authentication factors with high privacy intrusion and insufficient security contribution in subsequent authentication processes.

[0090] Authentication factors that are not dominated by other authentication factors, and authentication factors that, while different, are not comparable to other authentication factors, will be retained. These authentication factors must have a relative advantage in at least one dimension between privacy-intrusive attributes and security-contributing attributes, or be able to provide alternative options in different privacy and security trade-off scenarios.

[0091] Through the aforementioned elimination and retention process, the set of non-dominated authentication factors is formed. None of the authentication factors in this set are simultaneously inferior to other authentication factors in terms of both privacy intrusion and security contribution attributes. This provides a foundation of candidate factors with a reasonable trade-off between privacy protection and security enhancement for the subsequent construction of multi-factor authentication factor combinations.

[0092] The following describes in detail step 205, namely, "selecting authentication factors from different attribute types from the set of non-dominant authentication factors and constructing a combination of authentication factors that meets the requirements of multiple factors according to the medical data type," with reference to the embodiments.

[0093] After obtaining the set of non-dominated authentication factors, the present invention further filters and combines the set of non-dominated authentication factors based on the attribute types of the authentication factors to form a combination of authentication factors that meets the requirements of multi-factor authentication. This step is used to ensure that the factors ultimately participating in the authentication are diverse in terms of source and attributes, thereby avoiding the problem of concentrated security risks caused by a single type of authentication factor.

[0094] Attribute types are used to characterize the source features and verification methods of authentication factors. Authentication factors with different attribute types differ in their security mechanisms and privacy impacts. For example, identity credential factors focus on verifying the user's identity itself, behavioral characteristic factors focus on verifying the user's usage habits or operational behaviors, and environmental state factors focus on verifying the access environment and context. By distinguishing the attribute types of authentication factors, complementary security mechanisms can be introduced into the authentication process.

[0095] When selecting authentication factors, the selection scope is first limited to the set of non-dominated authentication factors to ensure that the selected authentication factors have a reasonable trade-off between privacy intrusion attributes and security contribution attributes. Based on this, authentication factors belonging to different attribute types are selected from the set of non-dominated authentication factors, ensuring that the resulting combination of authentication factors covers at least two different attribute types, thereby meeting the basic requirements of multi-factor authentication.

[0096] By selecting authentication factors from different attribute types, the resulting combination of authentication factors can work synergistically in areas such as identity verification, behavior consistency checks, and access environment legitimacy assessment. On the one hand, this avoids the authentication vulnerability caused by relying on a single verification mechanism; on the other hand, while ensuring system security, it reduces unnecessary privacy intrusions caused by the reuse of authentication factors.

[0097] As an implementable approach, selecting authentication factors from different attribute types from the set of non-dominated authentication factors to form an authentication factor combination that satisfies multi-factor requirements includes: determining authentication attribute coverage requirements matching the access request based on the medical data type, wherein the authentication attribute coverage requirements are used to limit the minimum number of attribute types that the authentication factor combination needs to cover; constructing authentication factor category coverage relationships based on the attribute types of each authentication factor in the set of non-dominated authentication factors; under the constraints of the authentication factor category coverage relationships, preferentially selecting authentication factors from the set of non-dominated authentication factors that can simultaneously cover multiple authentication factor attribute categories; when a single authentication factor cannot cover multiple attribute categories, selecting authentication factors from different attribute categories respectively to form the authentication factor combination.

[0098] Specifically, different types of medical data exhibit varying privacy-related characteristics in clinical workflows. For instance, some medical data is primarily used for administrative management or process support, while others directly involve patient diagnosis and treatment information or sensitive personal information. Based on these medical data types, the comprehensive requirements for privacy protection and security control in this access request can be determined, and these comprehensive requirements can be transformed into constraints on the coverage of authentication attribute types. The authentication factor category coverage relationship is constructed based on the attribute types of each authentication factor in the non-dominated authentication factor set, and is used to describe the correspondence between a single authentication factor and one or more attribute types. In practical applications, some authentication factors may simultaneously possess multiple attribute characteristics, such as reflecting user behavior characteristics while verifying identity. By constructing the authentication factor category coverage relationship, the coverage capability of each authentication factor in the attribute type dimension can be clarified, providing a basis for subsequent combination selection. When constructing the authentication factor combination, under the constraint of the authentication factor category coverage relationship, authentication factors that can simultaneously cover multiple authentication factor attribute types are preferentially selected from the non-dominated authentication factor set.

[0099] Prioritization can be based on a fixed numerical threshold or on a relative comparison of the attribute type coverage capabilities of authentication factors. This ensures that the combination of authentication factors meets multi-factor requirements while balancing efficiency and privacy protection in the authentication process. Specifically, for each authentication factor in the non-dominant authentication factor set, the range of attribute types it can cover is determined, and the authentication factors are compared and analyzed based on this coverage range. Under the premise of meeting the multi-factor authentication requirements corresponding to the current access request, authentication factors that can cover more attribute types are prioritized. In this way, a single authentication factor can undertake multiple verification functions during the authentication process, thereby reducing the number of authentication factors required. In the prioritization process, the comparison relationship between the authentication factors is relative, not absolute. That is, it does not require the attribute coverage capability of the authentication factors to reach a preset numerical standard, but rather determines their priority order in the current authentication scenario by horizontally comparing the attribute type coverage of different authentication factors.

[0100] By prioritizing authentication factors with multi-attribute coverage capabilities, the number of factors involved in authentication can be reduced while ensuring multi-factor authentication requirements are met, thereby reducing the user's operational burden and potential privacy intrusion during the authentication process.

[0101] When the set of non-dominant authentication factors does not contain any authentication factors that can individually cover multiple attribute types, or when the coverage is insufficient to meet the multi-factor authentication requirements of the current access request, authentication factors are selected separately from different attribute types. By selecting authentication factors separately from different attribute types, the resulting combination of authentication factors achieves complementary coverage in the attribute type dimension, thereby ensuring the security and robustness requirements of the authentication mechanism. Specifically, the system ensures that the final combination contains factors from at least two or more different categories, such as selecting an identity credential factor combined with a behavioral feature factor, or adding an environmental state factor, thus strictly meeting the basic requirements of multi-factor authentication. This step-by-step selection method ensures the diversity and security of the authentication combination, avoiding potential security vulnerabilities caused by all factors being concentrated in the same attribute category.

[0102] The following describes in detail step 206, namely "authenticating the access request based on the authentication factor combination and controlling access permissions to the hospital information system according to the authentication result", with reference to the embodiments.

[0103] The system first authenticates the user's access request based on a predetermined combination of authentication factors. Specifically, the user needs to verify each authentication factor in the combination sequentially or in parallel, such as providing identity credentials, accepting behavioral feature collection, and confirming whether the environmental status meets the requirements. Only when all selected authentication factors are verified successfully is the system considered the authentication to be fully successful. This rigorous execution method ensures the security strength of multi-factor authentication, effectively resisting the risk of a single factor being compromised, and is particularly suitable for hospital information systems involving patient privacy and sensitive medical data.

[0104] Regarding authentication result processing, the system does not employ a simple all-or-nothing strategy, but rather implements refined access control based on the actual authentication situation. When authentication is fully successful, the system grants the user the complete scope of permissions, including the corresponding functional operations and data access permissions, according to the original requirements of the access request. This approach ensures a smooth user experience for legitimate users under normal circumstances and avoids unnecessary operational obstacles.

[0105] Of particular note is the system's provision of restricted access when authentication fails completely, but the user successfully verifies some authentication factors. This restricted access design fully considers the unique characteristics of hospital scenarios. For example, during emergency rescues, medical staff may be unable to complete all authentication factors due to time constraints or equipment limitations. In such cases, the system allows the user to access a limited set of functional interfaces or view some non-core sensitive data, while simultaneously performing a full-process audit log of all restricted operations. This partial access mechanism reduces the clinical risks that complete access denial might pose, while ensuring compliance and traceability through rigorous audit logs, providing complete evidence for subsequent security reviews.

[0106] Furthermore, when granting permissions, the system also considers the attribute categories of each factor in the authentication factor combination to generate corresponding permission usage constraints. These constraints may include time limits, operational scope restrictions, or data anonymization requirements, further enhancing the granularity of access control. This dynamic constraint mechanism based on factor attributes makes permission allocation more precise, avoiding problems of over-authorization or under-authorization.

[0107] As an implementable approach, controlling access permissions to the hospital information system based on authentication results includes: generating permission usage constraint information corresponding to the access request based on the attribute categories of each authentication factor in the authentication factor combination; granting the user functional permissions and data access scope corresponding to the access request according to the permission usage constraint information when authentication is successful; and providing the user with restricted access permissions when authentication is not fully successful but some authentication factor verifications are met, and performing full-process auditing and recording of the operation behavior corresponding to the restricted access permissions.

[0108] First, the system generates permission constraints corresponding to the current access request based on the attribute categories of each factor in the authentication factor combination. These attribute categories include identity credentials, behavioral characteristics, and environmental status. Passing authentication for different categories of factors signifies that the user has gained trust on different dimensions, allowing the system to derive more refined constraint rules. For example, when an environmental status factor in the combination passes verification, the constraint information might restrict access to the hospital's internal network; when a behavioral characteristic factor passes, time restrictions for certain operations can be relaxed. This constraint generation method based on factor attribute categories makes permission allocation more precise and intelligent, avoiding the rigidity of traditional fixed permission policies.

[0109] If authentication is successful, the system will strictly adhere to the generated permission usage constraints, granting the user functional permissions and data access scope matching their access request. This means the user can perform the requested operations normally, such as viewing complete medical records, issuing prescriptions, or modifying treatment plans. Simultaneously, all granted permissions are subject to the constraints, ensuring that even with successful authentication, there is no over-authorization, thus complying with the principle of minimum necessary use of medical data and protecting patient privacy.

[0110] When authentication fails completely, but the user successfully verifies some authentication factors, the system does not simply deny access but grants the user limited access. This design fully considers the urgency and continuity of hospital clinical scenarios. For example, in emergency resuscitation, medical staff may not be able to immediately complete all biometric identification due to wearing gloves or equipment limitations, but they have already verified their identity credentials and environmental status. In this case, the system allows the user to enter emergency mode to view basic patient information or vital sign data, but prohibits modification of treatment plans or access to complete medical records. This limited access mechanism effectively reduces the medical risks that may arise from completely denying access while maintaining a high level of security.

[0111] To further enhance security, the system performs full-process auditing of all operations performed under restricted access permissions. This includes recording the time, content, context, and data scope of each user action, forming a complete and traceable log chain. These audit logs not only facilitate post-incident security reviews and accountability but also serve as a data source for subsequent evaluation of authentication factor security contribution attributes, supporting continuous system optimization. In the event of a security incident, the audit logs also provide crucial evidence to help quickly locate the problem.

[0112] Overall, this application constructs a multi-layered access control system through dynamic constraint generation, precise access upon full approval, restricted access upon partial approval, and full-process auditing. While ensuring high security for the hospital information system, it minimizes interference with the normal work of medical staff, demonstrating the advanced nature of medical information security technology moving towards intelligence and humanization.

[0113] The method provided in this application can be applied to various scenarios, including but not limited to: First, in routine outpatient and ward round scenarios, when doctors use mobile devices to view patient medical records, the system dynamically selects a combination of authentication factors with low privacy intrusion and high security contribution based on the sensitivity of medical data. For example, combining behavioral characteristics and environmental status verification can achieve rapid and seamless authentication, reducing interruptions for medical staff and improving clinical efficiency. Second, in emergency situations such as emergency resuscitation, when medical staff cannot complete all authentication factors, the system allows partial verification to pass, granting restricted access permissions, such as viewing only vital signs and basic information, while simultaneously performing full-process auditing to ensure timely patient treatment while maintaining data security. Finally, in remote medical consultation scenarios, when accessing highly sensitive data across institutions, the system automatically strengthens authentication and generates strict permission constraints, effectively preventing external risks and ensuring patient privacy compliance. This method balances security, privacy protection, and continuity of medical work, and is suitable for deployment in various hospital information systems.

[0114] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0115] According to another embodiment, a hospital information system access control system based on multi-factor authentication is provided. Figure 3 A schematic block diagram of a hospital information system access control system based on multi-factor authentication is shown according to one embodiment. Figure 3 As shown, the system 300 includes:

[0116] The access request acquisition unit 301 is configured to acquire user access requests to the hospital information system and determine the medical data type corresponding to the access request.

[0117] The candidate factor set construction unit 302 is configured to construct a multi-factor authentication candidate factor set, which includes multiple authentication factors. The attribute types of the authentication factors include at least identity credential factors, behavioral feature factors, and environmental state factors.

[0118] The authentication factor attribute acquisition unit 303 is configured to acquire the privacy intrusion attribute and security contribution attribute of each authentication factor respectively.

[0119] The non-dominated authentication factor set generation unit 304 is configured to construct a partial order relationship between the authentication factors under the premise that there is a conflict constraint between the privacy intrusion attribute and the security contribution attribute, and to eliminate authentication factors that are simultaneously dominated by other authentication factors in both the privacy intrusion attribute and the security contribution attribute, so as to generate a non-dominated authentication factor set.

[0120] The authentication factor combination generation unit 305 is configured to select authentication factors from different attribute types from the non-dominant authentication factor set, and to construct an authentication factor combination that meets the multi-factor requirements based on the medical data type.

[0121] The authentication result generation unit 306 is configured to authenticate the access request based on the authentication factor combination and control access permissions to the hospital information system according to the authentication result.

[0122] As an implementable approach, the access request acquisition unit 301 can be configured to: jointly parse the target resource identifier, request operation type, and user role information in the access request; map the access request to at least one medical data semantic category based on a pre-built medical data semantic mapping relationship; and determine the medical data type corresponding to the access request according to the medical data semantic category, wherein the medical data type is used to characterize the privacy association features of the medical data involved in the access request in the clinical business process.

[0123] As an implementable approach, the authentication factor attribute acquisition unit 303 can be configured to: acquire the personal information exposure method and information reuse count of the authentication factor in the historical authentication process, and determine whether it is necessary to collect new personal information; construct the privacy intrusion attribute of the authentication factor based on the personal information exposure method, information reuse count, and the need to collect new personal information; acquire the success rate, abnormal interception rate, and replacement rate of the authentication factor in the historical authentication process; and construct the security contribution attribute of the authentication factor based on the success rate, abnormal interception rate, and replacement rate.

[0124] As an implementable approach, the non-dominant authentication factor set generation unit 304, when constructing the partial order relationship between the authentication factors under the premise that there is a conflict constraint between the privacy intrusion attribute and the security contribution attribute, can be configured as follows: for any two authentication factors, compare their privacy intrusion attribute and security contribution attribute respectively; when one authentication factor is lower than or equal to the other authentication factor in the privacy intrusion attribute and higher than or equal to the other authentication factor in the security contribution attribute, determine that the former dominates the latter in the partial order relationship; when any two authentication factors do not satisfy the dominance relationship, determine that the two are in an incomparable state; based on the dominance relationship and the incomparable state, form a partial order structure for describing the relative constraint relationship between the authentication factors in privacy protection and security enhancement.

[0125] As an implementable approach, the non-dominated authentication factor set generation unit 304 can be configured to: traverse the partial order structure, identify authentication factors that are dominated by at least one other authentication factor in the partial order structure; remove the dominated authentication factors from the multi-factor authentication candidate factor set, and retain authentication factors that are not dominated by other authentication factors and authentication factors that are in an incomparable state, so as to form the non-dominated authentication factor set.

[0126] As an implementable approach, the authentication factor combination generation unit 305, when selecting authentication factors from different attribute types from the non-dominated authentication factor set and constructing an authentication factor combination that satisfies multi-factor requirements based on the medical data type, can be configured to: determine authentication attribute coverage requirements matching the access request based on the medical data type, wherein the authentication attribute coverage requirements are used to limit the minimum number of attribute types that the authentication factor combination needs to cover; construct authentication factor category coverage relationships based on the attribute types of each authentication factor in the non-dominated authentication factor set; under the constraints of the authentication factor category coverage relationships, preferentially select authentication factors from the non-dominated authentication factor set that can simultaneously cover multiple authentication factor attribute categories; when a single authentication factor cannot cover multiple attribute categories, select authentication factors from different attribute categories respectively to form the authentication factor combination.

[0127] As an implementable approach, the authentication result generation unit 306 can be configured to: generate permission usage constraint information corresponding to the access request based on the attribute category of each authentication factor in the authentication factor combination; grant the user the functional permissions and data access scope corresponding to the access request according to the permission usage constraint information when authentication is successful; and provide the user with restricted access permissions when authentication is not fully successful but some authentication factor verifications are met, and perform full-process auditing and recording of the operation behavior corresponding to the restricted access permissions.

[0128] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. Components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0129] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0130] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0131] And an electronic device comprising: one or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0132] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0133] in, Figure 4 An exemplary architecture of an electronic device is shown, which may include a processor 410, a video display adapter 411, a disk drive 412, an input / output interface 413, a network interface 414, and a memory 420. The processor 410, video display adapter 411, disk drive 412, input / output interface 413, network interface 414, and memory 420 can communicate with each other via a communication bus 430.

[0134] The processor 410 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0135] The memory 420 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 420 can store the operating system 421 for controlling the operation of the electronic device 400, and the basic input / output system (BIOS) 422 for controlling the low-level operations of the electronic device 400. Additionally, it can store a web browser 423, a data storage management system 424, and a hospital information system access control system 425 based on multi-factor authentication, etc. The aforementioned hospital information system access control system 425 based on multi-factor authentication can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 420 and executed by the processor 410.

[0136] Input / output interface 413 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0137] Network interface 414 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0138] Bus 430 includes a pathway for transmitting information between various components of the device, such as processor 410, video display adapter 411, disk drive 412, input / output interface 413, network interface 414, and memory 420.

[0139] It should be noted that although the above-described device only shows the processor 410, video display adapter 411, disk drive 412, input / output interface 413, network interface 414, memory 420, bus 430, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0140] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0141] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for access control of a hospital information system based on multi-factor authentication, characterized in that, The method includes: Obtain user access requests to the hospital information system and determine the medical data type corresponding to the access requests; Construct a multi-factor authentication candidate factor set, which includes multiple authentication factors, and the attribute types of the authentication factors include at least identity credential factors, behavioral feature factors, and environmental state factors; Obtain the privacy intrusion attributes and security contribution attributes of each authentication factor separately; For any two authentication factors, compare their privacy intrusion attributes and security contribution attributes respectively; When one authentication factor is lower than or equal to another authentication factor in terms of privacy intrusion attribute, but higher than or equal to another authentication factor in terms of security contribution attribute, the former is determined to dominate the latter in the partial order relation. When any two authentication factors do not satisfy the dominance relationship, they are determined to be incomparable. Based on the dominance relationship and the incomparable state, a partial order structure is formed to describe the relative constraint relationship between the authentication factors in terms of privacy protection and security enhancement; and authentication factors that are simultaneously dominated by other authentication factors in terms of privacy intrusion attribute and security contribution attribute are eliminated to generate a set of non-dominated authentication factors. The process of generating the non-dominated authentication factor set includes: traversing the partial order structure, identifying authentication factors that are dominated by at least one other authentication factor in the partial order structure; removing the dominated authentication factors from the multi-factor authentication candidate factor set, and retaining the authentication factors that are not dominated by other authentication factors and the authentication factors that are in an incomparable state to form the non-dominated authentication factor set. Authentication factors from different attribute types are selected from the set of non-dominant authentication factors, and authentication factor combinations that meet the multi-factor requirements are constructed according to the medical data type. The access request is authenticated based on the authentication factor combination, and access permissions to the hospital information system are controlled according to the authentication result.

2. The method according to claim 1, characterized in that, The determination of the medical data type corresponding to the access request includes: The target resource identifier, request operation type, and user role information in the access request are jointly parsed. Based on a pre-built semantic mapping relationship for medical data, the access request is mapped to at least one semantic category for medical data; Based on the semantic category of the medical data, the data type of the medical data corresponding to the access request is determined, wherein the data type of the medical data is used to characterize the privacy association features of the medical data involved in the access request in the clinical business process.

3. The method according to claim 1, characterized in that, The process of obtaining the privacy intrusion attributes and security contribution attributes of each authentication factor includes: Obtain the personal information exposure methods and information reuse times corresponding to the authentication factors in the historical authentication process, and determine whether it is necessary to collect new personal information; Based on the aforementioned methods of personal information exposure, the number of times information is reused, and the need to collect new personal information, the privacy intrusion attributes of the authentication factor are constructed. The successful authentication, abnormal interception, and replacement of the authentication factor in the historical authentication process are obtained respectively. Based on the successful pass, abnormal interception, and replacement use scenarios, the security contribution attribute of the authentication factor is constructed.

4. The method according to claim 1, characterized in that, The step of selecting authentication factors from different attribute types from the set of non-dominant authentication factors and constructing a combination of authentication factors that meets the multi-factor requirements based on the medical data type includes: Based on the medical data type, an authentication attribute coverage requirement matching the access request is determined. The authentication attribute coverage requirement is used to limit the minimum number of attribute types that the authentication factor combination must cover. Based on the attribute types of each authentication factor in the set of non-dominant authentication factors, a classification coverage relationship for authentication factors is constructed. Under the constraint of the certification factor category coverage relationship, certification factors that can simultaneously cover multiple certification factor attribute categories are preferentially selected from the set of non-dominant certification factors. When a single authentication factor cannot cover multiple attribute categories, authentication factors are selected from different attribute categories to form the authentication factor combination.

5. The method according to claim 1, characterized in that, The control of access permissions to the hospital information system based on authentication results includes: Based on the attribute category of each authentication factor in the authentication factor combination, permission usage constraint information corresponding to the access request is generated; If authentication is successful, the user is granted the functional permissions and data access scope corresponding to the access request in accordance with the permission constraint information. If authentication is not fully passed but some authentication factors are met, the user is granted limited access rights, and the operation behavior corresponding to the limited access rights is audited and recorded throughout the entire process.

6. A hospital information system access control system based on multi-factor authentication, characterized in that, The system includes: The access request acquisition unit is configured to acquire user access requests to the hospital information system and determine the medical data type corresponding to the access request; The candidate factor set construction unit is configured to construct a multi-factor authentication candidate factor set, which includes multiple authentication factors. The attribute types of the authentication factors include at least identity credential factors, behavioral feature factors, and environmental state factors. The authentication factor attribute acquisition unit is configured to acquire the privacy intrusion attribute and security contribution attribute of each authentication factor respectively; A non-dominated authentication factor set generation unit is configured to compare the privacy intrusion attribute and security contribution attribute of any two authentication factors. When one authentication factor is lower or equal to the other authentication factor in the privacy intrusion attribute and higher or equal to the other authentication factor in the security contribution attribute, it is determined that the former dominates the latter in the partial order relation. When any two authentication factors do not satisfy the dominance relation, they are determined to be in an incomparable state. Based on the dominance relation and the incomparable state, a partial order structure is formed to describe the relative constraint relationship between the authentication factors in privacy protection and security enhancement. Authentication factors that are simultaneously dominated by other authentication factors in both the privacy intrusion attribute and the security contribution attribute are eliminated to generate a non-dominated authentication factor set. Generating the non-dominated authentication factor set includes: traversing the partial order structure to identify authentication factors that are dominated by at least one other authentication factor in the partial order structure; removing the dominated authentication factors from the multi-factor authentication candidate factor set, and retaining the authentication factors that are not dominated by other authentication factors and the authentication factors in an incomparable state to form the non-dominated authentication factor set. The authentication factor combination generation unit is configured to select authentication factors from different attribute types from the non-dominant authentication factor set, and to construct an authentication factor combination that meets the multi-factor requirements according to the medical data type. The authentication result generation unit is configured to authenticate the access request based on the authentication factor combination and control access permissions to the hospital information system according to the authentication result.

7. An electronic device, characterized in that, include: One or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 5.

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 steps of the method according to any one of claims 1 to 5.

Images