A hospital patient information security management method

Abstract

The present invention discloses a hospital patient information security management method, which belongs to the field of information security technology. The method includes APP generating request data, HIS-LB load balancing and security verification, HIS-Gateway processing requests, and APP parsing data packets. It solves the technical problem of achieving security protection of sensitive medical data in a high-concurrency, cross-domain collaborative environment through multi-layer encryption, dynamic authorization and intelligent anomaly detection. The present invention ensures the confidentiality and integrity of data, meets the differentiated security requirements of multiple scenarios, greatly improves the internal threat detection capability, and adopts data desensitization middleware to achieve cross-hospital data statistical analysis without leaking original data, taking into account both data sharing and privacy protection.

Description

Technical Field

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

[0002] Amid the rapid development of healthcare informatization, hospital information systems (HIS) have become the core platform for managing patient medical data. Electronic prescriptions, as critical medical records, involve patient privacy, medication safety, and cross-institutional collaboration. However, traditional prescription query and sharing solutions face significant challenges in terms of security, flexibility, and compliance.

[0003] The shortcomings of traditional technology are:

[0004] Lack of dynamic authorization mechanism: The control of access rights in existing solutions is usually relatively fixed, making it difficult to dynamically adjust permissions based on specific access scenarios and data attributes.

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

[0006] Insufficient internal threat and anomaly detection: The detection and response mechanism for internal abnormal behavior is imperfect, and there is a lack of the ability to use intelligent means such as machine learning to achieve real-time anomaly monitoring.

[0007] Insufficient privacy protection in cross-institutional data sharing: During the data sharing process, the direct exchange of original data may lead to the risk of privacy leakage, and there is an urgent need to adopt data desensitization and security aggregation technology. Summary of the Invention

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

[0009] To achieve the above objectives, the present invention adopts the following technical inventions:

[0010] A hospital patient information security management method comprises the following steps:

[0011] Step 1: After the patient selects a 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. The request data is encrypted via TLS / HTTPS communication and sent to the HIS-LB load balancing layer of the hospital information system.

[0012] 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;

[0013] 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 uses the policy engine to determine access rights based on the access scenario and prescription attributes.

[0014] The HIS-Gateway server extracts AES-256 encrypted prescription data from the prescription database based on access rights, generates a one-time session key, encrypts the key using the ECC algorithm to obtain the key E-Ks, then uses the key E-Ks to re-encrypt the prescription data to generate encrypted prescription data, appends a MAC signature, and packages it into an encrypted data packet. Simultaneously, the HIS-Gateway server uses a machine learning model to monitor the current request behavior of the requested data in real time, and freezes access rights if an anomaly is detected.

[0015] Step 3: The prescription database adopts a distributed architecture, using read-write separation and Redis caching technology for data query. An HSM / KMS service is established to generate encryption keys for data, store them, and manage their regular rotation.

[0016] When cross-hospital data sharing is required, each collaborating hospital uploads encrypted feature data, which is then aggregated using a global model trained through aggregation. A desensitizing middleware is established to desensitize the extracted data upon receiving a data extraction request from the HIS-Gateway server, and the desensitized data is then shared with the collaborating hospitals.

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

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

[0019] 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 uses the policy engine to dynamically calculate the permissions according to the prescription attributes and access scenarios.

[0020] Preferably, 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 encrypted communication channel of the HIS-LB layer. The APP uses the local private key to first decrypt the key E-Ks, and then uses the key E-Ks to decrypt the encrypted prescription data, and finally obtains the prescription data.

[0021] Preferably, when executing step 2, the HIS-LB load balancing layer also performs the following security verification on the access of the APP client:

[0022] Device fingerprint verification, including detecting whether the requesting device deployed by the APP client is on the whitelist; if it is an untrusted device, secondary verification is triggered;

[0023] IP address and geolocation verification, including comparing IP addresses with historical data; if anomalies are found, the request will be marked as risky and rejected or require additional verification;

[0024] Traffic and DDoS protection, including monitoring abnormal traffic, limiting frequent access requests, or triggering traffic cleaning;

