Enterprise online physical examination diagnostic book generation method and system and computer program product

Abstract

The invention relates to the technical field of enterprise digital management, in particular to an enterprise online physical examination diagnostic book generation method and system and a computer program product. The method comprises the steps of collecting enterprise answers and attachments, and performing diagnosis calculation to generate a structured result R; recording an execution track T in the calculation process, constructing a dependency graph G according to the execution track T, solving a minimum dependency closure D, and generating a dependency fingerprint VD and a cache key K; rendering the diagnostic book into a static resource fragment Pi and generating a fragment list M, and performing atomic switching release on the list to avoid mixed use of new and old fragments; when the configuration is changed to form delta, the delta is mapped to G, incremental influence analysis is carried out to obtain an influenced fragment set P delta, and only differential failure and local re-rendering are carried out on the P delta; and carrying out single flight / lease concurrency control on the same K, verifying the abstract of the list, and issuing. According to the scheme, the updating efficiency and the cache hit rate are improved, and content consistency and high concurrency stability are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of enterprise digital management technology, and in particular to a method, system, and computer program product for generating online health check reports for enterprises. Background Technology

[0002] With the advancement of enterprise digital transformation, "online health check / assessment" services targeting enterprise management, compliance and risk control, financial health, and operational capabilities are gradually becoming a common form of information technology application. These platforms typically collect basic enterprise information and operational data through multi-dimensional questionnaires, automatically generate diagnostic results according to preset scoring rules, threshold segmentation, and diagnostic templates, and further create a shareable, traceable, and searchable diagnostic report page to facilitate subsequent analysis and decision-making by enterprise managers, external consultants, or expert teams. In actual deployment, these platforms often face the contradiction between multi-terminal access (mobile / PC), high concurrency, search engine indexing (SEO) requirements, and the balance between content "freshness" and "availability." On the one hand, diagnostic reports aim to improve access speed and indexability through static publishing; on the other hand, configurations such as questionnaire question banks, scoring rules, threshold segmentation, template fragments, and SEO fields inevitably need to be updated during operation. If old caches or old static pages are still used, problems such as inconsistencies between diagnostic results and current rules, chaotic page display, or invalid references can easily occur. If an overly aggressive full invalidation or short TTL strategy is adopted, it will lead to a decrease in cache hit rate and a sharp increase in backend computing pressure, which may even cause "cache breakdown / avalanche" and service unavailability in severe cases. Therefore, how to improve the hit rate and update efficiency of static pages while ensuring the consistency and traceability of diagnostic content is one of the long-standing engineering challenges of this type of system.

[0003] In existing technologies, various implementation approaches have been proposed for the staticization and caching management of dynamic content. For example, Chinese patent document CN103064932A discloses a static page processing system and method, which receives URL requests from user terminals through a web cache server and checks whether the cache is hit: if hit, the cached result is returned directly; if not hit, the target address remains unchanged and a new URL request is generated and forwarded to the web server. The web server converts the request into an actual dynamic request, processes it through a server-side script, and returns the result. The web cache server then caches the processing result and sends it back to the user, thereby reducing the load on the real web server and improving response efficiency by utilizing the cache server. This solution provides a relatively clear engineering implementation of the basic "dynamic generation—caching—return" chain and is suitable for staticizing frequently accessed dynamic pages to improve performance.

[0004] However, for business pages like online health checkups / diagnosis reports that are "strongly dependent on configuration versions and calculation rules," simply checking "whether the cache is hit / whether it's generated from the origin server if it's not" is often insufficient to solve the content consistency problem. On the one hand, diagnosis report pages are not only URL-related but also heavily reliant on configurations such as question banks, scoring rules, threshold segmentation, and templates. When configurations are updated, whether the old cache should be invalidated, which objects should be invalidated, and when it should be recalculated are all crucial questions. Without a fine-grained dependency management mechanism, the problem of "configuration changes but cache not being updated" can easily arise. On the other hand, if a coarse-grained strategy is adopted (such as full clearing by category or expiration by fixed TTL), a large number of unaffected cached objects will be unnecessarily deleted, leading to performance fluctuations and recalculation storms, which can easily trigger system-level risks, especially during peak business periods.

[0005] Relatedly, existing technologies have also proposed mechanisms for "easier location of cached objects to be invalidated." US Patent document US7076608B2 discloses a system and method for invalidating cache using secondary keys: when the primary key of a cached object is typically a URL, instead of relying solely on the URL to locate the data to be invalidated, "secondary keys" such as data source identifiers, template identifiers, geographic address information, names, and dates are used as identification criteria; the application or other entity passes the secondary key information to the caching system, which then identifies and invalidates cached objects matching the secondary keys. This approach helps avoid maintaining a large list of URLs in scenarios such as "template changes / data source changes," thereby improving the manageability of invalidation operations.

[0006] However, in the context of corporate health check reports, relying solely on secondary keys such as "template identifier / data source identifier" may still be too crude. This is because online health checks are typically determined by multi-level scoring, sub-indicators, threshold segments, rule branches, and template fragments; changes to the same template or data source may not affect all reports, and even reports from different companies within the same category may be affected differently. If the failure strategy remains at the "template-level / data source-level" matching, contradictions may arise: the failure scope may be too large (leading to wasted recalculation and the risk of data breaches) or too small (resulting in outdated content). Furthermore, when reports are fragmented and static (e.g., a combination of multiple fragments such as summaries, risk items, and recommendations), a lack of constraints on consistency between fragments may lead to the mixing of old and new fragments, causing semantic contradictions on the page and difficulties in auditing and tracing.

[0007] Furthermore, regarding the caching and expiration timing control of dynamically generated objects, Chinese patent document CN101147379B discloses a system and method for caching dynamically generated objects in a network. It emphasizes that certain dynamic content can only be cached and provided within a very short time period. To ensure data "freshness," cached objects can be invalidated or expired after a very small time increment, and objects can be refreshed before invalidation. This allows for the provision of previous objects with a shorter caching cycle while generating responses in milliseconds, without significantly compromising data freshness. This scheme embodies the idea of ​​balancing performance and freshness through fine-grained control of cache expiration.

[0008] However, for content like enterprise online health check reports—which involve "configuration-driven + computational output + long-tail access"—simply relying on "extremely short TTL / fast expiration" is not always feasible. Health check reports often have strong business retention and follow-up requirements (e.g., enterprises want to repeatedly view the same diagnostic results within a certain period, compare historical changes, or use them for expert consultations). Setting the cache expiration time too short can significantly increase backend rendering and computation costs. Simultaneously, configuration updates are usually discrete operational actions. Without a "change set - impact scope" derivation mechanism, the system can only passively respond by full refresh or shortening the TTL, making it difficult to balance stability and cost. Furthermore, in high-concurrency scenarios, when multiple requests simultaneously hit the same hot health check report or hot template from the same category, the lack of concurrency suppression measures (e.g., recalculation and deduplication of the same key, lease locks / single-operation mechanisms, etc.) can easily lead to instantaneous concurrent recalculation spikes, causing cache breakdown and database / computing service overload.

