Health service and code information processing method, device, system and storage medium

Abstract

The embodiments of the present application provide a health service and code information processing method, device, system and storage medium. The embodiments of the present application provide a health service system, in which the multi-level health service required to generate the health code information is dynamically configured based on the health service demand. The server-side device can call the dynamically configured multi-level health service to generate health code information for the user. The user can initiate a service request to obtain the health code information to the server-side device through the terminal device, obtain the health code information from the server-side device, and realize the intelligent management of the user's health status. Among them, the multi-level health service required to dynamically configure the health code information based on the health service demand can meet the differentiated needs of the user's health status in different application scenarios, different regions and / or different time periods, solve the problem of intelligent management of health status under multiple service needs, and greatly reduce the development cost of health services.

Description

Technical Field

[0001] The present application relates to the field of software technology, and in particular to a health service and code information processing method, device, system and storage medium. Background Art

[0002] Intelligent management of user health status will become a new trend in intelligent and digital urban management. This intelligent management of user health status not only provides users with a variety of health services and allows them to keep abreast of their health status, but also assists in disease prevention and control during special periods, thereby improving the health of the entire population.

[0003] In different application scenarios or different cities, the service demands for user health status may be different, that is, the intelligent management of user health status faces multiple service demands. How to solve the problem of intelligent management of user health status with multiple service demands is an issue to be solved. Summary of the Invention

[0004] Multiple aspects of this application provide a health service and code information processing method, device, system and storage medium to solve the problem of intelligent management of health status under various service requirements.

[0005] An embodiment of the present application provides a health service system, including: a server device and a terminal device; the server device is used to obtain multi-level health services dynamically configured based on health service needs, call the multi-level health services to generate health code information for at least one user; and receive a first service request from a first user, and return the health code information of the first user to the first user based on the first service request, the at least one user including the first user; the terminal device of the first user is used to send the first service request to the server device, and receive and display the health code information of the first user returned by the server device.

[0006] An embodiment of the present application also provides a health service method, which includes: dynamically configuring multi-level health services required to generate health code information based on health service needs; calling the multi-level health services to generate health code information for at least one user; receiving a first service request from a first user, and the at least one user includes the first user; and returning the health code information of the first user to the first user according to the first service request.

[0007] An embodiment of the present application also provides a server-side device, including: a memory, a processor, and a communication component; the memory is used to store a computer program; the processor is coupled to the memory and is used to execute the computer program, so as to: obtain a multi-level health service dynamically configured based on health service needs, and call the multi-level health service to generate health code information for at least one user; and receive a first service request from a first user through the communication component, and return the health code information of the first user to the first user according to the first service request, the at least one user includes the first user, and the multi-level health service is dynamically configured based on health service needs.

[0008] An embodiment of the present application also provides a configuration device, including: a memory and a processor; the memory is used to store a computer program; the processor is coupled to the memory and is used to execute the computer program, so as to: obtain health service needs; according to the health service needs, dynamically configure the multi-level health services required to generate health code information on the server device, so that the server device can generate health code information for at least one user based on the multi-level health service.

[0009] An embodiment of the present application also provides a method for displaying health code information, including: sending a service request to a server device to request the user's health code information, the health code information including the health code color and the user's identification information; receiving the health code information and reason information corresponding to the health code color returned by the server device; and displaying the health code information and reason information corresponding to the health code color on the health code interface.

[0010] An embodiment of the present application also provides a service configuration method, including: responding to a service configuration operation, displaying a service configuration interface, the service configuration interface including a first configuration item indicating whether the custom service depends on a third-party service; responding to a configuration operation on the first configuration item, obtaining configuration information indicating whether the custom service depends on a third-party service; if the third-party service depends on a third-party service, displaying a second configuration item for configuring a service domain name of the third-party service; and responding to the configuration operation on the second configuration item, obtaining a server domain name of the third-party service for accessing the third-party service.

[0011] An embodiment of the present application also provides a terminal device, including: a memory, a processor and a communication component; the memory is used to store a computer program; the processor is coupled to the memory, and is used to execute the computer program, so as to: send a service request to the server device through the communication component to request the user's health code information, the health code information including the health code color and the user's identification information; receive the health code information returned by the server device and the reason information corresponding to the health code color; and display the health code information and the reason information corresponding to the health code color on the health code interface.

[0012] An embodiment of the present application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor implements the steps in the health service method provided in the embodiment of the present application.

[0013] An embodiment of the present application also provides a code information processing system, including: a server device and at least one terminal device; the server device is used to obtain a multi-level status code service dynamically configured based on status code service requirements, and call the multi-level status code service to generate status code information for at least one data object; and receive a first service request from a first terminal device, and return status code information of a first data object to the first terminal device based on the first service request, wherein the first data object belongs to the at least one data object; the first terminal device is used to send a first service request to the server device, and receive and display the status code information of the first data object returned by the server device; the at least one terminal device belongs to the at least one terminal device.

[0014] An embodiment of the present application also provides a code information processing method, including: dynamically configuring a multi-level status code service required to generate status code information based on status code service requirements; calling the multi-level status code service to generate status code information for at least one data object; receiving a first service request from a first terminal device, the first service request being used to request status code information of the first data object; and returning the status code information of the first data object to the first terminal device according to the first service request, the first data object belonging to the at least one data object.

[0015] An embodiment of the present application also provides a server-side device, comprising: a memory, a processor, and a communication component; the memory is used to store a computer program; the processor is coupled to the memory, and is used to execute the computer program, so as to: obtain a multi-level status code service dynamically configured based on status code service requirements; call the multi-level status code service to generate status code information for at least one data object; receive a first service request from a first terminal device, the first service request being used to request status code information of the first data object; and return the status code information of the first data object to the first terminal device according to the first service request, the first data object belonging to the at least one data object.

[0016] The embodiment of the present application provides a health service system, in which the multi-level health services required to generate health code information can be dynamically configured based on health service needs. The server-side device can call the dynamically configured multi-level health services to generate health code information for the user. The user can initiate a service request to obtain health code information to the server-side device through the terminal device, obtain the health code information from the server-side device, and realize intelligent management of the user's health status. Among them, the multi-level health services required to dynamically configure and generate health code information based on health service needs can meet the differentiated needs of the user's health status in different application scenarios, different regions and / or different time periods, solve the problem of intelligent management of health status under multiple service needs, and greatly reduce the development cost of health services.

[0017] Similarly, the embodiment of the present application also provides a code information processing system, in which a multi-level status code service required for generating status code information can be dynamically configured based on status code service requirements. The server device can call the dynamically configured multi-level status code service to generate status code information for related data objects. The party that needs the status code information of the data object can initiate a service request for obtaining status code information to the server device through the terminal device, obtain the status code information of the related data object from the server device, and realize intelligent management of the related status of the data object. Among them, the multi-level status code service required for generating status code information dynamically configured based on status code service requirements can meet the differentiated requirements for object status in different application scenarios, different regions and / or different time periods, solve the problem of intelligent management of object status under multiple service requirements, and greatly reduce the development cost of status management services. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 A schematic diagram of the structure of a health service system provided by an exemplary embodiment of the present application;

[0020] Figure 2 A schematic diagram of the internal service framework and working principle of a server device 101 provided in an exemplary embodiment of the present application;

[0021] Figure 3a A schematic diagram of another internal service framework of the server device 101 and its working principle provided in an exemplary embodiment of the present application;

[0022] Figure 3b A schematic diagram of the internal service framework and working principle of another server device 101 provided in an embodiment of the present application;

[0023] Figure 4a A flowchart of a health service method provided by an exemplary embodiment of the present application;

[0024] Figure 4b A flowchart of a health code information display method provided for an exemplary embodiment of this application;

[0025] Figure 4c A flowchart of a service configuration method provided by an exemplary embodiment of the present application;

[0026] Figure 5 A schematic diagram of the structure of a server device provided by an exemplary embodiment of the present application;

[0027] Figure 6 A schematic structural diagram of a configuration device provided for an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0028] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0029] With the emergence of the demand for intelligent management of user health status, we are faced with the problem of how to solve the problem of intelligent management of user health status with multiple service requirements. In response to this technical problem, the embodiment of this application provides a health service system, such as Figure 1 As shown, the health service system 100 includes: a server device 101 and a terminal device 103.

[0030] In the health service system 100 of this embodiment, health code information is used to indicate the user's health status. The health code information can be in any form that can indicate the user's health status, without limitation. For example, the health code information can include text information such as "healthy" or "unhealthy." Another example is that the health code information can include color information indicating health status, such as "green" indicating health and "red" indicating unhealthy.

[0031] Among them, the intelligent management of the user's health status includes the process of generating and providing health code information for the user, but is not limited to this. In this embodiment, the process of generating health code information for the user is divided into multiple stages, each stage is completed by an independent health service, and the health services in adjacent stages are cascaded, that is, the results of the health services in the previous stage are aggregated and used as the input of the health services in the next stage, and are executed in sequence until the health service in the last stage generates the health code information. In this embodiment, according to the relationship between the multiple stages of generating health code information, the health services required to generate the health code are divided into multiple levels, which are called multi-level health services required to generate health code information.

[0032] Specifically, the server device 101 generates health code information representing the user's health status for the user based on the multi-level health services required to generate the health code information; when the user needs the health code information, he can initiate a service request to obtain the health code information to the server device 101 through the terminal device 103, obtain the health code information from the server device 101, and then carry out subsequent operations related to the health status based on the obtained health code information, such as showing his own health code information to the health checker to cooperate with the health checker's inspection work, thereby realizing intelligent management of the user's health status. It should be noted that this embodiment does not limit the device form of the server device 101 and the terminal device 103. For example, the server device 101 can be but is not limited to: a conventional server, a cloud server or a server array, etc.; the terminal device 103 can be but is not limited to: a smart phone, a tablet computer, a desktop computer or a smart TV, etc.

[0033] Furthermore, in this embodiment, the service requirements for the user's health status may vary in different application scenarios, in different regions, and / or at different times. For example, in a medical application scenario, during special periods (such as an epidemic), more attention may be paid to whether the user has visited an outpatient clinic related to the epidemic (such as a fever clinic). If the user has visited an outpatient clinic related to the epidemic (such as a fever clinic), the user is considered to be in an unhealthy state; otherwise, the user is considered to be in a healthy state. In addition, in a medical application scenario, during non-special periods, more attention may be paid to whether the user has been hospitalized. If the user has been hospitalized, the user is considered to be in an unhealthy state; otherwise, the user is considered to be in a healthy state. In city A, during special periods (such as an epidemic), more attention may be paid to whether the user has had close contact with the source of the epidemic and / or whether the user has visited an outpatient clinic related to the epidemic (such as a fever clinic). If the user has had close contact with the source of the epidemic or has visited an outpatient clinic related to the epidemic, the user is considered to be in an unhealthy state; otherwise, the user is considered to be in a healthy state. In city B, we may only need to consider whether the user has visited city A during the epidemic. If the user has visited city A during the epidemic, the user is considered unhealthy; otherwise, the user is considered healthy. In these examples, the user's health status is described using healthy and unhealthy states as examples, but the description is not limited to this. For example, the user's health status can also be divided into several levels, such as high health risk, medium health risk, low health risk, and no health risk, depending on the application needs.

[0034] In view of the above considerations, in an embodiment of the present application, the server-side device 101 adopts a configurable health code engine framework, and the multi-level health service for generating health code information runs in the health code engine framework and allows dynamic configuration of the multi-level health service. Specifically, in an embodiment of the present application, dynamic configuration of the multi-level health service required to generate health code information is allowed based on health service needs. Specifically, before calling the multi-level health service, the server-side device 101 can obtain the multi-level health service that is dynamically configured based on the health service needs; thereafter, the multi-level health service is called to generate health code information for at least one user.

[0035] In the embodiment of the present application, the implementation method of the server device 101 obtaining the multi-level health service that is dynamically configured based on the health service demand is not limited. For example, the server device 101 can provide a configuration interface for the health service demander, and the health service demander can dynamically configure the multi-level health service that is adapted to the current health service demand through the configuration interface according to the changes in the health service demand; the server device 101 can directly obtain the multi-level health service configured by the health service demander on the configuration interface. Optionally, the configuration interface can be a web page, and the health service demander can open the web page through the terminal device used by the health service demander, and dynamically configure the multi-level health service that is adapted to the current health service demand on the web page according to the changes in the health service demand; after the health service demander completes the configuration, he can click the submit button on the web page, and the web page can return the dynamically configured multi-level health service to the server device 101.

[0036] In addition to the above embodiments, Figure 1 As shown, the health service system 100 of this embodiment may also include: a configuration device 102, which is used to dynamically configure the multi-level health services required to generate health code information on the server device 101 based on health service needs. In this case, the server device 101 can directly obtain the multi-level health services dynamically configured by the configuration device 102. In the embodiment of the present application, the implementation form of the configuration device 102 is not limited. For example, the configuration device 102 can be but not limited to: a conventional server, a cloud server, a server array, a virtual machine (VM) or a container, etc. For the server device 101, the multi-level health service dynamically configured by the configuration device 102 can be called to generate health code information for the user. In other words, when the multi-level health service used to generate health code information changes, the logic of the server device 101 to generate health code information for the user will also change. In the following embodiment, taking the dynamic configuration of multi-level health services by the configuration device 102 based on health service needs as an example, the process of the configuration device 102 and the server device 101 cooperating to provide health services is described in detail.