[0025] Dynamic authorization preliminary calculation, calling the attribute-scenario dynamic authorization engine, performs preliminary calculation of the permission policy based on the query scenario and prescription attributes provided in the request, and generates a preliminary authorization tag.

[0026] Preferably, when executing step 3, the extracted data is desensitized, specifically including when the requested data involves cross-hospital collaboration, the desensitizing middleware filters the PII field according to preset rules, replaces the real name with an anonymous identifier, and generates a virtual patient ID.

[0027] Preferably, when executing step 2, the access rights are determined based on the access scenario and the prescription attributes by the policy engine, specifically: setting an attribute-scenario dynamic authorization engine at the HIS-LB load balancing layer and presetting the authorization rules;

[0028] The HIS-LB load balancing layer calls the attribute-scenario dynamic authorization engine to perform preliminary permission calculation based on the access scenario and prescription attributes contained in the request data, and generates a preliminary authorization tag. The preliminary permission calculation is specifically that the HIS-LB load balancing layer uses the following formula to calculate the preliminary permission score:

[0029] ;

[0030] in, scoring preliminary permissions; Score the user's identity matching; Score the matching degree of the access scenario; Score the matching degree of prescription attributes; Score the security of the access environment; 、 、 and These are weights adjusted in the authorization rules.

[0031] Setting thresholds ,like If the preliminary authorization is successful, the HIS-LB layer generates a preliminary authorization tag and forwards the request data to the assigned HIS-Gateway server; otherwise, the request is rejected or the user is required to perform additional verification.

[0032] The hospital patient information security management method described in the present invention solves the technical problem of achieving security protection of sensitive medical data in a high-concurrency, cross-domain collaborative environment through multi-layer encryption, dynamic authorization and intelligent anomaly detection. The present invention adopts multiple encryption and security verification in the entire process from request generation, distribution, business processing to data storage, desensitized sharing and client decryption to ensure the confidentiality and integrity of the data. It uses an attribute-scenario dynamic authorization engine to dynamically calculate permissions based on access scenarios and data attributes to meet the differentiated security needs of multiple scenarios such as emergency and scientific research. By integrating machine learning models, it monitors abnormal access behavior in real time, freezes permissions in time and triggers audits, greatly improving the internal threat detection capability. It uses data desensitization middleware to achieve cross-hospital data statistical analysis without leaking original data, and takes into account both data sharing and privacy protection. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is the main flow chart of the present invention;

[0034] Figure 2 is a flow chart of step 1 of the present invention;

[0035] Figure 3 is a flow chart of step 2 of the present invention;

[0036] Figure 4 It is a flow chart of step 3 of the present invention. DETAILED DESCRIPTION

[0037] Depend on Figures 1-4 A hospital patient information security management method shown includes the following steps:

[0038] Step 1: After the patient selects a 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. The request data is encrypted via TLS / HTTPS communication and sent to the HIS-LB load balancing layer of the hospital information system.

[0039] When executing step 1, the specific steps are as follows:

[0040] 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;

[0041] Step 1-2: The APP client generates a user identity token based on the patient's operation. The user identity token includes a JWT token generated based on the user's identity authentication information when logging in or registering;

[0042] The APP client collects the device fingerprint of the local device, including the device's unique identifier (such as IMEI, serial number), operating system version, device model, and other hardware parameters (prepared according to the hospital's requirements);

[0043] Device fingerprints are generated using a hash algorithm, specifically the SHA-256 algorithm, which performs a hash calculation on the collected information to form device fingerprint data of fixed length. The formula of the SHA-256 algorithm is as follows:

[0044] ;

[0045] in, The calculated hash value, is the IMEI of the device, is the operating system version of the device. is another parameter in the device model. In this embodiment, the value is the MAC address of the device. For other information about the device, this value is determined by the hospital's requirements, such as CPU serial number, capacity, etc.

[0046] The APP client obtains the currently used IP address through the Internet interface, and extracts and generates access scenario information based on the business scenario (such as outpatient, emergency, and scientific research) selected by the user during the operation;

