Data sharing method in medical insurance scene

Abstract

The invention discloses a data sharing method in a medical insurance scene, and aims to solve the problems of lack of safety protection, different data standards, insufficient compliance and low efficiency in traditional medical insurance data sharing. According to the method, a double-layer security protection system with container isolation and hardware credibility is constructed by fusing a gVisor-based security container technology and an SGX server-based TEE technology. Access multi-source data is preprocessed, hierarchical encryption is implemented according to data sensitivity levels, and a key management mechanism of hardware storage, authority control and regular rotation is matched. After mirror image scanning is executed through a tool to check vulnerabilities, a secure container is created, a TEE environment is deployed in the secure container, a trusted computing space is formed, data computing is completed in the trusted environment, and a computing result is output after being verified through a preset rule. Operation logs are recorded in the whole process, and data are thoroughly cleared after tasks are completed. According to the invention, the security, compliance and stability of data sharing are improved.

Description

Technical Field

[0001] This invention relates to the field of medical insurance data processing, and specifically to a data sharing method in a medical insurance scenario. Background Technology

[0002] In the process of digital transformation of the medical insurance industry, data sharing has become a core support for optimizing the supervision of medical insurance funds and improving the efficiency of medical service collaboration. However, the existing data sharing models and technical systems still have many prominent shortcomings, which restrict the safe and orderly development of sharing work. The main problems are as follows:

[0003] (1) Traditional medical insurance data sharing often adopts temporary copying and manual import methods. These methods lack systematic security protection measures in the data transmission and storage links, making them easy targets for external attacks and leading to the risk of leakage of sensitive data such as patient privacy information and medical insurance settlement details. At the same time, the sharing mode that relies on manual operation is not stable enough and is difficult to adapt to the long-term, high-frequency data interaction needs, resulting in poor sustainability.

[0004] (2) The information system architectures of medical insurance departments and medical institutions at all levels in different regions are significantly different, resulting in different data processing logics and storage formats, and a lack of unified data standards and specifications. This fragmented state of data makes it difficult to efficiently integrate and connect multi-source medical insurance data, which not only increases the complexity of data preprocessing, but also directly hinders the process of cross-regional and cross-institutional data sharing, and fails to give full play to the collaborative value of data.

[0005] (3) In the process of data sharing, the participating entities such as medical insurance departments and medical institutions have many concerns about the prediction and handling of data security risks due to the lack of clear basis for the division of responsibilities. They are worried that they will bear legal responsibility for data security issues caused by sharing behavior, which reduces their enthusiasm and initiative for data sharing.

[0006] Therefore, the existing medical insurance data sharing model cannot simultaneously ensure security, stability, and compliance, and is insufficient to meet the demand for efficient data flow for the high-quality development of the medical insurance system. New data sharing methods need to be developed to solve the current problems. Summary of the Invention

[0007] To address the aforementioned problems in existing technologies, this invention integrates gVisor-based secure container technology and SGX server-based TEE technology. Through the design of the technical system and process optimization, it achieves innovation in multiple aspects such as security protection, collaborative efficiency, and compliance management. This invention proposes a data sharing method in a medical insurance scenario, including the following steps:

[0008] S1. Access multi-source medical insurance data, perform standardized preprocessing to eliminate data heterogeneity, implement hierarchical encryption according to data sensitivity level, transmit through encrypted channel and perform integrity verification;

[0009] S2. Use scanning tools to detect vulnerabilities in containers and TEE dependent images, implement graded handling based on risk level, and archive the scan results;

[0010] S3. Create a secure container based on gVisor, deploy an Occlum system-supported TEE environment on the SGX server, and establish a container isolation and hardware trust protection architecture;

[0011] S4. Configure a security gateway to implement communication encryption and request forwarding, allocate differentiated permissions based on the RBAC model, and identify and handle abnormal access by combining traffic monitoring;

[0012] S5. Complete the encrypted data calculation within the TEE, ensure calculation security through environment self-check and temporary key management, and output the calculation result after verifying it according to preset rules;

[0013] S6. Record operation logs throughout the entire process and implement audit management. After the task is completed, destroy the security container and TEE environment, and clear data and operation traces.

[0014] Preferably, step S1 includes:

[0015] S11. Connect to the medical insurance data source. The structured database is accessed through JDBC or ODBC tools and field validity and data integrity checks are performed. Unstructured data is extracted using parsing tools to extract core fields. PDF format data is converted into structured data through OCR recognition. The medical insurance data source includes the medical insurance system database and the medical institution information system.

[0016] S12. Data standardization preprocessing: unify the date field format, map disease diagnosis codes to standard codes and drug codes to national drug standard codes, use the range method to normalize numerical data, and identify outlier extreme values.

[0017] S13. Data Encryption and Secure Transmission: Highly sensitive data uses the RSA asymmetric encryption algorithm, and batch business data uses the AES symmetric encryption algorithm. The hardware security module realizes full lifecycle management of keys, and the transmission channel is built based on SSL and TLS protocols and the data integrity is verified by hash algorithm.

[0018] Preferably, step S2 includes:

[0019] S21. Use Clair and Trivy to build a scanning system that covers container base images, application images and TEE dependency images, and configure scanning strategies such as forced scanning before container creation and daily full scanning.

[0020] S22. Classify vulnerabilities into high, medium, and low risk levels. For high-risk vulnerabilities, immediately suspend environment building and fix them within a specified period. For medium-risk vulnerabilities, include them in runtime monitoring. For low-risk vulnerabilities, archive them after assessment. Store the scan results according to the specifications and connect them to the security audit system.

[0021] Preferably, step S3 includes:

[0022] S31. When deploying gVisor runtime, create a secure container and limit CPU and memory resources, mount the encrypted data directory using the bind mount mode and grant read-only permissions, configure network rules and enable filtering mechanisms;

[0023] S32. Install the Occlum system on the SGX-compatible server, allocate dedicated EPC memory and CPU resources to create an Enclave, deploy the data processing program and dependent libraries, and start the program after verifying its integrity using a hash algorithm.

[0024] Preferably, step S4 includes:

[0025] S41. Deploy a security gateway based on NGINX, enable the TLS protocol and encryption suite, configure firewall rules to open necessary ports, and set up a reverse proxy to forward to the security container and TEE component;

[0026] S42. Define three types of roles: data administrator, auditor, and ordinary user, and assign permissions. Implement identity verification through the LDAP authentication system, deploy a monitoring suite to collect traffic metrics, and issue alerts and block access exceeding the threshold and abnormal IPs.

[0027] Preferably, step S5 includes:

[0028] S51. After startup, it automatically checks the configuration, permissions and connection status of the container and TEE. The key management system distributes temporary decryption keys to the TEE through an encrypted channel.

[0029] S52. Run an abnormal reimbursement identification or diagnosis and treatment data aggregation program within the TEE. The calculation process keeps the data encrypted, intermediate results are stored in the TEE's dedicated memory, and calculation indicators are collected and abnormalities are handled through the monitoring interface.

[0030] S53. Verify the results through logical verification, range verification, and integrity verification. If the verification passes, the result is encrypted and transmitted to the requester. If it fails, a work order is generated and the calculation is recalculated.

[0031] Preferably, step S6 includes:

[0032] S61. Deploy logging tools to record the entire process operation, using a unified format, and save logs through local storage and off-site backup. Auditors regularly check key logs and generate reports.

[0033] S62. Stop and delete the security container and TEE, release system resources, overwrite the data storage directory and TEE memory with random bytes, delete the image and application files and reset the SGX state, and record the entire destruction process log.

[0034] Preferably, configuring network rules and enabling the filtering mechanism includes:

[0035] (1) Configure container network rules to allow only port communication between containers, security gateways and TEE components, and deny other outbound and inbound connections;

[0036] (2) Enable gVisor’s seccomp filtering mechanism to restrict processes in the container to only calling necessary system calls, including read, write and execve.

[0037] Preferably, S32 includes:

[0038] (1) Enable SGX on the server, install Occlum dependent components, and execute the command to complete the Occlum installation;

[0039] (2) Allocate memory and CPU resources for TEE, create Enclave using Occlum command, and configure Occlum system parameters and Enclave file;

[0040] (3) Copy the medical insurance data processing program and dependent libraries into Occlum Enclave, execute the command to complete the construction; compare the file hash values ​​with the security algorithm to confirm that they have not been tampered with, and then start the program to prepare for calculation.

