A smart medical information system based on multi-system integration and a data security management method and device, electronic equipment and storage medium

Abstract

The application provides a smart medical information system and a data security management method and device based on multi-system integration, electronic equipment and a storage medium, and is applied to the technical field of medical data processing. The application obtains three types of information, including core security elements, multi-system heterogeneous adaptation (including HIS / LIS / EMR interface specifications), and whole-process auditing (including operation logs). Then, the core security elements are standardized by using AI multi-modal privacy recognition technology, and a standardized security baseline file is generated. The heterogeneous adaptation information is processed by using a lightweight API connector to form a multi-system security access scheme. Then, the baseline file and the access scheme are associated to generate a whole life cycle protection strategy based on a zero trust architecture. The auditing information is processed to generate a dynamic security auditing report. Finally, based on security-adaptation linkage decision engine and compliance verification, a cross-system data security sharing scheme and a privacy leakage emergency response instruction are output, and a medical data security management closed loop is realized.

Description

Technical Field

[0001] This invention relates to the field of medical data processing technology, and in particular to a smart medical information system and data security management method based on multi-system integration. Background Technology

[0002] Hospitals currently deploy independent business systems such as HIS (Hospital Information System), LIS (Laboratory Information System), and EMR (Electronic Medical Record System). These systems differ in their interface protocols (RESTful, Socket, WebService) and data formats (JSON, SOAP, custom formats). Multi-system integration primarily achieves data exchange through traditional API interfaces and data synchronization tools (such as ETL), with some using medical data standards like HL7 and FHIR for field mapping, but this approach lacks sufficient flexibility.

[0003] Existing integration technologies lack lightweight, standardized adaptation solutions. Differences in interface protocols and data formats lead to low cross-system compatibility, requiring extensive customized development, resulting in low adaptation efficiency and high maintenance costs. Traditional security management relies on manual definition of sensitive data, failing to intelligently identify multimodal privacy information. Fixed hierarchical protection rules are difficult to adapt to the dynamic changes in medical business scenarios, and anonymization can easily lead to decreased data availability. There is a lack of a comprehensive "access-protection-audit-response" linkage mechanism, resulting in a disconnect between cross-system protection strategies and data security baselines. Audit logs are highly tamper-proof, abnormal behavior detection is delayed, and there is no standardized emergency response process after privacy breaches. Existing solutions do not fully integrate medical data security regulatory requirements. Cross-system data sharing either involves excessive restrictions leading to inconvenience or insufficient protection causing compliance risks, lacking a dynamic matching mechanism for compliance verification and sharing permissions.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure and does not constitute information on prior art known to those skilled in the art. Summary of the Invention

[0005] According to one aspect of this application, a data security management method for smart healthcare information based on multi-system integration is provided, comprising: acquiring core security element information, multi-system heterogeneous adaptation information, and full-process audit information; the multi-system heterogeneous adaptation information includes HIS / LIS / EMR system interface specifications, data format difference parameters, and cross-institutional interface protocols; the full-process audit information includes data access operation logs, permission change records, and cross-domain transfer trajectories; intelligently organizing and processing the core security element information, introducing an AI multimodal privacy recognition algorithm and a dynamic hierarchical rule engine, and combining differential privacy technology with a blockchain evidence storage mechanism to generate a standardized security baseline file; processing the multi-system heterogeneous adaptation information based on the heterogeneous system adaptation engine, and using a lightweight standardized API connector and medical data... Based on standard automatic mapping technology, combined with cross-system compatibility verification and interface security hardening, a multi-system secure access solution is generated. The standardized security baseline file and the multi-system secure access solution are correlated, and a hierarchical protection system is built through a zero-trust security architecture to generate a full lifecycle security protection strategy for medical data. Operation logs, permission change data, and flow trajectories in the full-process audit information are processed using a behavioral anomaly detection model, integrating a real-time monitoring and alarm module with a blockchain immutable audit chain to generate a dynamic security audit report. Based on a security-adaptation linkage decision engine combined with multi-dimensional compliance verification strategies, the full lifecycle security protection strategy, dynamic security audit report, and multi-system secure access solution are processed to generate a cross-system data security sharing scheme and privacy leakage emergency response instructions.

[0006] Another aspect of this application discloses a data security management device for smart medical information based on multi-system integration, comprising: an acquisition module for acquiring core security element information, multi-system heterogeneous adaptation information, and full-process audit information; a processing module for intelligently organizing and processing the core security element information, introducing an AI multimodal privacy recognition algorithm and a dynamic hierarchical rule engine, and combining differential privacy technology and a blockchain evidence storage mechanism to generate a standardized security baseline file; and a processing module for processing the multi-system heterogeneous adaptation information based on a heterogeneous system adaptation engine, and generating a multi-system security baseline file through a lightweight standardized API connector and medical data standard automatic mapping technology, combined with cross-system compatibility verification and interface security hardening. The solution encompasses a comprehensive approach. It correlates standardized security baseline files with multi-system security access schemes, constructs a tiered protection system through a zero-trust security architecture, and generates a full lifecycle security protection strategy for medical data. It processes operation logs, permission change data, and workflow trajectories from the entire audit process using an abnormal behavior detection model, integrating a real-time monitoring and alarm module with an immutable blockchain audit chain to generate a dynamic security audit report. Based on a security-adaptive linkage decision engine combined with multi-dimensional compliance verification strategies, it processes the full lifecycle security protection strategy, dynamic security audit report, and multi-system security access schemes, generating a cross-system data security sharing scheme and privacy breach emergency response instructions.

[0007] According to another aspect of this application, an electronic device includes: a first processor; and a memory for storing executable instructions of the first processor; wherein the first processor is configured to execute the data security management method for smart medical information based on multi-system integration described above by executing the executable instructions.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a second processor, implements the above-described data security management method for smart medical information based on multi-system integration.

[0009] This application presents a smart healthcare information system and data security management method based on multi-system integration. The core of this method is to solve the security and compatibility issues of data interaction among heterogeneous systems such as HIS, LIS, and EMR, achieving a closed-loop security management system for the entire lifecycle of medical data. First, it acquires three key types of information: core security elements, multi-system heterogeneous compatibility (including interface specifications, data formats, etc.), and full-process auditing (including operation logs, permission changes, etc.). Next, it generates a standardized security baseline profile using AI multimodal privacy recognition, differential privacy, and blockchain evidence storage technologies. Simultaneously, it utilizes lightweight API connectors and automatic mapping technology for medical data standards to form a multi-system secure access solution. Then, it associates the baseline profile with the access solution, constructs a hierarchical protection system based on a zero-trust architecture, generates a full lifecycle security protection strategy, and combines a behavioral anomaly detection model with a blockchain audit chain to generate a dynamic security audit report. Finally, through a security-adaptation linkage decision engine and multi-dimensional compliance verification, it outputs a cross-system data security sharing solution and privacy leakage emergency response instructions. This application integrates core technologies such as AI, blockchain, and zero trust to solve the shortcomings of traditional multi-system integration, such as poor adaptability, inaccurate privacy protection, and lack of closed-loop security protection, thus ensuring the security, compliance, and efficiency of cross-system sharing of medical data.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0011] Figure 1 A flowchart illustrating a data security management method for smart medical information based on multi-system integration, provided in an embodiment of this application, is shown.

