A method for digital symptom monitoring and management

Abstract

The application provides a method based on digital symptom monitoring and management, relates to the fields of medical treatment and computer software, and aims to realize the coverage support of a digital symptom monitoring and management system platform in different scenes such as offline collection, multi-baseline whole-process management and patient repeated group management, and complete the implementation requirements of the digital symptom monitoring and management system platform. The method comprises the following steps: S1, after a data collection plan is issued, it is judged whether data can be collected online, if yes, online collection deployment is entered, otherwise offline collection deployment is entered; S2, after the online collection deployment or the offline collection deployment is completed, it is judged whether multi-baseline collection is performed, if yes, multi-baseline collection is performed, otherwise routine collection is performed; S3, after the multi-baseline collection or the routine collection is completed, it is judged whether repeated group entry is performed, if yes, after repeated group entry is completed, the step S2 is returned, otherwise, the step S4 is entered; and S4, a data collection plan is completed.

Description

Technical Field

[0001] This invention relates to the fields of medical and computer software, and in particular to a method for digital symptom monitoring and management. Background Technology

[0002] Symptom management for cancer patients is an integral part of the entire diagnosis and treatment process. The implementation of a digital symptom monitoring and management system platform for the entire treatment of specific diseases presents a variety of complex scenarios. Providing a unified digital management approach for both doctors and patients across these diverse scenarios is a prerequisite for the effective implementation of end-to-end digital management.

[0003] Traditional patient management platforms lack the ability to collect and process real-world data related to symptoms, and cannot meet the needs of electronic use based on patient-reported outcomes. Through meticulous design and technological means, a comprehensive support platform can be created to better suit actual clinical scenarios. This platform can support offline data collection, symptom tracking at different stages of patient care, effective tracking across multiple treatment cycles, and real-time monitoring of patient status based on symptom changes. It also allows for rapid intervention by healthcare professionals when symptom triage registration changes. These are key capabilities for the successful implementation of digital symptom management throughout the entire process.

[0004] Electronic Patient Reported Outcome (ePRO) is a digital means of enabling patients to evaluate their health status, quality of life, treatment outcomes, and related adverse reactions. ePRO data is collected through a series of standardized questionnaires. These questionnaires, as assessment tools, are structured within a clear conceptual framework and reflect various aspects of participants' symptoms, function, health status, and quality of life. They provide physicians with stronger references for diagnosis and treatment, and are of great significance to clinical practice.

[0005] However, existing technologies cannot meet the goal of practical implementation of digital symptom management. By introducing newer technologies and innovative solutions, we can achieve coverage and support for different scenarios such as offline data collection, multi-baseline end-to-end management, and patient re-enrollment management of the digital symptom monitoring and management system platform, fulfill the implementation requirements of the digital symptom monitoring and management system platform, and support the digital requirements of the above scenarios in terms of security, reliability, and usability. Summary of the Invention

[0006] This invention provides a method for digital symptom monitoring and management, aiming to achieve coverage and support for different scenarios such as offline data collection, multi-baseline end-to-end management, and patient re-enrollment management of the digital symptom monitoring and management system platform, thereby fulfilling the implementation requirements of the digital symptom monitoring and management system platform.

[0007] An embodiment of the present invention provides a method for digital symptom monitoring and management, comprising the following steps: S1. After the data collection plan is issued, it is determined whether data can be collected online. If so, online collection deployment is initiated; otherwise, offline collection deployment is initiated. S2. After the online or offline collection deployment is completed, it is determined whether to perform multi-baseline collection. If so, multi-baseline collection is performed; otherwise, regular collection is performed. S3. After the multi-baseline collection or regular collection is completed, it is determined whether duplicate enrollment is required. If so, duplicate enrollment is completed, and the process returns to step S2; otherwise, the process proceeds to step S4. S4. The data collection plan is completed.

[0008] Preferably, the offline data collection deployment described in step S1 specifically includes: when multiple terminals need to perform offline data collection simultaneously, and the collection items of each terminal need to be of a unified standard, the definition of the collection items and content will be uniformly defined on the central database platform. This supports centralized online synchronization and distributed offline data collection by the collection terminals, enabling synchronization of the project definition within the local area network. Then, offline data collection is used to collect stage data related to patient symptoms that meet the unified requirements of the project. Finally, the offline collected data is synchronously imported into the central platform through the local area network, enabling unified integration and analysis of medical and patient data on a single platform.

