Health state monitoring method and device and electronic equipment

Abstract

The embodiment of the invention provides a health state monitoring method and device and electronic equipment, and relates to the technical field of computers. The method comprises the following steps: acquiring multi-source data of a cockpit domain; the multi-source data comprises physiological data of the user, behavior data of the user and environment data of a cockpit domain; obtaining a health risk score of the user based on the multi-source data and the health state evaluation model; the health state evaluation model is used for evaluating the health state of the user to obtain a health risk score; and determining a corresponding health intervention strategy based on the health risk score of the user. The method can be used for carrying out real-time monitoring and dynamic intervention on the health state of the user in the intelligent cabin driving process, and is used for solving the problems of scene limitation, insufficient data processing, risk response lagging and single intervention strategy in the existing cabin health monitoring technology.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a health status monitoring method, device, and electronic device. Background Technology

[0002] With the development of communication technology, vehicle-to-everything (V2X) technology has been widely applied in the automotive field. As an important component of V2X, the functions of the smart cockpit are constantly expanding and deepening. Real-time monitoring and analysis of the health status of drivers and passengers in the smart cockpit is of paramount practical significance. On the one hand, the driver's health directly affects driving safety, and timely detection of driver health abnormalities can effectively prevent traffic accidents. On the other hand, for passengers, health monitoring functions can provide a more comfortable riding experience. However, current technologies have significant limitations in analyzing the health status of occupants within the cockpit, lacking sufficient adaptability to dynamic scenarios. Summary of the Invention

[0003] The purpose of this application is to provide a health status monitoring method, device, and electronic device, which aims to solve the problems of how to improve the accuracy, scenario adaptability, and user safety of health status monitoring.

[0004] Firstly, a health status monitoring method is provided, comprising: acquiring multi-source data in the cabin domain; the multi-source data includes the user's physiological data, the user's behavioral data, and the cabin domain's environmental data; obtaining the user's health risk score based on the multi-source data and a health status assessment model; the health status assessment model is used to assess the user's health status and obtain the health risk score; and determining corresponding health intervention strategies based on the user's health risk score.

[0005] The health status monitoring method provided in this application acquires multi-source data, including user physiological, behavioral, and environmental data, within the cockpit domain. This multi-source data is then processed based on a health status assessment model to obtain a quantified user health risk score. Subsequently, based on the health risk score, corresponding health intervention strategies are dynamically determined and implemented. This method overcomes the limitations of single data sources by utilizing multi-source data fusion analysis, improving the comprehensiveness and accuracy of user health status assessment. The intelligent quantification assessment achieved through the health status assessment model enhances the objectivity and accuracy of risk identification. Furthermore, the tiered intervention mechanism based on risk scores ensures the timeliness and targeted nature of health intervention strategies. This achieves full-process automation from risk perception to intelligent intervention, effectively improving the reliability of the cockpit health monitoring system and the user experience.

[0006] In conjunction with the first aspect mentioned above, in one possible implementation, the user's health intervention strategy is determined based on the user's health score, including: if the user's health risk score is greater than or equal to a first threshold and less than a second threshold, the user's health intervention strategy is determined as a first health intervention strategy; if the user's health risk score is greater than or equal to the second threshold, the user's health intervention strategy is determined as a second health intervention strategy; wherein, the second threshold is greater than the first threshold; and the intervention intensity of the second health intervention strategy is greater than the intervention intensity of the first health intervention strategy.

[0007] In conjunction with the first aspect mentioned above, in one possible implementation, the first health intervention strategy includes at least one of the following: activating seat vibration, playing voice prompts, and adjusting the cabin environment; the second health intervention strategy includes: establishing a connection with a telemedicine service platform and matching medical resources to provide corresponding medical services.

[0008] In conjunction with the first aspect mentioned above, one possible implementation involves establishing a connection with a telemedicine service platform and matching medical resources to provide corresponding medical services. This includes: connecting to the standardized API interface of the telemedicine service platform through a vehicle-to-everything (V2X) platform; transmitting multi-source data to the telemedicine service platform through the standardized API interface, so that the telemedicine service platform can match medical resources for users based on the multi-source data to provide corresponding medical services; wherein, the medical services include registration services or online doctor consultation services.

[0009] In conjunction with the first aspect mentioned above, one possible implementation involves establishing a connection with a telemedicine service platform and matching medical resources to provide corresponding medical services. This includes: connecting to the telemedicine service platform's standardized API interface through a vehicle-to-everything (V2X) platform; obtaining medical resource data from the telemedicine service platform through the standardized API interface; and matching medical resources for users based on multi-source data and the telemedicine service platform's medical resource data to provide corresponding medical services. These medical services may include appointment booking or online doctor consultations.

[0010] In conjunction with the first aspect mentioned above, in one possible implementation, medical resources are matched to users based on multi-source data and medical resource data from a telemedicine service platform to provide corresponding medical services. This includes: determining the user's vital signs status based on multi-source data; matching medical resources to the user based on their vital signs status when the user's vital signs status is not critical, to provide appointment services; and matching medical resources to the user based on their vital signs status when the user's vital signs status is critical, to provide online doctor consultation services.

[0011] In conjunction with the first aspect mentioned above, in one possible implementation, medical resources include at least one of the following: medical institution resources, medical expert resources, historical case resources, and historical medical treatment pathway resources.

[0012] In conjunction with the first aspect mentioned above, one possible implementation involves obtaining a user's health risk score based on multi-source data and a health status assessment model. This includes: preprocessing the multi-source data to extract feature information related to the user's health status; inputting the feature information into the health status assessment model; analyzing the feature information through the health status assessment model to assess the user's health status and obtain a health risk score.

