Hospital patient information security management method

Abstract

The invention discloses a hospital patient information security management method, which belongs to the technical field of information security, and comprises the steps of request data generation by an APP, HIS-LB load balancing and security verification, HIS-Gateway request processing and data packet analysis by the APP. The technical problem of safety protection of sensitive medical data in a high-concurrency and cross-domain cooperative environment is solved, the confidentiality and integrity of the data are ensured, the differentiated safety requirements of multiple scenes are met, the internal threat detection capability is greatly improved, cross-hospital data statistical analysis is realized without leaking original data by adopting data desensitization middleware, and the safety of the sensitive medical data is ensured. And data sharing and privacy protection are both considered.

Description

Technical Field

[0001] The present invention belongs to the technical field of information security, and particularly relates to a method for hospital patient information security management. Background Art

[0002] Under the background of the rapid development of medical informatization, the hospital information system (HIS) has become the core platform for patient diagnosis and treatment data management. Among them, the electronic prescription, as a key medical record, involves patient privacy, medication safety, and cross-institutional collaboration requirements. However, traditional prescription query and sharing solutions face severe challenges in terms of security, flexibility, and compliance.

[0003] The deficiencies of traditional technologies are as follows: Lack of dynamic authorization mechanism: In existing solutions, the control of access permissions is usually relatively fixed and it is difficult to dynamically adjust permissions according to specific access scenarios and data attributes.

[0004] Separation of terminal and transmission security protection: Transmission encryption and terminal data encryption do not form a unified full-link protection system, and there is a problem that data is in different security states in each link.

[0005] Insufficient detection of internal threats and anomalies: The detection and response mechanism for internal abnormal behaviors is imperfect, and there is a lack of the ability to achieve real-time anomaly monitoring using intelligent means such as machine learning.

[0006] Insufficient privacy protection for cross-hospital data sharing: In the process of data sharing, direct exchange of original data may lead to the risk of privacy leakage, and data desensitization and secure aggregation technologies are urgently needed. Summary of the Invention

[0007] The purpose of the present invention is to provide a method for hospital patient information security management, which solves the technical problem of realizing the security protection of sensitive medical data in a high-concurrency and cross-domain collaboration environment through multi-layer encryption, dynamic authorization, and intelligent anomaly detection.

[0008] To achieve the above purpose, the present invention adopts the following technical solutions: A method for hospital patient information security management, comprising the following steps: Step 1: After the patient selects prescription query on the APP client, the APP client generates request data including a user identity token, device fingerprint, IP address, and access scenario information, and sends the request data to the HIS-LB load balancing layer of the hospital information system after encrypting it through TLS / HTTPS communication; Step 2: After the HIS-LB load balancing layer performs security verification on the request data, it selects the HIS-Gateway server to distribute the request data; After receiving the request data from the HIS-LB layer, the HIS-Gateway server authenticates the request data using JWT or OAuth2.0 tokens, and determines the access permissions based on the access scenario and prescription attributes through the policy engine; The HIS-Gateway server extracts the prescription data encrypted and stored with AES-256 from the prescription database according to the access permissions, generates a key for a one-time session, encrypts the key through the ECC algorithm to obtain the key E-Ks, and then uses the key E-Ks to encrypt the prescription data for the second time to generate encrypted prescription data, attaches the MAC signature, and packages it into an encrypted data packet; at the same time, the HIS-Gateway server uses a machine learning model to monitor the current request behavior of the request data in real time, and freezes the access permissions if anomalies are detected; Step 3: The prescription database adopts a distributed architecture and uses the read-write separation method and Redis caching technology for data query; an HSM / KMS service is established, and the HSM / KMS service is used to generate the encryption key for the data, and store and manage the key with regular rotation; When cross-hospital data sharing is required, each collaborating hospital uploads encrypted feature data, and the aggregated training global model is used to aggregate the encrypted feature data; a desensitization middleware is established, and after receiving the data extraction request from the HIS-Gateway server, it desensitizes the extracted data and shares the desensitized data with the collaborating hospital; Step 4: After receiving the encrypted data packet sent from the HIS-Gateway server, the APP client verifies the integrity, decrypts the prescription data and displays it.