[0012] Figure 2 This illustration shows a schematic diagram of the structure of a data security management device for smart medical information based on multi-system integration, provided in an embodiment of this application. Detailed Implementation

[0013] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0014] In one implementation, Figure 1 A schematic diagram of a data security management method for smart medical information based on multi-system integration, according to an embodiment of this application, is shown.

[0015] S101, obtain core security element information, multi-system heterogeneous adaptation information, and full-process audit information.

[0016] In one implementation, core security element information serves as the foundational benchmark data for smart healthcare data security management, encompassing three core categories: medical data classification and grading labels, patient privacy-sensitive fields, and compliance policy requirements. Medical data classification and grading labels are categorized into three levels based on data sensitivity: extremely sensitive data, sensitive data, and general data. Extremely sensitive data includes patient ID numbers, core diagnostic records in medical records, and genetic testing data; sensitive data includes patient medical records and examination / test results; and general data includes hospital public service information and medical science popularization data. Patient privacy-sensitive fields include strictly confidential personal information fields such as patient name, ID number, contact information, home address, bank card number, medical insurance account number, past medical history, infectious disease diagnosis results, and reproductive health information. Compliance policy requirements must comply with relevant regulations and adapt to the HL7 / FHIR medical data standard, international medical privacy protection guidelines, and other relevant requirements, clearly defining the compliance boundaries for each stage of data collection, storage, use, transmission, and sharing.

[0017] Multi-system heterogeneous adaptation information is key data for resolving security issues in the collaboration of multiple systems such as HIS (Hospital Information System), LIS (Laboratory Information System), and EMR (Electronic Medical Record System). The HIS system uses a RESTful interface with HTTP / HTTPS protocol, with request methods including GET (data query), POST (data submission), and PUT (data update), and a JSON response format. The interface call frequency is limited to 100 times per second. The LIS system uses a TCP / IP protocol Socket interface with a data transmission baud rate of 9600bps, and the interface verification method is MD5 encryption verification. The EMR system supports a WebService interface, using the SOAP protocol to encapsulate data, and the interface authentication method is OAuth2.0 token authentication.

[0018] In the HIS system, the patient's date of birth is formatted as "YYYY-MM-DD", and the gender field uses "1 / 0" to represent "male / female"; in the LIS system, the date of birth is formatted as "DD / MM / YYYY", and the gender field uses "M / F" to represent "male / female"; in the EMR system, the date of birth is formatted as "YYYY year MM month DD day", and the gender field uses "male / female". Furthermore, the patient ID encoding rules differ between systems: the HIS system uses an 8-digit numeric code, the LIS system uses a 10-digit alphanumeric code, and the EMR system uses a 12-digit UUID code.

[0019] In regional medical collaboration scenarios, the HL7FHIRR4 protocol is used for data interaction, clearly defining the field mapping relationships for data transmission, error code definitions (e.g., "1001" indicates a data format error, and "1002" indicates a failure in authorization verification), and retransmission mechanisms (automatic retransmission within 30 seconds after a failure, with a maximum of 3 retransmissions). In cross-hospital scientific research collaboration scenarios, the SM4 encryption protocol is used to transmit sensitive data. The connection process includes identity authentication, protocol negotiation, data encryption transmission, reception and decryption, and data verification, clearly defining the timeout time for each step (the identity authentication timeout is 60 seconds) and the division of responsibilities.

[0020] Full-process audit information is the core data for achieving full traceability of medical data operations and monitoring of abnormal behavior, covering all stages of data flow. Data access operation logs record the operator's account (e.g., "doctor_001", "admin_012"), operation time (accurate to milliseconds, e.g., "2024-05-2014:30:25.123"), operation terminal information (terminal IP is "192.168.1.105", device model is "Lenovo ThinkPadX1", operating system is Windows 11), operation type (e.g., "query patient medical records", "export test reports", "modify medical records"), operation object (e.g., electronic medical records of patient ID "P20240520001", blood routine test data of patient name "Zhang San"), operation result ("success", "failure", failure reason such as "insufficient permissions" or "data does not exist"), etc.

[0021] The permission change record includes information such as the applicant for the permission change (e.g., "Department Director_Li XX"), the approver for the change (e.g., "Information Department Director_Wang XX"), the change time (e.g., "2024-05-19 09:15:30"), the permissions before the change (e.g., "Can only query patient data of this department"), the permissions after the change (e.g., "Can query patient data of this department and collaborating departments"), the reason for the permission change (e.g., "Required for cross-departmental consultation"), and the validity period of the permission (e.g., "2024-05-19 to 2024-06-19").

[0022] The cross-domain data transfer trajectory records the starting node of the data transfer (e.g., "XX City First People's Hospital HIS System"), intermediate nodes of the transfer (e.g., "Regional Medical Data Sharing Platform"), target node of the transfer (e.g., "XX City Second People's Hospital EMR System"), transfer time (e.g., "2024-05-20 15:00:00"), data type of the transfer (e.g., "patient inpatient medical record summary, examination and testing imaging data"), data transfer encryption method (e.g., "SSL / TLS1.3 encrypted transmission"), transfer verification result (e.g., "data integrity verification passed, no tampering"), and the receiving party's processing status (e.g., "received and stored" "processed and consultation opinions provided"), etc.

[0023] S102 intelligently organizes and processes core security element information, introduces AI multimodal privacy recognition algorithms and dynamic hierarchical rule engines, and combines differential privacy technology with blockchain evidence storage mechanisms to generate standardized security baseline files.

[0024] In one implementation, by comparing the attribute differences of privacy-sensitive fields, classification and grading labels, and compliance policy requirements in the core security element information, an AI multimodal privacy recognition algorithm is used to accurately extract sensitive information from text, images, and structured data. This yields patient privacy data, core medical data, and compliance constraint information. Dynamic rule engine matching and weight iteration optimization are applied to the classification and grading labels. Combined with differential privacy technology for desensitization and blockchain-based evidence storage, pre-processed single-dimensional security element data is generated. By comparing the attribute differences of the three key types of content in the core security element information, the core characteristics and adaptation boundaries of each information dimension are clarified. Privacy-sensitive fields emphasize the "confidentiality of the data itself," such as patient ID numbers and gene testing data; the core attribute is "non-disclosure." Classification and grading labels emphasize the "sensitivity level of the data," such as three levels of labels: extremely sensitive, sensitive, and general; the core attribute is "hierarchical correlation." Compliance policy requirements emphasize the "rule constraints on data processing," such as the "minimum necessary collection" requirement in the Personal Information Protection Law; the core attribute is "mandatory compliance."

