A method for combined evaluation of human scoliosis and posture based on image model

Abstract

The present application relates to the technical field of medical health information processing and human posture screening, and particularly relates to a human scoliosis and posture combined evaluation method based on an image model. The method acquires a back image, subject metadata records and rule records, generates scoliosis curvature estimation information, posture feature records and combined evaluation evidence records, and binds image versions, model versions, metadata versions and rule versions to a screening task; matches the combined evaluation evidence records with the rule records to generate node execution plans and node admission states; generates node instances after node admission, activates the node instances according to handover confirmation records and generates state versions; generates abnormal migration records and alternative node instances when rejected, without handover confirmation or node processing timeout, and generates late result records for node processing results with inconsistent versions. The present application improves the consistency of node states and processing results in cross-medical institution screening tasks.

Description

Technical Field

[0001] This invention relates to the fields of medical and health information processing and human posture screening technology, and in particular to a method for joint assessment of human scoliosis and posture based on image models. Background Technology

[0002] In the field of medical and health information processing, existing methods for screening scoliosis typically acquire images of the subject's upright or flexed back using image acquisition devices. Image models are then used to identify the back region, shoulder region, trunk midline, and spinal characteristic curves. Shoulder height data, shoulder angle, back symmetry, back balance, or trunk rotation angle are calculated, and based on this, scoliosis detection results, posture assessment tables, or comprehensive screening reference values ​​are generated. For screening subjects requiring hospital review, existing medical information systems can also establish process nodes based on the screening results, sending patient medical records or referral request information to the medical institution's terminal and receiving hospital review results or subsequent follow-up information.

[0003] Existing solutions often process screening results based on preset assessment thresholds, fixed process nodes, or manually configured referral rules. When back images, image models, subject metadata records, or rule records are updated, different process nodes may call different versions of the data; if necessary inputs are missing or the input versions are inconsistent, subsequent process nodes may still enter a pending state. When transferring node instances across medical institutions, there is no clear distinction between when the task has been sent and when the medical institution's terminal has received it. The node processing period may be recorded from the time the task is sent, making it difficult to correspond to the actual reception time of the medical institution's terminal.

[0004] In scenarios where multiple medical institution terminals asynchronously process the same screening task, the target medical institution terminal may return a rejection status, fail to return a handover confirmation record within the specified time, or fail to submit the node processing result by the node deadline after receiving the node instance. When the original medical institution terminal submits the processing result at a later time, there may also be a state conflict with the processing result of the reassigned node, resulting in inconsistencies between the node's valid state, the current processing result, and subsequent processes. Therefore, it is necessary to address the difficulty in maintaining consistency between node states and node processing results during asynchronous processing across medical institutions, focusing on screening tasks corresponding to the joint assessment of scoliosis and posture. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for jointly assessing human scoliosis and posture based on an image model, comprising:

[0006] S100. Acquire back images, subject metadata records, and rule records; generate spinal curvature prediction information and postural feature records based on the back images; bind image version, model version, metadata version, and rule version identifiers to the screening task to generate joint evaluation evidence records;

[0007] S200: Match the joint evaluation evidence record with the rule record corresponding to the rule version identifier to determine the effective rule set and generate a node execution plan; generate a node admission status based on the status of the preceding node, the completeness status of the necessary inputs, and the version consistency status.

[0008] S300: When the node admission status is executable, generate a node instance and send it to the medical institution terminal; receive a handover confirmation record that meets the reception receipt conditions, activate the node instance and generate a status version; receive the node processing result carrying the status version, update the node status and generate a status transition record when the verification is successful.

[0009] S400: When the medical institution terminal returns a rejection status, fails to return the handover confirmation record, or the node processing times out, an abnormal migration record and a replacement node instance are generated, and the valid status of the node instance is updated; for node processing results whose status version is inconsistent with the current status version, a late result record is generated and the current node status is not updated.

[0010] Furthermore, the back image includes upright image detection information and bent image detection information;

[0011] Image quality status is generated based on the upright image detection information and the curved image detection information, respectively.

[0012] The image quality status is composed of sharpness, back area integrity, occlusion status, and effective acquisition posture.

[0013] A re-acquisition task is generated when the image quality status does not meet the image model admission criteria.

[0014] Furthermore, the recorded body posture features include shoulder height data, shoulder angle, back symmetry, and back balance.

[0015] Based on the upright image detection information, the shoulder region and the torso midline are extracted, and the shoulder height data and shoulder angle are calculated;

[0016] The trunk rotation angle is generated based on the bending image detection information, and the trunk rotation angle is written into the spinal curvature prediction information.

[0017] Furthermore, the target rule version is determined based on the creation time of the screening task, the effective time of the rule recorded in the rule record, and the scope of application of the rule;

[0018] Bind the rule version identifier of the target rule version to the screening task;

[0019] When the node status of the screening task is not closed, the rule record is obtained according to the target rule version.

[0020] Furthermore, the joint evaluation evidence record and the subject metadata record are matched with multiple evaluation threshold conditions in the target rule version to generate a candidate rule set;

[0021] The candidate rule set is filtered according to rule priority;

[0022] For candidate rules with mutual exclusion relationships, retain the candidate rule with the higher priority.

[0023] The set of effective rules is determined according to dependencies.

[0024] Furthermore, the node execution plan includes the target process node, the preceding node, the necessary inputs, the operating role, the organizational capability conditions, the receipt conditions, the node deadline and the state transition conditions.

[0025] When the node status of the preceding node is completed, the input status of the necessary input is complete, the version of the necessary input is consistent with the version bound in the screening task, the role permissions of the operating role are valid, and the medical institution terminal meets the institution capability conditions, the node access status is marked as executable.

[0026] Furthermore, the node instance includes a node instance identifier, a screening task identifier, a sending sequence number, an idempotency identifier, a receipt deadline, a node deadline time, and a status version;

[0027] The handover confirmation record includes the node instance identifier, reception status, reception time, and reason for rejection.

[0028] When the receiving status is "receiving", the receiving time is recorded as the node start time;

[0029] A valid state is maintained for node instances with the same idempotent identifier.

[0030] Furthermore, when the current time exceeds the receipt period and the handover confirmation record is not received, the receipt status is rejected, or the current time exceeds the node deadline and the node status is not completed, the abnormal migration record is generated.

[0031] Based on the institution's capability conditions, another medical institution's terminal is matched, the alternative node instance is generated, and the original node instance is marked as replaced.

[0032] Update the state version of the replacement node instance to the current state version.

[0033] Furthermore, the hospital's review results are received, and the hospital's review results are associated with the joint assessment evidence record;

