Community endowment resource collaborative scheduling method and device, electronic equipment and storage medium

Abstract

This application relates to the field of blockchain technology and can be applied to the field of digital healthcare. It discloses a method, device, electronic device, and storage medium for collaborative scheduling of community elderly care resources. The method includes: collecting multimodal biometrics of target elderly care users through edge devices at community nodes, encrypting and generating biometric fingerprints as unique identifiers on the blockchain, and constructing a distributed elderly care health data network under a federated learning framework; inputting historical health data, real-time vital signs, community activities, and insurance-related data into an intelligent prediction model containing a time decay factor to calculate health risk levels; triggering corresponding smart contracts according to multi-level compensation rules, determining verification node groups based on service urgency, and executing resource scheduling after successful verification; storing elderly care service-related data on the blockchain, managing the data lifecycle according to rules, generating suitable insurance plans based on user information, and synchronizing them to the associated blockchain nodes. This method improves the intelligence and trustworthiness of community elderly care services.

Description

Technical Field

[0001] This application relates to the field of blockchain technology and can be applied to the field of digital healthcare, particularly to a method, device, electronic device, and storage medium for the collaborative scheduling of community elderly care resources. Background Technology

[0002] Current technological solutions for the elderly care industry suffer from several technical problems, failing to meet actual needs. First, a reliable data sharing mechanism is lacking. Health data, service records, and insurance certificates are scattered across centralized databases belonging to communities, medical institutions, and insurance companies, creating "data silos" that hinder efficient cross-process collaboration and severely restrict the efficiency of health assessments and insurance claims. Second, service and payment coordination is poor. Insurance payments are disconnected from service supply, the payment chain is lengthy and relies on manual review, resource allocation uses manual methods or simple algorithms, resulting in high equipment vacancy rates and inefficient personnel scheduling, failing to dynamically match the real-time needs of the elderly. Third, risk assessment and product adaptability are insufficient. Health risk assessment relies on regular physical examination data and fixed thresholds, failing to integrate dynamic vital signs and activity data, leading to delayed results. Insurance products use fixed rates that do not adjust according to the elderly's health status, resulting in a disconnect from actual risk needs and easily leading to disputes. In addition, security and traceability issues are prominent, the service process lacks reliable recording methods, service quality is difficult to guarantee, centralized data storage leads to a high risk of privacy leakage, and the prepaid model also poses a risk to fund security; cross-entity collaborative response is slow, emergency scenarios require manual information synchronization, supervision cannot conduct real-time audits, and risk management capabilities are weak. Summary of the Invention

[0003] The main technical problem addressed by the implementation method of this application is the inefficient coordination of data, services, and insurance in the technical solutions for the elderly care industry.

[0004] To address the aforementioned technical problems, the first technical solution adopted in this application is: providing a method for collaborative scheduling of community elderly care resources, comprising: collecting multimodal biometrics of target elderly care users through edge computing devices deployed at community nodes; encrypting the multimodal biometrics to generate biometric fingerprints; setting the biometric fingerprints as unique identifiers of the target elderly care users in the blockchain; constructing a distributed community elderly care health data network based on a federated learning framework; inputting the target elderly care users' historical health data, real-time vital sign data, community activity data, and insurance-related data into an intelligent prediction model containing a time decay factor; and calculating the health risks of the target elderly care users through the intelligent prediction model. The system is structured as follows: Based on the health risk level and multi-level compensation rules calculated using dynamic thresholds, a smart contract corresponding to the service level is triggered. The smart contract determines a verification node group within the blockchain network based on service urgency. Once the verification node group passes verification, community elderly care resources are allocated. Medical and nursing data and cultural and entertainment service data generated during the elderly care service process are stored on the main chain and secondary chain of the blockchain, respectively. Lifecycle management is performed on the data on the main chain and secondary chain using preset service value decay rules. A suitable insurance product plan is generated based on the health risk level, service records, and financial data of the target elderly care users. The health risk level, resource allocation results, and insurance product plan are then synchronized to the associated nodes in the blockchain network.

[0005] Optionally, the step of encrypting the multimodal biometrics to generate a biometric fingerprint includes: extracting feature values ​​of the multimodal biometrics to generate an original feature dataset; fusing the original feature dataset with the identification information of the community nodes deploying the edge computing device to obtain a fused dataset; performing operations on the fused dataset using a preset encryption algorithm to obtain a biometric fingerprint that meets a preset length requirement; verifying the unique correspondence between the biometric fingerprint and the target elderly user, and if the verification is successful, obtaining the generated biometric fingerprint.

[0006] Optionally, the step of constructing a distributed community-based elderly care health data network based on a federated learning framework includes: associating and storing the biometric fingerprint with the basic information of the target elderly users to generate a user identity mapping table; configuring the edge computing devices of the community nodes as local training nodes for federated learning, and setting local data access permissions for each local training node; sharing and aggregating the model parameters of each local training node through a federated learning parameter exchange mechanism to generate a global health assessment model; and sending the global health assessment model to each local training node to complete the construction of the distributed community-based elderly care health data network.

[0007] Optionally, the step of calculating the health risk level of the target elderly user through the intelligent prediction model includes: performing data standardization preprocessing on the collected historical health data, real-time vital sign data, community activity data, and insurance-related data to generate a model input dataset; configuring time decay coefficients corresponding to data in different time dimensions in the model input dataset, wherein the decay coefficient of the historical data is greater than the decay coefficient of the real-time vital sign data; inputting the model input dataset with configured time decay coefficients into the intelligent prediction model to drive the intelligent prediction model to perform calculations to obtain an initial health risk value; and mapping the initial health risk value to the corresponding health risk level according to a preset risk level classification threshold.

[0008] Optionally, the step of executing community elderly care resource scheduling after the verification node group passes the verification includes: obtaining real-time status information of schedulable elderly care service resources within the community, wherein the real-time status information includes resource type, current occupancy information, and service response time; filtering from the real-time status information to obtain matching candidate resources based on the service level triggered by the smart contract and the health risk level of the target elderly care user; prioritizing the candidate resources according to the service urgency to generate a resource scheduling sequence; and sending resource allocation instructions to the corresponding service provider nodes within the community according to the resource scheduling sequence, while synchronously updating the status information of the elderly care service resources to the blockchain network.

[0009] Optionally, the step of performing lifecycle management on the data of the main chain and sub-chain according to a preset service value decay rule includes: obtaining the service completion time and data importance level label of the medical care data and cultural and entertainment service data; calculating the data storage duration based on the service completion time and determining the retention value score of the current data based on the preset service value decay rule; marking the medical care data as pending archiving when the storage duration of the medical care data is greater than a preset first duration threshold or the retention value score is less than a preset first value score threshold; marking the cultural and entertainment service data as pending cleanup when the storage duration of the cultural and entertainment service data is greater than a preset second duration threshold or the retention value score is less than a preset second value score threshold; and performing corresponding archiving or cleanup operations on the data of the main chain and sub-chain according to the pending archiving or cleanup status, and synchronizing the updated data status to the blockchain network.

[0010] Optionally, the step of generating a suitable insurance product plan based on the health risk level, service records, and financial data of the target elderly user includes: obtaining service type, service quality, and service preference information from the service records as service record extraction results; obtaining account balance and payment capacity assessment results from the financial data as financial data extraction results; setting basic protection dimension parameters for the insurance product to be generated, using the health risk level as a constraint; inputting the service record extraction results, the financial data extraction results, and the basic protection dimension parameters into an insurance product optimization engine built based on reinforcement learning; driving the product optimization engine to iteratively calculate the input result data and parameters to generate multiple sets of insurance product parameter combinations; performing comprehensive screening and calculation on the multiple sets of insurance product parameter combinations through a preset objective function to obtain a target insurance product parameter combination; and generating an insurance product plan suitable for the target elderly user based on the target insurance product parameter combination and a preset insurance product plan generation engine.