[0025] Through AI-powered multimodal privacy recognition algorithms, the system comprehensively identifies textual data (such as the diagnostic description of "hepatitis B virus carrier" in electronic medical records), image data (such as ultrasound images containing the patient's face), and structured data (such as an Excel-formatted patient medical insurance payment record). This allows for the accurate extraction of patient privacy data (name, contact information, etc.), core medical data (surgical plans, pathology report conclusions, etc.), and compliance constraints (such as a data retention period not exceeding 3 years). Based on a dynamic rule engine, the initial classification and grading labels are matched with real-time updated compliance policies and clinical business needs, iteratively optimizing the label weights. For example, the "infectious disease diagnosis data" label, originally with a weight of 0.6, has had its weight adjusted to 0.9 due to newly issued epidemic prevention compliance requirements, increasing its protection priority; the "routine physical examination data" label, based on clinical usage frequency, has had its weight optimized from 0.5 to 0.3.

[0026] Differential privacy technology is used to de-identify the extracted sensitive data, de-identifying the patient's ID number "11010119900101XXXX" as "110101*******XXXX", protecting privacy while preserving the statistical value of the data. Through a blockchain notarization mechanism, the de-identified data and processing process (de-identification algorithm type, processing time "2024-05-2016:30:00") are recorded in a distributed ledger, generating an immutable notarization hash value "0x7f3e9d2b...", forming pre-processed single-dimensional security element data.

[0027] For preprocessed single-dimensional security element data, attribute alignment between privacy level and compliance requirements is performed based on medical data security standards. This aligns the element data through hierarchical classification mapping rules, generating a subset of privacy elements and a subset of compliance requirements with synchronized attributes. Based on the hierarchical standards in the *Medical Data Security Guidelines*, the "extremely sensitive" privacy level is aligned with the "prohibition of unauthorized access" and "encrypted storage" compliance requirements, clarifying that extremely sensitive data must simultaneously meet both compliance requirements. "Sensitive data" is aligned with the "authorized access" and "periodic audit" attributes to ensure traceability of access to sensitive data. Finally, "general data" is aligned with the "restricted scope of disclosure" attribute to avoid indiscriminate disclosure.

[0028] By using hierarchical classification mapping rules, the attribute-aligned element data is associated and integrated. This generates privacy element subsets, such as the "extremely sensitive privacy data subset," which includes anonymized patient genetic data, infectious disease diagnosis records, etc., with each data entry labeled with its corresponding privacy level. It also generates compliance requirement subsets, such as the "extremely sensitive data compliance subset," which includes specific rules such as "encryption storage algorithm is AES-256" and "access requires dual authorization," ensuring that each privacy element subset has a corresponding compliance requirement subset for matching constraints.

[0029] Based on attribute synchronization of privacy element subsets and compliance requirement subsets, standardized security element format processing is performed, and the trustworthiness of the archive is guaranteed by combining the immutability of blockchain to generate a standardized security baseline archive. The consistency between the privacy element subset and the compliance requirement subset is verified. For example, it checks whether all data in the "extremely sensitive privacy data subset" corresponds to the encrypted storage requirements of the "extremely sensitive data compliance subset." If a gene data item is found to be missing an encrypted storage identifier, it is determined to be inconsistent, triggering an automatic correction mechanism to add the corresponding compliance identifier. The consistency of data format is also verified, such as ensuring that the timestamp format of all data is uniformly "YYYY-MM-DDHH:MM:SS," avoiding the mixing of "2024 / 05 / 20" and "2024-05-20."

[0030] The format of the privacy element subset and the compliance requirement subset is unified into JSON format, with clear field definitions. For example, the format of extremely sensitive data entries is "{Data ID:P001, Data type: Genetic data, Privacy level: Extremely sensitive, Desensitization method: Differential privacy, Compliance requirement ID:C001, Evidence hash:0x7f3e9d2b...}"; the format of compliance requirement entries is "{Compliance requirement ID:C001, Applicable data level: Extremely sensitive, Storage requirement: AES-256 encryption, Access requirement: Two-person authorization, Retention period: 3 years}".

[0031] After integrating all verified and standardized data, and leveraging the immutability of blockchain, the entire archive is stored on a blockchain node, generating a standardized security baseline archive containing the archive version number "V1.0", the generation time "2024-05-2017:00:00", and the storage node information "node IP:192.168.2.100". The archive covers all subsets of privacy elements, subsets of compliance requirements, and related mapping relationships, providing a unified benchmark for subsequent security protection.

[0032] S103 processes heterogeneous adaptation information of multiple systems based on a heterogeneous system adaptation engine. Through lightweight standardized API connectors and automatic mapping technology of medical data standards, combined with cross-system compatibility verification and interface security hardening, it generates a secure access solution for multiple systems.

[0033] In one implementation, an adaptation mapping process is used to perform feature matching between the interface specifications and data format parameters in the heterogeneous adaptation information of multiple systems and the field definitions and protocol requirements in the medical data standards. Common adaptation fields between the system adaptation information and the standard specifications are extracted to generate a system-standard adaptation mapping table and an adaptation validity identifier. For the HIS system's RESTful interface specifications (HTTP / HTTPS protocol, JSON response format), feature matching was performed with the field definitions (e.g., the patient's "name" field is defined as "Patient.name") and protocol requirements (RESTful API interaction specifications) of the medical data standard HL7FHIR. For the LIS system's Socket interface data format parameters (birth date "DD / MM / YYYY", gender "M / F"), alignment was performed with the corresponding "Patient.birthDate" (format "YYYY-MM-DD") and "Patient.gender" (enumerated value "male / female") field features in HL7FHIR. For the EMR system's WebService interface cross-institutional interface protocol (SOAP encapsulation, OAuth2.0 authentication), matching was performed with the authentication protocol requirements and data encapsulation specifications for cross-institutional data interaction in the standard. From the above matching results, core fields common to both the system adaptation information and the standard specifications, such as "Patient ID, Name, Birth Date, Gender, and Medical Record ID," were extracted as common adaptation fields.

[0034] Generate a system-standard adaptation mapping table to clarify the correspondence between each system field and the standard field. For example, the HIS system's "Patient ID" corresponds to HL7FHIR "Patient.id", and the LIS system's "Gender (M / F)" corresponds to HL7FHIR "Patient.gender (male / female)". Mark each mapping relationship with an adaptation validity indicator. A complete match is marked as "Valid (100%)", a match that requires format conversion is marked as "Conditionally Valid (85%)", and a match without a corresponding standard field is marked as "Invalid (0%)".

[0035] By connecting to pre-defined compatibility standards and common compatibility field data, a system-standard compatibility verification model is constructed. The compatibility weight of the adapted data is determined through interface compatibility scoring logic, establishing an automated compatibility verification mechanism between heterogeneous information from multiple systems and medical data standards. Interface protocol compatibility standards are set (e.g., RESTful interfaces must support GET / POST / PUT / DELETE methods, and response latency ≤ 500ms), data format compatibility standards (e.g., date format must be uniformly "YYYY-MM-DD", encoding format must be UTF-8), and field integrity standards (common compatibility field missing rate ≤ 5%).

[0036] A system-standard adaptation verification model is constructed, comprising three core evaluation dimensions: protocol compatibility, format compatibility, and field integrity. Adaptability weights are assigned to each dimension through interface compatibility scoring logic, with protocol compatibility weighted at 0.4, format compatibility at 0.3, and field integrity at 0.3. For the HIS system, the protocol compatibility score is 95 (adaptability weight 0.4 × 0.95 = 0.38), the format compatibility score is 80 (adaptability weight 0.3 × 0.8 = 0.24), and the field integrity score is 90 (adaptability weight 0.3 × 0.9 = 0.27), resulting in a comprehensive adaptation weight of 0.89. Similarly, the comprehensive adaptation weights are calculated as follows: 0.82 for the LIS system and 0.86 for the EMR system.