[0034] Compare the predicted spinal curvature information with the hospital's review results to generate a pre-assessment-review difference record;

[0035] Generate review cycle records and review tasks based on the hospital's review results and review rule version;

[0036] Generate a record associated with the review task, including the screening task identifier, the hospital review result identifier, and the review rule version.

[0037] Furthermore, when generating the joint evaluation evidence record, node execution plan, node processing receipt, state transition record, abnormal transition record, or late result record, a corresponding audit record is generated.

[0038] The audit log includes screening task identifier, node instance identifier, input version summary, output version summary, rule version identifier, status version, operation subject, device identifier, and previous record summary;

[0039] Associate the summary of the preceding record of the current audit record with the previous audit record.

[0040] The following are its main beneficial effects:

[0041] (1) To address the issue that different versions of back images, subject metadata records, or rule records may be called at different process nodes, the version binding of screening tasks and the verification of the complete status and version consistency of necessary inputs are used to ensure that the node execution plan and node access status correspond to the same joint evaluation evidence record and rule version, thereby reducing node status connection errors caused by missing input records or version inconsistencies.

[0042] (2) To address the difficulty in distinguishing between the state of a node instance that has been sent and the state of a medical institution terminal that has been received, the node activation, node start time and state version are controlled by the handover confirmation record, so that the node processing period corresponds to the actual receiving state of the medical institution terminal, and the node processing result corresponds to the state version when it receives the task.

[0043] (3) To address the issues of medical institution terminal rejection, handover confirmation timeout, node processing timeout, and delayed submission of results by the original node, an alternative node instance is generated through abnormal migration records, and the effective status and current status version of the original node instance are updated synchronously; the node processing result corresponding to the old status version is recorded as a delayed result, without changing the current node status corresponding to the alternative node. Attached Figure Description

[0044] Figure 1 A flowchart illustrating a method for jointly assessing human scoliosis and posture based on an image model, provided in an embodiment of this application.

[0045] Figure 2 This is a structural block diagram of a method for jointly assessing human scoliosis and posture based on an image model, provided in an embodiment of this application. Detailed Implementation

[0046] Example 1: Refer to Figure 1 This is a flowchart illustrating a method for jointly assessing human scoliosis and posture based on an image model, provided by an embodiment of the present invention. The flowchart may include at least steps S100-S400:

[0047] S100. Acquire back images, subject metadata records, and rule records; generate spinal curvature prediction information and postural feature records based on the back images; bind image version, model version, metadata version, and rule version identifiers to the screening task to generate joint evaluation evidence records;

[0048] S200: Match the joint evaluation evidence record with the rule record corresponding to the rule version identifier to determine the effective rule set and generate a node execution plan; generate a node admission status based on the status of the preceding node, the completeness status of the necessary inputs, and the version consistency status.

[0049] S300: When the node admission status is executable, generate a node instance and send it to the medical institution terminal; receive a handover confirmation record that meets the reception receipt conditions, activate the node instance and generate a status version; receive the node processing result carrying the status version, update the node status and generate a status transition record when the verification is successful.

[0050] S400: When the medical institution terminal returns a rejection status, fails to return the handover confirmation record, or the node processing times out, an abnormal migration record and a replacement node instance are generated, and the valid status of the node instance is updated; for node processing results whose status version is inconsistent with the current status version, a late result record is generated and the current node status is not updated.

[0051] S100. Acquire back images, subject metadata records, and rule records; generate spinal curvature prediction information and postural feature records based on the back images; bind image version, model version, metadata version, and rule version identifiers to the screening task to generate joint evaluation evidence records.

[0052] This step is executed in conjunction with an image acquisition device, an information acquisition module, an image evaluation module, a joint evaluation evidence generation module, and a rule version binding module. The image acquisition device is located in the image acquisition area of ​​a school group screening point, a community initial screening point, or a medical institution terminal. The information acquisition module receives the subject's identifier, back image, and subject metadata records, and reads valid rule records from the rule record storage area. The image evaluation module calls the image model corresponding to the model version to perform back region recognition, key point calibration, and posture parameter calculation on the back image. The joint evaluation evidence generation module encapsulates the output of the image evaluation module. The rule version binding module writes the actual data version and rule version identifier used in this screening into the screening task.

[0053] The back images include upright image detection information and bent image detection information. The upright image detection information is a record of the back image formed when the subject is in an upright standing posture, and its recorded content includes image identifier, acquisition time, acquisition posture, acquisition device identifier, image size, and original image storage location. The bent image detection information is a record of the back image formed when the subject is in a forward bent posture, and its recorded content includes image identifier, acquisition time, bent posture state, acquisition device identifier, and original image storage location. The upright image detection information and the bent image detection information are associated with the same subject identifier and the same screening task identifier; if either image is re-acquired, a new image version is assigned to the re-acquired image, and the original image version is retained in the screening task's history.

[0054] The subject metadata record is the subject registration record corresponding to this screening task. Its content includes subject identifier, age group, height, weight, medical history status, previous screening status, data generation time, and metadata version. The medical history status is generated by the registration terminal based on the subject's submitted medical history options; the previous screening status is generated by the information acquisition module after reading previous screening tasks based on the subject identifier. The metadata version is updated when the age group, medical history status, or previous screening status changes. When only the contact information is modified without changing the fields participating in rule matching, in one implementation, the original metadata version is maintained, and the modification time is appended to the registration record; in another implementation, the metadata version is updated for each modification to the registration record, and the rule version binding module marks the metadata version actually used in this screening.

[0055] After receiving the upright image detection information and the bent image detection information, the information acquisition module generates image quality states respectively. The image quality states consist of sharpness, back region integrity, occlusion, and effective acquisition posture. Sharpness is generated by comparing the edge response and blur level within the back region with the image model's admission criteria. Back region integrity is generated based on whether the shoulder, torso, and pelvic regions are within the image area. Occlusion is generated based on the area of ​​the back region covered by clothing, hair, or external objects. Effective acquisition posture is generated based on the subject's torso orientation, foot position, and upright or bent posture markers. When all state fields in the image quality state meet the image model's admission criteria, the image evaluation module receives the corresponding back image. If any state field does not meet the image model's admission criteria, the joint evaluation evidence generation module does not generate a valid joint evaluation evidence record but instead generates a re-acquisition task. The re-acquisition task includes the original screening task identifier, the image identifier that does not meet the admission criteria, the corresponding state field, and the re-acquisition posture.

