Healthcare supervision data processing method and system

Abstract

The application provides a medical insurance supervision data processing method and system, and belongs to the technical field of information management. A central dispatcher receives a task request, performs version upgrade chain processing on a rule identifier set, merges rule groups by taking rule four-dimensional business grouping knowledge as a grouping key, and enables rules in the same group to share materialized data sets. Task parameter groups are solidified into temporary tables and four intermediate tables are generated, the number of rows is counted to inversely deduce the number of external table buckets. Each rule group is written into a distributed set as a task unit, and the total number is written into an atomic counter; a sharding executor concurrently consumes through SPOP, and each consumption is decreased by DECR. The last finisher triggers the end. The sharding executor dynamically generates a time truncation function and replaces a SQL template placeholder, creates an external table to load results to form a shared data set. Multidimensional indicators are counted at the end, and a six-dimensional aggregation storage rule violation judgment result is provided to the risk control center for supervision drilling analysis.

Description

Technical Field

[0001] This invention relates to the field of information management technology, and more specifically, to a method and system for processing medical insurance regulatory data. Background Technology

[0002] In the field of medical insurance regulatory data analysis, a rule-by-rule full scan approach is typically used to determine violations in medical records, meaning each rule executes a materialized query independently. This rule-by-rule full scan leads to redundant computations, with job time increasing linearly with the number of rules. Scheduling strategies are rigid and lack business awareness, relying on static definitions of directed acyclic graphs or allocation based solely on general resource metrics like CPU / memory. This fails to identify which rules can share the same materialized dataset, resulting in either wasteful global serial execution or blind parallelism causing concurrent write conflicts to the same intermediate table. Bucketing and parallelism configurations are static and lack adaptability. Rule version management and timeliness guarantees are insufficient, with tasks directly using the rule identifiers bound at creation time.

[0003] In existing technologies, such as Chinese patent application CN119806771A, a parallel task scheduling method based on dynamic node load and task correlation measurement is disclosed. This method combines a global scheduler and a local scheduler to achieve parallelism between samples and between models within a sample. It optimizes task allocation and model execution order through techniques such as computing resource virtualization, GPU virtualization reuse, and task prediction models. However, this type of method focuses on the dynamic allocation of general computing resources and task sorting optimization, failing to identify data dependencies and sharing relationships between rules at the business logic level. Therefore, it still cannot solve the performance bottleneck problem caused by repetitive materialized computation in rule engine scenarios. Summary of the Invention

[0004] In view of the deficiencies in the existing technology, the purpose of this invention is to provide a method and system for processing medical insurance supervision data.

[0005] According to one aspect of the present invention, a method for processing medical insurance regulatory data includes: Step S1: The central scheduler receives a regulatory task request; each regulatory task request contains a set of rule identifiers and a group of task parameters; Step S2: The central scheduler performs version upgrade chain processing on the rule identifier set; Step S3: The central scheduler reads the four-dimensional business grouping knowledge of each rule in the processed rule identifier set, uses the combination of four-dimensional values ​​as the grouping key, and merges rules with the same value combination into the same rule group, so that the rules in the same rule group share the same materialized dataset. Step S4: The central scheduler first solidifies the task parameter group into a temporary filtering table; based on the temporary filtering table, it generates four intermediate tables for consultation, prescription, diagnosis, and surgery. Then, it counts the number of data rows in the consultation intermediate table, estimates the data volume based on the number of data rows and the preset single-row byte constant, and reverses the number of buckets in the external table based on the data volume and the single-bucket capacity threshold. Step S5: The central scheduler writes each rule group as a task unit into the distributed set and writes the total number of rule groups into the atomic counter; multiple shard executors concurrently compete to consume task units through the pop operation of the distributed set. Each time a task unit is consumed, the atomic counter is atomically decremented. The last shard executor to complete consumption triggers a unified cleanup operation based on the decremented value of the atomic counter. Step S6: For the task units it consumes, the shard executor dynamically generates the time truncation function and the placeholder replacement result of the structured query statement according to the business group type, and obtains the materialized structured query statement; and creates an external table according to the number of buckets in the external table, loads the execution result of the materialized structured query statement into the external table, and forms the shared dataset corresponding to the rule group. Step S7: When the atomic counter decreases to zero, the last completed sharding executor triggers the calculation of statistical analysis indicators and sends a commissioned analysis notification carrying a list of rule groups and task identifiers to the risk control center. The risk control center performs violation judgment based on the shared dataset of each rule group. The judgment results are aggregated and stored according to six dimensions: province, unified planning area, rule, institution, insured person, and medical treatment, for the regulatory workbench to query and drill down for analysis. Among them, the statistical analysis indicators include at least the number of administrative divisions, the number of detected persons, the number of detected persons, the amount of suspicious amount, and the number of detected rules.