[0009] Preferably, when executing Step 2, after passing judgments such as device verification, IP verification, traffic analysis, prescription attribute authorization, and scenario dynamic authorization, the HIS-LB load balancing layer routes the request data to an idle HIS-Gateway server.

[0010] Preferably, when executing Step 2, after receiving the request data, the HIS-Gateway server first completes the authorization verification through JWT or OAuth2.0, and then dynamically calculates the permissions according to the prescription attributes and access scenarios using the policy engine.

[0011] Preferably, when executing Step 4, the encrypted data packet contains the key E-Ks, the encrypted prescription data, and the MAC signature. The encrypted data packet is sent by the HIS-Gateway server and transmitted to the patient APP through the TLS / HTTPS communication encryption channel of the HIS-LB layer. The APP first decrypts the key E-Ks using the local private key, and then uses the key E-Ks to decrypt the encrypted prescription data to finally obtain the prescription data.

[0012] Preferably, when performing step 2, the HIS-LB load balancing layer also performs the following security verifications on the access of the APP client: Device fingerprint verification, including detecting whether the requesting device deployed by the APP client is in the whitelist; if it is a non-trusted device, secondary verification is triggered; IP address and geographical location verification, including comparing the IP address with historical data; if an anomaly is found, it is marked as a risk request and the request is rejected or additional verification is required; Traffic and DDoS protection, including monitoring abnormal traffic and throttling or triggering traffic cleaning for frequent access requests; Initial calculation of dynamic authorization, invoking the attribute-scenario dynamic authorization engine, and performing an initial calculation of the permission policy based on the query scenario and prescription attributes provided in the request to generate an initial authorization token.

[0013] Preferably, when performing step 3, data desensitization for the extracted data specifically includes that when the request data involves cross-hospital collaboration, the desensitization middleware filters the PII fields according to preset rules, replaces the real name with an anonymous identifier, and generates a virtual patient ID.

[0014] Preferably, when performing step 2, the access permission is determined by the policy engine based on the access scenario and prescription attributes. Specifically: an attribute-scenario dynamic authorization engine is set in the HIS-LB load balancing layer, and authorization rules are preset; The HIS-LB load balancing layer invokes the attribute-scenario dynamic authorization engine to perform an initial permission calculation based on the access scenario and prescription attributes included in the request data, and generates an initial authorization token. The initial permission calculation specifically is that the HIS-LB load balancing layer calculates the initial permission score using the following formula: ; where is the initial permission score; is the user identity matching score; is the access scenario matching score; is the prescription attribute matching score; is the access environment security score; 、 、 and are all weights adjusted in the authorization rules.

[0015] Set a threshold , if , then the initial authorization is passed, and the HIS-LB layer generates an initial authorization token and forwards the request data to the allocated HIS-Gateway server; otherwise, the request is rejected or the user is required to perform additional verification.

[0016] A method for hospital patient information security management according to the present invention solves the technical problem of realizing the security protection of sensitive medical data in a high-concurrency and cross-domain collaboration environment through multi-layer encryption, dynamic authorization, and intelligent anomaly detection. From request generation, distribution, business processing to data storage, desensitization sharing, and client decryption, the whole process of the present invention adopts multiple encryption and security verification to ensure the confidentiality and integrity of data. By using an attribute-scenario dynamic authorization engine, it realizes the dynamic calculation of permissions according to access scenarios and data attributes to meet the differentiated security requirements of multiple scenarios such as emergency and scientific research. By integrating a machine learning model, it monitors abnormal access behaviors in real time, freezes permissions in a timely manner, and triggers audits, greatly improving the internal threat detection ability. By using a data desensitization middleware, it realizes cross-hospital data statistical analysis without revealing the original data, taking into account both data sharing and privacy protection. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is the main flowchart of the present invention; Figure 2 is the flowchart of step 1 of the present invention; Figure 3 is the flowchart of step 2 of the present invention; Figure 4 is the flowchart of step 3 of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0018] by Figures 1-4 A method for hospital patient information security management shown includes the following steps: Step 1: After the patient selects prescription query on the APP client, the APP client generates request data including a user identity token, device fingerprint, IP address, and access scenario information, and sends the request data to the HIS-LB load balancing layer of the hospital information system after encrypting it through TLS / HTTPS communication. When performing step 1, the specific steps are as follows: Step 1-1: The patient downloads and installs the APP client on the mobile terminal, logs in to the APP client, and selects prescription query; Step 1-2: The APP client generates a user identity token according to the patient's operation. The user identity token includes a JWT token generated based on identity authentication information when the user logs in or registers; The APP client collects the device fingerprint of the local device, including the device unique identifier (such as IMEI, serial number), operating system version, device model, and other hardware parameters (determined according to hospital requirements); The device fingerprint is generated using a hash algorithm. Specifically, the SHA-256 algorithm is used to perform a hash calculation on the collected information to form a device fingerprint data of a fixed length. The formula of the SHA-256 algorithm is as follows: ; Among them, The calculated hash value, is the IMEI of the device, is the operating system version of the device, is other parameters in the device model. In this embodiment, this value is the MAC address of the device; is other information about the device, and this value is determined by the hospital's requirements, such as the CPU serial number, capacity, etc.