[0056] The image evaluation module performs back region recognition on the upright image detection information, extracting the shoulder region and the torso midline from the back region; it generates shoulder height data based on the shoulder side position points in the left and right shoulder regions, and generates shoulder oblique angle based on the angle between the line connecting the two shoulder position points and the image reference direction; it generates back symmetry based on the contour position and grayscale distribution of the back regions on both sides of the torso midline; and it generates back balance based on the left-right positional relationship between the shoulder region and the pelvic region. The shoulder height data, shoulder oblique angle, back symmetry, and back balance are encapsulated into a postural feature record according to the subject identifier, screening task identifier, image version, and model version.

[0057] The image evaluation module identifies the back region based on the bending image detection information and generates a trunk rotation angle based on the left-right height changes of the back in a bending posture. In one embodiment, the image acquisition device acquires color and depth images, and the image evaluation module generates the trunk rotation angle based on the depth difference between corresponding positions on the left and right sides of the back region. In another embodiment, the bending image detection information consists of multi-angle images, and the image evaluation module generates the trunk rotation angle based on the back contour positions in multiple images. The image evaluation module generates spinal curvature prediction information based on the trunk rotation angle, the trunk midline offset state, and the spinal characteristic curve. The spinal curvature prediction information is a screening reference record formed by the body surface image and is not used as the Cobb angle measurement result on medical imaging. In one embodiment, the spinal curvature prediction information includes a Cobb angle prediction reference value, a trunk rotation angle, a spinal characteristic curve, and an evaluation confidence state. The evaluation confidence state is generated by the image quality state, the model's applicability range, and the consistency of the output of each image.

[0058] The image version includes image identifier, acquisition time, acquisition posture, and acquisition device identifier; the model version includes image model identifier, model parameter record version, applicable image type, and applicable age group; the metadata version corresponds to the subject metadata record called in this screening; the rule version identifier corresponds to the rule effective time and rule applicable scope of the rule record. When creating a screening task, the rule version binding module reads the system time, compares the system time with the rule effective and expiration times of multiple rule records, and, in conjunction with the subject's age group, source institution type, and screening scenario, obtains the target rule version from the valid rule records. After the screening task is created, the rule version identifier of the target rule version is written into the screening task; when the node status of the screening task is not closed, subsequent steps read the rule record according to the rule version identifier, and the rule version already bound to this screening task is not replaced by a new version appearing in the rule record storage area.

[0059] The joint evaluation evidence generation module encapsulates the spinal curvature prediction information, postural feature records, image quality status, image version, model version, metadata version, rule version identifier, and evidence generation time into a joint evaluation evidence record. This joint evaluation evidence record also includes a screening task identifier, subject identifier, and evaluation credibility status. After the joint evaluation evidence record is formed, the audit record module generates a corresponding audit record based on the screening task identifier, input version summary, output version summary, rule version identifier, operating entity, device identifier, and previous record summary. The input version summary is generated based on the image version, model version, and metadata version; the output version summary is generated based on the record version of the joint evaluation evidence record; the previous record summary of the current audit record is associated with the previous audit record for the same screening task.

[0060] In one specific implementation, the school group screening point obtains upright and flexed image detection information of the same subject through an image acquisition device. The image quality status shows that the back area of ​​the upright image is complete, while the flexed image is obscured by hair. The information acquisition module generates a re-acquisition task for the flexed image detection information, and the image acquisition device generates a new image version after re-acquisition. The image evaluation module calls the image model corresponding to the current model version to generate shoulder height data, shoulder angle, back symmetry, back balance, trunk rotation angle, and spinal curvature prediction information. The rule version binding module binds the re-acquisitioned image version, model version, metadata version, and target rule version to the screening task. The joint evaluation evidence generation module forms a joint evaluation evidence record accordingly. The joint evaluation evidence record and rule version identifier serve as inputs to S200. Among them, the spinal curvature prediction information, body shape feature record, and subject metadata record participate in rule condition matching, and the image version, model version, and metadata version participate in version consistency verification during node admission.

[0061] S200: Match the joint evaluation evidence record with the rule record corresponding to the rule version identifier to determine the effective rule set and generate a node execution plan; generate a node admission status based on the status of the preceding node, the completeness status of the necessary inputs, and the version consistency status.

[0062] This step is executed by the node execution plan generation module and the node access control module. The node execution plan generation module receives the joint evaluation evidence record, screening task context, and rule version identifier formed in S100, and reads the corresponding rule record from the rule record storage area according to the rule version identifier. The node access control module receives the node execution plan, the status of the preceding nodes, necessary inputs, role permissions, and the institutional capability conditions of the medical institution terminal, and verifies the execution conditions of the target process node. The screening task context in this step includes the screening task identifier, subject identifier, image version, model version, metadata version, rule version identifier, current process node, and current status version; the version field serves as the comparison benchmark for the consistency of the necessary input version status.

[0063] The rule record is a condition record configured according to the screening scenario. Its content includes rule identifier, rule version identifier, rule effective time, rule scope of application, evaluation threshold conditions, rule priority, mutual exclusion relationships, dependency relationships, target process nodes, institutional capability conditions, and state transition conditions. The evaluation threshold conditions correspond to fields in the joint evaluation evidence record; in one embodiment, the evaluation threshold conditions correspond to spinal curvature prediction information, shoulder height data, shoulder angle, back symmetry, back balance, trunk rotation angle, age group, and medical history status, respectively; in another embodiment, the evaluation threshold conditions are composed of multiple fields mentioned above, and the rule record simultaneously defines the value range and combination relationship of each field. The target process node in the rule record includes one of the following: image re-acquisition, manual review, community supplementary screening, hospital specialist review, or periodic review; the process node name is set according to the configuration record of the actual screening institution.

[0064] The node execution plan generation module reads spinal curvature prediction information, postural characteristic records, assessment credibility status, and subject metadata records from the joint assessment evidence record. It then matches each read field with the assessment threshold conditions in the target rule version. For single-field conditions, the module compares the field value with the value range in the rule record; if a match is found, the corresponding rule is written into the candidate rule set. For multi-field combination conditions, the module matches according to the combination relationship between the fields in the rule record; if all fields meet the corresponding conditions, the rule is written into the candidate rule set. For joint assessment evidence records with an invalid assessment credibility status, they are not included in the candidate rule matching of the medical institution review node; instead, the image re-acquisition rule is written into the candidate rule set.