[0009] In summary, existing technologies provide fundamental technical means for static webpage caching, dynamic object cache expiration control, and using secondary keys to locate invalid objects. However, their direct application to the scenario of "enterprise online health check reports" still has at least the following shortcomings: 1) The granularity of cache invalidation is too coarse, making it difficult to determine the minimum affected set based on runtime real dependencies such as "rule branches / threshold hits / fragment references," which can easily lead to full or false invalidations; 2) Insufficient constraints on the version consistency of fragmented static pages can easily lead to the mixing of old and new fragments, resulting in inconsistent diagnostic semantics and difficulties in auditing and tracing; 3) Lack of effective concurrent recalculation suppression and write verification mechanisms under configuration changes or hot access, which poses risks of cache breakdown, cache avalanche, and semi-finished product contamination of the cache; 4) In terms of balancing SEO staticization and content freshness, there is a lack of a "change-driven incremental update" mechanism tailored to the business characteristics of the diagnostic report, making it difficult to simultaneously meet access performance, stability, and consistency.

[0010] Therefore, there is an urgent need for a technical solution for generating and publishing online health check reports for enterprises. This solution should be able to accurately identify and differentially update the affected content when the questionnaire configuration and diagnostic rules change, while ensuring the version consistency of fragmented static resources during the publishing process. Furthermore, it should improve system stability through concurrency control and verification mechanisms, thereby achieving efficient, reliable, and traceable publishing of the diagnosis report page under high concurrency, multi-terminal, and SEO requirements. Summary of the Invention

[0011] This invention aims to provide a method and system for generating, fragmenting, statically publishing, and differentially updating online medical examination reports for enterprises. It automatically records the execution trajectory and constructs a dependency graph during the diagnostic calculation process, calculates the minimum dependency closure to generate dependency fingerprints and cache keys, and performs incremental impact analysis based on the dependency graph during configuration changes to accurately locate affected segments and perform local re-rendering. Simultaneously, it employs manifest atomic switching, single-flight / lease concurrency control, and verification digest validation to solve the problems of crude cache invalidation, high update costs, mixed use of old and new segments, and cache breakdown and inconsistency under high concurrency in existing technologies. This achieves consistent, traceable, and high-performance stable publishing of diagnostic report content.

[0012] In a first aspect, the present invention provides a method for generating an online health check-up report for an enterprise, the method comprising the following steps:

[0013] S1) Receive the enterprise identifier and selected physical examination category identifier submitted by the user after registration and login, load the questionnaire configuration object corresponding to the physical examination category, the questionnaire configuration object includes at least a set of questions and their indicator mapping, scoring rules, threshold segmentation, diagnosis certificate template, template fragment set and SEO meta information set; output the questionnaire page to the terminal and collect user answers and attachment materials;

[0014] S2) Perform diagnostic calculations on the answers according to the scoring rules to generate a structured diagnostic result object R, and record the execution trajectory T during the diagnostic calculation process. The execution trajectory T includes at least: the triggered indicator identifier, the hit threshold segment identifier, the entered scoring rule branch identifier, the referenced template fragment identifier, and the referenced SEO field identifier.

[0015] S3) Construct a dependency graph G based on the execution trajectory T and calculate the minimum dependency closure D of this diagnosis from G, wherein D contains at least a set of closures of the indicator identifier, threshold segment identifier, rule branch identifier, template fragment identifier, and SEO field identifier; perform normalized summary calculation on the version components of each dependency element in D to obtain the dependency fingerprint V. D ;

[0016] S4) Based on the diagnostic report template, render the diagnostic result object R into a collection of multiple independently cacheable static resource fragments P. i And generate a fragment list M, where M includes at least the cache key K = <Enterprise ID, Medical Examination Category ID, V> D > Fragment identifier set id(P i ) and P i Or the verification summary of M; when publishing diagnostic report page resources to the public, the fragment list M is used as the sole assembly basis and the new list is switched atomically to avoid mixing old and new fragments;

[0017] S5) Construct a reverse index of "configuration element - dependency graph node - fragment", and when a change in the questionnaire configuration object is detected, forming a change set Δ, map Δ to the node set of the dependency graph G, and perform incremental impact analysis based on G to determine the set of affected fragments. Only for The corresponding fragment undergoes differential invalidation and local re-rendering, and a new fragment list M′ is generated. Unaffected fragments are kept cached and reused.

[0018] S6) Enable single-flight mechanism or lease lock for concurrent re-render requests for the same cache key K, so that only one re-render task is allowed to execute at the same time; before writing to cache / static storage and publishing a new manifest, perform the verification digest verification on M′, and only after passing the verification can the publication and update of the cache lifecycle be allowed.

[0019] Preferably, the dependency graph G is a directed graph, whose nodes include at least indicator nodes, threshold segmentation nodes, rule branch nodes, template fragment nodes and SEO field nodes, and the edges are used to represent the dependency relationships of "diagnostic calculation trigger", "threshold hit", "rule branch entry", "template fragment reference" or "SEO field reference"; the minimum dependency closure D is obtained by performing reachability calculation or closure reduction on the target output node.

[0020] Preferably, the incremental impact analysis includes: taking the nodes corresponding to the change set Δ as the source set, performing propagation calculations on the dependency graph G to obtain the affected node set, and mapping the affected node set to the affected fragment set. When the propagation result is empty, the current fragment list M remains unchanged and re-rendering is prohibited.

[0021] Preferably, the static resource fragment set P i It includes at least a rating summary fragment, a risk item fragment, a suggestion fragment, and a page header fragment; the page header fragment contains the SEO meta information and is atomically published along with the fragment list M.

[0022] Preferably, during the attachment upload stage, the file format whitelist and size threshold are checked, and a file summary is generated as part of the execution trajectory T or as a node in the dependency graph G; when the attachment changes, causing the corresponding node to change, the incremental impact analysis determines the set of affected fragments, including at least the risk item fragments associated with the attachment.

[0023] As a preferred method, when the diagnosis report list M is published, a local re-render is triggered by differential failure, or a user submits consultation materials or an expert report, the SMS interface is called to send a status notification message to the user and / or the platform.

[0024] Secondly, the present invention also provides a system for generating online medical examination reports for enterprises, characterized in that the system is used to implement the method, including:

[0025] The questionnaire configuration management module is used to maintain the question set and indicator mapping, scoring rules, threshold segmentation, diagnosis template, template fragment set and SEO meta information set according to physical examination category, and output the configuration change set Δ;

[0026] The diagnostic calculation and trajectory recording module is used to collect user responses and attachments, generate structured diagnostic result objects R, and record the execution trajectory T.

[0027] The dependency graph construction and closure calculation module is used to construct a dependency graph G based on the execution trajectory T and calculate the minimum dependency closure D and dependency fingerprint V. D ;