[0011] To address the aforementioned technical problems, the second technical solution adopted in this application is: providing a community elderly care resource collaborative scheduling device, comprising: a biometric fingerprint module, used to collect multimodal biometric features of target elderly care users through edge computing devices deployed at community nodes, and encrypt the multimodal biometric features to generate a biometric fingerprint; an elderly care health data network module, used to set the biometric fingerprint as the unique identifier of the target elderly care user in the blockchain, and construct a distributed community elderly care health data network based on a federated learning framework; a health risk level module, used to input the historical health data, real-time vital sign data, community activity data, and insurance-related data of the target elderly care user into an intelligent prediction model containing a time decay factor, and calculate the health risk level of the target elderly care user through the intelligent prediction model; and an intelligent... The system comprises the following modules: a trigger module for triggering smart contracts corresponding to the service level based on the health risk level and multi-level compensation rules calculated using dynamic thresholds; a senior care resource scheduling module for determining a verification node group in the blockchain network according to the service urgency through the smart contract, and executing community senior care resource scheduling after the verification node group passes verification; an on-chain data cycle module for storing medical care data and cultural and entertainment service data generated during senior care services on the main chain and secondary chain of the blockchain, respectively, and performing lifecycle management on the data on the main chain and secondary chain through preset service value decay rules; and an insurance product solution module for generating suitable insurance product solutions based on the health risk level, service records, and financial data of the senior care target users, and synchronizing the health risk level, resource scheduling results, and insurance product solutions to the associated nodes of the blockchain network.

[0012] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the community elderly care resource collaborative scheduling method as described above.

[0013] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device executes the community elderly care resource collaborative scheduling method as described above.

[0014] Unlike related technologies, this application combines biometric encryption with blockchain, relying on federated learning and smart contracts to achieve trusted management of health data, accurate risk assessment, efficient resource allocation, and insurance matching, thereby improving the intelligence and trustworthiness of community-based elderly care services. Attached Figure Description

[0015] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0016] Figure 1 This is a schematic diagram of the operating environment of the community elderly care resource collaborative scheduling method provided in the embodiments of this application.

[0017] Figure 2 This is a schematic diagram of the execution flow of the community elderly care resource collaborative scheduling method provided in the embodiments of this application.

[0018] Figure 3 This is a schematic diagram of the execution process for constructing a distributed community elderly care health data network in the community elderly care resource collaborative scheduling method provided in the embodiments of this application.

[0019] Figure 4 This is a schematic diagram of the execution process for obtaining health risk levels in the community elderly care resource collaborative scheduling method provided in this application embodiment.

[0020] Figure 5 This is a schematic diagram of the system structure of the community elderly care resource collaborative scheduling device provided in the embodiments of this application.

[0021] Figure 6 This is a schematic diagram of the hardware structure of an electronic device for implementing the collaborative scheduling method for community elderly care resources, as provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0023] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0024] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0025] To facilitate understanding of this embodiment, a detailed description of a community elderly care resource collaborative scheduling method disclosed in this application embodiment will be provided first. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of the operating environment of the community elderly care resource collaborative scheduling method provided in the embodiments of this application, such as... Figure 1 As shown, the execution entity of the community elderly care resource collaborative scheduling method provided in this application embodiment is generally an electronic device with a certain computing power, such as a computer device. In some possible implementations, this community elderly care resource collaborative scheduling method can be implemented by a processor calling computer-readable instructions stored in memory. Figure 1 The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This can be understood as... Figure 1 The number of computer devices shown is merely illustrative and can be expanded in any number according to actual needs.

[0026] Please continue reading. Figure 2 , Figure 2 This is a schematic diagram of the execution flow of the community elderly care resource collaborative scheduling method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: S1. Collect multimodal biometrics of target elderly users through edge computing devices deployed at community nodes, and encrypt the multimodal biometrics to generate biometric fingerprints.

[0027] In the context of community-based elderly care, "edge computing devices deployed at community nodes" specifically refers to smart health terminals at community service stations and medical-grade wearable devices worn by users, such as dynamic electrocardiogram monitoring bracelets and smart gait analysis shoes. These devices can complete data collection and preliminary processing locally within the community, avoiding the privacy risks associated with centralized transmission. "Multimodal biometrics" can include electrocardiograms, gait characteristics, and speech spectrum. Electrocardiograms reflect cardiac electrophysiological activity, gait characteristics can collect information such as step frequency and step length through accelerometers, and speech spectrum can collect the frequency distribution of speech signals through microphones. Combining multi-dimensional features can improve the accuracy of elderly user identification and adapt to the volatile physiological characteristics of the elderly population. "Encrypted processing to generate biometric fingerprints" transforms original biometrics into irreversible digital identifiers. The core purpose is to provide a unique and trustworthy user identity anchor for the blockchain while protecting the privacy of the elderly (by not directly storing original physiological data), supporting subsequent health data association, service scheduling, and other full-process management.

[0028] As an optional implementation, the above-described steps for encrypting multimodal biometrics to generate biometric fingerprints may specifically include the following steps S11 to S14.

[0029] S11. Extract feature values ​​of multimodal biological features to generate the original feature dataset.

[0030] Specifically, for electrocardiograms, time-domain / frequency-domain features such as R-wave peak interval (heart rate variability index) and ST segment offset (myocardial ischemia early warning index) are extracted; for gait features, dynamic features such as gait symmetry and step length standard deviation are calculated using triaxial accelerometer data; and for speech spectra, acoustic features such as Mel-frequency cepstral coefficients and fundamental frequency are extracted using Fourier transform. These feature values ​​are structured and integrated into a "raw feature dataset," which preserves the uniqueness of biological characteristics while removing redundant information, such as filtering noise data generated by slight shaking when elderly people wear the device, improving feature stability and laying the data foundation for subsequent encryption processing.

[0031] S12. The original feature dataset and the identification information of the community nodes where edge computing devices are deployed are merged to obtain the merged dataset.

[0032] Among them, "community node identification information" refers to the unique code of the specific community service point where the edge device is deployed, such as "Monitoring Point 03 of XX Street Elderly Care Service Center". Technically, it will be associated with the original feature dataset through data splicing or feature fusion algorithms (such as weighted matrix fusion). This step realizes the binding of "biometric features - geographic information". In the community elderly care scenario, the service needs of the elderly have significant geographic attributes, such as nearby medical treatment and participation in community activities. The fused data can make the subsequently generated fingerprint implicitly geographic, which is convenient for dividing data permissions and scheduling local resources according to community nodes in the subsequent blockchain network.

[0033] S13. The fused dataset is processed by a preset encryption algorithm to obtain a biometric fingerprint that meets the preset length requirement.

[0034] For example, the "preset encryption algorithm" is an improved HMAC-SHA256 algorithm. First, it performs a hash operation on the fused dataset (original features + community node identifier) ​​using HMAC-SHA256 to ensure data integrity and prevent tampering during transmission or storage. Then, it extracts the first 16 bytes (128 bits) of the result as the final fingerprint. Compared to the traditional 512-bit hash value, this preserves the "avalanche effect" (small changes in input leading to significant differences in output) while reducing the computational and storage pressure on edge devices. This makes it suitable for terminal devices with limited computing power in community nodes, such as portable devices like smart bracelets. In community-based elderly care scenarios, the 128-bit length can meet the uniqueness requirements of millions of users, avoiding fingerprint conflicts between different elderly individuals. Its lightweight nature also makes it suitable for real-time computation on portable devices.

