Full-process intelligent hospital convenient service health data closed-loop management method and system

Abstract

This invention belongs to the technical field of closed-loop management methods for health data in hospital convenience services, and particularly relates to a method and system for closed-loop management of health data in smart hospital convenience services throughout the entire process. It constructs a full-domain identity binding system based on blockchain technology, configuring identifiers and dynamic attribute tags for health data and assigning digital identity certificates to terminals / systems / roles; relying on a distributed graph database and tracking framework, it deploys a lightweight data collection agent and constructs a federated dynamic lineage graph based on medical parsing rules; it establishes a multi-dimensional operation traceability mechanism, expanding the collection of behavioral fingerprints and operation context data beyond regular logs, and adopts a dual-mode storage approach of blockchain evidence storage and local encrypted backup; it constructs an AI intelligent audit engine, transforming regulations into an audit rule base through a large language model, and combining unsupervised learning modeling to identify abnormal operations in medical scenarios.

Description

Technical Field

[0001] This invention belongs to the technical field of closed-loop management methods for health data in hospital public services, and particularly relates to a closed-loop management method and system for health data in smart hospital public services throughout the entire process. Background Technology

[0002] Currently, smart hospital services cover the entire process from pre-hospital screening, in-hospital diagnosis and treatment, to post-hospital follow-up. Health data is characterized by multi-terminal collection, multi-system flow, and cross-institutional collaboration. Existing management models generally suffer from the lack of binding between data identity and subject identity, and imperfect full-link identity verification mechanisms. When health data flows between self-service machines, mobile terminals, HIS / EMR and other systems, it is difficult to achieve unified association of data identification, equipment, system, and operation role. At the same time, data lineage tracing relies on centralized collection and static recording, which cannot be adapted to distributed business architecture. After data is forwarded by multiple nodes and converted in format, lineage breaks are likely to occur, making it difficult to accurately trace the original source and flow trajectory.

[0003] With the implementation of Cybersecurity Law 2.0, the Personal Information Protection Law, and the Medical Data Security Management Standards, the requirements for compliance control and operational auditing of health data are continuously increasing. Traditional auditing models rely on manual rules and post-event verification, lacking the ability to intelligently identify abnormal operations in medical scenarios. Operation traces only cover regular logs, without collecting behavioral fingerprints and operational contexts, making it impossible to fully reconstruct operational behavior. Furthermore, the lack of unified audit interfaces across systems and the fragmented source tracing and evidence collection capabilities make it difficult to quickly locate the responsible party for data security incidents. At the same time, the system cannot be dynamically optimized with business iterations and regulatory updates, making it difficult to form a closed-loop process for health data management, resulting in prominent compliance risks and security vulnerabilities. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a closed-loop management method for health data in a smart hospital providing convenient services throughout the entire process, the method comprising: A comprehensive identity binding system is built based on blockchain technology, which involves configuring identifiers and dynamic attribute tags for health data and assigning digital identity certificates to terminals / systems / roles. Based on a distributed graph database and tracking framework, a lightweight data collection agent is deployed, and a federated dynamic kinship graph is constructed by combining medical analysis rules. Establish a multi-dimensional operation traceability mechanism, expand the collection of behavioral fingerprints and operation context data beyond regular logs, and adopt a dual-mode storage of blockchain evidence storage and local encrypted backup. Build an AI-powered intelligent audit engine that transforms regulations into an audit rule base using a large language model and combines unsupervised learning modeling to identify abnormal operations in medical scenarios. Establish a cross-system collaborative traceability and evidence collection platform, connect multi-terminal / system audit interfaces, and link kinship tracing and operation trace data; Establish a compliance self-adaptive dynamic optimization mechanism, and continuously optimize the traceability audit link by updating the audit model through federated learning, automatic compliance detection, and traceability drills to adapt to changes in business and regulations.

[0005] Furthermore, embodiments of the present invention also provide a closed-loop management system for health data in a smart hospital, characterized in that it includes: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the aforementioned closed-loop management method for health data of smart hospital public services by executing the machine-executable instructions.

[0006] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, the processor of a computer device reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the computer device to execute the above-described closed-loop management method for health data of smart hospital convenience services.

[0007] Based on the above, by using blockchain-based full-domain identity binding and a federated data lineage dynamic graph, a strong binding and traceability of the entire chain of health data, terminals, systems, and operating roles is achieved. This completely solves the problems of missing identity verification and broken lineage in multi-terminal and cross-system data flow. It can accurately trace the original source and flow trajectory of data after being forwarded and converted by multiple nodes, significantly improving the manageability, controllability, and accuracy of data flow. This invention relies on multi-dimensional operation traceability, AI intelligent auditing, and judicial-grade electronic evidence collection to achieve full-dimensional restoration of operational behavior and automatic identification of abnormal operations in medical scenarios. This effectively reduces the false alarm rate of audits and the cost of manual verification. At the same time, through a compliance self-adaptive dynamic optimization mechanism, it continuously iterates and upgrades to ensure that the system keeps up with business and regulatory updates, forming a closed loop of the entire process of health data collection, flow, auditing, traceability, and optimization, significantly improving the level of health data security control and compliance management in smart hospitals. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the execution flow of the closed-loop management method for health data in a smart hospital providing convenient services throughout the entire process, as provided in this embodiment of the invention.