[0028] The fragmented static rendering and manifest module is used to generate a collection of static resource fragments, P. i And a list of fragments M, and publish the list atomically to avoid page mix-ups;

[0029] The reverse indexing and incremental impact analysis module is used to map the change set Δ to the dependency graph G and perform incremental impact analysis to determine the set of affected segments. And on Perform differential failure and local re-rendering;

[0030] The concurrent consistency control module is used to enable single-flight mechanisms or lease locks on the same cache key K and perform checksum verification on the manifest before publication.

[0031] Preferably, the system also includes a consultation data and expert report module, which is used to perform format and size limit verification on the consultation data uploaded by users and generate file summaries, distribute consultation data to experts and receive expert reports; the expert reports are generated by the fragmented static rendering and list module to generate consultation report fragments and consultation report lists, and are uniformly updated by the incremental impact analysis and differential failure mechanism;

[0032] And / or, the system also includes a log auditing module for recording login, configuration changes, differential failures, partial re-rendering, list publishing and consultation data / report publishing events, and supports retrieval and tracking by enterprise identifier, physical examination category identifier, operation type and date range.

[0033] Thirdly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method.

[0034] Fourthly, the present invention also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the method.

[0035] This invention utilizes an automated dependency extraction mechanism of "execution trajectory T - dependency graph G - minimum dependency closure D" to establish a one-to-one minimum dependency relationship between the diagnostic report page and the actual metrics, threshold segments, rule branches, template fragments, and SEO fields triggered during runtime, and generates a dependency fingerprint V accordingly. D With the cache key K, when configurations such as the question bank, scoring rules, thresholds, or template fragments change, the system can map the set of changes Δ to nodes in the dependency graph and perform incremental impact analysis to accurately obtain the set of affected fragments. By only addressing differential failures and partial re-rendering of affected fragments, the cache hit rate is significantly improved, the computational and rendering overhead caused by full failures is reduced, update propagation time is shortened, and unnecessary recalculations are minimized. Simultaneously, using the fragment list M as the sole basis for page assembly and atomically switching to the new list, coupled with verification digests of the list or fragment set, avoids inconsistencies in diagnostic semantics, mismatched evidence chains, and difficulties in auditing traceability caused by mixing old and new fragments, thus improving release consistency and traceability. Furthermore, a single-fly / lease mechanism is introduced for re-rendering of the same key, effectively suppressing concurrent recalculation surges during hot access or concentrated configuration changes, preventing cache breakdown, cache avalanche, and cache contamination by unfinished products, improving stability and service availability in high-concurrency scenarios. Since the diagnostic report is published as a static resource and embeds SEO meta-information, it also improves cross-platform access performance and search engine indexing, ultimately achieving a comprehensive improvement in "accurate updates, stable performance, consistent traceability, and controllable costs" for enterprise online health check diagnostic reports. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the module structure of the online physical examination diagnosis report generation system for enterprises according to the present invention.

[0037] Figure 2 This is a schematic diagram of the overall process of the method of the present invention (S1-S6).

[0038] Figure 3To execute trajectory T records, construct dependency graph G, and calculate minimum dependency closure D and dependency fingerprint V. D The generated flowchart.

[0039] Figure 4 To map the configuration change set Δ to the dependency graph G and perform incremental impact analysis, the set of affected segments is obtained. A schematic diagram.

[0040] Figure 5 For the fragment set P i A diagram illustrating the organizational structure of cache key K and fragment list M, as well as the page assembly relationship based on the list.

[0041] Figure 6 A timing / state diagram for concurrent consistency control, verification digest validation, and atomic switching of inventory pointers. Detailed Implementation

[0042] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0043] I. Terminology and Symbol Conventions

[0044] For ease of understanding, the key terms used in this invention are explained as follows:

[0045] 1. Enterprise Identifier: An ID used to uniquely identify an enterprise entity, which can be a database primary key, a unified social credit code mapping value, or a UUID generated by the platform.

[0046] 2. Medical Examination Classification Label: Used to identify the medical examination scenario / questionnaire type, such as "financial health", "compliance and risk control", "operational capability", etc., which can be a classification code.

[0047] 3. Questionnaire configuration objects: refers to the configuration set that supports a certain physical examination category, including at least: question set and indicator mapping, scoring rules, threshold segmentation, diagnosis certificate template, template fragment set, and SEO meta information set.

[0048] 4. Structured Diagnostic Result Object R: The structured results output from this enterprise health check, including at least the total score, sub-indicator scores, diagnostic level, risk items, recommendation items and their source index.

[0049] 5. Execution Trajectory T: "Runtime Evidence" generated during the diagnostic calculation process, including at least: triggered indicator identifier, hit threshold segment identifier, entered scoring rule branch identifier, referenced template fragment identifier, referenced SEO field identifier, and (optional) attachment summary reference identifier.

[0050] 6. Dependency Graph G: A directed graph constructed based on the execution trajectory T. Nodes represent dependent elements (metrics / threshold segments / rule branches / template fragments / SEO fields / attachment summaries, etc.), and edges represent runtime dependencies (e.g., "metric trigger → ...).

[0051] (Referencing template fragments).

[0052] 7. Minimal Dependency Closure D: The minimum set of dependencies required for this output from the dependency graph G, which determines the minimum set of nodes and its closure for this diagnostic report output.

[0053] 8. Relying on fingerprint V D The fingerprint is obtained by performing normalized summary calculation on the version components of each dependency element in D, and is used to reflect "the version status of the current output dependency".

[0054] 9. Static resource fragment P i The diagnosis report page consists of multiple independently cacheable and updatable page segments, such as the rating summary segment, risk item segment, suggestion segment, header SEO segment, and consultation entry segment.

[0055] 10. Manifest (M): The sole basis for external publishing and page assembly, containing at least the cache key K and the fragment identifier set id (P). i ), fragment or list verification summary, publication timestamp, etc.

[0056] 11. Cache Key K: The index key of this diagnostic report (or a collection of its fragments) in cache / static storage, consisting of at least the enterprise identifier, the physical examination category identifier, and the dependency fingerprint V. D constitute.

[0057] 12. Change Set Δ: The "set of change elements" generated by updating the questionnaire configuration object, such as adjusting a threshold segment, changing the weight of a rule branch, redesigning a template fragment, updating an SEO field, etc.

[0058] 13. Set of affected segments The set of fragments that need to be failed / re-rendered is obtained by mapping Δ to the dependency graph G and performing incremental impact analysis.

[0059] 14. Single-Execution Mechanism / Lease Lock: For concurrent re-rendering requests with the same cache key K, ensure that only one execution task performs recalculation and writing at any given time, while other requests wait or reuse the old list to prevent cache breakdown and duplicate calculation.

[0060] II. System Structure

[0061] like Figure 1 As shown, the system of the present invention may include at least the following modules (modules may be deployed within the same server process or split into microservices; implementation may employ HTTP / HTTPS interfaces or RPC):