[0035] S14. Verify the unique correspondence between the biometric fingerprint and the target elderly user. If the verification is successful, the generated biometric fingerprint is obtained.

[0036] The process involves distributed comparison across blockchain nodes. The newly generated fingerprint is compared with the hash values ​​of all user fingerprints already stored in the blockchain. If no duplicates are found, the unique identity verification is successful. This step is crucial for ensuring the credibility of identities in community-based elderly care scenarios. Seniors may experience information confusion due to memory decline or require re-registration due to changes in physical characteristics (such as gait alterations caused by illness). Uniqueness verification prevents "one person, multiple identifiers" or "identity misuse," ensuring that subsequent health data and service records are accurately linked to the target user. This provides a reliable basis for insurance payouts and resource allocation, such as avoiding misallocation of elderly care service resources and insurance claims disputes caused by incorrect identification.

[0037] As an example, when a community-based elderly care service center provides health management services to seniors in its jurisdiction, it first collects electrocardiogram (ECG), gait data, and voice signals from the elderly through smart health terminals deployed at the service station and dynamic ECG monitoring bracelets and smart gait analysis shoes worn by the seniors. Next, it extracts feature values ​​such as heart rate variability, gait symmetry, and Mel-frequency cepstral coefficients from this multimodal data to form a raw feature dataset. This raw dataset is then fused with the service center's node identification information to obtain a fused dataset. An improved HMAC-SHA256 algorithm is used to process the fused dataset, extracting the first 16 bytes to generate a 128-bit biometric fingerprint. This fingerprint is then compared with existing elderly fingerprints stored in the blockchain to confirm no duplicates, thus completing fingerprint generation. Subsequent data storage and service scheduling for the elderly use this fingerprint as a unique identifier on the blockchain, protecting the privacy of the elderly while accurately matching them with nearby community elderly care resources and improving service efficiency.

[0038] S2. Set biometric fingerprints as the unique identifiers of target users in the blockchain and build a distributed community elderly care health data network based on a federated learning framework.

[0039] In community-based elderly care scenarios, biometric fingerprints are mapped to blockchain addresses as unique identifiers for seniors, linking them to their health data and service logs to prevent privacy leaks. Simultaneously, multiple community edge devices are organized into distributed nodes. Each node retains local senior data and participates in model training only through parameter sharing. For example, a node in community A does not directly access data from community B, yet it can participate in the training of the global health assessment model, adapting to the requirement of "data remaining within the community, services operating across regions."

[0040] As an alternative implementation method, please continue reading. Figure 3 , Figure 3 This is a schematic diagram illustrating the execution flow of constructing a distributed community elderly care health data network in the community elderly care resource collaborative scheduling method provided in this application embodiment, as shown below. Figure 3 As shown, it can specifically include the following steps S21 to S24.

[0041] S21. Link and store biometric fingerprints with the basic information of the target elderly users to generate a user identity mapping table.

[0042] For example, biometric fingerprints can be linked with basic information such as the elderly person's age, underlying medical conditions, drug allergy history, and emergency contact information in key-value pairs to generate a user identity mapping table. When calling services subsequently, the fingerprint can be used to quickly match key basic information, such as rapidly retrieving information about an elderly person's drug allergies during an emergency.

[0043] S22. Configure the edge computing devices of the community nodes as local training nodes for federated learning, and set the local data access permissions for each local training node.

[0044] For example, edge devices such as smart health servers in community service stations and smart nursing terminals in elderly people's homes can be configured as local training nodes for federated learning; permissions can be set through the RBAC mechanism, such as allowing medical nodes to read complete health data for training, while third-party insurance nodes can only read service record statistics to prevent data abuse.

[0045] S23. The model parameters of each local training node are shared and aggregated through the federated learning parameter exchange mechanism to generate a global health assessment model.

[0046] For example, using the federated averaging algorithm, each local node trains a local model based on its own elderly data, and then encrypts and uploads the model parameters to the server; the server aggregates the parameters according to the proportion of data volume of each node to generate a global health assessment model. A time decay factor can be introduced during training to make the model fit the current health status of the elderly.

[0047] S24. Send the global health assessment model to each local training node to complete the construction of a distributed community elderly care health data network.

[0048] The federated learning server encrypts and distributes the aggregated global health assessment model to each local training node. Nodes then update their local models, completing the construction of the distributed network. For example, when an elderly person moves between communities, the new community node can provide consistent services based on the elderly person's fingerprint association data through the global model.

[0049] As an example, when a street-level elderly care service station was building a health data network across three communities, it first associated each senior citizen's biometric fingerprint with their basic information. For instance, for 72-year-old Grandpa Wang, the fingerprint mapping table recorded "Underlying diseases: Type II diabetes + Allergic drugs: Penicillin + Emergency contact: Son Wang," facilitating quick retrieval of key information for subsequent services. Next, each community's smart health terminal was configured as a local training node for federated learning, with permissions set: community medical staff nodes could read the seniors' complete health data, while partner insurance institution nodes could only view service frequency statistics. Subsequently, each of the three community nodes trained a local model based on its local senior data, encrypted the model parameters, and uploaded them to the street-level server. The server aggregated the parameters according to the percentage of seniors in each community (e.g., 40% in Community A, 35% in Community B, and 25% in Community C) to generate a global health assessment model. Finally, the server distributed the global model to each community node, completing the network construction. Subsequently, regardless of which community a senior citizen visited, that community node could provide consistent health assessment services through the global model combined with the senior's fingerprint association data.

[0050] Through steps S21 to S24 above, the dual goals of "data security and service efficiency" can be achieved in community-based elderly care scenarios. On the one hand, the association between biometric fingerprints and basic information, along with access control, ensures that the privacy of the elderly is not leaked while ensuring that roles such as medical care and insurance can obtain data as needed. On the other hand, model training and distribution under the federated learning framework allows each community node to have a global health assessment model adapted to the characteristics of elderly people in multiple communities without sharing raw data. This significantly improves the accuracy of health assessments and the consistency of cross-community services, providing reliable technical support for subsequent health risk prediction and resource allocation.

[0051] S3. Input the historical health data, real-time vital sign data, community activity data, and insurance-related data of the target elderly care users into the intelligent prediction model that includes a time decay factor. The intelligent prediction model will then calculate the health risk level of the target elderly care users.

[0052] In the context of community-based elderly care, the input "historical health data" can include the elderly person's physical examination reports and chronic disease management records from the past year; "real-time vital signs data" can be collected in real time via smart bracelets, including heart rate, blood pressure, and blood oxygen saturation; "community activity data" can include the frequency and duration of the elderly person's participation in community rehabilitation training and recreational activities; and "insurance-related data" can include the elderly person's annual insurance payment records and past claims. The intelligent prediction model uses a time decay factor to assign differentiated weights to data with different timeframes. For example, physical examination data from one month ago (historical data) has a lower weight than real-time heart rate data from one hour ago (real-time data). Ultimately, it calculates a risk level that reflects the elderly person's current health status, providing the community with precise health intervention guidelines, such as prioritizing home visits for high-risk elderly individuals.

[0053] As an alternative implementation method, please continue reading. Figure 4 , Figure 4 This is a schematic diagram of the execution flow for obtaining health risk levels in the community elderly care resource collaborative scheduling method provided in this application embodiment, such as... Figure 4 As shown, the process can specifically include the following steps S31 to S34.

[0054] S31. Perform data standardization preprocessing on the collected historical health data, real-time vital sign data, community activity data, and insurance-related data to generate the model input dataset.