[0009] More preferably, the offline data collection deployment described in step S1 specifically includes: designing standardized electronic data forms for all data items, formats, field lengths, etc., involved in the project through the project backend management module; defining the required form structures and electronic data specifications in the system and saving them to the main server's SQL database table; simultaneously defining the frequency plan for patient data collection, with each frequency including a synchronization mechanism for the project structure on the collection terminal; the main server provides a RESTful API-based interface, including a request authentication mechanism carrying a token. After successful authentication, the form structure and collection plan definition for the corresponding project are synchronized to the local machine via a project template using a POST interface; when the "collection terminal" deployment mode is selected, the "collection terminal" system runs locally on the terminal, and access on the local machine uses HTTPS to ensure data security; the server's LAN IP address is set on the collection terminal, and when the data collection application needs to synchronize the project structure, LAN communication is conducted via an HTTP RESTful interface to remotely synchronize the basic data on the main server and distribute it to the collection terminal; during the import process, standard RESTful APIs are still used. The API interface performs token authentication with the main server, establishes a file stream via POST requests, and uploads the compressed data file to the main server. The backend writes the data to a structured database through a standard interface. Each data write is validated for format and value to ensure data quality. The main server automatically decompresses the uploaded ZIP file, reads the data from the CSV file, and saves it to the corresponding SQL database table based on the field ID. The main server's data management application can record and query the data synchronization of the acquisition terminals. When an acquisition terminal uploads data to the main server through synchronization, an upload record is generated in the SQL database, including the time, acquisition terminal ID, number of synchronized data, and number of attachments. When a user opens the main server interface, the front-end page retrieves dynamic, synchronized upload records via a standard HTTP interface and displays these entries on the page for administrator confirmation. The main server stores the uploaded data and indexes it according to each patient's ID. Finally, it outputs the data in a file according to the agreed-upon file data format, facilitating the aggregation of continuously updated data before synchronous storage on the central data platform. The exported data is encrypted using RSA encryption and signed with a CA certificate to ensure data integrity and reliability. Online synchronization uses HTTPS with SSL encryption to ensure data is not intercepted during transmission.

[0010] Preferably, step S2, which involves multi-baseline acquisition, specifically includes: transforming the overall management plan into a collection queue of multiple baselines through multi-baseline acquisition; promptly adjusting the patient's status time when adjustments are needed; automatically adjusting the collection plan based on the new time and updating the patient's symptom information through frequency baseline correlation; and automatically adjusting all collection plans, statistical analyses, etc., for the phase starting from that time each time the baseline time is adjusted, enabling changes to the symptom management plan under dynamic changes in the patient's condition, and supporting multiple adjustments to the baseline.

[0011] More preferably, step S2, which involves multi-baseline data collection, specifically includes: comparing the planned dates in the database to determine whether the frequency of patient reports has been affected; comparing the content items of each stage of the collection plan to confirm whether the affected answered frequency questions can be moved and reassigned to a new frequency; if there is no impact, a new collection plan is generated; alternatively, a clear button can be used to allow patients to answer questions again according to the new collection plan. The background SQL database will save the data as a history and set the answered status label to empty, allowing data to be rewritten; the system platform provides historical data processing functions. If there is an impact, the system needs to process the historical data of the affected frequencies. For saving and processing, the system provides researchers with a menu for manual operation. Here, medical staff need to manually determine whether the affected completed questionnaires need to be resubmitted for evaluation. If so, the status of the completed questionnaires will be reset, and the collection plan will be retried to allow patients to answer new questions. If it is believed that the completed questionnaires at this frequency can be retained or moved, and the new frequency content contains the items of the answered questions, a move button will appear. Researchers can click to move the content of the completed questionnaires to a new frequency, and the background SQL database will assign the frequency pointer to the corresponding new frequency, giving this questionnaire a new frequency label.

[0012] Preferably, the repeated enrollment in step S3 specifically includes: supporting periodic treatment status, providing patients with multiple periodic symptom management sessions, allowing patients to choose to re-enroll at any time without having to re-enter the patient's basic information, returning the patient's symptom management to the initial state, the system will recalculate the collection plan for the new enrollment, trigger a new reminder message timed task, push new assessment questionnaires to the patient on time, and simultaneously conduct horizontal comparisons of symptom management data from multiple periods; when a patient is selected to re-enroll, the patient's management collection plan will report symptoms from the initial enrollment state.