[0047] The APP client integrates the collected data to obtain a data structure in JSON format, clearly identifies the purpose of each field, and attaches a timestamp to finally generate the request data.

[0048] Steps 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, automatically completing data encryption, data integrity verification, and identity authentication. The specific encryption process is as follows:

[0049] 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 provided by the operating system) to perform a secure handshake (SSL / TLS handshake). During the handshake, the APP client exchanges certificates, negotiates encryption algorithms and session keys with the server deployed at the HIS-LB layer, and then uses the session keys to encrypt the request data.

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

[0051] After the data starts from the APP client, it is transmitted via the Internet to the HIS-LB layer server in the hospital prescription data center. The entire transmission process is protected by the TLS / HTTPS protocol.

[0052] 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;

[0053] The HIS-LB load balancing layer routes the request data to the idle HIS-Gateway server after device verification, IP verification, traffic analysis, prescription attribute authorization, and scenario dynamic authorization.

[0054] The HIS-LB load balancing layer also performs the following security verification on APP client access:

[0055] Device fingerprint verification, including detecting whether the requesting device deployed by the APP client is on the whitelist; if it is an untrusted device, secondary verification is triggered;

[0056] IP address and geolocation verification, including comparing IP addresses with historical data; if anomalies are found, the request will be marked as risky and rejected or require additional verification;

[0057] Traffic and DDoS protection, including monitoring abnormal traffic, limiting frequent access requests, or triggering traffic cleaning;

[0058] Dynamic authorization preliminary calculation, calling the attribute-scenario dynamic authorization engine, performs preliminary calculation of the permission policy based on the query scenario and prescription attributes provided in the request, and generates a preliminary authorization tag.

[0059] 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 uses the policy engine to determine access rights based on the access scenario and prescription attributes.

[0060] After receiving the request data, the HIS-Gateway server first completes authorization verification through JWT or OAuth2.0, and then uses the policy engine to dynamically calculate permissions based on prescription attributes and access scenarios.

[0061] The HIS-Gateway server extracts AES-256 encrypted prescription data from the prescription database based on access rights, generates a one-time session key, encrypts the key using the ECC algorithm to obtain the key E-Ks, and then uses the key E-Ks to encrypt the prescription data again to generate encrypted prescription data, attach a MAC signature, and package 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 requested data in real time, and freezes access rights if an anomaly is detected.

[0062] When executing step 2, the specific steps are as follows:

[0063] Step 2-1: The security verification and routing steps of the HIS-LB load balancing layer are as follows:

[0064] Step 2-1-1: After receiving the encrypted data packet, HIS-LB load balancing layer uses the TLS / HTTPS protocol decryption module to decrypt the data and restore the original request data, including the user identity token, device fingerprint, IP address and access scenario information;

[0065] In this embodiment, the HIS-LB load balancing layer deploys at least one load balancing server to receive and process TLS / HTTPS encrypted request data sent by the patient APP client. The data can exist in the form of data packets.

[0066] Step 2-1-2: Perform device fingerprint verification, IP address and geographic location verification, traffic and DDoS protection, and dynamic authorization preliminary calculations at the HIS-LB load balancing layer, as follows:

[0067] Device fingerprint verification:

[0068] The HIS-LB layer sets up a device management module. The device management module checks the device fingerprint provided in the request and compares the device fingerprint with the pre-registered whitelist data. If the device is not in the whitelist, it triggers secondary identity authentication. The secondary verification in this embodiment is SMS or verification code verification.

[0069] IP address and geographic location verification:

[0070] Establish a geographic location database at the HIS-LB layer to identify IP addresses;

[0071] The HIS-LB layer parses the IP address in the request data, maps the IP to a specific geographic location through the geolocation database, and compares it with 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 is displayed in YY region), the request data will be marked as a risky request and require additional verification or directly deny access.

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

[0073] Traffic and DDoS protection:

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

[0075] Dynamic authorization preliminary calculation:

[0076] Set up the attribute-scenario dynamic authorization engine at the HIS-LB layer and preset authorization rules.

[0077] The HIS-LB layer calls the attribute-scenario dynamic authorization engine to perform preliminary permission calculations based on the access scenarios (such as emergency, scientific research, etc.) and prescription attributes (such as whether psychotropic drugs are included) contained in the request data, and generates a preliminary authorization tag. This tag serves as the basis for subsequent more refined dynamic authorization at the HIS-Gateway layer.

[0078] In this embodiment, the authorization rules specifically include setting the value of the preset authorization weight coefficient, formulating user permissions, scene permissions, prescription attribute permissions, and access environment security permissions.

[0079] The HIS-LB load balancing layer uses the following formula to calculate the preliminary permission score:

[0080] ;

[0081] in, scoring preliminary permissions; Score user identity matching; Score the matching degree of the access scenario; Score the matching degree of prescription attributes; Score the security of the access environment; 、 、 and These are weights adjusted in the authorization rules.

[0082] Setting thresholds ,like If the preliminary authorization is passed, the HIS-LB layer generates a "preliminary authorization tag" and forwards the request data to the assigned HIS-Gateway server; otherwise, the request is rejected or the user is required to perform additional verification.

[0083] The calculation formula for the user identity matching score is as follows:

[0084] ;

[0085] in, is the permission level of the user's current role, is the permission level of the highest-authority role. In this embodiment, the administrator's permission is 1.0, the patient's permission is 0.2, the doctor's permission is 0.8, the pharmacist's permission is 0.7, and the scientific researcher's permission is 0.5.

[0086] The calculation formula for the access scenario matching score is as follows:

[0087] ;

[0088] in The scene matching mapping table is as follows in this embodiment:

[0089] Emergency: 1.0;

[0090] Outpatient: 0.8;

[0091] Inpatient: 0.7;

[0092] Research: 0.5;

[0093] Telemedicine: 0.6;

[0094] Others: 0.1.

[0095] The formula for assigning prescription attribute matching scores is as follows:

[0096] ;

[0097] The formula for calculating the access environment security score is as follows:

[0098] ;

[0099] in, Device trust: whitelisted devices = 1.0, unknown devices = 0.3; is the IP matching degree, normal IP = 1.0, abnormal IP = 0.2; For access time security, working time = 1.0, non-working time = 0.5; is the access frequency, low-frequency access = 1.0, high-frequency access = 0.2.

[0100] Step 2-1-3: HIS-LB monitors the current load of each HIS-Gateway server, selects an idle HIS-Gateway server, and forwards the request data that has passed the above security verification and preliminary authorization mark. The forwarding is completed through the TLS / HTTPS secure channel during the sending process.

[0101] Step 2-2: The HIS-Gateway server sets up an identity authentication module and verifies the user identity token in the request data through JWT or OAuth2.0 token. After successful verification, the user identity is confirmed and relevant access logs are recorded. In this embodiment, the access log includes time, IP, and device information.

[0102] The HIS-Gateway server uses a policy engine to determine access rights based on the access scenarios and prescription attributes in the request data. In this embodiment, the policy engine presets a permission level mapping list corresponding to the access scenarios and prescription attributes, and the HIS-Gateway server determines access rights by looking up the table.

[0103] Step 2-3: The HIS-Gateway server extracts the corresponding prescription data from the prescription database based on the user identity information. The prescription data is statically encrypted data encrypted with AES-256.

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

[0105] The extracted prescription data is encrypted twice with AES-256 using the session key Ks to generate encrypted prescription data, i.e., 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.

[0106] 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.

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

[0108] Step 2-4: The HIS-Gateway server enables the real-time monitoring module and monitors the current network request behavior through the trained machine learning model. In this embodiment, the detection indicators include high-frequency access during non-working hours, abnormal data queries across departments or cross-authority roles, and inconsistencies between device fingerprints and IP addresses and geographic locations.

[0109] When abnormal behavior is detected, the system automatically freezes the current access rights and records the logs.