[0055] The data standardization preprocessing step involves eliminating the dimensional differences between different data types. For example, data of different magnitudes, such as "blood pressure value (unit: mmHg)," "activity duration (unit: minutes)," and "payment amount (unit: yuan)," can be converted into a uniform format with a mean of 0 and a standard deviation of 1 within the [0,1] interval through Min-Max standardization or Z-Score standardization. In community-based elderly care, this step can prevent the model from being biased towards a certain type of data due to differences in data magnitude. For example, it can prevent the impact of "payment amount (larger value)" on the model from exceeding that of "abnormal blood pressure value (smaller but critical value)." This ensures the accuracy of subsequent model calculations and generates a structured dataset that meets the model input requirements.

[0056] S32. Configure the time decay coefficients for different time dimensions of the model input dataset, wherein the decay coefficient of historical data is greater than that of real-time vital signs data.

[0057] The "time decay coefficient" is a weighting coefficient set based on the interval (Δt) between the data collection time and the current time. Historical data (e.g., a physical examination report from one year ago) has a lower time sensitivity, so a larger decay coefficient is configured (e.g., 0.6). Real-time vital sign data (e.g., heart rate data from 10 minutes ago) has a higher time sensitivity, so a smaller decay coefficient is configured (e.g., 0.2). In community-based elderly care scenarios, this configuration reflects the dynamic changes in the health status of the elderly. For example, an elderly person may not have had hypertension one year ago, but their current real-time blood pressure may be consistently high. By using a smaller decay coefficient, real-time data can have a higher weight in the model, avoiding historical data from misleading the current health risk assessment results.

[0058] S33. Input the model input dataset after configuring the time decay coefficient into the intelligent prediction model, and drive the intelligent prediction model to perform calculations to obtain the initial health risk value.

[0059] In this process, a standardized dataset containing time decay coefficients is input into an intelligent prediction model (such as a hybrid neural network model based on LSTM-Transformer). The model then adjusts the weights of different time-sensitive data based on the decay coefficients for feature extraction and computation. For example, the model assigns high weights to "real-time high heart rate data with a decay coefficient of 0.2" to focus on capturing the abnormal cardiac load reflected by this data, while reducing the influence of "physical examination data from one year ago with a decay coefficient of 0.6". Finally, it outputs a continuous value (e.g., 85.6) as an initial health risk value, which intuitively reflects the severity of the elderly person's current health risk.

[0060] S34. Based on the preset risk level classification threshold, map the initial health risk value to the corresponding health risk level.

[0061] First, based on a sample of health data of elderly people in the community, risk level classification thresholds are set through statistical analysis. For example, the initial health risk value is divided into: [0, 30) for low risk, [30, 70) for medium risk, and [70, 100] for high risk. In community-based elderly care, this step transforms abstract numerical values ​​into actionable service criteria. For example, when the initial health risk value is 85.6, it is mapped to a high-risk level, and the community can trigger a high-level service response accordingly, such as arranging for medical staff to monitor health 24 hours a day and coordinating emergency medical resources to be on standby.

[0062] Through steps S31 to S34 above, accurate health risk levels tailored to the current condition of elderly individuals can be generated for community-based elderly care scenarios. Data standardization preprocessing eliminates dimensional differences and avoids interference from single data types in the assessment results; differentiated configuration of time decay coefficients gives higher weight to key data such as real-time vital signs, aligning with the dynamic changes in elderly health and reducing misjudgments caused by outdated historical data; further, through model calculations and threshold mapping, abstract numerical values ​​are transformed into actionable risk levels, providing clear service guidelines for the community, such as quickly identifying high-risk elderly individuals and prioritizing the allocation of care resources, improving the timeliness and targeting of health interventions.

[0063] S4. Trigger the smart contract for the corresponding service level based on the health risk level and the multi-level compensation rules calculated based on dynamic thresholds.

[0064] In the context of community-based elderly care, the "health risk level" is the result obtained through the intelligent prediction model mentioned earlier (e.g., low, medium, and high levels). The "multi-level compensation rule based on dynamic threshold calculation" refers to a rule system that dynamically adjusts the compensation threshold based on changes in the elderly person's health risk and insurance payment status. The dynamic threshold can be determined by real-time calculation of the "fluctuation range of health risk level" and "monthly insurance payment completion rate." For example, when an elderly person's health risk level rises from "medium" to "high" (fluctuation range ≥ 1 level) and the payment completion rate is 100%, the compensation threshold is lowered by 20%, triggering a higher proportion of insurance compensation. The "smart contract" is automated execution code deployed on the blockchain, with built-in mapping logic of "risk level - compensation ratio - service level." For example, when an elderly person has a high risk level and triggers the three-level compensation rule, the smart contract automatically triggers a high service level of "24-hour in-home medical care + monthly rehabilitation equipment subsidy," without manual review. This improves the response efficiency of community-based elderly care services and ensures transparency and trustworthiness in compensation and service execution through the immutability of the blockchain, avoiding disputes.

[0065] S5. Determine the verification node group in the blockchain network according to the service urgency through smart contracts. Once the verification node group passes the verification, the community elderly care resources will be allocated.

[0066] In community-based elderly care scenarios, smart contracts automatically determine the urgency of services based on the triggered service level (e.g., emergency services for high-risk elderly are "urgent," while routine physical examinations are "general"). A certain number of nodes are randomly selected from the blockchain network to form a verification node group (more nodes are selected for urgent services to improve verification efficiency). The verification node group verifies the authenticity and compliance of service requests by comparing user health data and service rules stored in the blockchain. For example, it verifies whether an elderly person's high-risk level is genuine and whether the triggered service complies with the contract. Once verification is successful, the smart contract automatically initiates a resource scheduling process to ensure that community elderly care resources (e.g., medical personnel, rehabilitation equipment) are quickly matched to the demand side, avoiding delays caused by manual intervention.

[0067] As an optional implementation method, the above-mentioned process of allocating community elderly care resources may specifically include the following steps S51 to S54.

[0068] S51. Obtain real-time status information of dispatchable elderly care service resources within the community, including resource type, current occupancy information, and service response time.

[0069] For example, by using IoT sensors and a real-time blockchain synchronization mechanism, dynamic data on various elderly care service resources within the community can be collected. "Resource types" include family doctors, rehabilitation therapy equipment, and ambulances; "Current Occupancy Information" shows whether the resource is in service (e.g., "Dr. Zhang: Currently serving the elderly in room 301, expected to be available in 1 hour"); "Service Response Time" refers to the estimated time for the resource to reach the user's location (e.g., "Community Ambulance: Approximately a 5-minute drive from the elderly in Building 7"). In community-based elderly care, this step provides a data foundation for resource scheduling. For instance, when an elderly person suddenly feels unwell, the system can quickly determine which medical personnel are available and the location of the nearest ambulance.

[0070] S52. Based on the service level triggered by the smart contract and the health risk level of the target elderly users, filter from real-time status information to obtain matching candidate resources.

[0071] The "service level triggered by smart contracts" corresponds to preset resource configuration standards (e.g., Level 1 service requires a general practitioner and an electrocardiograph, while Level 2 service requires a caregiver and a blood pressure monitor). This is combined with the user's health risk level (e.g., high-risk users should be prioritized for resources with emergency medical capabilities), and resources meeting the criteria are selected from real-time status information. For example, when a high-risk elderly person triggers Level 1 service, the system will select a combination of "available general practitioner + immediately available electrocardiograph + response time < 10 minutes" from the resource pool as candidate resources. This ensures accurate matching of resources and needs, avoiding the waste of low-priority resources in high-demand scenarios.

[0072] S53. Prioritize candidate resources according to service urgency to generate a resource scheduling sequence.