[0062] 1. Questionnaire Configuration Management Module: Stores and maintains the question bank, indicator mapping, scoring rules, threshold segmentation, diagnostic templates, template fragments, and SEO metadata. Each configuration release generates configuration version information and outputs a change set Δ (e.g., a list of change element IDs obtained based on difference comparison).

[0063] 2. Diagnostic Calculation and Trajectory Recording Module: Collects response data, behavioral data (optional), and attachments (optional), and generates structured results R in segments according to scoring rules and thresholds. During the calculation process, it records the execution trajectory T (including indicator triggering, threshold hitting, rule branch entry, template fragment referencing, SEO field referencing, etc.).

[0064] 3. Dependency Graph Construction and Closure Calculation Module: Constructs a dependency graph G based on the execution trajectory T, and calculates the minimum dependency closure D for the output target (e.g., "Diagnosis Report Homepage", "Risk List", "Recommendation Page"). Calculates the dependency fingerprint V based on D. D This is used for cache key generation and differential updates.

[0065] 4. Fragmented Static Rendering and Manifestation Module: Renders the structured result R into multiple static resource fragments P. i This generates a fragment list M. M is then used as the assembly basis for external release, and an atomic switch to the new list is employed to avoid version conflicts.

[0066] 5. Reverse Index and Incremental Impact Analysis Module: Establishes a reverse index of "Configuration Elements—Dependency Graph Nodes—Fragments" for quickly locating the impact scope of configuration changes. Maps the change set Δ to the dependency graph node set G, and performs incremental impact analysis to obtain... Differential failure and local re-rendering are performed only on the affected segments.

[0067] 6. Concurrency Consistency Control Module: Enables single-flight mechanism or lease lock for re-rendering of the same K; performs checksum verification on the new list M′ (or fragment set), and writes it to the cache / static storage and publishes it after successful verification.

[0068] 7. Optional modules: Consultation data and expert report module, SMS notification module, log auditing module.

[0069] III. Overall Technical Route for Implementing the Method of the Invention

[0070] like Figure 2 As shown, the method of the present invention can be implemented according to S1-S6:

[0071] S1: Login / Company Information and Category Selection → Load Questionnaire Configuration Object → Output Questionnaire Page and Collect Responses and Attachments.

[0072] S2: Diagnostic calculation generates R and records the execution trajectory T.

[0073] S3: Construct a dependency graph G based on T and calculate the minimum dependency closure D to obtain the dependency fingerprint V. D .

[0074] S4: Rendering fragment P i It also generates a fragment list M, which is published atomically to prevent cross-platform issues.

[0075] S5: Map the change set Δ to G and perform incremental impact analysis to obtain... Only affected segments experience differential failures and local re-rendering.

[0076] S6: Enable single flight / lease for the same K and perform verification digest validation to prevent breakdown and semi-finished product contamination.

[0077] The following will explain the steps in detail, with a focus on fully elaborating on the steps that have a high contribution rate.

[0078] S1: Configuration Loading, Questionnaire Output, and Data Collection

[0079] 1. Establishment of user and enterprise information

[0080] The user submits their mobile phone number / account password / third-party login credentials, and the server generates a session token after verification through the authentication module. When a user enters a specific health check category for the first time, they submit basic company information (company name, industry, size, region, etc.). The company information is written to the Enterprise table and the company identifier (eid) is returned.

[0081] 2. Load the questionnaire configuration object

[0082] The server reads the questionnaire configuration object from the configuration center based on the physical examination classification identifier (cid). The configuration object can be designed with the following structure:

[0083] 1) Question bank: Questions = q j Each question includes a question ID, question stem, options, validation rules, and associated indicator mapping;

[0084] 2) Indicator Mapping: Map(q) j →ind k ;

[0085] 3) Scoring rules: Rule set = r m It can contain branching structures and weights;

[0086] 4) Threshold segmentation: Thresholds = θ u Used for rating determination and suggestion generation;

[0087] 5) Template fragments: Fragments = f s Each fragment contains rendering placeholders and styles;

[0088] 6) SEO meta information: SEO = title, desc, keywords, schema...

[0089] 3. Questionnaire output and response collection

[0090] The platform can be accessed via H5, mini-programs, or PC Web. To ensure cross-platform compatibility, it is recommended that each question return a unified JSON description (question type, options, validation, hints, and redirection conditions), which will be rendered by the front-end component. Answers can be submitted either sequentially or in segments, with the server writing the answers to the Answer table and recording the timestamps.

[0091] 4. Attachment Collection (Optional)

[0092] For scenarios requiring the uploading of financial statements, scanned copies of contracts, etc., the front-end uploads attachments in the designated question or document area. The server performs format whitelist and size threshold checks (e.g., PDF / JPG / PNG, size <20MB, etc.). Once approved, the attachment is stored in object storage and the attachment ID and summary are returned (see S2 / S5 for details).

[0093] S2: Generate a diagnostic result object R and record the execution trajectory T.

[0094] S2 is one of the key steps in this invention: not only does it output the result R, but more importantly, it forms a reusable "execution trajectory T" during the calculation process, providing a basis for subsequent dependency graph G, closure D and incremental updates.

[0095] 2.1 Generation of Structured Diagnostic Result Object R

[0096] 1) Calculation of basic score

[0097] The system calculates the total score and sub-item scores based on the question mapping and scoring rules. A three-tiered structure of "Question Contribution → Indicator Aggregation → Total Score Unification" can be adopted.

[0098] Contribution to each problem: For each problem qj According to answer a j Calculate the score s of the question by mapping the scoring. j ;

[0099] Indicator aggregation: each indicator's ind k Summarize the scores of related questions and multiply them by the weight w k The index score S was obtained. k ;

[0100] Total score: The total score S is obtained by normalizing all the scores of the indicators.

[0101] It can be expressed by the following formula:

[0102]

[0103] Parameter definition: Q k To map to the metric ind k The set of questions; s j For the title q j Score; α j,k The contribution coefficient of the topic to the indicator; w k For indicator weights; S k S represents the indicator score; S represents the total score.

[0104] 2) Threshold hit and level determination

[0105] Based on threshold segmentation θ u The total score or key indicators are used to determine the diagnostic grade (e.g., A / B / C / D or "Healthy / Warning / Risk / Severe Risk"). The formula is as follows:

[0106]

[0107] Parameter definitions: θ1, θ2, θ3 are threshold segment boundaries; S is the total score; grade is the diagnostic level.

[0108] 3) Generation of risk items and suggestions

[0109] Risk entries can be generated by combining "rule branches + threshold hits + question trigger conditions". For example: if the indicator ind k Below the threshold γ k,u Trigger risk entry t And give suggestions t It is suggested that entries can reference template fragments and explanatory text libraries to form renderable structured content.

[0110] The final R suggestion should include the following fields:

[0111] R.header: Enterprise information summary, category name, generation time;

[0112] R.score: Total score S, indicator score vector S k ;

[0113] R.grade: Grade and description;

[0114] R.risks: A list of risk items (each item includes the trigger reason, related indicators, recommendations, and evidence index);