[0009] Figure 2 This is a schematic diagram of exemplary hardware and software components of the closed-loop management system for health data in a smart hospital providing convenient services throughout the entire process, as provided in this embodiment of the invention. Detailed Implementation

[0010] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a method for closed-loop management of health data for smart hospital services provided in an embodiment of the present invention. The following is a detailed description of this method.

[0011] Step S110: Construct a full-domain identity binding system based on blockchain technology by configuring identifiers and dynamic attribute tags for health data and assigning digital identity certificates to terminals / systems / roles; Focusing on the closed-loop management needs of health data throughout the entire process of convenient services in smart hospitals, a comprehensive identity binding system is constructed. Specifically, this involves configuring globally unique identifiers and dynamic attribute tags for each type of health data (including medical records, vital sign data, and service interaction data), and assigning exclusive blockchain digital identity certificates to convenient terminals (mini-programs, self-service machines, IoT monitoring devices, etc.), hospital system nodes (HIS, LIS, PACS, cloud platforms, etc.), and operating roles (medical staff, patients, maintenance personnel, researchers, etc.), thus building a strong bridge between identity and data. During implementation, the system fully adapts to the compliance requirements of medical scenarios, ensuring that identity binding covers the entire data generation, flow, storage, and access chain. Certificate and tag information are dynamically updated with the data, guaranteeing both the continuity of identity traceability and meeting stringent standards for privacy data protection.

[0012] Step S111: Identify four types of entities: health data, convenient terminals, in-hospital system nodes, and operating roles, and build a consortium blockchain and CA authentication system based on national cryptographic algorithms; First, a comprehensive analysis was conducted on the four core identity entities involved in the closed-loop management of health data in smart hospitals: health data encompassing structured and unstructured data generated throughout the entire cycle of pre-hospital screening, in-hospital diagnosis and treatment, and post-hospital follow-up; convenient terminals including mobile applications, self-service devices, and home monitoring IoT devices; hospital system nodes covering core business systems in clinical, medical technology, and management fields, as well as edge gateways and cloud servers; and operational roles categorized into different permission levels for medical staff, patients, operations and maintenance, research, and supervision. Based on this analysis, a consortium blockchain underlying architecture was built, with nodes including the hospital's core systems, medical consortium collaborating units, and regulatory agencies. The national cryptographic algorithms SM2 and SM3 are used to ensure on-chain data encryption and integrity verification. Simultaneously, CA authentication nodes were deployed to be responsible for the issuance, revocation, update, and verification of identity certificates, forming a complete system of "identity verification - certificate issuance - full-cycle management" to ensure the security and authority of identity authentication.

[0013] Step S112: Generate an immutable unique identifier for each piece of health data, consisting of a de-identified ID, data type, timestamp, and hash value, and configure dynamic attribute tags containing privacy identifier, sensitivity level, and timestamp; For each piece of health data, the patient's basic information is first extracted and irreversibly de-identified to generate a de-identified ID. This ID is then combined with data type encoding (following the FHIR medical data element standard) and a millisecond-level timestamp to form the original feature string. This string is then encrypted using a national cryptographic hash algorithm to obtain a globally unique and tamper-proof data identifier. This identifier is carried throughout the data's entire lifecycle and serves as the core credential for data identity. Simultaneously, dynamic attribute tags are configured. These tags include a privacy de-identification flag (marking whether core privacy information is involved), a data sensitivity level (divided into four levels: core, high, medium, and low), and a generation timestamp. The tags can be dynamically adjusted based on the data's purpose (treatment, research, statistics) and the data transfer node (internal hospital system, cross-institutional collaboration platform). For example, the de-identification flag level is automatically increased for research purposes, ensuring that the tags are accurately matched to the data's usage scenario.

[0014] Step S113: Issue blockchain digital identity certificates for terminals and system nodes, and assign personnel identity certificates with associated job permissions to operating roles; Blockchain digital identity certificates are issued for user-friendly terminals. These certificates contain information such as the device's MAC address, hardware serial number, device type, and authorized usage scope, with the private key stored in the device's secure encryption chip or trusted execution environment. Certificates issued to various system nodes within the institution are associated with system function modules, data processing permissions, and communication protocol types, clearly defining system operation boundaries. Personnel identity certificates assigned to operational roles are bound to information such as job title, department, data access permission list, and certificate validity period, achieving "one person, one certificate, one permission." After certificate issuance, signature authentication is completed through a blockchain CA node, ensuring the certificate cannot be forged. During data generation, the data acquisition terminal automatically binds its own certificate information to the data identifier. During data transfer, the receiving node verifies the legality of the sending node's certificate. Upon access, the operational role must present their personal certificate for identity verification. The entire process achieves strong on-chain binding between data identifiers and various identities through two-way certificate authentication. The associated records are permanently stored on the consortium blockchain, and an identity verification interface is provided for real-time verification during cross-system and cross-institutional access, ensuring traceable identity and accountable operations.