[0037] Among them, health service demand refers to the service demand of the health service demander for the user's health status, which at least includes the service logic required by the health service demander for generating health code information and the data dimensions on which the health code information is generated. In the case where the process of generating health code information includes multiple stages, the service logic required by the health service demander for generating health code information includes service logic corresponding to multiple stages. Among them, the health service demander refers to the party that needs to know the user's health status, for example, it can be the security management department of various places such as communities, schools, office buildings, parks, shopping malls, supermarkets, vegetable markets or the entire city. In order to ensure the safety of people entering and leaving the corresponding places, the security management personnel of these places need to know the health status of people entering and leaving, and the health service system 100 provided in this embodiment, the server device 101 can provide the health code information of each user according to the multi-level health service dynamically configured by the configuration device 102, which can meet the service needs of the security management part of each place for the user's health status.

[0038] Among them, the health service requirements will vary depending on the application scenario, regional attributes, and / or time attributes of the health service required, and accordingly, the service logic of the configured multi-level health service will also vary. Optionally, the configuration device 102 can determine the current health service requirements based on the regional attributes, time attributes, and / or application scenarios corresponding to the health service; obtain the multi-level health service adapted to the current health service requirements, and configure the multi-level health service adapted to the current health service requirements on the server device 101.

[0039] In an optional embodiment, the current health service demand can be determined based on the regional attributes corresponding to the health service. The regional attributes corresponding to the health service refer to the region specified in the health service demand, that is, the region where the health service is needed. This region can be one or more cities, one or more provinces, or a specific area flexibly defined as needed. The specific area can be a district in a city, a part of a residential complex, a building, a park, or a market, without limitation. If the regional attribute specifies city E, the current health service demand can be determined to be the demand for services related to the user's health status in city E. Assume that the service demand for the user's health status in city E is as follows: if the user has visited a specific area in city E, the user is determined to be at a high health risk level; if the user has not visited the specific area in city E but has had close contact with other users who have visited the specific area, the user is determined to be at a medium health risk level; if the user has not visited the specific area in city E and has not had close contact with other users who have visited the specific area, the user is determined to be at a low health risk level. The service logic of the multi-level health service adapted to the current health service needs is as follows: obtain the user's movement trajectory, and obtain the information of other users with whom the user has close contact and the movement trajectories of other users; determine whether the user has been to a specific area in city E based on the user's movement trajectory; and determine whether other users with whom the user has close contact have been to a specific area in city E based on the movement trajectories of other users with whom the user has close contact; if it is determined that the user has been to a specific area in city E, the user is determined to be at a high health risk level; if it is determined that the user has not been to a specific area in city E, but some of the other users with whom the user has close contact have been to the specific area, the user is determined to be at a medium health risk level; if it is determined that the user has not been to a specific area in city E, and other users with whom the user has close contact have not been to the specific area, the user is determined to be at a low health risk level.

[0040] In another alternative embodiment, the current health service demand can be determined based on the time attribute corresponding to the health service. The time attribute refers to the time information specified in the health service demand, which indicates the period during which the health service is required. The time attribute can be represented by a date, for example, between January 21st and February 21st, or from March 1st to the present, without limitation. If the time attribute specifies from March 1st to the present, the current health service demand can be determined to be the service demand for the user's health status on a global scale since March 1st. Assume that the global health status of the user since March 1st is as follows: if the user has visited city F since March 1st, the user is determined to be at a high health risk level; if the user has not visited city F since March 1st, but has had close contact with other users who have visited city F since March 1st, the user is determined to be at a medium health risk level; if the user has not visited city F since March 1st, and has not had close contact with other users who have visited city F since March 1st, the user is determined to be at a low health risk level. The service logic of the multi-level health service adapted to the current health service needs is as follows: obtain the user's movement trajectory after March 1, and obtain the information of other users with whom the user has close contact and the movement trajectories of other users after March 1; determine whether the user has been to city F after March 1 based on the user's movement trajectory after March 1; and determine whether other users with whom the user has close contact have been to city F after March 1 based on the movement trajectories of other users with whom the user has close contact; if it is determined that the user has been to city F after March 1, the user is determined to be at a high health risk level; if it is determined that the user has not been to city F after March 1, but some of the other users with whom the user has close contact have been to city F after March 1, the user is determined to be at a medium health risk level; if it is determined that the user has not been to city F after March 1, and other users with whom the user has close contact have not been to city F after March 1, the user is determined to be at a low health risk level.

[0041] In another optional embodiment, the current health service demand can be determined based on the application scenario corresponding to the health service. The application scenario refers to the application scenario pointed to in the health service demand, that is, the application scenario that requires the use of health services. For example, the application scenario pointed to in the health service demand may be a professional scenario, which may include but is not limited to: chefs, makeup artists, housekeeping, and aviation services. For another example, the application scenario pointed to in the health service demand may be a medical treatment scenario. Assume that the service demand for the user's health status in the medical treatment scenario is: if the user has seen a fever clinic, the user is determined to be at a high health risk level; if the user has not seen a fever clinic, but has had close contact with other users who have seen a fever clinic, the user is determined to be at a medium health risk level; if the user has not seen a fever clinic, and has not had close contact with other users who have seen a fever clinic, the user is determined to be at a low health risk level. The multi-level health service adapted to the current health service needs has the following service logic: obtain the user's medical records, and obtain the information of other users with whom the user has had close contact and the medical records of other users; determine whether the user has been to a fever clinic based on the user's medical records; and determine whether other users with whom the user has had close contact have been to a fever clinic based on the medical records of other users with whom the user has had close contact; if it is determined that the user has been to a fever clinic, the user is determined to be at a high health risk level; if it is determined that the user has not been to a fever clinic, but other users with whom the user has had close contact have been to a fever clinic, the user is determined to be at a medium health risk level; if it is determined that the user has not been to a fever clinic, and other users with whom the user has had close contact have not been to a fever clinic, the user is determined to be at a low health risk level.

[0042] In another alternative embodiment, the current health service demand can be determined based on the geographical attributes, time attributes, and application scenarios corresponding to the health service. For example, if the current geographical attribute is seafood market J in city H, the time attribute is the period after June 1st, and the application scenarios are the two occupational scenarios of chefs and couriers, then the current health service demand can be determined as the service demand for the health status of chefs and couriers who have had contact with seafood market J after June 1st in city H. Assume that the service demand for user health status in city H is: if the user's occupation is a chef or a courier, and he has been to Seafood Market J in city H after June 1, the user is determined to be at a high health risk level; if the user's occupation is a chef or a courier, and he has not been to Seafood Market J in city H after June 1, but has had close contact with other users who have been to Seafood Market J in city H after June 1, the user is determined to be at a medium health risk level; if the user's occupation is a chef or a courier, and he has not been to Seafood Market J in city H after June 1, and has not had close contact with other users who have been to Seafood Market J in city H after June 1, the user is determined to be at a low health risk level. The multi-level health service adapted to the current health service needs has the following service logic: obtain the movement trajectory of users whose occupations are chefs or couriers after June 1, and obtain the information of other users with whom the users whose occupations are chefs or couriers have had close contact, as well as the movement trajectory of other users after June 1; based on the movement trajectory of users whose occupations are chefs or couriers after June 1, determine whether users whose occupations are chefs or couriers have been to seafood market J in city H after June 1; and based on the movement trajectory of other users with whom the users whose occupations are chefs or couriers have had close contact after June 1, determine whether other users with whom the users whose occupations are chefs or couriers have had close contact have been to city J after June 1. Seafood Market J in City H; if it is determined that the user whose occupation is a chef or courier has been to Seafood Market J in City H after June 1, the user is determined to be at a high health risk level; if it is determined that the user whose occupation is a chef or courier has not been to Seafood Market J in City H after June 1, but other users with whom he has had close contact have been to Seafood Market J in City H after June 1, the user is determined to be at a medium health risk level; if it is determined that the user whose occupation is a chef or courier has not been to Seafood Market J in City H after June 1, and other users with whom he has had close contact have not been to Seafood Market J in City H after June 1, the user is determined to be at a low health risk level.

[0043] Whether the region where attention needs to be paid to the health status of the user changes (for example, there is a new city that needs to pay attention to the health status of the user), or the application scenario where attention needs to be paid to the health status of the user changes (for example, a new application scenario needs to be added), or the period where attention needs to be paid to the health status of the user changes (for example, from January to June), the configuration device 102 can determine the current health service needs; obtain multi-level health services that are adapted to the current health service needs, and configure multi-level health services that are adapted to the current health service needs on the server device 101. Accordingly, the server device 101 can call the multi-level health service dynamically configured by the configuration device 102 to generate health code information for at least one user. Among them, at least one user can be a user group corresponding to the current health service needs, for example, it can be a user who is in or enters the geographical range pointed to in the current health service needs (such as city E or F), or a user in the application scenario pointed to in the current health service needs (such as a chef, courier, etc.).

[0044] No matter how the multi-level health services required to generate the health code information change, the process of applying for the health code information is the same for the user, and the process of applying for the health code information is also the same for different users. Based on this, the process of applying for the health code information is explained by taking the first user as an example. The first user belongs to at least one of the above-mentioned users, or in other words, the above-mentioned at least one user includes the first user. The first user can send a first service request to the server device 101 through its terminal device 103, and the server device 101 can receive the first service request from the first user and return its health code information to the first user according to the first service request. The terminal device 103 of the first user can receive the health code information of the first user returned by the server device 101 and display the health code information. Among them, the first service request is a service request for requesting health code information from the server device 101.

[0045] It is noted that in an embodiment of the present application, the server device 101 may pre-call a multi-level health service to generate health code information for the first user, and then upon receiving a first service request from the first user, the server device 101 may directly obtain the pre-generated health code information according to the first service request and return it to the first user. Alternatively, upon receiving a first service request from the first user, the server device 101 may call a multi-level health service in real time to generate health code information for the first user, and return the real-time generated health code information to the first user.

[0046] Regardless of the above implementation methods, the first service request includes the identification information of the first user. The server device 101 parses the identification information of the first user from the first service request, determines based on the identification information of the first user that it is necessary to obtain the health code information of the first user, rather than the health code information of other users, and then returns the health code information of the first user to the first user. The identification information of the first user can be any information that can uniquely identify the user, such as the first user's registered account, mobile phone number, or email address.

[0047] In each embodiment of the present application, the number of levels of multi-level health services is not limited, for example, it can be level 2, level 3, level 5, etc., which can be determined according to the stage division of the process of generating health code information. In an optional embodiment, the process of generating health code information is divided into two stages, one stage is the data acquisition stage, and the other is the data aggregation stage; wherein, the data acquisition stage is responsible for obtaining the data required to generate health code information that depends on the user's data on at least one health-related dimension. The data aggregation stage is mainly responsible for judging the user's health status based on the data records of the user on at least one health-related dimension obtained in the data acquisition stage, and generating health code information based on the judgment result. Among them, the health-related dimension refers to the data dimension that has an impact on the user's health status, such as the movement trajectory dimension, medical treatment dimension, occupation dimension or residence dimension, etc. Based on this, if Figure 2 As shown, the multi-level health service includes two levels of health services, the first level of health services includes at least one data providing service, and the second level of health services is a data aggregation service cascaded after the at least one data providing service. Figure 2 In the figure, five data providing services a1-a5 and one data aggregation service b1 are used as examples for illustration, but the present invention is not limited thereto. Each data providing service is responsible for obtaining the user's data records on a health-related dimension, and the number of data providing services is determined by the number of health-related dimensions required in the health service demand; the data providing services corresponding to different health-related dimensions have different service logics for obtaining data records. In the case where the multi-level health service includes at least one data providing service and a data aggregation service cascaded after at least one data providing service, the process of the server-side device 101 generating health code information for the user includes: for any one of the at least one users, the server-side device 101 can obtain the user's data records on at least one health-related dimension through at least one data providing service; the data aggregation service generates the user's health code information based on the user's data records on at least one health-related dimension.

[0048] In this embodiment, the implementation form of the data provision service can be an atomic service (atomic service) or a composite service (composite service), and there is no limitation on this. Among them, atomic service refers to a service that cannot be decomposed into a finer-grained service, and refers to a service on a health-related dimension, such as a single service that provides medical records or a single service that provides motion trajectories. Composite service refers to a service composed of other services, and refers to a service on at least two health-related dimensions, such as a service that can provide both medical records and motion trajectories. Data aggregation service refers to a service that gathers and integrates data records on at least one health-related dimension, organically combines data records on at least one health-related dimension, and is used to generate a health code. Its implementation form can be an aggregation service.

[0049] In an optional embodiment, when there are multiple data providing services, once one or several data providing services fail, it may cause the user's service requests for health code information to pile up, exhaust the resources of the server device 101, and thus make the entire health status service unavailable. In order to avoid the aforementioned problems, resources can be isolated for multiple data providing services, and the data providing services are isolated from each other and are not affected by each other. The failure of one data providing service will not affect the services provided by other data, and the entire health status service can operate normally. Based on this, the configuration device 102 can also configure resource isolation parameters for multiple data providing services. Accordingly, the server device 101 can implement resource isolation between multiple data providing services according to the resource isolation parameters. Among them, the resource isolation parameters are parameters related to the implementation of resource isolation.

