Pelvic floor rehabilitation treatment closed-loop management method and system and storage medium

Abstract

The application discloses a kind of pelvic floor rehabilitation treatment closed loop management method, system and storage medium, comprising: positioning user and inquiring daily appointment session, verifying the binding relationship of user token, appointment session, fixed time period and stage subtoken, after verification, migrate to the state of having reported;In response to the confirmation request of nurse execution, check account validity and treatment single remaining number, after check, add execution record in transaction, migrate appointment state and increase treatment single used number;State migration event is generated audit evidence, based on audit evidence, identify repeated submission or cause and effect inversion anomaly, no exception is found, according to the value domain determined by quantitative score result to determine the treatment level and execute corresponding strategyThe application verifies the binding of user token, appointment session, fixed time period and stage subtoken, so that static two-dimensional code cannot pass verification when it is out of effective time period or stage, block abnormal reporting and repeated queuing, improve the reliability of closed loop management.

Description

Technical Field

[0001] This application relates to the field of medical data security technology, and in particular to a closed-loop management method, system and storage medium for pelvic floor rehabilitation treatment. Background Technology

[0002] Pelvic floor rehabilitation treatments are lengthy and involve numerous sessions, often managed in clinical practice using paper registration, spreadsheets, or general outpatient scheduling. This fragmented approach to user identification, remaining treatment sessions, appointment availability, and on-site check-in / actual treatment recording can easily lead to issues such as missed sessions, appointment conflicts, and inconsistent statistical methods. While some institutions use general appointment systems, these systems are not designed specifically for the characteristics of pelvic floor rehabilitation treatments and are insufficient to meet clinical management needs.

[0003] To improve management efficiency, some institutions have introduced QR code technology to assist in identity verification. A common practice is to directly encode user information or appointment details into the QR code, which users then save and present. This method allows QR codes to carry sensitive clinical information, posing a risk of privacy exposure. More importantly, once a static QR code is generated, it remains unchanged. If it is scanned outside of a valid appointment time or at an incorrect time, the system struggles to distinguish its legitimacy, potentially leading to incorrect registration or duplicate queuing.

[0004] Beyond security concerns during the check-in process, pelvic floor rehabilitation therapy also involves multiple services sharing the same equipment or therapists. If appointment slots are managed independently for each service, situations may arise where all services show available slots, but the actual number of patients exceeds the resource capacity limit. Furthermore, in cases of concurrent bookings, network replays, or service anomalies, the system typically only returns a binary result of success or failure, making it difficult to trace the business stage of a particular operation, the sequence of events, and the cause of the anomaly, lacking auditable quantitative evidence.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a closed-loop management method, system and storage medium for pelvic floor rehabilitation treatment, which aims to solve the technical problem in the existing pelvic floor rehabilitation management where static QR codes cannot be correctly identified when scanned outside of the valid appointment time or at the wrong stage, resulting in incorrect reporting or duplicate queuing.

[0007] To achieve the above objectives, this application proposes a closed-loop management method for pelvic floor rehabilitation treatment, the method comprising: In response to a user token submitted by a QR code reader, the user is located using the user token, and the user's appointment session for the current date is queried. Extract the fixed time period and current stage corresponding to the appointment session, and verify the binding relationship between the user token, appointment session, fixed time period and sub-token corresponding to the current stage based on the extraction results. After the verification is successful, the appointment status is changed to the checked-in status and the appointment is entered into the treatment queue. Based on the execution confirmation request submitted by the nurse terminal in response to the treatment queue, the validity of the nurse account on the nurse terminal and the remaining number of treatment orders for the user are verified. After the verification is successful, an execution record is added to the same database transaction, the appointment status is changed to the completed status, and the number of times the treatment order has been used is incremented. Obtain the appointment status transition event and generate audit evidence corresponding to the appointment status transition time; Based on the audit evidence, abnormal events are identified. When no abnormal events are found, the quantitative scoring results in the audit evidence are obtained. The migration handling level is determined according to the value range of the quantitative scoring results. The abnormal events include duplicate submission events and causal reversal events. The corresponding processing strategy is executed according to the migration handling level. Specifically, when the quantitative scoring result is in the first value range, the state migration is completed and the quantitative scoring result is recorded; when the quantitative scoring result is in the second value range, the state migration is completed and marked as pending audit status, and a review prompt is sent to the management terminal; when the quantitative scoring result is in the third value range, the current state migration is paused, compensation transaction processing is triggered, and a handling suggestion is sent to the management terminal; when the quantitative scoring result is in the fourth value range, the current state migration request is rejected, state migration evidence is retained, and a high-priority audit alarm is triggered. The numerical ranges of the first, second, third, and fourth value ranges decrease sequentially and do not overlap.

[0008] In one embodiment, prior to the step of responding to the user token submitted by the QR code reader, the method further includes: In response to a user profile creation request submitted by a staff member's terminal, a profile number corresponding to the user and a random user token associated with the profile number are generated. The profile number is assigned sequentially from an independent sequence in natural number order and does not reuse archived historical numbers. The user token is a high-entropy random string and does not contain the user's name or contact number. The file number and the user token are sent to the staff terminal. The staff terminal encodes the user token into a static QR code and outputs it. The static QR code does not contain the user's name or contact number, nor does it contain any plaintext information related to the appointment. Record the operator's account, filing time, and user token generation time of the staff terminal to form a user filing audit record.

[0009] In one embodiment, prior to the step of responding to the user token submitted by the QR code reader, the method further includes: In response to an appointment creation request submitted by a staff member's terminal, the appointment creation request includes the target user's user identifier, the target treatment item, the target appointment date, and the target fixed time period, and verifies whether the target user's remaining treatment attempts are greater than or equal to one. When the remaining number of treatments for the treatment order is greater than or equal to one, the target shared capacity group to which the target treatment item belongs is determined based on the target treatment item, and the number of existing appointments in the target shared capacity group during the target fixed time period is queried. Compare whether the number of existing reservations plus one exceeds the group-level capacity limit of the target shared capacity group during the target fixed time period. If it does not exceed the limit, create the reservation session. Obtain the user token of the target user, combine the hash value of the user token with the session identifier of the reservation session, the time information of the target fixed time period and the initial stage version into a binding tuple, and derive the initial stage sub-token from the binding tuple through a keyed hash operation; During each legitimate state transition of the scheduled session, a sub-token for the next stage is derived based on the sub-token of the current stage and the event digest of the current transition event, causing the old stage sub-token and the old fixed time period sub-token that have completed the transition to automatically become invalid.

[0010] In one embodiment, the step of identifying duplicate submissions and reversed causality based on the audit evidence includes: Compare the first idempotent identifier corresponding to the current state transition request with the second idempotent identifier in each versioned event stored in history. When the first idempotent identifier matches any of the second idempotent identifiers, the current state transition request is determined to be a duplicate submission event. When the first idempotent identifier is inconsistent with all the second idempotent identifiers, the first causal time sequence information corresponding to the current state transition request is extracted, and the first causal time sequence information is compared with the second causal time sequence information in each historical versioned event. When the causal relationship order indicated by the first causal time sequence information is contrary to the causal relationship order indicated by the second causal time sequence information, the current state transition request is determined to be a causal inversion event. When the first idempotency identifier is inconsistent with all the second idempotency identifiers and the causal relationship order of the first causal time sequence information is not contradictory to that of all the second causal time sequence information, it is confirmed that no duplicate submission event or causal inversion event is found, and the step of obtaining the quantitative scoring result is executed.

[0011] In one embodiment, prior to the step of obtaining the quantitative scoring result in the audit evidence, the method further includes: Obtain the expected state of the actual migration object in the expected migration path of the current state migration event, and compare the consistency between the actual state and the expected state to determine the degree of state matching deviation. The degree of path deviation is determined based on the difference between the actual migration path of the current state transition event and the preset shortest expected migration path; The degree of deviation of the time window is determined based on the degree of deviation between the actual occurrence time of the current state transition event and the expected execution time window corresponding to the reservation session; The degree of deviation from the context constraints is determined based on the degree to which the context conditions involved in the current state transition event are met. The context conditions include the matching of the user token with the user identity recorded in the appointment session, whether the treatment order is in a valid open state, whether the remaining number of treatment orders is greater than zero, the consistency between the appointment session and the fixed time period, and whether the nurse account is in a valid enabled state. The deviations of state matching, path, time window, and context constraint are assigned weights and summed to obtain a comprehensive deviation value. The comprehensive deviation value is then mapped to a percentage score to obtain the quantitative score result.

[0012] In one embodiment, the step of pausing the current state transition and triggering the compensation transaction includes: When a reserved resource is detected to be in a created but unconfirmed state, it is determined whether the time interval between the creation time of the reserved resource and the current time exceeds the validity period. If the validity period has not been exceeded, a confirmation instruction is resent to the database to restore the reserved resource. If the validity period has been exceeded, a release instruction is sent to the database to clear the reserved resource and the resource release event is recorded. When it is detected that the confirmation operation has been successfully executed but the corresponding target write operation is missing, the corresponding write position is searched in the database according to the idempotency flag carried by the confirmation operation. If the write position exists and can be written, the target write operation is written. If the write position cannot be written, a rollback confirmation instruction is sent to the database to cancel the confirmation operation. When it is detected that the target reservation has been cancelled but the reserved resources corresponding to the target reservation are still occupied, a release command is sent to the database to clear the reserved resources, and a resource leakage event between the reserved resources and the target reservation is recorded. When it is detected that the execution record has been successfully written to the database but the number of times the treatment order has been used has not been synchronously increased, under the hard constraint that the remaining number of times in the database is greater than zero, the instruction to increase the number of times is resent to the database until the number of times the treatment order has been used is consistent with the number of execution records or the remaining number of times the treatment order is zero.

[0013] In one embodiment, prior to the step of responding to the user token submitted by the QR code reader, the method further includes: In response to a backup request submitted by the administrator terminal, a database backup file is generated through a database consistency snapshot. The backup file contains at least user account information, user profile information, treatment order information, appointment record information, execution record information, and audit log information. Upon receiving an import request submitted by the administrator terminal on the target device, the backup file is subjected to a series of comprehensive verification steps in sequence. If the verification passes, a timestamp-marked rollback copy is created with the current database of the target device as the target, and the backup file is imported into the target device in an atomic replacement manner and incremental structure migration is performed. The verification steps include file header validity verification, page integrity verification, foreign key constraint verification, core data table existence verification, and database version compatibility verification. If any step fails to verify or import, the current database of the target device is retained and the original data of the current database is maintained. An error message containing the reason for the failure is returned to the administrator terminal. When all verifications pass and the import is successful, the old login session records of the target device are cleared, and the operator account, import time and source summary of the backup file for this import operation are written to the audit log to restore business services.