[0019] The APP client obtains the currently used IP address through the Internet interface, and at the same time extracts and generates access scenario information through the business scenarios (such as outpatient, emergency, scientific research) selected by the user during the operation process; The APP client integrates the collected data to obtain a JSON - formatted data structure, clearly identifies the uses of each field, and attaches a timestamp, and finally generates the request data.

[0020] Step 1 - 3: The APP client uses the TLS / HTTPS protocol to encrypt the generated request data. As a transport - layer security protocol, TLS / HTTPS will establish a secure channel between the application layer and the transport layer, and automatically complete data encryption, data integrity verification, and identity authentication. The specific encryption process is as follows: When the APP client is ready to send a request, the APP client calls the system network library (such as OpenSSL or the TLS library built into the operating system) for a secure handshake (SSL / TLS handshake). During the handshake process, the APP client and the server deployed in the HIS - LB layer exchange certificates, negotiate encryption algorithms, and session keys, and then use the session key to encrypt the request data.

[0021] Step 1 - 4: The request data encrypted by TLS / HTTPS is sent to the HIS - LB load - balancing layer of the hospital information system through the Internet. The devices and interfaces involved in the transmission are completed by the network module (such as Wi - Fi / 4G / 5G) of the patient's mobile terminal. As the data receiving end, the HIS - LB load - balancing layer is configured with corresponding network interfaces and TLS terminal processing modules, which can parse and decrypt the received encrypted data packets.

[0022] After the data departs from the APP client, it is transmitted through the Internet to the server in the HIS - LB layer of the hospital pharmacy data center, and the entire transmission process is protected by the TLS / HTTPS protocol.

[0023] Step 2: After performing security verification on the request data in the HIS - LB load - balancing layer, select the HIS - Gateway server to distribute the request data; After passing device verification, IP verification, traffic analysis, prescription attribute authorization, and scenario dynamic authorization judgments, the HIS-LB load balancing layer routes the request data to an idle HIS-Gateway server.

[0024] The HIS-LB load balancing layer also performs the following security verifications on the access of the APP client: Device fingerprint verification, including detecting whether the requesting device deployed by the APP client is within the whitelist; if it is a non-trusted device, secondary verification is triggered; IP address and geographical location verification, including comparing the IP address with historical data; if an anomaly is found, it is marked as a risk request and rejected or additional verification is required; Traffic and DDoS protection, including monitoring abnormal traffic and throttling or triggering traffic cleaning for frequent access requests; Initial calculation of dynamic authorization, calling the attribute-scenario dynamic authorization engine to perform an initial calculation of the permission policy based on the query scenario and prescription attributes provided in the request, and generating an initial authorization token.

[0025] After receiving the request data from the HIS-LB layer, the HIS-Gateway server authenticates the request data using a JWT or OAuth2.0 token, and determines the access permission based on the access scenario and prescription attributes through the policy engine; After receiving the request data, the HIS-Gateway server first completes the authorization verification through JWT or OAuth2.0, and then dynamically calculates the permission using the policy engine based on the prescription attributes and access scenario.

