Blockchain-based public health service intelligent closed-loop monitoring method and system

Abstract

This invention proposes a blockchain-based intelligent closed-loop monitoring method and system for public health services. The method includes: acquiring actual performance records and performance deviation values ​​for the same service recipient and the same service item, and encapsulating them as monitoring objects. Monitoring objects of the same service recipient that meet the anomaly judgment conditions in the same service item constitute an anomaly chain. The problem intensity index of the anomaly chain is calculated, and each anomaly chain is encapsulated as a problem object, with an anomaly chain summary and controlled strength coefficient calculated to construct an on-chain problem identifier. The on-chain problem identifier, current state, problem intensity index, controlled strength coefficient, problem generation time, and anomaly chain summary are written into the blockchain ledger to form an on-chain controlled object. The target on-chain controlled object is verified based on the state update transaction information, and a closed-loop judgment value is calculated. If the closed-loop judgment value is greater than the closed-loop judgment threshold, the target on-chain controlled object is updated based on the state update transaction information, thus realizing intelligent management of public health services.

Description

Technical Field

[0001] This invention belongs to the field of health monitoring, and in particular relates to a blockchain-based intelligent closed-loop monitoring method and system for public health services. Background Technology

[0002] Public health service management is characterized by continuous tracking of recipients, cyclical fulfillment of obligations, collaborative handling by institutions, and verifiable results. However, most existing information systems are still built as single systems and single processes, resulting in the same public health service issue being expressed piecemeal across different systems, making it difficult to form a unified, continuous, and reliable management object. Taking scenarios such as childhood immunization, standardized follow-up for chronic diseases, and health management of key populations as examples, what is truly needed in actual operations is not the isolated records themselves, but whether a service recipient has fulfilled their obligations for a specific service as planned. However, existing systems often only store immunization records, follow-up records, planned task records, or management ledgers separately, lacking a mechanism to organize these records uniformly around the same service recipient and the same service. Therefore, situations such as the same problem being repeatedly alerted, consecutive abnormalities being handled piecemeal, and abnormal chains being difficult to identify are prone to occur. Therefore, how to intelligently manage public health services has become an urgent technical problem to be solved. Summary of the Invention

[0003] The purpose of this invention is to provide a blockchain-based intelligent closed-loop monitoring method and system for public health services, which enables intelligent management of public health services.

[0004] To achieve the above objectives, a blockchain-based intelligent closed-loop monitoring method for public health services is provided in a first aspect of the present invention, the method comprising: Obtain the actual performance records and performance deviation values ​​of the same service object identifier and the same service item identifier, and encapsulate the service object identifier, the service item identifier, the actual performance time and the performance deviation value into a monitoring object; put the monitoring objects of the same service object on the same service item into the same candidate sequence, and determine whether the next monitoring object and the previous monitoring object in each candidate sequence meet the preset abnormal judgment conditions. If so, the corresponding monitoring objects constitute an abnormal chain. The average deviation value of the abnormal chain is calculated based on the performance deviation value and the length of the abnormal chain. The problem intensity index of the abnormal chain is calculated based on the average deviation value and the length of the abnormal chain. The actual performance time of the last monitored object in the abnormal chain is the problem generation time. Each abnormal chain is encapsulated as a problem object. Each of the monitored objects in the problem objects is concatenated and encoded to obtain a basic data unit. A summary is calculated based on the basic data unit to obtain an anomaly chain summary. An on-chain problem identifier is constructed based on the service object identifier, the service item identifier, the problem generation time, the problem intensity index, and the anomaly chain summary. The controlled strength coefficient is calculated based on the problem intensity index, the performance deviation value, and the abnormal chain length. The on-chain problem identifier, the preset current state, the problem intensity index, the controlled strength coefficient, the problem generation time, and the abnormal chain summary are written into the blockchain ledger to form an on-chain controlled object. All the on-chain controlled objects constitute an on-chain controlled object set. Obtain status update transaction information, locate the corresponding target on-chain controlled object from the on-chain controlled object set based on the status update transaction information, verify the target on-chain controlled object based on the status update transaction information and calculate the loop closure judgment value, and update the target on-chain controlled object based on the status update transaction information if the loop closure judgment value is greater than the preset loop closure judgment threshold.

[0005] Furthermore, obtaining the actual performance records and performance deviation values ​​for the same service recipient identifier and the same service item identifier includes: Obtain the planned performance time and allowed time window range corresponding to the service item identifier, and the performance status and actual performance time corresponding to the actual performance record; The deviation is calculated based on the actual performance time, the planned performance time, the allowed time window range, and the valid performance status identifier to obtain the performance deviation value; wherein, the service object identifier, the service item identifier, the allowed time window range, the performance status, the actual performance time, and the performance deviation value are encapsulated as monitoring objects.

[0006] Further, determining whether the subsequent and preceding monitored objects in each candidate sequence meet preset anomaly judgment conditions includes: If the latter monitoring object and the former monitoring object in the candidate sequence belong to a continuous management cycle, and both the latter monitoring object and the former monitoring object are in an abnormal state, then the abnormal judgment condition is met.

[0007] Furthermore, the state update transaction information includes a processing result summary and a problem reference summary path. The step of verifying the controlled object on the target chain and calculating the loop closure judgment value based on the state update transaction information includes: Based on the problem reference summary path, the controlled object on the target chain is subjected to problem binding verification to obtain the summary binding result. Based on the processing result summary, the state condition of the controlled object on the target chain is verified to obtain the condition satisfaction ratio. The closed-loop credibility index is calculated based on the summary binding result, the condition satisfaction ratio, and the controlled strength coefficient. The closed-loop judgment value is then calculated based on the closed-loop credibility index and the problem strength index.

[0008] Further, the step of calculating the closed-loop credibility index based on the summary binding result, the condition satisfaction ratio, and the controlled strength coefficient includes: Divide the controlled intensity coefficient by the preset number and the sum of the controlled intensity coefficients to obtain the first data; The closed-loop credibility index is obtained by multiplying the summary binding result, the condition satisfaction ratio, and the first data.

[0009] Further, the step of performing issue binding verification on the controlled objects on the target chain based on the issue reference digest path to obtain the digest binding result includes: Define the anomaly chain digest corresponding to the controlled object on the target chain as the target anomaly chain digest; The path reconstruction process is performed based on the problem reference summary path to obtain the problem reference summary. The problem reference summary is then compared with the target anomaly chain summary to obtain the summary binding result.