[0014] In one embodiment, prior to the step of responding to an execution confirmation request submitted by a nurse's terminal based on the treatment queue, the method further includes: When the type of treatment item corresponding to the reported status is a preset functional screening type, a structured screening result input interface corresponding to the treatment item is provided to the staff terminal. The structured screening result input interface includes at least one electromyography score input field and multiple anatomical site separation measurement value input fields. The multiple anatomical sites include at least the supraumbilical site, the umbilicus, and the subumbilical site. The system receives the structured screening results submitted by the staff terminal, binds and stores the structured screening results with the treatment order identifier of the treatment project and the user identifier of the user, and records the staff's account information and the entry time.

[0015] Furthermore, to achieve the above objectives, this application also proposes a closed-loop management system for pelvic floor rehabilitation therapy, wherein the system is deployed in an intra-hospital local area network environment, including: The user management module is used to generate a file number and a random user token in response to the basic user information submitted by the staff terminal, and send the user token to the staff terminal for encoding into a static QR code for output. The QR code does not contain the user's name, contact number, or appointment plaintext. The appointment management module is used to respond to the appointment creation request submitted by the staff terminal, verify the remaining number of treatments and the group-level capacity reserve of the shared capacity group to which the fixed time period belongs, and create an appointment session after the verification is successful and establish the binding relationship between the user token, the appointment session and the fixed time period, and derive sub-tokens based on the binding relationship. The check-in management module is used to respond to the user token submitted by the QR code reader, verify the binding relationship between the user token, the appointment session, the fixed time period and the sub-token, and after the verification is successful, change the appointment status to the checked-in status. The execution management module is used to respond to execution confirmation requests submitted by nurses' terminals, verify the validity of nurse accounts and the remaining number of treatments on the order. After the verification is successful, an execution record is added to the transaction and the appointment status and the number of treatments used are updated. The audit trail module is used to record each state transition as a versioned event. The versioned event includes at least an event type, version identifier, causal timing information and idempotency identifier, and identifies duplicate submissions and reversed causal situations based on the versioned events. The capacity control module is used to map multiple treatment items that occupy the same treatment resources to the same shared capacity group, set a group-level capacity limit for each shared capacity group at each fixed time period, and use database-level constraints to prevent concurrent over-occupancy. The data migration module is used to generate database backup files through consistent snapshots, and to sequentially verify the integrity, foreign key constraints and version compatibility of the backup files during import. After the verification is passed, the backup files are imported in an atomic replacement manner and a rollback copy is automatically created.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the closed-loop management method for pelvic floor rehabilitation treatment as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: The technical solution of this application, in response to a user token submitted by a QR code reader, locates the user using the user token and queries the user's appointment session for the current date; extracts the fixed time period and current stage corresponding to the appointment session, and verifies the binding relationship between the user token, appointment session, fixed time period, and sub-token corresponding to the current stage based on the extraction results; after successful verification, the appointment status is transitioned to the "checked in" status and the user enters the treatment queue; based on the treatment queue, in response to an execution confirmation request submitted by a nurse terminal, the validity of the nurse's account on the nurse terminal and the remaining number of treatments for the user are verified; after successful verification, an execution record is added in the same database transaction, the appointment status is transitioned to the "completed" status, and the number of treatments used is incremented; an appointment status transition event is obtained, and audit evidence corresponding to the appointment status transition time is generated; based on the audit evidence, abnormal events are identified, and if no abnormal events are found, the audit evidence is obtained. The quantitative scoring results are used to determine the migration handling level based on the value range in which the quantitative scoring results fall. The abnormal events include duplicate submission events and causal reversal events. A corresponding processing strategy is executed according to the migration handling level. Specifically, when the quantitative scoring result is in the first value range, the state migration is completed and the quantitative scoring result is recorded; when the quantitative scoring result is in the second value range, the state migration is completed and marked as pending audit status, and a review prompt is sent to the management terminal; when the quantitative scoring result is in the third value range, the current state migration is paused, compensation transaction processing is triggered, and a handling suggestion is sent to the management terminal; when the quantitative scoring result is in the fourth value range, the current state migration request is rejected, state migration evidence is retained, and a high-priority audit alarm is triggered. The numerical ranges of the first, second, third, and fourth value ranges decrease sequentially and do not overlap.

[0018] Through the technical solution of this application, the dynamic binding of identity credentials and business sessions is realized, resource control is shifted from post-event error reporting to pre-event group-level hard constraints, and state migration is upgraded from binary judgment to quantitative hierarchical auditing, solving the technical problems of QR code misuse, implicit resource over-contracting, and lack of evidence of anomalies. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the closed-loop management method for pelvic floor rehabilitation therapy according to this application. Figure 2 This is a detailed step diagram of step S60 in one embodiment; Figure 3 This is a flowchart illustrating the second embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 4 This is a flowchart illustrating the third embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 5 This is a flowchart illustrating the fourth embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 6 This is a flowchart illustrating the fifth embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 7 This is a flowchart illustrating the sixth embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 8 This is a schematic diagram of the closed-loop and trusted control architecture of the intra-institutional local area network of the present invention; Figure 9 This is a schematic diagram of the equipment structure of the hardware operating environment involved in the closed-loop management method for pelvic floor rehabilitation treatment in the embodiments of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] In the management of pelvic floor rehabilitation treatment, the existing solution uses static QR codes to carry identity, manages number sources independently for each project, and uses binary judgment to handle status migration. This leads to the misuse of identity credentials out of business context, implicit over-contracting of shared resources for multiple projects, and a lack of traceable and quantifiable evidence for abnormal events. This is fundamentally contradictory to the inherent requirements of closed-loop management and data security for pelvic floor rehabilitation, which involves the reuse of equipment for multiple projects and long-term periodic treatment.

[0026] To address the aforementioned shortcomings, this application proposes a closed-loop management method for pelvic floor rehabilitation treatment. In this method, the QR code contains only a random user token and no appointment plaintext. Upon scanning the code for check-in, the binding relationship between the user token, appointment session, fixed time period, and stage sub-token is verified. During each legitimate migration, the sub-token is chained to invalidate the old state, preventing scans at incorrect time periods or stages. For capacity control, multiple projects are mapped to shared capacity groups with set group-level upper limits, using hard database constraints to prevent implicit over-contracting. Regarding state migration, each migration generates a versioned event containing idempotent identifiers and causal sequence information, identifying duplicate submissions and causal inversions, and implementing four-tiered handling based on quantitative scoring: direct completion, pending audit, suspension with compensation, or rejection of alarms.

[0027] This enables dynamic binding of identity credentials to business sessions, shifts resource management from post-event error reporting to pre-event group-level hard constraints, and upgrades state migration from binary judgment to quantitative hierarchical auditing, solving the technical challenges of QR code misuse, implicit resource over-contracting, and lack of evidence for anomalies.

[0028] Based on this, the embodiments of this application provide a closed-loop management method for pelvic floor rehabilitation treatment, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the closed-loop management method for pelvic floor rehabilitation therapy according to this application. In this embodiment, the closed-loop management method for pelvic floor rehabilitation therapy is applied to a server and includes steps S10-S70: Step S10: In response to the user token submitted by the QR code reader, locate the user with the user token and query the user's appointment session for the current date; In this embodiment, the closed-loop management method based on pelvic floor rehabilitation treatment is applied to the server side and deployed in the hospital's local area network environment. Throughout the entire treatment management process, users only need to possess the static QR code issued during registration to complete all steps from check-in to treatment. All appointment operations are completed by staff on the local area network terminal, fully adapting to the actual management boundaries of the hospital staff's terminal access.

[0029] After the user arrives at the treatment room at the scheduled time, staff use an HID QR code reader to scan the static QR code held by the user. This QR code can be printed and pasted into the user's paper file, or the user can take a photo of it and save it to their mobile phone with staff permission. The HID QR code reader is a human-machine interface device that operates in keyboard simulation mode. The scanned QR code content is submitted to the currently logged-in staff terminal via keyboard input, and the terminal then sends the contained user token to the server. After submitting the user token, the QR code reader automatically sends an Enter key to complete the input operation, requiring no manual intervention from staff.

[0030] After receiving the user token submitted by the QR code reader, the server uses the token as a query index to locate the corresponding user file in the database, thereby determining the user's unique identity. This user token is a high-entropy random service token, generated and written into the user file by the server during file creation. The QR code contains only the token and does not include the user's name, phone number, or any plaintext information related to appointments. Therefore, even if the QR code is photographed or forwarded, the user's clinical privacy data will not be leaked. When staff create a new user file after logging in, a five-digit sequential file number is generated. This file number is assigned sequentially from an independent sequence using natural numbers, without reusing previously archived historical numbers. It is formatted as a five-digit number, for example, starting from 00001, 00002, 00003, etc., until it reaches 99999, at which point the staff is prompted to use a manual file number. The system also records the account information of the person entering the data and the file creation time, forming a complete file creation audit record.

[0031] After locating the user, the system further queries whether the user already has a valid reservation session for the current date. Specifically, using the time range from midnight of the current date to midnight of the next day, it retrieves all reservation records corresponding to the user's identifier from the reservation session table and filters out reservation sessions with a "reserved" status. If the user has multiple "reserved" reservation sessions for the current date, they are further sorted according to the proximity of the fixed time period of the reservation session to the current system time to determine the most likely upcoming reservation session. The process of locating the user and querying the reservation session described above is completed within a server-side in-memory transaction, without relying on any reservation information transmitted from the front end, thus ensuring the accuracy and security of the query results.

[0032] Step S20: Extract the fixed time period and current stage corresponding to the appointment session, and verify the binding relationship between the user token, appointment session, fixed time period and sub-token corresponding to the current stage based on the extraction results. After the verification is successful, the appointment status is changed to the checked-in status and the appointment is entered into the treatment queue. In this embodiment, the fixed time slot information corresponding to the queried appointment session and the current stage information of the appointment session are extracted from the queried appointment session. The fixed time slot is the time window set when the appointment is created, allowing users to check in and receive treatment. Each fixed time slot is fifty minutes long. For example, the fixed time slot of a certain appointment session is from 9:00 to 9:50 on Saturday, corresponding to the second time slot in the hospital's open hours. The current stage information reflects the progress of the appointment session's completed state transition, such as the initial stage, the checked-in stage, or the completed stage. According to the expected transition model of the finite state machine, the appointment state should gradually transition according to the preset path. The main path for a normal appointment is from the initial state to the booked state to the checked-in state to the completed state, and the cancellation path is from the booked state to the cancelled state or from the checked-in state to the cancelled state.