[0026] The HIS-Gateway server extracts the prescription data encrypted and stored with AES-256 from the prescription database according to the access permission, generates a key for a one-time session, encrypts the key through the ECC algorithm to obtain the key E-Ks, and then performs secondary encryption on the prescription data with the key E-Ks to generate encrypted prescription data, attaches a MAC signature, and packages it into an encrypted data packet; at the same time, the HIS-Gateway server uses a machine learning model to monitor the current request behavior of the request data in real time, and freezes the access permission if an anomaly is detected.

[0027] When performing step 2, the specific steps are as follows: Step 2-1: The steps of security verification and routing of the HIS-LB load balancing layer are as follows: Step 2-1-1: After receiving the encrypted data packet, the HIS-LB load balancing layer uses the decryption module of the TLS / HTTPS protocol to decrypt the data and recover the original request data, which includes the user identity token, device fingerprint, IP address, and access scenario information; In this embodiment, at least one load balancer server will be deployed in the HIS-LB load balancing layer to receive and process the request data encrypted by TLS / HTTPS sent by the patient APP client, and the data can exist in the form of data packets.

[0028] Step 2-1-2: Perform device fingerprint verification, IP address and geographical location verification, traffic and DDoS protection, and preliminary dynamic authorization calculation in the HIS-LB load balancing layer, specifically as follows: Device fingerprint verification: The HIS-LB layer sets up a device management module. The device management module checks the device fingerprint provided in the request, compares the device fingerprint with the pre-registered whitelist data. If the device is not in the whitelist, secondary authentication is triggered. In this embodiment, the secondary authentication is SMS or verification code verification.

[0029] IP address and geographical location verification: A geographical location database is established in the HIS-LB layer to identify the IP address; The HIS-LB layer parses the IP address in the request data, maps the IP to a specific geographical location through the geographical location database, and compares it with the historical registration data. If it is found that the IP address does not match the historical registration data (for example, the device is registered in XX region but the current IP shows YY region), the request data is marked as a risk request, and additional verification is required or access is directly denied.

[0030] In this embodiment, the additional verification is secondary verification code verification.

[0031] Traffic and DDoS protection: The HIS-LB layer sets up a traffic monitoring module to detect the request traffic in real time. When abnormal high-frequency requests or suspected DDoS attacks are detected within a short period of time, the involved IP or device is automatically rate-limited to prevent system overload.

[0032] Preliminary dynamic authorization calculation: An attribute-scenario dynamic authorization engine is set up in the HIS-LB layer, and authorization rules are preset.

[0033] The HIS-LB layer calls the attribute-scenario dynamic authorization engine to perform preliminary permission calculation based on the access scenario (such as emergency, scientific research, etc.) and prescription attributes (such as whether it contains psychotropic drugs) included in the request data, and generates a preliminary authorization mark, which is used as the basis for more refined dynamic authorization in the HIS-Gateway layer later.

[0034] In this embodiment, the authorization rules are specifically the value of the preset authorization weight coefficient, the formulation of user permissions, scenario permissions, prescription attribute permissions, and access environment security permissions.

[0035] The HIS-LB load balancing layer calculates the preliminary permission score using the following formula: ; Where is the preliminary permission score; is the user identity matching score; is the access scenario matching score; is the prescription attribute matching score; is the access environment security score; , , and are all weights adjusted in the authorization rules.

[0036] Set the threshold , if , then through preliminary authorization, the HIS-LB layer generates a "preliminary authorization mark" and forwards the request data to the allocated HIS-Gateway server; otherwise, the request is rejected or the user is required to perform additional verification.

[0037] The calculation formula for the user identity matching score is as follows: ; Where is the permission level of the user's current role, is the permission level of the highest permission role. In this embodiment, the administrator permission is 1.0, the patient is 0.2, the doctor is 0.8, the pharmacist is 0.7, and the researcher is 0.5.

[0038] The calculation formula for the access scenario matching score is as follows: ; Where is the scenario matching mapping table. In this embodiment, it is specifically as follows: Emergency: 1.0; Outpatient: 0.8; Inpatient: 0.7; Research: 0.5; Telemedicine: 0.6; Others: 0.1.