[0013] Secondly, this application provides a health status monitoring device, which includes: an acquisition module, a processing module, and an output module; the acquisition module is used to acquire multi-source data in the cabin domain; the multi-source data includes the user's physiological data, the user's behavioral data, and the cabin domain's environmental data; the processing module is used to obtain the user's health risk score based on the multi-source data and a health status assessment model; the health status assessment model is used to assess the user's health status and obtain the health risk score; the output module is used to determine the corresponding health intervention strategy based on the user's health risk score.

[0014] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, the electronic device implements the method of the first aspect described above.

[0015] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.

[0016] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the steps of the relevant method described in the first aspect above, so as to implement the method of the first aspect above.

[0017] The beneficial effects of the second to fifth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of a health status monitoring system provided in an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of the structure of an in-vehicle system terminal provided in an embodiment of this application;

[0021] Figure 3 A flowchart illustrating a health status monitoring method provided in an embodiment of this application;

[0022] Figure 4 A flowchart illustrating a method for matching medical resources provided in an embodiment of this application;

[0023] Figure 5 A flowchart illustrating another method for matching medical resources provided in this application embodiment;

[0024] Figure 6 A detailed flowchart illustrating a method for matching medical resources provided in this application embodiment;

[0025] Figure 7 A flowchart illustrating another health status monitoring method provided in this application embodiment;

[0026] Figure 8 A detailed flowchart illustrating a health status monitoring method provided in this application embodiment;

[0027] Figure 9 This is a schematic diagram of the composition of a health status monitoring device provided in an embodiment of this application;

[0028] Figure 10 This is a schematic diagram illustrating the composition of another health status monitoring device provided in an embodiment of this application;

[0029] Figure 11 This is a schematic diagram of a health status monitoring device provided in an embodiment of this application. Detailed Implementation

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

[0031] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0032] In the embodiments of this application, the terms "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," "fourth," "fifth," and "sixth" may explicitly or implicitly include one or more of that feature.

[0033] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0034] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0035] As described in the background section, with the rapid development of automotive intelligence and connectivity technologies, the application of vehicle-to-everything (V2X) technology in the automotive field is constantly deepening. The intelligent cockpit, as the core carrier of human-vehicle interaction, has expanded its functions from traditional entertainment and navigation to comprehensive perception and care of the status of drivers and passengers. Among these, real-time monitoring and intelligent analysis of the health status of drivers and passengers has extremely important practical significance.

[0036] However, current health status analysis technologies in the field of smart cockpits still have significant limitations, particularly in their adaptability to dynamic scenarios, making it difficult to meet the complex needs of actual driving and riding. Specifically, most existing technologies are designed based on static monitoring modes in fixed scenarios, such as collecting physiological data only under ideal conditions where the vehicle is stationary or moving at a constant speed, without fully considering dynamic interference factors during vehicle movement. In addition, existing technologies often can only achieve independent monitoring of a single health indicator (such as monitoring only driver fatigue), lacking the ability to fuse and analyze multi-dimensional health data, and thus failing to form a comprehensive assessment of the overall health status of drivers and passengers.

[0037] Based on this, embodiments of this application provide a health status monitoring method, which includes: acquiring multi-source data in the cockpit domain; the multi-source data includes the user's physiological data, the user's behavioral data, and the environmental data of the cockpit domain; obtaining the user's health risk score based on the multi-source data and a health status assessment model; the health status assessment model is used to assess the user's health status and obtain the health risk score; and determining corresponding health intervention strategies based on the user's health risk score. Compared with related technologies, this method overcomes the limitations of a single data source by utilizing multi-source data fusion analysis, improving the comprehensiveness and accuracy of user health status assessment; it enhances the objectivity and accuracy of risk identification by achieving intelligent quantitative assessment through the health status assessment model; and it ensures the timeliness and pertinence of health intervention strategies through a graded intervention mechanism based on risk scores, thereby achieving full-process automation from risk perception to intelligent intervention, effectively improving the reliability of the cockpit health monitoring system and the user experience.

[0038] Figure 1 This is a schematic diagram of a health status monitoring system provided in an embodiment of this application, as shown below. Figure 1 As shown, the health status monitoring system 100 may include: a health risk assessment server 101, an in-vehicle system terminal 102, and a medical system server 103. The health risk assessment server 101 can establish a connection with the in-vehicle system terminal 102 and the medical system server 103 through networks such as the Internet of Vehicles.

[0039] Figure 1 The health risk assessment server 101 can be configured with computing resources divided according to dimensions such as health risk level and user type to support the distributed deployment and efficient computation of health assessment models. For example, the health risk assessment server 101 can be configured with pre-defined machine learning model parameter files, inference interfaces, and service scheduling strategies, such as gradient boosting decision tree models and convolutional neural networks. Furthermore, the health risk assessment server 101 can serve as a backend server to support the inference service of health assessment models.

[0040] In one possible way, Figure 1 The health risk assessment server 101 can also be configured with a unified service management module to provide basic service functions such as user authentication, health data transmission monitoring and load balancing.

[0041] In one possible way, Figure 1 The health risk assessment server 101 can also be responsible for health assessment model version management, service scheduling, resource allocation and performance monitoring, support automated deployment, elastic scaling and service quality assurance of health assessment services, and achieve efficient management and stable operation of health risk assessment for personnel in the cabin domain.