[0013] More preferably, the repeated enrollment in step S3 specifically includes: providing an independent record ID for each individual patient for continuous system recording; for some patients requiring repeated treatment, when comparing data from each treatment cycle, the system platform provides a re-enrollment function and introduces a "enrollment count" label; on the patient management page, the doctor clicks the re-enrollment button, and the front end sends the re-enrollment request to the back end via an HTTP interface; the back end service will terminate all collection plans for the current patient, increment the patient's enrollment count field by 1 in the SQL database table, and reset all collection plan forms, including the patient's collection status, to prepare for the patient's re-collection of data; in the database, the same field is distinguished in different enrollment cycles based on the enrollment count, facilitating front end query display and data export; simultaneously, combined with multiple baselines, the status of the patient's incomplete collection plan is ended, and basic configuration is performed for the patient's symptom collection plan; based on the project type, it is determined whether the project is a multi-baseline collection project; if it is a multi-baseline project, it will proceed to multi-baseline collection, executed according to the above implementation of multi-baseline collection, and the back end can associate the enrollment data of the same patient from different times.

[0014] This invention presents a method for digital symptom monitoring and management, based on evidence-based medicine, using software to provide patients with digital product services for comprehensive management both inside and outside the hospital. By leveraging mobile internet technology for refined management of patient-reported symptom data, it innovatively implements a technical solution that closely aligns with real-world clinical scenarios, making this digital management model more applicable to real-world situations and more flexible and effective. The digital symptom monitoring and management system platform provides patients and doctors with digital channels for symptom and diagnostic communication through comprehensive symptom management for both in-hospital and out-of-hospital patients. This addresses the complexity and breadth of application implementation, compensates for the shortcomings of traditional patient management, integrates with clinical workflows, and ensures that real-world data truly becomes an essential tool for clinical patient diagnosis and treatment. Attached Figure Description

[0015] Figure 1-4 This is a flowchart of the method for digital symptom monitoring and management according to Embodiment 1 of the present invention. Detailed Implementation

[0016] Example 1: A method for digital symptom monitoring and management in this example, see [link to example]. Figure 1-4As shown, the process includes: after the data collection plan is issued, determining whether online data collection is possible; if so, proceeding to online data collection deployment; otherwise, proceeding to offline data collection deployment; after the online or offline data collection deployment is completed, determining whether to perform multi-baseline data collection; if so, performing multi-baseline data collection; otherwise, performing regular data collection; after the multi-baseline or regular data collection is completed, determining whether there is duplicate data inclusion; if so, completing the duplicate data inclusion and returning to determine whether to perform multi-baseline data collection; otherwise, completing the data collection plan. It should be noted that... Figure 1 The online data acquisition deployment and conventional data acquisition are both existing technologies, so they will not be described in detail here. Only the offline data acquisition deployment, multi-baseline acquisition, and repeated grouping are described in detail, including the following main steps:

[0017] 11. Offline data collection and deployment

[0018] In practical applications of patient symptom management, patients can use smart terminals outside the hospital to report their symptom-related data via an application. However, there are still scenarios where medical staff need to obtain patient data through follow-up visits. In some cases, medical staff terminals may not have internet access, or the network quality may be substandard or unstable, limiting data collection. To achieve full-scenario coverage and end-to-end symptom management, the digital symptom monitoring and management system platform innovatively utilizes offline data collection capabilities as a supplement to online symptom management, supporting these scenarios. Without changing the usage model, an HTTP service and a local SQL database are deployed on the collection terminal, allowing users to run independent web applications for data collection and storage. When multiple terminals need to collect data offline simultaneously, the collection items for each terminal must be standardized. Therefore, the definition of collection items and content is unified on the central database platform. This supports a "centralized online synchronization, distributed offline collection" approach, synchronizing project definitions within a local area network (LAN). Then, the offline data collection capabilities of the digital symptom monitoring and management system platform are used to collect stage-specific data related to patient symptoms, meeting the unified requirements of the project. Finally, the offline data is synchronously imported into the central platform via the LAN. This solves the problems of non-standard offline data collection and the need for individual modifications to each terminal in case of dynamic changes. Patient and medical data can be uniformly integrated and analyzed on a single platform, achieving data consistency, continuity, and completeness. Even offline, the system can meet the goal of full-process symptom management. The symptom management offline collection system is deployed on laptops, adapting to mobile usage scenarios. During use, the system deployment can be configured and modified to various modes, such as a collection terminal or a central main server. Furthermore, centralized data synchronization between different collection terminal deployments and the central deployment can be achieved through file transfer or network synchronization. Meanwhile, with data security becoming increasingly important, we have adopted strict encryption methods when synchronizing data between different deployment modes to ensure data security.

[0019] In practical implementation, in addition to considerations of data security and network security, the digital symptom monitoring and management system platform expands its coverage, enabling regions and groups that were previously unable to conduct online digital symptom management to not only complete data collection through offline support, but also combine offline data with online data from normal patients to achieve the goal of full-process symptom management.