[0110] The machine learning model is an existing technology and therefore will not be described in detail.

[0111] Step 3: The prescription database adopts a distributed architecture, using read-write separation and Redis caching technology for data query. An HSM / KMS service is established to generate encryption keys for data, store them, and manage their regular rotation.

[0112] When cross-hospital data sharing is required, each collaborating hospital uploads encrypted feature data, which is then aggregated using a global model trained through aggregation. A desensitizing middleware is established to desensitize the extracted data upon receiving a data extraction request from the HIS-Gateway server, and the desensitized data is then shared with the collaborating hospitals.

[0113] Desensitizing the extracted data specifically includes when the requested data involves cross-hospital collaboration, the desensitizing middleware filters the PII fields according to preset rules, replaces the real name with an anonymous identifier, and generates a virtual patient ID.

[0114] When executing step 3, the prescription database adopts a distributed architecture, and the separation strategy is as follows:

[0115] The master database is responsible for processing data write, update, delete and other transactions.

[0116] The slave database is responsible for data query, reducing the query load of the master database.

[0117] After receiving the requested data, the HIS-Gateway server first accesses the Redis cache to check whether there is already a data copy according to the requirements of the requested data: if the cache hits, the data is returned directly; if the cache does not hit, the data is queried from the database and the result is stored in Redis for the next query.

[0118] In this embodiment, Redis cache acceleration is used, specifically:

[0119] 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 first.

[0120] TTL (Time-To-Live) is responsible for setting the lifetime of cached data to avoid data expiration issues.

[0121] According to the CacheAside policy, the HIS-Gateway server first queries the cache. If there is a miss, it accesses the database and updates the cache.

[0122] The key management process for the HSM / KMS service is as follows:

[0123] S1: The HSM / KMS service generates an AES-256 encryption key for database encryption and storage.

[0124] S2: HSM / KMS service stores encryption keys.

[0125] S3: The HSM / KMS service is set to automatically rotate encryption keys regularly (for example, every 30 days). Old keys are gradually phased out and new keys take effect. During rotation, the HSM first decrypts existing data and then re-encrypts it with the new key.

[0126] In this embodiment, when cross-hospital data sharing is required, federated learning can be used to share data, and each collaborating hospital can only share encrypted feature data to avoid leakage of original data.

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

[0128] 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 encrypted communication channel of the HIS-LB layer. The APP uses the local private key to first decrypt the key E-Ks, and then uses the key E-Ks to decrypt the encrypted prescription data, and finally obtains the prescription data.

[0129] In this embodiment, the structure of the encrypted data packet is as follows:

[0130] ;

[0131] in To encrypt prescription data.

[0132] 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:

[0133] The app parses the Data_Packet, extracts the MAC, and calculates the HMAC-SHA256 checksum.

[0134] After confirming the integrity of the data, the APP client uses the local private key to perform ECC decryption and obtain the session key Ks.

[0135] After obtaining the session key Ks, the APP uses AES-256 to decrypt the encrypted prescription data Cdata.

[0136] The hospital patient information security management method described in the present invention solves the technical problem of achieving security protection of sensitive medical data in a high-concurrency, cross-domain collaborative environment through multi-layer encryption, dynamic authorization and intelligent anomaly detection. The present invention adopts multiple encryption and security verification in the entire process from request generation, distribution, business processing to data storage, desensitized sharing and client decryption to ensure the confidentiality and integrity of the data. It uses an attribute-scenario dynamic authorization engine to dynamically calculate permissions based on access scenarios and data attributes to meet the differentiated security needs of multiple scenarios such as emergency and scientific research. By integrating machine learning models, it monitors abnormal access behavior in real time, freezes permissions in time and triggers audits, greatly improving the internal threat detection capability. It uses data desensitization middleware to achieve cross-hospital data statistical analysis without leaking original data, and takes into account both data sharing and privacy protection.

Claims