[0042] In one possible way, Figure 1 The health risk assessment server 101 can also be configured with a database or connected to an external database. The database can be used to store health standard data, historical health case data, etc., that need to be accessed during health risk assessment, and in principle, it does not perform model training functions. When the database is an external system connected to the health risk assessment server 101, it can adopt a distributed storage architecture, deployed across multiple availability zones, to improve data loading efficiency and reduce service latency.

[0043] Figure 1 The vehicle-mounted system terminal 102 can be equipped with cabin domain health monitoring software to acquire multi-source data collected in the cabin domain and transmit the data to the health risk assessment server 101. At the same time, it can receive and display health assessment results and information related to the execution of corresponding health intervention strategies.

[0044] In one possible way, Figure 1 The in-vehicle system terminal 102 can be configured with a local data repository. This local data repository can be used to store basic cockpit domain environment data, etc., that needs to be accessed during health monitoring. Furthermore, Figure 1 The vehicle-mounted system terminal 102 can use local software to perform preliminary processing of some simple health monitoring tasks, or directly initiate service requests to the health risk assessment server 101 and obtain the calculated service results.

[0045] Optionally, the vehicle-mounted system terminal 102 can be a central control screen of the vehicle, a dedicated vehicle-mounted terminal device, or other devices capable of data interaction and display within the vehicle. Furthermore, the vehicle-mounted system terminal 102 can also support user interaction via touch, voice, and other methods. This disclosure does not impose any special limitations on the specific form of the vehicle-mounted system terminal 102.

[0046] Figure 1 The medical system server 103 belongs to the medical service provider. The medical service provider is a medical institution or medical service platform that is responsible for providing remote medical consultation, matching of medical resources, and emergency medical rescue services to users with health needs (such as drivers and passengers whose health risks are detected in the smart cockpit). It can respond quickly and provide professional medical support when drivers and passengers are at high health risk.

[0047] In one possible manner, this disclosure Figure 1 The servers involved (i.e., health risk assessment server 101 and medical system server 103) can be standalone servers or server clusters consisting of multiple server nodes. In some embodiments, the server cluster can adopt a distributed architecture to support cross-regional deployment. This disclosure does not limit the specific implementation of the servers.

[0048] Optionally, the above Figure 1 In the health status monitoring system shown, the health risk assessment server 101 can be connected to at least one vehicle-mounted system terminal 102 and a medical system server 103. This disclosure does not limit the number or type of vehicle-mounted system terminals 102.

[0049] Combination Figure 1 ,like Figure 2 The diagram shown is a structural schematic of an in-vehicle system terminal provided in an embodiment of this application. The in-vehicle system terminal 102 may be configured with an acquisition module 21, a communication module 22, and a display module 23. The acquisition module 21 can connect to sensor devices such as a steering wheel-embedded photoelectric sensor, a seat pressure sensor, a camera, and a microphone to acquire user physiological data, behavioral data, and cabin environmental data. The communication module 22 may be a wireless or wired communication interface for data transmission between the in-vehicle system terminal 102 and other devices (e.g., a health risk assessment server 101, a medical system server 103) or a communication network. The display module 23 may include an in-vehicle display screen or other output devices for displaying information such as health assessment scores and the implementation status of health intervention strategies.

[0050] In one possible implementation, the health status monitoring method provided in this application embodiment is not only applicable to various types of cars with smart cockpits, but also to other vehicles with enclosed cockpits, such as ship cockpits, airplane cockpits and high-speed rail cockpits, and can also be applied to mobile spaces with health monitoring needs, such as smart RVs and mobile medical stations.

[0051] The embodiments in this application illustrate the application of health status monitoring methods to automotive scenarios.

[0052] The following detailed description of a health status monitoring method provided by this application, in conjunction with specific embodiments and accompanying drawings, provides an example of such a method.

[0053] Figure 3 This is a flowchart illustrating a health status monitoring method provided in an embodiment of this application. Specifically, as shown... Figure 3 As shown, it includes the following:

[0054] S301, Acquire multi-source data from the cockpit domain.

[0055] The multi-source data includes user physiological data, user behavioral data, and cabin environment data.

[0056] In one possible approach, combining Figure 1 and Figure 2When the health status monitoring system needs to acquire multi-source data from the cockpit domain, it can acquire corresponding types of data through various acquisition devices connected to the vehicle system terminal 102.

[0057] In one possible implementation, for the user's physiological data, the user's heart rate and blood pressure can be monitored by an embedded photoelectric sensor in the steering wheel, and the user's weight and abnormal body movements (such as limb twitching before an epileptic seizure) can be detected by a seat pressure sensor; for the user's behavioral data, the user's body temperature, respiratory rate and facial expressions can be obtained by a camera installed in the cabin combined with infrared thermometry technology, and the user's fatigue state can be judged by voice analysis through a microphone; for the environmental data in the cabin area, it can be used to help distinguish between physiological signals and motion interference by combining with the user's driving behavior (such as rapid acceleration and steering).

[0058] In another possible implementation, the system can connect to the user's smartwatch, wristband, or other wearable devices via Bluetooth or vehicle networking protocols to obtain physiological and behavioral data such as heart rate, blood oxygen, and exercise status; at the same time, it can supplement environmental data through environmental sensors built into the cabin (such as temperature and humidity sensors and air quality sensors).

[0059] Next, after completing the collection of various data, the vehicle system terminal 102 can use the communication module 22 to summarize and transmit the collected user physiological data, behavioral data and cabin environment data to the health risk assessment server 101 of the health status monitoring system, so as to ensure that the health risk assessment server 101 can completely obtain multi-source data in the cabin domain, thereby laying a data foundation for subsequent operations based on multi-source data to perform health risk scoring.