[0033] After extracting the above information, the binding relationship between the user token, reservation session, fixed time period, and sub-token corresponding to the current stage is verified based on these extraction results. This verification process is executed entirely on the server side and does not rely on any assertion information transmitted from the front end. Specifically, the server first calculates the hash value of the received user token and compares it with the hash value stored when the reservation session was created to confirm whether the currently scanned user token truly belongs to the user corresponding to the reservation session. Second, it compares whether the current system date and time fall within the time window of the reservation date and fixed time period set by the reservation session to confirm whether the user arrived at the correct time. Third, it obtains the sub-token corresponding to the reservation session in the current stage and compares it with the sub-token independently recalculated by the server based on the binding tuple to confirm whether the sub-token is valid and has not been tampered with.

[0034] The sub-token is derived as follows: When a reservation session is created, the server combines the user token's hash value, the reservation session's session identifier, the fixed time period's time information, and the initial stage version into a binding tuple. An initial stage sub-token is then derived from this binding tuple through a keyed hash operation. During each valid state transition, the next stage sub-token is derived based on the current stage's sub-token and the event digest of the current transition event, automatically invalidating the old stage sub-token and the old fixed time period sub-token. Through this binding verification of the above four elements, even if a user's static QR code is copied by someone else or scanned at an incorrect time, it will fail the server's verification because the corresponding sub-token becomes invalid after the QR code is separated from the valid reservation session and the correct time period.

[0035] If all four binding relationship verifications pass, the QR code check-in request is confirmed as legitimate and valid. The status of the appointment session is then changed from "appointed" to "checked in," and the user is added to the treatment queue for the current date, awaiting treatment by the nurse. If any binding relationship verification fails—for example, due to a mismatched user token, the current time being outside a fixed time period, or an expired sub-token—the server rejects the check-in request and returns a corresponding error message, while also logging the failed attempt in the audit log.

[0036] Step S30: Based on the execution confirmation request submitted by the nurse terminal in response to the treatment queue, verify the validity of the nurse account on the nurse terminal and the remaining number of treatments for the user; After a user successfully checks in and enters the treatment queue, the nurse's terminal displays information about all checked-in users and their corresponding treatments. This queue is arranged in order of check-in time, ensuring that users who check in first receive treatment first, thus guaranteeing fairness and orderliness. The nurse selects a user from the queue and clicks the "Confirm Execution" button. At this point, the nurse's terminal submits an execution confirmation request to the server, which includes the selected user's identifier.

[0037] Upon receiving the execution confirmation request, the server first verifies the validity of the nurse account submitted by the nurse's terminal. Specifically, it queries the nurse account table to confirm the account's existence, non-deactivated status, and authorization to perform treatment. Nurses with existing execution records are deactivated and will not appear in the new service selection box, but historical statistics are retained. This design ensures historical data is not physically deleted while preventing deactivated personnel from operating new services. If the nurse account is invalid—for example, if it does not exist, is deactivated, or lacks execution permissions—the server directly rejects the execution confirmation request and returns an error message.

[0038] After the nurse's account validity is verified, the system further verifies whether the user's remaining treatment slots are greater than zero. The remaining treatment slots are calculated by subtracting the number of executed treatments and the number of pending appointments from the number of treatments created. This calculation is performed in real-time on the server side to ensure accuracy. The server reads the number of treatments created, executed, and the number of pending appointments for the user's corresponding treatments from the database and calculates the remaining slots. If the remaining slots are greater than zero, the verification passes, and the server allows continued treatment. If the remaining slots are zero, it means the user has used up their treatment slots, and the server rejects the execution confirmation request and displays a message indicating that the treatment slots have been used up. This double verification ensures that only nurses with valid permissions can perform treatment operations on users with remaining treatment slots, preventing unauthorized personnel from operating the system or exceeding the permitted number of treatment slots.

[0039] Step S40: After verification, add an execution record in the same database transaction, change the appointment status to the completed status, and increment the number of times the treatment order has been used; After the nurse's account validity verification and the remaining treatment count verification both pass, a database transaction is initiated. This transaction uses the serializability isolation level to ensure data consistency. Under this isolation level, concurrent transactions will not encounter problems such as dirty reads, non-repeatable reads, or phantom reads. Within this transaction, the server executes three data update operations in parallel. The first operation is to add an execution record to the execution record table. This execution record must at least include the user identifier, treatment order identifier, appointment session identifier, executing nurse's account identifier, execution time, and remarks. Each execution record represents one actual completed treatment and cancels one treatment count.

[0040] The second operation is to change the status of the appointment session from "checked in" to "completed" and update the version number of the appointment session. The third operation is to increment the usage count of the treatment order by one, and recalculate the remaining usage count based on the number of orders placed and the usage count. These three operations are committed within the same database transaction, ensuring that either all succeed or all fail, preventing partial updates from succeeding while others fail. This intra-transaction atomic update method prevents data inconsistencies caused by system anomalies or concurrent operations; for example, it prevents situations where an execution record has been added but the usage count of the treatment order has not been incremented.

[0041] After the transaction is committed, the server returns a success message to the nurse's terminal, which updates the treatment queue and removes the user from the pending list. Simultaneously, the server checks if the number of times the treatment order has been used has reached the required number of orders. If it has, the server automatically sets the treatment order's status to "completed," and no new appointments are allowed for that order. These three data update operations are atomically committed within the same database transaction, ensuring data consistency among the execution record, appointment status, and treatment order count. This provides a reliable data foundation for subsequent statistical analysis and audit trails.

[0042] Step S50: Obtain the reservation status transition event and generate audit evidence corresponding to the reservation status transition time; After each appointment status transition event occurs, such as from "Booked" to "Checked In" or from "Checked In" to "Completed," the server retrieves relevant information for that status transition event and generates corresponding audit evidence. The information for a status transition event includes at least the status before the transition, the status after the transition, the specific time the transition occurred, the account of the operator who triggered the transition, and the user identifiers and appointment session identifiers involved in the transition. The audit evidence generated by the server contains at least two components.

[0043] The first component is the quantitative score of the state transition, which measures the degree of consistency between the current state transition and the expected transition path. The score ranges from 0 to 100%, with a higher score indicating a closer alignment with the expected path. The second component is the versioned tracking record, which stores complete information about the current state transition in the form of versioned events. Each versioned event includes at least the event type, version identifier, node identifier, causal sequence information, and idempotency identifier.

[0044] The event type is used to distinguish different types of events, such as appointment creation events, check-in events, execution events, or cancellation events. Each event type corresponds to a different expected migration path. The version identifier is used to distinguish the state versions of the same entity at different points in time. Each state migration generates a new version, thus forming a complete state change history chain. The node identifier is used to identify the system node where the event occurred, facilitating the tracing of the event's origin in a distributed deployment scenario. Causal sequence information describes the sequential or concurrent relationships between different events. This causal sequence information is implemented using vector clocks. Each event carries a versioned node count vector. By comparing the vector clocks of two events, their causal relationship can be determined: if the vector clock of the first event is generally less than that of the second event, then the first event precedes the second event causally; if the two vector clocks are not comparable, they are considered concurrent branches. The idempotency identifier is used to uniquely identify a business operation. Even if the operation is submitted repeatedly, the server can identify duplicate requests through the idempotency identifier, preventing duplicate processing. Versioned events also include a prequel summary, recording the hash value of the previous event, forming an event chain to ensure event integrity and tamper-proof nature.

[0045] After generating audit evidence, the server persistently stores it in the audit event table of the database and associates it with the corresponding user ID and appointment session ID for subsequent querying and analysis. The generation of this audit evidence does not rely on any external system and is entirely completed locally on the server, ensuring the reliability and independence of the audit function.

[0046] Step S60: Identify abnormal events based on the audit evidence. When no abnormal events are found, obtain the quantitative scoring results in the audit evidence and determine the migration handling level according to the value range of the quantitative scoring results. The abnormal events include duplicate submission events and causal reversal events. In this embodiment, after generating audit evidence, the system identifies whether the current state transition request is an anomalous event based on this evidence. Anomalous events include two categories: duplicate submission events and causal reversal events. For the identification of duplicate submission events, the first idempotency identifier carried by the current state transition request is compared with the second idempotency identifiers in the previously stored versioned events. If the first idempotency identifier matches any of the second idempotency identifiers, it indicates that the request has already been submitted before. The server determines that the current state transition request is a duplicate submission, directly rejects the request, and returns an idempotency conflict warning.

[0047] For identifying causal inversion events, when the first idempotency flag is inconsistent with all second idempotency flags, the server extracts the first causal sequence information corresponding to the current state transition request and compares this first causal sequence information with the second causal sequence information in each historical versioned event. If the causal order indicated by the first causal sequence information contradicts the causal order indicated by the second causal sequence information—for example, the current request attempts to transition the reservation status from "completed" to "checked in," while historical events show that the reservation has already undergone a transition from "reserved" to "checked in"—then the current state transition request is determined to be a causal inversion case, the server rejects the request and returns a causal order error message.

[0048] When the first idempotency identifier is inconsistent with all second idempotency identifiers and the causal order of the first causal time sequence information is not contradictory to that of all second causal time sequence information, the server confirms that no duplicate submissions or causal inversions are found, and then obtains the quantitative scoring result from the audit evidence. This quantitative scoring result is calculated based on the degree of matching between the actual state and the expected state, the degree of deviation between the actual migration path and the expected migration path, the degree of coincidence between the migration time and the expected time window, and the degree of satisfaction of contextual constraints.

[0049] Specifically, based on the actual migration object of the current state migration event, the expected state of the actual migration object in the expected migration path is obtained, and the consistency between the actual state and the expected state is compared to determine the degree of state matching deviation. For example, the main path for a normal appointment is from the initial state to the booked state to the checked-in state to the completed state. If the actual migration skips an intermediate state, a deviation occurs. The server determines the path deviation degree based on the difference between the actual migration path of the current state migration event and the preset shortest expected migration path. For example, migrating directly from booked to completed, skipping the checked-in state, constitutes a path deviation. The server determines the time window deviation degree based on the deviation between the actual occurrence time of the current state migration event and the expected execution time window corresponding to the appointment session. The server determines the context constraint deviation degree based on the degree to which the context conditions involved in the current state migration event are met. Context conditions include the matching of the user token with the user identity recorded in the appointment session, whether the treatment order is in a valid open state, whether the remaining number of treatment orders is greater than zero, the consistency between the appointment session and the fixed time period, and whether the nurse account is in a valid enabled state. The server normalizes each deviation level to a range of zero to one. It then assigns weights to each normalized deviation level and performs a weighted summation, with the sum of all weights equal to one. This weighted summation is the overall deviation value. This overall deviation value is then mapped to a percentage score, yielding the quantitative score result. The server determines the handling level for this migration based on the value range of this quantitative score result. There are four value ranges: the first, second, third, and fourth value ranges, with the numerical ranges decreasing sequentially and not overlapping.