[0115] R. suggestions: A list of suggestions (which can be associated with risk items);

[0116] R.refs: A "list of references" including rules, thresholds, template fragments, SEO fields, etc. (used for tracking).

[0117] 2.2 Recording mechanism for execution trajectory T

[0118] The execution trajectory T is the carrier of "runtime real dependencies" and it is recommended to record it in the diagnostic calculation module using an "event stream" approach. The event structure can be standardized as follows:

[0119] Metric trigger event: (type=IND, id=ind) k meta=value=S k ,source=Q k )

[0120] Threshold hit event: (type=TH, id=θ) u (meta = hit_range)

[0121] Rule branch entry event: (type=RB, id=r) m , meta=branch=b, conditions)

[0122] Template fragment reference event: (type=FRAG, id=f s (meta=slot=x)

[0123] SEO field reference event: (type=SEO, id=seo) p (meta=field=title / desc)

[0124] Attachment summary reference event (optional): (type=ATT, id=att) h (meta = mime, size).

[0125] The storage format of the trajectory can be:

[0126] An in-memory queue (database is stored all at once after calculation);

[0127] Alternatively, calculations can be performed and written to the "Trace" table simultaneously to handle long processes.

[0128] Recommended minimum field for trajectory:<sessionid,eid,cid,type,id,ts,meta> .

[0129] 2.3 Binding of Trajectory with Traceable Evidence

[0130] To ensure that subsequent "dependency closure D" is interpretable and auditable, it is recommended to retain an "evidence index" in R:

[0131] Each risk item t Includes evidence i ds corresponds to several event IDs in the trajectory record (e.g., a threshold hit + a rule branch entry + an indicator trigger).

[0132] Evidence can be used when rendering templates. i The DS outputs a "trigger basis" prompt, or provides it for administrator auditing in the background.

[0133] Through the above design, the output of S2 includes not only the result R, but also the trajectory T and its binding relationship with the result entries, providing a solid and feasible foundation for subsequent steps.

[0134] S3: Construct the dependency graph G, compute the minimum dependency closure D, and generate the dependency fingerprint V. D

[0135] S3 addresses the key issue of "how to obtain the minimum update range from runtime evidence." Unlike traditional coarse-grained failure analysis based on templates / URLs, this invention uses the execution trajectory T as input to construct a dependency graph G and compute the closure D.

[0136] 3.1 Construction of Dependency Graph G

[0137] 1) Definition of a node set

[0138] In the dependency graph G=(V,E), node V must include at least: index node: Threshold segmentation node: Rule branch node: Template fragment node: SEO field node: Optional attachment nodes: Output target node: (e.g., the first page of the diagnosis report, the risk list page, the recommendation page, etc.).

[0139] 2) Edge set definition (dependencies)

[0140] Edge E is generated by the causal relationship between the trajectory events and the computation process. Typical edges include:

[0141] Indicator Trigger → Rule Branch: (A certain indicator value triggers entry into a certain rule branch);

[0142] Rule Branch → Risk Entry Output:

[0143] Threshold hit → Level output:

[0144] Output → Template Fragment Reference:

[0145] Template snippet → SEO field reference: (If this segment determines the title / desc, etc.);

[0146] Attachment → Rule Branch: (If the attachment verification or summary affects a rule).

[0147] The dependency graph can be constructed as follows: traverse the event sequence in T and generate edges according to the predefined "event to edge" mapping rules; for edges that are difficult to derive directly from events, they can be actively marked in the diagnostic calculation module (for example, when entering a rule branch, its trigger index and threshold are recorded at the same time).

[0148] 3.2 Calculation of the least dependent closure D

[0149] The meaning of the minimum dependency closure D: It determines the minimum set of dependent nodes necessary for this output. One possible implementation is: using the target set of output nodes... For the target, trace back to reachable nodes and perform reduction.

[0150] Here is a general description of closure computation:

[0151] D = Reachable(G -1 ,O);

[0152] Parameter definition: G -1 This is a dependency graph inverse graph; O is the set of output target nodes; Reachable(·) is the reachability calculation function; D is the set of closure nodes.

[0153] Furthermore, to meet the "minimum" requirement, D can be reduced: if a node makes no actual contribution to the output (e.g., a rule branch does not produce any output entries), it is removed from D. This can be implemented using "output reference counting" or "contribution marking": when generating R, the rule / threshold / metric ID referenced by each output entry is recorded, and only the referenced nodes are retained during closure reduction.

[0154] 3.3 Reliance on fingerprint V D The generation

[0155] Relying on fingerprint V D The output should reflect the version status that this output depends on. Specific implementation details:

[0156] 1) Version component extraction

[0157] For each node v in D, take its version component ver(v). The version component can be the configuration center version number, git commit number, release timestamp, or content hash.

[0158] 2) Normalization and Summary Calculation

[0159] Will<type(v),id(v),ver(v)> Sort the strings lexicographically, concatenate them into a canonical string, and then extract the hash. The formula is as follows:

[0160] V D =Hash(Join(Sort(<type(v),id(v),ver(v)> |v∈D)));

[0161] Parameter definitions: Sort for sorting; Join for concatenation; Hash for hash function (e.g., SHA-256); V D It relies on fingerprints.

[0162] The technical effect of this is that as long as the version of any dependent element in D changes, V... D Changes in D drive changes to cache key K and differential updates; conversely, if a change does not affect D, then V... D This remains unchanged, allowing for cache reuse.

[0163] S4: Fragmented Rendering P i Generate list M and publish it atomically.

[0164] S4 addresses the key challenge of "staticization and consistent deployment": how to avoid semantic inconsistencies caused by mixing old and new fragments under fragment caching conditions. This invention introduces a fragment list M as the sole assembly basis and achieves consistent deployment through atomic switching.

[0165] 4.1 Fragment Segmentation Strategy and Fragment Content

[0166] Fragment splitting should revolve around "update frequency and dependency differences." It should at least include:

[0167] P head : Header fragment (containing SEO meta information: title / desc / keywords / schema, etc.);

[0168] Psum : Scoring summary excerpt (showing the total score S, grade, and key indicators);

[0169] P risk Risk item fragments (risk list and evidence index);

[0170] P sugg Suggested segments (suggested items and landing actions);

[0171] Optional P consult Consultation entry / data status snippet;

[0172] Optional P footer Footer and disclaimer excerpt.

[0173] Each fragment is recommended to be output as either an HTML fragment that can be statically stored or JSON + front-end template; if SEO is emphasized, HTML fragments are preferred.

[0174] 4.2 Cache Key K and Fragment Identifier

[0175] The cache key is determined according to the claims:

[0176] K = <eid,cid,V D >;

[0177] Parameter definitions: eid is the enterprise identifier; cid is the medical examination category identifier; V D For fingerprint dependency; K is the cache key.

[0178] Fragment identifier id(P) i You can use either "fragment type + content hash" or "fragment type + version + serial number", for example:

[0179] id(P risk = risk:Hash(R.risks).

[0180] 4.3 Structure and Verification Summary of Fragment List M

[0181] List M contains at least:

[0182] MK: cache key K;

[0183] M.parts: List of fragments (type) i ,id(P i ),url i );

[0184] M.digest: Verification digest, used to verify whether the fragment set is complete and consistent;

[0185] M.ts: Publication timestamp;

[0186] Optional M.schema: Page structure schema version, used for compatibility with multi-platform assembly.

[0187] The verification digest can be calculated as follows:

[0188] digest(M)=Hash(K‖Join(Sort(id(P i ))));

[0189] Parameter definitions: || is for concatenation; Hash is for digest; digest(M) is for list digest.

[0190] 4.4 Implementation of Atomic Release (Anti-Mixed Version)

[0191] The meaning of "atomic switching": When publishing externally, the page layout only recognizes the "current valid list pointer". The list switching is either completely successful or the old list remains unchanged.

[0192] Possible atomic publishing methods include (any one or a combination thereof):

[0193] Object storage + pointer file: Write the new list M′ to the object storage, and finally update the pointer file "current.json" to the address of M′ using atomic overwrite method;

[0194] Database CAS update: The manifest table records the current_manifest_id, and CAS (compare-and-swap) is used during the update to ensure concurrency safety;

[0195] Redis Atomic SET: Sets the current_manifest_key to the key of M′, using a Lua script to ensure atomic updates after verification.

[0196] When a page request arrives: first read the current manifest pointer, then assemble the fragments according to the manifest, ensuring that all fragments used in the same response come from the same manifest, and completely avoiding the mixing of old and new fragments.

[0197] S5: Mapping of Change Set Δ and Incremental Impact Analysis Based on Dependency Graph G

[0198] S5 addresses the core issue of "only updating affected fragments after configuration changes." Compared to the traditional "failure by template / URL," this step uses a dependency graph to propagate the changes and outputs...

[0199] 5.1 Modify the construction of set Δ

[0200] When a new version of the questionnaire configuration object is released, the configuration management module compares the differences between the old and new configurations and outputs a change set Δ, for example:

[0201] The threshold segmentation boundary θ2 is adjusted from 60 to 65: Δ includes TH: θ2;

[0202] The weight of rule branch r7 changes from 0.2 to 0.25: Δ includes RB: r7;

[0203] Template fragment f risk Style or field change: Δ contains FRAG: f risk ;

[0204] SEO title template change: Δ Includes SEO: title.

[0205] 5.2 Mapping Δ to Dependency Graph Nodes

[0206] Map each change element to a set of nodes Δ in G. V :

[0207]

[0208]

[0209] If the configuration change involves "question → indicator mapping", then map it to the indicator node or question node (if you include the question node in G) to ensure complete propagation.

[0210] 5.3 Incremental Impact Analysis: Propagation from Change Nodes to Fragment Sets

[0211] An achievable impact analysis: from Δ V As a set of source nodes, reachability propagation is performed on the dependency graph G to find the set of nodes that will affect the output target and template fragments, and then mapped to the fragments.

[0212] It can be described as follows:

[0213] A Δ =Reachable(G, Δ) V );

[0214] Parameter definition: A Δ For the set of affected nodes; Δ V For the set of nodes to be changed; Reachable(G, ·) represents forward reachability propagation.

[0215] The affected nodes are then mapped to a set of fragments. The mapping rules could be:

[0216] If A Δ Contains a template fragment node Then the corresponding fragment P i Affected;

[0217] If A ΔIncludes a certain output node v OUT If _risk, then the risk segment P_risk is affected;

[0218] If A Δ Includes a certain SEO field node v SEO If _p, then the header segment P_head is affected.

[0219] get:

[0220]

[0221] Parameter definition: MapToParts is the mapping function from nodes to fragments; This is the set of affected segments.

[0222] Empty propagation optimization: If This means that the change will not affect the diagnostic report instance (because the closure D does not contain related dependencies or cannot propagate to the output). The system will keep the current list unchanged and prohibit triggering re-rendering to avoid invalid updates.

[0223] 5.4 Differential Failure and Local Re-rendering

[0224] right Execution of the fragment in:

[0225] Expiration: Mark the corresponding segment cache as expired or delete it (but do not leave unaffected segments untouched);

[0226] Partial re-rendering: Only the affected fragments are re-rendered, reusing the id(P) of the unaffected fragments. i ) and content;

[0227] Generate a new list M′: Assemble M′ using the old and new fragment sets and calculate the new digest(M′).

[0228] In this way, even with frequent configuration changes, the system can limit computation and rendering work to the minimum necessary scope, significantly reducing update costs.

[0229] 5.5 Impact Analysis of Annex Changes

[0230] If certain risk entries depend on the attachment summary (e.g., "Risk triggered by missing fields in uploaded report"), then the attachment summary node... Also included in G. When a user replaces the attachment, a Δ is formed (including ATT:h changes), and propagation can locate the corresponding risk output node and risk fragment, achieving the effect of "attachment change → only re-rendering risk-related fragments".

[0231] S6: Solo Flight / Lease Concurrency Control and Verification Digest Validation

[0232] S6 ensures system stability in high-concurrency and centralized change scenarios, avoiding cache breakdown, duplicate recalculation, and pollution of unfinished products.

[0233] 6.1 Key Points for Implementing Single Flight

[0234] For re-render requests with the same cache key K, the system sets either a "in progress flag" or a "lease lock". Example implementation:

[0235] When a request triggers a re-render, first attempt to acquire lock L(K), which can be stored in Redis.

[0236] SETNX L(K) successful → This request becomes the leader and performs a re-render;

[0237] SETNX failure indicates that a leader is already executing, and the current request will either enter a waiting state or return to the old list directly.

[0238] Lease locks need to have a time-to-live (TTL) expiration time to prevent deadlocks caused by abnormal leader exit. If the leader times out, other requests are allowed to preempt and retry.

[0239] 6.2 Return Strategy for Concurrent Scenarios

[0240] One of the following strategies can be adopted:

[0241] 1) Waiting strategy: The follower waits for the leader to finish and then reads the new list;

[0242] 2) Old list fallback: The follower directly returns to the corresponding page of the old list (ensuring availability) and automatically switches to the new list on the next visit;

[0243] 3) Gray-scale strategy: Return the new list to some users and the old list to the rest.

[0244] 6.3 Verification Summary Validation: Preventing contamination and cross-contamination of semi-finished products.

[0245] After the leader completes the partial re-rendering and obtains the new fragment set and the new list M′, it must perform validation:

[0246] 1) Verify that M′.K matches the expected K′;

[0247] 2) Verify that M′.parts contains the required fragment types (e.g., P). head P sum P risk P sugg );

[0248] 3) Verify that the digest(M′) matches the actual hash of the fragment (HEAD verification or content hash comparison can be performed on each fragment).

[0249] Only after the verification passes can M′ be written to static storage and atomic pointer switching be performed; otherwise, rollback is performed, the old list is retained, and audit logs are recorded for investigation.