[0041] Preferably, in step S62, the data storage directory and TEE memory are overwritten multiple times using commands to delete the image and application files, the SGX state is reset, and the process log is destroyed.

[0042] The present invention has the following beneficial effects:

[0043] (1) This invention integrates gVisor-based secure container technology and SGX server-based TEE technology to form a two-layer protection architecture with container isolation and hardware trust, blocking unauthorized access and data leakage paths from the bottom layer of the computing environment. Through differentiated encryption strategies, highly sensitive data is protected by RSA asymmetric encryption algorithm, while batch business data is protected by AES symmetric encryption algorithm, balancing security and efficiency. Combined with the hardware storage, access control, and periodic rotation mechanism of the full lifecycle key management system, the risk of key leakage is significantly reduced. At the same time, the dual mechanism of mirror scanning can detect environmental vulnerabilities in advance. Measures such as SSL / TLS encryption channel and integrity verification for data transmission, and full data erasure after calculation, realize a secure closed loop for the entire process from data access, storage, calculation to destruction, greatly improving the security and trustworthiness of medical insurance data sharing.

[0044] (2) To address the data discrepancies across different systems, this invention utilizes a standardized data preprocessing workflow to unify field formats and encoding standards, eliminating data format heterogeneity and laying the foundation for cross-regional and cross-institutional data fusion. At the access layer, it adapts to various data sources, including structured databases and unstructured files, achieving efficient data aggregation. At the computing layer, it uses secure containers and TEE resources for flexible allocation, combined with encryption and computing strategies adapted for large-scale processing, to avoid the impact of security measures on data processing speed. This breaks down the data fragmentation of traditional models, improves the efficiency of data sharing and application response speed, and meets the needs of long-term, stable, and high-frequency data interaction.

[0045] (2) This invention, through access control policies and role-based differentiated permissions, ensures that only authorized personnel can perform corresponding operations, thus regulating data access behavior from the source. The localized operation log system records key behaviors throughout the entire process of data access, encryption, calculation, and output in detail, and adopts strict log modification control to meet the audit and traceability requirements of data security regulations. The clear operation traceability and risk warning mechanism clarifies the boundaries of rights and responsibilities of each participating entity, effectively alleviating the concerns of entities such as medical insurance departments regarding data sharing due to unclear rights and responsibilities, and providing compliance support for data sharing behavior.

[0046] This invention provides a data sharing method in a medical insurance scenario, which reduces the overall cost of data sharing and helps to promote the large-scale application of medical insurance data sharing. Attached Figure Description

[0047] Figure 1 This is a diagram illustrating the method steps of an embodiment of the present invention;

[0048] Figure 2 This is a schematic diagram illustrating the working principle of the secure container and trusted execution environment in an embodiment of the present invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0050] This embodiment is based on an architecture that integrates gVisor secure containers and SGX server TEE (Trusted Execution Environment) technology, such as... Figure 2 As shown, this enables secure sharing of medical insurance data throughout its entire lifecycle, from access to destruction, and is suitable for high-frequency data interaction scenarios such as cross-regional medical insurance fund supervision and multi-institutional medical service collaboration. Figure 1 As shown, the detailed implementation steps are as follows:

[0051] S1, end-to-end processing of medical insurance data.

[0052] S11. Multi-source data access. The core sources of medical insurance data are clearly defined, including provincial medical insurance system databases, information systems of secondary and above medical institutions, settlement systems of linked designated pharmacies, inter-regional medical treatment settlement platforms, and medical insurance supervision and early warning systems. Differentiated access solutions are adopted for different types of data sources:

[0053] 1. Structured Database Access: Common database connection tools include JDBC and ODBC, with connection parameters configured based on the data source type. MySQL databases use a JDBC driver package, setting a connection timeout of 30 seconds and a maximum of 50 connections; Oracle databases use an ODBC driver, enabling a connection pool mechanism to reduce the overhead of repeated connections. Double validation is performed during the access process: field validity validation uses regular expressions to match the format of key fields such as ID card numbers and medical insurance card numbers; data integrity verification compares the number of records in the source table with the access data, and the non-null rate of key fields, removing invalid records with a null value ratio exceeding 30% or logical conflicts (such as treatment time being later than settlement time).