[0010] Further, the processing result summary includes at least one processing condition summary, and the step of performing state condition verification on the controlled object on the target chain based on the processing result summary to obtain the condition satisfaction ratio includes: Define the current state of the controlled object on the target chain as the initial current state, and obtain the total number of migration rules and condition items corresponding to the initial current state to the target state; Determine whether each processing condition summary satisfies the migration rule to obtain the number of satisfied condition items. Calculate the ratio of the number of satisfied condition items to the total number of condition items to obtain the condition satisfaction ratio.

[0011] A second aspect of the invention provides a blockchain-based intelligent closed-loop monitoring system for public health services, the system comprising: The acquisition unit is used to acquire the actual performance records and performance deviation values ​​of the same service object identifier and the same service item identifier, and encapsulate the service object identifier, the service item identifier, the actual performance time and the performance deviation value into a monitoring object; put the monitoring objects of the same service object on the same service item into the same candidate sequence, and determine whether the next monitoring object and the previous monitoring object in each candidate sequence meet the preset abnormal judgment conditions. If so, the corresponding monitoring objects constitute an abnormal chain. The first calculation unit is used to calculate the average deviation value of the abnormal chain based on the performance deviation value and the abnormal chain length, and to calculate the problem intensity index of the abnormal chain based on the average deviation value and the abnormal chain length; wherein, the actual performance time of the last monitored object in the abnormal chain is the problem generation time, and each abnormal chain is encapsulated as a problem object. The encoding unit is used to concatenate and encode each of the monitored objects in the problem objects to obtain a basic data unit, perform a summary calculation based on the basic data unit to obtain an anomaly chain summary, and construct an on-chain problem identifier based on the service object identifier, the service item identifier, the problem generation time, the problem intensity index, and the anomaly chain summary. The second calculation unit is used to calculate the controlled strength coefficient based on the problem intensity index, the performance deviation value and the abnormal chain length, and write the on-chain problem identifier, the preset current state, the problem intensity index, the controlled strength coefficient, the problem generation time and the abnormal chain summary into the blockchain ledger to form an on-chain controlled object; wherein, all the on-chain controlled objects constitute an on-chain controlled object set; An update unit is used to acquire state update transaction information, locate the corresponding target on-chain controlled object from the on-chain controlled object set according to the state update transaction information, verify the target on-chain controlled object according to the state update transaction information and calculate the loop closure judgment value, and update the target on-chain controlled object according to the state update transaction information if the loop closure judgment value is greater than the preset loop closure judgment threshold.

[0012] In a third aspect of the invention, an electronic device is provided, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the method described in the first aspect above.

[0013] In a fourth aspect of the invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0014] The beneficial technical effects of the present invention are at least as follows: To address the aforementioned issues, this invention provides a blockchain-based intelligent closed-loop monitoring method and system for public health services. It constructs a continuous object evolution and state control link around the formation and handling process of public health service issues in real-world operations, enabling scattered performance records to be progressively elevated into trustworthy problem objects that can be managed in a closed loop. Its core lies in first organizing the original business records into monitoring objects with unified performance semantics based on the service recipient, service item, planned performance time, and actual performance result. This allows the system to monitor public health services beyond individual records, directly addressing the performance relationship itself. Furthermore, based on the same service recipient, the same service item, and the same abnormal evolution process, multiple monitoring objects are continuously merged to form problem objects reflecting management issues such as persistent mismanagement, persistent missed visits, and persistent waiting for vaccination. This ensures that problems are no longer present as scattered alerts but are identified and addressed as a complete abnormal chain. Subsequently, the problematic object is transformed into a controlled on-chain object, and is fixed to the blockchain environment through a unique on-chain identifier, anomaly chain summary, and state machine constraints. This ensures that subsequent state transitions always revolve around the same problematic object, thereby guaranteeing object consistency, state consistency, and evidence consistency in multi-node collaboration. Finally, during the operation of the controlled on-chain object, state transition conditions, processing result binding relationships, and loop closure conditions are uniformly incorporated into the on-chain judgment logic. This ensures that loop closure is not simply dependent on manual confirmation or process completion, but is based on verifiable problem object identity, verifiable processing results, and traceable state updates. Therefore, this invention integrates performance monitoring, problem formation, on-chain control, and loop closure judgment in public health services into a unified, continuous solution. It connects previously separate data monitoring, problem identification, and process control capabilities under the same technical path, better aligning with the cross-cycle, cross-node, highly regulated, and verification-intensive business characteristics of public health services, and achieving intelligent public health service management. Attached Figure Description

[0015] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0016] Figure 1 This is a flowchart of a blockchain-based intelligent closed-loop monitoring method for public health services provided in this application embodiment.

[0017] Figure 2 This is a schematic diagram of the structure of the blockchain-based intelligent closed-loop monitoring system for public health services provided in this application embodiment. Detailed Implementation

[0018] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0019] Please refer to Figure 1 , Figure 1 This is a flowchart of a blockchain-based intelligent closed-loop monitoring method for public health services provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0020] Step S101: Obtain the actual performance record and performance deviation value of the same service object identifier and the same service item identifier; encapsulate the service object identifier, service item identifier, actual performance time and performance deviation value into a monitoring object; place the monitoring objects of the same service object on the same service item into the same candidate sequence; determine whether the next monitoring object and the previous monitoring object in each candidate sequence meet the preset abnormal judgment conditions; if so, the corresponding monitoring objects constitute an abnormal chain. Step S102: Calculate the average deviation value of the abnormal chain based on the performance deviation value and the abnormal chain length, and calculate the problem intensity index of the abnormal chain based on the average deviation value and the abnormal chain length; wherein, the actual performance time of the last monitored object in the abnormal chain is the problem generation time, and each abnormal chain is encapsulated as a problem object. Step S103: Concatenate and encode each monitored object in the problem object to obtain a basic data unit. Perform summary calculation based on the basic data unit to obtain an anomaly chain summary. Construct on-chain problem identifiers based on service object identifier, service item identifier, problem generation time, problem intensity index and anomaly chain summary. Step S104: Calculate the controlled strength coefficient based on the problem intensity index, performance deviation value, and abnormal chain length; write the on-chain problem identifier, preset current state, problem intensity index, controlled strength coefficient, problem generation time, and abnormal chain summary into the blockchain ledger to form an on-chain controlled object; wherein, all on-chain controlled objects constitute an on-chain controlled object set. Step S105: Obtain state update transaction information, locate the corresponding target on-chain controlled object from the on-chain controlled object set based on the state update transaction information, verify the target on-chain controlled object based on the state update transaction information and calculate the loop closure judgment value, and update the target on-chain controlled object based on the state update transaction information if the loop closure judgment value is greater than the preset loop closure judgment threshold.