[0015] Step S114: In the data generation, flow and access stages, the data identifier, device identity, system identity and role identity are strongly bound on the chain through two-way certificate authentication and the associated records are retained. At the same time, an identity verification interface is provided to realize full-link identity traceability.

[0016] A strict two-way certificate authentication mechanism is implemented at each key stage of data generation, flow, and access: During data generation, the acquisition terminal uploads its own digital certificate hash value along with the data identifier and dynamic attribute tag to the consortium blockchain, completing the initial identity binding. When data flows between different system nodes, the sending and receiving nodes mutually verify the validity of each other's certificates (including signature, validity period, and scope of permissions). After successful verification, an association record of both parties' identities and data identifiers is appended to the blockchain. When an operator accesses data, they must submit their personal digital certificate to the server through a client. Access is only allowed after the server verifies the certificate, and the binding relationship between the accessing role, access time, operation content, and data identifier is recorded. All association records are stored in encrypted form on the consortium blockchain, are tamper-proof, and are permanently retained. A standardized identity verification interface is provided simultaneously, supporting real-time calls from various systems and regulatory agencies to verify the integrity of the data-identity binding. If a certificate expires, identity mismatches, or data identifier is detected, a system alarm is immediately triggered, and data flow is blocked, ensuring accurate traceability of identities throughout the entire chain and meeting medical data security compliance requirements.

[0017] Step S120: Based on the distributed graph database and tracking framework, deploy a lightweight data collection agent and construct a federated dynamic bloodline graph by combining medical parsing rules; Focusing on the end-to-end data lineage tracing needs of smart hospitals, this project builds a core technology foundation based on a distributed graph database (using Neo4j distributed version, supporting high-concurrency read / write and distributed storage) and the OpenTelemetry tracking framework. Lightweight lineage collection agents (developed in Go, with CPU usage ≤5% and memory usage ≤100MB) are deployed across all nodes in the data chain, including user terminals, edge gateways, HIS, EMR, and cloud platforms. These agents capture key information about data flow through a hook mechanism, eliminating the need for centralized storage of raw medical data. Simultaneously, a dedicated lineage parsing rule base for medical scenarios is constructed, defining parsing logic for data format conversion, field association, and fusion calculation. Through distributed storage and real-time synchronization mechanisms, a federated dynamic lineage graph is formed, ensuring that the graph can be queried across systems and institutions. Even if data is forwarded through multiple nodes and undergoes multiple format conversions, its original source can still be accurately traced, completely resolving the technical pain points of broken lineage records and difficult source tracing in smart hospitals.

[0018] Step S121: Build a tracking framework based on a distributed graph database and OpenTelemetry, and deploy lightweight lineage collection agents on convenient terminals, edge gateways, HIS / EMR and cloud platforms to capture data flow information without centrally storing the original data; First, a distributed graph database adapted to the medical scenario is selected, which needs to support distributed storage and rapid relational querying of massive kinship data. Then, a full-link data tracking architecture is built based on the OpenTelemetry framework, defining a unified tracking data format (including core fields such as data ID, source node ID, target node ID, operation type, and timestamp). Lightweight kinship collection agents are deployed at all nodes involved in data flow, including convenient terminals, edge gateways, HIS, EMR, and cloud platforms. These agents are mounted to each system in a low-intrusive manner, capturing data flow events in real time through hook functions, extracting only key data association information (such as data identifiers, operation instructions, and field mapping relationships), without centrally storing any raw medical data to avoid privacy risks. For the private interfaces of legacy medical systems, dedicated adaptation plugins are developed to achieve standardized conversion of non-standard interface data and extraction of kinship information, ensuring comprehensive kinship data collection across all nodes.

[0019] Step S122: Establish a medical lineage analysis rule base to automatically identify and analyze data format conversion, field association, and fusion calculation behaviors; A medical lineage analysis rule base was established based on typical scenarios of medical data processing in smart hospitals. The rule base includes three core rule categories: data format conversion parsing rules, which clarify field mapping relationships and format conversion logic for scenarios such as DICOM image to JPG conversion, HL7 message to JSON conversion, and laboratory data unit conversion; field association parsing rules, which focus on association scenarios such as diagnostic conclusions and laboratory indicators, medication records and patient complaints, and vital sign data and chronic disease management plans, defining association identifiers and matching logic; and fusion calculation parsing rules, which clarify the data source field combination logic and calculation process association relationships for scenarios requiring multi-source data fusion calculations, such as health risk scores and chronic disease control effect assessments. The rule base is stored in a configurable JSON format, allowing medical personnel to dynamically add or modify rules based on new treatment processes and data processing needs, ensuring real-time adaptation between the rule base and medical business scenarios, and achieving accurate and automatic identification and parsing of various data processing behaviors.

[0020] Step S123: Distribute and synchronize the lineage data of each node in real time to form a federated dynamic lineage graph, which supports cross-system and cross-institutional penetrating queries and traceability of the original data source after multi-node forwarding.