[0054] 2. Unstructured / Semi-structured Data Access: For reimbursement voucher lists and medical record summaries in Excel and CSV formats, Apache POI is used to parse .xlsx files and OpenCSV to parse .csv files, extracting core fields such as name, visit date, and cost details. For scanned medical records in PDF format, Tesseract-OCR is used for text recognition and then converted into structured data. The recognition accuracy must reach over 95%. Files that do not meet this standard are marked for manual review.

[0055] S12. Data standardization preprocessing. This eliminates data heterogeneity across multiple systems through standardized operations, laying the foundation for cross-organizational integration.

[0056] 1. Data Format Conversion: Date fields are uniformly standardized to the format "YYYY-MM-DD HH:MM:SS". The original formats of medical institutions, such as "MM / DD / YYYY" and "DD-MM-YYYY", are batch converted using the SimpleDateFormat utility class. Disease diagnosis codes are uniformly mapped to ICD-10 codes, and drug codes are uniformly converted to the 20-digit drug standard codes issued by the National Medical Products Administration. For records with missing codes, the National Drug Code Query API is used to complete the codes by associating the drug name, specifications, and other information.

[0057] 2. Data normalization processing: Numerical data such as reimbursement amount, treatment duration, and drug dosage are processed using the range method to compress the data to a preset range. The calculation formula is "normalized value = (original value - minimum value) / (maximum value - minimum value)". For data with abnormal extreme values, such as a single reimbursement amount exceeding 10 times the annual per capita disposable income of the region, the Z-score method is used to identify and mark them. Records with an absolute Z-score greater than 3 are included in the abnormal data pool for manual verification.

[0058] S13. Data Encryption and Secure Transmission. Construct a multi-layered protection system encompassing algorithm hierarchy, key control, and channel encryption.

[0059] 1. Implementation of a tiered encryption strategy: Highly sensitive data, including patient ID numbers, core information on the first page of medical records, and past medical history, are encrypted using the RSA 2048-bit asymmetric encryption algorithm. The public key is used for data encryption, while the private key is stored only in the hardware security module. Batch business data, including medical insurance reimbursement records and drug procurement records, are encrypted using the AES 256-bit symmetric encryption algorithm. The encryption mode selected is GCM to ensure both confidentiality and integrity.

[0060] 2. Full Lifecycle Key Management: Deploy the Utimaco HSM hardware security module to store core keys, establishing a closed-loop process for key generation, distribution, rotation, and destruction. Key generation uses a random number generator (RNG) to generate keys conforming to the NIST standard; distribution is transmitted to trusted nodes via an encrypted channel, and recipients must be authenticated before obtaining the keys; the rotation cycle is set to 90 days for highly sensitive data keys and 30 days for business data keys, with the rotation process executed automatically and the key ledger updated synchronously.

[0061] 3. Encrypted Transmission and Integrity Verification: The transmission channel is built based on the SSL / TLS 1.3 protocol, enabling the TLS_AES_256_GCM_SHA384 encryption suite and disabling insecure protocols such as TLS 1.0 and 1.1. Before transmission, a data digest is generated using the SHA-256 hash algorithm. The sender transmits the data along with the digest, and the receiver recalculates and compares the digest. If they do not match, the data is considered tampered with, immediately triggering a retransmission mechanism and logging the exception.

[0062] S2, Mirror Scanning and Security Risk Prevention.

[0063] S21. Scanning Tool Deployment and Policy Configuration. A dual scanning system is selected, consisting of Clair and Trivy. Clair is responsible for deep vulnerability detection, while Trivy is responsible for fast and lightweight scanning. Tool deployment uses Docker containerization to ensure compatibility with the target environment.

[0064] 1. Scan Scope and Depth Configuration: Covers container base images such as Ubuntu and CentOS, application images such as Python runtime environments and Java application images, and TEE dependency images such as the Occlum image. Scan depth includes underlying operating system kernel vulnerabilities, application layer package vulnerabilities such as OpenSSL and LibSSH, and dependency component vulnerabilities such as Python libraries and Java JAR packages. It also detects malware in the images, sensitive files such as key files and configuration passwords, and non-compliant configurations, such as SSH service not being disabled or root account being directly enabled.