[0039] The assignment formula for the prescription attribute matching score is as follows: ; The calculation formula for the access environment security score is as follows: ; Among them, is the device trust level. For whitelisted devices, it is 1.0; for unknown devices, it is 0.3. is the IP matching degree. For normal IPs, it is 1.0; for abnormal IPs, it is 0.2. is the security of the access time. During working hours, it is 1.0; during non - working hours, it is 0.5. is the access frequency. For low - frequency access, it is 1.0; for high - frequency access, it is 0.2.

[0040] Step 2 - 1 - 3: HIS - LB monitors the current load of each HIS - Gateway server, selects an idle HIS - Gateway server, forwards the request data marked with the above - mentioned security verification and preliminary authorization, and completes the forwarding through the TLS / HTTPS secure channel during the sending process.

[0041] Step 2 - 2: The HIS - Gateway server sets up an identity authentication module, verifies the user identity token in the request data through a JWT or OAuth2.0 token. After successful verification, it confirms the user identity and records the relevant access logs. In this embodiment, the access logs include information such as time, IP, and device.

[0042] The HIS - Gateway server uses a policy engine to determine the access permissions according to the access scenario and prescription attributes in the request data. In this embodiment, a permission level mapping list corresponding to the access scenario and prescription attributes respectively is preset in the policy engine, and the HIS - Gateway server determines the access permissions by looking up the table.

[0043] Step 2 - 3: The HIS - Gateway server extracts the corresponding prescription data from the prescription database according to the user identity information. The prescription data is static encrypted data encrypted by AES - 256.

[0044] The HIS - Gateway server generates a one - time session key Ks for this session, encrypts the one - time session key Ks using the ECC algorithm to obtain the encrypted key E - Ks. The generation and management of the key are both provided by the backend HSM / KMS service to ensure the secure storage and regular rotation of the key.

[0045] Use the session key Ks to perform secondary AES - 256 encryption on the extracted prescription data to generate the encrypted prescription data, that is, the encrypted prescription data. In this embodiment, the secondary encryption of the prescription data increases the security of the data during transmission. Even if the database data is stolen, it cannot be directly decrypted without the session key.

[0046] The HIS-Gateway server performs a Message Authentication Code (MAC) signature on the encrypted prescription data for data integrity verification. In this embodiment, the HMAC-SHA256 algorithm is used for MAC signature.

[0047] The HIS-Gateway server integrates and packages the key E-Ks, the encrypted prescription data, and the MAC signature into an encrypted data packet.

[0048] Step 2-4: The HIS-Gateway server enables the real-time monitoring module to monitor the current network request behavior through the trained machine learning model. In this embodiment, the detection metrics include high-frequency access during off-peak hours, abnormal data queries across departments or permission roles, and contradictions between device fingerprints and IP addresses / geographical locations.

[0049] When an abnormal behavior is detected, the system automatically freezes the current access permission and records the log.

[0050] The machine learning model is a prior art, so it will not be described in detail.

[0051] Step 3: The prescription database adopts a distributed architecture and uses the read-write separation method and Redis caching technology for data query; an HSM / KMS service is established. The HSM / KMS service is used to generate the encryption key for the data, and store and manage the key with regular rotation; When cross-hospital data sharing is required, each collaborating hospital uploads the encrypted feature data, and the aggregated training global model is used to aggregate the encrypted feature data; a desensitization middleware is established. After receiving the data extraction request from the HIS-Gateway server, the desensitization middleware desensitizes the extracted data and shares the desensitized data with the collaborating hospitals; The desensitization of the extracted data specifically includes that when the requested data involves cross-hospital collaboration, the desensitization middleware filters the PII fields according to the preset rules, replaces the real name with an anonymous identifier, and generates a virtual patient ID.

[0052] When performing Step 3, the prescription database adopts a distributed architecture, and the separation strategy is as follows: The main database is responsible for processing transactions such as data writing, updating, and deleting.

[0053] The slave database is responsible for data query, reducing the query load on the main database.