[0060] S302. Based on multi-source data and a health status assessment model, obtain the user's health risk score.

[0061] Among them, the health status assessment model is used to assess the user's health status and obtain a health risk score.

[0062] In one possible approach, after acquiring multi-source data (user physiological data, behavioral data, and cabin environmental data) from the cabin domain, the health status monitoring system first performs preprocessing operations on the multi-source data to ensure that it meets the input requirements of the health status assessment model. Furthermore, the entire data preprocessing process is completed automatically in the system background, requiring no user intervention and achieving seamless data processing.

[0063] In one possible implementation, after multi-source data preprocessing, the health risk assessment server invokes a pre-defined health status assessment model. This model is trained on a large amount of historical health data (covering physiological and behavioral data of users of different ages and health conditions, as well as corresponding health risk outcomes), and possesses the ability to comprehensively analyze multi-dimensional data. The health risk assessment server inputs the preprocessed multi-source data feature values ​​into the health status assessment model, and the model uses internal algorithms (such as gradient boosting trees, convolutional networks, random forests, etc.) to assign weights and perform correlation calculations on each data feature.

[0064] In one possible approach, after completing data calculations, the health status assessment model outputs a corresponding health risk score. This health risk score is typically presented as a numerical value between 0 and 1, with different score ranges corresponding to different health risk levels. The score results are simultaneously stored in the database of the health status monitoring system for later retrieval when determining health intervention strategies based on the score. Simultaneously, the model generates a brief explanation of the scoring criteria when outputting the score, providing a reference for the subsequent development of intervention strategies.

[0065] In one possible approach, the health status monitoring system verifies the effectiveness of the health status assessment model before invoking it. For example, it obtains the latest user health feedback data (such as subsequent medical diagnosis results and self-reported health status information) and compares it with the health risk score previously output by the model. If the score's match with the actual health status is lower than a preset threshold (such as 85%), the system automatically triggers a model update mechanism to optimize and adjust the model parameters based on the latest health data, ensuring that the health status assessment model always has high assessment accuracy.

[0066] In one possible approach, if the health status monitoring system starts up for the first time or detects that the currently used health status assessment model version is too low, it will automatically download the latest version of the model file from the cloud server. During the model download and update process, the system will maintain the normal operation of its core functions, that is, it can continue to acquire and temporarily store multi-source data, and immediately perform health risk score calculation after the model update is completed, so as to avoid interruption of the health monitoring process due to model update and ensure the continuity of user experience.

[0067] S303. Based on the user's health risk score, determine the corresponding health intervention strategy.

[0068] In one possible approach, after obtaining a user's health risk score, the health status monitoring system will first match the score with a preset risk level classification standard to determine the user's current health risk level, and then formulate differentiated health intervention strategies for different risk levels to ensure that the intervention measures are accurately matched to the user's health status and avoid over-intervention or under-intervention.

[0069] In one possible approach, the health monitoring system dynamically adjusts intervention measures based on user feedback and data changes. For example, if a user receives fatigue alerts multiple times at low-risk levels but their fatigue does not significantly improve, the system will upgrade the alert to "forced slight seat adjustment (such as adjusting the backrest angle)" to enhance the intervention effect. If a user reports that a certain type of intervention (such as specific soothing music) is ineffective in stabilizing their heart rate, the system will record this preference and replace it with other types of relaxation guidance in subsequent interventions. Simultaneously, the system will periodically analyze the effectiveness of different intervention strategies and optimize the priority of intervention strategies at each risk level based on the statistical results, ensuring the practicality and effectiveness of the intervention measures.

[0070] In one possible approach, the system records each determined health intervention strategy, its execution process, and changes in user data to the user's health record (stored in the system database and accessible only with user authorization). This allows users to easily query historical intervention records via the in-vehicle system or a linked mobile app, while also providing actual intervention effect data to support the subsequent optimization of the health status assessment model, forming a closed loop of "scoring-intervention-feedback-optimization".

[0071] In some embodiments, determining a user's health intervention strategy based on the user's health score includes: determining the user's health intervention strategy as a first health intervention strategy when the user's health risk score is greater than or equal to a first threshold and less than a second threshold; determining the user's health intervention strategy as a second health intervention strategy when the user's health risk score is greater than or equal to the second threshold; wherein the second threshold is greater than the first threshold; and the intervention intensity of the second health intervention strategy is greater than the intervention intensity of the first health intervention strategy.

[0072] In one possible approach, the health status monitoring system can pre-configure two risk scoring thresholds, a first threshold and a second threshold (where the second threshold is greater than the first threshold). After obtaining the user's health risk score, the system compares the score with these two thresholds to divide different health risk ranges, and then matches corresponding health intervention strategies to ensure that the intensity of the intervention measures is appropriate to the risk level.

[0073] In one possible approach, the health status monitoring system can combine a feature library of driving scenarios such as high speed and nighttime driving with the user's personalized physiological data baseline to dynamically adjust the warning threshold, thereby reducing misjudgments caused by individual differences and scenario fluctuations.

[0074] In one possible approach, a health status monitoring system can replace the multi-threshold dynamic decision-making mechanism by setting a fuzzy logic mechanism. By defining fuzzy variables such as "fatigue level" and "abnormal blood pressure" and membership functions, the system can dynamically output intervention strategies based on a rule base, without the need to preset fixed thresholds, thereby adapting to individual physiological differences and complex driving scenarios.