[0073] The "service urgency" is determined by the smart contract based on factors such as the user's health risk level and symptom type (e.g., a heart attack warning is "top emergency," and routine medication delivery is "normal emergency"). The urgency is converted into a quantifiable index using an assignment method (e.g., top emergency = 100 points, normal = 30 points). This index is then combined with parameters such as the response time and resource capabilities of candidate resources to calculate a comprehensive score. The candidates are then sorted from highest to lowest score to generate a scheduling sequence. For example, in a top emergency scenario, the combination of "an ambulance with a 5-minute response time + a doctor with emergency medical qualifications" scores higher than the combination of "a normal vehicle with a 15-minute response time + a caregiver," and is prioritized in the scheduling sequence to ensure the most urgent needs receive the fastest response.

[0074] S54. Send resource allocation instructions to the corresponding service provider nodes in the community according to the resource scheduling sequence, and synchronously update the status information of elderly care service resources to the blockchain network.

[0075] The system sends instructions to service-providing nodes sequentially according to the scheduling sequence (e.g., sending "Immediately dispatch Dr. Wang with an electrocardiograph to Room 201, Building 7" to the community hospital terminal). These instructions are transmitted encrypted to ensure immutability. Simultaneously, resource status information (e.g., "Dr. Wang: Departed, in service," "Electrocardiograph: Allocated") is written to the blockchain in real time, and all nodes are updated synchronously to avoid duplicate resource scheduling. For example, if a rehabilitation therapy device has been scheduled to Building 3, the blockchain will mark its "occupied" status, which can be obtained in real time by other community nodes, preventing duplicate allocation instructions from being sent to the same device and improving the utilization efficiency of community elderly care resources.

[0076] Through steps S51 to S54 above, a highly efficient mechanism of "data-driven, precise matching, and dynamic synchronization" can be built for the scheduling of community elderly care resources. First, the acquisition of real-time resource status information allows the system to clearly understand the occupancy and response capabilities of resources such as medical personnel and rehabilitation equipment within the community, avoiding "blind resource allocation." Second, by combining service level and health risk level screening logic, it ensures that the urgent needs of high-risk elderly can be matched with resources with corresponding capabilities (such as emergency medical care and equipment), reducing resource mismatch. Third, generating a scheduling sequence based on service urgency prioritizes rapid response to critical and urgent needs, avoiding delays. Finally, the synchronization of instruction issuance with blockchain status prevents duplicate resource scheduling and ensures full-process data traceability, significantly improving the utilization efficiency and service reliability of community elderly care resources, and meeting the core needs of the elderly for timely and stable services.

[0077] S6. Store medical care data and cultural and entertainment service data generated during the elderly care service process to the main chain and secondary chain of the blockchain respectively, and perform lifecycle management on the data of the main chain and secondary chain through preset service value decay rules.

[0078] In community-based elderly care scenarios, the main blockchain, due to its high security and immutability, is specifically used to store medical and nursing data (such as elderly people's outpatient medical records, medication records, and rehabilitation assessment reports). This type of data is crucial for health diagnosis and medical liability tracing, and its integrity must be guaranteed over the long term. The secondary blockchain stores cultural and recreational service data (such as attendance records and photos of elderly people participating in community calligraphy and painting classes and choir activities). This type of data has high timeliness requirements and lower long-term storage value. The "service value decay rule" is a lifecycle management logic set based on data type and storage duration. For example, the value of medical and nursing data decays slowly over time, while the value of cultural and recreational service data decays rapidly. This rule allows for the rational allocation of blockchain storage resources, avoiding excessive storage pressure on the main blockchain while ensuring that critical data is not lost.

[0079] As an optional implementation, the above-described data lifecycle management process may specifically include the following steps S61 to S65.

[0080] S61. Obtain service completion time and data importance level labels for medical care data and cultural and entertainment service data.

[0081] The system uses blockchain timestamps to record "service completion time" (e.g., automatically generated timestamps at the end of medical care services, or system-recorded timestamps after the closing of cultural and recreational activities). "Data importance level labels" are preset by the system based on the data's purpose. For example, in medical care data, "myocardial infarction emergency treatment records" are marked as "Level 1 Importance," and "routine blood pressure measurement records" are marked as "Level 2 Importance." In cultural and recreational service data, "annual community arts performance participation records" are marked as "Level 3 Importance," and "single square dance activity check-in" is marked as "Level 4 Importance." In community-based elderly care, this step provides foundational data for subsequent value assessments, such as quickly distinguishing between emergency data that needs to be prioritized and ordinary activity data that can be periodically cleared.

[0082] S62. Calculate the data storage duration based on the service completion time, and determine the retention value score of the current data based on the preset service value decay rule.

[0083] The "storage duration" is calculated by subtracting the service completion time from the current system time (for example, if the completion time of medical and nursing data is January 1, 2024, and the current time is July 1, 2024, the storage duration is 6 months). The "preset service value decay rule" can be calculated using a quantitative formula to determine the retention value score. For example, the retention value score for medical and nursing data = initial score × (1 - 0.05 × storage duration / 12) (where 0.05 is the annual decay coefficient), and the retention value score for cultural and entertainment service data = initial score × (1 - 0.3 × storage duration / 3) (where 0.3 is the quarterly decay coefficient). For example, medical and nursing data of "Level 1 Importance" has an initial score of 100 points, and its retention value score after 6 months of storage is 97.5 points; cultural and entertainment data of "Level 4 Importance" has an initial score of 50 points, and its retention value score after 3 months of storage is 35 points, directly reflecting the current storage value of the data.

[0084] S63. When the storage duration of medical care data exceeds a preset first duration threshold, or the retention value score is less than a preset first value score threshold, the medical care data is marked as pending archiving.

[0085] The "preset first duration threshold" and "first value score threshold" are set for medical and nursing data. For example, the first duration threshold is set to 5 years (i.e., storing medical and nursing data older than 5 years), and the first value score threshold is set to 60 points (i.e., retaining medical and nursing data with a value score lower than 60 points). In community-based elderly care, when an elderly person's "Level 2 Important" routine physical examination record from 5 years ago (stored for 6 years, retaining a value score of 55 points) meets both of the above conditions, the system automatically marks it as pending archiving. Archiving is not deletion, but rather migrating the data to a distributed storage system (such as IPFS) associated with the blockchain. This frees up main chain storage space and allows for retrieval via the main chain index when needed (e.g., for tracing medical disputes).

[0086] S64. When the storage duration of cultural and entertainment service data exceeds a preset second duration threshold, or the retention value score is less than a preset second value score threshold, the cultural and entertainment service data is marked as pending cleanup.

[0087] The "preset second duration threshold" and "second value score threshold" are set for cultural and recreational service data. For example, the second duration threshold is set to 1 year (retaining cultural and recreational service data older than 1 year), and the second value score threshold is set to 30 points (retaining cultural and recreational service data with a value score lower than 30 points). For example, an elderly person's attendance record for a single square dance activity two years ago (stored for 24 months, retaining a value score of 10 points) would be marked as pending cleanup if the above conditions are met. In community-based elderly care, this type of data is meaningless for long-term storage (e.g., there is no need to assess the elderly person's current needs through a single activity record from two years ago), and marking it as pending cleanup avoids wasting secondary chain storage resources.

[0088] S65. Based on the pending archiving or pending cleanup status, perform corresponding archiving or cleanup operations on the main chain and sub-chain data, and synchronize the updated data status to the blockchain network.

[0089] The system identifies medical and nursing data awaiting archiving and automatically migrates it to a distributed storage system, recording the archiving index in the main chain (e.g., "Myocardial infarction emergency record on January 1, 2024, has been archived to IPFS address XXX"). After identifying cultural and entertainment service data awaiting cleanup, the system performs deletion operations according to a preset cycle (e.g., the 1st of each month), freeing up storage space on the secondary chain. Once the operation is complete, the data's "archiving / cleanup status" and update time are written to the blockchain in real time, and all nodes are updated synchronously. For example, community hospital nodes and elderly care service center nodes can know in real time that certain medical data has been archived and can retrieve it through the index, ensuring consistent data status across the entire network and avoiding query errors caused by asynchronous data status.