[0037] Based on the above model and weights, an automated adaptation verification process is established. When the system is connected, it automatically verifies whether the interface protocol conforms to the standard, whether the data format is convertible, and whether the common fields are complete. It outputs the adaptation weight and non-compliant items in real time (such as the LIS system format compatibility not meeting the standard, prompting "the birth date format needs to be converted from DD / MM / YYYY to YYYY-MM-DD").

[0038] Using system type as the dividing dimension, a multi-dimensional system adaptation matrix is ​​constructed by integrating the corresponding adaptation information, standard mapping data, and adaptation verification results of each system. For the HIS system, its interface specification (RESTful), data format parameters (e.g., patient ID is an 8-digit number), standard mapping data ("patient number → Patient.id"), and verification results (overall adaptation weight 0.89, non-compliant items are some field formats that need to be converted) are integrated; similarly, relevant information of the LIS system (Socket interface, date format "DD / MM / YYYY", mapping data "gender M / F → male / female", verification result adaptation score 0.82) and the EMR system (WebService interface, name is full Chinese name, mapping data "medical record number → Patient.identifier", verification result adaptation score 0.86) are integrated.

[0039] Construct a multi-dimensional system adaptation matrix. The row dimension is the system type (HIS / LIS / EMR), and the column dimensions are "interface specifications, data format, standard mapping relationship, adaptation weight, and non-compliant items". The matrix clearly fills in the specific information of each system in the corresponding dimension. For example, the content of the column corresponding to the HIS system row is "RESTful interface, JSON format, patient number → Patient.id, 0.89, date format must be consistent", which intuitively presents the adaptation status and differences of each system.

[0040] Access security is enhanced through interface lightweighting optimization and security hardening mechanisms. Layered verification logic for cross-system compatibility checks strengthens the stability and security of the adaptation scheme. This is integrated with system-standard adaptation verification model features to generate a multi-system secure access scheme that includes an adaptation mapping table, verification results, and security hardening measures. The RESTful interfaces of the HIS system are lightweighted, simplifying redundant request parameters and making non-core fields optional, reducing interface response latency to within 300ms. For the Socket interfaces of the LIS system, data compression transmission technology (such as GZIP compression) is used to reduce data transmission volume. For the WebService interfaces of the EMR system, complex SOAP encapsulation is replaced with lightweight JSON format to improve interface call efficiency.

[0041] Add authentication mechanisms to all system interfaces (add JWT token verification to the RESTful interface of the HIS system, use SM4 encrypted transmission for the Socket interface of the LIS system, and strengthen OAuth2.0 permission control for the WebService interface of the EMR system); set interface access frequency limits (maximum 50 calls per second per IP); add data transmission encryption (SSL / TLS1.3) and integrity verification (MD5 checksum) mechanisms.

[0042] A layered verification logic is adopted. The first layer verifies the compatibility of the interface protocol and security mechanism; the second layer verifies the compatibility of the data format and field mapping; and the third layer verifies the stability of system linkage. This verification logic is integrated with the features of the system-standard adaptation verification model (adaptation weight, non-compliant items) to finally generate a multi-system secure access solution. The solution includes the previously generated system-standard adaptation mapping table, the adaptation verification results of each system (including adaptation weight, rectification suggestions for non-compliant items), and core content such as interface lightweight optimization parameters and security hardening configurations (such as encryption algorithm type, authentication method, access frequency threshold).

[0043] S104 associates standardized security baseline files with multi-system security access schemes, builds a hierarchical protection system through a zero-trust security architecture, and generates a full lifecycle security protection strategy for medical data.

[0044] In one implementation, a correlation and quantitative analysis is performed on the privacy grading standards and compliance constraints in the standardized security baseline file and the interface protection rules and adaptive security policies in the multi-system secure access scheme. This generates a baseline-access adaptation factor, a security level matching factor, and a compliance linkage factor. The baseline-access adaptation factor characterizes the technical compatibility between the security baseline and the system access scheme; the security level matching factor characterizes the adaptability between the privacy grading and the access protection strength; and the compliance linkage factor characterizes the synergistic compliance between compliance requirements and cross-system access rules. The key content of the standardized security baseline file and the multi-system secure access scheme is correlated and quantified to clarify the specific values ​​and meanings of the three types of factors. In the standardized security baseline file, the privacy grading standards include three levels: "extremely sensitive," "sensitive," and "general." The compliance constraints include "encrypted storage, dual-authorized access, and 3-year data retention." In the multi-system secure access scheme, the interface protection rules include "JWT token verification, SM4 encrypted transmission, and access frequency restriction," and the adaptive security policies include "differentiated protection based on system type and hardening of cross-organizational data transmission protocols."

[0045] Through technical compatibility assessment, the encrypted storage requirements of highly sensitive data are fully compatible with the SM4 encrypted transmission technology of the LIS system's Socket interface, the authorized access requirements of sensitive data are compatible with the JWT token verification technology of the HIS system's RESTful interface, and the public scope restrictions of general data are compatible with the interface access control policy of the EMR system. The baseline-access compatibility factor is calculated to be 0.92 (within the range of 0-1, the closer to 1, the stronger the compatibility).

[0046] Extremely sensitive data requires the highest level of protection, corresponding to the high-strength protection of "SM4 encryption + dual authorization" in the access solution, with a 100% match rate; sensitive data corresponds to "JWT verification + access frequency restriction," with a 90% match rate; general data corresponds to "basic interface authentication," with an 85% match rate. The weighted calculation yields a security level matching factor of 0.91 (weighting is allocated according to data volume: extremely sensitive 30%, sensitive 50%, general 20%). The compliance requirements of "encrypted data transmission" are fully coordinated with the "SSL / TLS 1.3 transmission encryption" in the cross-system access rules; "access auditing" is coordinated with the "operation log retention" in the access solution; and "privacy desensitization" is coordinated with the "data preprocessing mechanism" during access. The compliance verification yields a compliance linkage factor of 0.93.

[0047] Based on the baseline-access adaptation factor, security level matching factor, and compliance linkage factor, the graded protection standards in the security baseline file and the interface hardening strategies and adaptation security mechanisms in the multi-system security access scheme are integrated to generate a quantitative correlation and protection strategy integration scheme. The baseline-access adaptation factor (0.92) serves as the technical foundation to ensure the feasibility of the integration scheme; the security level matching factor (0.91) serves as the strength basis to ensure that the protection strength matches the data sensitivity level; and the compliance linkage factor (0.93) serves as the compliance baseline to ensure that all integration strategies comply with policy requirements.

[0048] For extremely sensitive data, a triple protection of "proof storage-encryption-authorization" is formed by integrating "blockchain evidence preservation (from the security baseline) + SM4 encrypted transmission (from the access solution) + dual-authorization access (from the security baseline)". For sensitive data, a combined protection of "de-identification-verification-rate limiting" is formed by integrating "differential privacy de-identification (from the security baseline) + JWT token verification (from the access solution) + access frequency restriction (from the access solution)". For general data, a basic protection of "standardization-authentication" is formed by integrating "format standardization processing (from the security baseline) + basic interface authentication (from the access solution)". Finally, a quantitative correlation and protection strategy integration scheme is generated, which clarifies the technical combination, execution order and quantitative indicators of each level of protection (such as encryption strength ≥ 256 bits, authorization response time ≤ 1 second).