[0075] In one possible approach, the first health intervention strategy focuses on "immediate intervention and risk mitigation" and may include at least one of the following: activating seat vibration, playing voice prompts, or adjusting the cabin environment. The second health intervention strategy focuses on "professional medical support and ensuring safety" and may include: establishing a connection with a telemedicine service platform and matching medical resources to provide corresponding medical services. The intervention intensity of the second health intervention strategy is greater than that of the first health intervention strategy.

[0076] In one feasible approach, the first threshold can be further divided into a primary threshold and an intermediate threshold, and the second threshold can be determined as an advanced threshold. Correspondingly, if the user's health risk score is greater than or equal to the primary threshold and less than the intermediate threshold, the health status monitoring system can implement a health intervention strategy of "activating seat vibration and / or playing voice prompts"; if the user's health risk score is greater than or equal to the intermediate threshold and less than the advanced threshold, the health status monitoring system can implement a health intervention strategy of "adjusting the cabin environment," such as releasing fragrance and / or adjusting the seat; if the user's health risk score is greater than or equal to the advanced threshold, the health status monitoring system can implement a health intervention strategy of "establishing a connection with a telemedicine service platform and matching medical resources."

[0077] In one possible approach, when implementing the first or second health intervention strategy, the health status monitoring system can simultaneously record the threshold comparison results, strategy execution time, specific operation content, and user feedback, and update them to the user's health record. This can provide data support for subsequent threshold adjustments (such as fine-tuning the threshold based on the intervention effects of most users) and also allow users to follow up on the medical service process.

[0078] In one possible approach, if the user is in a high-risk zone (score ≥ second threshold), the health status monitoring system, while implementing the second health intervention strategy, can also trigger relevant auxiliary safety measures: automatically turn on hazard lights and / or emergency warning lights; if the user is currently driving and the vehicle is not stopped, a strong voice prompt will be given stating "The current health risk is high, it is recommended to pull over safely immediately," and the option to "navigate to the nearest parking lot" will pop up on the central control display screen; if the user does not experience significant relief after parking, the system can automatically unlock the doors according to the user's preset authorization, facilitating the rapid entry of medical personnel into the cabin and further improving rescue efficiency.

[0079] In some embodiments, Figure 4 This is a flowchart illustrating a method for matching medical resources provided in an embodiment of this application. Specifically, as shown... Figure 4 As shown, when establishing a connection with a telemedicine service platform and matching medical resources to provide corresponding medical services, the following are included:

[0080] S401, Standardized API interface for connecting to remote medical service platforms via vehicle networking platforms.

[0081] S402. Transmit multi-source data to the telemedicine service platform through a standardized API interface, so that the telemedicine service platform can match medical resources to users based on the multi-source data and provide corresponding medical services.

[0082] Medical services include registration services or online doctor consultation services.

[0083] In one possible approach, medical resources include at least one of the following: medical institution resources, medical expert resources, historical case resources, and historical medical treatment pathway resources.

[0084] For example, when implementing the second health intervention strategy, the in-vehicle network platform built into the cockpit can be used to proactively connect to the standardized API interface pre-opened by the telemedicine service platform. After completing interface authentication (such as matching the unique device identifier of the vehicle network platform with the authorization key of the telemedicine platform), the previously collected and pre-processed multi-source data of the cockpit domain (including user physiological data, behavioral data, and cockpit environmental data) can be transmitted to the telemedicine service platform in real time through the standardized API interface. The telemedicine service platform analyzes the multi-source data to determine the type and urgency of the user's health risk, and then matches the user with appropriate medical resources (including medical institution resources, medical expert resources, historical case resources, historical medical path resources, etc.). Finally, it provides the user with corresponding medical services such as registration services or online doctor consultation services, thereby realizing professional medical intervention for health risks.

[0085] For example, the standardized API interface of the telemedicine service platform connected to the vehicle-to-everything (V2X) platform is the same standardized API interface for connecting to the hospital's HIS system (such as the HL7 FHIR protocol interface). A communication channel is established by matching the unique device identifier of the V2X platform with the authorization key of the telemedicine platform. Multi-source data, encapsulated in JSON format, is then transmitted to the hospital's HIS system. After receiving data, the hospital's HIS system analyzes and determines that the user has common chronic symptoms (such as mild dizziness). It then matches the user with a general practitioner online doctor within the platform, generates a link to the doctor's online consultation service, and pushes it to the cockpit's central control screen via the vehicle network platform. The user can then click the link to initiate a real-time video consultation. If the system determines that the user's symptoms require offline treatment (such as suspected acute discomfort), it filters hospitals and corresponding departments (such as cardiology or emergency departments) within a 5-kilometer radius based on the user's current GPS location. After obtaining the current number of available appointments at each hospital, it generates a recommended appointment list (including hospital name, department, doctor, and number of available appointments). After the user selects the target hospital and department, the vehicle network platform automatically completes the appointment registration through a standardized API interface and simultaneously sends the successful registration information (including appointment time and department location navigation link) back to the user.

[0086] In some embodiments, Figure 5 This is a flowchart illustrating another method for matching medical resources provided in an embodiment of this application. Specifically, as shown... Figure 5 As shown, when establishing a connection with a telemedicine service platform and matching medical resources to provide corresponding medical services, the following are included:

[0087] S501, a standardized API interface for connecting to a remote medical service platform via a vehicle networking platform.

[0088] S502. Obtain medical resource data from the remote medical service platform through standardized API interfaces.

[0089] S503. Based on multi-source data and medical resource data from the telemedicine service platform, match medical resources for users to provide corresponding medical services.