[0021] The kinship data collected from each node is first stored in the corresponding local distributed graph database node. A cross-node data synchronization protocol based on the Raft algorithm is used to achieve real-time synchronization of kinship data between nodes, ensuring the consistency of global kinship information. Based on the synchronized kinship data, a federated dynamic kinship data graph is constructed. The graph reflects the flow trajectory and relationships of the data throughout its entire lifecycle in real time, and supports retrieval by multiple dimensions such as data ID, patient anonymization marker, system node, and time range. For cross-system and cross-institutional data query needs, the graph achieves penetrating retrieval through a distributed query algorithm. Even if the data is forwarded by multiple levels of medical consortium institutions and undergoes multiple format conversions, the graph can still quickly locate the original collection node and initial data state, completely solving the technical defects of traditional centralized kinship management that cannot adapt to cross-system and cross-institutional scenarios, and providing support for data traceability in regional medical collaboration.

[0022] Step S130: Establish a multi-dimensional operation traceability mechanism, expand the collection of behavioral fingerprints and operation context data beyond regular logs, and adopt a dual-mode storage of blockchain evidence storage and local encrypted backup; To address the need for traceability and auditability of the entire data operation process in smart hospitals, a multi-dimensional operation traceability mechanism has been established. Building upon routine operation log collection, two key information categories are expanded to include user behavior fingerprints and data operation context. Behavioral fingerprints encompass user operating habits, terminal hardware characteristics, and network environment characteristics, while operation context includes snapshots before and after data operations, field changes, and related operation sequences, ensuring comprehensive coverage of all dimensions of the operation. Simultaneously, a dual-mode storage of traceability data is employed: blockchain notarization and local encrypted backup. The blockchain records only the hash value of the traceability data, leveraging its immutability to guarantee data authenticity; local storage uses national cryptographic algorithms to encrypt and store complete traceability information, ensuring detailed verification. This mechanism satisfies privacy protection requirements while enabling comprehensive traceability of operational behavior, providing complete data support for auditing and evidence collection.

[0023] Step S131: Based on the regular operation log, collect the behavioral fingerprint composed of user operation habits, terminal hardware fingerprint, and network environment fingerprint, as well as the operation context composed of snapshots before and after data operation, changed content, and associated sequences. Building upon the collection of routine operation logs (including operator identity, operation time, operation type, operation object, and operation result), the collection dimensions are further expanded. For behavioral fingerprint collection, user operation habit characteristics (such as keyboard input rhythm, mouse movement trajectory, touchscreen operation pressure and frequency) are captured through terminal sensors. Terminal hardware fingerprints (device model, operating system version, hardware serial number, device unique identifier) ​​and network environment fingerprints (IP address, MAC address, network operator, access point information) are extracted through system interfaces. For operation context collection, incremental snapshots before data operations (recording only the original state of the fields to be changed) and post-operation changes are captured through database triggers. Link tracing technology records related operation sequences (such as "query → download → share" and "modify → save → synchronize," etc.). During the collection process, fields involving core sensitive information such as patient ID numbers and mobile phone numbers undergo irreversible anonymization in real time to ensure no privacy data is leaked during collection. Simultaneously, encrypted transmission protocols are used to push the collected data to storage nodes to prevent data leakage during transmission.

[0024] Step S132: Adopt a dual storage mode of blockchain-based evidence storage and complete trace information storage, and locally encrypted storage, to achieve tamper-proof operation data and traceability of details; A dual-mode storage architecture of "blockchain notarization + local encrypted backup" is adopted to process all trace data. First, the integrated trace data (including regular logs, behavioral fingerprints, and operation contexts) is packaged in a unified format and a unique hash value is calculated using a national cryptographic hash algorithm. This hash value, along with the operation timestamp and storage node identity, is uploaded to the consortium blockchain for notarization. Leveraging the immutability and permanent retention characteristics of blockchain, the authenticity and integrity of the trace data are ensured, preventing malicious tampering. Simultaneously, the complete trace data is encrypted using a national cryptographic symmetric encryption algorithm and stored on a local encrypted hard drive or distributed storage cluster. The storage medium has tamper-proof and leak-proof functions. Differentiated storage periods are set for trace data of different importance levels: core operation logs (such as data tampering and unauthorized access records) are retained for ≥3 years, regular operation logs for ≥1 year, and behavioral fingerprint data for ≥6 months. A tiered storage strategy of hot, warm, and cold data is adopted, with hot query data stored on SSDs to improve access speed, and cold data migrated to object storage to reduce costs, achieving the dual goals of tamper-proof operation data and detailed traceability.

[0025] Step S133: Use indexing and visualization tools to complete the full-dimensional behavior reconstruction of the operation subject, time, object, content, channel, and before and after states.

[0026] A full-text search index for trace data is built based on Elasticsearch, supporting multi-dimensional queries based on operator identity, operation time, operation object, behavioral fingerprint characteristics, network environment, etc., ensuring a query response time of ≤1 second. Simultaneously, an operation behavior visualization and reconstruction tool was developed. This tool, by associating regular logs, behavioral fingerprints, and operation context data, intuitively presents the operation subject, operation time, operation object, operation content, access channel, and data status changes before and after the operation in the form of time series diagrams, before-and-after data comparison interfaces, and operation flow diagrams. For example, when it is necessary to reconstruct the access operation of a sensitive data item, the tool can clearly display the visitor's identity, the terminal device information used, the network access environment, the access time, the specific data content viewed, whether the data changed before and after the access, and related subsequent operations, achieving a full-dimensional visualization and reconstruction of operation behavior. This provides intuitive and reliable evidence for audit verification, security incident tracing, and responsibility determination, significantly improving the efficiency and accuracy of data operation auditing.