[0065] 2. Scan Frequency and Trigger Mechanism: A dual strategy can be set up, including a mandatory scan before container creation and a full scan scheduled at 2 AM daily. The mandatory scan is a blocking process; images that fail the scan cannot be used for environment building. The scheduled scan is non-blocking, and the scan results are pushed to the security management platform in real time for operations and maintenance personnel to track and handle.

[0066] S22. Vulnerability Mitigation and Closed-Loop Management. Establish a risk-level-based tiered mitigation mechanism to ensure vulnerabilities are traceable and can be closed-loop managed.

[0067] 1. Risk Level Classification and Handling Measures: High-risk vulnerabilities include remote code execution vulnerabilities (such as CVE-2023-20197) and privilege escalation vulnerabilities (such as CVE-2024-21413). Upon discovery, the environment building process should be immediately suspended, a vulnerability remediation ticket should be generated and assigned to developers, requiring them to complete the remediation or replace the image with a security-certified one within 4 hours; Medium-risk vulnerabilities include information disclosure vulnerabilities and low-risk configuration errors. The vulnerability ID, scope of impact, and remediation recommendations should be recorded and included in the runtime monitoring list, with remediation progress reviewed every 24 hours; Low-risk vulnerabilities include software packages that have passed their lifecycle. The scope of impact should be assessed to determine whether to remediate them. If there is no impact, they should be marked as "acceptable risk" and archived.

[0068] 2. Scan Result Archiving and Auditing: All scan results are stored categorized by "Mirror ID - Scan Time - Risk Level," including fields such as vulnerability description, CVSS score, and remediation plan. Scan logs are synchronously integrated into the security information and event management system, serving as the core basis for environmental security compliance auditing, and are retained for no less than one year.

[0069] S3, Building a Trusted Computing Environment.

[0070] S31. Creating and Configuring a gVisor Secure Container. The specific steps for building an isolated computing environment based on gVisor version 1.1.0 are as follows:

[0071] 1. Runtime Environment Deployment: On the Ubuntu 22.04 server, install the gVisor dependency package via apt, and execute "sudo apt-get install runsc" to complete the runsc runtime installation. Configure the Docker daemon by modifying the / etc / docker / daemon.json file, adding ""runtimes": {"runsc": {"path": " / usr / local / bin / runsc"}}", and restarting the Docker service for the configuration to take effect.

[0072] 2. Container Creation and Resource Configuration: A secure container is created using the Docker command, specifying gVisor as the runtime: "docker run --runtime=runsc --name=medical-ins-data-container -d -m 8GB --cpus=2 -v / encrypted-data: / container-data ubuntu:22.04". Resource limits are set to 2 CPU cores and 8GB of memory to prevent the container from excessively consuming system resources. Data mounting uses a bind mount mode, mounting the host machine's encrypted data directory / encrypted-data to the container's / container-data directory, granting the container only read-only permissions.

[0073] 3. Network Security Policy Configuration: Configure container network rules via iptables to allow communication only between containers and the security gateway (IP: 192.168.1.100) on port 443 and the TEE component (IP: 192.168.1.200) on port 5000, while denying all other outbound and inbound connections. Enable gVisor's seccomp filtering mechanism to restrict processes within the container to only calling necessary system calls such as read, write, and execve, while disabling high-risk calls such as fork and mount.

[0074] S32 and TEE environment deployment and initialization. Building a hardware-level trusted execution environment based on Intel SGX servers and Occlum:

[0075] 1. Basic Environment Preparation: Enable SGX functionality on the SGX-compatible server and verify hardware support using the "sgx_enable" tool. Install Occlum dependencies, including libsgx-enclave-common and libsgx-urts, by executing "sudo apt-get install occlum" to complete the Occlum installation.

[0076] 2. TEE Resource Allocation and System Configuration: Allocate 4GB of dedicated EPC memory and 1 dedicated CPU core to the TEE. Create an Enclave using the Occlum command: "occlum new --heap-size 2GB --stack-size 128MB --thread-num 4 occlum-enclave". Configure Occlum system parameters, modify the / etc / occlum.json file within the Enclave, and enable security features such as memory encryption and code integrity verification.