[0065] After the candidate rule set is formed, the node execution plan generation module sorts the multiple candidate rules according to rule priority. For candidate rules with mutual exclusion, the candidate rule with higher priority is retained, and the excluded rule and its corresponding mutual exclusion relationship are written into the rule matching record. For candidate rules with dependency relationships, the dependency rule identifier is read, and the current candidate rule is written into the effective rule set only if the dependency rule is in the effective rule set or its corresponding predecessor node is in the completed state. When candidate rules have the same rule priority and mutual exclusion relationship, in one implementation, a rule conflict handling record is generated, and a node execution plan awaiting manual review is generated; in another implementation, rules with later effective times are retained according to the rule effective time order in the rule record, and the processing method is recorded in the conflict handling field of the target rule version.

[0066] After the set of effective rules is formed, the node execution plan generation module reads the target process node, preceding node, necessary inputs, operating roles, institutional capability conditions, receipt conditions, node deadlines, and state transition conditions corresponding to each effective rule, and generates a node execution plan. The target process node represents the process node that the current screening task needs to enter; the preceding node represents the process node that needs to be completed before the target process node is executed; the necessary inputs represent the records that need to be read when the target process node is processed, including joint evaluation evidence records and node processing receipts from preceding nodes; the operating roles represent the role permissions corresponding to the medical institution terminal when submitting node processing results; the institutional capability conditions represent the screening or review service types that the medical institution terminal needs to possess; the receipt conditions represent the field conditions that need to be met when the handover confirmation record is recognized as a valid received record; the node deadline represents the time boundary within which a node instance is allowed to be in the executing state after activation; and the state transition conditions represent the input records required when the node state changes from pending access, executable, pending handover confirmation, executing, or completed to the next state.

[0067] The node admission control module obtains the status of the preceding nodes based on the node execution plan, and reads the joint evaluation evidence records and the node processing receipts of the preceding nodes according to the necessary input index. It compares the actual quantity of necessary inputs with the number of records recorded in the necessary input index to generate an input completeness status. It compares the image version, model version, metadata version, and rule version identifiers in the necessary inputs with the bound versions in the screening task context item by item to generate a version consistency status. When the preceding node's node status is "complete," the input completeness status is "complete," and the version consistency status is "consistent," the node admission control module continues to read the role permissions of the operating role and the institutional capability conditions of the candidate medical institution terminal. When the operating role's role permissions are valid, and the service type, receiving status, and availability status of the medical institution terminal meet the institutional capability conditions, the node admission status is marked as executable.

[0068] When the current node status is not completed, the node admission control module marks the node admission status as pending completion of the previous node and retains the node execution plan. When necessary inputs are missing, the node admission status is marked as incomplete inputs, and an input missing record is generated, which records the missing record type and the corresponding previous node. When the version of the necessary input is inconsistent with the bound version in the screening task context, the node admission status is marked as inconsistent versions, and a version comparison record is generated without calling the new version rule to regenerate the node execution plan for the current task. When the role permissions of the operating role are invalid, the node admission status is marked as invalid role permissions. When the candidate medical institution terminal does not meet the institution capability conditions, the node admission control module matches another medical institution terminal based on the same institution capability conditions and writes the matching result into the node execution plan.

[0069] In one implementation, when a rule record is missed, the node execution plan generation module generates a node execution plan pointing to the manual review process node. The necessary inputs to this node execution plan include joint evaluation evidence records and rule miss records. In another implementation, when a rule is missed, the screening task remains at the current process node, awaiting the submission of a new rule record by the rule maintenance terminal. However, the new rule record does not directly replace the target rule version already bound to the current task. After the rule maintenance terminal completes processing, it generates a node processing receipt based on the manual review results, and then the state transition conditions control subsequent nodes. If the version of the rule record changes but the current screening task is not closed, the node execution plan generation module continues to use the rule version identifier bound to the screening task. When a review task is established after the current screening task is closed, the review task obtains the corresponding review rule version according to its creation time.

[0070] In one specific implementation, the joint assessment evidence record generated by S100 includes postural characteristic records, spinal curvature prediction information, and metadata versions. The node execution plan generation module reads the rule record according to the rule version identifier bound in the screening task, matches each assessment field with multiple assessment threshold conditions, and forms two candidate rules pointing to the community supplementary screening node and the hospital specialist review node. The two candidate rules have a dependency relationship, with the hospital specialist review node depending on the completion of the community supplementary screening node. Based on this, the node execution plan generation module generates a node execution plan that executes the community supplementary screening node first, followed by the hospital specialist review node. The node access control module verifies that the necessary inputs are complete and consistent in version, and that the candidate community medical institution terminal meets the institution capability conditions, marking the node access status of the community supplementary screening node as executable; the hospital specialist review node remains in a state awaiting completion of the preceding node.

[0071] This step ultimately forms the set of effective rules, node execution plans, and node access status, and generates corresponding audit records. The target process node, medical institution terminal, operating role, receipt conditions, node deadline, and state transition conditions in the node execution plan serve as inputs for S300 to generate node instances and verify handover confirmation records; the node access status controls whether S300 sends node instances; the necessary inputs and version consistency status continue to participate in verification when S300 receives node processing results.

[0072] S300: When the node admission status is executable, generate a node instance and send it to the medical institution terminal; receive a handover confirmation record that meets the reception receipt conditions, activate the node instance and generate a status version; receive the node processing result carrying the status version, update the node status and generate a status migration record when the verification is successful.

[0073] This step is executed by the handover processing module and the state transition module. The handover processing module receives the node execution plan and node admission status generated by S200. When the node admission status is executable, it generates a node instance based on the target process node, medical institution terminal, operator role, necessary input index, receipt conditions, and node deadline in the node execution plan. The state transition module receives the handover confirmation record and node processing results, and updates the execution status of the node instance based on its current status, status version, role permissions, and necessary outputs. When the node admission status is not executable, the handover processing module does not send the node instance but retains the node execution plan and node admission status generated by S200.

[0074] The node instance is an execution record generated for a specific screening task and target process node. Its content includes a node instance identifier, screening task identifier, target process node, target institution identifier, operator role, necessary input index, sending sequence number, idempotency identifier, receipt deadline, node deadline, and status version. The node instance identifier is formed by associating the screening task identifier, target process node, and node generation sequence number; the sending sequence number is updated according to the number of times the same node instance is sent; the idempotency identifier is generated based on the screening task identifier, target process node, and rule version identifier; the receipt deadline records the time boundary for the target medical institution's terminal to submit the handover confirmation record; and the node deadline records the completion time boundary after the node instance is in the executing state. The initial state of the node instance is pending handover confirmation, and the initial state version is written to the node instance.

[0075] The handover processing module sends the node instance, the necessary input index, and the read address of the necessary input to the medical institution terminal. In one implementation, the necessary input itself is stored in the screening task record storage area, and the medical institution terminal reads the record after role permission verification according to the necessary input index. In another implementation, the handover processing module sends the structured fields in the necessary input along with the node instance, and the back image is read by the medical institution terminal according to the image storage location. After the node instance is sent, the handover processing module writes the sending time and sending sequence number; duplicate sending records with the same sending sequence number are associated with an idempotent identifier, and no new valid node instance is generated.