[0027] Step S140: Build an AI intelligent audit engine, transform regulations into an audit rule base through a large language model, and combine unsupervised learning modeling to identify abnormal operations in medical scenarios; Focusing on the compliance audit needs of smart hospitals' medical data, an AI-powered intelligent audit engine has been constructed. A large language model, fine-tuned for medical scenarios, is used to deeply analyze regulations such as the Cybersecurity Law 2.0, the Personal Information Protection Law, and the Measures for the Administration of Cybersecurity in Medical and Health Institutions. Abstract clauses are transformed into an executable audit rule base, covering abnormal behavior characteristics and compliance verification indicators. Based on historical operational data, an unsupervised learning algorithm is used to train a medical-specific abnormal operation identification model, accurately identifying violations such as bulk access during non-working hours and high-frequency downloads across regions. A three-tiered response mechanism of early warning, blocking, and evidence collection is established, automatically triggering corresponding measures according to risk levels. It also supports customizing audit report dimensions according to regulatory requirements, generating standardized reports, and achieving intelligent and real-time compliance auditing of medical data operations.

[0028] Step S141: Use a large language model to transform the Cybersecurity Classified Protection 2.0, the Personal Information Protection Law, and the Medical Network Security Management Standards into an audit rule base that includes abnormal behavior characteristics and compliance verification indicators; A regulatory analysis engine was built using a large language model specifically tweaked for the medical field. Clauses from the Cybersecurity Law Level 2.0 ("Prohibition of unauthorized bulk access to sensitive data") and the Personal Information Protection Law ("Minimum necessary use of privacy data") were input into the model. Through semantic parsing, entity extraction, and rule transformation processes, these prohibitive and mandatory clauses were converted into specific, enforceable rule entries. The constructed audit rule base is divided into an abnormal behavior feature base and a compliance verification indicator base. The abnormal behavior feature base clarifies the criteria for judging behaviors such as bulk access during non-working hours and cross-regional downloads, such as "single access of ≥50 core sensitive data items between 2-6 AM". The compliance verification indicator base includes quantitative indicators such as data encryption rate and permission compliance rate, with thresholds dynamically adjusted based on regulatory requirements.

[0029] Step S142: Based on historical operation data, an unsupervised learning model is constructed to identify abnormal operations in medical scenarios, automatically identifying behaviors such as batch access during non-working hours, cross-regional downloads, and unauthorized queries. First, the historical operational data of the entire smart hospital process is preprocessed to remove invalid data such as test logs and duplicate records. The data is then categorized and labeled according to operation type, role, and data sensitivity level to construct a standardized medical operation dataset. Unsupervised learning algorithms such as Isolation Forest and Autoencoder are used to train an abnormal operation recognition model based on the dataset. By learning the feature distribution of normal operations, the model automatically identifies abnormal behaviors that deviate from the distribution. Feedback from medical business experts is incorporated into the model training process, and annotation optimizations are performed for special scenarios such as cross-regional access during emergency periods and data sharing during public health emergencies, keeping the false alarm rate below 5%. After deployment, the model receives operation log data in real time and automatically identifies violations such as batch access during non-working hours, high-frequency cross-regional downloads, and unauthorized queries, providing accurate basis for tiered response.

[0030] Step S143: Implement tiered responses of early warning, blocking, and evidence collection based on the identified risk level, and automatically generate a compliance audit report with customizable dimensions.

[0031] The warning level targets operations that are authorized but require attention (such as single access to highly sensitive data), notifying relevant personnel via system notifications and emails. The blocking level targets high-risk operations such as unauthorized batch downloads and suspected tampering, immediately blocking the operation process, locking the account, and notifying the security administrator. The evidence collection level automatically initiates electronic evidence collection processes for confirmed data leaks and malicious tampering. Simultaneously, the engine has a built-in audit report generation module that supports customized report content based on time period, system, role, and violation type. It automatically summarizes compliance scores, anomaly details, and rectification suggestions, generating standardized reports in PDF / Excel format, which are automatically pushed to regulatory interfaces monthly to meet daily compliance checks and regulatory requirements.

[0032] Step S150: Build a cross-system linkage traceability and evidence collection platform, connect multi-terminal / system audit interfaces, and link pedigree data with operation trace data; A cross-system collaborative tracing and evidence collection platform was established. First, a unified audit data interface standard was defined, adopting a RESTful API design and a unified data transmission format of JSON, supporting HTTPS encrypted transmission and national cryptographic algorithm signature verification. Data channels were established between convenient terminals, edge nodes, various business systems within the institution, and the cloud platform, achieving real-time synchronization of audit data through a Kafka message queue. A data association engine was built, using unique data identifiers and identity hashes as key fields to link federated lineage graphs and operational trace data, quickly locating the source nodes and responsible parties of data tampering and leakage. An electronic evidence collection module compliant with judicial evidence collection standards was built-in, using fixed logs, blockchain hashes, behavioral fingerprints, and other evidence to generate legally valid evidence packages with digital signatures, directly connecting to the regulatory audit system to achieve integrated cross-system tracing, compliant evidence collection, and regulatory integration.