[0050] Step S70: Execute the corresponding processing strategy according to the migration handling level. Specifically, when the quantitative scoring result is in the first value range, complete the state migration and record the quantitative scoring result; when the quantitative scoring result is in the second value range, complete the state migration and mark it as pending audit status, and send a review prompt to the management terminal; when the quantitative scoring result is in the third value range, pause the current state migration, trigger compensation transaction processing, and send a handling suggestion to the management terminal; when the quantitative scoring result is in the fourth value range, reject the current state migration request, retain state migration evidence, and trigger a high-priority audit alarm. The numerical ranges of the first, second, third, and fourth value ranges decrease sequentially and do not overlap.

[0051] In this embodiment, the corresponding processing strategy is executed according to the determined migration handling level. When the quantitative score result is in the first value range, which corresponds to the highest score range, it indicates that the current state migration is highly consistent with the expected migration path. The server directly completes the state migration and records the quantitative score result in the audit log without additional manual intervention. This method is suitable for normal, non-abnormal state migration scenarios and accounts for the vast majority of system operations.

[0052] When the quantitative score result is in the second range, which corresponds to the second highest score range, it indicates that there is a slightly interpretable deviation in this state transition. The server completes the state transition and marks the transition as pending audit status. At the same time, it sends a review prompt to the management terminal to remind the management personnel to conduct a subsequent manual review of the transition. This method is suitable for scenarios where there is a reasonable deviation but it does not affect the overall business process, such as when a user is late but completes the check-in within a reasonable tolerance range.

[0053] When the quantitative scoring result falls within the third value range, which corresponds to a lower score range, it indicates a significant deviation in the current state transition. The server pauses the current state transition, does not perform any data write operations, and triggers compensation transaction processing. Compensation transaction processing refers to a mechanism for automatically repairing abnormal transactions, including the following four scenarios: 1. When a reserved resource is detected to be in a created but unconfirmed state, it is determined whether the time interval between the creation time of the reserved resource and the current time exceeds the validity period. If the validity period has not exceeded, a confirmation command is resent to the database to restore the reserved resource. If the validity period has exceeded, a release command is sent to the database to clear the reserved resource and record the resource release event. 2. When a confirmation operation is detected to have been successfully executed but the corresponding target write operation is missing, the corresponding write position is searched in the database based on the idempotency flag carried by the confirmation operation. If the write position exists and is writable, the target write operation is completed. If the write position is not writable, a rollback confirmation command is sent to the database to undo the confirmation operation. When it is detected that a target appointment has been cancelled but the reserved resource corresponding to that appointment is still occupied, a release command is sent to the database to clear the reserved resource and record the resource leak event. When it is detected that an execution record has been successfully written to the database but the number of times the treatment order has been used has not been synchronously incremented, under the hard constraint that the remaining number of times in the database is greater than zero, the increment command is resent to the database until the number of times the treatment order has been used matches the number of execution records or the remaining number of times the treatment order has been used is zero. The server also sends a disposal suggestion to the management terminal, prompting the administrator to review and make a decision on this migration.

[0054] When the quantitative scoring result falls within the fourth value range, which corresponds to the lowest score range, it indicates a serious inconsistency in the current state transition. The server rejects the current state transition request, does not perform any data update operations, retains state transition evidence, and triggers a high-priority audit alarm, notifying administrators to intervene immediately. This approach is suitable for scenarios with serious anomalies that cannot be resolved automatically. Through these four-tiered handling strategies, the server can adopt differentiated processing methods based on the credibility of the state transition, ensuring efficient processing of normal transitions while ensuring that abnormal transitions receive appropriate attention and correction. This represents a technological leap in state transition management from simple binary judgment to quantitative tiered auditing, and also provides interpretable and traceable audit evidence for complex scenarios such as concurrency, network replay, and service anomalies.

[0055] Specifically, the step of pausing the current state migration and triggering the compensation transaction processing to send a handling suggestion to the management terminal includes: When a reserved resource is detected to be in a created but unconfirmed state, it is determined whether the time interval between the creation time of the reserved resource and the current time exceeds the validity period. If the validity period has not been exceeded, a confirmation instruction is resent to the database to restore the reserved resource. If the validity period has been exceeded, a release instruction is sent to the database to clear the reserved resource and the resource release event is recorded. When it is detected that the confirmation operation has been successfully executed but the corresponding target write operation is missing, the corresponding write position is searched in the database according to the idempotency flag carried by the confirmation operation. If the write position exists and can be written, the target write operation is written. If the write position cannot be written, a rollback confirmation instruction is sent to the database to cancel the confirmation operation. When it is detected that the target reservation has been cancelled but the reserved resources corresponding to the target reservation are still occupied, a release command is sent to the database to clear the reserved resources, and a resource leakage event between the reserved resources and the target reservation is recorded. When it is detected that the execution record has been successfully written to the database but the number of times the treatment order has been used has not been synchronously increased, under the hard constraint that the remaining number of times in the database is greater than zero, the instruction to increase the number of times is resent to the database until the number of times the treatment order has been used is consistent with the number of execution records or the remaining number of times the treatment order is zero.

[0056] This embodiment defines the specific implementation method of the compensation transaction processing. After pausing the current state transition, compensation transaction processing is triggered and a handling suggestion is sent to the management terminal. This compensation transaction processing is used to automatically repair various abnormal transactions that occur during the state transition process.

[0057] The first scenario for compensation transaction processing is the hanging of reserved resources. When the server detects that a reserved resource is in a created but unconfirmed state, it indicates that the system has reserved a slot for the reservation but has not yet completed the confirmation operation. The server determines whether the time interval between the creation time of the reserved resource and the current time has exceeded the validity period, which is the validity period of the reserved resource set when the reservation was created. If the validity period has not exceeded, the server resends a confirmation command to the database to restore the reserved resource, thereby completing the previously interrupted confirmation process. If the validity period has exceeded, the server sends a release command to the database to clear the reserved resource and records the resource release event, preventing expired reserved resources from continuously occupying slots and preventing other users from making reservations. This design corresponds to the migration process from the TRY state to the CONFIRM or CANCEL state in the TCC compensation mechanism.

[0058] The second scenario for compensatory transaction processing is partial commit. When the server detects that the acknowledgment operation has been successfully executed but the corresponding target write operation is missing, it indicates that an abnormal interruption occurred during the database write process. The server searches for the corresponding write position in the database based on the idempotency identifier carried by the acknowledgment operation. This idempotency identifier uniquely identifies a complete business operation. If the write position exists and is writable, the server rewrites the target write operation to complete the previously interrupted data persistence. If the write position is not writable, the server sends a rollback acknowledgment command to the database to undo the acknowledgment operation, thereby restoring the state before execution.

[0059] The third scenario for compensation transaction processing is resource leakage. When the server detects that a target reservation has been cancelled but the reserved resources corresponding to that reservation are still occupied, it indicates that the reservation cancellation operation was successfully executed but the reserved resources were not released synchronously. The server sends a release command to the database to clear the reserved resources and records the resource leakage event between the reserved resources and the target reservation. The resource leakage event is recorded in the audit log, which facilitates subsequent tracking and statistical analysis of the frequency and causes of such anomalies, providing data support for system optimization.

[0060] The fourth scenario for compensation transaction processing is clinical count deviation. When the server detects that an execution record has been successfully written to the database but the number of times a treatment order has been used has not been synchronously incremented, it indicates that a transaction commit anomaly occurred after the execution record was added, causing the count update operation to fail. Under the hard constraint that the remaining count in the database is greater than zero, the server resends the count increment instruction to the database until the number of times a treatment order has been used matches the number of execution records or the remaining count for the treatment order is zero. This hard constraint serves as a safety baseline, ensuring that even during the compensation operation, the number of times the execution order exceeds the limit will not be exceeded. The detection conditions and recommended compensation actions for the above four compensation scenarios are pre-configured as detection rules on the server side. These rules do not rely on external system input and are entirely based on the event status in the local database. While executing the compensation operation, the server sends handling suggestions to the management terminal. These suggestions include the detected anomaly type, the executed compensation action, and the current data status, helping managers understand the anomaly handling situation and decide whether further manual intervention is needed.

[0061] Further, see Figure 2 , Figure 2 This is a detailed step diagram of step S60 in one embodiment, based on the shown... Figure 2 The step of identifying abnormal events based on the audit evidence includes S61 to S63: Step S61: Compare the first idempotent identifier corresponding to the current state transition request with the second idempotent identifier in each versioned event that has been stored in history. When the first idempotent identifier is consistent with any of the second idempotent identifiers, determine that the current state transition request is a duplicate submission event. Step S62: When the first idempotent identifier is inconsistent with all the second idempotent identifiers, extract the first causal timing information corresponding to the current state transition request, and compare the first causal timing information with the second causal timing information in each historical versioned event. When the causal relationship order indicated by the first causal timing information is contrary to the causal relationship order indicated by the second causal timing information, determine that the current state transition request is a causal inversion event. Step S63: When the first idempotency identifier is inconsistent with all the second idempotency identifiers and the causal relationship order of the first causal time sequence information is not contradictory to all the second causal time sequence information, confirm that no duplicate submission event or causal inversion event is found, and execute the step of obtaining the quantitative scoring result.

[0062] This embodiment defines a specific implementation method for anomaly event identification. After generating audit evidence, it identifies whether the current state transition request is an anomaly event based on this evidence. These anomalies include two categories: duplicate submission events and causal reversal events. During the identification process, the server compares the first idempotency identifier carried in the current state transition request with the second idempotency identifiers in all previously stored versioned events. The idempotency identifier is a unique string generated by hashing various elements of the business operation, such as user identifier, appointment session identifier, operation type, and operation time combined and then hashed. The server reads the idempotency identifiers of all historical versioned events from the audit event table in the database and compares them one by one with the first idempotency identifier of the current request. If the first idempotency identifier matches any of the second idempotency identifiers, it indicates that the request has already been submitted and successfully processed. The server determines that the current state transition request is a duplicate submission event, directly rejects the request, returns an idempotency conflict warning to the operation terminal, and records the duplicate submission detection log for subsequent auditing. If the first idempotency identifier does not match any of the second idempotency identifiers, it indicates that the request is a new business request.