[0006] Preferably, in step S1, the task parameter group includes at least one of the following: administrative division, medical institution level, medical category, time window, and treatment cost range; the supervision task request is manually created by the person in charge through the supervision workbench, or automatically generated by the periodic task triggered on time by the daily / monthly plan; the central scheduler calculates the data time window and parses the task parameter group accordingly for subsequent filtering and time window calculation.

[0007] Preferably, step S2 specifically includes: Remove rule identifiers that are in a deactivated state, and upgrade rule identifiers whose rule versions are lower than the latest effective version to rule identifiers that point to the latest effective version based on the superior source rule identifier and the original source rule identifier, thus obtaining the processed set of rule identifiers.

[0008] Preferably, in step S3, the four-dimensional business grouping knowledge includes business grouping type, business grouping dependency, visit grouping field, and prescription grouping field. The business grouping type includes four categories: single visit, day, month, and year. Among them, all rules of the "single visit" type take a single visit as the smallest processing unit and do not involve cross-visit time aggregation. Their materialized datasets have the same form, and regardless of the values ​​of the other three dimensions, they are all merged into the same rule group. The "day, month, and year" types involve cross-visit time aggregation, so they are grouped according to the combination of the values ​​of business grouping dependency, visit grouping field, and prescription grouping field.

[0009] Preferably, in step S4, the step of back-calculating the number of buckets for the external table based on the data volume and the single-bucket capacity threshold specifically includes: The estimated data volume is obtained by multiplying the sum of the single-row byte constants by the number of data rows; the estimated data volume is divided by the single-bucket capacity threshold and rounded up to obtain the candidate bucket number; when the candidate bucket number is less than the preset minimum bucket number, the minimum bucket number is taken.

[0010] Preferably, in step S5, the central scheduler starts multiple shard executors according to the sharding broadcast routing strategy, and each shard executor has a unique shard sequence number. The main shard executor with shard sequence number 0 undertakes the initialization responsibility and executes the following in sequence: generating a unique task identifier, calling the version upgrade chain processing interface to perform version compatibility upgrade processing on the rule identifier set, calling the rule grouping and merging interface to merge the rule identifier set into several rule groups according to a preset strategy and encapsulate them into a task unit set, calling the adaptive bucketing interface to dynamically calculate the number of buckets based on the data volume, and finally writing the unique task identifier and the task unit set into the distributed cache, and writing the number of buckets into the cache for use in subsequent steps. After the shard executor with a shard sequence number not equal to 0 starts, it reads the unique task identifier from the distributed cache in a round-robin manner. After successfully reading, it starts the concurrent competition consumption process.

[0011] Preferably, in step S6, the structured query statement is stored externally in the form of a template, including at least two types: single-visit template and cross-visit template. The template includes at least placeholders for the number of buckets, visit group field, intermediate table name, filter condition, and subquery association condition.

[0012] Preferably, the method further includes the following mechanism: When a task cancellation instruction is received, the central scheduler sets the task status to cancelled and publishes a task cancellation event. This event is received in parallel by multiple listeners, including the data preparation listener, the risk control notification listener, and the result storage listener. The data preparation listener deletes the generated external and intermediate tables, the risk control notification listener notifies the risk control center to cancel the violation judgment, and the result storage listener notifies the result aggregation layer to cancel the result storage.

[0013] Preferably, the method further includes the following mechanism: The central scheduler records the status and progress of each of the three stages—data preparation, data analysis, and data storage—using task execution logs. The stage progress is represented by a decimal between 0 and 1 (example for the data preparation stage: 0.01→0.45→0.9→1.0). When an anomaly occurs at any stage, the stage status of that task is set to failure, the reason for the failure is recorded, and other jobs belonging to the same task on other shard executors are canceled.