[0033] Step S151: Establish a unified audit data interface standard and connect the data channels between terminals, edge computing, internal systems and the cloud, and achieve real-time synchronization of audit data through message queues; Establish cross-system audit data interface standards, specifying that interface fields include core information such as operation log data ID, lineage data ID, operator identity hash, and data type. HTTPS encryption is used for transmission, and both interface requests and responses must be verified using national cryptographic algorithms to ensure transmission security and data integrity. For legacy medical systems lacking standard interfaces, develop dedicated adaptation plugins to extract audit data through log parsing and database reading, converting it to a standard format before integrating it into the platform. Build a cross-system data synchronization hub based on Kafka, configuring synchronization strategies: core operation data (such as tampering and unauthorized access records) is synchronized in real-time (delay ≤ 1 second), while regular data is synchronized in batches every minute. The synchronization hub has a built-in data cleaning module that automatically removes duplicate data, completes missing fields, and corrects format errors, ensuring data consistency and availability across systems.

[0034] Step S152: Establish a data association engine to associate the federated lineage map with the operation trace data according to the key fields of data identifier and identity hash, and quickly locate the nodes and responsible parties of data tampering, leakage, and misuse; A data association engine is established, using unique health data identifiers, operator identity hashes, and terminal device IDs as core association fields to construct a federated dynamic data lineage graph and a mapping relationship between multi-dimensional operation trace data. The association engine supports complex query condition combinations, such as "access operations and flow links of core sensitive data corresponding to a patient's de-identified ID within a certain time period," and employs a distributed query algorithm to quickly retrieve associated data. By reconstructing the entire data flow path through the lineage graph and combining it with operation trace data, key information such as the operation subject, time, and terminal is identified. This accurately pinpoints the source nodes (such as a HIS system node or self-service terminal) and responsible parties (such as medical staff or maintenance personnel) of data tampering, leakage, or misuse. The source tracing response time is controlled within 30 seconds, significantly improving the efficiency of security incident handling.

[0035] Step S153: Through the built-in judicial standard electronic evidence collection module, fix logs, blockchain hashes, and behavioral fingerprint evidence to generate a legally valid evidence package, and achieve connection with the regulatory audit system.

[0036] The platform incorporates an electronic evidence collection module that strictly adheres to judicial evidence collection standards, automatically extracting related raw log data, blockchain-stored hash values, behavioral fingerprint verification results, and kinship tracing graphs. By connecting to the trusted timestamp service of the National Time Service Center, the platform solidifies the temporal accuracy of the evidence. It employs national cryptographic algorithms to digitally sign the evidence package, adding information such as the identity of the evidence collector, the collection time, and process descriptions. The generated evidence package includes an evidence list, a data integrity verification report, and a compliance statement. It supports exporting as electronic evidence files that meet judicial requirements and is compatible with the data import formats of regulatory audit systems and judicial evidence collection platforms. Simultaneously, a regulatory interface adaptation module has been developed to enable two-way communication with provincial and national medical data supervision platforms, pushing audit reports, anomaly records, and evidence packages in real time to meet compliance inspection and judicial evidence collection needs.

[0037] Step S160: Establish a compliance self-adaptive dynamic optimization mechanism, and continuously optimize the traceability audit link by updating the audit model through federated learning, automatic compliance detection, and traceability drills to adapt to changes in business and regulations.

[0038] Establish a compliance-adaptive dynamic optimization mechanism, adopting a horizontal federated learning architecture. This involves system nodes as participants and the cloud platform as a model aggregation server, updating audit rules and anomaly detection models without allowing data to leave the domain. Deploy automated compliance detection tools to capture the latest regulations and industry standards in real time, scan the traceability audit system daily, identify compliance gaps, and output optimization solutions. Build a traceability drill scenario library including data leakage, tampering, and privilege abuse scenarios, regularly simulating and evaluating system performance. Form a closed-loop iterative mechanism of "detection—analysis—optimization—verification," dynamically adapting to adjustments in medical business processes and updates to regulations and policies, continuously optimizing the traceability audit chain, ensuring the system's long-term compliance requirements, and improving audit accuracy and response speed.

[0039] Step S161: Update the audit rule model and anomaly identification model based on horizontal federated learning without leaving the data domain; scan the source audit system daily using regulatory monitoring and automatic detection tools to identify compliance gaps and output optimization solutions;