[0050] In the embodiments of the present application, the resource isolation method adopted is not limited. For example, a thread pool-based isolation method can be adopted, a semaphore-based isolation method can be adopted, or both resource isolation methods can be adopted at the same time. Among them, the thread pool-based isolation method will allocate a thread pool for each data service provider, and all access requests that rely on the same data service provider will be allocated to the thread pool corresponding to the data service provider, without using thread resources in other thread pools to achieve resource isolation. The thread pool-based isolation method is suitable for most scenarios, for example, it can be applied to provide services for data that need to initiate API call requests. The semaphore-based isolation method will allocate the maximum number of accesses that can be processed simultaneously for each data service provider. When the access to a certain data service reaches the maximum number of accesses that can be processed simultaneously, other access requests will be rejected, thereby achieving the purpose of resource isolation and current limiting protection. The semaphore-based isolation method has a small memory overhead and is more suitable for providing services for data that do not require API call requests.

[0051] Further, in this embodiment, the data provision service in this embodiment can be divided into data provision service that depends on third-party services and data provision service that does not depend on third-party services. Among them, data provision service that depends on third-party services refers to a service form in which the user's data records on one or some health-related dimensions can be obtained by calling a third-party service through an API. Data provision service that does not depend on third-party services refers to a service form in which the user's data records on one or some health-related dimensions can be obtained without calling a third-party service through an API. For example, the user's data records on one or some health-related dimensions can be obtained directly from the local memory or hard disk of the server device 101. Optionally, the configuration device 102 can configure a semaphore-based isolation method and its parameters for data provision services that do not depend on third-party services, and configure a thread pool-based isolation method and its parameters for data provision services that depend on third-party services. It should be noted that if the performance of the data provision service that depends on third-party services is relatively stable, the data provision service can also adopt a semaphore-based isolation method, which is not limited to this.

[0052] In this embodiment, parameters required for the semaphore-based isolation method may include, but are not limited to, the number of semaphores n1, average response time, or timeout ratio. The number of semaphores refers to the number of access requests that can be processed concurrently by the data service provider, and can be, for example, 5, 10, or 20, with no specific limitations. The average response time refers to the average response time required for the data service provider to process n1 access requests, and can be, for example, 100ms, 200ms, or 300ms, with no specific limitations. The timeout ratio refers to the percentage of the time required for the data service provider to process each user's access request that exceeds the average response time, and can be, for example, 30%, 40%, or 50%. Parameters required for the thread pool-based isolation method include, but are not limited to, the number of threads in the thread pool, n2, average response time, or timeout ratio. The number of threads refers to the maximum number of threads that can be supported by the thread pool, and can be, for example, 5, 10, or 20, with no specific limitations. Based on this, the maximum number of access requests that can be supported concurrently by the data service provider is the number of threads in the data service provider thread pool. The average response time refers to the average response time that the data provision service needs to meet to process n2 access requests, for example, it can be 100ms, 200ms or 300ms, etc., and there is no limit on this. The timeout ratio refers to the ratio of the time required for the data service to process each user's access request to exceed the average response time to the average response time. For example, the timeout ratio can be but not limited to 30%, 40% or 50%, etc. It is explained here that an access request refers to an access request initiated to the data provision service when the server-side device 101 needs to call the data provision service to generate health code information for the user. It can also be called a scheduling request for the data service. Optionally, if the server-side device 101 generates health code information for the user in real time based on the service request initiated by the user, the access request can also be a service request initiated by the user.

[0053] Furthermore, when configuring semaphore-based or thread pool-based isolation, you can also configure circuit breaker and degradation parameters for each data service. This allows you to alleviate pressure on the data service by circuit breaker or degradation of the data service when the number of service requests scheduled for the data service reaches the configured maximum number of access requests. Circuit breaker refers to a failure or anomaly in a data service. If specific conditions are triggered, the data service is directly disconnected. For example, if the actual average duration of processing access requests for a data service exceeds the configured average response time, the circuit breaker mechanism is triggered for that data service. Or, if the timeout ratio of processing access requests for a data service exceeds the configured timeout ratio, the circuit breaker mechanism is triggered for that data service. The circuit breaker time refers to the time it takes for a data service to return to normal after an anomaly or failure occurs in a data service. The circuit breaker time can be, but is not limited to, 2s, 3s, or 5s. Demotion refers to the time it takes for a data service to downgrade to a lower level when the number of access requests it needs to process exceeds the maximum number of access requests it supports, thereby rejecting access requests that exceed the maximum number of access requests, thereby achieving the purpose of limiting traffic.

[0054] For example, in Figure 2 In the example, there are 5 data service providers. Among them, data service a1 adopts a thread pool-based isolation method. The isolation parameters are that the maximum number of threads supported by the thread pool is 10, the average response time is 200ms, and the fuse time is 5s; data service a2 adopts a thread pool-based isolation method. The isolation parameters are that the number of threads is 20, the timeout ratio is 40%, and the fuse time is 3s; data service a3 adopts a thread pool-based isolation method. The isolation parameters are that the maximum number of threads supported by the thread pool is 20, the average response time is 300ms, and the fuse time is 5s; data service a4 adopts a semaphore-based isolation method. The isolation parameters are that the maximum number of semaphores supported by data service a4 is 20, the timeout ratio is 50%, and the fuse time is 5s; data service a5 adopts a semaphore-based isolation method. The isolation parameters are that the maximum number of semaphores supported by data service a5 is 10, the average response time is 200ms, and the fuse time is 5s. Specifically, the server device 101 calls data providing services a1 - a5 to provide data acquisition services to multiple users.

[0055] Taking data providing services a1 and a5 as an example, the following is an illustrative description of the process in which the server device 101 uses data providing services a1 and a5 based on a thread pool or semaphore-based isolation method to obtain the user's data records on two health-related dimensions. For data providing service a1, at the same time, data providing service a1 can provide up to 10 users and obtain data records on the health-related dimensions corresponding to data providing service a1. Assuming that the server device 101 generates health code information for the user when receiving the user's service request, when a user's service request is scheduled to the thread pool K1, if the number of threads has not reached the upper limit, a thread is started for the user; if the number of threads reaches the upper limit, the thread pool K1 is downgraded, that is, subsequent service requests are rejected. It should be noted that downgrading the thread pool K1 will not affect the thread pools in other data providing services.

[0056] It should be noted that the thread pool-based isolation method also supports circuit breaking processing, that is, when an exception or failure occurs in a thread pool that provides services for a certain data, for example, when the average time for all threads in the thread pool to process service requests exceeds the average response time, or the actual timeout ratio exceeds the set timeout ratio, the server device 101 will perform circuit breaking processing on the thread pool with the exception.

[0057] For data provision service a5, at the same time, data provision service a5 can obtain data records on the health-related dimension corresponding to data provision service a5 for up to 10 users, that is, the number of user service requests that data provision service a5 is allowed to process simultaneously is 10. The server-side device 101 monitors the number of service requests (i.e., the number of semaphores) that data provision service a5 processes simultaneously. When the number of monitored semaphores reaches the set semaphore threshold (e.g., 10), the server-side device 101 will downgrade the data provision service a5, and the data provision service a5 will reject subsequent service requests to achieve the effect of current limiting protection. If the data provision service a5 maintained by the server-side device 101 has an abnormality or failure at this time, the server-side device 101 will perform a fuse processing on the data provision service a5 5s after the abnormality or failure occurs.

[0058] In some embodiments of the present application, at least one data service provider includes a local built-in service and / or a custom service. The at least one data service provider may include only a local built-in service, only a custom service, or both a local built-in service and a custom service. Figure 2 As shown, at least one data service provider includes both local built-in services and customized services, wherein data service provider a1 and data service provider a2 are local built-in services, and data service providers a3 - a5 are customized services.

[0059] Among them, local built-in services refer to services provided by data that exists by default in the server device 101, that is, services provided by data that can be used directly. Local built-in services can be services corresponding to any health-related dimension, such as services that provide medical treatment records (referred to as medical services), services that provide movement trajectory records, or services that provide entry and exit records, etc., without limitation. Customized services refer to services that can be provided by health service demanders based on customized data according to the health service needs of the local end. Customized services can also be services corresponding to any health-related dimension, such as services that provide medical treatment records, services that provide movement trajectory records, services that provide entry and exit records, etc., or services that provide residence information, services that provide whether or not a specific group of people has been contacted, or services that provide whether or not a specific place has been visited, etc., without limitation. Optionally, some target health-related dimensions that are common to different health service demanders can be selected from the health-related dimensions, and the services corresponding to the selected target health-related dimensions can be implemented as local built-in services, and the services corresponding to other health-related dimensions that have not been selected can be implemented as customized services. The specific service logic can be defined by each health service demander based on their own or local health service needs. It should be noted that when both local built-in services and customized services are included, the health-related dimensions corresponding to the local built-in services and customized services do not overlap.

[0060] Whether built-in or custom, data acquisition services can rely on or not rely on third-party services. Third-party services include, but are not limited to, medical consultation services, mobile tracking services, residential information services, office information services, and user-related status services. The medical consultation service is used to query a user's medical records, such as which hospital the user visited, which clinic the user attended, and their medical records. The mobile tracking service is used to query a user's movement trajectory. For example, the user's mobile phone's movement trajectory can be obtained through the positioning function on the user's terminal device, or through a positioning service provider. The residential information service is used to query a user's residential information, such as the residential community and location. The office information service is used to query work-related information, such as the user's office location or colleagues. The user-related status service is used to query information about other people associated with the user, such as roommates or family members.

[0061] The configuration processes for local built-in services and custom services are different. The following describes the configuration processes for local built-in services and custom services:

[0062] In this embodiment, when at least one data providing service includes a local built-in service, the local built-in service may be dependent on a third-party service or may not be dependent on a third-party service, and there is no limitation on this. Among them, if the local built-in service depends on a third-party service, the server domain name of the third-party service that the local built-in service depends on is built into the server-side device 101, so that when the server-side device 101 calls the local built-in service, it can directly access the third-party service that the local built-in service depends on based on the server domain name, thereby obtaining the user's data records on the corresponding health-related dimensions. If the local built-in service does not depend on a third-party service, a script file corresponding to the local built-in service is stored in the designated database, and the server-side device 101 is configured with the script ID of the script text in the designated database, so that when the server-side device 101 calls the local built-in service, it can directly call the script file corresponding to the local built-in service in the designated database based on the script ID, thereby obtaining the user's data records on the corresponding health-related dimensions.

[0063] For data records on health-related dimensions that require minimal memory but are frequently accessed, a script file for retrieving these data records can be pre-generated and stored in the local database. Preferably, the script file can be implemented as a Groovy script. Groovy is a Java Virtual Machine-based development language that combines many powerful features of Python, Ruby, and Smalltalk. Groovy code integrates well with Java code and can also be used to extend existing code.

[0064] Optionally, for local built-in services, the server device 101 may provide a configuration function for whether to use the local built-in service, and the health service demander may configure whether to use the local built-in service by turning the local built-in service on or off. For example, the server device 101 may provide a configuration interface that the service demander may access on the terminal device used by the service demander. The configuration interface may be provided with a configuration control that can be turned on or off, and the service demander may choose whether to use the local built-in service through the configuration control. If the service demander chooses to turn on the configuration control, it indicates that the local built-in service is used; if the service demander chooses to turn off the configuration control, it indicates that the local built-in service is not used, and there is no limitation on this.

[0065] In this embodiment, when at least one data provision service includes a custom service, an implementation method for configuring the custom service includes: if the custom service depends on a third-party service, configuring the server domain name of the third-party service on the server device so that the server device can access the third-party service through an API; if the custom service does not depend on a third-party service, uploading the script file corresponding to the custom service to a designated database, and configuring the script ID of the script file in the designated database on the server device so that the server device can call the custom service.

[0066] Further optionally, regardless of the configuration method adopted, before configuring the custom service on the server-side device, a service configuration request reported by the health event occurrence party can also be received, and the service configuration request includes event details information; then, a custom service is generated based on the event details information; thereafter, the custom service can be configured on the server-side device for the service demander to use the custom service. Wherein, the health event occurrence party refers to the party where the health event occurs or a person closely related to the health event. For example, assuming that an epidemic occurs in area A, the relevant personnel in area A can send a service configuration request to their superior government department (equivalent to the service demander) as the health event occurrence party to request health services for the epidemic in area A; after the service demander receives the service configuration request reported by the health event occurrence party, it parses the event details information from the service configuration request, determines which dimensions of data records are required and how to process them based on the event details information, and generates a custom service accordingly, configures the custom service on the server-side device, and the server-side device provides targeted health services for the epidemic in area A. Wherein, the event details information includes the time and place of the event, the relevant personnel involved in the event, the severity of the event, etc.

[0067] Further optionally, for a custom service, whether configured through a configuration interface provided by the server device or configured by the configuration device 102, a detailed configuration process of a custom service includes the following operations:

[0068] In response to a service configuration operation, a service configuration interface is displayed, which includes a first configuration item indicating whether the custom service depends on a third-party service. The service requester can use the first configuration item to configure whether the custom service depends on the third-party service. For example, the first configuration item can be in the form of a drop-down list including two options: dependent and not dependent. The service requester can select the dependent or not dependent option to configure whether the custom service depends on the third-party service. In another example, the first configuration item can be a text input box, in which the service requester can enter the text "dependent" or "not dependent" to configure whether the custom service depends on the third-party service. In another example, the first configuration item can also include two options: dependent and not dependent. The user can select the dependent or not dependent option by checking or clicking to configure whether the custom service depends on the third-party service. Regardless of the method used, the service requester needs to initiate a configuration operation on the first configuration item. Based on this, in response to the configuration operation on the first configuration item, configuration information on whether the custom service depends on the third-party service can be obtained.

[0069] Furthermore, if the custom service depends on a third-party service, a second configuration item is displayed for configuring the service domain name of the third-party service. This second configuration item allows the service requester to configure the server domain name of the third-party service and can be a text input box. The service requester can enter the server domain name of the third-party service in the text input box. Based on this, in response to the configuration operation of the second configuration item, the server domain name of the third-party service is obtained for accessing the third-party service, thus completing the configuration of the custom service that depends on the third-party service.

[0070] Furthermore, if the custom service doesn't rely on third-party services, a script file upload control and a script ID configuration item will be displayed. The script text upload control allows the service requester to upload the script file for the custom service. The script ID configuration item allows the service requester to configure the script ID of the custom service, thereby facilitating the acquisition of the script file corresponding to the custom service. Based on this, on the one hand, a trigger operation on the script file upload control can be responded to to upload the script file corresponding to the custom service to a specified database; on the other hand, a configuration operation on the script ID configuration item can be responded to to obtain the script ID of the script file in the specified database for invoking the custom service, thus completing the configuration of the custom service that does not rely on third-party services.

[0071] In this embodiment, in addition to dynamically configuring at least one data provision service, the configuration device 102 can also dynamically configure a data aggregation service. Optionally, the data aggregation service can be locally built-in or customized by the health service demander. In addition, whether the data aggregation service is locally built-in or customized, it can rely on a third-party service or not. The third-party service that the data aggregation service relies on refers to a service that can perform aggregate calculations, and is functionally different from the third-party service that the data provision service relies on. Among them, the process of configuring the data aggregation service is the same or similar to the process of configuring the data provision service. For specific details, please refer to the aforementioned embodiment and will not be repeated here. In the case that the data aggregation service is a customized service, its detailed configuration process is the same or similar to the detailed configuration process of the customized data service provision. Please refer to the aforementioned embodiment and will not be repeated here.

[0072] After configuring at least one data provision service and data aggregation service, the server device 101 can call at least one data provision service to obtain the user's data records in at least one health-related dimension according to the set health code information generation time, such as 10 o'clock every night or 1 o'clock every morning, etc., or when receiving the first service request initiated by the user; then, call the data aggregation service, and the data aggregation service generates the user's health code information based on the user's data records in at least one health-related dimension.

[0073] In this embodiment, an implementation method for generating a user's health code information by a data aggregation service based on the user's data records in at least one health-related dimension includes: the data aggregation service performs aggregation judgment based on the health status judgment conditions in at least one health-related dimension and the user's data records in at least one health-related dimension to obtain the user's health status information; and generates the user's health code information based on the user's health status information and the user's identification information.

[0074] In this embodiment, the health status determination conditions in at least one health-related dimension are not limited, and the health status determination conditions may vary depending on the user's data records in at least one health-related dimension. For example, in the dimension of movement trajectory, if the user's data record in this dimension is the user's movement trajectory, then the health status determination condition may be to determine whether the user has been to a certain city, or to determine whether the user has been to a certain area, or to determine whether the user has been to a certain community, etc., without limitation. For another example, in the dimension of medical records, if the user's data record in this dimension is the user's medical records, then the health status determination condition may be to determine whether the user has been to a hospital, or to determine whether the user has been to a specific clinic, without limitation. It should be noted that the health status determination conditions may be flexibly set according to different application scenarios or according to different needs.

[0075] In this embodiment, the implementation method of the data aggregation service for obtaining the user's health status information by performing aggregation judgment based on the health status judgment conditions on at least one health-related dimension and the user's data records on at least one health-related dimension is not limited. For example, if the user meets the health status judgment conditions in all health-related dimensions, the user's health status information is low health risk; if the user does not meet the health status judgment conditions in one health-related dimension, the user's health status information is medium health risk; if the user does not meet the health status judgment conditions in two or more health-related dimensions, the user's health status information is high health risk. For another example, if the user meets the health status judgment conditions in all health-related dimensions, the user's health status information is healthy; if the user does not meet the health status judgment conditions in one or more health-related dimensions, the user's health status information is unhealthy.

[0076] In this embodiment, an implementation method for generating a user's health code information based on the user's health status information and the user's identification includes: determining the user's health code color based on the user's health status information; and generating health code information including the health code color and the user's identification information.

[0077] In this embodiment, the method of determining the color of the user's health code based on the user's health status information is not limited. For example, if the user's health status information is low health risk, the health code color can be green; if the user's health status information is medium health risk, the health code color can be yellow; if the user's health status information is medium health risk, the health code color can be red. For another example, if the user's health status information is healthy, the health code color can be blue; if the user's health status information is unhealthy, the health code color can be yellow, and there is no limitation on this.

[0078] In this embodiment, the implementation form of the health code is not limited. For example, it can be in the form of a QR code, an "arrow" pattern, or a configuration control with user health status information. There is no limitation on this.

[0079] In this embodiment, a first user can send a first service request to the server device 101, and the server device 101 returns health code information to the first user based on the first service request. An implementation method for returning the health code information of the first user based on the first service request includes: parsing the first user's identification information and facial image from the first service request; obtaining the first user's health code information from the health code information of at least one user based on the first user's identification information; and combining the first user's health code information and the first user's facial image and returning the combined information to the first user.

[0080] Optionally, the health code information of the first user, the facial image of the first user, and the identification information of the first user are combined and returned to the first user and displayed. In this embodiment, the combination of the health code information of the first user, the facial image of the first user, and the identification information of the first user is not limited. For example, the facial image of the first user may be at the top, the health code information of the first user may be in the middle, and the identification information of the first user may be at the bottom; or the health code information of the first user may be at the top, the identification information of the first user may be in the middle, and the facial image of the first user may be at the bottom, and there is no limitation on this. Further optionally, when displaying the identification information of the user, in order to ensure the security of the user's information and protect the user's privacy, the identification information of the first user may be blurred or hidden when the identification information of the first user is returned to the first user.

[0081] Furthermore, in some optional embodiments, in addition to generating the health code color, the server-side device may also generate reason information corresponding to the health code color, and return the reason information to the first user's terminal device for the terminal device to display to the user. For example, when the health code color is red, the reason information returned may be that the first user has been to a high-risk area such as City F in the past 14 days; when the health code is green, the reason information returned may be that the first user has not left the city G where he lives in the past 14 days; when the health code is yellow, the reason information returned may be that the first user has left the city G where he lives in the past 14 days, but has not been to a high-risk area such as City F, and so on. The reason information here is only illustrated by the movement trajectory of the first user as an example, but is not limited to this. For example, it can also be combined with the medical status of the first user, as well as the trajectory, medical status and other information of his family members.

[0082] In the case where the server device returns the health code information and the reason information corresponding to the health code color in the health code information, from the perspective of the first user terminal device, after sending the first service request to the server device, the server device can receive the health code information of the first user and the reason information corresponding to the health code color in the health code information; then, the health code information and the reason information corresponding to the health code color are displayed on the health code interface. Among them, the health code information includes the health code color and the identification information of the first user, and further, it can also include the facial image of the first user (i.e., face image).

[0083] Furthermore, the health code interface may also include: a complaint control corresponding to the above-mentioned reason information, so that the first user can file a complaint against the reason information if the first user finds that the reason information is inaccurate or erroneous. When the first user needs to file a complaint against the reason information, the complaint control on the health code interface can be triggered; the terminal device can respond to the first user's triggering operation on the complaint control and send a complaint request to the server device or the health service demander to file a complaint against the reason information. This is conducive to protecting the legitimate rights and interests of users and facilitating the improvement of user experience and service quality. The complaint control can be a button or a link to a complaint page. Furthermore, after the first user clicks the button or link, the complaint interface can be displayed; the first user can enter the reason for the complaint on the complaint interface and submit relevant supporting materials, etc. Furthermore, the health service demander or the server device can also update or adjust the health code information of the first user if the review is passed.

[0084] The following Figure 3a As shown, taking the third-party services of mobile trajectory service, residence service and medical service as an example, the entire service process of providing health code information is described in detail.

[0085] In this embodiment, when the server-side device 101 receives the first service request from the first user, it calls the multi-level health service in real time to generate health code information for the first user, and returns the real-time generated health code information to the first user. Among them, the multi-level health service includes 3 data provision services and 1 data aggregation service. Among the 3 data service providers, the mobile trajectory service and the medical service are local built-in services that rely on third-party services, and the residence service is a custom service that does not rely on third-party services. The server-side device 101 can call the mobile trajectory service, the medical service and the residence service to respectively obtain the data records of the first user in the three health-related dimensions, namely the first user's mobile trajectory, the first user's medical records and the first user's residence information.

[0086] In this embodiment, in these three health-related dimensions, the health status determination conditions are whether the user's movement trajectory indicates that the user has been to community M, whether the user's medical record indicates that the user has been to a fever clinic, and whether the user's residence information indicates that the user lives in community N. If the user's health status determination conditions in the three health-related dimensions are all "no", the user's health status information is determined to be low health risk or no risk; if the user's health status determination conditions in the three health-related dimensions are "yes" for one, the user's health status information is determined to be medium health risk; if the user's health status determination conditions in the three health-related dimensions are "yes" for two or three, the user's health status information is determined to be high health risk. The relationship between the health risk level and the determination condition is not limited to the one listed here. For example, if the user has been to community M, regardless of the judgment results of the other two health-related dimensions, the user's health status information can be directly determined to be high health risk; if the user has not been to community M, and one of the judgment results of the other two health-related dimensions is yes and the other judgment result is no, then the user's health status information is determined to be medium health risk; if the user has not been to community M, and the judgment results of the other two health-related dimensions are both no, then the user's health status information is determined to be low health risk or no risk.

[0087] In this embodiment, if the user's health status information is low health risk or no risk, the health code color is determined to be green; if the user's health status information is medium health risk, the health code color is determined to be yellow; if the user's health status information is high health risk, the health code color is determined to be red.

[0088] In addition, the server device 101 can parse the first user's identification information and facial image from the first service request sent by the first user, obtain the first user's health code information based on the first user's identification information, and further return the health code information, the first user's identification information, and the first user's facial image to the first user, and the first user displays the health code information, the first user's identification information, and the first user's facial image on the terminal device 103. The first user's identification information can be any information that can uniquely identify the first user, such as a mobile phone number, an email address, or a registered account.

[0089] In the embodiment of the present application, in addition to dynamically configuring multi-level health services on the server device 101 based on health service requirements, the configuration device 102 can also dynamically configure other health services on the server device 101 based on health service requirements, such as Figure 3bThe service content and service forms that other health services can provide are different from those of multi-level health services. For example, other health services may include but are not limited to at least one of the following: health code information query service, health code information verification service and health status reporting service, etc. Figure 3b shown.

[0090] Among them, the health code information query service refers to the service of querying health code information. The health code information may include but is not limited to color information, user information or user avatar information, etc. The health code information verification service refers to the service of verifying health code information. For example, it can verify whether the health code information displayed by the user is accurate and check whether there is any health code fraud. The health status reporting service refers to a service for users or relevant personnel to report health status and health status-related information, such as reporting the user's movement trajectory, the user's medical records, the user's health status and / or the user's health code information, etc., without limitation.

[0091] Based on the above, the server device can also receive a second service request from a second user; the second service request is different from the first service request, and refers to a service request for requesting other health services; other health services are called to process the second service request, and the service result corresponding to the second service request is returned to the second user; wherein, at least one user includes the second user. In this embodiment, the first user and the second user may be the same user or may not be the same user. In addition, depending on the different other health services required, the second user may be a user who needs to provide health status or a health service demander, and there is no limitation on this.

[0092] Optionally, the second service request includes identification information of the second user. The server device 101 parses the identification information of the second user from the second service request and returns a service result corresponding to the second service request to the second user based on the identification information of the second user, without limitation. The identification information of the second user may be an email address, mobile phone number, or registered account number of the second user, without limitation.

[0093] In an optional embodiment, in order to more conveniently use other health services, the configuration device 102 can dynamically configure custom pre-operations and / or custom post-operations of other health services, such as Figure 3b Correspondingly, the server device 101 may also perform pre-processing on the second service request using a custom pre-operation; and / or perform post-processing on the service result corresponding to the second service request using a custom post-operation.