[0054] After receiving the requested data, the HIS-Gateway server first accesses the Redis cache according to the requirements of the requested data to check if there is already a data copy: if the cache hits, the data is directly returned; if the cache misses, the data is queried from the slave database, and the result is stored in Redis for future queries.

[0055] In this embodiment, Redis cache acceleration is adopted, specifically as follows: LRU (Least Recently Used) is responsible for eliminating the data that has not been accessed for the longest time, ensuring that hot data is cached preferentially.

[0056] TTL (Time-To-Live) is responsible for setting the survival time of cached data to avoid data expiration problems.

[0057] The HIS-Gateway server queries the cache according to the CacheAside policy. If the cache is not hit, it accesses the database and updates the cache.

[0058] The key management process of the HSM / KMS service is as follows: S1: The HSM / KMS service generates an AES-256 encryption key for encrypted storage in the database.

[0059] S2: The HSM / KMS service stores the encryption key.

[0060] S3: The HSM / KMS service sets the encryption key to be automatically rotated regularly (e.g., every 30 days). The old key is gradually phased out and the new key becomes effective. When rotating, the HSM first decrypts the existing data and then re-encrypts it with the new key.

[0061] In this embodiment, when cross-hospital data sharing is required, the federated learning method can be used to share data. Each collaborating hospital can only share encrypted feature data to avoid the leakage of raw data.

[0062] Step 4: After receiving the encrypted data packet sent from the HIS-Gateway server, the APP client verifies the integrity, decrypts the prescription data, and displays it.

[0063] The encrypted data packet contains the key E-Ks, encrypted prescription data, and MAC signature. The encrypted data packet is sent by the HIS-Gateway server and transmitted to the patient APP through the TLS / HTTPS communication encryption channel of the HIS-LB layer. The APP first decrypts the key E-Ks using the local private key, and then decrypts the encrypted prescription data using the key E-Ks to finally obtain the prescription data.

[0064] In this embodiment, the structure of the encrypted data packet is as follows: ; where is the encrypted prescription data.

[0065] After receiving the encrypted data packet from the HIS-Gateway server, the APP first performs integrity verification to prevent the data from being tampered with or damaged during transmission. The specific verification method is as follows: The APP parses the Data_Packet, extracts the MAC, and calculates the check value of HMAC-SHA256.

[0066] After confirming the data integrity, the APP client uses the local private key for ECC decryption to obtain the session key Ks.

[0067] After obtaining the session key Ks, the APP decrypts the encrypted prescription data Cdata using AES-256.

[0068] A hospital patient information security management method described in the present invention solves the technical problem of realizing the security protection of sensitive medical data in a high-concurrency and cross-domain collaboration environment through multi-layer encryption, dynamic authorization, and intelligent anomaly detection. From request generation, distribution, business processing to data storage, desensitization sharing, and client decryption, the whole process of the present invention adopts multiple encryption and security verification to ensure the confidentiality and integrity of data. By using an attribute-scenario dynamic authorization engine, it realizes dynamic calculation of permissions according to access scenarios and data attributes to meet the differentiated security requirements of multiple scenarios such as emergency and scientific research. By integrating a machine learning model, it monitors abnormal access behaviors in real time, freezes permissions in a timely manner, and triggers audits, greatly improving the internal threat detection ability. By using a data desensitization middleware, it realizes cross-hospital data statistical analysis without leaking the original data, taking into account both data sharing and privacy protection.

Claims