[0040] A horizontal federated learning architecture was established, with various business systems within the hospital, the cloud platform, and the systems of medical consortia as participants. Local model training modules were deployed, and models were trained based on local operational data, with only model parameters uploaded to the cloud aggregation server. A federated averaging algorithm was used to securely aggregate parameters, generating a globally updated model which was then distributed to all participants, ensuring model iteration could be completed without data leaving the domain. An automatic compliance detection tool was deployed, integrating a regulatory update monitoring module. This tool captures the latest regulations issued by departments such as the National Health Commission and the Cyberspace Administration of China in real time, parses new clauses using a large language model, and automatically updates the audit rule base. The tool scans audit logs and the traceability system daily at midnight to verify indicators such as data encryption rate and permission compliance rate, identify compliance gaps (such as new requirements for the protection of children's health data), and automatically generate optimization plans including rectification measures, responsible departments, and completion deadlines.

[0041] Step S162: Establish a database of tracing scenarios that include data leakage, tampering, and abuse of privileges, conduct regular simulations and evaluate the system response and evidence collection effectiveness; A database of source tracing drill scenarios has been established, covering typical scenarios such as internal personnel downloading unauthorized data in bulk, malicious modification of test results, nurses accessing doctors' diagnoses without authorization, and unauthorized data sharing across institutions. Each scenario clearly defines the drill objectives (e.g., verifying source tracing response time and evidence collection accuracy), triggering conditions (e.g., simulating the bulk download of 50 core sensitive data entries in the early morning), and evaluation indicators (response speed, accuracy of responsibility identification, and completeness of evidence). Source tracing drills are organized quarterly. After each simulated scenario is triggered, the system records data throughout the entire process from anomaly identification, alarm, source tracing to evidence collection, generating a drill evaluation report. This report analyzes the system's performance in terms of response speed, evidence collection completeness, and location accuracy, identifying technical bottlenecks and optimization directions.

[0042] Step S163: Establish a closed-loop iterative mechanism for detection, analysis, optimization, and verification to adapt to changes in medical business and regulations and policies, and continuously optimize the traceability and auditing process.

[0043] A joint review team composed of technical personnel, medical business experts, and compliance specialists was established. Monthly optimization review meetings are held to analyze system issues, such as high false alarm rates and incomplete traceability links, based on compliance testing results, model performance data, and traceability drill reports. Optimization plans are developed to address these issues, such as adjusting audit rule thresholds, optimizing field extraction logic for bloodline collection agents, and improving access control strategies. After implementation, the effectiveness of the optimization plans is verified through secondary compliance testing and specialized drills. If the expected goals are not achieved, the plans are readjusted, forming a closed-loop iterative mechanism of "testing—analysis—optimization—verification." This mechanism ensures that the system can dynamically adapt to changes in medical business processes and updates to regulations and policies, continuously improving the compliance, accuracy, and adaptability of the traceability audit system, and guaranteeing the long-term security and compliance of smart hospital data closed-loop management.

[0044] Based on the same inventive concept, please refer to Figure 2 This paper shows a schematic block diagram of the structure of a closed-loop management system 100 for health data of a smart hospital providing convenient services, which is used to perform the above-described closed-loop management method for health data of a smart hospital providing convenient services. The closed-loop management system 100 may include a communication unit 110, a machine-readable storage medium 120, and a processor 130.

[0045] In this embodiment, both the machine-readable storage medium 120 and the processor 130 are located within the end-to-end smart hospital public service health data closed-loop management system 100 and are separately configured. However, it should be understood that the machine-readable storage medium 120 may also be independent of the end-to-end smart hospital public service health data closed-loop management system 100 and may be accessed by the processor 130 via a bus interface. Alternatively, the machine-readable storage medium 120 may also be integrated into the processor 130 and may communicate and interact with external systems through the communication unit 110.

[0046] The processor 130 is the control center of the end-to-end smart hospital public service health data closed-loop management system 100. It connects to various parts of the system via various interfaces and lines, and executes software programs and / or modules stored in the machine-readable storage medium 120, as well as accessing data stored in the machine-readable storage medium 120. This allows for the execution of various functions and data processing within the system, thereby providing overall monitoring of the end-to-end smart hospital public service health data closed-loop management system 100. Optionally, the processor 130 may include one or more processing cores; for example, it may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor. The machine-readable storage medium 120 is used to store machine-executable instructions for executing the scheme of this application, and the processor 130 is used to execute the machine-executable instructions stored in the machine-readable storage medium 120, so as to realize the closed-loop management method of health data for the whole process of smart hospital convenience services provided in the aforementioned method embodiments.

[0047] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

[0048] The embodiments of this application have been described above with reference to the accompanying drawings. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. This application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A closed-loop management method for health data in smart hospitals throughout the entire process, characterized by: Includes the following steps: A comprehensive identity binding system is built based on blockchain technology, which involves configuring identifiers and dynamic attribute tags for health data and assigning digital identity certificates to terminals / systems / roles. Based on a distributed graph database and tracking framework, a lightweight data collection agent is deployed, and a federated dynamic kinship graph is constructed by combining medical analysis rules. Establish a multi-dimensional operation traceability mechanism, expand the collection of behavioral fingerprints and operation context data beyond regular logs, and adopt a dual-mode storage of blockchain evidence storage and local encrypted backup. Build an AI-powered intelligent audit engine that transforms regulations into an audit rule base using a large language model and combines unsupervised learning modeling to identify abnormal operations in medical scenarios. Establish a cross-system collaborative traceability and evidence collection platform, connect multi-terminal / system audit interfaces, and link kinship tracing and operation trace data; Establish a compliance self-adaptive dynamic optimization mechanism, and continuously optimize the traceability audit link by updating the audit model through federated learning, automatic compliance detection, and traceability drills to adapt to changes in business and regulations.

2. The closed-loop management method for health data of smart hospital public services according to claim 1, characterized in that: The aforementioned blockchain-based full-domain identity binding system, through configuring identifiers and dynamic attribute tags for health data and assigning digital identity certificates to terminals / systems / roles, includes: We identified four types of stakeholders: health data, convenient terminals, in-hospital system nodes, and operational roles, and built a consortium blockchain and CA authentication system based on national cryptographic algorithms. Generate an immutable and unique identifier for each piece of health data, consisting of a de-identified ID, data type, timestamp, and hash value, and configure dynamic attribute tags that include privacy identifier, sensitivity level, and timestamp; Issue blockchain digital identity certificates for terminals and system nodes, and assign personnel identity certificates with associated job permissions to operating roles; In the data generation, flow and access stages, two-way certificate authentication is used to strongly bind data identifiers, device identities, system identities and role identities on the blockchain and retain related records. At the same time, an identity verification interface is provided to achieve full-link identity traceability.

3. The closed-loop management method for health data of smart hospital public services according to claim 1, characterized in that: The method relies on a distributed graph database and tracking framework, deploys a lightweight data collection agent, and constructs a federated dynamic kinship graph based on medical analysis rules, including: A tracking framework is built based on a distributed graph database and OpenTelemetry. Lightweight lineage collection agents are deployed in convenient terminals, edge gateways, HIS / EMR and cloud platforms to capture data flow information without centrally storing the original data. Establish a medical lineage analysis rule base to automatically identify and analyze data format conversion, field association, and fusion calculation behaviors; The kinship data of each node is distributed, stored, and synchronized in real time to form a federated dynamic data kinship graph, which supports cross-system and cross-institutional penetrating queries and tracing of the original data source after multi-node forwarding.

4. The closed-loop management method for health data of smart hospital public services according to claim 1, characterized in that: The establishment of a multi-dimensional operation tracking mechanism expands the collection of behavioral fingerprints and operation context data beyond regular logs, employing a dual-mode storage approach of blockchain notarization and local encrypted backup, including: Based on regular operation logs, behavioral fingerprints are collected, consisting of user operation habits, terminal hardware fingerprints, and network environment fingerprints, as well as operation contexts consisting of snapshots before and after data operations, changed content, and associated sequences. It adopts a dual storage mode of blockchain-based evidence storage and complete trace information storage, which realizes the anti-tampering of operation data and the traceability of details; Through indexing and visualization restoration tools, a full-dimensional behavioral restoration of the operation subject, time, object, content, channel, and before and after states can be completed.

5. The closed-loop management method for health data of smart hospital public services according to claim 1, characterized in that: The construction of the AI ​​intelligent audit engine involves converting regulations into an audit rule base using a large language model, and combining unsupervised learning modeling to identify abnormal operations in medical scenarios, including: Using a large language model, the Cybersecurity Classified Protection 2.0, the Personal Information Protection Law, and the Medical Network Security Management Standards are transformed into an audit rule base that includes abnormal behavior characteristics and compliance verification indicators; Based on historical operation data, an unsupervised learning model is built to identify abnormal operations in medical scenarios, which automatically identifies batch access, cross-regional downloads, and unauthorized query behaviors during non-working hours. Based on the identified risk level, a tiered response of early warning, blocking, and evidence collection is implemented, and a compliance audit report with customizable dimensions is automatically generated.

6. The closed-loop management method for health data of smart hospital public services according to claim 1, characterized in that: The aforementioned establishment of a cross-system collaborative tracing and evidence collection platform, which connects multiple terminal / system audit interfaces and links pedigree data with operational trace data, includes: Establish a unified audit data interface standard and connect the data channels between terminals, edge computing, internal systems and the cloud, and achieve real-time synchronization of audit data through message queues; Establish a data association engine to link federated kinship maps with operation trace data according to key fields such as data identifiers and identity hashes, and quickly locate the nodes and responsible parties for data tampering, leakage, and misuse; By using a built-in judicial standard electronic evidence collection module, it can fix logs, blockchain hashes, and behavioral fingerprint evidence to generate legally valid evidence packages, and achieve integration with regulatory audit systems.

7. The closed-loop management method for health data of smart hospital public services according to claim 1, characterized in that: The aforementioned establishment of a compliance self-adaptive dynamic optimization mechanism, through federated learning to update the audit model, automatic compliance detection, and source tracing drills, adapts to changes in business and regulations, and continuously optimizes the source tracing audit chain, including: Based on horizontal federated learning, the audit rule model and anomaly identification model are updated without leaving the data domain; the audit system is scanned daily through regulatory monitoring and automatic detection tools to identify compliance gaps and output optimization solutions. Establish a database of tracing scenarios that include data leakage, tampering, and abuse of privileges, and conduct regular simulations and evaluate the system response and evidence collection effectiveness. Establish a closed-loop iterative mechanism for detection, analysis, optimization, and verification to adapt to changes in medical business and regulations and policies, and continuously optimize the traceability and auditing process.

8. A closed-loop management system for health data in a smart hospital, characterized in that: include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the closed-loop management method for health data of a smart hospital for public convenience services as described in any one of claims 1 to 7 by executing the machine-executable instructions.

Images