[0014] According to another aspect of the present invention, a medical insurance supervision data processing system includes: Module M1: The central scheduler receives regulatory task requests; each regulatory task request contains a set of rule identifiers and a group of task parameters. Module M2: The central scheduler performs version upgrade chain processing on the set of rule identifiers; Module M3: The central scheduler reads the four-dimensional business grouping knowledge of each rule in the processed rule identifier set, uses the combination of four-dimensional values ​​as the grouping key, and merges rules with the same value combination into the same rule group, so that rules in the same rule group share the same materialized dataset; Module M4: The central scheduler first solidifies the task parameter group into a temporary filtering table; based on the temporary filtering table, it generates four intermediate tables for consultation, prescription, diagnosis, and surgery. Then, it counts the number of data rows in the consultation intermediate table, estimates the data volume based on the number of data rows and the preset single-row byte constant, and reverse-calculates the number of buckets for the external table based on the data volume and the single-bucket capacity threshold. Module M5: The central scheduler writes each rule group as a task unit into the distributed set and writes the total number of rule groups into the atomic counter; multiple shard executors concurrently compete to consume task units through the pop operation of the distributed set. Each time a task unit is consumed, the atomic counter is atomically decremented. The last shard executor to complete consumption triggers a unified cleanup operation based on the decremented value of the atomic counter. Module M6: The sharded executor dynamically generates time truncation functions and placeholder replacement results for structured query statements based on the business grouping type for the task units it consumes, thus obtaining materialized structured query statements; and creates external tables based on the number of buckets in the external table, loading the execution results of the materialized structured query statements into the external tables to form the shared dataset corresponding to the rule grouping. Module M7: When the atomic counter decreases to zero, the last completed sharding executor triggers the calculation of statistical analysis indicators and sends a commissioned analysis notification carrying a list of rule groups and task identifiers to the risk control center. The risk control center performs violation judgment based on the shared dataset of each rule group. The judgment results are aggregated and stored according to six dimensions: province, unified planning area, rule, institution, insured person, and medical treatment, for the regulatory workbench to query and drill down for analysis. Among them, the statistical analysis indicators include at least the number of administrative divisions, the number of detected persons, the number of detected persons, the amount of suspicious amount, and the number of detected rules.

[0015] Compared with the prior art, the present invention has the following beneficial effects: This invention involves a central scheduler receiving regulatory task requests → version upgrade chain processing → rule business grouping and merging → filtering temporary tables and four intermediate tables + adaptive bucketing → sharded task scheduling → dynamically materializing SQL and loading external tables → finally, the sharded executor triggers statistical analysis and risk control delegated analysis, with results stored in a six-dimensional aggregate. The data generated in each step (processed rule identifier set, rule groups, intermediate tables, external table bucket counts, task identifiers, etc.) are all used in subsequent steps.

[0016] This invention categorizes massive medical insurance regulatory rules into rule groups based on four-dimensional business grouping knowledge (business grouping type, business grouping dependency, visit grouping field, and prescription grouping field), enabling rules within the same group to share the same materialized dataset. This transforms the full-scale scanning of each rule into sharded parallel processing based on shared materialized data by business group. Furthermore, it achieves decentralized sharded task scheduling through pop-up operations of distributed collections and atomic counters, adaptively calculates the number of buckets in the external table based on the data scale, and combines version upgrade chain processing and task cancellation event listening to significantly reduce redundant calculations and storage overhead while ensuring data consistency.

[0017] This invention employs a rule-based business grouping and merging algorithm to group regulatory rules with the same data access dimension into the same rule group and share the same materialized dataset. This solves the problems of repetitive calculations and linear increases in job time with the number of rules caused by full rule-by-rule scanning in existing technologies. It achieves the effect of reducing the number of repeated scans and materializations of big data from the order of rules to the order of rule groups (reducing the time consumption by approximately 86%).

[0018] This invention solves the single-point bottleneck and uneven load problem of the master node in the unified distribution method by adopting distributed set pop operation and atomic counter sharding task scheduling, and achieves the effects of lock-free contention consumption, adaptive load balancing, and precise triggering of the closing logic once (neither repeating nor omitting).

[0019] This invention solves the dilemma of insufficient parallelism when the number of buckets is fixed, which is a problem when the data volume is small and the number of buckets in the external table is insufficient when the data volume is small and the number of buckets in the external table is large, by adopting adaptive bucketing based on the number of data rows and the constant number of bytes per row to estimate the data volume.

[0020] This invention solves the problem of distorted regulatory conclusions caused by task binding creation time rules and execution of outdated rules by adopting version upgrade chain processing.

[0021] This invention solves the problems of residual intermediate data and inability to accurately observe and roll back execution progress when a task is abnormal / cancelled by using multiple listeners to receive task cancellation events in parallel and a three-stage progress log. Attached Figure Description

[0022] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the overall process of medical insurance supervision data processing. Figure 2 This is a schematic diagram of the medical insurance supervision data processing system architecture; Figure 3 This diagram illustrates the grouping and merging of rule-based business tasks into sharded task scheduling. Detailed Implementation

[0023] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0024] Example 1: This embodiment provides a method for processing medical insurance regulatory data, such as... Figure 1 and Figure 3 As shown, the method includes: Step S1: The central scheduler receives regulatory task requests; each regulatory task request contains a set of rule identifiers and a task parameter group; the task parameter group includes at least one of the following: administrative division, medical institution level, medical category, time window, and treatment cost range.