[0094] Among them, the custom pre-operations and custom post-operations can be large-scale, complicated or repetitive operations that the data providing service and data aggregation service do not have to perform. For example, assuming that other health services can only recognize encoded data, the custom pre-operation can be an encoding operation, which is used to encode the second service request and provide it to other health services; accordingly, the custom post-operation can be a decoding operation, which is used to decode the service result corresponding to the second service request into a service result that can be understood by the second user. For another example, assuming that other health services can only recognize data objects with standard input data structures, the custom post-operation can be an input data format conversion operation, which is used to convert the second service request into a standard input data structure and then provide it to other health services; accordingly, the custom post-operation is an output data format conversion operation, which is used to convert the service result into a standard output data structure.

[0095] Figure 4a A flowchart of a health service method provided by an exemplary embodiment of the present application is shown as follows: Figure 4a As shown, the method includes:

[0096] 41a. Based on health service needs, dynamically configure the multi-level health services required to generate health code information;

[0097] 42a. Invoke the multi-level health service to generate health code information for at least one user;

[0098] 43a. Receive a first service request from a first user, where the at least one user includes the first user;

[0099] 44a. Return the health code information of the first user to the first user according to the first service request.

[0100] In an optional embodiment, based on health service needs, multi-level health services required to generate health code information are dynamically configured, including: determining current health service needs based on the geographical attributes, time attributes and / or application scenarios corresponding to the health services; obtaining multi-level health services that are adapted to the current health service needs, and configuring multi-level health services that are adapted to the current health service needs.

[0101] In an optional embodiment, configuring a multi-level health service adapted to the current health service demand includes: configuring at least one data service provision adapted to the current health service demand; configuring a data aggregation service adapted to the current health service demand; wherein the data aggregation service is cascaded after at least one data service provision.

[0102] In an optional embodiment, invoking a multi-level health service to generate health code information for at least one user includes: obtaining data records of the user in at least one health-related dimension through at least one data service for any of the at least one user; and generating the user's health code information by a data aggregation service based on the user's data records in at least one health-related dimension. If multiple data provision services are provided, they can be executed concurrently.

[0103] In an optional embodiment, at least one data service provision includes local built-in services and / or custom services; when at least one data service provision includes a custom service, at least one data service provision adapted to the current health service needs is configured, including: if the custom service depends on a third-party service, then the server domain name of the third-party service is configured for access to the third-party service; if the custom service does not depend on a third-party service, then the script file corresponding to the custom service is uploaded to the designated database, and the script ID of the script file in the designated database is configured for calling the custom service.

[0104] Further optionally, the detailed process of configuring the custom service includes: in response to a service configuration operation, displaying a service configuration interface, which includes a first configuration item indicating whether the custom service depends on a third-party service; in response to a configuration operation on the first configuration item, obtaining configuration information on whether the custom service depends on a third-party service; if the custom service depends on a third-party service, displaying a second configuration item for configuring the service domain name of the third-party service; in response to a configuration operation on the second configuration item, obtaining the server domain name of the third-party service for accessing the third-party service. Furthermore, if the custom service does not depend on a third-party service, displaying a script file upload control and a script ID configuration item; in response to a trigger operation on the script file upload control, uploading the script file corresponding to the custom service to a specified database; and in response to a configuration operation on the script ID configuration item, obtaining the script ID of the script file in the specified database for calling the custom service.

[0105] Further optionally, before configuring the custom service on the server device, it also includes: receiving a service configuration request reported by the party that caused the health event, the service configuration request including event details information; and generating a custom service according to the event details information.

[0106] In an optional embodiment, the local built-in service also includes a local built-in service that depends on a third-party service and / or a local built-in service that does not depend on a third-party service; for any one of the at least one users, obtaining the user's data records on at least one health-related dimension through at least one data provision service, including: based on the script ID corresponding to the first service, loading the script file corresponding to the first service in the specified database to obtain the user's data records on the health-related dimension corresponding to the first service; and / or accessing the third-party service pointed to by the server domain name based on the server domain name corresponding to the second service to obtain the user's data records on the health-related dimension corresponding to the second service; wherein the first service refers to a local built-in service and / or a custom service that does not depend on a third-party service; the second service refers to a local built-in service and / or a custom service that depends on a third-party service.

[0107] Further optionally, the third-party service includes at least one of the following: a medical inquiry service, a movement trajectory inquiry service, a residence information inquiry service, an office information inquiry service, and an associated user status inquiry service.

[0108] In an optional embodiment, the data aggregation service generates the user's health code information based on the user's data records in at least one health-related dimension, including: the data aggregation service aggregates and judges the health status judgment conditions in at least one health-related dimension and the user's data records in at least one health-related dimension to obtain the user's health status information; and generates the user's health code information based on the user's health status information and the user's identification information.

[0109] In an optional embodiment, the user's health code information is generated based on the user's health status information and the user's identification, including: determining the user's health code color based on the user's health status information; generating health code information including the health code color and the user's identification information.

[0110] In an optional embodiment, the health code information of the first user is returned to the first user according to the first service request, including: parsing the first user's identification information and facial image from the first service request; obtaining the first user's health code information from the health code information of at least one user according to the first user's identification information; and combining the first user's health code information and the first user's facial image and returning them to the first user.

[0111] Furthermore, in an optional embodiment, when the health code information includes the health code color, reason information corresponding to the health code color can also be generated and returned to the first user so that the user can know the reason information corresponding to the health code color.

[0112] In an optional embodiment, the method of this embodiment also includes: dynamically configuring other health services according to health service needs; receiving a second service request from a second user; calling other health services to process the second service request, and returning the service result corresponding to the second service request to the second user.

[0113] Further optionally, the method of this embodiment also includes: dynamically configuring custom pre-operations and / or custom post-operations of other health services; accordingly, before calling other health services to process the second service request, it also includes: using custom pre-operations to pre-process the second service request; and / or before returning the service result corresponding to the second service request to the second user, it also includes: using custom post-operations to post-process the service result corresponding to the second service request.

[0114] In an optional embodiment, other health services include at least one of the following: health code information query service, health code information verification service and health status reporting service.

[0115] In an optional embodiment, the at least one user includes a user who is in or has entered the geographical area indicated in the health service demand, or a user in the application scenario indicated in the health service demand.

[0116] The embodiment of the present application provides a health service method, in which a configuration device dynamically configures the multi-level health service required to generate health code information based on health service needs. The server device can call the dynamically configured multi-level health service to generate health code information for the user. The user can initiate a service request to obtain health code information to the server device through the terminal device, obtain the health code information from the server device, and realize intelligent management of the user's health status. Among them, the multi-level health service required to dynamically configure and generate health code information based on health service needs can meet the differentiated needs of the user's health status in different application scenarios, different regions and / or different time periods, solve the problem of intelligent management of health status under multiple service needs, and greatly reduce the development cost of health services.

[0117] The present application also provides a method for displaying health code information. Figure 4b As shown, the method includes:

[0118] 41b. Send a service request to the server device to request the user's health code information, which includes the health code color and the user's identification information.

[0119] 42b. Receive the health code information and reason information corresponding to the health code color returned by the server device.

[0120] 43b. On the health code interface, the health code information and the reason information corresponding to the health code color are displayed.

[0121] Further, if Figure 4b As shown, after step 43b, the method further includes:

[0122] 44b. In response to the user triggering the appeal control corresponding to the reason information on the health code interface, send an appeal request to the server device or the health service demander to initiate an appeal regarding the reason information.

[0123] In this embodiment, the user can request the server device for his corresponding health code information through his terminal device, and the health code information includes the health code color and the user's identification information; the server device can return his health code information to the user, and further return the reason information corresponding to the health code color in his health code information to the user, so that the user can know the reason information corresponding to the health code color.

[0124] Furthermore, the health code interface will also feature a complaint control corresponding to the reason information, allowing users to file a complaint against the reason information if they find it inaccurate or erroneous. When a user needs to file a complaint regarding the reason information, they can trigger the complaint control on the health code interface. The terminal device will respond to the user's triggering of the complaint control by sending a complaint request to the server device or health service requester to file a complaint regarding the reason information. This helps protect the legitimate rights and interests of users and improves user experience and service quality.

[0125] Optionally, the appeal control can be a button or a link to an appeal page. Furthermore, after the first user clicks the button or link, an appeal interface can be displayed; the first user can enter the reason for the appeal on the appeal interface and submit relevant supporting documents. Furthermore, if the health service requester or service-side device passes the review, it can also update or adjust the first user's health code information.

[0126] The present application also provides a service configuration method, which is mainly used to configure a custom service, such as Figure 4c As shown, the method includes:

[0127] 41c. In response to the service configuration operation, a service configuration interface is displayed, where the service configuration interface includes a first configuration item indicating whether the custom service depends on a third-party service.

[0128] 42c. In response to the configuration operation on the first configuration item, obtain configuration information of whether the custom service depends on a third-party service.

[0129] 43c. If the custom service depends on a third-party service, the second configuration item for configuring the service domain name of the third-party service is displayed.

[0130] 44c. In response to the configuration operation on the second configuration item, obtain the server domain name of the third-party service for accessing the third-party service.

[0131] Further, if Figure 4c As shown, the method further includes:

[0132] 45c. If the custom service does not rely on third-party services, the script file upload control and script ID configuration items are displayed.

[0133] 46c. In response to the triggering operation of the script file upload control, the script file corresponding to the custom service is uploaded to the specified database.

[0134] 47c. In response to the configuration operation on the script ID configuration item, the script ID of the script file in the specified database is obtained for calling the custom service.

[0135] Furthermore, in an optional embodiment, before configuring the custom service, the method further includes: receiving a service configuration request reported by a party that caused a health event, the service configuration request including event details information; and generating a custom service according to the event details information.

[0136] It should be noted that the technical principles provided by the above embodiments of this application for dynamically configuring multi-level health services based on health service needs in the user health field to provide user health code information on demand can also be extended to other fields with status code information needs. For example, it can be extended to the field of traffic health management to provide traffic health codes of vehicles or vehicle owners to traffic information demanders. For another example, it can be extended to the field of community management to provide community code information of community members to community managers. The community code information can indicate various statuses of community members such as age and residence according to application requirements. For another example, it can be extended to emergency affairs scenarios to provide emergency code information of emergency objects such as people or objects involved in emergency scenarios to emergency managers. The emergency code information can indicate various emergency statuses of emergency objects according to application requirements. For another example, it can be extended to the scenario of tracking industrial hazardous waste to provide tracking code information of industrial hazardous waste to regulators. The tracking code information can indicate various processing statuses of industrial hazardous materials according to application requirements. For another example, it can be extended to the scenario of health and medical tracking to provide health and medical management parties with health and medical code information of relevant personnel; the health and medical code information indicates the hygiene and health status of the personnel. For another example, it can also be expanded to the field of business management, providing the enterprise's license code information to the enterprise regulator, and the license code information indicates the business status of the enterprise.

[0137] In view of the above, an embodiment of the present application also provides a code information processing system, which includes: a server device and at least one terminal device; the server device is used to obtain a multi-level status code service dynamically configured based on status code service requirements, and call the multi-level status code service to generate status code information for at least one data object; and receive a first service request from a first terminal device, and return the status code information of a first data object to the first terminal device according to the first service request, where the first data object belongs to at least one data object; the first terminal device is used to send the first service request to the server device, and receive and display the status code information of the first data object returned by the server device; the first terminal device belongs to at least one terminal device.

[0138] In an embodiment of the present application, a data object refers to an object related to the status code information, which may be the above-mentioned community personnel, vehicles, emergency objects, hazardous waste or other relevant personnel involved in health and health status, etc. In this embodiment, the status information of the data object is represented by status code information. In different fields or scenarios, the status information of the data object represented by the status code information will be different. In this embodiment, the process of generating status code information for the data object is divided into multiple stages, each stage is completed by an independent status code service, and the status code services in adjacent stages are cascaded, that is, the results of the status code service in the previous stage are aggregated as the input of the status code service in the next stage, and are executed in sequence until the status code service in the last stage generates status code information. In this embodiment, according to the relationship between the multiple stages of generating status code information, the status code service required to generate the status code is divided into multiple levels, which are called multi-level status code services required to generate status code information.

[0139] Specifically, the server-side device generates status code information for a data object based on the multi-level status code service required to generate status code information; when a status code information demander needs status code information for a certain data object or certain data objects, they can initiate a service request for obtaining status code information to the server-side device through the terminal device, obtain status code information of the relevant data object from the server-side device, and then carry out subsequent operations related to the data object based on the obtained status code information, such as tracking, troubleshooting, or positioning. It should be noted that this embodiment does not limit the device form of the server-side device and the terminal device. For example, the server-side device can be, but is not limited to: a conventional server, a cloud server, or a server array, etc.; the terminal device can be, but is not limited to: a smart phone, a tablet computer, a desktop computer, or a smart TV, etc.

[0140] In this embodiment, it is taken into account that the service requirements for the status information of data objects may be different in different application scenarios, in different regions and / or at different times. In view of the above considerations, in an embodiment of the present application, the server-side device adopts a configurable status code engine framework, and the multi-level status code service for generating status code information runs in the status code engine framework and allows the multi-level status code service to be dynamically configured. Specifically, in an embodiment of the present application, it is allowed to dynamically configure the multi-level status code service required to generate status code information based on the status code service requirements. Specifically, before calling the multi-level status code service, the server-side device 101 can obtain the multi-level status code service that is dynamically configured based on the status code service requirements; thereafter, the multi-level status code service is called to generate status code information for at least one data object.