[0250] 6.4 Caching Cycle and Release Schedule

[0251] The cache duration can be set to different TTLs for different segments:

[0252] SEO header and template snippets can be quite long (configuration changes drive updates);

[0253] Risk entry snippets can be of medium quality (to allow for updates after users provide additional information);

[0254] Consultation status segments can be relatively short (due to more frequent status changes).

[0255] Regardless of the TTL, the atomic switching of list M always ensures consistent page assembly for the same time.

[0256] Furthermore, when a company needs a consultation, users upload materials and generate an attachment summary node v. ATT _h is incorporated into the dependency graph; expert reports can be viewed as another type of "output target node v". OUT The template fragment "_consult" is included in both G and closure D, just like the SEO field. Therefore: the expert report release forms a change set Δ, and propagation can precisely locate relevant fragments of the consultation report, perform partial re-rendering, and generate a consultation list; the consultation entry fragment P... consult Updates can be made using shorter TTLs or event-driven updates to ensure timely status updates.

[0257] Furthermore, the system logs and supports retrieval of the following events: configuration change events (including Δ); closure calculation events (recording |D| and V). D Impact analysis events (records) ); Inventory release event (records M summary and switching results); Lock acquisition / release and timeout events (concurrency control); Consultation data upload and report release events.

[0258] Through the above logs, this invention can achieve full-link traceability of "why the update was made, what was updated, which segments were affected by the update, when it was released, and whether it was successful".

[0259] The following three examples demonstrate the effectiveness of the invention from the perspectives of performance, correctness consistency, and update cost.

[0260] Application Example 1:

[0261] 1) Test Objects and Environment

[0262] Physical examination classification: cid = financial literacy physical examination; question bank of 120 questions, 20 indicators, threshold segmentation of 4 levels (A / B / C / D).

[0263] Diagnosis report segment: P head P sum P risk P sugg P consult .

[0264] Enterprise Sample: N=100 enterprises that have completed physical examinations and generated diagnostic reports were randomly selected. Each enterprise corresponds to a list of diagnostic reports M and a set of fragments P. i .

[0265] Deployment: Object storage saves HTML fragments; Redis saves list pointers, cache indexes, and lease locks.

[0266] 2) Comparison Plan

[0267] Compared to A (TTL naturally expires): Full page cache TTL = 24h; after configuration changes, no precise location is performed, only waiting for the TTL to expire and then naturally updating.

[0268] Comparison B (Batch invalidation by category / template): After the configuration change, all diagnostic reports under this category become invalid and the entire page is re-rendered.

[0269] The present invention proposes the following solution: Record the execution trajectory T and construct a dependency graph G, calculate the minimum dependency closure D and the dependency fingerprint V. D Incremental impact analysis was performed after the configuration change generated Δ. Only the affected fragments are differentially disabled and locally re-rendered; released as a manifest M atomic switch.

[0270] 3) Configure the changes (forming a Δ)

[0271] Adjust the threshold segmentation: change θ2 from 60 to 65, Δ1 = TH:θ2;

[0272] Also adjust the suggested template fragments: Copywriting and fields

[0273] 4) Statistical scope and results

[0274] After constructing a dependency graph and calculating the closure D for the historical trajectories T of N=100 companies, statistics show that 27 companies have θ2 hits or contain θ2 in their closure D. Reference (i.e., Δ reachable output target node).

[0275] The set of affected fragments obtained from the propagation is mainly as follows:

[0276] Regarding the aforementioned 27 companies:

[0277] The remaining 73 companies: (Keep the original list M unchanged, and do not trigger a re-render).

[0278] The update costs of the three schemes are compared as follows:

[0279]

[0280] Technical effect conclusion: Under the same configuration change, the present invention reduces the number of "diagnostic report instances that need to be updated" from 100 in control B to 27 (a reduction of about 73%), and the update granularity changes from "whole page" to "3 fragments", which significantly reduces the pressure of re-rendering and writing, while ensuring that the configuration update takes effect in near real time and avoids the risk of outdated content caused by TTL.

[0281] Application Example 2:

[0282] 1) Problem Scenario

[0283] If the diagnostic report is statically generated in a fragmented manner, and the fragments are written one by one during the update process, and the page assembly is not constrained by the manifest, the following may occur:

[0284] P sum The new threshold indicates a change in the displayed level, but P sugg The old suggestion to use paragraph breaks is still being followed;

[0285] Inconsistencies between the SEO header and content segments can lead to discrepancies between the page's indexed information and the main text.

[0286] 2) Comparison with the present invention

[0287] Compared to C (no manifest atomic switching): Page assembly directly reads the latest cache of each fragment, and the fragments are overwritten one by one during updates.

[0288] This invention: Generates a list M = <K,id(P i ), digest(M)>, only the "current_manifest pointer" is recognized for external release, the pointer is switched to M′ atomically, and the same fragment is strictly taken during assembly.

[0289] 3) Verification methods and results (N=100)

[0290] Within a 10-minute window following the triggering of the Δ2 update, each of these 100 companies was sampled and visited 10 times, for a total of 1000 visits. The verification rules were: whether the grade level was consistent with the suggested segmentation reference; and whether the SEO title in the header was consistent with the grade level of the main text (e.g., the title contained information such as "A grade / risk").

[0291] 4) Statistical results:

[0292] The mixed version occurred 9 times out of 1000 (0.9%) in the comparison C: This is typically because the level has been updated but the suggested fragment has not been updated.

[0293] The mixed version of the present invention is 0 times / 1000 times: the assembly fragments of the same response all come from the same list M, and the list switching is atomic operation.

[0294] Technical effect conclusion: This invention eliminates the consistency defect of "mixing old and new fragments" during the update window by switching atomically in list M and verifying the digest, thereby improving the semantic consistency of diagnosis and the traceability of audit.

[0295] Application Example 3:

[0296] 1) Hotspot concurrency conditions (an example out of N=100)

[0297] One company was selected from 100 companies as a hot topic (eid). * (For example, frequent sharing), short-term peak access reaches QPS=60 (a common level for small-scale systems or single-node load testing). Simultaneously triggering configuration change Δ2, a partial re-rendering of the enterprise diagnostic report is required.

[0298] 2) Comparison with the present invention

[0299] Compared to D (no solo flight / lease): After the cache expires, each concurrent request triggers a re-render write.

[0300] This invention: For the same cache key K * Enable lease-lock / single-fly mechanism, allowing only one leader to perform re-rendering, while other requests wait or return the old list; after the leader completes, digest(M′) is validated before publishing.

[0301] 3) Results

[0302] Statistics are compiled within a 30-second window following the update trigger:

[0303] Compared to D: The same key re-rendering task is triggered 40+ times (concurrent repeated calculation), the p99 latency fluctuates significantly, and there is a probability event of "missing fragments leading to blank pages" when the fragment write is interrupted.