[0049] Based on the cross-domain sharing needs and real-time access frequency in medical data flow scenarios, the baseline-access adaptation factor, security level matching factor, and compliance linkage factor are dynamically adjusted to generate rules for the association and fusion of scenario requirements and quantitative factors. Cross-domain sharing needs include inter-institutional consultation data sharing and research data collaboration; real-time access frequency includes high-frequency access in outpatient clinics and low-frequency queries in chronic disease management. In the inter-institutional consultation data sharing scenario, the cross-domain transmission demand is high, requiring an increase in the compliance linkage factor (adjusted from 0.93 to 0.96) to ensure cross-institutional access meets collaborative compliance requirements. In the research data collaboration scenario, the data interaction frequency is low but the sensitivity is high, requiring an increase in the security level matching factor (adjusted from 0.91 to 0.95) to strengthen protection. In the high-frequency outpatient clinic access scenario, the real-time access frequency is high (≥30 times per second), requiring an increase in the baseline-access adaptation factor (adjusted from 0.92 to 0.94) to ensure technical compatibility and smooth access. In the low-frequency chronic disease management query scenario, the access frequency is low (≤5 times per day), maintaining the root cause value balances protection and efficiency.

[0050] The rules for linking and integrating scenario requirements with quantitative factors are defined, specifying that "high cross-domain sharing requirements → compliance linkage factor ≥ 0.95", "scientific research collaboration scenarios → security level matching factor ≥ 0.94", "high-frequency access scenarios → baseline-access adaptation factor ≥ 0.93", and "low-frequency query scenarios → the three types of factors maintain the baseline value". At the same time, the triggering conditions for factor adjustment (such as automatically triggering the upward adjustment of compliance linkage factor when the amount of cross-domain shared data ≥ 100) and the adjustment range (a single adjustment shall not exceed 0.05) are specified.

[0051] This paper integrates and optimizes the fusion scheme of quantitative correlation and protection strategies, as well as the fusion rules of scenario requirements and quantitative factors. Combining the continuous authentication and least privilege principles of the zero-trust security architecture, a full lifecycle security protection strategy for medical data is generated. Based on the fusion scheme of quantitative correlation and protection strategies, scenario requirements and quantitative factor association rules are embedded to ensure the strategy adapts to different scenarios. In conjunction with the "continuous authentication and least privilege" principles of the zero-trust architecture, mechanisms such as dynamic verification and dynamic permission adjustment are added to compensate for the limitations of fixed protection.

[0052] During the data acquisition phase, "sensitive information identification (from the security baseline) + interface authentication access (from the access solution) + real-time compliance verification (from scenario rules)" is implemented, and the identity of the acquisition terminal is continuously verified according to the zero-trust principle. During the data storage phase, "tiered encrypted storage (from the converged solution) + blockchain evidence storage (from the security baseline)" is implemented, and only the minimum permissions required for storage management are granted. During the data transmission phase, the protection strength is dynamically adjusted according to scenario rules (such as enabling SM4 encryption + SSL / TLS1.3 dual encryption for consultation data transmission), and the identity of the transmission node is continuously verified throughout the process. During the data usage phase, "least privilege authorization (from zero trust) + access behavior auditing (from the access solution)" is followed. Non-core verification processes are automatically simplified in high-frequency access scenarios, and multi-dimensional verification is strengthened in low-frequency, high-sensitivity scenarios. During the data destruction phase, "blockchain evidence storage cancellation (from the security baseline) + interface access permission revocation (from the access solution)" is implemented to ensure that the data is completely destroyed and traceable. Finally, a medical data security protection strategy covering the entire lifecycle of "acquisition-storage-transmission-use-destruction" is formed, which clarifies the protection measures, responsible parties, quantitative indicators, and scenario adaptation logic for each stage.

[0053] S105 processes the operation logs, permission change data, and flow trajectory in the full-process audit information in conjunction with the behavior anomaly detection model, integrates the real-time monitoring and alarm module with the blockchain tamper-proof audit chain, and generates a dynamic security audit report.

[0054] In one implementation, a behavioral feature extraction algorithm is used to deeply analyze the operation logs, permission change data, and workflow trajectories in the full-process audit information to generate preset behavioral feature baseline rules and anomaly judgment threshold ranges. The operation behavior of the "doctor account (doctor_001)" in the operation log is analyzed to extract its daily operation time patterns (e.g., weekdays 8:00-18:00), operation type proportions (medical record queries 80%, treatment record modifications 15%, data exports 5%), and access terminal consistency (common IP "192.168.1.105", device model "Lenovo ThinkPadX1"). Permission change data is analyzed to extract the regular cycle of permission adjustments (e.g., centralized adjustments on the 5th of each month) and approval process time (average 24 hours). Cross-domain workflow trajectories are analyzed to extract regular workflow paths (e.g., "XX City First People's Hospital HIS System → Regional Medical Data Sharing Platform") and the proportion of workflow data types (outpatient data 60%, inpatient data 40%).

[0055] Based on the analysis results, baseline rules are generated, including: "Operation time: Weekdays 8:00-18:00, non-working hours operation rate ≤10%", "Operation type: Doctor account data export rate ≤8%", "Permission change: Approval process time ≤48 hours", and "Cross-domain transfer: Only allowed to transfer to registered regional sharing platforms". Abnormal thresholds are set, such as "Non-working hours operation rate >10%", "Single data export volume >50 records (normally ≤20 records per export)", "Permission change approval time >48 hours", and "Data transfer to unregistered nodes", forming anomaly judgment threshold ranges.

[0056] By integrating with the medical data security operation specification library and audit information data, behavioral audit benchmarks are constructed. Compliance judgment rules for different operational behaviors are determined through feature matching logic. Simultaneously, an abnormal behavior detection model is introduced, combining deep learning algorithms with behavioral profiles of medical business scenarios to establish a dynamic analysis mechanism for audit-detection collaboration. In line with relevant provisions of the "Medical Data Security Operation Specifications" and the "Personal Information Protection Law," behavioral audit benchmarks are constructed, clearly defining core benchmark requirements such as "prohibition of unauthorized export of sensitive patient data," "requiring dual approval for permission changes," and "encrypted transmission and retention of data tracking for cross-domain transfers."

[0057] By using feature matching logic, audit information is correlated with benchmark requirements to formulate judgment rules, such as "exporting" behavior in the operation log is not associated with authorization approval records → judged as non-compliant," "data on permission changes lacks approver signatures → judged as non-compliant," and "cross-domain transfer trajectory does not record encryption methods → judged as non-compliant." A deep learning-based behavior anomaly detection model is introduced, combined with medical business scenario profiles (such as differentiated operation profiles for outpatient doctors, researchers, and administrative staff). The model automatically optimizes the detection logic by learning from historical compliant / non-compliant behavior data. For example, for researcher accounts, they are allowed to export anonymized research data in batches, while batch exports from doctor accounts trigger an alert, forming a collaborative mechanism of "audit benchmark verification + AI model intelligent detection."