[0063] Next, the first causal timing information corresponding to the current state transition request is extracted. This causal timing information is implemented using vector clocks. Each event carries a versioned node count vector, which records the event counts occurring on each system node. By comparing the vector clocks of two events, the causal relationship between them can be determined. This first causal timing information is then compared with the second causal timing information in each historical versioned event to determine if there is a causal conflict between the current request and historical events. If the causal order indicated by the first causal timing information contradicts the causal order indicated by the second causal timing information—for example, if the current request attempts to transition the reservation status from "completed" to "cancelled," while historical events show that the reservation has already undergone a transition path from "reserved" to "checked in" and then to "completed"—the transition from "completed" to "cancelled" does not conform to the expected transition path defined by the finite state machine, then the current state transition request is determined to be a causal inversion event. Or, more specifically, the current request attempts to transition the reservation status from "completed" to "checked in," while historical events show that the reservation has already undergone a forward transition from "reserved" to "checked in." Reversing from "completed" to "checked in" clearly violates the basic temporal logic of state transitions, constituting a typical case of causal inversion. The request is rejected, and a causal order error message is returned to the terminal. Simultaneously, this causal inversion detection is recorded in the audit log.

[0064] Based on the calculated data, when the first idempotency identifier is inconsistent with all second idempotency identifiers and the causal order of the first causal time sequence information is not contradictory to that of all second causal time sequence information, the server confirms that no duplicate submission events or causal inversion events have been found. At this point, the state transition request is neither a duplicate submission nor does it involve causal inversion conflicts. The server allows the subsequent steps to proceed, namely, obtaining the quantitative scoring results from the audit evidence and determining the transition handling level based on the quantitative scoring results. This three-layer progressive anomaly identification architecture enables the system to filter out the two most obvious anomalies—idempotency conflicts and causal inversions—before entering quantitative scoring. This improves the efficiency of anomaly handling and provides a more reliable data foundation for subsequent quantitative scoring. Through this design, the system can accurately distinguish between normal business requests and malicious requests when facing complex scenarios such as network replay, concurrent operations, or service anomalies, thereby ensuring the security and correctness of state transitions.

[0065] Furthermore, you can also view Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 3 Prior to the step of responding to the user token submitted by the QR code reader, steps S80-S100 are also included: Step S80: In response to the user filing request submitted by the staff terminal, generate a file number corresponding to the user and a random user token associated with the file number. The file number is assigned sequentially from an independent sequence in natural number order and does not reuse archived historical numbers. The user token is a high-entropy random string and does not contain the user's name or contact number. Step S90: Send the file number and the user token to the staff terminal. The staff terminal encodes the user token into a static QR code and outputs it. The static QR code does not contain the user's name or contact number, nor does it contain any plaintext information related to the appointment. Step S100: Record the operator account, filing time, and user token generation time of the staff terminal to form a user filing audit record.

[0066] This embodiment defines the specific implementation method of user profile creation and static identity token generation. Specifically, before the scan check-in step is executed, the system needs to complete the creation of user profiles and the issuance of identity credentials as the data foundation for all subsequent treatment processes.

[0067] First, the system responds to user file creation requests submitted by staff terminals and performs file creation operations. After logging into the system, staff enter basic user information in the user management interface. This basic information includes at least necessary fields such as user name and contact number. Upon receiving a file creation request, the system generates a file number corresponding to the user and a random user token associated with that file number. The file number generation adopts an independent sequence management method. The server maintains an independent sequence number generation table, which records the next available natural value. When generating a file number, a serialized transaction is initiated, and the sequence number generation table is locked using the BEGIN IMMEDIATE method. The next natural value is read from the transaction, and then it is checked whether the value has been used by an existing user file or an archived user file. If it has been used, it is automatically skipped and the next value is taken. This cyclic skipping mechanism ensures the uniqueness of the file number. After determining the available value, the server formats the value into a five-digit numeric string, for example, starting from 00001, 00002, 00003 sequentially, ensuring that the file numbers are allocated in natural number order and that historical numbers are not reused. If the sequence reaches 99999, meaning all five digits are used up, the system prompts staff to use a manual file number, and will no longer automatically assign one from an independent sequence. The user token is a high-entropy random service token generated by a secure random number generator on the server side. This token does not contain the user's name or contact number; it is used only as an internal index key to identify the user, ensuring that even if the token is leaked, the user's personal privacy information will not be exposed.

[0068] The generated file number and user token are sent to the staff terminal. Upon receiving this information, the staff terminal encodes the user token into a static QR code and displays it on the terminal screen. Staff can print out this QR code and affix it to the user's paper file, or the user can take a photo of it and save it on their mobile phone with staff permission. The encoded content of this static QR code only contains the user token and does not include the user's name, contact number, or any plaintext information related to appointments. Therefore, the QR code will not disclose the user's clinical privacy data during transmission, printing, or photographing. Furthermore, since the QR code does not contain appointment information, even if someone obtains the QR code, they cannot learn the user's treatment program or appointment time from it. The generated static QR code remains unchanged throughout the entire treatment cycle. Users do not need to change the QR code or save different QR codes at different treatment stages; users only need to present this static QR code to complete the check-in process for the entire treatment cycle.

[0069] The system records the operator's account, registration time, and user token generation time on the staff terminal, forming a user registration audit log. This audit log is persistently stored in the database's audit log table and includes at least the operator's account information, the timestamp of the registration operation, the generated file number, and the user token generation time. This audit log ensures that every user registration operation is traceable to the specific operator and time. When reviewing or tracking registration operations is needed, administrators can query the audit log to obtain the complete registration history. After completing the registration process, the user obtains a unique identity identifier and credential in the system. Staff can then issue treatment orders and create appointment sessions based on this user file. The user can also use this static QR code to check in at the hospital at the agreed treatment time and receive treatment. This registration process achieves a complete closed loop from user information entry to identity credential issuance and audit log storage, providing a reliable identity foundation for subsequent appointments, check-ins, and treatment execution.

[0070] Furthermore, you can also view Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention, based on the shown... Figure 4 Prior to the step of responding to the user token submitted by the QR code reader, steps S110-S150 are further included: Step S110: In response to the appointment creation request submitted by the staff terminal, the appointment creation request includes the user identifier of the target user, the target treatment item, the target appointment date and the target fixed time period, and verifies whether the remaining number of treatments for the target user is greater than or equal to one. Step S120: When the remaining number of treatments is greater than or equal to one, determine the target shared capacity group to which the target treatment item belongs based on the target treatment item, and query the number of existing appointments in the target shared capacity group during the target fixed time period. Step S130: Compare whether the number of existing reservations plus one exceeds the group-level capacity limit of the target shared capacity group in the target fixed time period. If it does not exceed the limit, create the reservation session. Step S140: Obtain the user token of the target user, combine the hash value of the user token with the session identifier of the reservation session, the time information of the target fixed time period and the initial stage version into a binding tuple, and derive the initial stage sub-token from the binding tuple through a keyed hash operation. In step S150, during each legitimate state transition of the scheduled session, a sub-token for the next stage is derived based on the sub-token of the current stage and the event digest of the current transition event, so that the old stage sub-token and the old fixed time period sub-token that have completed the transition are automatically invalidated.

[0071] This embodiment defines the specific implementation method of appointment creation. After the user completes the registration and obtains the static QR code, before the scan check-in step is executed, the staff needs to create an appointment session for the registered user as a key link connecting the user's identity certificate with the subsequent check-in process.

[0072] The system responds to appointment creation requests submitted by staff terminals by executing appointment creation operations. Staff select the target treatment, target appointment date, and target fixed time slot on the user profile page. The staff terminal combines this information with the target user's user identifier to form an appointment creation request and submits it to the server. Upon receiving this request, the system first verifies whether the target user's remaining treatment slots are greater than or equal to one. The remaining treatment slots are calculated by subtracting the number of executed and pending appointments from the number of orders placed. This calculation is performed in real-time on the server to ensure accuracy. If the remaining slots are greater than or equal to one, it means the user still has available treatment slots, and the server allows the appointment creation process to continue. If the remaining slots are zero, it means the user has used up all their treatment slots, and the server rejects the appointment creation request and displays a message indicating that all treatment slots have been used up.

[0073] When there is one or more remaining treatment attempts, the target shared capacity group to which the target treatment item belongs is determined based on the target treatment item. Different treatment items may occupy the same treatment equipment or the same treatment personnel resources. For example, vaginal radiofrequency, rectus abdominis radiofrequency, vulvar radiofrequency, and rectus abdominis manipulation therapy share the same set of equipment resources and are therefore mapped to the same shared capacity group. The system configuration table is queried to find the shared capacity group code corresponding to the target treatment item. After determining which capacity group the treatment item belongs to, the number of existing appointments for that target shared capacity group during the target fixed time period is further queried. The number of existing appointments refers to the number of appointment sessions that are already in a booked or checked-in state within the target fixed time period. These appointment sessions occupy the available slots for that capacity group during that time period.

[0074] The system compares the number of existing appointments plus one to see if it exceeds the group-level capacity limit of the target shared capacity group during the target fixed time period. The group-level capacity limit is the maximum number of appointments allowed for each shared capacity group in each fixed time period. For example, if the capacity limit for a shared capacity group is one, it means that only one appointment can be accepted for all mapped items in that group during that time period. If the number of existing appointments plus one does not exceed the group-level capacity limit, it means that there are still available appointments for that time period. The server creates an appointment session and stores it in the database. If the number of existing appointments plus one exceeds the group-level capacity limit, it means that the appointments for that time period are full. The server rejects the appointment creation request and returns a message indicating that the appointments are full, while also providing an overbooking risk score for staff reference. Through this group-level hard constraint mechanism of shared capacity groups, multiple treatment items are mapped to the same appointment counter and group-level capacity hard constraints are implemented, effectively preventing the implicit overbooking problem caused by different items counting independently.

[0075] After a reservation session is successfully created, the target user's user token is obtained. The hash value of this user token is combined with the session identifier of the reservation session, the time information of the target fixed time period, and the initial stage version to form a binding tuple. An initial stage sub-token is then derived from this binding tuple through a keyed hash operation. The construction of the binding tuple is completed in the server's memory, without any network transmission, ensuring the confidentiality of the derivation process. The initial stage sub-token is the first stage credential of the reservation session, used for verification of the four elements during subsequent QR code check-in. The validity of this sub-token depends on the correct combination of the user token, reservation session, fixed time period, and stage version; any change in any of these elements will invalidate the sub-token.