[0090] Medical services include registration services or online doctor consultation services.

[0091] For example, when implementing the second health intervention strategy, the vehicle-to-everything (V2X) platform in the cockpit can be used to connect to the pre-opened standardized API interface of the telemedicine service platform based on the MCP protocol (V2X communication protocol). After the communication link between the V2X platform and the telemedicine service platform is encrypted and authenticated through the MCP protocol, real-time updated medical resource data (including online doctor information, hospital department distribution, and appointment availability) can be obtained from the telemedicine service platform through the standardized API interface. Subsequently, the obtained medical resource data, together with the previously collected multi-source data from the cockpit domain, is input into the intermediary medical big data model. The intermediary medical big data model combines the multi-source data to analyze the user's health risk type (such as cardiovascular discomfort, respiratory discomfort) and the urgency of the need, and filters and prioritizes the medical resource data to match the user with suitable medical resources. Finally, the user is provided with corresponding medical services such as appointment services or online doctor consultation services. The entire process relies on the MCP protocol to ensure communication stability and security, and relies on the intermediary medical big data model to improve the accuracy and efficiency of medical resource matching.

[0092] For example, when the vehicle-to-everything (V2X) platform connects to the standardized API interface of a remote medical service platform based on the MCP protocol, it must first submit the vehicle manufacturer's unique identifier, device serial number, and temporary authorization code through the MCP protocol's identity authentication module. After the remote medical service platform verifies the information, a two-way encrypted communication channel is established to ensure that data transmission is not stolen or tampered with during the transmission process. Medical resource data obtained through this API interface must be returned in a preset format. After receiving multi-source data and medical resource data, the intermediary medical big data model first identifies anomalies in the physiological data (such as heart rate and blood oxygen) from the multi-source data to determine potential health problems of the user (such as a sudden increase in heart rate suggesting cardiovascular problems). Then, combined with the user's current location (obtained through GPS data from the V2X platform), it filters out areas within a 5-kilometer radius where corresponding medical services can be provided. For users with urgent symptoms (e.g., heart rate consistently exceeding 120 beats per minute according to multi-source data), the system prioritizes matching them with doctors who support immediate online consultations. A consultation request is generated and pushed to the doctor's terminal. Once the doctor accepts the request, a video consultation link is established between the user and the doctor through the vehicle-to-everything (V2X) platform. If the user's symptoms require in-person treatment, the intermediary medical model recommends three optimal appointment options based on available appointment slots and hospital distance (e.g., "XX Hospital Cardiology Department, 5 available slots, 2.3 km away"). After the user selects an option, the V2X platform automatically submits the appointment information (including basic user information and symptom description) via a standardized API interface. Upon successful appointment registration, a notification (including appointment time and department navigation route) is simultaneously sent to the cockpit central control screen and / or the user's mobile phone.

[0093] In some embodiments, medical resources are matched to users based on multi-source data and medical resource data from a telemedicine service platform to provide corresponding medical services, including: determining the user's vital signs status based on multi-source data; matching medical resources to the user based on the user's vital signs status to provide registration services when the user's vital signs status is not in a critical state; and matching medical resources to the user based on the user's vital signs status to provide online doctor consultation services when the user's vital signs status is in a critical state.

[0094] In one possible approach, medical resources include at least one of the following: medical institution resources, medical expert resources, historical case resources, and historical medical treatment pathway resources.

[0095] For example, when matching medical resources to a user based on multi-source data and medical resource data from a telemedicine service platform, the system first extracts key physiological indicators such as the user's heart rate, blood oxygen saturation, blood pressure, and respiratory rate from the multi-source data. Data analysis is then used to determine the user's current vital signs status (e.g., indicators within the normal range or with only slight fluctuations indicate a non-critical state; indicators exceeding safety thresholds and showing an abnormal trend indicate a critical state). If the user's vital signs status is determined to be non-critical, the system combines the user's vital signs (e.g., slightly elevated blood pressure, occasional chest tightness) with the medical resource data from the telemedicine service platform (including medical institution resources, medical expert resources, historical case resources, and historical...). The system uses various resources, including diagnostic pathways, to select suitable medical resources (such as community hospitals specializing in the initial diagnosis of cardiovascular diseases and historical medical pathways for the corresponding symptoms) and provide registration services for users. If a user's vital signs are determined to be in a critical state, based on the emergency situation of the user's vital signs (such as a sudden increase in heart rate or a sudden drop in blood oxygen), it prioritizes matching medical resources in the telemedicine service platform that support immediate response (such as online emergency doctors, medical experts with experience in handling similar critical cases, and historical case resources of related critical illnesses) to provide users with online doctor consultation services and quickly obtain professional medical guidance. The entire process achieves accurate matching of medical resources and reasonable selection of service types through the classification and judgment of vital signs.