[0020] The system platform employs a two-tier architecture: a main server and data acquisition terminals. These two components can operate independently but must work together to ensure the consistency and validity of the collected data. The platform enables offline data acquisition and end-to-end online and offline management, digitizing patient information, including structured and unstructured data and files, achieving standardized electronic data storage. When there is a need for centralized data aggregation, network synchronization ensures data collection and uploading, storing the data in a central database. In this digital symptom monitoring and management system platform implementation scenario, security and reliability are also considered. By using cloud-native Docker as the underlying platform, the deployment and readiness cycle of the offline data acquisition system is accelerated. Furthermore, a microservice framework is designed for data services, ensuring that updates to the data model do not require updates to the entire service.

[0021] During the deployment of the digital symptom monitoring and management system platform software, the administrator can select "Main Server" as the "Deployment Mode" based on deployment resources, and install the corresponding software system on the main server. The main server is the core backend management platform of this system, where users can manage projects and query stored data. Users can click "Create Project" to create new projects for new research or symptom management needs, and then define the project content. During the project preparation phase, the project backend management module (…) Figure 2 Section 21) standardizes the design of electronic data forms for all data items, formats, field lengths, and other data involved in the collection of all projects. It defines the required form structures and standardized requirements for electronic data collection within the system and saves them to the main server's SQL database table. Simultaneously, it defines the frequency plan for patient data collection for each project, with each frequency including a section for synchronizing the project structure with the collection terminals. The main server provides a RESTful API interface, including a request authentication mechanism carrying a token. After successful authentication, the form structure and collection plan definition for the corresponding project are synchronized via a project template using a POST interface. Figure 2 22) to local.

[0022] When the "Data Acquisition Terminal" deployment mode is selected, the "Data Acquisition Terminal" system runs locally on the terminal, and access on the local machine will also use HTTPS to ensure data security. The server's local area network IP address is configured on the data acquisition terminal, and when the data acquisition application (… Figure 2 (23) When it is necessary to synchronize the project structure, local area network communication should be carried out through an HTTP RESTful interface. Figure 2(24) The basic data on the main server is remotely synchronized and distributed to the data collection terminal. For medical staff or researchers to collect patient information offline, they first need to receive the synchronized project template data pushed by the system in main server mode within an internal private network environment. The main server will use HTTPS to push the project name, collection scale, data storage format, and hierarchical rules to the data collection terminal. When researchers use the data collection terminal in the field to collect data, they import or enter historical data according to a predetermined structure to form standardized electronic data. Figure 2 (24) All data files are stored on the hard drive of the acquisition terminal. When the acquisition terminal is brought back to the center, it can upload data to the main server via a local area network (LAN). The patient information and data stored in the acquisition terminal are uploaded and synchronized according to a predetermined structure to achieve data aggregation. After the terminal has collected data and connected to the LAN, it communicates with the main server via the LAN. Figure 2 24 in the data acquisition application ( Figure 2 In step 23), a synchronous upload operation is performed, distributing the data synchronously. The main server stores the uploaded data and indexes it according to each patient's ID. Finally, the data is output as a file according to the agreed file data format, facilitating the continuous aggregation of updated data before it is stored on the central data platform.

[0023] The offline data acquisition terminal supports both patient data entry and import methods. The offline system provides a UI interface ( Figure 2 Content 23) allows doctors or nurses to organize and fill in data. Information about each patient, their symptoms, and follow-up records can be entered on the page. When importing electronic data (…),… Figure 2 When encountering step 25), the first step is to format the offline collected data. A "Download Form Template" button is provided on the page. Clicking this will save a CSV file containing field definitions to the terminal. Data entry personnel can then transcribe the offline data into a CSV spreadsheet according to the template's field format requirements. For batch data import, first compress the CSV file and attachments into a ZIP file as required. Users can then click the "Upload Collected Data" button on the page. The page will display the local file path, allowing users to select the files to import. The "Upload Synchronize" function will then upload the data to a server with a specified IP address. Clicking the "Confirm Upload Synchronize" button completes the data upload. Figure 2(26) During this upload process, HTTPS is used to ensure data integrity and prevent data theft. The import process continues to use a standard RESTful API interface for token authentication with the main server. A file stream is established via a POST request, and the compressed data file is uploaded to the main server. The backend writes the data to a structured database through a standard interface, with each data entry performing format and value validation to ensure data quality. The main server automatically decompresses the uploaded ZIP file, reads the data from the CSV file, and saves it to the corresponding SQL database table based on the ID field. Compressed attachments are decompressed and moved to the corresponding server directory for storage.