[0021] In step S101 of some embodiments, a set of monitoring objects is constructed around the public health service performance relationship. The system extracts records directly related to the target service item from existing business systems, and organizes the planning information and execution information scattered in different systems into monitoring objects under the same structure through unified item mapping and time window matching. After the monitoring objects are formed, subsequent steps no longer deal with independent original records such as vaccination registration forms, follow-up completion forms, and planned task forms, but with standard objects that already have performance meaning. The significance of this approach is that public health service issues are not determined by a single business record, but by "the relationship between the planned requirements and actual execution results of a certain service object on a certain service item". Therefore, this step directly fixes this relationship, providing stable input for subsequent problem classification.

[0022] The input is a set of raw business records, collected from existing systems via a pre-defined interface using a medical data middleware. The source of these records varies depending on the service item, but the field types remain consistent: service object identifiers come from the resident health record master index or the internal object index of the business system; service item identifiers come from the public health service configuration table and the business system item code mapping table; planned time information comes from the immunization schedule table, chronic disease management cycle table, key population service plan table, or planned task table; actual performance records come from execution-related business tables such as vaccination registration tables, follow-up completion tables, and treatment receipt tables; actual performance time comes from the registration time or completion time field in each business record. For example, in the scenario of children's immunization, the interface extracts the child object index, dose code, expected vaccination date, allowed vaccination time window, and vaccination completion time; in the scenario of hypertension management, the interface extracts the management object index, follow-up item code, expected follow-up date, cycle range, and follow-up completion time. All data entering this step is structured record, typically entering the middleware cache as database rows or objects returned by the interface, and then uniformly converted by the item mapping component.

[0023] First, planned items are generated based on the service recipient identifier and service item identifier. These planned items are not manually entered one by one, but are automatically expanded according to the service specification configuration. For example, in the case of childhood vaccination, the system reads the recipient's date of birth and immunization schedule configuration to obtain the number of doses a recipient should complete at a certain point in time; in the case of chronic disease management, the system reads the inclusion date and follow-up cycle configuration to obtain the follow-up items a recipient should complete within the current cycle. After the planned items are generated, the system searches the execution-type business table for actual performance records with the same service recipient identifier and the same service item identifier, and matches them according to the time window corresponding to the service item. During matching, both the item code and time boundary are used to ensure a one-to-one correspondence between the found actual performance records and the service items. Taking "MMR first dose" as an example, the system only searches for completion records of the same child under that dose code and determines whether it is a valid performance based on the vaccination window in the configuration table; taking "quarterly follow-up for hypertension" as an example, the system only searches for follow-up completion records of the same managed recipient within the current cycle and determines whether it belongs to the performance of this cycle based on the cycle boundary. After this round of matching, each "service item - execution record" relationship has a clear performance semantic.

[0024] After matching is completed, the system establishes a performance status and further generates a performance deviation value. The performance status is represented by a unified finite set, such as "fulfilled," "unfulfilled," and "delayed performance," facilitating the use of the same merging logic in subsequent steps across different business scenarios. Specifically, if a matching actual performance record for a service item is found, and the actual performance time falls within the allowed time window, the performance status is "fulfilled." If a matching actual performance record is found, but the actual performance time is outside the allowed time window, the performance status is "delayed performance." If no matching actual performance record is found, the actual performance record is empty, and the performance status is "unfulfilled." The performance deviation value expresses the degree of deviation between the planned requirements and the actual execution. It is calculated based on the actual performance time, the planned performance time, the allowed time window range, and the valid performance status identifier, yielding the performance deviation value. The formula is as follows: ; In the formula, This represents the performance deviation value, which is calculated by the performance determination component in this step based on the matching results between the service items and the actual performance records; This indicates the actual fulfillment time. When an actual fulfillment record is found, the completion time of that record is taken. When no actual fulfillment record has been found, the current monitoring time is taken. This value comes from the completion time field of the vaccination registration form, follow-up completion form, or treatment receipt form, or from the monitoring task trigger time. The planned fulfillment time is derived from the service specifications and the basic information of the recipients, such as the vaccination date in the immunization program or the follow-up date in chronic disease management. The permitted time window range for this service item is given by the public health service configuration table; This indicates a valid performance status indicator. It is set to 1 when the performance has been completed and the actual performance time falls within the allowed time window, and to 0 when the performance is not completed or delayed. This value is generated by the event matching and time window verification results. Thus, when the monitored object is in a delayed performance status... Take the actual performance time. Taking 0 corresponds to the performance deviation value. It can still be calculated normally. This expression compresses the performance relationship into a continuous value: when effective performance is achieved, the performance deviation value is zero; when effective performance has not yet been achieved, the performance deviation value increases as the deviation between the planned time point and the monitoring time point increases. In this way, objects that are also considered incomplete can be distinguished according to the degree of deviation in subsequent steps. For example, a child who was originally scheduled to complete vaccination within the allowed time window has just passed the planned date, and the generated performance deviation value is small; another child who has clearly exceeded the allowed time window and still has no vaccination record has a significantly higher performance deviation value. Furthermore, for example, a hypertensive subject who has not completed follow-up at the beginning of the cycle and one who has not completed follow-up by the end of the cycle should not receive the same treatment intensity when merging issues in subsequent steps; this difference is naturally reflected in the performance deviation value.

[0025] After calculating the performance status and performance deviation value, the system encapsulates the results into monitoring objects. Each monitoring object corresponds to a service object's performance determination for a single service item, including the service object identifier, service item identifier, allowed time window range, performance status, actual performance time, and performance deviation value. The actual performance time is determined using a uniform rule: if an actual performance record exists, the execution completion time is used; if no actual performance record exists, the current monitoring time is used. For example, in a typical vaccination scenario, a child is scheduled to receive the first dose of MMR (measles, mumps, rubella) around March 10th. If the system retrieves a vaccination record for March 12th from the vaccination registration table and confirms that the date falls within the allowed time window range, this child becomes a performed monitoring object, and the performance deviation value is set to zero. Another child has the same dose requirement, but no vaccination completion record has been found as of the current monitoring time. In this case, the system creates an unperformed monitoring object, and its performance deviation value is updated based on the distance between the current monitoring time and the planned performance time. The same process applies to hypertension follow-up: If a subject plans to complete a follow-up in early April of this quarter, and the system finds a follow-up record for this period in the follow-up completion table, then the subject is considered a fulfilled monitoring subject; if no record is found by the time the period has entered its later stages, then the subject is considered an unfulfilled monitoring subject. In this way, the heterogeneous records in the original business table are uniformly compressed into monitoring subjects with the same structure and the same judgment semantics.