[0025] Understandably, regulatory task requests are either manually created by the personnel in charge through the regulatory workbench (one-time tasks) or automatically generated by periodic tasks triggered on time by the daily / monthly plan. The central scheduler calculates the data time window based on this (daily tasks take yesterday, monthly tasks go back 18 months) and parses the task parameter group for subsequent filtering and time window calculation.

[0026] Step S2: The central scheduler performs version upgrade chain processing on the set of rule identifiers.

[0027] Specifically, rule identifiers that are inactive are removed, and those representing rule versions lower than the latest effective version are upgraded to point to the latest effective version based on the superior and original source rule identifiers, resulting in a processed set of rule identifiers. This step ensures the timeliness of the task execution rule set and avoids distorting regulatory conclusions by executing obsolete or outdated rules.

[0028] Step S3: The central scheduler reads the four-dimensional business grouping knowledge of each rule in the processed rule identifier set, uses the combination of four-dimensional values ​​as the grouping key, and merges rules with the same value combination into the same rule group, so that rules within the same rule group share the same materialized dataset, wherein: The four-dimensional business grouping knowledge includes business grouping type, business grouping dependency, visit grouping field, and prescription grouping field. The business grouping type includes four categories: single visit, day, month, and year. All rules for the "single visit" type take a single visit as the smallest processing unit and do not involve aggregation across visit times. Their materialized datasets have a consistent form, and regardless of the values ​​of the other three dimensions, they are all merged into the same rule group. The "day, month, and year" types involve aggregation across visit times, and are grouped according to the combination of values ​​of business grouping dependency, visit grouping field, and prescription grouping field.

[0029] Step S4: The central scheduler first solidifies the task parameter group into a temporary filtering table, which is then used as a unified filtering basis in the materialization process of all subsequent rule groups. Based on the temporary filtering table, four intermediate tables are generated: consultation, prescription, diagnosis, and surgery (the table name carries the task identifier and project prefix to support multi-tenant isolation, and has a limited lifespan, such as 2 days, for automatic recycling). Then, the number of data rows in the consultation intermediate table is counted, the data volume is estimated based on the number of data rows and the preset single-row byte constant, and the number of buckets in the external table is deduced based on the data volume and the single-bucket capacity threshold.

[0030] Specifically, in response to a received regulatory task request, the unique identifier of the task is extracted from the regulatory task request, and a temporary filtering table name uniquely bound to the regulatory task is dynamically generated based on preset table name rules. Based on the task parameter group in the regulatory task request, a benchmark filtering instruction containing the aforementioned constraints is constructed. The benchmark filtering command is sent to the distributed data computing engine for execution. The medical insurance benchmark records that meet the task parameter group are persistently written into the filtering temporary table, and the metadata identifier of the filtering temporary table is output. Based on the unique task identifier and the metadata identifier of the temporary filtering table, data extraction and materialization construction instructions are generated for the medical visit entity, prescription entity, diagnosis entity and surgery entity respectively. In each materialization construction instruction, a temporary table is used as the driving filtering source, an inner join constraint is executed with the entity table corresponding to the full medical insurance basic data, and the materialization intermediate table of the target dimension is defined and generated through the "CREATE TABLE...AS SELECT" statement; The materialization construction instructions of each dimension are traversed and submitted to the distributed data computing engine for synchronous execution in sequence. The execution is blocked on the executor side to wait for execution feedback until the intermediate tables of consultation, prescription, diagnosis and surgery are generated for subsequent multi-rule grouping and sharing.

[0031] The estimated data volume (MB) is obtained by multiplying the sum of the single-line byte constants (306 bytes for consultation + 264 bytes for prescription + 106 bytes for diagnosis) by the number of data lines; the estimated data volume is then divided by the single-bucket capacity threshold (default 512MB, configurable) and rounded up to obtain the number of candidate buckets; when the number of candidate buckets is less than the preset minimum number of buckets (e.g., 500), the minimum number of buckets is used as a safety net to avoid empty buckets and small files.

[0032] Construct intermediate state association statistics instructions, which associate the intermediate medical visit table and the intermediate prescription table within the primary key, and match them with the task constraints of the regulatory task to obtain the target total number of valid record rows after the two tables are associated. Extract the pre-defined baseline byte size of each row of data for each dimension, and multiply the weighted sum of the baseline byte size of each row of data by the total number of valid target records to obtain the estimated overall data volume of the regulatory data to be processed. Verify the system's preset single-bucket carrying capacity threshold: if the threshold is lower than the preset safety lower limit, reset the single-bucket carrying capacity to the default protection value; otherwise, maintain the threshold. The ratio of the estimated total data volume to the verified single-bucket capacity threshold is used to perform an up-rounding operation to calculate the number of candidate buckets to guide the parallel partitioning of external tables.