[0076] After receiving a node instance, the medical institution terminal generates a handover confirmation record based on its institutional capabilities, the availability of operating roles, and the read status of necessary inputs. The handover confirmation record includes the node instance identifier, receiving institution identifier, receiving status, receiving time, reason for rejection, receiving terminal identifier, and confirmation record version. The receiving status includes "accepted" and "rejected." If the medical institution terminal meets the institutional capabilities, has an operating role with valid permissions, and the necessary inputs are successfully read, the receiving status is set to "accepted." If the medical institution terminal does not meet the institutional capabilities, the operating role is unavailable, or the necessary inputs cannot be read, the receiving status is set to "rejected," and the corresponding reason for rejection is written.

[0077] After receiving the handover confirmation record, the handover processing module matches the node instance identifier in the confirmation record with the sent node instance; compares the receiving organization identifier with the target organization identifier in the node execution plan; and compares the confirmation record version with the already saved confirmation record version for the same node instance. If the node instance identifier and receiving organization identifier match, the confirmation record version is not lower than the already saved confirmation record version, and the reception status is "received," the handover confirmation record meets the reception receipt conditions. The handover processing module records the reception time as the node start time, updates the node instance from "pending handover confirmation" to "in execution," and updates the status version. If the reception status is "rejected," the node instance is not activated, and the handover confirmation record enters the S400 abnormal migration processing.

[0078] For multiple node instances with the same idempotency identifier, the handover processing module reads the valid status of each node instance. If one node instance is already in an executing or completed state, the remaining node instances with the same idempotency identifier are marked as invalid. If multiple node instances are in a pending handover confirmation state, the node instance with the later sending sequence number is retained as a valid node instance, and the remaining node instances are marked as invalid. In one implementation, when a medical institution terminal repeatedly submits the same confirmation record, the handover processing module identifies the duplicate record based on the node instance identifier and the confirmation record version, retains one valid handover confirmation record, and writes the duplicate record to the audit record but does not update the node status.

[0079] After the medical institution terminal completes the operation corresponding to the target process node, it generates the node processing result. The node processing result includes a node instance identifier, a screening task identifier, a status version, an operation subject identifier, a result record identifier, a necessary output index, a completion time, and an idempotency identifier. The node processing result for the hospital specialist review node also includes a hospital review result identifier. The state transition module matches the node instance identifier in the node processing result with the current node instance, compares the screening task identifier with the screening task identifier in the node instance, compares the status version with the current status version, and reads the role permissions and necessary outputs corresponding to the operation subject.

[0080] When the status version in the node processing result matches the current status version, the operator's role and permissions are valid, and the necessary outputs are complete and the idempotency identifier matches the node instance, the state transition module updates the node status from "in execution" to "completed" according to the state transition conditions in the node execution plan; it generates a node processing receipt and a state transition record, and updates the current status version. The node processing receipt includes the node instance identifier, processing result reception status, result record identifier, receipt time, and updated status version; the state transition record includes the screening task identifier, node instance identifier, pre-migration status, post-migration status, migration time, input status version, and output status version. When necessary outputs are missing, the state transition module marks the node processing result as having incomplete outputs, and the node status remains "in execution"; when role and permissions are invalid, an invalid role and permission record is generated; when the idempotency identifier in the node processing result is inconsistent, the node status is not updated.

[0081] In one specific implementation, S200 marks the hospital specialist review node as executable. The handover processing module generates a node instance and sends it to the first medical institution terminal. The first medical institution terminal returns a handover confirmation record with a received status. The handover processing module records the receipt time as the node start time, updates the node instance to "in execution," and generates a new status version. After the hospital operator completes the medical image review, the medical institution terminal submits the node processing result carrying this status version. The status transition module verifies the status version, operator role, and hospital review result index. After successful verification, it updates the node instance to "completed," generates a node processing receipt, and a status transition record. The hospital review result identifier and the joint evaluation evidence record are linked in S400.

[0082] The node instances, handover confirmation records, status versions, node processing receipts, and status transition records generated in this step are all associated with the screening task identifier, and audit records are generated for each. If a node instance is not accepted, the handover confirmation record indicates rejection, the node instance is not completed before the node deadline, or the status version carried by the node processing result is inconsistent with the current status version, the corresponding record is used as input to S400. The node start time, post-migration status, and current status version in the status transition record participate in S400's identification of node processing timeout and late results. The hospital review results generated by the hospital specialist review nodes are entered into S400's pre-assessment—review difference record and review task processing.

[0083] S400: When the medical institution terminal returns a rejection status, fails to return the handover confirmation record, or the node processing times out, an abnormal migration record and a replacement node instance are generated, and the valid status of the node instance is updated; for node processing results whose status version is inconsistent with the current status version, a late result record is generated and the current node status is not updated.

[0084] This step is executed by the timeout handling module, state transition module, review task generation module, and audit log module. The timeout handling module receives the node instance, handover confirmation record, node start time, node end time, node processing receipt, and state transition record generated by S300; it generates a timeout event record or abnormal migration record based on the current state of the node instance and the system time; the state transition module updates the valid state of the original node instance based on the abnormal migration record and generates a replacement node instance; the review task generation module receives the hospital's review results and joint assessment evidence record, generating a pre-assessment-review difference record, review cycle record, review task, and review task association record; the audit log module generates audit logs for abnormal migrations, late results, and the review task generation process.

[0085] When the medical institution terminal returns a rejection status, the timeout handling module reads the rejection reason from the handover confirmation record and compares it with the institution's capability conditions in the node execution plan. If the rejection reason is that the institution's capability conditions are not met, the operating role is unavailable, or the necessary input material fails to be read, an abnormal migration record is generated. The abnormal migration record includes the screening task identifier, the original node instance identifier, the abnormality type, the abnormality occurrence time, the original target institution identifier, the institution's capability conditions, the original status version, and the abnormal record version. The abnormality type is marked according to the rejection status, handover confirmation timeout, or node processing timeout; the rejection reason in the handover confirmation record is retained as an input field for the abnormal migration record.