[0026] This step outputs the public health service monitoring target set. . Each element in the process corresponds to a monitoring object that has completed performance assessment, including service object identifier, service item identifier, allowed time window range, performance status, actual performance time, and performance deviation value. These monitoring objects, upon entering the next step, will be merged according to the same service object, the same service item, and the same performance anomaly logic chain to form public health service problem objects. This step, through planned item generation, actual performance record matching, performance status normalization, and performance deviation value calculation, organizes the original business records in the public health service scenario into a set of monitoring objects that can directly participate in problem merging. The monitoring objects constructed in this way not only preserve the true performance relationship between service objects and service items but also compress the execution results from different systems into a unified expression framework, enabling the next step to focus on problem identification and merging around the same type of object.

[0027] Furthermore, due to the management challenges in public health service scenarios, anomalies in the same service recipient and for the same service item often occur consecutively across multiple monitoring points. For example, a hypertension patient might fail to complete follow-up visits for two consecutive quarters, or a child might remain awaiting vaccination at multiple monitoring points for the same dose. Management requires not just a few isolated alerts, but a single problem object reflecting a persistent issue. This step, based on this business characteristic, first connects the monitoring recipients into an anomaly chain, then merges the anomaly chain into a problem object, thereby elevating the performance assessment result from the previous step into a management object that can enter the closed-loop control chain.

[0028] First, classify the monitoring object set according to the service object identifier and service item identifier. The system categorizes the data, resulting in several candidate sequences. These candidate sequences have a clear public health service semantic: monitoring subjects for the same service item are placed in the same candidate sequence, while different service items form their own sequences. For example, in the case of childhood immunization programs, monitoring subjects for the same child on "Hepatitis B first dose," "Hepatitis B second dose," and "MMR first dose" will belong to three separate candidate sequences; similarly, in the case of hypertension management, multiple monitoring subjects for the same subject on "quarterly follow-up" will enter the same candidate sequence. After categorization, the system sorts the candidate sequences using the actual fulfillment time for each monitoring subject. The sorted candidate sequences retain the trajectory of the fulfillment deviation value over time, enabling the system to determine whether anomalies are continuous. Subsequently, based on the continuity of the allowed time window and the evolution of the fulfillment status, the system further segments the candidate sequences into anomaly chains: when a subsequent monitoring subject belongs to a continuous management cycle with the previous monitoring subject, and its fulfillment status still corresponds to an abnormal state, the system merges it into the same anomaly chain; where the fulfillment status is non-fulfillment or delayed fulfillment, the fulfillment status is an abnormal state. When a subsequent cycle has established stable performance and a new anomaly reappears, the system initiates the next anomaly chain from the new anomaly point. This anomaly chain corresponds to practical problems in primary public health management such as "continuous mismanagement," "continuous missed visits," and "continuous waiting for vaccination." For example, a candidate sequence has six monitoring subjects: A, B, C, D, E, and F. If A, B, and C all meet the requirements of continuous management cycle and abnormal state, then A, B, and C can form an anomaly chain. If D and C do not meet the conditions, the first anomaly chain ends at C. Subsequently, if E and D meet the requirements of continuous management cycle and both E and D are in an abnormal state, then D and E can form a second anomaly chain; if D is not in an abnormal state, and only E is in an abnormal state, then E alone serves as the starting point of a new anomaly chain.

[0029] It should be noted that a continuous management cycle refers to a period in which the planned performance time or planned time window of the next monitored object is immediately following the cycle of the previous monitored object according to the configuration rules of the service item, without any new item switching or cycle break. In other words, the two monitored objects belong to adjacent management cycles under the same service item.

[0030] In step S102 of some embodiments, after the anomaly chain is formed, the system aggregates the performance deviation values ​​within the anomaly chain to generate a problem intensity index. The calculation approach used here is derived from two classic mathematical constructs: one is the arithmetic mean, used to characterize the overall deviation of a set of values; the other is the logarithmic growth function, used to reflect the cumulative effect of continuity as the sequence length increases, while maintaining smooth growth and avoiding excessive amplification of values ​​when the chain length is too long. Based on these two constructs, this step first starts from the performance deviation value sequence and defines the average deviation value of the anomaly chain as: ; In the formula, The average deviation of the outlier chain is derived from the arithmetic mean formula in mathematics. Indicates the first in the exception chain Performance deviation values ​​of each monitored object; The length of the anomaly chain represents the number of monitored objects in that chain. This is due to the... (The sentence is incomplete and requires more context to translate accurately.) A unified standard has already been adopted to express the degree of deviation from performance, therefore, here... After averaging, Maintaining the same scale, it can be directly used as the basis for the overall anomaly degree of the anomaly chain. This average deviation addresses the question of "how much the overall deviation of the same anomaly chain is across multiple monitoring points." For example, if three consecutive monitoring points show performance deviation values ​​of 0.20, 0.75, and 1.10 respectively, substituting these values ​​into the above formula yields... This indicates that the entire abnormal chain has experienced a moderate to high level of performance deviation.

[0031] After obtaining the average deviation value, the system introduces a continuity correction term to express the management urgency caused by repeated anomalies in the same service item across multiple consecutive periods. This correction term is derived from the natural logarithm function. This is a classic form of problem intensity index, characterized by a significant increase when the input is small and a gradual flattening out as the input increases. It is suitable for depicting the business pattern that "the more consecutive anomalies, the more serious the problem, but the growth should remain stable." Based on this, this step defines the problem intensity index as: ; in, The index representing the severity of the problem is the average deviation value. With the length of the abnormal chain Calculated together; The average deviation value represents the overall degree of deviation of each monitored object within the anomaly chain; The number of monitored objects within the same anomaly chain is derived from the anomaly chain segmentation results. This formula is not a simple superposition of two unrelated quantities, but rather a combined expression of two characteristics in the public health service scenario: "deviation magnitude" and "duration length." It is responsible for describing the complexity of the exception itself. This describes how long the anomaly lasted. Continuing with the example of the aforementioned three consecutive anomalies, we have already obtained... Meanwhile, the length of the exception chain Then the continuity correction term is The final problem intensity index is If another object exhibits only a minor anomaly once in the current period, with a performance deviation value of 0.20, and constitutes only one monitoring object, then... , ,at this time Compared to the latter, the former is significantly higher, allowing the system to naturally distinguish between "continuous mismanagement problems" and "single minor anomaly problems." This calculation process follows the original mathematical sources of the average formula and logarithmic function, and also incorporates chain length corrections to address the management characteristics of continuous anomalies in public health services, thus forming a problem intensity expression adapted to the scenario of this solution.