[0033] For example, comparing the results: a small-scale coordinated area at the municipal level (500,000 outpatient visits) is estimated to be about 323MB, with a minimum of 500 buckets; a large-scale coordinated area at the provincial level (50 million outpatient visits) is estimated to be about 32,287MB, with 63 buckets. The number of buckets adaptively adjusts with the data size, ensuring that the parallelism of reading remains within an optimal range.

[0034] Step S5: The central scheduler writes each rule group as a task unit into the distributed set and writes the total number of rule groups into the atomic counter. Multiple shard executors concurrently compete to consume task units through the pop operation of the distributed set. Each time a task unit is consumed, the atomic counter is atomically decremented. The last shard executor to finish consuming a task unit triggers a unified cleanup operation based on the decremented value of the atomic counter. This mechanism can naturally achieve load balancing without unified distribution by the master node (faster executors automatically consume more task units), and the last shard executor to finish triggers the cleanup operation.

[0035] It is understandable that step S5 specifically includes: Step S5.1: After the central scheduler obtains the list of rule groups, it iterates through each rule group, serializes each rule group into a task unit object, writes each task unit into a distributed set with a preset key name, and writes the total number of rule groups into an atomic counter with a preset key name. The initial value of the atomic counter is equal to the total number of rule groups.

[0036] Step S5.2: After multiple shard executors start, they atomically pop a task unit from the distributed set. When a non-empty result is returned, the current shard executor successfully competes to acquire a task unit and then executes the dynamic materialization and loading process corresponding to the task unit. After each task unit is consumed, the current shard executor atomically decrements the atomic counter and competes for the next task unit until an empty result is returned and the loop exits. Step S5.3: After exiting the consumption loop, each shard executor obtains the last return value as an indicator of the number of remaining tasks. When the return value is equal to 0, it indicates that the current shard executor has completed the consumption of the last task unit, which is the last shard executor to complete, and this shard executor will perform the unified cleanup operation alone. When the return value is greater than 0, it indicates that there are still other shard executors consuming task units or there is an abnormal situation, and the current shard executor will not perform the cleanup operation. Step S5.4: The final unified cleanup operations performed by the sharding executor include: calling the statistical analysis interface to perform indicator statistics on the processed rule groups; updating the task execution log status to data preparation complete; calling the notification interface to send an analysis entrustment message to the risk control center to trigger the subsequent risk control analysis process; and deleting the cache keys corresponding to the distributed set and atomic counter to complete resource cleanup.

[0037] Based on the above scheme, the central scheduler starts multiple shard executors according to the sharding broadcast routing strategy, each shard executor having a unique shard sequence number. The master shard executor with shard sequence number 0 is responsible for initialization, and executes the following sequentially: generating a unique task identifier, calling the version upgrade chain processing interface to perform version compatibility upgrade processing on the rule identifier set, calling the rule grouping and merging interface to merge the rule identifier set into several rule groups according to a preset strategy and encapsulate them into task unit sets, calling the adaptive bucketing interface to dynamically calculate the number of buckets based on the data volume, and finally writing the unique task identifier and task unit set into the distributed cache, and writing the number of buckets into the cache for subsequent steps. After the shard executor with a non-zero shard sequence number starts, it reads the unique task identifier from the distributed cache in a round-robin manner. After successfully reading, it starts the concurrent competition consumption process, such as... Figure 3 As shown in the figure, this diagram illustrates the scheduling of rule-based business grouping and sharding tasks. The first and second slave sharding executors in the diagram simply represent any two sharding executors whose sharding sequence number is not 0. The number of slave sharding executors is not limited to two and can be expanded to more depending on the data scale and computing resources.

[0038] It should be noted that before the dynamic materialization and loading process of each task unit in step S5.2, the current shard executor prepares the corresponding data to be analyzed from the external data source according to the rule grouping information in the task unit, and loads the prepared data into the computing context of the execution engine for dynamic materialization processing.

[0039] Step S6: The sharding executor dynamically generates placeholder replacement results for time truncation functions and structured query statements for the task units it consumes, based on the business grouping type, to obtain materialized structured query statements; and creates an external table based on the number of buckets in the external table, loading the execution results of the materialized structured query statements into the external table to form a shared dataset corresponding to the rule group; wherein, the structured query statements are stored externally in the form of templates, including at least two types: single-visit templates and cross-visit (day / month / year aggregation) templates. The templates include at least bucket number placeholders, visit group field placeholders, intermediate table name placeholders, filter condition placeholders, and subquery association condition placeholders.