[0058] Using data operation type as the coverage dimension, this system integrates log data, permission change records, and workflow trajectories corresponding to different operation types. Combined with behavioral characteristic baseline rules and anomaly judgment thresholds, it achieves precise definition of the objects processed by the entire process audit information. Data operation types are divided into six categories: "query, modification, export, deletion, cross-domain transfer, and permission change." For "export" operations, it integrates information such as export time, exported data volume, and exporting account from the operation log; account permission level from the permission change record; and the destination of exported data from the workflow trajectories. For "cross-domain transfer" operations, it integrates information such as the initiating node, target node, data type, and encryption method.

[0059] The fused data is filtered by combining baseline rules for behavioral characteristics with anomaly thresholds. For example, "doctor account doctor_002 exported 30 complete patient medical records at 23:00 (exceeding the threshold of 20 records)," "transferring data across domains to an unregistered research institution," and "permission changes taking effect before the approval process was completed" are all identified as key audit targets. However, "doctor account doctor_001 queried 5 patient medical records from their department at 10:00" meets the baseline rules and is excluded from the key audit scope.

[0060] Audit information is integrated through log anonymization and data association preprocessing mechanisms. This, combined with a behavioral anomaly detection model, enhances the accuracy of abnormal behavior identification. Real-time monitoring and alarm modules trigger warnings for violations. Furthermore, the immutable audit chain of blockchain, combined with the dynamism of real-time monitoring, generates a dynamic security audit report with abnormal behavior identifiers, warning records, and traceability links. Sensitive fields such as patient ID numbers and mobile phone numbers in the audit information are anonymized (e.g., "11010119900101XXXX"). Data association is established, linking accounts in operation logs with account permissions in permission change records and operational behaviors in workflow traces, forming a complete data chain of "account-permission-operation-trajectory." The behavioral anomaly detection model analyzes the preprocessed associated data to accurately identify abnormal behaviors such as "login operations from other locations after account theft" and "modification of patient medical records beyond authorized permissions." The real-time monitoring and alarm module simultaneously triggers warnings, notifying administrators via SMS and system pop-ups. Warning information includes core information such as the type of abnormal behavior, time of occurrence, operating account, and terminal IP.

[0061] Integrating the immutable audit chain characteristics of blockchain, the report records the complete trajectory of abnormal behavior (such as operation initiation time, terminal information, data flow path), early warning records (early warning trigger time, processing status), and tracing links (blockchain evidence hash value "0x8a7b6c..."). The report updates the abnormal behavior processing progress in real time, such as "2024-05-21 09:30 detected excessive export behavior → 09:35 triggered early warning → 10:00 administrator verified as misoperation → 10:10 marked processing result", ultimately generating a dynamic security audit report with abnormal behavior identifiers, early warning records, and tracing links.

[0062] S106, based on a security-adaptation linkage decision engine and multi-dimensional compliance verification strategies, processes full lifecycle security protection strategies, dynamic security audit reports, and multi-system security access schemes to generate cross-system data security sharing schemes and privacy leakage emergency response instructions.

[0063] In one implementation, the hierarchical protection rules in the full lifecycle security protection strategy, the abnormal early warning information in the dynamic security audit report, and the adaptive security mechanisms in the multi-system security access scheme are prioritized and their effectiveness verified. This generates protection strategy weight allocation results, audit abnormality risk level labels, and access scheme adaptation compliance ratings, forming basic data for decision input preprocessing. Regarding the tiered protection rules, ranked in the order of "encrypted storage of extremely sensitive data," "authorized access to sensitive data," and "general data access control," the effectiveness of the "SM4 encrypted storage of extremely sensitive data" rule in multiple systems was verified to be 98%, and the effectiveness of "JWT authorized access to sensitive data" was 95%. Regarding the abnormal warnings in the dynamic security audit report, ranked in the risk priority order of "excessive export of sensitive patient data," "remote login operation," and "permission change approval timeout," the accuracy rate of the "excessive export" warning was verified to be 99%, and the accuracy rate of the "remote login" warning was 96%. Regarding the adapted security mechanisms, ranked in the importance order of "SM4 encrypted transmission of interfaces," "JWT token verification," and "access frequency restriction," the effectiveness of "SM4 encrypted transmission" in the LIS system was verified to be 97%, and the effectiveness of "JWT verification" in the HIS system was 94%.

[0064] The system generates the following protection strategy weight allocation results: "Encrypted storage of extremely sensitive data" weight 0.4, "Authorized access to sensitive data" weight 0.3, "General data access control" weight 0.2, and "Cross-domain transmission encryption" weight 0.1; it also generates audit anomaly risk level labels: "Excessive export" is labeled "High risk", "Login from other locations" is labeled "Medium risk", and "Approval timeout" is labeled "Low risk"; and it generates access scheme adaptation compliance ratings: "Interface SM4 encryption" is rated "A level (97 points)", "JWT token verification" is rated "B level (94 points)", and "Access frequency restriction" is rated "B level (92 points)", ultimately forming the basic data for decision input preprocessing.

[0065] The compliance dimensions and verification standards in the multi-dimensional compliance verification strategy are adapted and calibrated, and compliance thresholds are defined. This generates compliance dimension weight parameters, security compliance level classification standards, and risk emergency response thresholds, forming compliance verification constraint information. The multi-dimensional compliance verification dimensions include "data encryption compliance," "authorization process compliance," "audit retention compliance," and "cross-domain sharing compliance." Combining medical data security regulations and industry standards, the weights are set as follows: "data encryption compliance" 0.35, "authorization process compliance" 0.3, "audit retention compliance" 0.2, and "cross-domain sharing compliance" 0.15. Security compliance level classification standards are defined: Level A (90-100 points) is fully compliant, Level B (80-89 points) is basically compliant, Level C (70-79 points) is slightly non-compliant, and Level D (<70 points) is seriously non-compliant. Risk emergency response thresholds are set: high-risk anomaly trigger response time ≤10 minutes, medium-risk anomaly ≤30 minutes, and low-risk anomaly ≤2 hours. Generate a compliance dimension weight parameter table, clarifying the weight and verification indicators for each dimension; generate a security compliance level classification standard description, clarifying the compliance requirements and rectification directions corresponding to each level; generate a risk emergency response threshold list, clarifying the response time limits and processing procedures for different risk levels, forming compliance verification constraint information.

[0066] The security-adaptation linkage decision engine synchronizes and correlates cross-system interaction data and multi-dimensional compliance verification results to generate system-linked security features, compliance verification trend indicators, and policy-audit-access consistency verification results, forming multi-source decision fusion information. It synchronizes cross-system interaction data between the HIS and EMR systems, including data transmission type (medical record data, test results), transmission frequency (500 times per day), and encryption method (SSL / TLS 1.3); and correlates compliance verification results, achieving a 98% pass rate for "cross-domain transmission encryption compliance," a 95% pass rate for "authorization process compliance," and a 93% pass rate for "audit retention compliance." Extract system-wide security features, such as "all cross-domain transmission of highly sensitive data uses SM4+SSL dual encryption" and "all authorized accesses pass JWT token verification." Generate compliance verification trend indicators: in the past 30 days, the pass rate for "cross-domain sharing compliance" has increased from 92% to 98%, and the pass rate for "permission change compliance" has remained stable at 95%. Generate policy-audit-access consistency verification results: the consistency between "highly sensitive data encryption policy" and "SM4 encryption access mechanism" for "encryption compliance verification" reaches 99%, and the consistency between "authorized access policy" and "JWT verification mechanism" for "authorization compliance verification" reaches 96%. Integrate the above features, indicators, and verification results to form multi-source decision fusion information, clarifying the security advantages (dual encryption, high authorization verification pass rate), compliance trends (steady increase in pass rate), and consistency status (high consistency between policy and mechanism, and verification).