[0032] In terms of problem intensity index After the calculation is completed, the system encapsulates each chain of exceptions into a problem object and generates a set of public health service problem objects. .gather Each issue object in the table corresponds to an exception chain of a service object on a service item, including the service object identifier, service item identifier, set of associated monitoring objects, and issue intensity index. And the issue generation time. The issue generation time is taken as the actual fulfillment time of the latest monitored object in the anomaly chain, so that the resulting issue object always corresponds to the latest management status. The associated monitored object set directly retains the monitored objects that have been sorted in the anomaly chain, so that subsequent steps can convert the issue object into a controlled object on the chain along this fulfillment evolution chain. Taking the child vaccination scenario as an example, if a child has non-fulfilled monitoring objects at multiple monitoring time points for the "MMR first dose" issue, this step will connect these monitoring objects into the same anomaly chain and generate a vaccination-type issue object accordingly; taking the hypertension management scenario as an example, if an object fails to complete follow-up in two consecutive cycles, the two monitoring objects formed will be sorted, segmented and aggregated into a follow-up-type issue object in this step, with the issue intensity index... It increases with continuity. This is how it is obtained. It is no longer a simple collection of individual monitoring objects, but a unified management unit formed around the same service object, the same service item, and the same continuous chain of anomalies.

[0033] The entire consolidation process is closely linked to the steps described above. These steps organize the original performance records into monitoring objects and generate performance deviation values. This step fully utilizes the monitoring objects and their components. These are then categorized, sorted, segmented, and aggregated to elevate them to problem objects. In this way, each monitored object participates in the construction of the anomaly chain in this step, and the performance deviation value... Then through the average deviation value and problem intensity index Proceed to the problem object calculation. After this process, ongoing performance anomalies in public health service scenarios are grouped into problem objects with continuity and integrity. The next step can directly use this problem object set... As input, each problem object is assigned an on-chain problem identifier and loaded into a preset state machine framework, completing the transition from "problem identification" to "blockchain closed-loop control".

[0034] In step S103 of some embodiments, the problem object set output by the above steps is... Based on this, the problem objects that have already undergone anomaly chain merging are further transformed into on-chain controlled objects that can be uniformly constrained and circulated within the consortium blockchain. (Set) Each problem object already includes a service object identifier, a service item identifier, a set of associated monitoring objects, and a problem intensity index. And the time when the problem was generated, where the set of associated monitoring objects is directly derived from the set of monitoring objects. And retained the performance deviation value. And the actual performance time. Therefore, this step no longer accesses the original business system during processing, but relies entirely on... Using the existing information, the "problem object" is mapped to the "on-chain controlled object", giving it a unique identifier, a verifiable source, and executable state constraints.

[0035] In its implementation, the system first performs an ordered reconstruction of the set of associated monitoring objects within each problem object. This process sorts the monitoring objects according to their actual performance time field, resulting in a performance deviation sequence strictly arranged by time. ,in This is the deviation value from the contract. This represents the number of monitored objects associated with the problematic object. This sequence fully describes the abnormal evolution process of a specific service object for a specific service item. Subsequently, the system concatenates and encodes the key fields (service object identifier, service item identifier, actual performance time, performance status, and performance deviation value) of each monitored object in the sequence to form a set of basic data units. Each All data originates from field combinations of specific monitored objects and can be directly obtained and encoded through data middleware.

[0036] Based on this, the system constructs an anomaly chain digest. This digest is constructed using the classic Merkle tree structure in blockchain technology, whose original idea is to compress multiple data units into a root digest through pairwise hash combinations. In this step, the modification to this structure is that leaf nodes no longer represent ordinary transaction records, but rather sequences of monitored objects within the same problematic object. The specific calculation method is as follows: ; in, This represents the summary of the anomaly chain, calculated by the Merkle tree building module within the blockchain node. Indicates the first Each monitored object is coded into a data unit; is the length of the anomaly chain, representing the number of monitored objects in this problem object. This formula is based on the Merkle tree algorithm used in computer science for data consistency verification. This step redefines the input structure specifically for expressing anomaly chains in public health service problems. Because each All of them come from the same set of monitored objects related to the same problem, therefore the generated This uniquely corresponds to the complete evolutionary path of this problem object. In actual calculations, for example, if a problem object contains three monitoring objects, their encoding results are as follows: , , The system first calculates Get the intermediate node, then connect it with... Combine to obtain the final exception chain summary This compresses three records into a single verifiable value.

[0037] After obtaining the exception chain summary Next, the system continues to construct on-chain issue identifiers. These identifiers are obtained by combining and encoding the core fields of the issue object and then performing a digest calculation. The fields involved in the combination include the service object identifier, service item identifier, issue generation time, and issue severity index. and exception chain summary After encoding, a fixed-length identifier is generated using a hash function built into the blockchain node, ensuring consistent results when different nodes process the same problem object. This generates a unique on-chain problem identifier that also reflects the key attributes of the problem object.

[0038] After generating the on-chain issue identifier, the system loads the issue object into a predefined state machine framework. This state machine framework originates from the closed-loop management process of public health services, and its state set and transition rules were already defined according to service specifications during the system deployment phase. During loading, this step uses the on-chain issue identifier as the key, and loads the current state (initially "discovered") and issue severity index... Exception chain summary The time of the problem's occurrence is also written to the on-chain ledger. The writing process is completed through the chaincode execution module of the blockchain node. When the chaincode is executed, it calls the underlying ledger interface, writes the above fields as transaction content, and synchronizes them among the nodes through the consensus mechanism.

[0039] To further enhance the ability of on-chain controlled objects to make judgments during subsequent state transitions, this step focuses on the problem strength index. Based on this, a sequence fluctuation term is introduced to construct a controlled strength coefficient. This construction originates from the mathematical concept of total variation of a discrete sequence, whose original form is used to measure the magnitude of change of a sequence between adjacent points. In this step, this concept is adapted to describe the trend of performance deviation over time. Specifically, it is expressed as: ; in, This represents the controlled strength coefficient, which is calculated in this step when the controlled object is loaded onto the chain. The index representing the severity of the problem is derived from the calculation of the average deviation and duration of the anomaly chain; Indicates the first Performance deviation values ​​of each monitored object; This indicates the number of monitored objects in the anomaly chain. The formula consists of two parts: the first part... The first part indicates the overall severity of the problem, and the second part is the normalized cumulative value of the difference between adjacent deviations, used to characterize whether the anomaly shows a continuous worsening trend. When =1, there are no adjacent deviation pairs in the summation term, and the second part is treated as an empty sum, which is 0. ;when When the value is greater than 1, the second part increases with the change of adjacent deviations. For example, when the deviation sequence of a problem object is... When, the sum of adjacent differences is If the length of the exception chain is The second part is ,final When the deviation sequence is When, the sum of adjacent differences is The second part is ,final Closer This design enables controlled objects on the chain to distinguish between "repeated problems" and "stable existence problems" during subsequent state transitions.