[0090] Through steps S61 to S65 above, a data lifecycle management system of "categorized storage, dynamic control, and resource optimization" can be built for community-based elderly care scenarios. First, accurately acquiring the service completion time and importance tags of data lays the foundation for differentiated management and avoids the mixing of medical care and cultural / entertainment data. Second, quantifying the data retention value through service value decay rules makes data management more objective, for example, preventing the premature cleanup of highly important medical data and the long-term occupation of low-value cultural / entertainment data in storage. Third, marking the status of data to be archived / cleaned according to thresholds and executing corresponding operations not only preserves the traceability value of medical data through archiving but also releases secondary chain resources through cleanup, avoiding storage redundancy. Finally, the blockchain synchronously updates the data status, ensuring data consistency across all community nodes, improving the accuracy of data query and retrieval, and adapting to the needs of community-based elderly care where "medical data needs to be long-term reliable and cultural / entertainment data can be dynamically transferred."

[0091] S7. Generate suitable insurance product plans based on the health risk level, service records, and financial data of the target elderly users, and synchronize the health risk level, resource allocation results, and insurance product plans to the associated nodes of the blockchain network.

[0092] In community-based elderly care scenarios, "health risk level" determines the focus of insurance product coverage (e.g., high-risk elderly need to focus on critical illness and emergency care), "service records" reflect the elderly's actual needs for elderly care services (e.g., frequent use of rehabilitation services requires additional rehabilitation subsidy coverage), and "financial data" reflects the elderly's ability to pay (e.g., stable account balances allow for recommendations of long-term insurance products). By combining these three factors to generate a tailored solution, a "one-size-fits-all" insurance recommendation model can be avoided. For example, for high-risk elderly who frequently use rehabilitation services and have moderate payment capacity, a product can be customized with "basic critical illness coverage + rehabilitation expense subsidy + monthly premium." Simultaneously, synchronizing relevant information to blockchain-connected nodes (e.g., insurance institution nodes, community service nodes) enables data sharing. Insurance institutions can quickly verify the elderly's risk level, and the community can simultaneously know the scope of the elderly's insurance coverage, improving service collaboration efficiency.

[0093] As an optional implementation, the process of generating the adapted insurance product solution described above may specifically include the following steps S71 to S77.

[0094] S71. Obtain service type, service quality, and service preference information from service records as the service record extraction results.

[0095] S72. Obtain the account balance and payment capacity assessment results from the funding data as the funding data extraction results.

[0096] S73. Set the basic protection dimension parameters of the insurance product to be generated, based on the health risk level.

[0097] Among them, the "health risk level" (e.g., low, medium, high) corresponds to different protection priorities. Technically, the core parameters of the basic protection dimension are set according to the level: for example, the basic protection dimension of low-risk elderly is "accidental medical treatment + general physical examination subsidy", with parameters set as "accidental medical treatment coverage of 50,000 yuan, physical examination subsidy once a year (maximum of 800 yuan)"; the basic protection dimension of high-risk elderly is "critical illness medical treatment + emergency transport subsidy + chronic disease medication subsidy", with parameters set as "critical illness medical treatment coverage of 300,000 yuan, emergency transport subsidy maximum of 2,000 yuan per instance, and chronic disease medication subsidy of 300 yuan per month".

[0098] S74. Input the service record extraction results, fund data extraction results, and basic protection dimension parameters into the insurance product optimization engine built on reinforcement learning.

[0099] The insurance product optimization engine, built on reinforcement learning, uses meeting the protection needs of the elderly as its reward objective and controlling premium costs as its constraint. It continuously learns the mapping relationship between different data combinations and the optimal insurance plan through an intelligent agent. Input data includes: service record extraction results (e.g., "preference for rehabilitation services"), financial data extraction results (e.g., "good payment ability"), and basic protection dimension parameters (e.g., "critical illness coverage of 300,000 yuan for high-risk elderly"). In community-based elderly care, the engine can combine historical cases (e.g., insurance plans chosen by elderly people with similar risk levels and service preferences) to quickly identify optimization directions, such as prioritizing adjustments to parameters related to rehabilitation protection.

[0100] S75 drives the product optimization engine to perform iterative calculations on the input result data and parameters to generate multiple sets of insurance product parameter combinations.

[0101] The optimization engine uses multiple rounds of iterative calculations to adjust the core parameters of insurance products (coverage amount, premium payment method, coverage period, and subsidy ratio) to generate multiple feasible combinations. For example, based on data from high-risk elderly individuals, the engine can generate combination 1: "Critical illness coverage of 300,000 yuan + rehabilitation subsidy of 400 yuan per month + annual premium of 9,000 yuan"; combination 2: "Critical illness coverage of 250,000 yuan + rehabilitation subsidy of 350 yuan per month + monthly premium of 700 yuan"; combination 3: "Critical illness coverage of 350,000 yuan + rehabilitation subsidy of 450 yuan per month + annual premium of 10,000 yuan," etc. Each combination meets the basic conditions of "coverage of core risks + premium matching payment capacity," providing multiple options for subsequent screening.

[0102] S76. By using a preset objective function, a comprehensive screening and calculation is performed on multiple combinations of insurance product parameters to obtain the target insurance product parameter combination.

[0103] The preset objective function comprehensively considers three dimensions: coverage adequacy, premium reasonableness, and service matching. For example, the objective function = (coverage adequacy score × 0.5) + (premium reasonableness score × 0.3) + (service matching score × 0.2). Each dimension is scored based on the performance of the parameter combination (maximum score 100 points). For example, combination 2 above has a coverage adequacy score of 85 points (the coverage amount is slightly low but meets basic needs), a premium reasonableness score of 90 points (the monthly premium of 700 yuan matches the payment ability), and a service matching score of 88 points (the rehabilitation subsidy matches the preference). The comprehensive score is 85 × 0.5 + 90 × 0.3 + 88 × 0.2 = 86.1 points, which is higher than combination 1 (82 points) and combination 3 (83 points). Therefore, it is selected as the parameter combination of the target insurance product.

[0104] S77. Based on the combination of target insurance product parameters and the preset insurance product scheme generation engine, generate an insurance product scheme suitable for the target elderly user.

[0105] The "preset insurance product plan generation engine" includes built-in insurance clause templates and parameter mapping rules. Technically, it takes a combination of target parameters (e.g., "critical illness coverage of 250,000 yuan + monthly rehabilitation subsidy of 350 yuan + monthly premium of 700 yuan") and inputs them into the template to automatically generate a complete plan text. This text includes the scope of coverage ("covering 20 critical illnesses and monthly rehabilitation expense subsidy"), payment method ("automatic deduction from the retirement account on the 5th of each month"), and claims process ("after the community node submits the application, the blockchain automatically verifies the risk level and service records, and pays out within 3 working days"). In community-based elderly care, the generated plan can be directly pushed to the elderly's terminal (e.g., a smart retirement bracelet) with parameter explanations (e.g., "the monthly rehabilitation subsidy of 350 yuan can be used to pay for community rehabilitation courses") to facilitate the elderly's understanding.