[0096] For example, Figure 6 This is a detailed flowchart illustrating a method for matching medical resources, provided as an embodiment of this application. Figure 6As shown, the cabin health data is first input into the medical semantic conversion unit for clinical semantic parsing of vital signs and conversion into natural language commands. After the medical semantic conversion is completed, the data is transmitted to the treatment request generator, which encapsulates standardized data and marks service priorities so that different treatment requests can be processed according to priorities. Subsequently, it is determined whether the situation is critical. If it is critical, the emergency channel judgment logic analyzes the deterioration of vital signs; then, real-time communication is established with the doctor's interactive terminal through the doctor's direct connection interface, and the interaction protocol is adapted to achieve synchronization of vital sign data. The real-time vital sign stream and dynamic case indicators are transmitted to the doctor's interactive terminal, and the doctor's handover terminal can feed the information back to the cabin through the cabin feedback interface. If it is not critical, a medical institution is matched through the resource scheduling interface and the knowledge base matching engine. Specifically, the resource scheduling interface has the ability to acquire institutional services and detect resource availability. It can acquire institutional resource data and expert capability graphs. At the same time, the knowledge base matching engine can calculate the similarity of pathological features and generate the optimal service path. It can acquire case feature matching and treatment path recommendations. Then, based on institutional resource data, expert capability graphs, case feature matching, and treatment path recommendation information, case feature matching is performed. The data after case feature matching is transmitted to the medical institution system. After processing, the medical institution system feeds back the appropriate medical resource information (such as community hospitals specializing in the initial diagnosis of cardiovascular diseases and the historical treatment paths of the corresponding diseases) to the cockpit through the cockpit feedback interface.

[0097] In some embodiments, combined with Figure 3 , Figure 7 This is a flowchart illustrating another health status monitoring method provided in an embodiment of this application. Specifically, as shown... Figure 7 As shown, step S302, based on multi-source data and a health status assessment model, obtains the user's health risk score, which may include the following steps S701-S702:

[0098] S701. Perform data preprocessing on multi-source data to extract feature information related to the user's health status.

[0099] S702. Input the feature information into the health status assessment model, analyze the feature information through the health status assessment model to assess the user's health status and obtain a health risk score.

[0100] For example, when obtaining a user's health risk score based on multi-source data and a health status assessment model, the first step is to perform data preprocessing on the collected cabin domain multi-source data (user physiological data, behavioral data, and cabin environment data) to remove outliers and missing values ​​and perform standardization transformation. The weights of each modality feature are dynamically adjusted through a cross-modal attention adjustment mechanism to obtain fused multi-source data. Then, feature information directly related to the user's health status is extracted from the preprocessed multi-source data. Subsequently, the extracted feature information is packaged according to the input format requirements of the health status assessment model and input into the pre-trained health status assessment model. The health status assessment model performs multi-dimensional analysis of the feature information through internal algorithms, and calculates a health risk score that reflects the user's current health status by combining the influence weights of each feature on the health status.

[0101] For example, in the data preprocessing stage, a BiLSTM time series model is used to filter motion artifact noise in ECG / PPG signals, a dynamic time warping algorithm is used to achieve spatiotemporal alignment, a weighted fusion strategy is used to integrate the two signals, and the data scale is unified. Then, time-domain and frequency-domain features are extracted from the fused signal, motion-related features are extracted from behavioral data, and features such as temperature and humidity are extracted from environmental data. Subsequently, the extracted feature information is packaged according to the input format requirements of the health status assessment model and input into a pre-trained health status assessment model based on a convolutional network and random forest ensemble. The health status assessment model performs multi-dimensional analysis of the feature information, combines the influence weights of each feature on health status, and calculates a health risk score that reflects the user's current health status.

[0102] In one possible implementation, multi-source data can be preprocessed by using a lightweight timing model to run on a high-performance chip, in order to adapt to scenarios with extremely high real-time requirements.

[0103] In summary, in one possible implementation, Figure 8 This is a detailed flowchart illustrating a health status monitoring method provided in an embodiment of this application. Figure 8As shown, the health status monitoring system first collects heart rate / blood pressure data via an embedded sensor in the steering wheel, weight / body movement data via a seat pressure sensor, body temperature / respiratory rate / facial expression data via a camera, and relevant voice data via a microphone for voice fatigue detection. All this collected data is aggregated into a raw data pool. Next, the data in the raw data pool is input into a time-series data processing model, where it is processed to obtain preprocessed data. This preprocessed data is then input into a health status assessment model, where features are first extracted using a convolutional network to obtain deep features, and then a random forest ensemble learning algorithm is used to generate a health risk score. Afterwards, a threshold correlation algorithm is used to judge the health risk score, performing multi-threshold matching to make a warning level decision, and outputting a primary warning, intermediate warning, or advanced warning based on the decision result.

[0104] The health status monitoring method provided in this application includes: acquiring multi-source data in the cockpit domain; the multi-source data includes the user's physiological data, the user's behavioral data, and the environmental data of the cockpit domain; obtaining the user's health risk score based on the multi-source data and a health status assessment model; the health status assessment model is used to assess the user's health status and obtain the health risk score; and determining corresponding health intervention strategies based on the user's health risk score. This method overcomes the limitations of a single data source by utilizing multi-source data fusion analysis, improving the comprehensiveness and accuracy of user health status assessment; it enhances the objectivity and accuracy of risk identification through intelligent quantitative assessment using the health status assessment model; and it ensures the timeliness and targeting of health intervention strategies through a graded intervention mechanism based on risk scores, thereby achieving full-process automation from risk perception to intelligent intervention, effectively improving the reliability of the cockpit health monitoring system and the user experience.

[0105] In an exemplary embodiment, Figure 9 This is a schematic diagram illustrating the composition of a health status monitoring device provided in an embodiment of this application. Figure 9 As shown, the health status monitoring device includes: an acquisition module 901, a processing module 902, and an output module 903. The acquisition module 901 acquires multi-source data from the cabin domain. This multi-source data includes the user's physiological data, user behavioral data, and environmental data from the cabin domain. The processing module 902 obtains the user's health risk score based on the multi-source data and a health status assessment model. The health status assessment model evaluates the user's health status and yields the health risk score. The output module 903 determines corresponding health intervention strategies based on the user's health risk score.