[0040] It is understandable that step S6 specifically includes: Step S6.1: The structured query statement template is externalized to the code in the form of a configuration file, including at least a single-visit template and a cross-visit aggregation template; the single-visit template is used to handle rule calculations for a single visit dimension, and the cross-visit aggregation template is used for daily, monthly, or yearly aggregation scenarios across visit dimensions; each template has at least the following placeholders pre-defined: a first placeholder for indicating the number of buckets, a second placeholder for indicating the visit grouping field, a third placeholder for indicating the intermediate table name, a fourth placeholder for indicating the filtering conditions, and a fifth placeholder for indicating the subquery association conditions; the configuration file is loaded and read by the sharding executor at runtime.

[0041] Step S6.2: The sharding executor reads the business grouping type corresponding to the current task unit. The business grouping type includes at least daily grouping, monthly grouping, and yearly grouping. When the business grouping type is daily grouping, a preset daily truncation function template is obtained. The daily truncation function template contains three date placeholders, which are filled into the medical visit grouping field in sequence to generate a date truncation expression truncated to the day. When the business grouping type is monthly grouping, a preset monthly truncation function template is obtained. The monthly truncation function template contains two date placeholders, which are filled into the medical visit grouping field in sequence to generate a date truncation expression truncated to the month. When the business grouping type is yearly grouping, a preset annual truncation function template is obtained. The annual truncation function template contains one date placeholder, which is filled into the medical visit grouping field to generate a date truncation expression truncated to the year. Step S6.3: The sharding executor selects the corresponding SQL template based on the business grouping type of the current task unit. If the business grouping type is a single visit type, the single visit template is selected; if the business grouping type is a cross-visit aggregation type, the cross-visit aggregation template is selected. Obtain the placeholder mapping set of the current task unit. The placeholder mapping set contains at least the bucket number value, visit grouping field name, intermediate table name, filter condition expression, and subquery association condition expression. Iterate through each key-value pair in the placeholder mapping set, replace each placeholder in the SQL template with the corresponding actual value, and embed the time truncation function generated in step S6.2 into the corresponding date grouping position in the SQL template to obtain the complete materialized structured query statement. Step S6.4: The sharding executor obtains the external table naming template and the external table creation statement template. The external table creation statement template includes at least a table name placeholder, a storage path placeholder, and a lifecycle declaration. Based on the task identifier and rule grouping identifier of the current task, the external table naming template is filled to generate the external table name. Based on the external table name and the cache key of the current task, the external table creation statement template is filled to generate the creation statement. The computing engine interface is called to execute the creation statement, creating an external table with a preset lifecycle reclamation strategy. The external table name is associated with the current cache key and stored in the cache. The lifecycle reclamation strategy is used to automatically reclaim storage resources by the computing engine after the external table exceeds a preset lifespan. Step S6.5: The sharding executor obtains the materialized structured query statement generated in step S6.3, fills the external table name into the corresponding table name placeholder position in the materialized structured query statement, and generates a data loading statement; the data loading statement adopts the overwrite write method, writes the query result of the materialized structured query statement into the corresponding partition of the external table according to the partition key, forming the shared dataset corresponding to the rule group; when executing the data loading statement, if the execution fails, a retry mechanism is triggered, and the execution is repeatedly submitted until the execution is successful or the preset retry limit is reached, after which an exception is thrown; Step S6.6: The external table is created on a shared distributed storage system. After the data loading statement is executed, the shared dataset stored in the external table is available for subsequent risk control analysis to access through the standard query interface. Multiple analysis tasks are isolated from each other by the table name of the external table. Multiple rule groups within the same task are isolated by partitioning the data using the partition key of the external table. The value of the partition key is obtained by hashing the results of the materialized structured query statement based on the number of buckets, so as to achieve a uniform distribution of data in the external table.

[0042] For example, the eight rule groups are loaded into eight external tables to form eight shared datasets; if grouping and merging are not used, 57 datasets would need to be loaded for each of the 57 rules. This invention reduces the number of loading times by about 86%.

[0043] Step S7: When the atomic counter decrements to zero, the last completed sharding executor triggers the calculation of statistical analysis indicators. These indicators include at least the number of administrative divisions, the number of detected individuals, the number of detected individuals, the amount of suspected violations, and the number of detected rules. A delegated analysis notification carrying a list of rule groups and a task identifier is sent to the risk control center. The risk control center performs violation determination based on the shared dataset of each rule group. The determination results are aggregated and stored according to six dimensions: province, unified planning area, rule, institution, insured person, and medical visit, for querying and drill-down analysis on the regulatory workbench. This invention centralizes general responsibilities such as data preparation in the rule engine, while delegating the specialized logic of violation determination to the decoupled risk control center, achieving loose coupling through remote procedure calls and fault-tolerant switches.