[0040] After completing the above calculations, the system will display the on-chain problem identifier, current state, and problem strength index. Controlled intensity coefficient Problem generation time and exception chain summary This is written as a complete record into the blockchain ledger, forming an on-chain controlled object. Multiple problematic objects, after the above processing, form a set of on-chain controlled objects. .gather Each element in the chain can be uniquely accessed via an on-chain issue identifier, and its internal state can be updated via chaincode, maintaining consistency across nodes. This is due to the anomaly chain digest. With controlled strength coefficient Since the issue is already embedded in a controlled on-chain object, subsequent steps, such as state verification and loop closure determination, can directly utilize this information to assess the authenticity and processing priority of the problem. Through this process, the problem object is further transformed into a controlled on-chain object, giving it not only a structured representation but also a unified identity and verifiability within the blockchain environment. Performance Deviation Value After aggregation Then, in this step, it is combined with sequence change information to generate Simultaneously, it is compressed into a summary using a Merkle structure. This creates a complete object on the chain that can both express the source of the problem and support subsequent control. This continuous transformation from the monitored object to the problem object and then to the controlled object on the chain enables public health service problems to be consistently identified and handled in a multi-node environment.

[0041] In step S105 of some embodiments, the on-chain controlled object set To address the fundamentals, state updates, verification comparisons, and loop closure checks are performed on each controlled object within the chain. (Set) Each on-chain controlled object already contains an on-chain problem identifier, current state, and problem strength index. Controlled intensity coefficient Problem generation time and exception chain summary These fields are derived from the continuous processing results of the performance deviation value, the anomaly chain, and the problem object in the preceding steps. Therefore, this step does not deal with the original business records, but rather with the problem object that has already been structured, summarized, and loaded onto the chain. In actual operation, the responsible nodes include grassroots service nodes, family doctor teams, vaccination clinic nodes, or management nodes. After completing a certain action, the responsible node will generate a structured processing record of the action result through the business system interface, and then submit it as a status update transaction through the chaincode interface. The status update transaction information includes the on-chain problem identifier, target status, processing result summary, and problem reference summary path. The problem reference summary path is generated by the responsible node based on the set of associated monitoring objects corresponding to the current problem object, and is used to bind this transaction to the target on-chain controlled object. After receiving the status update transaction, the system first retrieves the on-chain controlled object set according to the on-chain problem identifier. The corresponding on-chain controlled object is located and defined as the target on-chain controlled object. Then, problem binding verification and state condition verification are handled separately. Specifically, the anomaly chain digest corresponding to the target on-chain controlled object is defined as the target anomaly chain digest, and the current state corresponding to the target on-chain controlled object is defined as the initial current state.

[0042] The issue binding verification is based on the Merkle proof concept commonly used in blockchain and distributed storage. Its original approach is: given a leaf node and its proof path, the root digest can be reconstructed without expanding all the original data and compared with the root digest stored in the ledger. This step applies this classic proof method to the public health service issue processing stage. Specifically, the responsible node submits the issue reference digest path referenced by the current transaction. The chaincode module reconstructs the path according to a fixed hash concatenation order to obtain the issue reference digest, which is then compared with the target abnormal chain digest. If they match, the digest binding result is achieved. The value is 1; if the two are inconsistent, the summary binding result is... The value is 0.

[0043] The process involves obtaining the migration rules and the total number of condition items corresponding to the transition from the initial current state to the target state. Each condition summary is then checked to ensure it meets the migration rule, resulting in the number of satisfied condition items. These processing conditions are derived from predefined public health service closed-loop rules. For example, when a vaccination-related issue moves from "Processing" to "Pending Verification," a vaccination completion summary and a responsible node signature record are required; similarly, when a chronic disease follow-up issue moves from "Processing" to "Pending Verification," a follow-up completion summary and a result receipt summary are required. The ratio of the number of satisfied condition items to the total number of condition items is calculated to obtain the condition satisfaction ratio. .so, The process summary is used to confirm that the transaction is bound to the current problem object itself, and to confirm whether the evidence required for this state transition is complete. Specifically, if the initial current state is "Processing" and the target state is "Pending Verification", the transition from "Processing" to "Pending Verification" uses the total number of transition rules and condition items corresponding to this specific state transition path "Processing → Pending Verification".

[0044] Based on the above, the system calculates a closed-loop credibility index. This index is constructed using a gated weighting approach: first, the summary binding result is used to control whether the current transaction can enter the credibility scoring; then, the controlled strength coefficient is used to adjust the contribution of the rule fulfillment degree to the credibility. Based on this, the system writes the closed-loop credibility index as follows: ; In the formula, This represents the closed-loop credibility index, which is calculated by this step after receiving the status update transaction. This indicates the summary binding result. The value is 1 when the summary path of the issue submitted by the responsible node is consistent with the target anomaly chain summary after being reconstructed by the Merkle path, and 0 when they are inconsistent. The condition satisfaction ratio is obtained by dividing the number of conditions satisfied in this state transition by the total number of conditions required by the state transition path. Its value is calculated by the state machine rule checking module. This represents the controlled strength coefficient. In this expression, Responsible for strongly binding the current transaction with the controlled object on the target chain; the degree of rule satisfaction is only determined when the binding is successful. Only then will it proceed to credibility calculation; It is a bounded adjustment term generated by the controlled intensity coefficient, whose value is always between 0 and 1, and is used to introduce the persistence and volatility of the problem into the closed-loop judgment.

[0045] After obtaining the closed-loop credibility index Then, the system continues to calculate the final closed-loop judgment value by combining the problem intensity index P. The method used here is based on the classic ratio-based normalization method, whose original purpose was to make a score comparable under different intensity backgrounds. In this step, the modification to this method is to use the problem intensity index... As part of the normalization denominator, this means that more complex problem objects require higher credibility support when entering a closed-loop state. The calculation method is as follows: ; in, Indicates the closed-loop determination value; As a closed-loop credibility indicator; This represents a problem intensity index. The logical relationship of this formula is: We assess whether the current state update transaction is credible and meets the state transition conditions. To measure "the overall strength of this problem itself on the historical anomaly chain," the two factors, when combined, This indicates whether the update is sufficient to support a closed loop for the current problem strength. The state machine presets a closed loop determination threshold for each type of state transition. For example, a closed loop determination threshold can be set for the transition from "pending verification" to "closed loop." When the value exceeds the closed-loop determination threshold, the chaincode module performs a state update and writes the target state, state update time, and processing result summary into the blockchain ledger; when... If the closed-loop judgment threshold is not reached, the system maintains its current state and records the calculation result of this failure in the on-chain trace so that evidence can be supplemented for subsequent processing.