1. A method for hospital patient information security management, characterized in that: It includes the following steps: Step 1: After the patient selects the prescription query on the APP client, the APP client generates request data containing the user identity token, device fingerprint, IP address, and access scenario information, and sends the request data to the HIS-LB load balancing layer of the hospital information system after encrypting it through TLS / HTTPS communication; Step 2: After the HIS-LB load balancing layer conducts security verification on the request data, it selects the HIS-Gateway server to distribute the request data; After receiving the request data from the HIS-LB layer, the HIS-Gateway server authenticates the request data using JWT or OAuth2.0 tokens, and determines the access permission based on the access scenario and prescription attributes through the policy engine; The HIS-Gateway server extracts the prescription data encrypted by AES-256 from the prescription database according to the access permission, generates a key for a one-time session, encrypts the key through the ECC algorithm to obtain the key E-Ks, and then uses the key E-Ks to perform secondary encryption on the prescription data to generate encrypted prescription data, attaches the MAC signature, and packages it into an encrypted data packet; at the same time, the HIS-Gateway server uses a machine learning model to monitor the current request behavior of the request data in real time, and freezes the access permission if an anomaly is detected; Step 3: The prescription database adopts a distributed architecture, uses the read-write separation method and Redis caching technology for data query; establishes an HSM / KMS service, and the HSM / KMS service is used to generate the encryption key for the data, and store and manage the key with regular rotation; When cross-hospital data sharing is required, each collaborating hospital uploads encrypted feature data, and uses the aggregated training global model to aggregate the encrypted feature data; Establish a desensitization middleware, which desensitizes the extracted data after receiving the data extraction request from the HIS-Gateway server, and shares the desensitized data with the collaborating hospital; Step 4: After the APP client receives the encrypted data packet sent from the HIS-Gateway server, it decrypts the prescription data and displays it after verifying the integrity.

2. The method for hospital patient information security management according to claim 1, wherein: When executing Step 2, after the HIS-LB load balancing layer makes judgments on device verification, IP verification, traffic analysis, prescription attribute authorization, and scenario dynamic authorization, it routes the request data to the idle HIS-Gateway server.

3. The hospital patient information security management method according to claim 1, characterized in that: When executing Step 2, after receiving the request data, the HIS-Gateway server first completes the authorization verification through JWT or OAuth2.0, and then dynamically calculates the permission using the policy engine according to the prescription attributes and access scenario.

4. The hospital patient information security management method according to claim 1, wherein: When executing Step 4, the encrypted data packet contains the key E-Ks, encrypted prescription data, and MAC signature. The encrypted data packet is sent by the HIS-Gateway server and transmitted to the patient APP through the TLS / HTTPS communication encryption communication channel of the HIS-LB layer. The APP decrypts the key E-Ks using the local private key first, and then decrypts the encrypted prescription data using the key E-Ks to finally obtain the prescription data.

5. The hospital patient information security management method according to claim 1, characterized in that: When performing step 2, the HIS-LB load balancing layer also performs the following security verifications on the access of the APP client: Device fingerprint verification, including detecting whether the requesting device deployed by the APP client is within the whitelist; if it is a non-trusted device, secondary verification is triggered; IP address and geographical location verification, including comparing the IP address with historical data; if an anomaly is found, it is marked as a risk request and rejected or additional verification is required; Traffic and DDoS protection, including monitoring abnormal traffic and throttling or triggering traffic cleaning for frequent access requests; Initial calculation of dynamic authorization, invoking the attribute-scenario dynamic authorization engine to perform an initial calculation of the permission policy based on the query scenario and prescription attributes provided in the request, and generating an initial authorization token.

6. The hospital patient information security management method according to claim 1, characterized in that: When performing step 3, the desensitization of the extracted data specifically includes that when the requested data involves cross-hospital collaboration, the desensitization middleware filters the PII fields according to preset rules, replaces the real name with an anonymous identifier, and generates a virtual patient ID.

7. The hospital patient information security management method according to claim 1, characterized in that: When performing step 2, the access permission is determined by the policy engine based on the access scenario and prescription attributes. Specifically: set the attribute-scenario dynamic authorization engine in the HIS-LB load balancing layer and preset the authorization rules; The HIS-LB load balancing layer invokes the attribute-scenario dynamic authorization engine to perform an initial permission calculation based on the access scenario and prescription attributes included in the request data, generating an initial authorization token. The initial permission calculation is specifically that the HIS-LB load balancing layer calculates the initial permission score using the following formula: ； Among them, is the preliminary permission score; is the user identity matching score; is the access scenario matching score; is the prescription attribute matching score; is the access environment security score; , , and are all weights adjusted in the authorization rules; Set threshold If , then through preliminary authorization, the HIS-LB layer generates a preliminary authorization mark and forwards the request data to the allocated HIS-Gateway server; otherwise, the request is rejected or the user is required to perform additional verification.

Images