[0044] In this embodiment, when a task cancellation instruction is received, the central scheduler sets the task status to cancelled and publishes a task cancellation event. This event is received in parallel by multiple listeners, including the data preparation listener, the risk control notification listener, and the result storage listener. The data preparation listener deletes the generated external and intermediate tables, the risk control notification listener notifies the risk control center to cancel the violation judgment, and the result storage listener notifies the result aggregation layer to cancel the result storage.

[0045] In this embodiment, the central scheduler records the stage status and progress of each of the three stages—data preparation, data analysis, and data storage—using a task execution log. The stage progress is represented by a decimal between 0 and 1 (example for the data preparation stage: 0.01→0.45→0.9→1.0). When an anomaly occurs in any stage, the stage status of that task is set to failure, the reason for the failure is recorded, and jobs belonging to the same task on other shard executors are canceled.

[0046] The present invention also provides a medical insurance supervision data processing system, which can be implemented by executing the process steps of the medical insurance supervision data processing method. That is, those skilled in the art can understand the medical insurance supervision data processing method as a preferred embodiment of the medical insurance supervision data processing system.

[0047] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0048] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A method for processing medical insurance regulatory data, characterized in that, include: Step S1: The central scheduler receives a monitoring task request; Each regulatory task request contains a set of rule identifiers and a group of task parameters; Step S2: The central scheduler performs version upgrade chain processing on the rule identifier set; Step S3: The central scheduler reads the four-dimensional business grouping knowledge of each rule in the processed rule identifier set, uses the combination of four-dimensional values ​​as the grouping key, and merges rules with the same value combination into the same rule group, so that the rules in the same rule group share the same materialized dataset. Step S4: The central scheduler first solidifies the task parameter group into a temporary filtering table; based on the temporary filtering table, it generates four intermediate tables for consultation, prescription, diagnosis, and surgery. Then, it counts the number of data rows in the consultation intermediate table, estimates the data volume based on the number of data rows and the preset single-row byte constant, and reverses the number of buckets in the external table based on the data volume and the single-bucket capacity threshold. Step S5: The central scheduler writes each rule group as a task unit into the distributed set and writes the total number of rule groups into the atomic counter; multiple shard executors concurrently compete to consume task units through the pop operation of the distributed set. Each time a task unit is consumed, the atomic counter is atomically decremented. The last shard executor to complete consumption triggers a unified cleanup operation based on the decremented value of the atomic counter. Step S6: For the task units it consumes, the shard executor dynamically generates the time truncation function and the placeholder replacement result of the structured query statement according to the business group type, and obtains the materialized structured query statement; and creates an external table according to the number of buckets in the external table, loads the execution result of the materialized structured query statement into the external table, and forms the shared dataset corresponding to the rule group. Step S7: When the atomic counter decreases to zero, the last completed sharding executor triggers the calculation of statistical analysis indicators and sends a commissioned analysis notification carrying a list of rule groups and task identifiers to the risk control center. The risk control center performs violation judgment based on the shared dataset of each rule group. The judgment results are aggregated and stored according to six dimensions: province, unified planning area, rule, institution, insured person, and medical treatment, for query and drill-down analysis by the regulatory workbench. The statistical analysis indicators include at least the number of administrative divisions, the number of detected persons, the number of detected persons, the amount of suspicious amount, and the number of detected rules.

2. The method according to claim 1, characterized in that, In step S1, the task parameter group includes at least one of the following: administrative division, medical institution level, medical category, time window, and treatment cost range; the supervision task request is manually created by the person in charge through the supervision workbench, or automatically generated by the periodic task triggered on time by the daily / monthly plan, and the central scheduler calculates the data time window and parses the task parameter group accordingly.

3. The method according to claim 1, characterized in that, Step S2 specifically includes: Remove rule identifiers that are in a deactivated state, and upgrade rule identifiers whose rule versions are lower than the latest effective version to rule identifiers that point to the latest effective version based on the superior source rule identifier and the original source rule identifier, thus obtaining the processed set of rule identifiers.

4. The method according to claim 1, characterized in that, In step S3, the four-dimensional business grouping knowledge includes business grouping type, business grouping dependency, visit grouping field, and prescription grouping field. The business grouping type includes four categories: single visit, day, month, and year. Among them, all rules of the "single visit" type take a single visit as the smallest processing unit and do not involve aggregation across visit times. Their materialized datasets have the same form, and regardless of the values ​​of the other three dimensions, they are all merged into the same rule group. The "day, month, and year" types involve aggregation across visit times, so they are grouped according to the combination of the values ​​of business grouping dependency, visit grouping field, and prescription grouping field.