[0086] When a node instance is in a pending handover confirmation state, and the current time exceeds the acknowledgment deadline in the node instance, and no handover confirmation record meeting the acknowledgment reception conditions has been received, the timeout handling module generates a handover timeout event record. In one implementation, the node execution plan records the maximum number of retransmissions; if the current transmission count has not reached the maximum number of retransmissions, the handover processing module updates the transmission sequence number and retransmits to the same node instance, keeping the idempotency flag unchanged; if the current transmission count reaches the maximum number of retransmissions, the timeout handling module generates an abnormal migration record. In another implementation, no retransmission count is set, and an abnormal migration record is directly generated when the current time exceeds the acknowledgment deadline; the processing method used is recorded by the timeout handling conditions corresponding to the rule version identifier.

[0087] When a node instance is in the "in execution" state, the timeout handling module reads the current time based on the node's start and end times. If the current time exceeds the node's end time and no state transition record indicating the node's status as "completed" has been generated, an exception transition record corresponding to the node processing timeout is generated. If a node processing result has been generated but the necessary outputs are incomplete, the node status remains "in execution," and the node processing timeout handling begins after the node's end time is reached. If the node processing result has passed verification and the transitioned status in the state transition record is "completed," no node processing timeout record is generated. The node's end time is recorded in the node execution plan and is calculated from the reception time in the handover confirmation record after the node instance is effectively received.

[0088] After an anomaly migration record is generated, the state migration module matches another medical institution terminal from the institutional capability status records of multiple medical institution terminals based on the institutional capability conditions recorded therein. During matching, the original target institution identifier is excluded, and the service type, operational role availability status, and terminal reception status of the candidate medical institution terminals are compared. If a medical institution terminal that meets the institutional capability conditions exists, a replacement node instance is generated according to the original node execution plan. The replacement node instance inherits the screening task identifier, target process node, necessary input index, operational role, receipt conditions, and node deadline, and is assigned a new node instance identifier, sending sequence number, and idempotency identifier. The state migration module marks the original node instance as replaced and updates the status version of the replacement node instance to the current status version. Subsequently, the replacement node instance is sent to another medical institution terminal, and the handover confirmation and node processing process are executed according to S300.

[0089] When no medical institution terminal meets the institutional capability requirements, in one implementation, the state transition module generates a node instance awaiting manual review and marks the original node instance as replaced. The necessary inputs for the node instance awaiting manual review include joint assessment evidence records, abnormal migration records, and the handover record of the original node instance. In another implementation, the state transition module maintains the original node instance in an abnormal waiting state and generates a record indicating that the institutional capability conditions are not matched. When the institutional capability status of the medical institution terminal changes, the timeout handling module rereads the institutional capability status record and performs matching again. When the rule version changes, the current screening task still reads the timeout handling conditions according to its bound rule version identifier; the replacement node instance does not invoke new rule records due to rule version updates.

[0090] Even after the original node instance is marked as replaced, the medical institution terminal may still submit the original node's processing results. After receiving the node processing results, the state transition module reads the state version and node instance identifier; it compares the state version with the current state version of the screening task and reads the valid state of the node instance. If the state version carried by the node processing result is inconsistent with the current state version, or if the valid state of the corresponding node instance is replaced or invalid, the state transition module generates a late result record without updating the current node state. The late result record includes the screening task identifier, original node instance identifier, result record identifier, result state version, current state version, result reception time, and late result state; the late result record retains the necessary output indexes from the node processing results, and its record state is stored separately from the currently valid node results.

[0091] In one implementation, the node processing result in the late result record is resubmitted by the operating role to the currently valid node instance. The operating entity of the currently valid node reads the late result record, uses the necessary outputs as supplementary inputs, and generates a new node processing result according to the current state version. The new node processing result updates the node state after verification of the state version and role permissions in S300. In another implementation, the late result record is only entered into the audit record and is not used as input for the current node; the above selection is recorded by the state transition conditions. Only one valid record is retained for late result records with the same idempotency identifier, and the reception time of duplicate records is written into the audit record.

[0092] After the hospital specialist review node is completed, the review task generation module receives the hospital review results and reads the corresponding medical image review record according to the hospital review result identifier; it then associates the hospital review results with the joint assessment evidence record under the same screening task. The hospital review results include the spinal curvature value on the medical image, the scoliosis type determination result, the review time, the review institution identifier, and the hospital review result identifier; the joint assessment evidence record includes spinal curvature prediction information and postural characteristic records. The review task generation module compares the Cobb angle prediction reference value in the spinal curvature prediction information with the spinal curvature value in the hospital review results, and encapsulates the comparison difference, prediction record version, hospital review result identifier, and comparison time into a pre-assessment-review difference record; for implementations where the spinal curvature prediction information does not include the Cobb angle prediction reference value, the review task generation module compares the screening status in the spinal curvature prediction information with the scoliosis type determination result in the hospital review results, generating the corresponding pre-assessment-review difference record.

[0093] The review task generation module matches the hospital review results, patient medical record information, and review cycle conditions in the review rule version to generate a review cycle record. This record includes the hospital review result identifier, review rule version, review start time, and review time. A review task is then generated based on this record. This task includes a new screening task identifier, subject identifier, source screening task identifier, hospital review result identifier, review rule version, review time, and initial node status. The module also generates a review task association record, which includes the original screening task identifier, the screening task identifier of the review task, the hospital review result identifier, the joint assessment evidence record identifier, and the review rule version. When the review time arrives, the review task is entered as a new screening task in S100, and valid rule records are retrieved according to the task creation time.

[0094] When abnormal migration records, substitute node instances, late result records, pre-assessment-review difference records, and review task association records are formed, the audit record module generates audit records respectively. The audit record includes a screening task identifier, node instance identifier, input version summary, output version summary, rule version identifier, status version, operating entity, device identifier, and preceding record summary. The input version summary is generated based on the node instance version before the abnormal migration, the handover confirmation record version, or the hospital review result version. The output version summary is generated based on the substitute node instance version, the late result record version, or the review task association record version. The preceding record summary of the current audit record is associated with the previous audit record for the same screening task. In one embodiment, the preceding record summary is formed by calculating the field sequence of the previous audit record using a preset message digest algorithm. The original back image, hospital review result, and complete node processing result are saved according to their respective record identifiers and are not written into the summary field of the audit record.

[0095] In one specific implementation, the first medical institution terminal, after receiving the hospital specialist review node, failed to submit a complete hospital review result before the node deadline. The overdue handling module generated an abnormal migration record based on the node start time and node deadline. The status migration module matched the second medical institution terminal according to the institution's capabilities, generated a substitute node instance, marked the original node instance as replaced, and updated the current status version. After the second medical institution terminal received the substitute node instance and submitted the hospital review result, the status migration module updated the substitute node instance to "completed." Subsequently, the first medical institution terminal submitted the original node processing result, which carried a status version lower than the current status version. The status migration module generated a late result record but did not update the current node status formed by the substitute node. The review task generation module associated the hospital review result generated by the second medical institution terminal with the original joint assessment evidence record, generating a pre-assessment-review difference record, a review cycle record, a review task, and a review task association record.