[0067] By integrating preprocessed basic data for decision input, compliance verification constraint information, and multi-source decision fusion information, and combining the intelligent inference logic of the security-adaptive linkage decision engine, cross-system data sharing permission configuration, security compliance achievement conclusions, and privacy leakage risk handling paths are generated, forming a cross-system data security sharing scheme and privacy leakage emergency response instructions with a sharing permission matrix and emergency response flowchart. The security-adaptive linkage decision engine combines weight allocation, compliance standards, and integrated information deduction to generate cross-system data sharing permission configurations, clearly defining that "extremely sensitive data (such as gene data) can only be accessed by the chief physician of this hospital and authorized physicians of collaborating hospitals," "sensitive data (such as medical records) can be accessed by medical staff of this hospital and registered researchers," and "general data (such as popular science information) can be publicly accessed." It generates a security compliance conclusion, currently achieving a compliance level of "Level A (95.2 points)" in multi-system integration scenarios, fully complying with the Data Security Law, the Personal Information Protection Law, and medical data security standards. It generates privacy leakage risk handling paths, clearly defining the handling process for "high-risk leakage (such as excessive export of sensitive data)": triggering an alarm → locking the operating account → tracing the data flow → notifying relevant users → reporting to regulatory authorities; and the handling process for "medium-risk leakage (such as logging in from a different location without operating on sensitive data)": triggering an alarm → verifying the operator's identity → forcibly logging off the account → resetting the login password → recording audit logs.

[0068] A cross-system data security sharing scheme is formed, which includes a shared permission matrix and an emergency response flowchart. The matrix clearly defines the access subjects, authorization processes and encryption requirements for different data types, and the flowchart intuitively presents the handling steps and responsible parties for different risk levels. At the same time, privacy leakage emergency response instructions are generated, including instruction number, triggering conditions, execution steps, responsible department and response time limit, such as "Emergency Instruction 001: Export excessive sensitive data (high risk) → Lock account within 10 minutes → Trace data flow within 2 hours → Report to regulatory authorities within 4 hours".

[0069] In one implementation, such as Figure 2 As shown, this application also provides a data security management device for smart medical information based on multi-system integration, comprising:

[0070] The acquisition module 201 is used to acquire core security element information, multi-system heterogeneous adaptation information, and full-process audit information.

[0071] Processing module 202 is used to intelligently organize and process core security element information, introduce AI multimodal privacy recognition algorithms and dynamic hierarchical rule engines, and combine differential privacy technology and blockchain evidence storage mechanisms to generate standardized security baseline files. Based on the heterogeneous system adaptation engine, it processes heterogeneous adaptation information of multiple systems, and generates multi-system secure access solutions through lightweight standardized API connectors and medical data standard automatic mapping technology, combined with cross-system compatibility verification and interface security hardening. It correlates the standardized security baseline files and multi-system secure access solutions, builds a hierarchical protection system through a zero-trust security architecture, and generates a full lifecycle security protection strategy for medical data. It processes operation logs, permission change data, and flow trajectories in the full-process audit information in combination with a behavior anomaly detection model, integrates a real-time monitoring and alarm module with a blockchain tamper-proof audit chain, and generates dynamic security audit reports. Based on the security-adaptation linkage decision engine and multi-dimensional compliance verification strategies, it processes the full lifecycle security protection strategy, dynamic security audit reports, and multi-system secure access solutions to generate cross-system data security sharing solutions and privacy leakage emergency response instructions.

[0072] The computer-readable storage medium provided in the above embodiments of this application and the data security management method for smart medical information based on multi-system integration provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0073] The various embodiments in this application are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for evaluating the data security management method, electronic device, electronic device, and readable storage medium for smart medical information based on multi-system integration are relatively simple to describe because they are substantially similar to the embodiments of the data security management method for smart medical information based on multi-system integration described above. Relevant parts can be referred to the descriptions of the embodiments of the data security management method for smart medical information based on multi-system integration described above.

Claims

1. A data security management method for smart medical information based on multi-system integration, characterized in that, include: Acquire core security element information, multi-system heterogeneous adaptation information, and full-process audit information. Core security element information includes medical data classification and grading labels, patient privacy sensitive fields, and compliance policy requirements. Multi-system heterogeneous adaptation information includes HIS / LIS / EMR system interface specifications, data format difference parameters, and cross-institutional docking protocols. Full-process audit information includes data access operation logs, permission change records, and cross-domain transfer trajectories. The core security element information is intelligently organized and processed, and an AI multimodal privacy recognition algorithm and dynamic hierarchical rule engine are introduced. Combined with differential privacy technology and blockchain evidence storage mechanism, a standardized security baseline file is generated. Based on the heterogeneous system adaptation engine, the heterogeneous adaptation information of multiple systems is processed. Through lightweight standardized API connectors and medical data standard automatic mapping technology, combined with cross-system compatibility verification and interface security hardening, a multi-system secure access solution is generated. This process correlates standardized security baseline files with multi-system secure access solutions, constructs a tiered protection system through a zero-trust security architecture, and generates a full lifecycle security protection strategy for medical data. This includes quantitative analysis of the correlation between privacy grading standards and compliance constraints in the standardized security baseline files and interface protection rules and adaptive security strategies in multi-system secure access solutions. This generates baseline-access adaptation factors, security level matching factors, and compliance linkage factors. The baseline-access adaptation factor characterizes the technical compatibility between the security baseline and the system access solution; the security level matching factor characterizes the compatibility between privacy grading and access protection strength; and the compliance linkage factor characterizes the synergistic compliance between compliance requirements and cross-system access rules. Based on these factors, security... The baseline archive's tiered protection standards are integrated with the interface hardening strategies and adaptation security mechanisms in the multi-system secure access scheme to generate a quantitative correlation and protection strategy fusion scheme. Based on the cross-domain sharing needs and real-time access frequency in medical data flow scenarios, the baseline-access adaptation factor, security level matching factor, and compliance linkage factor are dynamically adjusted to generate scenario requirements and quantitative factor correlation and fusion rules. Cross-domain sharing needs include inter-institutional consultation data sharing and scientific research data collaboration, while real-time access frequency includes high-frequency access for outpatient treatment and low-frequency queries for chronic disease management. The quantitative correlation and protection strategy fusion scheme and the scenario requirements and quantitative factor correlation and fusion rules are integrated and optimized, and combined with the continuous authentication and least privilege principle of the zero-trust security architecture, a full lifecycle security protection strategy for medical data is generated. The operation logs, permission change data and flow trajectory in the full-process audit information are processed in combination with the behavior anomaly detection model, and the real-time monitoring and alarm module is integrated with the blockchain tamper-proof audit chain to generate dynamic security audit reports. Based on a security-adaptation linkage decision engine combined with multi-dimensional compliance verification strategies, the system processes full lifecycle security protection strategies, dynamic security audit reports, and multi-system security access solutions to generate cross-system data security sharing solutions and privacy leakage emergency response instructions.