[0076] During each legitimate state transition in the appointment session, the server derives the next-stage sub-token based on the current stage's sub-token and the event digest of the current transition event. For example, when transitioning from an "appointed" state to a "checked-in" state, the server combines the current stage's sub-token with the event digest of the check-in event, and derives the next-stage sub-token through a keyed hash operation. This chain-like derivation mechanism automatically invalidates the old stage sub-tokens and old fixed-time period sub-tokens that have completed the transition. Even if an attacker obtains a stage's sub-token, they cannot deduce the next stage's sub-token because the derivation process relies on the combination of the previous stage's sub-token and the event digest, and the event digest contains complete information about the current transition. Through this design, the sub-token chain corresponding to the old fixed-time period becomes invalid after a rescheduling. Upon check-in, a rescan returns the same idempotent result without duplicate queuing. Incorrect users, dates, time periods, or stages will all fail server-side verification. After completing the above appointment creation process, staff inform the user of the appointment date and fixed time period. The user then presents a static QR code at the hospital at the agreed time to complete the check-in.

[0077] Furthermore, you can also view Figure 5 , Figure 5 This is a flowchart illustrating the fourth embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 5 Before the step of obtaining the quantitative scoring result in the audit evidence, steps S160~S200 are further included: Step S160: Obtain the expected state of the actual migration object in the expected migration path of the current state migration event, and compare the consistency between the actual state and the expected state to determine the degree of state matching deviation. Step S170: Determine the degree of path deviation based on the difference between the actual migration path of the current state migration event and the preset shortest expected migration path; Step S180: Determine the degree of time window deviation based on the degree of deviation between the actual occurrence time of the current state transition event and the expected execution time window corresponding to the reservation session; Step S190: Determine the degree of deviation of the context constraint based on the degree of satisfaction of the context conditions involved in the current state transition event. The context conditions include the matching of the user token with the user identity recorded in the appointment session, whether the treatment order is in a valid open state, whether the remaining number of treatment orders is greater than zero, the consistency of the appointment session with the fixed time period, and whether the nurse account is in a valid enabled state. Step S200: Assign weights to the deviation degree of state matching, path deviation degree, time window deviation degree, and context constraint deviation degree respectively, and perform weighted summation to obtain a comprehensive deviation value. Map the comprehensive deviation value to a percentage score to obtain the quantitative score result.

[0078] This embodiment defines the specific calculation method for the quantitative scoring result. Specifically, after the server confirms that no duplicate submissions or causal reversal events are found, and before executing the step of obtaining the quantitative scoring result from the audit evidence, the server needs to calculate the degree of deviation from four dimensions respectively, and then weight and synthesize the deviation degrees to obtain the final quantitative scoring result. This quantitative scoring mechanism replaces the traditional binary legal or illegal determination method, providing a continuous quantitative measure of the credibility of state transitions.

[0079] Based on the actual migration object of the current state transition event, the expected state of that actual migration object in the expected migration path is obtained, and the consistency between the actual state and the expected state is compared to determine the degree of state matching deviation. The expected migration path is an ideal migration route predefined for different state machines according to the business scenario. For example, the main path for a regular appointment is from the initial state to the booked state to the checked-in state to the completed state, and the cancellation path is from the booked state to the cancelled state or from the checked-in state to the cancelled state. If the actual migration object of the current state transition event is a reservation session, the server starts from the current state of the reservation session, finds the next expected state of that state in the expected migration path, and compares the consistency between the next expected state and the actual migration target state. If the actual migration target state is consistent with the expected state, the degree of state matching deviation is low; if the actual migration target state deviates from the expected state, for example, from the booked state to the cancelled state and the expected path does not contain this migration branch, the degree of state matching deviation is high. This degree of deviation is normalized to between zero and one, where zero represents a perfect match and one represents a complete deviation.

[0080] The path deviation is determined by comparing the actual migration path of the current state transition event with the preset shortest expected migration path. The shortest expected migration path is the legal path that traverses the fewest state nodes from the starting state to the ending state. For example, a direct migration from the initial state to the completed state skips the intermediate states of "reserved" and "reported," resulting in a path length of one, while the shortest expected path has a length of three, indicating a difference. The server determines the path deviation by comparing the difference in the number of state nodes and the path shape between the actual migration path and the shortest expected path. If the actual migration path is completely identical to the shortest expected path, the path deviation is zero; if the actual migration path differs significantly from the shortest expected path, such as including unexpected branch states or skipping multiple necessary states, the path deviation is high.

[0081] The degree of time window deviation is determined based on the deviation between the actual occurrence time of the current state transition event and the expected execution time window corresponding to the appointment session. Each appointment session is assigned a fixed execution period upon creation, which is the time window during which users can check in and receive treatment. The server obtains the timestamp of the actual occurrence of the current state transition event and compares it with the deviation between this timestamp and the start and end times of the expected execution time window corresponding to the appointment session. If the actual occurrence time falls within the expected execution time window, the time window deviation is zero; if the actual occurrence time is earlier than the window start time or later than the window end time, the degree of deviation is determined based on the proportion of the deviation duration to the total window duration, with a larger deviation proportion indicating a higher degree of time window deviation.

[0082] The degree of deviation from the context constraints is determined based on the satisfaction of the context conditions involved in the current state transition event. The context conditions include five indicators: the matching of the user token with the user identity recorded in the appointment session (confirming whether the currently scanned user token truly belongs to the user corresponding to the appointment session); whether the treatment order is in a valid open state (confirming that the treatment order has not been cancelled or completed); whether the remaining treatment attempts are greater than zero (confirming that the user still has available treatment attempts); the consistency between the appointment session and the fixed time period (confirming that the fixed time period corresponding to the appointment session is consistent with the time period expected by the current operation); and whether the nurse account is in a valid enabled state (confirming that the nurse account executing the operation exists and has not been deactivated). The server checks each of the above five context conditions and calculates the proportion of unmet conditions to the total number of conditions; this proportion represents the degree of deviation from the context constraints.

[0083] Weights are assigned to the deviations in state matching, path deviation, time window deviation, and context constraint deviation, and then weighted and summed to obtain a comprehensive deviation value. The specific values ​​of each weight are pre-configured by the system, and the sum of the weights is one. For example, state matching deviation and context constraint deviation, because they are directly related to business correctness, can be assigned higher weights, while path deviation and time window deviation are assigned relatively lower weights. The server maps the weighted summed deviation value to a percentage score. The mapping method is to subtract the deviation value multiplied by one hundred from one hundred, thus obtaining a quantitative score result. This quantitative score result ranges from 0 to 100. A higher score indicates a higher consistency between the state transition and the expected transition path, while a lower score indicates a greater degree of deviation. The server determines the transition handling level based on the value range of this quantitative score result. For example, 90 to 100 points corresponds to the first value range, 70 to 89 points to the second value range, 40 to 69 points to the third value range, and 0 to 39 points to the fourth value range. By calculating and weighting the deviation from the above multiple dimensions, the system can accurately measure the credibility of each state transition, providing a quantitative basis for subsequent graded handling decisions.

[0084] Furthermore, you can also view Figure 6 , Figure 6 This is a flowchart illustrating the fifth embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention. Figure 6 Prior to the step of responding to the user token submitted by the QR code reader, the method further includes steps S210-S230: Step S210: In response to the backup request submitted by the administrator terminal, a database backup file is generated through a database consistency snapshot. The backup file includes at least user account information, user profile information, treatment order information, appointment record information, execution record information, and audit log information. Step S220: Upon receiving the import request submitted by the administrator terminal on the target device, the backup file is subjected to a series of comprehensive verification steps in sequence. If the verification passes, a timestamp-marked rollback copy is created with the current database of the target device as the target, and the backup file is imported into the target device in an atomic replacement manner and incremental structure migration is performed. The verification steps include file header validity verification, page integrity verification, foreign key constraint verification, core data table existence verification, and database version compatibility verification. Step S230: If any step fails to verify or import, retain the current database of the target device and maintain the original data of the current database. Return error information containing the reason for failure to the administrator terminal. When all verifications pass and the import is successful, clear the old login session records of the target device, write the operator account, import time and source summary of the backup file of this import operation into the audit log, and restore business services.

[0085] This embodiment defines the specific implementation method of complete database backup and cross-device migration. Before the scan check-in step is executed, the system may need to migrate data between different computers. For example, when the department changes computers or the server environment changes, the backup import mechanism ensures that all accounts, users and event chains can continue on another computer.

[0086] The system executes a database backup operation in response to a backup request submitted by the administrator terminal. After the administrator clicks the backup button in the system management interface, the administrator terminal sends a backup request to the server. Upon receiving the backup request, the server generates a database backup file using a database consistency snapshot. This consistency snapshot is generated through the SQLite online backup interface or an equivalent method, ensuring that all data in the backup file is at the same transaction point in time, avoiding inconsistencies caused by data changes during the backup process. The backup file contains at least user account information, user profile information, treatment order information, appointment record information, execution record information, and audit log information, as well as stage keys, TCC reserved records, and system sequences. The backup file is saved in a single database file format for easy download and transfer between different devices by the administrator.

[0087] Upon receiving an import request submitted by the administrator terminal on the target device, the server sequentially performs a comprehensive verification process on the backup file. Before the import process begins, the server locks the write entry point of the target database to prevent new business operations from writing data during the import process. The server writes the uploaded backup file to an isolated temporary directory to prevent path traversal attacks. Then, it sequentially performs file header validity verification to confirm that the uploaded file is in a valid SQLite database file format; performs page integrity verification to confirm that all pages in the database are undamaged, corresponding to the PRAGMAintegrity_check command; performs foreign key constraint verification to confirm that all foreign key relationships in the database are correct, corresponding to the PRAGMAforeign_key_check command; performs core data table existence verification to confirm that the backup file contains all core data tables necessary for system operation, such as the user table, treatment order table, appointment table, execution record table, and audit event table; and performs database version compatibility verification by reading the schema_version field in the backup file and comparing it with the current system version to confirm compatibility. If all the above checks pass, the server creates a timestamp-stamped rollback copy of the target device's current database. This copy uses the current timestamp as the filename suffix and creates a complete copy of the current database as a rollback backup. The server then imports the backup file into the target device using atomic replacement. Atomic replacement is an operating system-level file renaming operation that either executes completely or not at all, with no intermediate state. After the import is complete, incremental structure migration is performed, completing the index and trigger definitions of the target database to ensure the database structure is consistent with the expected structure of the current running version.