[0077] 3. Application Deployment and Verification: Copy the medical insurance data processing program (such as a Python reimbursement review script) and its dependent libraries (Pandas 2.0.3, NumPy 1.24.3) into the Occlum Enclave, and execute "occlum build occlum-enclave" to complete the build. Calculate the hash value of the program file using the SHA-384 algorithm and compare it with a pre-stored trusted hash value. If they match, the program has not been tampered with, and the program is started to prepare for computation; if they do not match, the deployment is terminated and a security alert is triggered.

[0078] S4, Security Gateway and Access Control Deployment.

[0079] S41. Security Gateway Configuration. NGINX is selected as the security gateway to implement access control and communication encryption.

[0080] 1. Basic Configuration and Encryption Activation: After installing NGINX, modify the ` / etc / nginx / nginx.conf` file and configure the SSL / TLS protocol: `ssl_protocols TLSv1.3; ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256; ssl_prefer_server_ciphers on;`. Deploy the SSL certificate provided by Let's Encrypt and set up an automatic certificate renewal mechanism to avoid communication interruptions due to certificate expiration.

[0081] 2. Network and Forwarding Configuration: Configure firewall rules to open port 443 on the server via firewalld and close unnecessary ports such as 80 and 22. Set up reverse proxy rules to forward legitimate requests from outside to the secure container (172.17.0.2:8080) and the TEE component (172.17.0.3:5000), with a forwarding timeout of 60 seconds to avoid long connections consuming resources.

[0082] S42. Access Control and Traffic Monitoring. Role-based access control (RBAC) models enable fine-grained permission management, coupled with traffic monitoring to identify abnormal behavior.

[0083] 1. RBAC Permission Configuration: Define three core roles: Data administrators can perform data access, encryption, and computation task submission operations; auditors can only query operation logs and scan results, and have no data modification permissions; ordinary users can only receive verified computation results. The system connects to the LDAP authentication system through NGINX's auth_request module. Users must complete identity authentication before accessing the system, and access permissions are assigned according to roles after successful authentication.

[0084] 2. Traffic Monitoring and Anomaly Handling: Deploy the Prometheus + Grafana monitoring suite to collect gateway traffic metrics, including requests per second (QPS), request response time, and error rate. Set anomaly thresholds: trigger alarms when QPS exceeds 100 requests / second, response time exceeds 5 seconds, or error rate exceeds 5%. For abnormal IP addresses that initiate more than 50 invalid requests within 1 minute, add them to the blacklist using the NGINX deny directive to block subsequent access.

[0085] S5. Trusted computation and result verification.

[0086] S51. Computing environment initialization and key distribution.

[0087] 1. Environment Self-Check Process: After starting the secure container and TEE, the self-check script is executed automatically: It checks whether the gVisor seccomp rules are effective and whether the container network connection complies with the policy; it checks the SGX EPC memory integrity and whether the Occlum system configuration is consistent with the default; it verifies whether the data mount directory permissions are read-only. If the self-check fails, an error log is generated and the environment is restarted. If it still fails after 3 restarts, the operations and maintenance personnel are notified for intervention.

[0088] 2. Temporary Key Distribution: The key management system distributes temporary decryption keys to the TEE through a secure gateway. The keys are transmitted using RSA encryption and can only be decrypted by trusted applications within the TEE. The temporary key is valid for 2 hours and automatically expires after the computation task is completed. After expiration, the key will be completely removed from the TEE's memory and cannot be recovered.

[0089] S52. Data Calculation and Process Monitoring. Encrypted data calculations are performed within the TEE, ensuring data confidentiality throughout the process.

[0090] 1. Execution of Computational Tasks: Run corresponding computational programs according to business needs. In medical insurance fund supervision scenarios, execute the "Abnormal Reimbursement Identification Program," which uses a rule engine to match abnormal patterns such as excessive prescriptions and duplicate treatments. In cross-institutional collaboration scenarios, execute the "Patient Treatment Data Aggregation Program," which aggregates medical records from different hospitals to generate a unified health record. Data computation remains encrypted throughout, with temporary decryption only occurring during program execution within the TEE. Intermediate results are encrypted and stored in real-time in dedicated TEE memory, without being written to disk.