5. The method according to claim 1, characterized in that, In step S4, the specific steps of deducing the number of buckets for the external table based on the data volume and the single-bucket capacity threshold include: The estimated data volume is obtained by multiplying the sum of the single-row byte constants by the number of data rows; the estimated data volume is divided by the single-bucket capacity threshold and rounded up to obtain the candidate bucket number; when the candidate bucket number is less than the preset minimum bucket number, the minimum bucket number is taken.

6. The method according to claim 1, characterized in that, In step S5, the central scheduler starts multiple shard executors according to the sharding broadcast routing strategy, and each shard executor has a unique shard sequence number. The main shard executor with shard sequence number 0 is responsible for initialization and executes the following steps in sequence: generating a unique task identifier, calling the version upgrade chain processing interface to perform version compatibility upgrade processing on the rule identifier set, calling the rule grouping and merging interface to merge the rule identifier set into several rule groups according to a preset strategy and encapsulate them into a task unit set, calling the adaptive bucketing interface to dynamically calculate the number of buckets based on the data volume, and finally writing the unique task identifier and the task unit set into the distributed cache, and writing the number of buckets into the cache for use in subsequent steps. After the shard executor with a shard sequence number not equal to 0 starts, it reads the unique task identifier from the distributed cache in a round-robin manner. After successful reading, it starts the concurrent competition consumption process.

7. The method according to claim 1, characterized in that, In step S6, the structured query statement is stored externally in the form of a template, including at least two types: single-visit template and cross-visit template. The template includes at least placeholders for the number of buckets, visit group field, intermediate table name, filter condition, and subquery association condition.

8. The method according to claim 1, characterized in that, The method also includes the following mechanism: When a task cancellation instruction is received, the central scheduler sets the task status to cancelled and publishes a task cancellation event. This event is received in parallel by multiple listeners, including the data preparation listener, the risk control notification listener, and the result storage listener. The data preparation listener deletes the generated external and intermediate tables, the risk control notification listener notifies the risk control center to cancel the violation judgment, and the result storage listener notifies the result aggregation layer to cancel the result storage.

9. The method according to claim 1, characterized in that, The method also includes the following mechanism: The central scheduler records the stage status and progress of each of the three stages of data preparation, data analysis, and data storage using task execution logs. The stage progress is represented by a decimal between 0 and 1. When an anomaly occurs at any stage, the stage status of that task is set to failure, the reason for the failure is recorded, and other jobs belonging to the same task on other shard executors are canceled.

10. A medical insurance supervision data processing system, characterized in that, include: Module M1: The central scheduler receives regulatory task requests; each regulatory task request contains a set of rule identifiers and a group of task parameters. Module M2: The central scheduler performs version upgrade chain processing on the set of rule identifiers; Module M3: The central scheduler reads the four-dimensional business grouping knowledge of each rule in the processed rule identifier set, uses the combination of four-dimensional values ​​as the grouping key, and merges rules with the same value combination into the same rule group, so that rules in the same rule group share the same materialized dataset; Module M4: The central scheduler first solidifies the task parameter group into a temporary filtering table; based on the temporary filtering table, it generates four intermediate tables for consultation, prescription, diagnosis, and surgery. Then, it counts the number of data rows in the consultation intermediate table, estimates the data volume based on the number of data rows and the preset single-row byte constant, and reverse-calculates the number of buckets for the external table based on the data volume and the single-bucket capacity threshold. Module M5: The central scheduler writes each rule group as a task unit into the distributed set and writes the total number of rule groups into the atomic counter; multiple shard executors concurrently compete to consume task units through the pop operation of the distributed set. Each time a task unit is consumed, the atomic counter is atomically decremented. The last shard executor to complete consumption triggers a unified cleanup operation based on the decremented value of the atomic counter. Module M6: The sharded executor dynamically generates time truncation functions and placeholder replacement results for structured query statements based on the business grouping type for the task units it consumes, thus obtaining materialized structured query statements; and creates external tables based on the number of buckets in the external table, loading the execution results of the materialized structured query statements into the external tables to form the shared dataset corresponding to the rule grouping. Module M7: When the atomic counter decreases to zero, the last completed sharding executor triggers the calculation of statistical analysis indicators and sends a commissioned analysis notification carrying a list of rule groups and task identifiers to the risk control center. The risk control center performs violation judgment based on the shared dataset of each rule group. The judgment results are aggregated and stored according to six dimensions: province, unified planning area, rule, institution, insured person, and medical treatment, for query and drill-down analysis by the regulatory workbench. The statistical analysis indicators include at least the number of administrative divisions, the number of detected persons, the number of detected persons, the amount of suspicious amount, and the number of detected rules.

Images