[0096] The abnormal migration record generated in this step records the reason why the original node can no longer be a valid node; the replacement node instance is returned to S300 as a new executable object to perform handover confirmation and state migration; the late result record is saved separately from the current valid node state; the hospital review result, the pre-assessment-review difference record, and the review rule version together form the review task; after the review task reaches the review time, it enters the next round S100, and its source screening task identifier, hospital review result identifier, and review rule version serve as the historical input for the next round of screening task.

[0097] Example 2: Figure 2 A structural block diagram of a method for jointly assessing human scoliosis and posture based on an image model, according to an embodiment of the present invention, is shown. Figure 2 As shown, the structure may include:

[0098] The joint evaluation evidence generation module 01 is used to acquire back images, subject metadata records, and rule records. Based on the back images, it generates spinal curvature prediction information and postural feature records, and binds image version, model version, metadata version, and rule version identifiers to the screening task to generate joint evaluation evidence records. Specifically, the back images come from an image acquisition device, the subject metadata records come from subject registration records, and the rule records are pre-configured according to the rule effective time and the scope of rule application. After receiving the back images, the joint evaluation evidence generation module identifies the back region, extracts the shoulder region, trunk midline, and spinal feature curves, generates shoulder height data and shoulder angle based on the shoulder region, generates spinal curvature prediction information based on the trunk midline and spinal feature curves, and writes the shoulder height data, shoulder angle, back symmetry, and back balance into the postural feature records. The generation module retrieves the valid rule version identifier from the rule record based on the creation time of the screening task, and associates the image version, model version, metadata version, and rule version identifier actually involved in the processing with the screening task. The joint evaluation evidence record includes the screening task identifier, spinal curvature prediction information, body posture record, image version, model version, metadata version, and rule version identifier. When the back image does not meet the image model admission criteria, the joint evaluation evidence generation module generates a re-acquisition task and does not output a valid joint evaluation evidence record. The joint evaluation evidence generation module provides the joint evaluation evidence record and the rule version identifier to the node execution plan generation module. The spinal curvature prediction information, body posture record, and subject metadata record serve as inputs for rule matching, while the image version, model version, and metadata version serve as inputs for version consistency verification.

[0099] The node execution plan generation module 02, connected to the joint evaluation evidence generation module, is used to match the joint evaluation evidence records with the rule records corresponding to the rule version identifier, determine the effective rule set, and generate a node execution plan. It generates node admission status based on the status of preceding nodes, the completeness status of necessary inputs, and the version consistency status. Specifically, the node execution plan generation module receives the joint evaluation evidence records and rule version identifiers output by the joint evaluation evidence generation module, calls the corresponding rule records according to the rule version identifier, and reads the spinal curvature prediction information, postural characteristic records, and subject metadata records from the joint evaluation evidence records. The node execution plan generation module matches the read fields with the evaluation threshold conditions in the rule records, writes the rule records that meet the evaluation threshold conditions into the candidate rule set, filters the candidate rule set according to rule priority, retains the rule records with higher priority for mutually exclusive rule records, and determines the effective rule set according to dependencies. The node execution plan generation module reads the target process node, preceding nodes, necessary inputs, operating roles, institutional capability conditions, and connection points based on the effective rule set. The node execution plan generation module retrieves the execution conditions, node deadlines, and state transition conditions, and encapsulates the reading results into the node execution plan. The node execution plan generation module reads the corresponding records based on the record identifiers of the necessary inputs, compares the actually read records with the necessary inputs recorded in the node execution plan, generates the complete state of the inputs, and compares the image version, model version, metadata version, and rule version identifiers in the necessary inputs with the corresponding versions bound to the screening task, generating the version consistency state. When the preceding node state is completed, the input complete state is complete, and the version consistency state is consistent, the node execution plan generation module marks the node admission state as executable. When the preceding node state is incomplete, the necessary inputs are missing, or the versions are inconsistent, the node execution plan generation module records the corresponding state and keeps the node admission state as non-executable. The node execution plan generation module provides the node execution plan and node admission state to the handover processing and state transition module, with the target process node, institutional capability conditions, receipt conditions, node deadlines, and state transition conditions serving as inputs for node instance generation and node state updates.

[0100] The handover processing and state transition module 03, connected to the node execution plan generation module, is used to generate a node instance and send it to the medical institution terminal when the node's admission status is executable; receive a handover confirmation record that meets the receipt receipt conditions; activate the node instance and generate a status version; receive the node processing result carrying the status version; and update the node status and generate a state transition record when the verification passes. Specifically, the handover processing and state transition module receives the node execution plan and node admission status output by the node execution plan generation module. When the node's admission status is executable, it processes the node instance according to the target process node and necessary parameters in the node execution plan. The node instance is generated based on input materials, operating roles, institutional capability conditions, receipt conditions, and node deadlines. The node instance includes a node instance identifier, screening task identifier, sending sequence number, idempotency identifier, receipt deadline, node deadline, and status version. The handover processing and status transition module sends the node instance to a medical institution terminal that meets the institutional capability conditions and records the node instance's status as pending handover confirmation. The medical institution terminal generates a handover confirmation record based on the receiving status, receiving time, and rejection reason. The handover processing and status transition module compares the node instance identifier in the handover confirmation record with the previously sent... The node instance is matched, and the receiving status is compared with the receiving receipt condition. When the handover confirmation record meets the receiving receipt condition, the handover processing and state transition module records the receiving time as the node start time, updates the node status of the node instance to "in execution," and generates a status version corresponding to the node instance. After the medical institution terminal completes the processing corresponding to the target process node, it submits a node processing result containing a node instance identifier, screening task identifier, status version, necessary outputs, and idempotency identifier. The handover processing and state transition module compares the status version carried in the node processing result with the current status version. The system compares and verifies the operation roles, necessary outputs, and idempotency identifiers. When the state versions are consistent, the operation roles have valid permissions, the necessary outputs are complete, and the idempotency identifiers are consistent, the handover processing and state transition module updates the node state according to the state transition conditions and generates the node processing receipt and state transition record. The handover processing and state transition module provides the abnormal migration module with the node instance, handover confirmation record, node start time, node end time, state version, and state transition record, so that the abnormal migration module can identify node processing results such as rejection status, missing handover confirmation, node processing timeout, and inconsistent state versions.