[0141] In an optional embodiment, the above-mentioned code information processing system also includes: a configuration device, which is used to dynamically configure the multi-level status code service required to generate status code information on the server-side device based on the status code service requirements. In this case, the server-side device can directly obtain the multi-level status code service dynamically configured by the configuration device. In the embodiment of the present application, the implementation form of the configuration device is not limited. For example, the configuration device can be but not limited to: a conventional server, a cloud server, a server array, a virtual machine (VM) or a container, etc. For the server-side device, the multi-level status code service dynamically configured by the configuration device can be called to generate status code information for the data object. In other words, when the multi-level status code service used to generate status code information changes, the logic of the server-side device to generate status code information for the data object will also change.

[0142] Among them, the status code service demand refers to the service demand of the status code service demander for the status of the data object, which at least includes the service logic required by the status code service demander for generating the status code information and the data dimensions on which the status code information is generated. In the case where the process of generating the status code information includes multiple stages, the service logic required by the status code service demander for generating the status code information includes service logic corresponding to the multiple stages. Among them, the status code service demand will be different depending on the application scenario, regional attributes and / or time attributes of the status code service required, and accordingly, the service logic of the configured multi-level status code service will also be different. Optionally, the configuration device can determine the current status code service demand based on the regional attributes, time attributes and / or application scenarios corresponding to the status code service; obtain a multi-level status code service that is compatible with the current status code service demand, and configure a multi-level status code service that is compatible with the current status code service demand on the server-side device.

[0143] In each embodiment of the present application, the number of levels of the multi-level status code service is not limited. For example, it can be 2, 3, 5, etc., which can be determined according to the stage division of the process of generating status code information. In an optional embodiment, the process of generating status code information is divided into two stages, one stage is the data acquisition stage, and the other is the data aggregation stage; wherein, the data acquisition stage is responsible for obtaining the data records of the data object required to generate the status code information in at least one dimension. The data aggregation stage is mainly responsible for judging the status of the data object based on the data records of the data object in at least one dimension obtained in the data acquisition stage, and generating status code information based on the judgment result. Based on this, the multi-level status code service includes two levels of status code services. The first level status code service includes at least one data service provider, and the second level status code service is a data aggregation service cascaded after at least one data service provider. Among them, each data service provider is responsible for obtaining the data records of the data object in one dimension, and the number of data service providers is determined by the number of dimensions required in the status code service requirements; corresponding to data service providers of different dimensions, the service logic for obtaining data records will be different. In the case where a multi-level status code service includes at least one data provision service and a data aggregation service cascaded after the at least one data provision service, the process of generating status code information for a data object by a server-side device includes: for any data object, the server-side device may obtain data records for the data object in at least one dimension through the at least one data provision service; and the data aggregation service may generate status code information for the data object based on the data records for the at least one dimension. Optionally, the data provision service may be implemented as an atomic service or a composite service, without limitation.

[0144] Furthermore, in this embodiment, data provision services can be divided into data provision services that rely on third-party services and data provision services that do not rely on third-party services. Among them, data provision services that rely on third-party services refer to a service form in which data records of a data object in one or more dimensions can be obtained by calling a third-party service through an API. Data provision services that do not rely on third-party services refer to a service form in which data records of a data object in one or more dimensions can be obtained without calling a third-party service through an API. For example, data records of a data object in one or more dimensions can be obtained directly from the local memory or hard disk of the server-side device.

[0145] Furthermore, the data provision services are classified from another perspective. At least one data service provision in this embodiment includes local built-in services and / or custom services. The at least one data service provision may include only local built-in services, only custom services, or both local built-in services and custom services. Among them, local built-in services refer to data service provision that exists by default, that is, data service provision that can be used directly, and local built-in services can be services corresponding to any dimension. Custom services refer to data service provision that can be customized by the status code service demander according to its own needs. Custom services can also be services corresponding to any dimension. It should be noted that when both local built-in services and custom services are included, the dimensions corresponding to local built-in services and custom services do not overlap.

[0146] In summary, the data provision service of this embodiment can be a local built-in service, which can be dependent on a third-party service or not; the data provision service of this embodiment can also be a custom service, which can be dependent on a third-party service or not. After the data provision service and the data aggregation service are dynamically configured on the server-side device according to the status code service requirements, the server-side device can sequentially call the data provision service and the data aggregation service to generate status code information for the data object; and based on the first service request initiated by the status code service demander through the first terminal device, the server-side device can obtain the first service request and return the status code information of the first data object to the first terminal device, so that the status code service demander can perform subsequent processing accordingly.

[0147] Furthermore, the configuration device is also used to: dynamically configure other status code services on the server device according to the status code service requirements. The service content and service form that other status code services can provide are different from the multi-level status code services. For example, other status code services may include but are not limited to at least one of the following: status code information query service, status code information verification service and status reporting service, etc. Based on this, the server device is also used to: receive a second service request from a second terminal device, call other status code services to process the second service request, and return the service result corresponding to the second service request to the second terminal device, and the second terminal device belongs to at least one terminal device. The second service request is different from the first service request, and refers to a service request for requesting other status code services.

[0148] It should be noted that the code information processing system of this embodiment can be applied to various fields or scenarios. In different fields or scenarios, the meaning and content of the status code service demander, data object and status code information will be different. An example is given below to illustrate this.

[0149] For example, in the field of traffic health management, a traffic health code service system can be provided for traffic information demanders (a specific implementation of the above-mentioned status code service demanders). In this service system, a multi-level traffic health code service can be dynamically configured based on the traffic health code service demand. The server-side device can generate a traffic health code for each vehicle (a specific implementation of the above-mentioned data object) through the dynamically configured multi-level traffic health code service, and can respond to the service request initiated by the traffic information demander, and return the traffic health code of the target vehicle requested by the service request to the traffic information demander according to the service request, so that the traffic information demander can quickly obtain the traffic status information of the vehicle in real time, solve the problem of difficult vehicle traffic status verification and slow response, and can also help the traffic information demander to unify and standardize management, and fast system synchronization and feedback can also help the traffic information demander save patrol expenses, save personnel management energy, and avoid the occurrence of some public security problems. Among them, the traffic information demander can be a government user related to traffic information, such as the transportation department / bureau of each province and city and / or the traffic management bureau of each city; it can also be an enterprise user related to traffic information, such as a bus group, an online car-hailing platform, a cruising taxi company, a logistics express company, etc. The traffic health code indicates the traffic status of the vehicle, such as free travel, congestion, traffic accident, etc. Furthermore, the traffic health code may also include some additional information, such as free travel time, congestion time, congestion level, and the time and road section of the traffic accident.

[0150] For another example, in the field of community management, a community code service system can be provided to the community management party (a specific implementation of the above-mentioned status code service demander). In this service system, based on the community code service demand, a multi-level community code service is dynamically configured. The server-side device can generate community code information of community members (a specific implementation of the above-mentioned data object) through the dynamically configured multi-level community code service, and can respond to the service request initiated by the community management party and return the community code information of the target person requested by the service request to the community management party according to the service request. Among them, the community code information reflects one or more status information of the community members. Of course, depending on the different community code service demands, the status information of the community members reflected by the community code information will also be different. For example, the community code information can reflect the living status of the community members, such as whether the community members live in the community; it can also reflect the health status of the community members, such as whether they have been to high-risk areas or high-risk cities or whether they have infectious diseases; it can also reflect the age status of the community members, such as whether they are elderly; it can also reflect the safety status of the community members, such as whether they are high-risk persons for public security; and so on. High-risk individuals are those who pose a threat to public security. Community managers can include neighborhood committees, community property management companies, and subdistrict governments, all of which have management authority and responsibilities. Through the community code service system, community managers can access various situations or information about community members as needed. This, to a certain extent, addresses the complex flow of community personnel and the difficulty in truly monitoring and avoiding risks. It also helps community managers implement tiered management and early warning of population and human flows, and helps communities better implement community identity registration, enabling targeted community services, better population control, and better maintenance of community and public security.

[0151] For another example, in some emergency response areas, an emergency code service system can be provided to emergency management parties (a specific implementation of the aforementioned status code service demander). In this service system, a multi-level emergency code service is dynamically configured based on emergency code service requirements. Using this dynamically configured multi-level emergency code service, the server-side device can generate emergency code information for emergency objects (a specific implementation of the aforementioned data objects). In response to service requests initiated by the emergency management party, the server-side device can return the emergency code information of the target emergency object requested by the service request to the emergency management party. The emergency code information reflects the emergency status of the emergency object in the emergency scenario. For example, in a natural disaster emergency scenario, the application object can be a person or an object, and the emergency code information can reflect the person's or object's state of distress, whether or not rescue is urgently needed, and other status information. For another example, in a production safety emergency scenario, the emergency object can be a product required for the emergency, and the emergency code information can reflect the production progress, safety and quality, and the movement of related equipment and personnel of the emergency product. The emergency management party can be a provincial emergency department, a municipal / district / county emergency management bureau, or a park management committee. Through the emergency code service system, emergency management can promptly monitor the status of emergency targets as needed. This can address the complex verification of personnel and items and slow mobilization responses in emergency scenarios, and in the area of safe production, it can also address the difficulty in controlling production safety in enterprises. Furthermore, in natural disaster emergency scenarios, the emergency code service system can help emergency management quickly allocate personnel and quickly classify and arrange affected people based on their emergency codes, minimizing the impact and economic losses caused by natural disasters. In safe production, it can record the movements of production machinery and personnel, enabling the fastest notifications and early warnings, reducing losses and risks.

[0152] For another example, in the field of industrial hazardous waste tracking codes, a tracking code service system can be provided to hazardous waste supervisors (a specific implementation of the above-mentioned status code service demander). In this service system, based on the hazardous waste tracking service needs, a multi-level tracking code service is dynamically configured. The server-side device can generate tracking code information for hazardous waste (a specific implementation of the above-mentioned data object) through the dynamically configured multi-level tracking code service, and can respond to the service request initiated by the hazardous waste supervisor, and return the tracking code information of the target hazardous waste requested by the service request to the hazardous waste supervisor according to the service request. Among them, the tracking code information reflects the processing status of the hazardous waste in the hazardous waste tracking scenario, such as whether it is recycled, landfilled, etc. Among them, the hazardous waste supervisor can be a hazardous waste supervision department, a production enterprise, a transportation enterprise, a processing enterprise or a storage enterprise, etc. Through the tracking code service system, hazardous waste regulators can promptly understand the hazardous waste treatment status of relevant enterprises as needed, conduct efficient inspections of enterprises, and help production enterprises reasonably analyze and control the declaration and disposal of hazardous waste. This can solve the problem that hazardous waste regulators are unable to verify the hazardous waste treatment status of enterprises, and are unable to monitor and inspect. It also solves the problem that errors caused by manual recording of hazardous waste treatment status by production enterprises cannot be traced.

[0153] For another example, in the field of health and wellness tracking, a health and wellness code service system can be provided to health and wellness management parties (a specific implementation of the above-mentioned status code service demand party). In this service system, based on the health and wellness tracking service needs, a multi-level health and wellness code service is dynamically configured. The server-side device can generate health and wellness code information for the relevant population through the dynamically configured multi-level health and wellness code service, and can respond to the service request initiated by the health and wellness management party, and return the health and wellness code information of the target person requested by the service request to the health and wellness management party according to the service request. Among them, the health and wellness code information reflects the health and wellness status of the relevant personnel, such as whether they are infected by the epidemic, whether they have infectious diseases, whether they have sought medical treatment or medical treatment, etc. Among them, the health and wellness management party can be a department or enterprise related to the health and wellness of the masses, such as the regional health and wellness commission, the disease control center or the hospital. Through the health code service system, health management can timely understand the health information of all personnel as needed, the disease control center can immediately provide timely feedback on some disease control risks through the update of health code information, and the hospital can also make reasonable and correct diagnosis based on the patient's current status and previous medical records, reducing medical risks. This solves the problems of the National Health Commission being unable to confirm and control the health status of the people, unable to respond to possible epidemic infections, and the hospital being unable to obtain the patient's previous medical information and make correct diagnoses.

[0154] For another example, in the field of food and drug enterprise supervision, a license code service system can be provided to enterprise regulators (a specific implementation of the above-mentioned status code service demander). In this service system, based on the enterprise's business license service needs, a multi-level license code service is dynamically configured. The server-side device can generate the license code information of each enterprise (especially food and drug enterprises) through the dynamically configured multi-level license code service, and can respond to the service request initiated by the enterprise regulator, and return the license code information of the target enterprise requested by the service request to the enterprise regulator according to the service request. Among them, the license code information reflects the business status of the enterprise, such as whether it is operating normally or illegally. Among them, the enterprise regulators can be national enterprises and individual industrial and commercial households, market supervision bureaus, etc. Through the license code service system, law enforcement standards can be unified, and targeted verification and disposal of the business status of enterprises can be achieved, helping enterprises to open license codes, meet the enterprise's production safety and real-time supervision needs, and thus solve problems such as inconsistent business status of enterprises, slow synchronization, weak full-process supervision capabilities, and inconsistent systems of regulatory departments.