1. A hospital patient information security management method, characterized by: The steps include: Step 1: After the patient selects a 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. The request data is encrypted via TLS / HTTPS communication and sent to the HIS-LB load balancing layer of the hospital information system. 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 uses the policy engine to determine access rights based on the access scenario and prescription attributes. The HIS-Gateway server extracts AES-256 encrypted prescription data from the prescription database based on access rights, generates a one-time session key, encrypts the key using the ECC algorithm to obtain the key E-Ks, then uses the key E-Ks to re-encrypt the prescription data to generate encrypted prescription data, appends a MAC signature, and packages it into an encrypted data packet. Simultaneously, the HIS-Gateway server uses a machine learning model to monitor the current request behavior of the requested data in real time, and freezes access rights if an anomaly is detected. Step 2-1: The security verification and routing steps of the HIS-LB load balancing layer are as follows: Step 2-1-1: After receiving the encrypted data packet, HIS-LB load balancing layer uses the TLS / HTTPS protocol decryption module to decrypt the data and restore the original request data, including the user identity token, device fingerprint, IP address and access scenario information; The HIS-LB load balancing layer deploys at least one load balancing server to receive and process TLS / HTTPS encrypted request data sent by the patient APP client. The data exists in the form of data packets. Step 2-1-2: Perform device fingerprint verification, IP address and geographic location verification, traffic and DDoS protection, and dynamic authorization preliminary calculations at the HIS-LB load balancing layer, as follows: Device fingerprint verification: The HIS-LB layer sets up a device management module, which checks the device fingerprint provided in the request and compares the device fingerprint with the pre-registered whitelist data. If the device is not in the whitelist, it triggers a secondary authentication. IP address and geographic location verification: Establish a geographic location database at the HIS-LB layer to identify IP addresses; The HIS-LB layer parses the IP address in the request data, maps the IP address to a specific geographic location through the geolocation database, and compares it with historical registration data. If the IP address does not match the historical registration data, the request data will be marked as a risky request and require additional verification or directly deny access; The additional verification is a two-step verification code verification; Traffic and DDoS protection: The HIS-LB layer sets up a traffic monitoring module to detect request traffic in real time. When abnormally high-frequency requests or suspected DDoS attacks are detected in a short period of time, the module automatically limits the flow of the IP or device involved to prevent system overload. Dynamic authorization preliminary calculation: Set up an attribute-scenario dynamic authorization engine at the HIS-LB layer and preset authorization rules; The HIS-LB layer calls the attribute-scenario dynamic authorization engine to perform preliminary permission calculations based on the access scenario and prescription attributes contained in the request data, and generates a preliminary authorization tag, which serves as the basis for subsequent dynamic authorization at the HIS-Gateway layer. Authorization rules specifically include setting the value of the preset authorization weight coefficient, setting user permissions, scene permissions, prescription attribute permissions, and access environment security permissions; The HIS-LB load balancing layer uses the following formula to calculate the preliminary permission score: ； in, scoring preliminary permissions; Score the user's identity matching; Score the matching degree of the access scenario; Score the matching degree of prescription attributes; Score the security of the access environment; 、 、 and These are weights adjusted in the authorization rules; Setting thresholds ,like If the request is successful, the HIS-LB layer generates a "preliminary authorization tag" and forwards the request data to the assigned HIS-Gateway server; otherwise, the request is rejected or the user is required to perform additional verification. The calculation formula for the user identity matching score is as follows: ； in, is the permission level of the user's current role, The permission level of the highest-privilege role; The calculation formula for the access scenario matching score is as follows: ； in Matching mapping table for the scene; The formula for assigning prescription attribute matching scores is as follows: ； The formula for calculating the access environment security score is as follows: ； in, is the device trust, IP matching degree; For access time security; is the frequency of visits; Step 2-1-3: HIS-LB monitors the current load of each HIS-Gateway server, selects an idle HIS-Gateway server, and forwards the request data that has passed the above security verification and preliminary authorization mark. The forwarding is completed through the TLS / HTTPS secure channel during the sending process; Step 2-2: The HIS-Gateway server sets up an identity authentication module and verifies the user identity token in the request data through JWT or OAuth2.0 token. After successful verification, the user identity is confirmed and relevant access logs are recorded. The access logs include time, IP, and device information. The HIS-Gateway server uses a policy engine to determine access rights based on the access scenario and prescription attributes in the request data. The policy engine has a preset permission level mapping list corresponding to the access scenario and prescription attributes. The HIS-Gateway server determines access rights by looking up the table. Step 2-3: The HIS-Gateway server extracts the corresponding prescription data from the prescription database based on the user's identity information. The prescription data is statically encrypted data encrypted with AES-256. The HIS-Gateway server generates a one-time session key Ks for this session and encrypts it using the ECC algorithm to obtain the encrypted key E-Ks. Key generation and management are provided by the backend HSM / KMS service. The extracted prescription data is encrypted twice with AES-256 using the session key Ks to generate encrypted prescription data, i.e., encrypted prescription data; The HIS-Gateway server performs a message authentication code (MAC) signature on the encrypted prescription data for data integrity verification, using the HMAC-SHA256 algorithm for MAC signature. The HIS-Gateway server integrates and packages the key E-Ks, encrypted prescription data, and MAC signature into an encrypted data packet; Step 2-4: The HIS-Gateway server activates the real-time monitoring module and uses the trained machine learning model to monitor current network request behavior. Detection indicators include high-frequency access during non-working hours, abnormal data queries across departments or roles, and inconsistencies between device fingerprints and IP addresses and geographic locations. When abnormal behavior is detected, the current access rights are automatically frozen and logs are recorded; Step 3: The prescription database adopts a distributed architecture, using read-write separation and Redis caching technology for data query. An HSM / KMS service is established to generate encryption keys for data, store them, and regularly rotate them. When cross-hospital data sharing is required, each collaborating hospital uploads encrypted feature data, which is then aggregated using a global model trained through aggregation. A desensitizing middleware is established to desensitize the extracted data upon receiving a data extraction request from the HIS-Gateway server, and the desensitized data is then shared with the collaborating hospitals. When executing step 3, the prescription database adopts a distributed architecture, and the separation strategy is as follows: The primary database is responsible for processing data write, update, and delete transactions; The slave database is responsible for data query, reducing the query load of the master database; After receiving the request data, the HIS-Gateway server first checks whether there is a data copy in the Redis cache according to the requirements of the requested data. If the cache hits, the data is returned directly. If the cache misses, the data is queried from the database and the result is stored in Redis for the next query. Use Redis cache to accelerate, specifically: LRU is responsible for eliminating the data that has not been accessed for the longest time, ensuring that hot data is cached first; TTL is responsible for setting the lifetime of cached data to avoid data expiration issues; According to the CacheAside policy, the HIS-Gateway server first queries the cache. If there is a miss, it accesses the database and updates the cache. The key management process for the HSM / KMS service is as follows: S1: The HSM / KMS service generates an AES-256 encryption key for database encryption and storage. S2: HSM / KMS service stores encryption keys; S3: The HSM / KMS service automatically rotates encryption keys regularly, gradually phasing out old keys and activating new ones. During rotation, the HSM first decrypts existing data and then re-encrypts it with the new key. When cross-hospital data sharing is required, federated learning is used to share data. Collaborating hospitals only share encrypted feature data to avoid leakage of original data. Step 4: After the APP client receives the encrypted data packet sent from the HIS-Gateway server, it verifies the integrity, decrypts the prescription data and displays it.

2. A hospital patient information security management method according to claim 1, characterized in that: 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 encrypted communication channel of the HIS-LB layer. The APP uses the local private key to first decrypt the key E-Ks, and then uses the key E-Ks to decrypt the encrypted prescription data, and finally obtains the prescription data.

3. A hospital patient information security management method according to claim 1, characterized in that: When executing step 3, the extracted data is desensitized. Specifically, when the requested data involves cross-hospital collaboration, the desensitizing middleware filters the PII fields according to preset rules, replaces the real name with an anonymous identifier, and generates a virtual patient ID.

Images