[0101] The abnormal migration module 04 is connected to the handover processing and state migration module. It is used to generate an abnormal migration record and a replacement node instance when the medical institution terminal returns a rejection status, does not return the handover confirmation record, or the node processing times out. It updates the valid status of the node instance and generates a late result record for the node processing result that is inconsistent with the current status version without updating the current node status. Specifically, the anomaly migration module receives node instances, handover confirmation records, node start times, node end times, status versions, and status migration records provided by the handover processing and status migration module. When the acceptance status in the handover confirmation record is "rejected," the anomaly migration module reads the rejection reason and generates an anomaly migration record recording the original node instance identifier, the original target institution identifier, the institution's capability conditions, the original status version, and the time of anomaly occurrence. When the current time exceeds the receipt deadline and no handover confirmation record meeting the receipt conditions is received, the anomaly migration module generates an anomaly migration record corresponding to missing handover confirmation. When the node instance is in an executing state, the current time exceeds the node's deadline, and no status migration record indicating the node status is "completed" has been generated, the anomaly migration module generates an anomaly migration record corresponding to node processing timeout. The anomaly migration module matches another medical institution terminal based on the institution's capability conditions in the anomaly migration record and generates the replacement node instance based on the node execution plan corresponding to the original node instance, updates the valid status of the original node instance to "replaced," and updates the status of the replacement node instance. The status version is updated to the current status version; the anomaly migration module returns the replacement node instance to the handover processing and status migration module, which then sends the replacement node instance to another medical institution terminal and performs handover confirmation and status migration according to the received receipt conditions; when the original medical institution terminal submits the node processing result, the anomaly migration module compares the status version carried by the node processing result with the current status version; if the two status versions are inconsistent, or if the node instance corresponding to the node processing result has been marked as replaced, the anomaly migration module generates the late result record, which includes the screening task identifier, the original node instance identifier, the result record identifier, the result status version, the current status version, and the result reception time, while keeping the current node status unchanged; the anomaly migration record, the replacement node instance, and the late result record are all associated with the screening task, and the replacement node instance enters the handover processing and status migration module to form a new handover confirmation record and a status migration record, while the late result record is recorded separately from the node processing result of the currently valid node.

Claims

1. A method for jointly assessing human scoliosis and posture based on image models, characterized in that, include: S100: Acquire back images, subject metadata records, and rule records; Based on the back image, spinal curvature prediction information and postural feature records are generated; Bind image version, model version, metadata version, and rule version identifiers to the screening task to generate joint evaluation evidence records; S200: Match the joint evaluation evidence records with the rule records corresponding to the rule version identifiers to determine the set of effective rules and generate a node execution plan; Generate node admission status based on the status of the preceding node, the completeness status of the necessary inputs, and the version consistency status; S300: When the node admission status is executable, generate a node instance and send it to the medical institution terminal; receive a handover confirmation record that meets the reception receipt conditions, activate the node instance and generate a status version; receive the node processing result carrying the status version, update the node status and generate a status transition record when the verification is successful. S400: When the medical institution terminal returns a rejection status, fails to return the handover confirmation record, or the node processing times out, an abnormal migration record and a replacement node instance are generated, and the valid status of the node instance is updated; for node processing results whose status version is inconsistent with the current status version, a late result record is generated and the current node status is not updated.

2. The method according to claim 1, characterized in that, The back image includes upright image detection information and bent image detection information; Image quality status is generated based on the upright image detection information and the curved image detection information, respectively. The image quality status is composed of sharpness, back area integrity, occlusion status, and effective acquisition posture. A re-acquisition task is generated when the image quality status does not meet the image model admission criteria.

3. The method according to claim 2, characterized in that, The recorded body posture features include shoulder height data, shoulder angle, back symmetry, and back balance. Based on the upright image detection information, the shoulder region and the torso midline are extracted, and the shoulder height data and shoulder angle are calculated; The trunk rotation angle is generated based on the bending image detection information, and the trunk rotation angle is written into the spinal curvature prediction information.

4. The method according to claim 1, characterized in that, The target rule version is determined based on the creation time of the screening task, the effective time of the rule recorded in the rule record, and the scope of application of the rule; Bind the rule version identifier of the target rule version to the screening task; When the node status of the screening task is not closed, the rule record is obtained according to the target rule version.

5. The method according to claim 4, characterized in that, The joint assessment evidence record and the subject metadata record are matched with multiple assessment threshold conditions in the target rule version to generate a candidate rule set; The candidate rule set is filtered according to rule priority; For candidate rules with mutual exclusion relationships, retain the candidate rule with the higher priority. The set of effective rules is determined according to dependencies.

6. The method according to claim 5, characterized in that, The node execution plan includes the target process node, the preceding node, the necessary inputs, the operating roles, the organizational capability conditions, the conditions for receiving receipts, the node deadline time, and the state transition conditions. When the node status of the preceding node is completed, the input status of the necessary input is complete, the version of the necessary input is consistent with the version bound in the screening task, the role permissions of the operating role are valid, and the medical institution terminal meets the institution capability conditions, the node access status is marked as executable.

7. The method according to claim 6, characterized in that, The node instance includes a node instance identifier, a screening task identifier, a sending sequence number, an idempotency identifier, a receipt deadline, a node expiration time, and a status version; The handover confirmation record includes the node instance identifier, reception status, reception time, and reason for rejection. When the receiving status is "receiving", the receiving time is recorded as the node start time; A valid state is maintained for node instances with the same idempotent identifier.

8. The method according to claim 7, characterized in that, The abnormal migration record is generated when the current time exceeds the receipt period and the handover confirmation record is not received, the receipt status is rejected, or the current time exceeds the node deadline and the node status is not completed. Based on the institution's capability conditions, another medical institution's terminal is matched, the alternative node instance is generated, and the original node instance is marked as replaced. Update the state version of the replacement node instance to the current state version.

9. The method according to claim 1, characterized in that, Receive the hospital's review results and associate the hospital's review results with the joint assessment evidence record; Compare the predicted spinal curvature information with the hospital's review results to generate a pre-assessment-review difference record; Generate review cycle records and review tasks based on the hospital's review results and review rule version; Generate a record associated with the review task, including the screening task identifier, the hospital review result identifier, and the review rule version.

10. The method according to claim 1, characterized in that, When generating the joint evaluation evidence record, node execution plan, node processing receipt, state transition record, abnormal transition record, or late result record, a corresponding audit record is generated. The audit log includes screening task identifier, node instance identifier, input version summary, output version summary, rule version identifier, status version, operation subject, device identifier, and previous record summary; Associate the summary of the preceding record of the current audit record with the previous audit record.

Images