[0304] This invention: Re-rendering tasks with the same key are triggered once (leader), and other requests either wait for switching or return the old manifest to ensure availability; if the manifest summary verification fails, it is rolled back and not published, and no blank pages / half-finished product pollution occurs.

[0305] Technical Results: This invention effectively reduces the risk of cache breakdown by suppressing concurrent recalculation surges through single-flight / lease operations; and improves service stability and consistency during update windows by avoiding the release of incomplete fragments through manifest digest verification and atomic switching.

[0306] As demonstrated by the three examples above, under the condition of enterprise sample size N=100, this invention can construct a dependency graph G based on the execution trajectory T and calculate the minimum dependency closure D, so that the configuration change set Δ, after incremental impact analysis, only triggers the set of affected fragments. The differential failure and local re-rendering significantly reduce unnecessary recalculation and writing; at the same time, strong consistency of fragment assembly is achieved through atomic switching of list M, avoiding the mixing of old and new fragments during the update window; and hot spot concurrent recalculation and the release of semi-finished products are suppressed by single flight / lease and digest verification mechanism, ultimately achieving comprehensive improvement in "update efficiency, page consistency, high concurrency stability and traceability".

[0307] The foregoing description of embodiments of the present invention, through which those skilled in the art are able to implement or use the present invention, will be readily apparent to those skilled in the art. Various modifications to these embodiments will be readily apparent to those skilled in the art. The general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novelty disclosed herein.

Claims

1. A method for generating an online health check report for an enterprise, characterized in that, The method includes the following steps: S1) Receive the enterprise identifier and selected physical examination category identifier submitted by the user after registration and login, load the questionnaire configuration object corresponding to the physical examination category, the questionnaire configuration object includes at least a set of questions and their indicator mapping, scoring rules, threshold segmentation, diagnosis certificate template, template fragment set and SEO meta information set; output the questionnaire page to the terminal and collect user answers and attachment materials; S2) Perform diagnostic calculations on the responses according to the scoring rules to generate structured diagnostic result objects. And record the execution trajectory during the diagnostic calculation process. The execution trajectory It includes at least: the triggered metric identifier, the hit threshold segment identifier, the entered scoring rule branch identifier, the referenced template fragment identifier, and the referenced SEO field identifier; S3) Based on the execution trajectory Building a dependency graph and from The minimum dependency closure of this diagnosis report was calculated. ,in At least a closure set containing the aforementioned indicator identifier, threshold segment identifier, rule branch identifier, template fragment identifier, and SEO field identifier; Dependency fingerprints are obtained by normalizing and summarizing the version components of each dependency element. ; S4) Based on the diagnostic report template, the diagnostic results object... Rendered as a collection of multiple independently cacheable static resource fragments. and generate a list of fragments. ,in At least include cache keys Fragment identifier set And to or Verification summary; when publishing diagnostic report page resources externally, use a list of fragments. This serves as the sole basis for assembly and switches to the new list atomically to avoid mixing old and new fragments; S5) Construct a reverse index of "configuration element - dependency graph node - fragment", and generate a change set when a change in the questionnaire configuration object is detected. At that time, Mapping to dependency graph A set of nodes, executing based on Incremental impact analysis to determine the set of affected fragments Only for Perform differential invalidation and local re-rendering on the corresponding fragments and generate a new fragment list. Unaffected segments are kept cached and reused; S6) For the same cache key Concurrent re-rendering requests should enable a single-flight mechanism or lease lock to ensure that only one re-rendering task is allowed to execute at a time; before writing to the cache / static storage and publishing a new manifest, [the following should be done]. Perform the verification digest verification, and only after passing the verification can the release be allowed and the cache period be updated.

2. The method according to claim 1, characterized in that, The dependency graph The graph is a directed graph, whose nodes include at least indicator nodes, threshold segmentation nodes, rule branch nodes, template fragment nodes, and SEO field nodes. Edges represent dependencies such as "diagnostic calculation trigger," "threshold hit," "rule branch entry," "template fragment reference," or "SEO field reference." The minimum dependency closure... It is obtained by performing reachability calculation or closure reduction on the target output node.

3. The method according to claim 1, characterized in that, The incremental impact analysis includes: [the analysis of] the change set The corresponding nodes are used as the source set in the dependency graph. Perform propagation computation to obtain the set of affected nodes, and map the set of affected nodes to the set of affected fragments. Maintain the current fragment list when the propagation result is empty. It remains unchanged and prevents re-rendering.

4. The method according to claim 1, characterized in that, The set of static resource fragments It includes at least a rating summary fragment, a risk item fragment, a suggestion fragment, and a page header fragment; the page header fragment contains the SEO metadata and is included with the fragment list. Released atomically together.

5. The method according to claim 1, characterized in that, During the attachment upload phase, the file format whitelist and size threshold are checked, and a file digest is generated as the execution trajectory. Part of or as a dependency graph The node; when an attachment change causes a corresponding node change, the incremental impact analysis determines the set of affected segments, including at least the risk entry segments associated with the attachment. .

6. The method according to claim 1, characterized in that, When the list of diagnosis reports When the release is completed, when a differential failure triggers a local re-render, or when a user submits consultation materials or an expert report for release, the SMS interface is called to send a status notification message to the user and / or the platform.

7. A system for generating online health check reports for enterprises, characterized in that, The system is used to implement the method according to any one of claims 1-6, comprising: The questionnaire configuration management module is used to maintain the question set and indicator mapping, scoring rules, threshold segmentation, diagnosis certificate template, template fragment set and SEO meta information set according to physical examination category, and output the configuration change set. ; The diagnostic calculation and trajectory recording module is used to collect user responses and attachments, and generate structured diagnostic result objects. And record the execution trajectory ; The dependency graph construction and closure calculation module is used to calculate based on execution trajectories. Building a dependency graph And calculate the least dependent closure. and fingerprint-dependent ; The Fragmented Static Rendering and Manifestation module is used to generate collections of static resource fragments. and a list of segments And publish the list atomically to avoid version conflicts; The reverse index and incremental impact analysis module is used to analyze change sets. Mapping to Dependency Graph Incremental impact analysis was performed to determine the set of affected segments. and to Perform differential failure and local re-rendering; The concurrency consistency control module is used for the same cache key. Enable stand-alone mechanism or lease lock and perform validation summary verification on the list before publication.

8. The system according to claim 7, characterized in that, The system also includes a consultation data and expert report module, which is used to perform format and size limit verification on the consultation data uploaded by users and generate file summaries, distribute consultation data to experts and receive expert reports; the expert reports are generated by the fragmented static rendering and list module to generate consultation report fragments and consultation report lists, and are uniformly updated by the incremental impact analysis and differential failure mechanism; And / or, the system also includes a log auditing module for recording login, configuration changes, differential failures, partial re-rendering, list publishing and consultation data / report publishing events, and supports retrieval and tracking by enterprise identifier, physical examination category identifier, operation type and date range.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the method of any one of claims 1–6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the method of any one of claims 1–6.

Images