[0024] Data management application of the main server ( Figure 2 (27) This feature enables the recording and querying of synchronized data from acquisition terminals. After a terminal uploads data to the main server via synchronization, an upload record is created in the SQL database, including the time, acquisition terminal ID, number of synchronized data items, and number of attachments. When a user opens the main server interface, the front-end page retrieves the dynamic synchronized upload records via a standard HTTP interface and displays these entries on the page for administrator confirmation. Uploaded offline data is summarized, and the basic information and data details for each patient can be viewed through the patient list. During data synchronization and import on the main server, a duplicate check for patient data is enabled. Duplicate data is displayed on the interface, and doctors and nurses can select the data and click "Merge" or "Store Independently." This completes the normalization process for duplicate data collection.

[0025] The main server stores the uploaded data and indexes it according to each patient's ID. Finally, it outputs the data in a pre-defined file format for easy aggregation and synchronous storage of continuously updated data. Figure 2 (28) The data is transmitted to the central data platform. In the exported encrypted data file, RSA encryption is used for data encryption, and a CA certificate is used for file signing to ensure data integrity and reliability. For online synchronization, HTTPS is used for SSL encryption to ensure that data is not intercepted during transmission.

[0026] 12. Multi-baseline acquisition

[0027] The implementation of a digital symptom monitoring and management system platform requires greater precision in ensuring the effectiveness of symptom management data and the reliability of data reflecting true symptoms. The overall process for patients, from pre-operative to post-operative discharge, is lengthy, resulting in various possible changes in their condition throughout the perioperative period. Whether these changes are accurately reflected in the symptom reporting data affects the accuracy of the data. In particular, different collection plans at different stages will lead to changes in the frequency and content of symptom assessments. After uniformly defining the project, the key to generating a personalized collection plan for each patient is determining the dates for multiple baselines. Digital symptom management needs to be able to dynamically adjust and configure symptom management for reporting symptoms in both normal and abnormal states. By enabling the digital symptom monitoring and management system platform to support multi-baseline symptom management for single patients, and considering that the automated generation of collection plans generally uses the patient's enrollment date as the base time calculation, modifications to key dates affecting the collection frequency can disrupt the entire collection plan and even affect the frequency attribution of already collected results. Therefore, the system must be able to adapt to changes in key baseline times throughout the entire treatment cycle. Typical database systems can only collect data and record time. Personalized automatic calculations involving questionnaire content and reminders for each patient on any date involve complex logical judgments and require consideration of many details. To provide a more convenient user experience, this system adopts a new multi-baseline mode, transforming the overall management plan into a collection queue of multiple baselines. When adjustments to patient status times are needed, timely adjustments can be made. Through frequency baseline correlations, the collection plan is automatically adjusted according to the new time, ensuring data accuracy on the system platform. Timely and accurate updates to patient symptom information achieve tangible treatment goals in symptom management and clinical intervention. Each baseline time adjustment automatically adjusts all collection plans and statistical analyses for the phase starting from that time, enabling changes to the symptom management plan as the patient's condition dynamically changes, and supporting multiple baseline adjustments.

[0028] In practical implementation, offline data collection solves the problem of expanding the coverage of digital symptom management and compensates for the inability to collect data. However, as a high-frequency symptom data collection method, it still faces the challenge of uncertain baseline frequency dates, which may change due to actual clinical dates. The starting point of multi-baseline management is to address the dynamic changes in the collection plan that objectively exist in clinical practice, allowing the system platform to more flexibly adapt to the uncertainties in the patient's treatment progress, such as changes in the perioperative period. When a patient's surgery date is postponed or discharge date is modified, it will affect the established date plan for symptom collection, and higher requirements are placed on the reliability and integrity of the data. If the platform is to automatically generate a series of collection tasks for enrolled patients, including updates to content and dates, then accurate baseline plan dates are the key to automation. If only the patient's enrollment date is used as the baseline, the system can only provide a collection plan schedule for subsequent periods in a fixed cycle, which cannot cope with changes in key clinical time points. Changes in the patient's key time baseline date will update the timeline of all plans corresponding to that baseline. On the one hand, the start of a new baseline cycle can be used to end the previous collection plan; on the other hand, the new baseline date can be used to calculate the accurate date or time interval of the associated collection frequency. Storing the affected portion of the original data as historical data also allows researchers to judge how the data was processed. Relying on the introduction of these IT technologies, the multi-baseline management function of symptom management can be implemented to support the accurate implementation of digital symptom management.

[0029] The system platform provides a data acquisition plan setting module ( Figure 3(31) Among them, it supports the ability to plan and set the frequency of multi-baseline data collection during the entire patient management process, making it simpler and more effective for medical staff and patients to use. The frequency of patient data collection is irregular. Different collection frequency densities and redundancy durations are designed for patients according to the needs of the project. Some are collected multiple times a day, some every few days, and some only once a week, month, or half a year. The allowed duration also varies, sometimes within 24 hours, sometimes for many days. If the system needs to automatically generate the baseline date input for each patient's collection date, automatically complete the update of the collection plan, push messages, etc., and can flexibly modify the planned date, the system needs to be very flexible in responding to the actual situation when setting the collection frequency for multi-baseline projects. The entire patient management process is divided into three types: 1. Admission, 2. In-hospital, 3. Out-of-hospital. When a data collection frequency is added to the page, the backend SQL database will assign a "frequency type" tag to each frequency by the user. This divides the project's data collection plan into different queues, each queue corresponding to a "baseline frequency." The date of this baseline frequency will affect the start and end dates of the data collection for each frequency in the corresponding period. In the digital symptom monitoring and management system platform, medical staff can click "Add Enrollment" to enroll patients. This stage completes the patient's admission registration and will by default register the patient's key "baseline dates," such as admission date and treatment start date. These are the inputs for the baseline date. Figure 3 (32 in the text) to activate the plan for frequencies related to this "baseline series". For key "baseline dates" throughout the entire patient management cycle, the responsible healthcare staff needs to update them on the system. A phased, stacked strategy is adopted. When the baseline date of a later cycle occupies the collection range of a previous cycle, the system will automatically terminate the remaining plans of the previous cycle through logical judgment. For example, if the in-hospital collection plan is for 10 days, but the patient is to be discharged on the 5th day, then the in-hospital collection plan for the last 5 days will be canceled based on the updated input. The background will change the status of these plan frequencies to "no plan" and will not participate in the overall data statistics. At the same time, it will also calculate each time node based on the new date, thereby completing the collection frequency management of symptom management data for the next stage. Figure 3 33) corresponds to the generation of the date.

[0030] The data collection plan generates a corresponding data collection calendar based on the baseline frequency date. The system background has an automatically executing scheduled task module. Figure 3(34) This module automatically triggers relevant collection messages within the time frame specified by the scheduled task according to the collection plan. When a patient needs to report, the scheduled task will trigger the subscription message template interface through the WeChat Mini Program API to send a reporting reminder to the patient, ensuring that the patient completes the reporting on time. Near the end of the reporting time frame, a message will also be sent to designated medical staff through the Enterprise WeChat API to inform them of the patient's failure to respond. This allows medical staff and patients to promptly remind the patient manually or conduct remote follow-up, achieving symptom tracking both inside and outside the hospital and realizing the goal of full-process management.

[0031] After enrollment, patients log into the system and report their symptom data according to the frequency requirements established during admission. During the perioperative frequency reporting process, medical staff can update the patient's baseline date at any time by clicking the key baseline date button on the page. Figure 3 (35) Clicking "Surgery Time" allows you to adjust a series of data collection plans after surgery; clicking "Discharge Time" allows you to adjust a series of data collection plans after discharge. Each update to the baseline date triggers a corresponding update to the data collection plan in the backend code. Based on the date interval of the data collection frequency, redundant dates for answering questions are allowed to be entered, thus regenerating a new data collection plan date table. The new start and end dates for each frequency are written to the SQL database table of the data collection plan, corresponding to the start and end time fields for each frequency.

[0032] Background baseline change logic processing module ( Figure 3 36) Based on the comparison with the planned dates in the database, determine whether it affects the frequency of patient reports. Compare the content items of each stage of the collection plan to confirm whether the affected answered frequency questions can be moved and reassigned to a new frequency. If there is no impact, then a new collection plan is generated. Of course, the patient can also answer the questions again according to the new collection plan by using the clear button. The background SQL database will save the data as history and set the answered status label to empty, allowing data to be rewritten. The system platform provides a "historical data processing" function for doctors to choose from, and these inaccurate data can be discarded or retained for archiving.

[0033] If an impact occurs, the system will save and process the historical data of the affected frequencies. The system provides researchers with a manual operation menu, where medical staff need to manually determine whether the affected answered frequencies need to be resubmitted for evaluation. If so, the status of the answered frequencies will be reset, and the collection plan will be retried, allowing patients to complete new questionnaires. If it is determined that the answered questionnaires at that frequency can be retained or moved, a "Move Frequency" button will appear if the new frequency content contains the answers to the questions. Researchers can click "Move Frequency" to select which new frequency to move the answered frequency content to. Simultaneously, the background SQL database will assign the frequency pointer to the corresponding new frequency, assigning a new frequency label to this questionnaire.

[0034] The system's backend scheduled task for answering questions will also execute according to the new date. When a patient opens the questionnaire through the client on the new planned date, the client sends an HTTP request to the server to answer the questions. The backend, based on the current system date and the corresponding data collection frequency definition, returns the corresponding form content via the HTTP interface. This implementation process and method avoids the need for the initial patient data collection plan to be updated according to new time nodes due to changes in admission, surgery, and discharge dates, and can even adapt to multiple changes.

[0035] 13. Duplicate enrollment

[0036] Digital symptom management is crucial in clinical research and routine clinical management, particularly in scenarios where patients undergo different stages of treatment and rehabilitation both in and out of the hospital. Treatment plans may require multiple repetitive cycles of treatment, such as multiple rounds of radiotherapy and chemotherapy, or further surgery, depending on the patient's condition. Each cycle involves symptom collection from both in-hospital and out-of-hospital patients. For example, a radiotherapy cycle typically lasts 4-7 weeks, and patients participate in different symptom collection plans within each cycle. This leads to real-world scenarios involving multiple cycles of symptom management. Due to the uncertainty of dates, the traditional method involved adding the patient again at the beginning of each new cycle, creating unnecessary steps for research and clinical work. In this scenario, the digital symptom monitoring and management system platform innovatively supports cyclical treatment states, providing patients with multiple cyclical symptom management sessions. Patients can choose to "re-enroll" at any time without needing to re-enter their basic information, returning their symptom management to its initial state. The system recalculates the data collection plan for the new enrollment, triggering new scheduled reminders and pushing new assessment questionnaires to the patient on time. Simultaneously, it allows for cross-sectional comparison of symptom management data across multiple cycles. When "re-enroll" is selected for a patient, the patient's data collection plan will report symptoms from the initial enrollment state, avoiding the process of adding and re-entering basic patient information, reducing the burden of repetitive work and subsequent data quality issues. The system platform manages symptom management cycles and intervention cycles, dynamically adjusting the patient's symptom management adaptation group settings, making symptom management more flexible and efficient.

[0037] In its implementation, repeated enrollment is built upon the multi-baseline functionality. Based on the characteristics of certain treatment methods requiring multiple repetitions, it facilitates the comprehensive management of repeated patient care and meets data collection needs. This allows for relatively independent management of each periodic treatment while maintaining the integrity of the patient's overall treatment process within the department. Patient management involves multiple and multi-period symptom management needs, with differentiated symptom management requirements across different treatment cycles. Through a microservice-based functional module design, the symptom management needs of the same patient across different treatment cycles are adjusted within the microservices. Independent service updates are performed online and take effect immediately after the patient's enrollment status is adjusted. The adjustment process is completed automatically by the system, requiring no manual intervention.

[0038] In the digital symptom monitoring and management system platform, we allocate specific management processes for symptom management of patients requiring repeated treatments. Each patient is assigned a unique record ID for continuous system recording. For patients requiring repeated treatment, the system platform provides a "re-enrollment" function when comparing data from each treatment cycle (e.g., ...). Figure 4 (41) This avoids repetitive operations by the management system on setting patient basic information and patient report outcome collection plans. The system introduces a "Number of Enrollments" label. On the patient management page, doctors can click the "Re-enroll" button. The front end sends a re-enrollment request to the back end via an HTTP interface. The back end service will then terminate all collection plans for the current patient and increment the patient's "Number of Enrollments" field in the SQL database table by 1. Figure 4 (42 in the middle), and reset all collection plan forms, including the patient collection status ( Figure 4 (43) Prepares everything for patient data collection again, enabling patients to complete a new round of "treatment". In the database, the same field is differentiated across different enrollment cycles based on "number of enrollments", facilitating front-end query display and data export. Simultaneously, combined with the multi-baseline function, it terminates the incomplete collection plan state for patients and performs basic configuration for the patient's symptom collection plan. On the patient management interface, medical staff no longer need to add basic patient information; the collection plan will be reset to a new set of pending collection states. The system determines whether a project is a multi-baseline collection project based on its type; if it is, it will proceed to the multi-baseline collection (… Figure 4 The process described in step 12) is executed based on the multi-baseline acquisition implementation, and the backend can correlate different enrollment data of the same patient. Figure 4(44) When it is necessary to view the patient's reported status, the system defaults to displaying the latest collection status and content of the "Number of Enrollments" group. If it is necessary to review past enrollment frequency data, select "Number of Enrollments" through the drop-down menu and send a query request for the corresponding "Number of Enrollments" to the backend. The backend database returns the record data corresponding to the number of enrollments through the REST interface based on the filtering conditions, and the frontend can then display the corresponding record data. To maintain consistency in patient management throughout the process, the system provides a view of symptom data curves. By identifying "symptoms" in the SQL database, symptom curves with the same symptom field ID are connected by lines of the same color in the graph, forming a complete symptom tracking curve spanning multiple "enrollment cycles". This facilitates medical staff's understanding and control of the development of related symptoms during and after several repetitive treatment cycles. When medical staff perform a "re-enrollment" operation for a patient through the system, the system's scheduled task module in the backend will also adapt to the newly generated collection plan for that patient and perform new scheduled tasks, including scheduled question reminders and indicator statistics. If the project is a single-frequency data collection type project, it will be executed according to the data collection plan of a single baseline, realizing multiple-frequency data reporting of a single baseline, as well as the corresponding scheduled message task service.

[0039] For each cycle of treatment for the same patient, the system platform's basic configuration includes multiple baseline cycle data collection plans based on the actual clinical situation. Healthcare professionals only need to wait for the patient to be readmitted or for repeated treatment to begin; they can then use the interface to generate a new, repeated cycle symptom monitoring plan for that patient and take further interventions based on symptom alerts. Repeated readmissions (…) Figure 4 The 46) management function does not limit the number of readmissions and allows for multiple rounds of treatment enrollment based on the patient's actual situation. For patients, as long as medical staff perform accurate and timely repeated enrollment operations, a new round of personalized scheduled tasks will be automatically generated based on the "enrollment count" field in the SQL database and the corresponding date. This includes sending new quiz reminders on time and pushing new symptom monitoring data to patients, ensuring more accurate symptom assessment. Based on high-quality data collection, more precise digital diagnostic and treatment interventions can be implemented.

[0040] The description and application of the present invention herein are illustrative and suggestive only, and are not intended to limit the scope of the invention to the embodiments described above. Variations and modifications of the embodiments disclosed herein are entirely possible, and substitutions and equivalent components of the embodiments are well known to those skilled in the art. It should also be understood by those skilled in the art that the invention can be implemented in other forms, structures, arrangements, proportions, and with other components, materials, and parts without departing from the spirit or essential characteristics of the invention, and that other variations and modifications can be made to the embodiments disclosed herein without departing from the scope and spirit of the invention.

Claims

1. A method for digital symptom monitoring and management, characterized in that, Includes the following steps: S1. After the data collection plan is issued, determine whether data can be collected online. If so, proceed to online data collection deployment; otherwise, proceed to offline data collection deployment. S2. After the above online or offline data collection deployment is completed, determine whether to perform multi-baseline data collection. If so, perform multi-baseline data collection; otherwise, perform regular data collection. S3. After the above multi-baseline acquisition or conventional acquisition is completed, determine whether there is duplicate enrollment. If so, return to step S2 after completing the duplicate enrollment; otherwise, proceed to step S4. S4. Complete the data acquisition plan; The offline data collection deployment described in step S1 specifically includes: when multiple terminals need to perform offline data collection simultaneously, and the collection items of each terminal need to be of a unified standard, the definition of the collection items and content will be uniformly defined on the central database platform. This supports centralized online synchronization and distributed offline data collection by the collection terminals, enabling synchronization of the project definition within the local area network. Then, offline data collection is used to collect stage data related to patient symptoms that meet the unified requirements of the project. Finally, the offline data is synchronously imported into the central platform via the local area network, enabling unified integration and analysis of medical and patient data on a single platform. Step S2, which involves multi-baseline acquisition, specifically includes: transforming the overall management plan into a collection queue of multiple baselines. When adjustments to the patient's status time are needed, these adjustments are made promptly. By using frequency baseline correlation, the collection plan is automatically adjusted according to the new time, updating the patient's symptom information. Each adjustment to the baseline time automatically adjusts all collection plans and statistical analyses for the phase starting at that time, enabling changes to the symptom management plan under dynamic changes in the patient's condition and supporting multiple baseline adjustments. The repeated enrollment mentioned in step S3 specifically includes: supporting the periodic treatment status, providing patients with multiple periodic symptom management sessions, allowing them to choose to re-enroll at any time without having to re-enter the patient's basic information, returning the patient's symptom management to the initial state, the system will recalculate the collection plan for the new enrollment, trigger a new reminder message timed task, push new assessment questionnaires to the patient on time, and simultaneously conduct horizontal comparisons of symptom management data from multiple periods; when a patient is selected to re-enroll, the patient's management collection plan will report symptoms from the initial enrollment state.

Images