[0091] 2. Computation Process Monitoring: Computation metrics, including CPU utilization, memory usage, and program execution progress, are collected through Occlum's monitoring interface. Upon detecting program crashes, memory overflows, or other anomalies, the computation task is immediately terminated, the TEE environment is locked, and logs are saved for subsequent troubleshooting.

[0092] S53. Result Verification and Output. Based on preset rules, perform a full verification of the calculation results to ensure accuracy and compliance.

[0093] 1. Validation rule configuration: Three types of validation rules are preset: logical validation ensures that the result conforms to the business logic, such as reimbursement amount ≤ total treatment cost; range validation restricts the numerical range of the result, such as single hospitalization reimbursement amount 0-100,000 yuan; integrity validation compares the matching degree between the number of result records and the number of input data records, and the deviation must be ≤1%.

[0094] 2. Verification Process and Handling: After calculation, the verification program automatically calls the rule base to perform verification. Successful verification results are encrypted using the AES algorithm and transmitted to the requesting party through a security gateway; failed verification results are intercepted, the failure type (e.g., logical error, range exceeded) is recorded, a repair work order is generated, and the data administrator is notified. The calculation is re-executed after the problem is resolved.

[0095] S6. Operation log auditing and environment destruction.

[0096] S61. Log Recording and Audit Management. Establish a comprehensive log system to meet compliance and audit requirements:

[0097] 1. Log System Configuration: Log4j logging is deployed in both the secure container and the TEE. RollingFileAppender is configured to implement log rotation, with a single log file size limit of 100MB, retaining the 30 most recent files. The log format is uniformly set to "Time-traceId-Operator-Operation Type-Object-Result," where the traceId is used throughout the entire process from data access to result output for easy log traceability.

[0098] 2. Log Storage and Auditing: Logs employ a combination of local storage and off-site backup. Local logs are stored in a read-only directory within the container and retained for 90 days. Every day at midnight, logs are synchronized to an off-site backup server using the rsync tool, and backup logs are retained for one year. Auditors perform daily log audits, focusing on critical logs such as those related to "unauthorized access," "key operations," and "verification failures," and generate weekly audit reports for submission to regulatory authorities.

[0099] S62. Computing Environment Destruction and Data Clearing. Completely destroy the environment after the task is completed to eliminate the risk of residual data.

[0100] 1. Resource Release Process: Stop and delete the secure container using Docker commands: "docker stop medical-ins-data-container && docker rm medical-ins-data-container"; execute "occlum terminate occlum-enclave" to stop the TEE, releasing the CPU and memory resources it occupies. After resource release, update the system resource ledger and mark the resource as "available".

[0101] 2. Data and Trace Removal: The container mount directory and TEE dedicated memory are overwritten three times using the `dd` command, with the overwritten content being random bytes, ensuring that the original data cannot be recovered. The container image and TEE application files are deleted, and the SGX state is reset using the "sgx_reset" tool to clean up all runtime traces. The entire destruction process is logged, including the destruction time, operator, destruction objects, and removal results, serving as the final proof of a data security closed loop.

[0102] This invention provides a data sharing method for a medical insurance scenario, which integrates secure containers and TEE technology to build a secure and reliable protection system to achieve secure sharing of medical insurance data.

[0103] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A data sharing method in a medical insurance scenario, characterized in that, Comprise the following steps: S1. Access multi-source medical insurance data, perform standardization preprocessing to eliminate data heterogeneity, implement hierarchical encryption according to data sensitivity level, transmit through encrypted channel and perform integrity check; S2. Use scanning tools to detect vulnerabilities in containers and TEE dependent images, implement hierarchical treatment based on risk level and archive scanning results; S3. Create a secure container based on gVisor, deploy a TEE environment supported by the Occlum system on an SGX server, and establish a container isolation and hardware trusted protection architecture; S4. Configure a secure gateway to implement communication encryption and request forwarding, assign differentiated permissions based on the RBAC model, and identify and handle abnormal access in combination with traffic monitoring; S5. Complete encrypted data calculation in TEE, ensure calculation security through environment self-checking and temporary key management, and output after checking the calculation results according to the preset rules; S6. Record operation logs throughout the process and implement audit management, destroy the secure container and TEE environment after the task is completed, and clear data and running traces.