2. The method of claim 1, wherein, The core security information is intelligently organized and processed, incorporating AI multimodal privacy recognition algorithms and dynamic hierarchical rule engines. Combined with differential privacy technology and blockchain evidence storage mechanisms, a standardized security baseline profile is generated, including: By comparing the differences in attributes of privacy-sensitive fields, classification and grading labels, and compliance policy requirements in the core security element information, the AI ​​multimodal privacy recognition algorithm is used to accurately extract sensitive information from text, images, and structured data to obtain patient privacy data, core medical data, and compliance constraint information. Dynamic rule engine matching and weight iteration optimization are implemented for classification and grading labels. Combined with differential privacy technology for desensitization and blockchain notarization, preprocessed single-dimensional security element data is generated. For the preprocessed single-dimensional security element data, attribute alignment of privacy level and compliance requirements is performed based on medical data security standards. The aligned element data is then associated through hierarchical classification mapping rules to generate a privacy element subset and a compliance requirement subset with synchronized attributes. Based on a subset of privacy elements and a subset of compliance requirements synchronized with attributes, standardized security baseline archives are generated by verifying data consistency, standardizing security element formats, and combining the immutability of blockchain to ensure the credibility of the archives.

3. The method as described in claim 1, characterized in that, Based on a heterogeneous system adaptation engine, multi-system heterogeneous adaptation information is processed. Through lightweight standardized API connectors and automatic mapping technology for medical data standards, combined with cross-system compatibility verification and interface security hardening, a multi-system secure access solution is generated, including: The adaptation mapping process performs feature matching between the interface specifications and data format parameters in the heterogeneous adaptation information of multiple systems and the field definitions and protocol requirements in the medical data standards. It extracts the common adaptation fields between the system adaptation information and the standard specifications, and generates a system-standard adaptation mapping table and an adaptation validity identifier. By connecting to the pre-defined compatibility standards and common compatibility field data, a system-standard compatibility verification model is constructed. The compatibility weight of the compatibility data is determined through interface compatibility scoring logic, and an automated compatibility verification mechanism for heterogeneous information from multiple systems and medical data standards is established. Based on system type as the dividing dimension, the system adaptation information, standard mapping data and adaptation verification results of each system are integrated to construct a multi-dimensional system adaptation matrix. By optimizing lightweight interfaces and strengthening security mechanisms, access security is enhanced. The stability and security of the adaptation scheme are strengthened by combining layered verification logic for cross-system compatibility verification. The scheme is integrated with the features of the system-standard adaptation verification model to generate a multi-system secure access scheme with an adaptation mapping table, verification results and security strengthening measures.

4. The method of claim 1, wherein, The operation logs, permission change data, and workflow traces in the full-process audit information are processed using a behavior anomaly detection model. This is combined with a real-time monitoring and alarm module and a blockchain-based immutable audit chain to generate a dynamic security audit report, including: By using behavioral feature extraction algorithms, the operation logs, permission change data and flow trajectory in the full-process audit information are deeply analyzed to generate preset behavioral feature baseline rules and anomaly judgment threshold ranges. By connecting the medical data security operation specification library with audit information data, a behavioral audit benchmark is constructed. The compliance judgment rules for different operational behaviors are determined through feature matching logic. At the same time, a behavioral anomaly detection model is introduced. Combined with deep learning algorithms and behavioral profiles of medical business scenarios, a dynamic analysis mechanism for audit-detection collaboration is established. Using data operation type as the coverage dimension, it integrates log data, permission change records and flow trajectory corresponding to different operation types, and combines behavioral characteristic baseline rules and anomaly judgment thresholds to achieve accurate definition of the audit information processing objects of the whole process; By integrating audit information through log anonymization and data association preprocessing mechanisms, and combining it with a behavior anomaly detection model to enhance the accuracy of abnormal behavior identification, while relying on a real-time monitoring and alarm module to trigger warnings of violations, and further integrating the traceability characteristics of the blockchain's immutable audit chain with the dynamism of real-time monitoring, a dynamic security audit report with abnormal behavior identifiers, warning records, and traceability links is generated.

5. The method of claim 4, wherein, Based on a security-adaptation linkage decision engine combined with multi-dimensional compliance verification strategies, the system processes full lifecycle security protection strategies, dynamic security audit reports, and multi-system security access solutions to generate cross-system data security sharing schemes and privacy breach emergency response instructions, including: Prioritize and verify the effectiveness of the hierarchical protection rules in the full lifecycle security protection strategy, the abnormal early warning information in the dynamic security audit report, and the adaptive security mechanisms in the multi-system security access scheme. Generate protection strategy weight allocation results, audit abnormality risk level labels, and access scheme adaptation compliance ratings to form the basic data for decision input preprocessing. The compliance dimensions and verification standards in the multi-dimensional compliance verification strategy are adapted and calibrated, and compliance thresholds are defined. Compliance dimension weight parameters, security compliance level classification standards, and risk emergency response thresholds are generated to form compliance verification constraint information. The cross-system interaction data and multi-dimensional compliance verification results collected by the security-adaptation linkage decision engine are synchronized and feature-correlated to generate system linkage security features, compliance verification trend indicators, and policy-audit-access consistency verification results, forming multi-source decision fusion information. By integrating preprocessed basic data for decision input, compliance verification constraint information, and multi-source decision fusion information, and combining the intelligent inference logic of the security-adaptive linkage decision engine, cross-system data sharing permission configuration, security compliance achievement conclusions, and privacy leakage risk handling paths are generated, forming a cross-system data security sharing scheme and privacy leakage emergency response instructions with a sharing permission matrix and emergency response flowchart. 6.A data security management device for intelligent medical information based on multi-system integration, characterized in that, The apparatus for implementing the method of claim 1 includes: The acquisition module is used to acquire core security element information, multi-system heterogeneous adaptation information, and full-process audit information. The processing module intelligently organizes and processes core security element information, introducing AI multimodal privacy recognition algorithms and dynamic hierarchical rule engines, combined with differential privacy technology and blockchain evidence storage mechanisms to generate standardized security baseline files. Based on a heterogeneous system adaptation engine, it processes heterogeneous adaptation information from multiple systems, generating multi-system secure access solutions through lightweight standardized API connectors and automatic mapping technology for medical data standards, combined with cross-system compatibility verification and interface security hardening. It correlates the standardized security baseline files with multi-system secure access solutions, constructing a hierarchical protection system through a zero-trust security architecture to generate a full lifecycle security protection strategy for medical data. It processes operation logs, permission change data, and flow trajectories in the full-process audit information using a behavioral anomaly detection model, integrating a real-time monitoring and alarm module with an immutable blockchain audit chain to generate dynamic security audit reports. Based on a security-adaptation linkage decision engine combined with multi-dimensional compliance verification strategies, it processes the full lifecycle security protection strategy, dynamic security audit reports, and multi-system secure access solutions to generate cross-system data security sharing schemes and privacy leakage emergency response instructions.

7. An electronic device, comprising: include: First processor; and memory for storing executable instructions of the first processor; The first processor is configured to execute the data security management method for smart medical information based on multi-system integration as described in any one of claims 1 to 5 by executing the executable instructions.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by the second processor, it implements the data security management method for smart medical information based on multi-system integration as described in any one of claims 1 to 5.

Images