[0155] In addition to the above system embodiments, the embodiments of the present application also provide a code information processing method, which includes the following steps: based on the status code service requirements, dynamically configuring the multi-level status code service required to generate status code information; calling the multi-level status code service to generate status code information for at least one data object; receiving a first service request from a first terminal device, the first service request being used to request status code information for a first data object; and returning status code information of a first data object to the first terminal device based on the first service request, the first data object belonging to at least one data object. For the detailed process of this method, please refer to the aforementioned code information processing system embodiment and the same or similar description in the aforementioned health service system embodiment, which will not be repeated here.

[0156] It should be noted that the execution entity of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. For example, the execution entity of steps 41a to 43a can be device A; for another example, the execution entity of steps 41a and 42a can be device A, and the execution entity of step 43a can be device B; and so on.

[0157] In addition, in some of the processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or may be executed in parallel. The sequence numbers of the operations, such as 41a, 42a, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to being different types.

[0158] Figure 5 This is a schematic diagram of the structure of a server device provided by an exemplary embodiment of the present application. Figure 5 As shown, the server device includes: a memory 54 , a processor 55 and a communication component 56 .

[0159] The memory 54 is used to store computer programs and can be configured to store various other data to support operations on the server device. Examples of such data include instructions for any application or method operating on the server device, contact data, phone book data, messages, images, videos, etc.

[0160] The memory 54 may be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0161] The processor 55 is coupled to the memory 54 and is used to execute the computer program in the memory 54 to: call the multi-level health service required to generate health code information to generate health code information for at least one user; and receive a first service request from a first user through the communication component 56, and return the health code information of the first user to the first user according to the first service request. The at least one user includes the first user, and the multi-level health service is dynamically configured based on the health service demand.

[0162] In an optional embodiment, the multi-level health service includes at least one data providing service and a data aggregation service cascaded after the at least one data providing service; when the processor 55 calls the multi-level health service to generate health code information for at least one user, it is specifically used to: for any one of the at least one users, obtain the user's data records in at least one health-related dimension through at least one data providing service; and the data aggregation service generates the user's health code information based on the user's data records in at least one health-related dimension.

[0163] In an optional embodiment, when there are multiple data provision services, the processor 55 is further configured to: obtain resource isolation parameters corresponding to the multiple data provision services; and implement resource isolation between the multiple data provision services based on the resource isolation parameters. The resource isolation parameters corresponding to the multiple data provision services are configured by the configuration device for the multiple data provision services.

[0164] In an optional embodiment, the server device of this embodiment is further configured with other health services, and the processor 55 is further configured to: receive a second service request from a second user; invoke the other health service to process the second service request, and return a service result corresponding to the second service request to the second user; wherein the at least one user includes the second user. The other health service is dynamically configured on the server device by the configuration device based on health service requirements.

[0165] In an optional embodiment, the processor 55 is further configured to: perform pre-processing on the second service request using a custom pre-operation; and / or perform post-processing on the service result corresponding to the second service request using a custom post-operation. The custom pre-operation and / or custom post-operation are dynamically configured by the configuration device for other health services.

[0166] Further, if Figure 5 As shown, the server device also includes: a power supply component 58 and other components. Figure 5 Only some components are shown schematically, which does not mean that the server device only includes Figure 5 Optionally, the server device can be implemented as a traditional server, a cloud server, or a server array.

[0167] It should be noted that, in addition to the above-mentioned operation of providing health code information, the server device of this embodiment, whose processor executes the computer program in the memory, can also implement the following operation of providing status code information:

[0168] Obtain multi-level status code services that are dynamically configured based on status code service requirements;

[0169] Invoke a multi-level status code service to generate status code information for at least one data object;

[0170] receiving a first service request from a first terminal device, where the first service request is used to request status code information of a first data object;

[0171] According to the first service request, status code information of a first data object is returned to the first terminal device, where the first data object belongs to at least one data object.

[0172] Among them, the detailed process of the processor implementing the above-mentioned operations related to the status code information is the same as or similar to the detailed process of the processor implementing the above-mentioned operations related to the health code information. Please refer to the above-mentioned embodiment and will not be repeated here.

[0173] Accordingly, an embodiment of the present application also provides a computer-readable storage medium storing a computer program, which, when executed, can implement the various steps that can be executed by the server-side device in the above-mentioned health service method embodiment.

[0174] Figure 6 This is a schematic diagram of a configuration device provided by an exemplary embodiment of the present application. Figure 6 As shown, the configuration device includes: a memory 64 and a processor 65.

[0175] The memory 64 is configured to store computer programs and may be configured to store various other data to support operations on the configured device. Examples of such data include instructions for any application or method operating on the configured device, contact data, phone book data, messages, images, videos, etc.

[0176] The memory 64 may be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0177] The processor 65 is coupled to the memory 64 and is used to execute the computer program in the memory 64 to: obtain health service requirements; and dynamically configure the multi-level health services required to generate health code information on the server device according to the health service requirements, so that the server device can generate health code information for at least one user based on the multi-level health services.

[0178] Among them, the demand for health services is changing dynamically. When the demand for health services changes, multi-level health services will also change accordingly.

[0179] In an optional embodiment, when the processor 65 dynamically configures the multi-level health services required to generate health code information on the server device based on the health service needs, it is specifically used to: determine the current health service needs based on the geographical attributes, time attributes and / or application scenarios corresponding to the health services; obtain multi-level health services that are adapted to the current health service needs, and configure the multi-level health services on the server device.

[0180] In an optional embodiment, the processor 65 is further configured to: when multiple data service providers are provided, configure resource isolation parameters for the multiple data service providers, so that the server-side device can implement resource isolation between the multiple data service providers based on the resource isolation parameters. Further optionally, when configuring resource isolation parameters for the multiple data service providers, the processor 65 is specifically configured to: configure a semaphore-based isolation method and its parameters for data service providers that do not rely on third-party services, and configure a thread pool-based isolation method and its parameters for data service providers that rely on third-party services.

[0181] In an optional embodiment, at least one data providing service includes a local built-in service and / or a custom service; based on this, when at least one data providing service includes a custom service, the processor 65 is specifically used to: if the custom service depends on a third-party service, configure the server domain name of the third-party service on the server device so that the server device can access the third-party service through an API; if the custom service does not depend on a third-party service, upload the script file corresponding to the custom service to the specified database, and configure the script ID of the script file in the specified database on the server device so that the server device can call the custom service.

[0182] Further optionally, when configuring the custom service, the processor 65 is specifically configured to:

[0183] In response to the service configuration operation, a service configuration interface is displayed, where the service configuration interface includes a first configuration item indicating whether the custom service depends on a third-party service; in response to the configuration operation on the first configuration item, configuration information indicating whether the custom service depends on the third-party service is obtained;

[0184] If the custom service depends on a third-party service, a second configuration item for configuring the service domain name of the third-party service is displayed; in response to the configuration operation on the second configuration item, the server domain name of the third-party service is obtained for accessing the third-party service;

[0185] If the custom service does not rely on third-party services, the script file upload control and script ID configuration item are displayed. In response to the trigger operation of the script file upload control, the script file corresponding to the custom service is uploaded to the specified database. In response to the configuration operation of the script ID configuration item, the script ID of the script file in the specified database is obtained for calling the custom service.

[0186] Further optionally, before configuring the custom service, the processor 65 is further configured to: receive a service configuration request reported by a party that causes a health event, the service configuration request including event details information; and generate a custom service according to the event details information.

[0187] In an optional embodiment, the processor 65 is further configured to dynamically configure other health services on the server device according to health service requirements.

[0188] In an optional embodiment, the processor 65 is further configured to dynamically configure customized pre-operations and / or customized post-operations of other health services.

[0189] Further, if Figure 6 As shown, the configuration device also includes: a communication component 66, a display 67, a power component 68, an audio component 69 and other components. Figure 6 Only some components are shown schematically, which does not mean that the configuration device only includes Figure 6 In addition, Figure 6 Components in dashed boxes are optional, not required, and depend on the implementation form of the configuration device. If the configuration device is implemented as a traditional server, cloud server, or server array, the components in dashed boxes may not be included.

[0190] It should be noted that, in addition to implementing the above-mentioned operations of configuring the multi-level health service, the configuration device of this embodiment, whose processor executes the computer program in the memory, can also implement the following operations of configuring the multi-level status code service:

[0191] Obtaining status code service requirements; dynamically configuring a multi-level status code service required to generate status code information on the server device, so that the server device generates status code information for at least one data object based on the multi-level status code service.

[0192] Among them, the detailed process of the processor implementing the above-mentioned configuration of the multi-level status code service is the same as or similar to the detailed process of the processor implementing the above-mentioned configuration of the multi-level health service. Please refer to the above-mentioned embodiment and will not be repeated here.

[0193] Accordingly, an embodiment of the present application also provides a computer-readable storage medium storing a computer program, which, when executed, can implement the various steps that can be performed by the configuration device in the above-mentioned health service method embodiment.

[0194] The embodiment of the present application also provides a terminal device, including: a memory, a processor, and a communication component; further, the terminal device also includes: a display, a power component, an audio component, and other components. The memory is used to store a computer program; the processor is coupled to the memory and is used to execute the computer program, which is used to: send a service request to a server device through the communication component to request the user's health code information, the health code information including the health code color and the user's identification information; receive the health code information and reason information corresponding to the health code color returned by the server device; and display the health code information and reason information corresponding to the health code color on the health code interface.

[0195] In an optional embodiment, the health code interface includes a complaint control corresponding to the reason information; based on this, the processor is also used to: respond to the user's triggering operation on the complaint control, send a complaint request to the server device or the health service demander to initiate a complaint regarding the reason information.

[0196] Accordingly, an embodiment of the present application also provides a computer-readable storage medium storing a computer program, which, when executed, can implement the various steps of the above-mentioned health code information display method embodiment.

[0197] above Figure 5 and Figure 6 The communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0198] above Figure 5 and Figure 6 The display in the embodiment includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensor may not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0199] above Figure 5 and Figure 6The power supply component in a device provides power to various components of the device in which the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located.

[0200] above Figure 5 and Figure 6 The audio component in the device may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), and when the device where the audio component is located is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal may be further stored in a memory or sent via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0201] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0202] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0203] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0204] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0205] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0206] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0207] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0208] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0209] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included within the scope of the claims of the present application.

Claims

1. A health service system, characterized in that: include: Configuration equipment, server equipment and terminal equipment; The configuration device is used to determine the current health service demand based on the regional attributes, time attributes and / or application scenarios corresponding to the health service; Obtain a multi-level health service that is compatible with the current health service needs and configure the multi-level health service on the server-side device; wherein the multi-level health service includes health services corresponding to multiple stages, where the multiple stages are obtained by dividing the process of generating health code information for the user, each stage is completed using an independent health service, and the health services in adjacent stages are cascaded, and the results of the health services in the previous stage are aggregated and used as input for the health services in the next stage; A server device, configured to obtain a multi-level health service dynamically configured based on health service requirements, and to invoke the multi-level health service to generate health code information for at least one user; and receiving a first service request from a first user, and returning health code information of the first user to the first user according to the first service request, wherein the at least one user includes the first user; The terminal device of the first user is used to send a first service request to the server device, and receive and display the health code information of the first user returned by the server device.

2. The system according to claim 1, wherein: The multi-level health service includes at least one data providing service and a data aggregation service cascaded after the at least one data providing service; The server-side device is specifically used to: obtain the data records of any one of the at least one user in at least one health-related dimension through the at least one data providing service; and generate the health code information of the user based on the data records of the user in at least one health-related dimension by the data aggregation service.

3. The system according to claim 2, characterized in that The configuration device is further configured to: when the data provides multiple services, configure resource isolation parameters for the multiple data services; The server device is further configured to implement resource isolation between the multiple data provision services according to the resource isolation parameters.

4. The system according to claim 3, characterized in that The configuration device is specifically used to configure a semaphore-based isolation method and its parameters for providing services for data that does not rely on third-party services, and to configure a thread pool-based isolation method and its parameters for providing services for data that relies on third-party services.

5. The system according to claim 2, wherein: The at least one data service provided includes a local built-in service and / or a custom service; when the at least one data service provided includes a custom service, the configuration device is specifically configured to: If the custom service depends on a third-party service, the server domain name of the third-party service is configured on the server-side device so that the server-side device can access the third-party service through the API; If the custom service does not rely on third-party services, the script file corresponding to the custom service is uploaded to the designated database, and the script ID of the script file in the designated database is configured on the server device for the server device to call the custom service.

6. The system according to claim 5, characterized in that The configuration device is further configured to: before configuring the custom service on the server-side device, receive a service configuration request reported by a health event occurrence party, the service configuration request including event details information; and generate a custom service according to the event details information.

7. The system according to any one of claims 1 to 6, characterized in that: The configuration device is further used to: dynamically configure other health services on the server device according to health service requirements; The server device is further configured to: receive a second service request from a second user; The other health service is called to process the second service request, and a service result corresponding to the second service request is returned to the second user; the at least one user includes the second user.