2. The method of claim 1, wherein, The step S1 comprises: S11. Interface with medical insurance data sources, structured databases are accessed and field legality and data integrity checks are performed through JDBC or ODBC tools, unstructured data extracts core fields through parsing tools, and PDF format data is converted to structured data through OCR identification; The medical insurance data sources include medical insurance system databases and medical institution information systems; S12. Data standardization preprocessing, unify date field format, map disease diagnosis codes to standard codes and drug codes to national drug base codes, normalize numerical data using range method, and identify abnormal extreme values; S13. Data encryption and secure transmission: highly sensitive data uses RSA asymmetric encryption algorithm, batch business data uses AES symmetric encryption algorithm, key lifecycle management is achieved through hardware security module, transmission channel is built based on SSL and TLS protocols, and data integrity is checked through hash algorithm.

3. The method of claim 1, wherein, The step S2 comprises: S21. Use Clair and Trivy to build a scanning system that covers container base images, application images, and TEE dependent images, and configure scanning strategies such as mandatory scanning before container creation and daily regular full scanning; S22. Divide vulnerabilities into high, medium, and low risk levels, immediately suspend environment building for high-risk vulnerabilities and repair them within a limited period, include medium-risk vulnerabilities in runtime monitoring, archive low-risk vulnerabilities after evaluation, store scanning results according to specifications and access security audit system.

4. The method of claim 1, wherein, The step S3 comprises: S31. Deploy gVisor runtime, create secure containers and limit CPU and memory resources, use bind mount mode to mount encrypted data directory and grant read-only permissions, configure network rules and enable filtering mechanism; S32. Install Occlum system on SGX compatible server, allocate dedicated EPC memory and CPU resources to create Enclave, deploy data processing program and dependent libraries, and start after checking program integrity through hash algorithm.

5. The method of claim 1, wherein, The step S4 comprises: S41. Deploy the security gateway based on NGINX, enable the TLS protocol and encryption suite, configure the firewall rule to open the necessary ports, and set up the reverse proxy forwarding to the security container and TEE component; S42. Define three types of roles, data administrator, auditor, and ordinary user, and assign permissions, implement identity verification through the LDAP authentication system, deploy a monitoring suite to collect traffic indicators, and implement alarm and blocking for access exceeding the threshold and abnormal IP.

6. The method of claim 1, wherein, The step S5 includes: S51. Automatically check the configuration, permissions, and connection status of the container and TEE after startup, and the key management system distributes temporary decryption keys to the TEE through an encrypted channel; S52. Run the abnormal reimbursement identification or diagnosis data aggregation program in the TEE, keep the data encrypted during the calculation process, store the intermediate results in the TEE dedicated memory, collect calculation indicators through the monitoring interface, and handle exceptions; S53. Check the results through logical verification, range verification, and integrity verification, and if the verification is successful, the results are encrypted and transmitted to the demand side, otherwise, a work order is generated and the calculation is restarted.

7. The method of claim 1, wherein, The step S6 includes: S61. Deploy log tools to record the entire process operation, use a unified format, save logs through local storage and off-site backup, and auditors regularly check key logs and generate reports; S62. Stop and delete the security container and TEE, release system resources, overwrite data storage directories and TEE memory with random bytes, delete images and application files, and reset the SGX state, and record the entire process of destruction.

8. The method of claim 4, wherein, The configuration of network rules and the enablement of filtering mechanisms include: (1) Configure container network rules to allow only container, security gateway, and TEE component port communication, and reject other outbound and inbound connections; (2) Enable gVisor's seccomp filtering mechanism to limit container processes to only call necessary system calls, including read, write, and execve.

9. The method of claim 4, wherein, The S32 includes: (1) Enable SGX function on the server, install Occlum dependent components, and execute the command to complete Occlum installation; (2) Allocate memory and CPU resources for TEE, create Enclave through Occlum command, configure Occlum system parameters and Enclave files; (3) Copy the medical insurance data processing program and dependent libraries to the Occlum Enclave, execute the command to complete the build, and through the secure algorithm to compare the file hash value, confirm that it has not been tampered with, and start the program for calculation.

10. The method of claim 1, wherein, In S62, multiple random byte overwrites are performed on the data storage directory and TEE memory using commands, and after deleting the image and application files, the SGX state is reset, and the destruction process log is recorded.

Images