[0046] To illustrate the calculation process, an example of calculating a type of vaccination problem is given below. Let the problem strength index of a certain child vaccination problem be denoted as . The controlled strength coefficient obtained by further calculation is The current responsible node submits a state update transaction generated by the inoculation system, which includes an issue reference digest path and an inoculation completion record digest. The chaincode module reconstructs an issue reference digest based on the issue reference digest path, and this reconstructed issue reference digest matches the target anomalous chain digest. The target status has changed from "Pending Verification" to "Closed Loop," corresponding to a total of 4 conditions. Currently, 3 conditions have been met. Therefore... .have ,then . If the loop closure threshold for this type of issue in the "Pending Verification" to "Closed Loop" phase is set to 0.18, then the current state update meets the loop closure condition, and the system updates the current state of the controlled object on the chain to "Closed Loop"; if the threshold is set to 0.20, the system maintains the "Pending Verification" state and prompts for further verification records. hour, and ;when hour, and Thus, both the summary binding result and the degree of rule satisfaction directly affect whether the closed loop is valid.

[0047] Once the state update is accepted by the chaincode module, the system writes the on-chain issue identifier, the updated current state, the processing summary involved in this judgment, the migration time, and the closed-loop judgment value into the blockchain ledger, forming a new state trajectory record. After continuous monitoring of multiple on-chain controlled objects through this step, a closed-loop monitoring result set for public health services is ultimately formed. .gather Each element in the result set corresponds to an on-chain issue identifier and its current final state and complete trajectory, including the final state, state transition records, transition time series, and corresponding processing summary index. Since these results are directly derived from on-chain ledger records, participating nodes can maintain a consistent understanding of the same issue object. For vaccination-related issues, the objects in the result set can be represented as "closed loop" with trajectories indicating completed vaccination and verified results; for chronic disease follow-up issues, the objects in the result set can be represented as "processing" or "pending verification," with corresponding supplementary visit records and verification trajectories.

[0048] Steps S101 to S105 of this embodiment involve obtaining the actual performance records and performance deviation values ​​for the same service object identifier and the same service item identifier, and encapsulating the service object identifier, service item identifier, actual performance time, and performance deviation value into a monitoring object. Monitoring objects for the same service object on the same service item are placed in the same candidate sequence. It is determined whether the subsequent monitoring object and the preceding monitoring object in each candidate sequence meet preset anomaly judgment conditions. If so, the corresponding monitoring objects constitute an anomaly chain. The average deviation value of the anomaly chain is calculated based on the performance deviation value and the length of the anomaly chain. The problem intensity index of the anomaly chain is then calculated based on the average deviation value and the length of the anomaly chain. The actual performance time of the last monitoring object in the anomaly chain is the problem generation time. Each anomaly chain is encapsulated as a problem object. Each monitoring object in the problem object is concatenated and encoded to obtain a basic data unit. A summary is calculated based on the basic data unit to obtain an anomaly chain summary. An on-chain problem identifier is constructed based on the service object identifier, service item identifier, problem generation time, problem intensity index, and anomaly chain summary. The controlled strength coefficient is calculated based on the problem intensity index, performance deviation value, and abnormal chain length. The on-chain problem identifier, preset current state, problem intensity index, controlled strength coefficient, problem generation time, and abnormal chain summary are written into the blockchain ledger to form on-chain controlled objects. All on-chain controlled objects constitute an on-chain controlled object set. Status update transaction information is obtained, and the corresponding target on-chain controlled object is located from the on-chain controlled object set based on this information. The target on-chain controlled object is then verified based on the status update transaction information, and a loop closure judgment value is calculated. If the loop closure judgment value is greater than a preset loop closure judgment threshold, the target on-chain controlled object is updated according to the status update transaction information, thus achieving intelligent public health service management.

[0049] Please see Figure 2 This application also provides a blockchain-based intelligent closed-loop monitoring system for public health services, which can implement the above-mentioned blockchain-based intelligent closed-loop monitoring method for public health services. The system includes: The acquisition unit 201 is used to acquire the actual performance records and performance deviation values ​​of the same service object identifier and the same service item identifier, and encapsulate the service object identifier, service item identifier, actual performance time and performance deviation value into monitoring objects; put the monitoring objects of the same service object on the same service item into the same candidate sequence, and determine whether the next monitoring object and the previous monitoring object in each candidate sequence meet the preset abnormal judgment conditions. If so, the corresponding monitoring objects constitute an abnormal chain. The first calculation unit 202 is used to calculate the average deviation value of the abnormal chain based on the performance deviation value and the abnormal chain length, and to calculate the problem intensity index of the abnormal chain based on the average deviation value and the abnormal chain length; wherein, the actual performance time of the last monitored object in the abnormal chain is the problem generation time, and each abnormal chain is encapsulated as a problem object. Encoding unit 203 is used to concatenate and encode each monitored object in the problem object to obtain a basic data unit, perform summary calculation based on the basic data unit to obtain an anomaly chain summary, and construct on-chain problem identifiers based on service object identifiers, service item identifiers, problem generation time, problem intensity indicators and anomaly chain summaries. The second calculation unit 204 is used to calculate the controlled strength coefficient based on the problem intensity index, the performance deviation value and the abnormal chain length, and write the on-chain problem identifier, the preset current state, the problem intensity index, the controlled strength coefficient, the problem generation time and the abnormal chain summary into the blockchain ledger to form an on-chain controlled object; wherein, all on-chain controlled objects constitute an on-chain controlled object set; The update unit 205 is used to obtain state update transaction information, locate the corresponding target on-chain controlled object from the on-chain controlled object set according to the state update transaction information, verify the target on-chain controlled object according to the state update transaction information and calculate the closed loop judgment value. If the closed loop judgment value is greater than the preset closed loop judgment threshold, the target on-chain controlled object is updated according to the state update transaction information.

[0050] The specific implementation of this blockchain-based intelligent closed-loop monitoring system for public health services is basically the same as the specific implementation of the blockchain-based intelligent closed-loop monitoring method for public health services, and will not be repeated here.