[0106] In one possible implementation, the acquisition module 901 includes a multimodal data acquisition module, the processing module 902 includes a health status assessment module and a health risk decision-making module, and the output module 903 includes a standard protocol integration module and a medical system interface module. Figure 10 This is a schematic diagram illustrating the composition of another health status monitoring device provided in an embodiment of this application. Figure 10 As shown, the multimodal data acquisition module collects body movement and weight data through seat sensors, body temperature and facial expression data through cameras, heart rate and blood pressure data through steering wheel sensors, and voice fatigue-related data through microphones, thereby obtaining physiological, behavioral, and environmental data. This data is transmitted to the health status assessment module, which outputs a health score / abnormal signal. The health risk decision-making module receives the health score / abnormal signal and makes decisions based on primary, intermediate, and advanced thresholds: when the primary threshold is triggered, the local intervention unit is controlled to vibrate the seat / provide voice prompts; when the intermediate threshold is triggered, the cabin adjustment unit is controlled to release fragrance / adjust the seat; when the advanced threshold is triggered, the standard protocol integration module generates a standardized treatment request and matches medical resources, then transmits it to the medical system interface module, which interacts with the registration system and doctor's terminal.

[0107] In an exemplary embodiment, this application also provides an electronic device, which may be a health status monitoring device as described in the above method embodiments. Figure 11 This is a schematic diagram of a health status monitoring device provided in an embodiment of this application. Figure 11 As shown, the health status monitoring device may include: a processor 1101 and a memory 1102; the memory 1102 stores instructions executable by the processor 1101; when the processor 1101 is configured to execute instructions, it causes the electronic device or network device or manager to perform the system functions described in the foregoing method embodiments.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0109] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0110] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0111] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0112] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0113] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for monitoring health status, characterized in that, The method includes: Acquire multi-source data from the cockpit domain; the multi-source data includes user physiological data, user behavioral data, and cockpit domain environmental data. Based on the multi-source data and the health status assessment model, the user's health risk score is obtained; the health status assessment model is used to assess the user's health status and obtain the health risk score. Based on the user's health risk score, a corresponding health intervention strategy is determined.

2. The method according to claim 1, characterized in that, The process of determining the user's health intervention strategy based on the user's health score includes: If the user's health risk score is greater than or equal to a first threshold and less than a second threshold, the user's health intervention strategy is determined to be the first health intervention strategy. If the user's health risk score is greater than or equal to the second threshold, the user's health intervention strategy is determined to be the second health intervention strategy. Wherein, the second threshold is greater than the first threshold; and the intervention intensity of the second health intervention strategy is greater than the intervention intensity of the first health intervention strategy.

3. The method according to claim 2, characterized in that, The first health intervention strategy includes at least one of the following: activating seat vibration, playing voice prompts, and adjusting the cabin environment; The second health intervention strategy includes: establishing a connection with a telemedicine service platform and matching medical resources to provide corresponding medical services.

4. The method according to claim 3, characterized in that, The process of establishing a connection with the telemedicine service platform and matching medical resources to provide corresponding medical services includes: The standardized API interface of the remote medical service platform is connected through the vehicle network platform; The multi-source data is transmitted to the telemedicine service platform through the standardized API interface, so that the telemedicine service platform can match medical resources for the user based on the multi-source data and provide corresponding medical services; wherein, the medical services include registration services or online doctor consultation services.

5. The method according to claim 3, characterized in that, The process of establishing a connection with the telemedicine service platform and matching medical resources to provide corresponding medical services includes: The standardized API interface of the remote medical service platform is connected through the vehicle network platform; Medical resource data of the remote medical service platform can be obtained through the standardized API interface; Based on the multi-source data and the medical resource data of the telemedicine service platform, medical resources are matched for the user to provide corresponding medical services; wherein, the medical services include registration services or online doctor consultation services.

6. The method according to claim 5, characterized in that, The process of matching medical resources for the user based on the multi-source data and the medical resource data of the telemedicine service platform to provide corresponding medical services includes: The user's vital signs status are determined based on the multi-source data; If the user's vital signs are not in a critical condition, medical resources will be matched to the user based on the user's vital signs to provide registration services; If the user's vital signs are in a critical state, medical resources will be matched to the user based on the user's vital signs to provide online doctor consultation services.

7. The method according to claim 4 or 5, characterized in that, The medical resources include at least one of the following: medical institution resources, medical expert resources, historical case resources, and historical medical treatment pathway resources.

8. The method according to claim 1, characterized in that, The process of obtaining the user's health risk score based on the multi-source data and health status assessment model includes: The multi-source data is preprocessed to extract feature information related to the user's health status; The feature information is input into the health status assessment model, and the feature information is analyzed by the health status assessment model to assess the user's health status and obtain the health risk score.

9. A health status monitoring device, characterized in that, The device includes: an acquisition module, a processing module, and an output module; The acquisition module is used to acquire multi-source data in the cockpit domain; the multi-source data includes user physiological data, user behavioral data, and cockpit domain environmental data. The processing module is used to obtain the user's health risk score based on the multi-source data and the health status assessment model; the health status assessment model is used to assess the user's health status and obtain the health risk score. The output module is used to determine the corresponding health intervention strategy based on the user's health risk score.

10. An electronic device, characterized in that, The controller includes: a processor and a memory; The memory stores instructions that the processor can execute; When the processor is configured to execute the instructions, the controller causes the controller to implement the method as described in any one of claims 1-8.

Images