[0088] If any of the above steps fails verification or import fails, the current database of the target device is retained, and the original data in the current database is maintained. No write or replace operations are performed, and an error message containing the reason for the failure is returned to the administrator terminal. This design ensures that even if an anomaly occurs during the import process, the original business data on the target device will not be lost. When all verifications pass and the import is successful, the server clears the old login session records of the target device, requiring all users to log in to the system again to avoid mismatch between the old session and the imported data state. The server writes the operator account, import time, and source summary of the backup file for this import operation to the audit log, forming a complete import audit record. The version handshake mechanism works in conjunction with the import process. The desktop launcher reads the backend version number and compares it with the built-in frontend version. When the versions are inconsistent, it automatically prompts or restarts the current version service to prevent mismatches in statistical fields, file sequences, or recovery processes caused by page calls to old interfaces after the upgrade. After the above import process is completed, business services are restored. The original administrator and staff accounts, file number sequences, user QR codes, remaining treatment times, nurse workload, and event chains can still be used, achieving complete data continuity from one computer to another.

[0089] Furthermore, you can also view Figure 7 , Figure 7 This is a flowchart illustrating the sixth embodiment of the closed-loop management method for pelvic floor rehabilitation therapy of the present invention, based on the shown... Figure 7 Before the step of responding to the execution confirmation request submitted by the nurse terminal based on the treatment queue, the method further includes steps S240-S250: Step S240: When the type of treatment item corresponding to the reported status is a preset functional screening type, a structured screening result input interface corresponding to the treatment item is provided to the staff terminal. The structured screening result input interface includes at least one electromyography score input field and multiple anatomical site separation measurement value input fields. The multiple anatomical sites include at least the supraumbilical site, the umbilical site, and the subumbilical site. Step S250: Receive the structured screening results submitted by the staff terminal, bind and store the structured screening results with the treatment order identifier of the treatment project and the user identifier of the user, and record the staff's account information and entry time.

[0090] This embodiment defines the specific implementation method of structured recording of functional screening results. Before the nurse selects a user from the treatment queue and submits an execution confirmation request, if the treatment item received by the user is a preset functional screening type, an additional screening result entry function needs to be provided to ensure the complete collection of clinical data.

[0091] When the treatment item corresponding to the reported status is a preset functional screening type, the server provides the staff terminal with a structured screening result entry interface corresponding to that treatment item. The preset functional screening type refers to a pelvic floor function screening and assessment item, which is marked in the system configuration as a specific type requiring the collection of screening result data. The server determines whether to display the screening result entry interface based on the treatment item type identifier; other treatment items, such as pelvic floor electromyography (EMG) therapy and vaginal radiofrequency therapy, do not display this module. After determining it to be a functional screening type, the server pushes the data structure and rendering instructions for the structured screening result entry interface to the staff terminal, which then renders an entry interface containing multiple input fields. This structured screening result entry interface includes at least one EMG score input field and multiple anatomical site separation measurement input fields, with the multiple anatomical sites including at least the supraumbilical, umbilical, and subumbilical regions. Specifically, the data entry interface includes fields for pelvic floor electromyography (EMG) scores, supraumbilical rectus abdominis diastasis values, umbilical rectus abdominis diastasis values, subumbilical rectus abdominis diastasis values, and abdominal circumference. Staff can immediately fill in these results after the user completes the functional screening assessment. This interface is linked to the treatment plan; one treatment plan corresponds to one screening result entry, and the entered fields have explicit physical units, such as centimeters for diastasis values, ensuring the accuracy and consistency of clinical data. The triggering and display of this structured screening result entry interface are entirely controlled by the server based on the treatment type; staff do not need to manually select or switch modes.

[0092] The system receives structured screening results submitted by staff terminals, binds and stores these results with the treatment order identifier and user identifier, and records the staff's account information and entry time. After staff complete and confirm the submission of all screening data, the staff terminal organizes the entered structured screening results into a structured data message and submits it to the server. Upon receiving the data message, the server first verifies the correctness of the data format and numerical range of each input field, such as the numerical range of pelvic floor electromyography scores, the non-negativity of separation measurements of various parts, and the reasonable range of abdominal circumference. If the data format does not meet the preset requirements, an error message is returned and a request for re-entry is made. After successful verification, the server stores each field value in the structured screening result according to the preset data structure in the screening result table of the database, and associates the screening result record with the treatment order identifier and user identifier to ensure that the corresponding screening result can be accurately retrieved through the user identifier or treatment order identifier in subsequent queries. At the same time, the server records the staff's account information and entry time for the current operation, forming complete entry audit information. Once stored, screening results can be retrieved in subsequent clinical queries and statistics. Query dimensions include user name, file number, hospital number, or medical card number. Administrators can export the entire screening history of a single user or the screening records of all users. Through this structured input and storage design, functional screening data achieves structured management throughout the entire process from collection to storage, providing a standardized data foundation for subsequent clinical analysis and statistical reports.

[0093] Furthermore, you can also view Figure 8 , Figure 8 This is a schematic diagram of the closed-loop and trusted control architecture of the intra-institutional local area network of the present invention. Figure 8 The indicated data processing method runs in the hospital's local area network environment. The system as a whole adopts a closed-loop trusted control architecture, and the data processing logic of this architecture is as follows.

[0094] Users do not run any mobile applications; the QR code only serves as a user identification input. Each user's unique QR code exists by pasting it onto a paper file or keeping a photograph of it. Staff members complete all operations such as file creation, order processing, appointment scheduling, check-in, and execution on the terminal. The entire business process is completed within the hospital's data boundaries, involving data management functions such as account management, user files, comprehensive statistics, and complete backup and migration.

[0095] When scanning the QR code for check-in, the HID QR code reader submits the QR code content via keyboard input and automatically sends an Enter key, completing a full identity verification input. Upon receiving this input, the staff terminal sends the user token contained in the QR code to the local area network's trusted session layer. The trusted session layer performs security controls such as login authentication, CSRF (Cross-Site Request Forgery) protection, identity token matching verification, appointment session and fixed time period verification, and request rate limiting to ensure that every request entering the system originates from a legitimate logged-in terminal and is within a valid session period.

[0096] After passing the security verification of the trusted session layer, the request enters the system's decision engine cluster for processing. The FSM consistency deviation scoring module calculates a quantitative score and determines the migration handling level for each scheduled state transition event based on the degree of matching between the actual and expected states, the degree of deviation between the actual and expected migration paths, the degree of conformity between the migration time and the expected time window, and the degree of satisfaction of context constraints. The chained credential tuple binding and HMAC module combines the user token's hash value, the scheduled session identifier, the time information of a fixed time period, and the initial stage version into a binding tuple during appointment creation. It then derives an initial stage sub-token through a keyed hash operation. During each legitimate state transition, it derives the next stage sub-token based on the current stage sub-token and the event digest of the current transition event, automatically invalidating the old stage sub-token and the old fixed time period sub-token that have already been migrated. The event causality vector clock module records the causal time sequence information and idempotency flag corresponding to each state transition event. It identifies duplicate submission events by comparing idempotency flags and identifies causal inversion events by comparing causal time sequence information. The conflict risk isolation and optimization module and the TCC module calculate the conflict risk value before appointment creation and determine the transaction processing strategy based on the risk value. When anomalies occur, they trigger compensatory transaction processing to automatically repair abnormal situations such as reserved resources being suspended, partial submissions, resource leaks, and deviations in clinical counts. The supply and demand matching module predicts the demand for candidate time slots and derives recommended additional appointment quotas based on real-time arrival rate, completion rate, no-show rate, historical arrival distribution, waiting queue, and current availability. When the sample is insufficient, it automatically switches to a safe fallback time slot.

[0097] All data generated during the processing of each decision engine is ultimately persisted in a local SQLite event ledger and relational database. This database contains user profile information, treatment order information, appointment record information, execution record information, screening result information, personnel information, appointment group configuration information, audit log information, and backup file information. All data is stored and accessed within the local area network, without relying on external networks or cloud services, ensuring the security and controllability of clinical data. Through this data processing architecture, the system achieves closed-loop management of the entire process from user registration, appointment creation, QR code check-in, treatment execution to data backup and migration.

[0098] This application provides a closed-loop management device for pelvic floor rehabilitation therapy, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the closed-loop management method for pelvic floor rehabilitation therapy described in Embodiment 1 above.

[0099] The following is for reference. Figure 9 This document illustrates a structural schematic diagram of a closed-loop management device for pelvic floor rehabilitation therapy suitable for implementing embodiments of this application. The closed-loop management device for pelvic floor rehabilitation therapy in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 9 The pelvic floor rehabilitation closed-loop management device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0100] like Figure 9As shown, the pelvic floor rehabilitation closed-loop management device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the pelvic floor rehabilitation closed-loop management device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the pelvic floor rehabilitation closed-loop management device to exchange data with other devices wirelessly or via wired communication. Although the figure shows a pelvic floor rehabilitation closed-loop management device with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0101] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0102] The pelvic floor rehabilitation treatment closed-loop management device provided in this application, employing the pelvic floor rehabilitation treatment closed-loop management method in the above embodiments, can solve the technical problem in existing pelvic floor rehabilitation management where static QR codes cannot be correctly identified when scanned outside of valid appointment time slots or at incorrect stages, leading to incorrect registration or duplicate queuing. Compared with the prior art, the beneficial effects of the pelvic floor rehabilitation treatment closed-loop management device provided in this application are the same as those of the pelvic floor rehabilitation treatment closed-loop management method provided in the above embodiments, and other technical features in this pelvic floor rehabilitation treatment closed-loop management device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0103] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0104] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0105] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the closed-loop management method for pelvic floor rehabilitation treatment in the above embodiments.

[0106] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0107] The aforementioned computer-readable storage medium may be included in the pelvic floor rehabilitation closed-loop management device; or it may exist independently and not assembled into the pelvic floor rehabilitation closed-loop management device.

[0108] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the pelvic floor rehabilitation closed-loop management device, enable the pelvic floor rehabilitation closed-loop management device to implement the technical content of the pelvic floor rehabilitation closed-loop management method embodiment shown above.

[0109] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0111] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0112] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described closed-loop management method for pelvic floor rehabilitation treatment. This solves the technical problem in existing pelvic floor rehabilitation management where static QR codes cannot be correctly identified when scanned outside of valid appointment periods or at incorrect stages, leading to incorrect registration or duplicate queuing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the closed-loop management method for pelvic floor rehabilitation treatment provided in the above embodiments, and will not be elaborated upon here.