[0051] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A blockchain-based intelligent closed-loop monitoring method for public health services, characterized in that, The method includes: Obtain the actual performance records and performance deviation values ​​of the same service object identifier and the same service item identifier, and encapsulate the service object identifier, the service item identifier, the actual performance time and the performance deviation value into a monitoring object; put the monitoring objects of the same service object on the same service item into the same candidate sequence, and determine whether the next monitoring object and the previous monitoring object in each candidate sequence meet the preset abnormal judgment conditions. If so, the corresponding monitoring objects constitute an abnormal chain. The average deviation value of the abnormal chain is calculated based on the performance deviation value and the length of the abnormal chain. The problem intensity index of the abnormal chain is calculated based on the average deviation value and the length of the abnormal chain. The actual performance time of the last monitored object in the abnormal chain is the problem generation time. Each abnormal chain is encapsulated as a problem object. Each of the monitored objects in the problem objects is concatenated and encoded to obtain a basic data unit. A summary is calculated based on the basic data unit to obtain an anomaly chain summary. An on-chain problem identifier is constructed based on the service object identifier, the service item identifier, the problem generation time, the problem intensity index, and the anomaly chain summary. The controlled strength coefficient is calculated based on the problem intensity index, the performance deviation value, and the abnormal chain length. The on-chain problem identifier, the preset current state, the problem intensity index, the controlled strength coefficient, the problem generation time, and the abnormal chain summary are written into the blockchain ledger to form an on-chain controlled object. All the on-chain controlled objects constitute an on-chain controlled object set. Obtain status update transaction information, locate the corresponding target on-chain controlled object from the on-chain controlled object set based on the status update transaction information, verify the target on-chain controlled object based on the status update transaction information and calculate the loop closure judgment value, and update the target on-chain controlled object based on the status update transaction information if the loop closure judgment value is greater than the preset loop closure judgment threshold.

2. The blockchain-based intelligent closed-loop monitoring method for public health services according to claim 1, characterized in that, The acquisition of actual performance records and performance deviation values ​​for the same service recipient identifier and the same service item identifier includes: Obtain the planned performance time and allowed time window range corresponding to the service item identifier, and the performance status and actual performance time corresponding to the actual performance record; The deviation is calculated based on the actual performance time, the planned performance time, the allowed time window range, and the valid performance status identifier to obtain the performance deviation value; wherein, the service object identifier, the service item identifier, the allowed time window range, the performance status, the actual performance time, and the performance deviation value are encapsulated as monitoring objects.

3. The blockchain-based intelligent closed-loop monitoring method for public health services according to claim 1, characterized in that, Determining whether the subsequent and preceding monitored objects in each candidate sequence meet preset anomaly judgment conditions includes: If the latter monitoring object and the former monitoring object in the candidate sequence belong to a continuous management cycle, and both the latter monitoring object and the former monitoring object are in an abnormal state, then the abnormal judgment condition is met.

4. The blockchain-based intelligent closed-loop monitoring method for public health services according to claim 1, characterized in that, The state update transaction information includes a processing result summary and a problem reference summary path. The step of verifying the controlled object on the target chain and calculating the loop closure judgment value based on the state update transaction information includes: Based on the problem reference summary path, the controlled object on the target chain is subjected to problem binding verification to obtain the summary binding result. Based on the processing result summary, the state condition of the controlled object on the target chain is verified to obtain the condition satisfaction ratio. The closed-loop credibility index is calculated based on the summary binding result, the condition satisfaction ratio, and the controlled strength coefficient. The closed-loop judgment value is then calculated based on the closed-loop credibility index and the problem strength index.

5. The blockchain-based intelligent closed-loop monitoring method for public health services according to claim 4, characterized in that, The step of calculating the closed-loop credibility index based on the summary binding result, the condition satisfaction ratio, and the controlled strength coefficient includes: Divide the controlled intensity coefficient by the preset number and the sum of the controlled intensity coefficients to obtain the first data; The closed-loop credibility index is obtained by multiplying the summary binding result, the condition satisfaction ratio, and the first data.

6. The blockchain-based intelligent closed-loop monitoring method for public health services according to claim 4, characterized in that, The step of performing issue binding verification on the controlled objects on the target chain based on the issue reference digest path to obtain the digest binding result includes: Define the anomaly chain digest corresponding to the controlled object on the target chain as the target anomaly chain digest; The path reconstruction process is performed based on the problem reference summary path to obtain the problem reference summary. The problem reference summary is then compared with the target anomaly chain summary to obtain the summary binding result.

7. The blockchain-based intelligent closed-loop monitoring method for public health services according to claim 4, characterized in that, The state update transaction information also includes the target state, and the processing result summary includes at least one processing condition summary. The step of performing state condition verification on the controlled object on the target chain based on the processing result summary to obtain the condition satisfaction ratio includes: Define the current state of the controlled object on the target chain as the initial current state, and obtain the total number of migration rules and condition items corresponding to the initial current state to the target state; Determine whether each processing condition summary satisfies the migration rule to obtain the number of satisfied condition items. Calculate the ratio of the number of satisfied condition items to the total number of condition items to obtain the condition satisfaction ratio.

8. A blockchain-based intelligent closed-loop monitoring system for public health services, characterized in that: The system includes: The acquisition unit is used to acquire the actual performance records and performance deviation values ​​of the same service object identifier and the same service item identifier, and encapsulate the service object identifier, the service item identifier, the actual performance time and the performance deviation value into a monitoring object; put the monitoring objects of the same service object on the same service item into the same candidate sequence, and determine whether the next monitoring object and the previous monitoring object in each candidate sequence meet the preset abnormal judgment conditions. If so, the corresponding monitoring objects constitute an abnormal chain. The first calculation unit is used to calculate the average deviation value of the abnormal chain based on the performance deviation value and the abnormal chain length, and to calculate the problem intensity index of the abnormal chain based on the average deviation value and the abnormal chain length; wherein, the actual performance time of the last monitored object in the abnormal chain is the problem generation time, and each abnormal chain is encapsulated as a problem object. The encoding unit is used to concatenate and encode each of the monitored objects in the problem objects to obtain a basic data unit, perform a summary calculation based on the basic data unit to obtain an anomaly chain summary, and construct an on-chain problem identifier based on the service object identifier, the service item identifier, the problem generation time, the problem intensity index, and the anomaly chain summary. The second calculation unit is used to calculate the controlled strength coefficient based on the problem intensity index, the performance deviation value and the abnormal chain length, and write the on-chain problem identifier, the preset current state, the problem intensity index, the controlled strength coefficient, the problem generation time and the abnormal chain summary into the blockchain ledger to form an on-chain controlled object; wherein, all the on-chain controlled objects constitute an on-chain controlled object set; An update unit is used to acquire state update transaction information, locate the corresponding target on-chain controlled object from the on-chain controlled object set according to the state update transaction information, verify the target on-chain controlled object according to the state update transaction information and calculate the loop closure judgment value, and update the target on-chain controlled object according to the state update transaction information if the loop closure judgment value is greater than the preset loop closure judgment threshold.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the blockchain-based intelligent closed-loop monitoring method for public health services as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the blockchain-based intelligent closed-loop monitoring method for public health services as described in any one of claims 1 to 7.

Images