[0106] The community-based elderly care resource collaborative scheduling method provided in this application provides the following features: It generates unique identifiers using biometric encryption and links them to a blockchain to ensure the trustworthiness of elderly users' identities and data privacy; it constructs a distributed health data network based on federated learning to achieve collaborative training of data from multiple communities, improving service consistency across communities; it introduces an intelligent prediction model with a time decay factor to dynamically output health risk levels, improving assessment timeliness; it collects resource status in real time based on smart contracts and the Internet of Things, scheduling elderly care resources according to urgency to avoid resource waste and response delays; it uses blockchain to classify and store data, managing the data lifecycle through value decay rules to balance security and storage efficiency; and it combines multi-dimensional data to generate personalized insurance plans and synchronize them to associated nodes, forming a closed-loop technology process that significantly improves the intelligence, trustworthiness, and efficiency of community-based elderly care services.

[0107] Please continue reading. Figure 5 , Figure 5 This is a schematic diagram of the system structure of the community elderly care resource collaborative scheduling device provided in the embodiments of this application, such as... Figure 5 As shown, the community elderly care resource collaborative scheduling device 50 includes: a biometric fingerprint module 51, an elderly care health data network module 52, a health risk level module 53, a smart contract triggering module 54, an elderly care resource scheduling module 55, an on-chain data cycle module 56, and an insurance product solution module 57.

[0108] The biometric fingerprint module 51 is specifically used to collect multimodal biometric features of target elderly users through edge computing devices deployed at community nodes, and to encrypt the multimodal biometric features to generate biometric fingerprints.

[0109] The elderly care and health data network module 52 is specifically used to set the biometric fingerprint as the unique identifier of the elderly target user in the blockchain, and to build a distributed community elderly care and health data network based on a federated learning framework.

[0110] The health risk level module 53 is specifically used to input the historical health data, real-time vital sign data, community activity data, and insurance-related data of the target elderly care user into an intelligent prediction model containing a time decay factor, and to calculate the health risk level of the target elderly care user through the intelligent prediction model.

[0111] The smart contract triggering module 54 is specifically used to trigger the smart contract corresponding to the service level based on the health risk level and the multi-level compensation rules calculated based on dynamic thresholds.

[0112] The elderly care resource scheduling module 55 is specifically used to determine a verification node group in the blockchain network according to the service urgency through the smart contract, and to execute the community elderly care resource scheduling after the verification node group passes the verification.

[0113] The on-chain data cycle module 56 is specifically used to store medical care data and cultural and entertainment service data generated during the elderly care service process to the main chain and the secondary chain of the blockchain, respectively, and to perform lifecycle management on the data of the main chain and the secondary chain through a preset service value decay rule.

[0114] The insurance product solution module 57 is specifically used to generate a suitable insurance product solution based on the health risk level, service records and financial data of the target elderly user, and to synchronize the health risk level, resource scheduling results and insurance product solution to the associated nodes of the blockchain network.

[0115] As an optional implementation, the biometric fingerprint module 51 is further specifically used to extract the feature values ​​of the multimodal biometrics to generate an original feature dataset; fuse the original feature dataset and the identification information of the community nodes deploying the edge computing device to obtain a fused dataset; perform operations on the fused dataset using a preset encryption algorithm to obtain a biometric fingerprint that meets the preset length requirement; verify the unique correspondence between the biometric fingerprint and the target elderly user, and if the verification is successful, the generated biometric fingerprint is obtained.

[0116] As an optional implementation, the elderly care health data network module 52 is further configured to associate and store the biometric fingerprint with the basic information of the target elderly user to generate a user identity mapping table; configure the edge computing device of the community node as a local training node for federated learning, and set the local data access permissions of each local training node; share and aggregate the model parameters of each local training node through a federated learning parameter exchange mechanism to generate a global health assessment model; and send the global health assessment model to each local training node to complete the construction of the distributed community elderly care health data network.

[0117] As an optional implementation, the health risk level module 53 is further specifically used to perform data standardization preprocessing on the collected historical health data, real-time vital sign data, community activity data, and insurance-related data to generate a model input dataset; configure time decay coefficients corresponding to data in different time dimensions in the model input dataset, wherein the decay coefficient of the historical data is greater than the decay coefficient of the real-time vital sign data; input the model input dataset with configured time decay coefficients to the intelligent prediction model, drive the intelligent prediction model to perform calculations to obtain an initial health risk value; and map the initial health risk value to the corresponding health risk level according to a preset risk level classification threshold.

[0118] As an optional implementation, the elderly care resource scheduling module 55 is further configured to obtain real-time status information of dispatchable elderly care service resources within the community, wherein the real-time status information includes resource type, current occupancy information, and service response time; filter from the real-time status information according to the service level triggered by the smart contract and the health risk level of the target elderly care user to obtain matching candidate resources; prioritize the candidate resources according to the service urgency to generate a resource scheduling sequence; send resource allocation instructions to the corresponding service providing nodes within the community according to the resource scheduling sequence, and synchronously update the status information of the elderly care service resources to the blockchain network.

[0119] As an optional implementation, the on-chain data cycle module 56 is further specifically used to obtain the service completion time and data importance level label of the medical care data and cultural and entertainment service data; calculate the data storage duration based on the service completion time and determine the retention value score of the current data based on a preset service value decay rule; when the storage duration of the medical care data is greater than a preset first duration threshold, or the retention value score is less than a preset first value score threshold, the medical care data is marked as pending archiving; when the storage duration of the cultural and entertainment service data is greater than a preset second duration threshold, or the retention value score is less than a preset second value score threshold, the cultural and entertainment service data is marked as pending cleanup; based on the pending archiving or pending cleanup status, corresponding archiving or cleanup operations are performed on the data of the main chain and the sub-chain, and the updated data status is synchronized to the blockchain network.

[0120] As an optional implementation, the insurance product solution module 57 is specifically used to: extract service type, service quality, and service preference information from the service records as service record extraction results; extract account balance and payment capacity assessment results from the financial data as financial data extraction results; set basic protection dimension parameters for the insurance product to be generated, using the health risk level as a constraint; input the service record extraction results, the financial data extraction results, and the basic protection dimension parameters into an insurance product optimization engine built based on reinforcement learning; drive the product optimization engine to iteratively calculate the input result data and parameters to generate multiple sets of insurance product parameter combinations; perform comprehensive screening and calculation on the multiple sets of insurance product parameter combinations through a preset objective function to obtain a target insurance product parameter combination; and generate an insurance product solution suitable for the target elderly user based on the target insurance product parameter combination and the preset insurance product solution generation engine.

[0121] It should be noted that the aforementioned community elderly care resource collaborative scheduling device can execute the community elderly care resource collaborative scheduling method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the community elderly care resource collaborative scheduling device can be found in the community elderly care resource collaborative scheduling method provided in the embodiments of this application.

[0122] Figure 6 This is a schematic diagram of the hardware structure of the electronic device for implementing the collaborative scheduling method of community elderly care resources provided in the embodiments of this application, as shown below. Figure 6 As shown, the electronic device 600 includes: One or more processors 610 and memory 620, Figure 6 Take the 610 processor as an example.

[0123] The processor 610 and the memory 620 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0124] The memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the community elderly care resource collaborative scheduling method in the embodiments of this application. The processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 620, thereby implementing the community elderly care resource collaborative scheduling method in the above-described method embodiments.