8. The system according to claim 7, characterized in that The configuration device is further used to: dynamically configure the customized pre-operation and / or customized post-operation of the other health services; Correspondingly, the server-side device is further configured to: perform pre-processing on the second service request using the custom pre-operation; And / or, using the customized post-operation to perform post-processing on the service result corresponding to the second service request.

9. A health service method, characterized in that: include: Determine current health service needs based on the geographical attributes, temporal attributes, and / or application scenarios of health services; Obtain and configure multi-level health services that are compatible with current health service needs; Invoking the multi-level health service to generate health code information for at least one user; wherein the multi-level health service includes health services corresponding to multiple stages, wherein the multiple stages are obtained by dividing the process of generating health code information for the user, each stage is completed by an independent health service, and the health services in adjacent stages are cascaded, and the results of the health services in the previous stage are aggregated and used as input for the health services in the next stage; receiving a first service request from a first user, wherein the at least one user includes the first user; Return the health code information of the first user to the first user according to the first service request.

10. The method according to claim 9, characterized in that Configure multi-level health services that are adapted to current health service needs, including: Configuring at least one data provision service adapted to the current health service demand; A data aggregation service adapted to the current health service demand is configured; wherein the data aggregation service is cascaded after the at least one data providing service.

11. The method according to claim 10, characterized in that Invoking the multi-level health service to generate health code information for at least one user includes: For any one of the at least one user, obtaining data records of the user in at least one health-related dimension through the at least one data providing service; The data aggregation service generates the user's health code information based on the user's data records in at least one health-related dimension.

12. The method according to claim 11, characterized in that The at least one data service provider includes a local built-in service and / or a custom service; In a case where the at least one data provision service includes a customized service, configuring at least one data provision service adapted to the current health service demand includes: If the custom service depends on a third-party service, configure the server domain name of the third-party service for accessing the third-party service; If the custom service does not rely on a third-party service, the script file corresponding to the custom service is uploaded to the designated database, and the script ID of the script file in the designated database is configured for calling the custom service.

13. The method according to claim 12, characterized in that The local built-in service also includes a local built-in service that relies on a third-party service and / or a local built-in service that does not rely on a third-party service; For any one of the at least one user, obtaining data records of the user in at least one health-related dimension through the at least one data provision service includes: Based on the script ID corresponding to the first service, loading the script file corresponding to the first service in the designated database to obtain data records of the user in the health-related dimension corresponding to the first service; and / or Accessing the third-party service pointed to by the server domain name based on the server domain name corresponding to the second service to obtain the data record of the user in the health-related dimension corresponding to the second service; The first service refers to a local built-in service and / or a customized service that does not rely on a third-party service; the second service refers to a local built-in service and / or a customized service that relies on a third-party service.

14. The method according to claim 13, characterized in that The third-party service includes at least one of the following: a medical inquiry service, a movement trajectory inquiry service, a residence information inquiry service, an office information inquiry service, and an associated user status inquiry service.

15. The method according to claim 12, characterized in that Before configuring the custom service on the server device, the following steps are also included: Receive a service configuration request reported by a party that causes a health event, wherein the service configuration request includes event details information; and generate a custom service according to the event details information.

16. The method according to claim 11, characterized in that The data aggregation service generates the user's health code information based on the user's data records in at least one health-related dimension, including: The data aggregation service performs aggregation judgment based on the health status judgment condition on the at least one health-related dimension and the data record of the user on the at least one health-related dimension to obtain the health status information of the user; Generate the user's health code information based on the user's health status information and the user's identification information.

17. The method according to claim 16, characterized in that Generating the user's health code information according to the user's health status information and the user's identifier, including: Determine the color of the user's health code according to the user's health status information; Generate health code information including the health code color and the user's identification information.

18. The method according to claim 17, characterized in that Returning the health code information of the first user to the first user according to the first service request includes: Parsing the first user's identification information and facial image from the first service request; Acquire the health code information of the first user from the health code information of the at least one user according to the identification information of the first user; The health code information of the first user and the facial image of the first user are combined and returned to the first user.

19. The method according to claim 17, wherein Also includes: Generate reason information corresponding to the health code color and return the reason information to the first user.

20. The method according to any one of claims 9 to 19, characterized in that: Also includes: Dynamically configure other health services based on health service needs; receiving a second service request from a second user; The other health service is called to process the second service request, and a service result corresponding to the second service request is returned to the second user.

21. The method according to claim 20, characterized in that Also includes: Dynamically configure the custom pre-operations and / or custom post-operations of the other health services; Accordingly, before calling the other health service to process the second service request, the method further includes: performing pre-processing on the second service request by using the custom pre-operation; and / or Before returning the service result corresponding to the second service request to the second user, the method further includes: performing post-processing on the service result corresponding to the second service request by using the custom post-operation.

22. The method according to claim 20, characterized in that The other health services include at least one of the following: health code information query service, health code information verification service and health status reporting service.

23. The method according to any one of claims 9 to 19, characterized in that The at least one user includes a user who is in or enters the geographical area indicated in the health service demand, or a user in the application scenario indicated in the health service demand.

24. A method for displaying health code information, characterized in that: include: Sending a service request to a server device to request the user's health code information, the health code information including the health code color and the user's identification information, wherein the server device generates the user's health code information according to any one of claims 9-23; Receive the health code information and reason information corresponding to the health code color returned by the server device; On the health code interface, the health code information and the reason information corresponding to the health code color are displayed.

25. The method according to claim 24, characterized in that The health code interface includes a complaint control corresponding to the reason information; the method further includes: In response to the user triggering the appeal control, a complaint request is sent to the server device or the health service demander to initiate an appeal based on the reason information.

26. A service configuration method, characterized in that: include: In response to the service configuration operation, a service configuration interface is displayed, wherein the service configuration interface includes a first configuration item of whether the custom service depends on a third-party service; In response to a configuration operation on the first configuration item, obtaining configuration information indicating whether the custom service depends on a third-party service; If the custom service depends on a third-party service, a second configuration item for configuring the service domain name of the third-party service is displayed; In response to the configuration operation on the second configuration item, obtaining a server domain name of the third-party service for accessing the third-party service; Determine current health service needs based on the geographical attributes, temporal attributes, and / or application scenarios of health services; Obtain multi-level health services that are adapted to current health service needs, and configure multi-level health services that are adapted to current health service needs; wherein, multi-level health services include health services corresponding to multiple stages, and multiple stages are obtained by dividing the process of generating health code information for users. Each stage is completed with an independent health service, and the health services in adjacent stages are cascaded. The results of the health services in the previous stage are aggregated and used as input for the health services in the next stage.

27. The method according to claim 26, characterized in that Also includes: If the custom service does not rely on third-party services, the script file upload control and script ID configuration items are displayed; In response to the triggering operation of the script file upload control, the script file corresponding to the custom service is uploaded to the specified database; as well as In response to the configuration operation on the script ID configuration item, the script ID of the script file in the specified database is obtained for calling the custom service.

28. The method according to claim 26 or 27, characterized in that Before configuring the custom service, it also includes: Receive a service configuration request reported by a party that causes a health event, wherein the service configuration request includes event details information; and generate a custom service according to the event details information.

29. A server device, characterized in that: include: memory, processors, and communication components; The memory is used to store computer programs; The processor, coupled to the memory, is configured to execute the computer program to: determine current health service needs based on geographical attributes, time attributes, and / or application scenarios corresponding to the health services; Obtain and configure multi-level health services that are compatible with current health service needs; Invoking the multi-level health service to generate health code information for at least one user, wherein the multi-level health service includes health services corresponding to multiple stages, wherein the multiple stages are obtained by dividing the process of generating health code information for the user, each stage is completed by an independent health service, and the health services in adjacent stages are cascaded, and the results of the health services in the previous stage are aggregated and used as input for the health services in the next stage; And receiving a first service request from a first user through a communication component, and returning the health code information of the first user to the first user according to the first service request, the at least one user includes the first user, and the multi-level health service is dynamically configured based on health service needs.

30. A configuration device, characterized in that: include: memory and processor; The memory is used to store computer programs; The processor, coupled to the memory, is configured to execute the computer program to: Determine current health service needs based on the geographical attributes, temporal attributes, and / or application scenarios of health services; Acquire a multi-level health service that is compatible with the current health service demand, and configure the multi-level health service that is compatible with the current health service demand on the server device, so that the server device generates health code information for at least one user based on the multi-level health service; Among them, multi-level health services include health services corresponding to multiple stages. Multiple stages are obtained by dividing the process of generating health code information for users. Each stage is completed by an independent health service. The health services in adjacent stages are cascaded, and the results of the health services in the previous stage are aggregated as input for the health services in the next stage.

31. The device according to claim 30, characterized in that The multi-level health service includes at least one data providing service and a data aggregation service cascaded after the at least one data providing service; the at least one data providing service includes a custom service; The processor is specifically configured to: In response to the service configuration operation, a service configuration interface is displayed, wherein the service configuration interface includes a first configuration item of whether the custom service depends on a third-party service; In response to a configuration operation on the first configuration item, obtaining configuration information indicating whether the custom service depends on a third-party service; If the custom service depends on a third-party service, a second configuration item for configuring the service domain name of the third-party service is displayed; In response to the configuration operation on the second configuration item, a server domain name of the third-party service is obtained for accessing the third-party service.

32. The device according to claim 31, characterized in that The processor is further configured to: If the custom service does not rely on third-party services, the script file upload control and script ID configuration items are displayed; In response to a triggering operation on the script file upload control, uploading the script file corresponding to the custom service to a designated database; as well as In response to the configuration operation on the script ID configuration item, the script ID of the script file in the specified database is obtained for calling the custom service.

33. The device according to claim 31 or 32, characterized in that The processor is further configured to: Before configuring the custom service on the server-side device, a service configuration request reported by a party that generates a health event is received, the service configuration request including event details information; and a custom service is generated according to the event details information.

34. A terminal device, characterized in that: include: memory, processors, and communications components; The memory is used to store computer programs; The processor, coupled to the memory, is configured to execute the computer program to: Sending a service request to a server device through the communication component to request the user's health code information, the health code information including the health code color and the user's identification information, wherein the server device generates the user's health code information according to the method of any one of claims 9-23; Receive the health code information and reason information corresponding to the health code color returned by the server device; On the health code interface, the health code information and the reason information corresponding to the health code color are displayed.

35. The terminal device according to claim 34, characterized in that The health code interface includes a complaint control corresponding to the reason information; The processor is further configured to: respond to the user's triggering operation on the complaint control, and send a complaint request to the server device or the health service demander to initiate a complaint regarding the reason information.

36. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the processor is caused to implement the steps of the method according to any one of claims 9 to 28.

37. A code information processing system, characterized in that: include: Configuration device, server device and at least one terminal device; A configuration device, configured to dynamically configure, on the server device, a multi-level status code service required to generate status code information based on status code service requirements; The server-side device is configured to obtain a multi-level status code service dynamically configured based on status code service requirements, invoke the multi-level status code service to generate status code information for at least one data object, wherein the multi-level status code service includes status code services corresponding to multiple stages, the multiple stages being obtained by dividing the process of generating status code information for the at least one data object, each stage being completed using an independent status code service, the status code services in adjacent stages being cascaded, and the results of the status code service in the previous stage being aggregated and used as input for the status code service in the next stage; and receive a first service request from a first terminal device, and return status code information of a first data object to the first terminal device according to the first service request, the first data object belonging to the at least one data object; The first terminal device is used to send a first service request to the server device, and receive and display the status code information of the first data object returned by the server device; the first terminal device belongs to the at least one terminal device.

38. The system according to claim 37, wherein: The configuration device is further configured to: dynamically configure other status code services on the server device according to status code service requirements; The server device is also used to: receive a second service request from a second terminal device, call the other status code service to process the second service request, and return a service result corresponding to the second service request to the second terminal device, where the second terminal device belongs to the at least one terminal device.

39. A code information processing method, characterized in that: include: Based on status code service requirements, dynamically configure the multi-level status code service required to generate status code information; the multi-level status code service includes status code services corresponding to multiple stages. The multiple stages are obtained by dividing the process of generating status code information for at least one data object. Each stage is completed by an independent status code service. The status code services in adjacent stages are cascaded, and the results of the status code service in the previous stage are aggregated and used as input for the status code service in the next stage. Invoking the multi-level status code service to generate status code information for at least one data object; receiving a first service request from a first terminal device, where the first service request is used to request status code information of the first data object; According to the first service request, status code information of the first data object is returned to the first terminal device, where the first data object belongs to the at least one data object.

40. A server device, characterized in that: include: memory, processors, and communication components; The memory is used to store computer programs; The processor, coupled to the memory, is configured to execute the computer program to: Obtain a multi-level status code service that is dynamically configured based on status code service requirements. The multi-level status code service includes status code services corresponding to multiple stages. The multiple stages are obtained by dividing the process of generating status code information for at least one data object. Each stage is completed by an independent status code service. The status code services in adjacent stages are cascaded, and the results of the status code service in the previous stage are aggregated and used as input for the status code service in the next stage. Invoking the multi-level status code service to generate status code information for at least one data object; receiving a first service request from a first terminal device, where the first service request is used to request status code information of the first data object; According to the first service request, status code information of the first data object is returned to the first terminal device, where the first data object belongs to the at least one data object.

Images