Claims

1. A closed-loop management method for pelvic floor rehabilitation therapy, characterized in that, When applied to a server, the following steps are included: In response to a user token submitted by a QR code reader, the user is located using the user token, and the user's appointment session for the current date is queried. Extract the fixed time period and current stage corresponding to the appointment session, and verify the binding relationship between the user token, appointment session, fixed time period and sub-token corresponding to the current stage based on the extraction results. After the verification is successful, the appointment status is changed to the checked-in status and the appointment is entered into the treatment queue. Based on the execution confirmation request submitted by the nurse terminal in response to the treatment queue, the validity of the nurse account on the nurse terminal and the remaining number of treatment orders for the user are verified. After the verification is successful, an execution record is added to the same database transaction, the appointment status is changed to the completed status, and the number of times the treatment order has been used is incremented. Obtain the appointment status transition event and generate audit evidence corresponding to the appointment status transition time; Based on the audit evidence, abnormal events are identified. When no abnormal events are found, the quantitative scoring results in the audit evidence are obtained. The migration handling level is determined according to the value range of the quantitative scoring results. The abnormal events include duplicate submission events and causal reversal events. The corresponding processing strategy is executed according to the migration handling level. Specifically, when the quantitative scoring result is in the first value range, the state migration is completed and the quantitative scoring result is recorded; when the quantitative scoring result is in the second value range, the state migration is completed and marked as pending audit status, and a review prompt is sent to the management terminal; when the quantitative scoring result is in the third value range, the current state migration is paused, compensation transaction processing is triggered, and a handling suggestion is sent to the management terminal; when the quantitative scoring result is in the fourth value range, the current state migration request is rejected, state migration evidence is retained, and a high-priority audit alarm is triggered. The numerical ranges of the first, second, third, and fourth value ranges decrease sequentially and do not overlap.

2. The method as described in claim 1, characterized in that, Prior to the step of responding to the user token submitted by the QR code reader, the method further includes: In response to a user profile creation request submitted by a staff member's terminal, a profile number corresponding to the user and a random user token associated with the profile number are generated. The profile number is assigned sequentially from an independent sequence in natural number order and does not reuse archived historical numbers. The user token is a high-entropy random string and does not contain the user's name or contact number. The file number and the user token are sent to the staff terminal. The staff terminal encodes the user token into a static QR code and outputs it. The static QR code does not contain the user's name or contact number, nor does it contain any plaintext information related to the appointment. Record the operator's account, filing time, and user token generation time of the staff terminal to form a user filing audit record.

3. The method as described in claim 2, characterized in that, Prior to the step of responding to the user token submitted by the QR code reader, the method further includes: In response to an appointment creation request submitted by a staff member's terminal, the appointment creation request includes the target user's user ID, the target treatment item, the target appointment date, and the target fixed time period, and verifies whether the target user's remaining treatment slots are greater than or equal to one. When the remaining number of treatments for the treatment order is greater than or equal to one, the target shared capacity group to which the target treatment item belongs is determined based on the target treatment item, and the number of existing appointments in the target shared capacity group during the target fixed time period is queried. Compare whether the number of existing reservations plus one exceeds the group-level capacity limit of the target shared capacity group during the target fixed time period. If it does not exceed the limit, create the reservation session. Obtain the user token of the target user, combine the hash value of the user token with the session identifier of the reservation session, the time information of the target fixed time period and the initial stage version into a binding tuple, and derive the initial stage sub-token from the binding tuple through a keyed hash operation; During each legitimate state transition of the scheduled session, a sub-token for the next stage is derived based on the sub-token of the current stage and the event digest of the current transition event, causing the old stage sub-token and the old fixed time period sub-token that have completed the transition to automatically become invalid.

4. The method as described in claim 1, characterized in that, The step of identifying abnormal events based on the audit evidence includes: Compare the first idempotent identifier corresponding to the current state transition request with the second idempotent identifier in each versioned event stored in history. When the first idempotent identifier matches any of the second idempotent identifiers, the current state transition request is determined to be a duplicate submission event. When the first idempotent identifier is inconsistent with all the second idempotent identifiers, the first causal time sequence information corresponding to the current state transition request is extracted, and the first causal time sequence information is compared with the second causal time sequence information in each historical versioned event. When the causal relationship order indicated by the first causal time sequence information is contrary to the causal relationship order indicated by the second causal time sequence information, the current state transition request is determined to be a causal inversion event. When the first idempotency identifier is inconsistent with all the second idempotency identifiers and the causal relationship order of the first causal time sequence information is not contradictory to that of all the second causal time sequence information, it is confirmed that no duplicate submission event or causal inversion event is found, and the step of obtaining the quantitative scoring result is executed.

5. The method as described in claim 1, characterized in that, Before the step of obtaining the quantitative scoring results in the audit evidence, the method further includes: Obtain the expected state of the actual migration object in the expected migration path of the current state migration event, and compare the consistency between the actual state and the expected state to determine the degree of state matching deviation. The degree of path deviation is determined based on the difference between the actual migration path of the current state transition event and the preset shortest expected migration path; The degree of deviation of the time window is determined based on the degree of deviation between the actual occurrence time of the current state transition event and the expected execution time window corresponding to the reservation session; The degree of deviation from the context constraints is determined based on the degree to which the context conditions involved in the current state transition event are met. The context conditions include the matching of the user token with the user identity recorded in the appointment session, whether the treatment order is in a valid open state, whether the remaining number of treatment orders is greater than zero, the consistency between the appointment session and the fixed time period, and whether the nurse account is in a valid enabled state. The deviations of state matching, path, time window, and context constraint are assigned weights and summed to obtain a comprehensive deviation value. The comprehensive deviation value is then mapped to a percentage score to obtain the quantitative score result.

6. The method as described in claim 1, characterized in that, The steps of pausing the current state migration, triggering compensation transaction processing, and sending handling suggestions to the management terminal include: When a reserved resource is detected to be in a created but unconfirmed state, it is determined whether the time interval between the creation time of the reserved resource and the current time exceeds the validity period. If the validity period has not been exceeded, a confirmation instruction is resent to the database to restore the reserved resource. If the validity period has been exceeded, a release instruction is sent to the database to clear the reserved resource and the resource release event is recorded. When it is detected that the confirmation operation has been successfully executed but the corresponding target write operation is missing, the corresponding write position is searched in the database according to the idempotency flag carried by the confirmation operation. If the write position exists and can be written, the target write operation is written. If the write position cannot be written, a rollback confirmation instruction is sent to the database to cancel the confirmation operation. When it is detected that the target reservation has been cancelled but the reserved resources corresponding to the target reservation are still occupied, a release command is sent to the database to clear the reserved resources, and a resource leakage event between the reserved resources and the target reservation is recorded. When it is detected that the execution record has been successfully written to the database but the number of times the treatment order has been used has not been synchronously increased, under the hard constraint that the remaining number of times in the database is greater than zero, the instruction to increase the number of times is resent to the database until the number of times the treatment order has been used is consistent with the number of execution records or the remaining number of times the treatment order is zero.

7. The method as described in claim 1, characterized in that, Prior to the step of responding to the user token submitted by the QR code reader, the method further includes: In response to a backup request submitted by the administrator terminal, a database backup file is generated through a database consistency snapshot. The backup file contains at least user account information, user profile information, treatment order information, appointment record information, execution record information, and audit log information. Upon receiving an import request submitted by the administrator terminal on the target device, the backup file is subjected to a series of comprehensive verification steps in sequence. If the verification passes, a timestamp-marked rollback copy is created with the current database of the target device as the target, and the backup file is imported into the target device in an atomic replacement manner and incremental structure migration is performed. The verification steps include file header validity verification, page integrity verification, foreign key constraint verification, core data table existence verification, and database version compatibility verification. If any step fails to verify or import, the current database of the target device is retained and the original data of the current database is maintained. An error message containing the reason for the failure is returned to the administrator terminal. When all verifications pass and the import is successful, the old login session records of the target device are cleared, and the operator account, import time and source summary of the backup file for this import operation are written to the audit log to restore business services.

8. The method as described in claim 1, characterized in that, Before the step of responding to the execution confirmation request submitted by the nurse's terminal based on the treatment queue, the method further includes: When the type of treatment item corresponding to the reported status is a preset functional screening type, a structured screening result input interface corresponding to the treatment item is provided to the staff terminal. The structured screening result input interface includes at least one electromyography score input field and multiple anatomical site separation measurement value input fields. The multiple anatomical sites include at least the supraumbilical site, the umbilicus, and the subumbilical site. The system receives the structured screening results submitted by the staff terminal, binds and stores the structured screening results with the treatment order identifier of the treatment project and the user identifier of the user, and records the staff's account information and the entry time.

9. A closed-loop management system for pelvic floor rehabilitation therapy, characterized in that, The system is deployed in the hospital's local area network environment and includes: The user management module is used to generate a file number and a random user token in response to the basic user information submitted by the staff terminal, and send the user token to the staff terminal for encoding into a static QR code for output. The QR code does not contain the user's name, contact number, or appointment plaintext. The appointment management module is used to respond to the appointment creation request submitted by the staff terminal, verify the remaining number of treatments and the group-level capacity reserve of the shared capacity group to which the fixed time period belongs, and create an appointment session after the verification is successful and establish the binding relationship between the user token, the appointment session and the fixed time period, and derive sub-tokens based on the binding relationship. The check-in management module is used to respond to the user token submitted by the QR code reader, verify the binding relationship between the user token, the appointment session, the fixed time period and the sub-token, and after the verification is successful, change the appointment status to the checked-in status. The execution management module is used to respond to execution confirmation requests submitted by nurses' terminals, verify the validity of nurse accounts and the remaining number of treatments on the order. After the verification is successful, an execution record is added to the transaction and the appointment status and the number of treatments used are updated. The audit trail module is used to record each state transition as a versioned event. The versioned event includes at least an event type, version identifier, causal timing information and idempotency identifier, and identifies duplicate submissions and reversed causal situations based on the versioned events. The capacity control module is used to map multiple treatment items that occupy the same treatment resources to the same shared capacity group, set a group-level capacity limit for each shared capacity group at each fixed time period, and use database-level constraints to prevent concurrent over-occupancy. The data migration module is used to generate database backup files through consistent snapshots, and to sequentially verify the integrity, foreign key constraints and version compatibility of the backup files during import. After the verification is passed, the backup files are imported in an atomic replacement manner and a rollback copy is automatically created.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the closed-loop management method for pelvic floor rehabilitation therapy as described in any one of claims 1-8.

Images