[0125] The memory 620 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the community elderly care resource coordination and scheduling device. Furthermore, the memory 620 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 620 may optionally include memory remotely located relative to the processor 610, and these remote memories can be connected to the community elderly care resource coordination and scheduling device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0126] The one or more modules are stored in the memory 620. When executed by the one or more processors 610, they perform the community elderly care resource collaborative scheduling method in any of the above method embodiments, for example, the method described above. Figure 2 Method steps S1 to S7, Figure 3 Method steps S21 to S24, Figure 4 Steps S31 to S34 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0127] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0128] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 610 can enable the one or more processors to execute the community elderly care resource collaborative scheduling method in any of the above method embodiments, for example, to execute the above-described Figure 2 Method steps S1 to S7, Figure 3 Method steps S21 to S24, Figure 4 Steps S31 to S34 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0129] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by an electronic device, enable the electronic device to perform the community elderly care resource collaborative scheduling method in any of the above method embodiments, for example, to perform the above-described method. Figure 2 Method steps S1 to S7, Figure 3 Method steps S21 to S24, Figure 4 Steps S31 to S34 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0130] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0131] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0132] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A community pension resource collaborative scheduling method, characterized in that, include: Multimodal biometrics of target elderly users are collected by edge computing devices deployed at community nodes, and the multimodal biometrics are encrypted to generate biometric fingerprints. The biometric fingerprint is set as the unique identifier of the target elderly care user in the blockchain, and a distributed community elderly care health data network based on the federated learning framework is constructed. Input the historical health data, real-time vital sign data, community activity data, and insurance-related data of the target elderly care users into an intelligent prediction model that includes a time decay factor, and calculate the health risk level of the target elderly care users through the intelligent prediction model; Based on the stated health risk level and the multi-level compensation rules calculated based on dynamic thresholds, the smart contract corresponding to the service level is triggered. The smart contract determines a verification node group from the nodes of the blockchain network according to the urgency of the service. Once the verification node group passes the verification, the community elderly care resources are allocated. Medical care data and cultural and entertainment service data generated during the elderly care service process are stored on the main chain and the secondary chain of the blockchain, respectively. Lifecycle management is performed on the data on the main chain and the secondary chain through a preset service value decay rule. Based on the health risk level, service records, and financial data of the target elderly users, a suitable insurance product plan is generated, and the health risk level, resource allocation results, and insurance product plan are synchronized to the associated nodes of the blockchain network.

2. The method for collaborative scheduling of community elderly care resources according to claim 1, characterized in that, The step of encrypting the multimodal biometrics to generate a biometric fingerprint includes: Extract the feature values ​​of the multimodal biometrics to generate the original feature dataset; The original feature dataset and the identification information of the community nodes where the edge computing devices are deployed are fused to obtain a fused dataset; The fused dataset is processed by a preset encryption algorithm to obtain a biometric fingerprint that meets the preset length requirement; Verify the unique correspondence between the biometric fingerprint and the target elderly user. If the verification is successful, the generated biometric fingerprint is obtained.

3. The method for collaborative scheduling of community elderly care resources according to claim 1, characterized in that, The steps for constructing a distributed community-based elderly care and health data network based on a federated learning framework include: The biometric fingerprint is associated with and stored with the basic information of the target elderly users to generate a user identity mapping table; Configure the edge computing devices of the community nodes as local training nodes for federated learning, and set local data access permissions for each local training node; The model parameters of each local training node are shared and aggregated through a federated learning parameter exchange mechanism to generate a global health assessment model. The global health assessment model is sent to each of the local training nodes to complete the construction of the distributed community elderly care health data network.

4. The method for collaborative scheduling of community elderly care resources according to claim 1, characterized in that, The step of calculating the health risk level of the target elderly user through the intelligent prediction model includes: The collected historical health data, real-time vital sign data, community activity data, and insurance-related data are subjected to data standardization preprocessing to generate the model input dataset; Configure the time decay coefficients for data in different time dimensions in the model input dataset, wherein the decay coefficient of the historical data is greater than the decay coefficient of the real-time vital signs data; The model input dataset after configuring the time decay coefficient is fed into the intelligent prediction model, driving the intelligent prediction model to perform calculations to obtain the initial health risk value; Based on a preset risk level classification threshold, the initial health risk value is mapped to the corresponding health risk level.

5. The method for collaborative scheduling of community elderly care resources according to claim 1, characterized in that, The step of scheduling community elderly care resources after the verification node group passes the verification includes: Obtain real-time status information of dispatchable elderly care service resources within the community, wherein the real-time status information includes resource type, current occupancy information, and service response time; Based on the service level triggered by the smart contract and the health risk level of the target elderly user, the real-time status information is filtered to obtain matching candidate resources; The candidate resources are prioritized according to the service urgency to generate a resource scheduling sequence; According to the resource scheduling sequence, resource allocation instructions are sent to the corresponding service provider nodes within the community, and the status information of the elderly care service resources is synchronously updated to the blockchain network.

6. The method for collaborative scheduling of community elderly care resources according to claim 1, characterized in that, The step of performing lifecycle management on the data of the main chain and the secondary chain according to the preset service value decay rule includes: Obtain the service completion time and data importance level tags of the medical care data and cultural and entertainment service data; The data storage duration is calculated based on the service completion time, and the retention value score of the current data is determined based on the preset service value decay rule. When the storage duration of the medical care data exceeds a preset first duration threshold, or the retention value score is less than a preset first value score threshold, the medical care data is marked as pending archiving. When the storage duration of the cultural and entertainment service data exceeds a preset second duration threshold, or the retention value score is less than a preset second value score threshold, the cultural and entertainment service data is marked as pending cleanup. Based on the pending archiving status or the pending cleanup status, perform corresponding archiving or cleanup operations on the data of the main chain and the sub-chain, and synchronize the updated data status to the blockchain network.

7. The method for collaborative scheduling of community elderly care resources according to claim 1, characterized in that, The step of generating a suitable insurance product plan based on the health risk level, service records, and financial data of the target elderly users includes: The service type, service quality, and service preference information are extracted from the service records as the service record extraction results. The account balance and payment capacity assessment results are obtained from the aforementioned financial data as the financial data extraction results; Based on the aforementioned health risk level, set the basic protection dimension parameters for the insurance product to be generated; Input the service record extraction results, the fund data extraction results, and the basic protection dimension parameters into the insurance product optimization engine built based on reinforcement learning; The product optimization engine is driven to iteratively calculate the input result data and parameters to generate multiple sets of insurance product parameter combinations; The target insurance product parameter combination is obtained by comprehensively screening and calculating the multiple sets of insurance product parameter combinations through a preset objective function. Based on the target insurance product parameter combination and the preset insurance product scheme generation engine, an insurance product scheme suitable for the target elderly user is generated.

8. A community-based elderly care resource collaborative scheduling device, characterized in that, include: The biometric fingerprint module is used to collect multimodal biometric features of target elderly users through edge computing devices deployed at community nodes, and to encrypt the multimodal biometric features to generate a biometric fingerprint. The elderly care and health data network module is used to set the biometric fingerprint as the unique identifier of the elderly care target user in the blockchain, and to build a distributed community elderly care and health data network based on a federated learning framework. The health risk level module is used to input the historical health data, real-time vital sign data, community activity data and insurance-related data of the target elderly care users into an intelligent prediction model that includes a time decay factor, and calculate the health risk level of the target elderly care users through the intelligent prediction model. The smart contract triggering module is used to trigger the smart contract corresponding to the service level based on the health risk level and the multi-level compensation rules calculated based on dynamic thresholds. The elderly care resource scheduling module is used to determine a verification node group in the blockchain network according to the service urgency through the smart contract, and to execute the community elderly care resource scheduling after the verification node group passes the verification. The on-chain data lifecycle module is used to store medical care data and cultural and entertainment service data generated during the elderly care service process to the main chain and the secondary chain of the blockchain, respectively, and to perform lifecycle management on the data of the main chain and the secondary chain through a preset service value decay rule. The insurance product solution module is used to generate suitable insurance product solutions based on the health risk level, service records, and financial data of the target elderly users, and to synchronize the health risk level, resource scheduling results, and insurance product solutions to the associated nodes of the blockchain network.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the community elderly care resource collaborative scheduling method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the community elderly care resource collaborative scheduling method according to any one of claims 1-7.

Images