Clinical test data intelligent processing method, device, equipment and medium

Abstract

The invention discloses a clinical test data intelligent processing method and device, equipment and a medium, and the method comprises the steps: generating a verification value through extracting a key field of a subject, comparing and triggering cross-system data updating, generating an audit log based on a document operation event, and driving document synchronization, collecting the context of a writing interface to generate a semantic vector, matching historical fragments to complete report content, analyzing the content by using an intelligent verification engine to generate a correction suggestion, and predicting a notification time point by combining service conditions and user behaviors to trigger an early warning message so as to realize automatic processing of test data, documents and reports. Through linkage data synchronization, document updating, content generation and task notification, the information consistency in the test process is improved, the generation efficiency is improved, and reminding is timely, so that the clinical test collaboration quality and execution efficiency are enhanced.

Description

Technical Field

[0001] This invention relates to the field of clinical trial management and automated data processing technology, and in particular to a method, apparatus, equipment and medium for intelligent processing of clinical trial data. Background Technology

[0002] Clinical trial management systems are widely used in real-world trial environments to record subject information and drive collaboration in multi-center trials. However, existing systems generally rely on manual data entry and discrete update mechanisms to maintain subject status data. Key fields such as enrollment status or visit schedules may experience delays or discrepancies between different systems, making timely identification and verification difficult and often leading to inconsistencies in cross-system data recording. Furthermore, the lack of automated calculation and comparison methods for key field changes makes the triggering conditions for subject status updates unclear, easily causing information gaps in business processes.

[0003] In existing clinical trial document processing scenarios, most systems can only capture coarse-grained document uploads or edits, failing to generate structured change logs that can be transferred across systems. The relationship between local document status and external archiving systems is often asymmetrical or unidirectional, making it difficult to maintain consistent document version information. Lagging or even missed updates are particularly prominent in multi-center trial collaborations. Furthermore, the lack of a traceable audit trail makes it difficult to accurately pinpoint the source, timing, and scope of document changes, easily leading to incomplete documentation during regulatory audits.

[0004] In the testing process, monitoring and inspection reports or test progress reports still primarily rely on manual writing. The system often cannot capture contextual information during the writing process, nor can it utilize historical report content to assist in text generation, resulting in low writing efficiency and inconsistent content quality. Simultaneously, manual proofreading remains the main method for report content review, with limited ability to identify semantic logic, terminology standardization, and content consistency, easily leading to subjective biases in quality control. Furthermore, existing system reminder mechanisms typically rely on fixed-time configurations, making it difficult to dynamically trigger task prompts based on changes in business conditions or user operating habits. Insufficient reminder coverage or missed processing opportunities are common problems, further impacting business collaboration performance. Summary of the Invention

[0005] The main objective of this invention is to provide an intelligent processing method, apparatus, device, and storage medium for clinical trial data, aiming to solve the technical problem that existing clinical trial systems lack an automated processing and feedback mechanism throughout the entire process of subject data, document processing, report generation, and task notification, thus failing to achieve timely and consistent data updates and business collaboration.

[0006] To achieve the above objectives, the present invention provides an intelligent processing method for clinical trial data, comprising: Extract the values ​​of key fields from the local subject records, and generate the current state feature verification value based on the values ​​of the key fields; The system retrieves historical state feature verification values ​​stored locally and compares them with the current state feature verification values. Based on the comparison results, it sends subject change data to an external data system through a bidirectional interface and receives data change notifications from the external data system to update local subject records. Detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of an external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status; The real-time context text of the report writing interface is collected, and the pre-trained language model is used to convert the real-time context text into a current semantic vector. Historical report fragments similar to the current semantic vector are retrieved from the vector database to generate report content. The intelligent verification engine is invoked to analyze the report content, and correction suggestions are generated based on the analysis results; Scan the business condition configuration library to identify pending tasks, predict the optimal notification time based on the pending tasks using user historical behavior data, and send an early warning message corresponding to the pending tasks at the optimal notification time.

[0007] Furthermore, to achieve the above objectives, the present invention provides an intelligent processing device for clinical trial data, comprising: The subject data processing module is used to extract key field values ​​from local subject records and generate current status feature verification values ​​based on the key field values. The data synchronization module is used to retrieve the historical status feature verification value stored locally and compare it with the current status feature verification value. Based on the comparison result, it sends the subject change data to the external data system through a bidirectional interface and receives the data change notification sent by the external data system to update the local subject record. The document synchronization module is used to detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of the external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status. The semantic retrieval module is used to collect the real-time context text of the report writing interface, use a pre-trained language model to convert the real-time context text into a current semantic vector, and retrieve historical report fragments similar to the current semantic vector from the vector database to generate report content. The content verification module is used to call the intelligent verification engine to analyze the report content and generate correction suggestions based on the analysis results; The task warning module is used to scan the business condition configuration library to identify tasks to be processed, predict the best notification time based on the task to be processed using user historical behavior data, and send a warning message corresponding to the task to be processed at the best notification time.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a clinical trial data intelligent processing program stored in the memory and executable on the processor, wherein when the clinical trial data intelligent processing program is executed by the processor, it implements the steps of the clinical trial data intelligent processing method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a clinical trial data intelligent processing program, which, when executed by a processor, implements the steps of the clinical trial data intelligent processing method as described above.

[0010] Beneficial Effects: This invention discloses an intelligent processing method, device, equipment, and medium for clinical trial data, including: generating state feature verification values ​​by extracting key fields of subjects and comparing them with historical state feature verification values ​​to complete cross-system data updates; converting document operation events into audit logs and triggering external system synchronization; collecting contextual text from the writing interface to generate semantic vectors; filtering historical fragments from a vector database to generate report content; using an intelligent verification engine to perform content analysis and generate correction suggestions; and combining business conditions and user behavior to predict the optimal notification time to trigger early warning messages, thereby achieving continuous updates, content generation, and task triggering of key trial data and documents. This invention automatically completes core tasks through collaborative links such as state comparison, event-driven synchronization, semantic generation, and intelligent verification, improving cross-system data consistency, ensuring real-time and reliable document flow, achieving efficient and accurate report generation, and providing intelligent and timely reminder mechanisms, thus significantly improving the execution efficiency and information quality of the clinical trial process. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for the intelligent processing method for clinical trial data in one embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the intelligent processing method for clinical trial data of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the intelligent clinical trial data processing device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The intelligent clinical trial data processing method provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can extract key fields of the subjects from the client to generate status feature verification values ​​and compare them with historical status feature verification values ​​to complete cross-system data updates. It can also convert document operation events into audit logs and trigger external system synchronization, collect contextual text from the writing interface to generate semantic vectors, filter historical fragments from a vector database to generate report content, use an intelligent verification engine to perform content analysis to generate correction suggestions, and combine business conditions and user behavior to predict the optimal notification time to trigger early warning messages. This achieves continuous updates, content generation, and task triggering of key trial data and documents. This invention automatically completes core tasks through collaborative links such as status comparison, event-driven synchronization, semantic generation, and intelligent verification, improving cross-system data consistency, ensuring real-time and reliable document flow, efficient and accurate report generation, and intelligent and timely reminder mechanisms, thereby significantly improving the execution efficiency and information quality of the clinical trial process. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the intelligent processing method for clinical trial data provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the intelligent processing method for clinical trial data proposed in this invention includes the following steps: S10, extract the key field values ​​from the local subject records, and generate the current state feature verification value based on the key field values; In this embodiment, local subject records are typically stored in a database or memory cache, saving the subject's current status information as fields. The extraction of key fields involves obtaining important field values ​​representing the status through a data access interface, such as enrollment status or visit schedule time. These fields may originate from manual input or feedback from external systems. Before further processing, the extracted key field values ​​undergo format standardization, employing date format conversion, status label mapping, or text normalization operations to convert heterogeneous formats into stable string representations. The processed field values ​​are combined in a defined order to form a continuous character sequence, ensuring comparability between different record instances under the same rules. The current status feature verification value is generated through hashing, encoding and compressing the concatenated string into a fixed-length identifier. Hash functions typically possess irreversibility and sensitivity, ensuring that any change in field value is reflected in the output identifier, thus forming the computational basis for determining whether the status has changed.

[0016] Key fields can be extracted through direct database queries or retrieved from memory-mapped structures via an object model interface. Field formatting can be standardized using built-in formatting functions for dates or by converting status tags using static mapping tables. String concatenation order can be statically defined in a configuration file or sorted naturally by field name. Validation value generation can be accomplished by software calls to hash functions, or, in performance-critical scenarios, by using a hash library with instruction acceleration. Within the same system environment, the extraction frequency and concatenation string caching strategy can be adjusted based on data volume to balance real-time performance and computational overhead.

[0017] This embodiment extracts key fields, performs format normalization, constructs concatenated strings, and generates verification values. It can describe the state information in the subject's records in a computable way, transforming state changes into comparable identifiers. This avoids omissions or misjudgments caused by relying on manual judgment of field differences and improves the uniqueness and stability of state descriptions.

[0018] S20, retrieve the historical status feature verification value stored locally and compare it with the current status feature verification value. Based on the comparison result, send the subject change data to the external data system through a bidirectional interface, and receive the data change notification sent by the external data system to update the local subject record. In this embodiment, the local system stores historical feature verification values ​​of the subject's status to represent the data status at the previous moment. After the current feature verification value is generated from the latest record, it needs to be compared with the values ​​in the historical records to determine if the status has changed. The comparison is performed by determining the equivalence of values ​​in string or binary form, or by comparing bits and pieces at the byte level to obtain the difference results. The comparison conclusion forms the trigger for synchronous actions. When the status changes, the local system constructs a data request through a bidirectional interface, outputting the changed fields or the complete record to the external data system. The bidirectional interface can handle request sending and result feedback, used for cross-system data transfer. After the request is sent, the external system may update the status and send a data change notification back to the local system. The change notification contains new values ​​that can locate the subject and fields. By parsing the notification content, the local record is updated to ensure that the record is consistent with the status stored by the external system.

[0019] Historical checksums can be read from a persistent database table or extracted from a cached structure. Comparison between the current checksum and historical values ​​can be achieved through direct string comparison, hash value comparison, or encoding sequence consistency checks. The bidirectional interface can be based on REST communication or message queue transmission, choosing the transmission mechanism based on system connection requirements. Change notifications can be received via polling or push notifications. When updating local records, fields can be directly replaced, or partial writes can be performed based on field differences, adapting to different system write strategies and lock control requirements.

[0020] This embodiment compares current and historical feature verification values ​​and triggers bidirectional interface synchronization, enabling cross-system updates driven by data changes. This ensures that the subject's status is always based on real-time records to drive external data synchronization and maintains consistency in local records, reducing information deviations caused by manual operations.

[0021] S30, detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of the external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status; In this embodiment, the local system continuously monitors various user actions related to documents, including uploading, modifying, replacing versions, or completing reviews. The application layer receives these actions through an event listener component, treating each trigger as a potential source of content change. To ensure changes can be tracked, the system extracts document identifiers, trigger time records, and version encoding information, combining these fields into a structured record. This structured record is written to a log set for subsequent cross-system transmission. An asynchronous scheduling mechanism operates independently of the user's operation path, scanning pending entries in the log set according to preset logic and deciding whether to perform data synchronization. When an unsynchronized record is detected, the scheduling thread accesses the application programming interface provided by the external document system, submitting the document identifier and version information to the external system for status update or archiving. After processing, the external system returns a notification containing the latest document status information. The local system parses the returned content and updates the locally stored document status accordingly, ensuring consistency with the external system's records.

[0022] Event detection can capture user file operations on the interface through embedded hook functions, or capture underlying changes through file system monitoring services. Structured records can be built using plain text storage, or key-value databases or document databases for fast retrieval. Asynchronous scheduling can be achieved through periodic polling by a thread pool, or by configuring a message-driven scheduler to trigger immediately when logs are generated. External interface calls can be based on HTTP or remote procedure calls, selecting the request format according to the characteristics of the interfacing system. Notification reception can be achieved by polling to retrieve responses, or by having external systems actively push notifications via callback mechanisms. When updating local document status, old values ​​can be directly overwritten, or a differential strategy can be used to reduce the write scope.

[0023] This embodiment independently monitors document changes and drives the synchronization process with structured records. Even if users are scattered in different centers or have different operation nodes, the document status can still be continuously transmitted to external storage and written back through automatic scheduling, so that the local and external versions always maintain the same version, reducing the risk of inconsistency caused by omissions and manual synchronization.

[0024] S40: Collect the real-time context text of the report writing interface, use a pre-trained language model to convert the real-time context text into a current semantic vector, and retrieve historical report fragments similar to the current semantic vector from the vector database to generate report content. In this embodiment, the system continuously reads the content of the text input area in the user's report writing interface, and extracts the paragraph text before the cursor by monitoring the cursor's position as real-time context. This paragraph text serves as a data source representing the user's current expressive intent and typically contains key descriptions, incomplete sentences, and clues to the chapter's theme. The system inputs the real-time context into a pre-trained language model. Internally, the model uses a multi-layered encoding structure to parse word order relationships, contextual associations, and latent semantic expressions, outputting a set of numerical semantic vectors. These semantic vectors represent the semantic spatial position of the current context at the conceptual level. The vector database retains the semantic representations of text fragments such as historical monitoring reports and visit records. The database uses a similarity function to measure the distance between the real-time semantic vectors and existing vectors. The system filters out fragments with a matching degree reaching a threshold, extracts the text content, and organizes it into candidate completion text, which is used as a reference for the generated content being written.

[0025] Context capture can be achieved through periodic polling of text regions using a front-end script, or through real-time extraction via input event awareness. The pre-trained language model can employ a bidirectional encoding model trained on large-scale text data, with vocabulary expansion tailored to the medical text context, or integrate a lightweight parameter model to reduce computational load. Vector retrieval can use cosine distance for similarity scoring, or configure an approximate nearest neighbor index to accelerate comparison. Candidate segment synthesis can directly return the original text segment, or incorporate source identifiers or content confidence weights for user decision-making.

[0026] This embodiment utilizes contextual semantic vectors to drive fragment retrieval, enabling the system to automatically locate content similar to the current expression from historical records, reducing the workload of manual recall and repetitive writing, improving text generation speed, and enhancing content structure consistency.

[0027] S50, invoke the intelligent verification engine to analyze the report content, and generate correction suggestions based on the analysis results; In this embodiment, the system inputs the generated report content into the intelligent verification engine. The verification engine uses its internal parsing module to break down the text into sentence-level, paragraph-level, and entity-level structures, extracting features such as semantic span, logical connections, terminology, temporal descriptions, and citation relationships. The engine internally loads various knowledge resources, such as medical terminology ontology, clinical process rules, language expression norms, and content consistency verification rules, to construct a multi-dimensional analysis framework for the report text. Logical consistency judgment identifies potential contradictions by recognizing the thematic coherence, causal chains, and event sequence relationships between paragraphs. Terminology analysis detects non-standard vocabulary or semantically repetitive expressions through lexical mapping. Text quality analysis locates redundant expressions, vague descriptions, and unclear structures through syntactic trees, pronoun resolution, and rhetorical structure analysis. Each analysis module outputs structured diagnostic information, such as risk item labels, terminology substitution suggestions, logical inconsistencies, and content missing prompts. The engine then synthesizes these structured results to generate targeted correction suggestions.

[0028] The analysis process can run in parallel by modules or sequentially in a fixed order. Logical detection can employ a graph-based event sequence analysis model or a semantically relation-oriented contrastive encoder to enhance contradiction identification. Terminology analysis can be based on a static professional dictionary or incorporate an updatable terminology knowledge base to adapt to different experimental domains. Language quality assessment can use a multi-task language model to output structural clarity scores or employ rule templates to decompose sentence structures to pinpoint readability issues. Correction suggestions can be generated based on rule combinations or through generative models to output more natural alternative expressions, which are then combined with risk level screening before being presented to the user.

[0029] This embodiment introduces an intelligent verification engine to perform structured and multi-dimensional analysis of the report text, enabling quality issues to be automatically identified and correction directions provided during the writing process. This reduces omissions in manual proofreading, improves content consistency, and enhances the overall reliability of the text.

[0030] S60, scan the business condition configuration library to identify tasks to be processed, predict the best notification time based on the task to be processed using user historical behavior data, and send an early warning message corresponding to the task to be processed at the best notification time.

[0031] In this embodiment, the system first scans the business condition configuration library, reading the monitoring conditions marked as enabled. Each monitoring condition includes parameters such as trigger fields, thresholds, periodic information, business source, and associated task type, indicating which business status needs attention. The system generates query expressions based on these configuration fields, enabling the scanning process to identify data entities related to the current condition. After processing, business data may generate pending tasks, which typically include affected users, business objects, reasons for task generation, and expected execution time limits, forming the basis for further calculations. For each pending task, the system extracts historical behavior data of the users associated with the task, including indicators such as notification reception time, reading interval, click-to-jump records, and processing completion time. The system organizes these behavior records into a time series to infer user response patterns. The model calculates the time point at which users are more likely to respond to the alert, forming the optimal notification time point. The system constructs an alert message containing task source, task content, and jump entry information, and attaches the sending behavior to the scheduling unit, triggering a notification push when the optimal notification time point is reached.

[0032] The scanning process can be executed by periodically polling the database or by updating the condition cache and scanning again using an event-triggered mode. Monitoring condition parsing can be driven by static configuration tables or dynamically adjusted by administrators through a graphical configuration interface, allowing them to adjust fields, thresholds, or periods. Task identification can utilize SQL expressions to filter data tables or employ lightweight in-memory index structures to improve query speed. User behavior data acquisition can rely on reading historical log tables or aggregate behavioral events into a log queue via a log collection agent before storing them in the database. Optimal notification timing prediction can use linear fitting models or regression decision trees or lightweight probabilistic models to adapt to different user behavior patterns. Alert message push notifications can rely on message queues for scheduled dequeueing or can be directly triggered by a scheduler to send messages via a third-party notification service.

[0033] This embodiment automatically analyzes business conditions and combines them with user historical behavior data to calculate the timing of notification delivery, enabling reminders to be delivered during periods with a higher probability of response, thereby reducing missed processing and improving business execution efficiency.

[0034] In one embodiment, step S10 includes: S101, Identify the enrollment status identifier and visit plan date in the local subject records as key fields; S102, extract the key field values ​​of the key fields and convert the key field values ​​into standard string format; S103, concatenate the standard string format values ​​in a preset order to generate the string to be verified; S104, The string to be verified is processed using a hash algorithm to generate the current state feature verification value.

[0035] In this embodiment, during subject management, local subject records are typically stored in a clinical trial management system or related business database. Each record corresponds to the status information of a single subject in the current center or multi-center environment. The record contains multiple fields, including an enrollment status identifier indicating whether the subject has completed screening, has been formally enrolled, has withdrawn from the trial, or is in the follow-up phase. This identifier is generally presented as an enumeration value, status code, or Boolean field. The visit schedule date records the time arrangement for the subject's next or a specific round of scheduled visits. This can be a single date field or a set of time fields with visit numbers. To link status changes to key business nodes, the processing procedure selects the enrollment status identifier and visit schedule date as key fields from among numerous fields and explicitly identifies these field names, data types, and value ranges in the configuration layer or metadata table for automatic extraction in subsequent processing stages.

[0036] The extraction of key field values ​​is typically achieved through database queries or application-layer data access interfaces. Based on predefined field mappings, the system reads the current enrollment status identifier and the corresponding visit plan date from the subject's records, using these two or more values ​​as a set of key field values. Since subsequent string-level operations are required, numeric status codes, date data, or timestamps need to undergo standardized formatting beforehand. Standard string formats can be defined as fixed-length date strings, zero-padding status code strings, or timestamp strings in a unified time zone. Formatting functions or custom conversion logic convert different types of key field values ​​into string representations that can be directly concatenated. Simultaneously, it controls whether hours, minutes, and seconds are retained, whether international standard time representation is used, and whether time zone offset information is included to ensure that the same business meaning corresponds to the same string result in different system environments.

[0037] After format conversion, all key field values ​​in the standard string format are concatenated in a preset order to form a single string to be verified. This preset order can be defined in the configuration table; for example, it can specify concatenating the group status identifier first, followed by the visit plan date. In multi-field scenarios, auxiliary fields such as visit number and center number can also be introduced. The concatenation method can be simple chaining, or separator characters can be inserted between fields to improve readability and facilitate debugging, while ensuring deterministic generation under different environments. Through this consistent convention of order and content, the string to be verified can stably map the combination of the current subject's status and plan information, forming a distinguishable string representation for different subjects or different time points of the same subject.

[0038] After the string to be verified is generated, the processing stage applies a hash algorithm to generate a current state feature verification value. The hash algorithm can be a message digest algorithm for string input, an unencrypted hash function, or a lightweight verification function, mapping a variable-length string to a fixed-length verification value using fixed rules. To reduce the probability of collisions and ensure good distinguishability even with a large number of subjects and frequent state updates, a hash algorithm version with a longer output length can be selected, or uniqueness can be enhanced by adding a salt value or an additional context field. The calculation process is generally completed in the application service layer or middleware layer. The string to be verified is used as input to obtain the current state feature verification value in binary or hexadecimal string form, and this verification value is bound to the subject identifier for subsequent comparison with historical state records.

[0039] This embodiment extracts key fields such as enrollment status identifier and visit plan date from the subject's records, converts them into a standard string format, concatenates them in a preset order, and then uses a hash algorithm to generate a current status feature verification value. This can map the combination of multiple field statuses into a stable and easily comparable verification identifier, enabling the clinical trial system to quickly determine whether the subject's status has changed without directly traversing each field. This improves the efficiency and accuracy of status synchronization judgment and reduces the data risk caused by inconsistencies in status across systems.

[0040] In one embodiment, step S20 above includes: S201, query the local database to obtain the historical state feature verification value corresponding to the subject record associated with the current state feature verification value; S202, Perform a comparison between the historical state feature verification value and the current state feature verification value; S203, when the comparison results are inconsistent, the data synchronization direction is determined according to the preset source system priority identifier; S204, If the data synchronization direction indicates that the local system is the update source, then send the subject change data to the external data system through the bidirectional interface; S205, if the data synchronization direction indicates that the external data system is the update source, then receive data change notifications from the external data system through the bidirectional interface; S206. Update the local subject record based on the data change notification or the result of sending subject change data to an external data system.

[0041] In this embodiment, during the subject status synchronization process, the current status feature verification value is first associated with the local historical records based on the existing data structure in the local database. The local database can be indexed using fields such as the subject's unique identifier, center number, and visit number. The status feature verification value generated each time the status changes is persisted in a dedicated history table, recording additional information such as the generation time and source system identifier. When it is necessary to determine whether the current status has changed, the application layer initiates a query to the local database based on the subject identifier information carried by the current status feature verification value. The query retrieves the most recent valid record for the corresponding subject in the history table or associated table and reads the historical status feature verification value bound to that subject record. This retrieval process can be completed through a single exact match query, or a partitioning strategy based on trial project, center, or visit stage can be introduced to accelerate query efficiency with large-scale samples.

[0042] After obtaining the historical state feature verification values, the application layer compares the historical and current state feature verification values ​​in memory. The comparison process typically uses an exact equality check, comparing the two verification values ​​as strings or fixed-length byte sequences bit by bit. A time window check can also be added to filter out expired historical records. If they are the same, it is assumed that the subject's key fields have not changed, and cross-system synchronization is not required. If they are different, it is determined that the current subject's state has been updated relative to the historical record, and further decisions are needed regarding the flow of data between the local system and external data systems.

[0043] To control data write direction in a multi-system collaborative environment, the system pre-configures source system priority identifiers. These identifiers can be stored in a configuration table, defining the priorities of local and external data systems in different scenarios, granularly based on test projects, business scenarios, or field types. For example, EDC takes priority for group entry status, and CTMS takes priority for visit plans. When a discrepancy is detected between historical and current status feature verification values, the application layer reads the corresponding configuration record, parses the source system priority identifier into a specific data synchronization direction, and maps it to commands such as "local update external" or "external update local," providing a decision-making basis for subsequent API calls.

[0044] When the synchronization direction is directed to the local system, the local system is considered the latest data source. The application layer constructs subject change data based on the current subject records, encapsulating the subject identifier, enrollment status, visit plan date, status characteristic verification value, and necessary timestamps and operator information into a structured message, which is then sent to the external data system via a bidirectional interface. This bidirectional interface can be implemented using HTTP, message queues, or remote procedure calls, carrying authentication information and idempotency flags to ensure the external data system can verify the request source and avoid duplicate writes. After processing, the external data system returns an acknowledgment response, which may include the reception result, error codes, or the updated version information. The local system can then record synchronization logs and the latest status characteristic verification value based on this information.

[0045] When the synchronization direction is external, the external data system is considered the latest data source. The local system receives data change notifications through bidirectional interfaces via polling, subscription, or callback. Change notifications may include the subject identifier, change type, field values ​​before and after the change, status feature verification values ​​calculated by the external system, and the change time. The interface access layer is responsible for verifying the signature and parsing the format of the notification messages, and submitting the parsed content to the business layer for processing. The business layer corrects the local subject records based on the status information carried in the change notification, updating local fields to the latest values ​​in the notification, and simultaneously updating the locally stored historical status feature verification values ​​to maintain the continuity of subsequent comparisons.

[0046] Regardless of whether the synchronization direction is local or external, a consistency update must ultimately be completed in the local subject records. The update process is typically executed within a database transaction. First, the corresponding record is locked based on the subject identifier, then the latest field values ​​and new status feature verification values ​​are written, and a synchronization log entry is appended to record the source, direction, and result of this synchronization. In scenarios where local data is being sent externally, the external response can be used to determine whether a retry or rollback is necessary. For example, if the external system returns a failure, the reason for the failure can be recorded while maintaining the old local state to avoid creating invalid status markers. Through this sequential processing chain, a complete closed loop is achieved, from difference detection and synchronization direction determination to cross-system interface calls and data updates.

[0047] This embodiment retrieves and accurately compares historical state feature verification values ​​associated with the current state feature verification value in the local database, introduces a source system priority identifier to determine the data synchronization direction, and combines a bidirectional interface to transmit subject change data or data change notifications between the local system and external data systems. When a subject's key state changes, it can automatically decide which party should be the data update source and complete the synchronous update of the local record. This reduces manual comparison and repetitive entry in a multi-system collaborative environment, lowers the probability of cross-system state conflicts, and improves the consistency and traceability of subject state data.

[0048] In one embodiment, step S30 above includes: S301 deploys an event interceptor at the local application layer to detect document upload events, document editing events, and document approval events as local document operation events; S302, Extract the unique document identifier, operation timestamp, and version number associated with the local document operation event; S303, construct structured log entries based on the document's unique identifier, operation timestamp, and version number to generate a change audit log; S304, poll the pending records in the change audit log using an asynchronous scheduling mechanism; S305, for the pending records polled, calls the application programming interface of the external document system to initiate a document synchronization request; S306, Receive document change notifications sent by external document systems; S307, Update the local document status based on the document unique identifier and version number contained in the document change notification.

[0049] In this embodiment, during the document synchronization and auditing process, the local application layer first deploys an event interceptor, integrating it at the entry points of document upload, editing, and auditing functions to transparently intercept and listen to these operation requests. The event interceptor can exist as middleware, a filter, or a UI component listener, uniformly encapsulating upload requests, edit / save requests, and audit approval operations submitted from the front end. Without affecting normal business submissions, it generates an operation event record for each document operation. Document upload events are typically associated with creating a new document or adding a version, document editing events correspond to content modifications, and document audit approval events reflect changes in process status. These three types of events collectively cover key change scenarios from creation to archiving. For each local document operation event, the application layer extracts the document's unique identifier, operation timestamp, and version number from the current context. The document's unique identifier can originate from the primary key assigned to the document record in the database or from a globally agreed-upon tag with an external document system, used to uniquely locate the same document across different systems. The operation timestamp is generated by the server time, accurate to the second or millisecond, recording the specific time the operation occurred for subsequent sorting and conflict detection. The version number is obtained from the document version management module, reflecting the version sequence corresponding to this operation and used to distinguish historical versions from the latest version. The application layer uses the document unique identifier, operation timestamp, and version number as basic fields, assembling them into structured log entries according to a unified structure. These entries can be in the form of key-value pairs, JSON objects, or relational tables, thus solidifying the key elements of each operation event and continuously writing these structured entries to the change audit log storage area. Change audit logs can reside in a separate database table or be written to a persistent queue or log indexing system to support subsequent polling and tracing.

[0050] The asynchronous scheduling mechanism is responsible for consuming pending records in the change audit log without blocking business operations. The scheduling module triggers polling at set time intervals or task queue depths. Upon each trigger, it selects records from the log storage that are in an unsynchronized or failed synchronization state, groups these records into batches, and delivers them to the synchronization execution unit for processing. The polling process can be combined with concurrency control and retry flags, such as setting a processing status field and retry count for each record to avoid duplicate submissions and omissions. For each pending record polled, the application layer constructs a document synchronization request based on the document's unique identifier and version number in the log entry. The request body can include document metadata, change type, version information, and necessary verification digests, and calls the application interface according to the interface specifications agreed upon with the external document system. Interface calls can be issued via HTTP interfaces, SDK encapsulation, or message queue gateways, with parameter mapping, authentication signing, and exception handling uniformly handled by the interface adaptation layer. After processing the synchronization request, the external document system feeds back the generated change results to the local system via callback notifications, push notifications, or polling responses. The local system receives the document change notification at the interface access layer, parses and validates the notification content, reads the document's unique identifier and version number, and determines whether synchronization was successful by combining the status field or result flag in the notification. Finally, the local document status update process locates the corresponding record in the local document table based on the document's unique identifier, adjusts the version number and status field to the latest values ​​carried in the notification, and updates the synchronization flag and the most recent synchronization time to indicate that the document has been aligned with the external document system. If necessary, the update process can be executed within a database transaction to ensure consistent updates of the status field, version number, and audit log status, maintaining a correspondence between the audit trail and the actual document status.

[0051] This embodiment captures document upload, editing, and approval operations by deploying an event interceptor at the local application layer. It constructs a structured change audit log by combining the document's unique identifier, operation timestamp, and version number. It uses an asynchronous scheduling mechanism to poll pending records and call the external document system's application programming interface to complete document synchronization. Then, it updates the local document status based on the document's unique identifier and version number carried in the document change notification. This can form a continuous link from local operation capture, log recording, asynchronous synchronization to status write-back without affecting the front-end user experience. This ensures that the document status and version information between the local system and the external document system are consistent, while retaining a complete change trajectory, providing a reliable basis for subsequent compliance verification and problem tracing.

[0052] In one embodiment, step S40 above includes: S401, Real-time monitoring of the cursor position in the report writing interface, and extracting the paragraph content before the cursor position as real-time context text; S402, Invoke the pre-trained language model to encode the real-time context text and output a high-dimensional feature vector as the current semantic vector; S403, calculate the similarity value between the current semantic vector and the historical report fragment vectors stored in the vector database; S404, filter out historical report segments whose similarity values ​​exceed a preset threshold; S405, after annotating the source information of the selected historical report fragments, insert them into the editing area of ​​the report writing interface to generate report content.

[0053] In this embodiment, during the report generation stage, the process first relies on the report writing interface to obtain real-time text environment information. The report writing interface can be a browser-based rich text editing page or a text editing component in a desktop client. By integrating cursor monitoring logic at the interface layer, the current cursor position is continuously monitored, triggering a position update event when the user inputs characters, creates a new line, or moves the cursor. To construct an effective contextual context, the system traces backward from the current cursor position, extracting several consecutive paragraphs of text according to paragraph boundaries, and uniformly treating these text contents as real-time contextual text. Paragraph boundaries can be determined based on rules such as line breaks, heading marks, and paragraph styles to ensure that the extracted text fragments are complete and semantically coherent. The real-time contextual text, as the semantic carrier of the current writing scenario, is fed into a pre-trained language model for encoding processing. The pre-trained language model can be a deep neural network structure trained on general corpora and further trained on medical or clinical texts, such as an encoding network based on the Transformer architecture. It captures the dependencies and semantic patterns between contextual words through multi-layer self-attention operations, thereby outputting a vectorized representation of the entire text. During the encoding process, the system performs preprocessing on the real-time context text, such as word segmentation, tokenization, and adding sentence beginning and end tags. Then, it segments or truncates the text according to the model input length limit and finally obtains a high-dimensional feature vector with a fixed dimension. This vector is defined as the current semantic vector in the current scenario, which is used to represent the overall semantic state of the text before the current writing position.

[0054] The vector database pre-stores vector representations of a large number of historical report fragments. Each historical report fragment undergoes the same encoding process as the real-time context text upon entry, generating a corresponding historical report fragment vector. Simultaneously, it establishes an association with the original text content and metadata (such as report type, indication category, creation time, author identifier, etc.). The vector database can employ a dedicated storage engine supporting vector similarity retrieval, organizing these vectors through inverted indexes, approximate nearest neighbor search structures, or graph index structures to improve the efficiency of large-scale retrieval. Upon obtaining the current semantic vector, the system initiates a retrieval request in the vector database, selecting cosine similarity, inner product similarity, or the inverse of Euclidean distance as the similarity metric. Batch vector operations are used to calculate the similarity value between the current semantic vector and each historical report fragment vector. The similarity value reflects the closeness of two texts in the semantic space; the higher the similarity, the closer the historical report fragment is to the current writing context. To avoid introducing irrelevant content, the system sets a preset threshold to filter all similarity values, retaining only historical report fragments with similarity exceeding the threshold as candidate results. The threshold can be configured to different values ​​based on historical usage, user feedback, or different report types. It can also be used in conjunction with the upper limit of the number of candidates, for example, retaining only the top few results in terms of similarity while meeting the threshold constraint.

[0055] For selected historical report fragments, the system supplements the original fragments with source information to provide transparent source markings when inserting and editing. Source information may include the original report number, writing time, associated project name, or center number, for subsequent traceability and auditing. Annotation methods can include adding visual labels before and after the fragment text, or displaying it as a floating tooltip or sidebar metadata through interface controls. During the insertion phase, the system inserts the annotated historical report fragment into the editing area based on the current cursor position. This can be done by inserting it directly before the cursor position, overwriting the currently selected text, or appending it to the end of the current paragraph. The insertion process should preserve the original text formatting, such as paragraph indentation, list structure, or section headings, to reduce manual adjustments. After insertion, the original content in the editing area and the newly inserted historical report fragment together constitute the new report content. Users can continue to edit, delete, or supplement this content, thus reusing high-quality existing text while maintaining semantic coherence.

[0056] This embodiment extracts contextual text by monitoring the cursor position in real time within the report writing interface. It then uses a pre-trained language model to convert this context into a current semantic vector. Based on a vector database, it calculates the similarity between the current semantic vector and historical report fragment vectors. After filtering high-similarity fragments according to a preset threshold and adding source information, it inserts the fragments into the editing area to generate report content. This ensures that the generated text is semantically consistent with the current writing context, improving the accuracy and relevance of historical content reuse. It also reduces the time spent manually searching for and copying existing reports. Furthermore, it retains source markers when inserting fragments, balancing writing efficiency and content traceability. This helps to form a report text resource system that can be automatically retrieved and reused as historical data is continuously accumulated.

[0057] In one embodiment, step S50 above includes: S501 loads the pre-built clinical trial standard condition library, medical terminology ontology library and natural language processing model into the intelligent verification engine; S502, The intelligent verification engine performs compliance analysis on the report content based on the clinical trial standard condition library, and generates compliance check results; S503, The intelligent verification engine performs logical consistency analysis on the report content based on a natural language processing model to generate a logical consistency check result. S504, The intelligent verification engine performs terminology consistency analysis on the report content based on the medical terminology ontology, and generates terminology consistency check results. S505, The intelligent verification engine performs language quality analysis on the report content based on a natural language processing model to generate language quality check results. S506, Based on the compliance check results, logical consistency check results, terminology uniformity check results, and language quality check results, the intelligent verification engine generates correction suggestions through the intelligent verification engine.

[0058] In this embodiment, when automatically checking the report content, multiple types of checking resources need to be loaded into the intelligent verification engine in the runtime environment first. The clinical trial standard condition library can adopt a structured storage format, breaking down clauses such as ethical approval requirements, subject protection clauses, adverse event reporting time limits, safety follow-up intervals, and visit plan requirements into condition items with unique identifiers. Each condition item includes fields such as trigger scenario, applicable objects, parameter range, and time limit. The medical terminology ontology can be built based on a medical vocabulary list, diagnostic coding table, and drug dictionary, establishing a mapping relationship between different spellings, abbreviations, and old names and the currently recommended terms, and attaching attributes such as the system to which it belongs, anatomical location, and route of administration. The natural language processing model can be deployed as a service process or an embedded inference component. During the initialization phase, the model parameter file is loaded, and language resources such as word segmentation dictionary, stop word list, and syntax template are configured. When the intelligent verification engine starts, it registers the clinical trial standard condition library, medical terminology ontology library, and natural language processing model to the internal resource management module, recording the version number and scope of effectiveness through a unified resource index structure, providing basic support for subsequent various analysis calls.

[0059] During compliance analysis, the engine receives the text data of the current report content, parses the text into blocks according to chapters, paragraphs, and clause numbers, and extracts key sentences related to subject protection, adverse event handling, and visit implementation. For each key sentence, the engine matches it with conditions in the clinical trial standard condition library based on keywords, field tags, or upstream processing results to determine whether the report explicitly covers required content, whether necessary time point descriptions are missing, and whether there are descriptions exceeding the time limits in the condition library. During the check, each matching result for a condition item can be recorded, generating a set of records containing condition item identifiers, matching positions, matching status, and deviation information. This set is summarized into a compliance check result at output, used to indicate the degree of conformity and deficiencies between the report and expected regulations.

[0060] During logical consistency analysis, the engine semantically encodes the report content using a natural language processing model, representing paragraph text as vectors or graph structures. It then combines this with extracted event timelines, visit sequences, and subject status change trajectories for consistency verification. Specifically, the engine constructs a timeline, marking the order of events such as screening, enrollment, medication administration, follow-up, and termination. It extracts corresponding time expressions, event types, and object identifiers from the text, detecting conflicts in the time descriptions of the same event between paragraphs and inconsistencies in the status descriptions of the same subject—for example, marking the same visit as both completed and cancelled. When contradictions or gaps are detected, the engine records the conflicting pairs, missing points, and their corresponding locations as logical consistency check results, used to generate actionable modification suggestions later.

[0061] During the terminology consistency analysis, the engine utilizes a medical terminology ontology to standardize and compare professional terms in the report content. The text first extracts entities such as disease names, examination items, drug names, and adverse event types through word segmentation and entity recognition. Then, it identifies non-recommended terms and mixed usages using the ontology's synonym mapping, hierarchical relationships, and preferred terminology tags. For example, when different abbreviations or mixed language expressions appear simultaneously in the text, the engine marks the terms that need to be standardized based on the preferred terms in the ontology. In the output recording phase, the engine generates terminology consistency check results for each inconsistent term, including the original term, recommended terms, location, and suggested replacement range, facilitating subsequent highlighting or automatic batch replacement in the interface.

[0062] During language quality analysis, the engine continues to utilize natural language processing models to assess the text quality of the report content. On one hand, it identifies incomplete, excessively long, and structurally disorganized sentences through syntactic and dependency parsing, and marks sentences with poor readability based on preset sentence length thresholds and nesting level restrictions. On the other hand, it detects overly subjective, emotionally charged, or unobjective descriptions in clinical reports through sentiment analysis and tone analysis, such as the use of exaggerated, evaluative, or overly vague adjectives. For detected issues, the engine constructs language quality check results, recording the issue type, sentence content, and suggested processing methods (splitting, rewriting, reducing subjectivity, etc.), providing input for subsequent specific recommendations.

[0063] During the revision suggestion generation phase, the engine integrates compliance check results, logical consistency check results, terminology consistency check results, and language quality check results to categorize issues from different sources and sort them according to severity and processing complexity. The engine can match pre-configured modification strategies for each issue record. For example, it can generate suggestions such as "add a certain type of explanation" for records with missing required paragraphs, "unify the description of events before and after" for records with contradictory states, "replace a certain word in the text with recommended terminology" for records with inconsistent terminology, and "split long sentences" or "delete evaluative statements" for records with language quality issues. During generation, the engine can map the issue location back to paragraph and sentence offsets in the original report content, enabling location and linked modifications in the user interface. The final output is a set of revision suggestions containing a list of issues, corresponding suggested text, affected locations, and suggestion priorities, for the report writer or reviewer to adopt and implement.

[0064] This embodiment loads a clinical trial standard condition library, a medical terminology ontology, and a natural language processing model into an intelligent verification engine. Within a single engine, corresponding inspection results are generated in the order of compliance analysis, logical consistency analysis, terminology uniformity analysis, and language quality analysis. These inspection results are then categorized and matched with strategies within the same engine to form structured correction suggestions. This allows for multi-dimensional automatic checks of report content without altering the original report writing process. It systematically evaluates regulatory requirement coverage, event timeline consistency, standardization of professional terminology use, and text expression quality, thereby reducing omissions and subjective biases caused by purely manual proofreading, improving the pertinence and feasibility of report modification suggestions, and enhancing the stability and traceability of clinical trial document quality control.

[0065] In one embodiment, step S60 above includes: S601, Read the business monitoring conditions that are enabled in the business condition configuration library, and parse the trigger thresholds and inspection cycles contained in the business monitoring conditions; S602, Scan the associated business data table based on the trigger threshold and inspection cycle to identify tasks to be processed; S603, For the task to be processed, extract the click time records from the user's historical behavior data; S604, Based on the click time record, predict the optimal notification time using a regression analysis model; S605, Generate an early warning message corresponding to the task to be processed; S606, send the warning message corresponding to the task to be processed at the optimal notification time.

[0066] In this embodiment, the business condition configuration library can reside in a database table or configuration service. Business monitoring conditions are recorded for each type of monitored item, such as "subject follow-up not completed within the specified period," "safety report submission deadline approaching," and "ethics approval document about to expire." Each business monitoring condition includes at least an activation flag, target business type, trigger threshold, inspection cycle, and associated business data table identifier. The trigger threshold can be stored in the form of days, hours, times, or proportions, used to limit the extent to which business data is deemed abnormal or requires alert. The inspection cycle limits the time window and trigger frequency for the system to scan business data, for example, checking records from the past seven days every hour or checking records from the past thirty days every day. During runtime, the task identification unit only reads business monitoring conditions with the activation flag set to true from the business condition configuration library, parses the trigger threshold and inspection cycle into an executable time interval, threshold expression, and filtering conditions. Based on the parsed conditions, the system selects the corresponding associated business data table for each business monitoring condition, generates a query statement through condition combinations, filters out records that meet the threshold requirements and are in an unprocessed state, and adds task identifiers, priority, and responsible person information to these records, aggregating them into a set of tasks to be processed.

[0067] After receiving pending tasks, it is necessary to associate the tasks with historical notification behaviors to build a view of user historical behavior data. User historical behavior data can come from logs in the message center, email system, or in-application notification module, and is typically recorded in time-series format, including fields such as user identifier, notification type, sending time, click time, and terminal type. For each pending task, the system filters notification records from the user's historical behavior data based on the user identifier and business type included in the task, identifying notification records from the same user in similar or related business scenarios, and extracts the click time field to form a click time record sequence. Click time records can be grouped by calendar day, weekdays and weekends, or by business category to enhance the distinguishability of time patterns. The time field can be converted to features such as hours, minutes, and days of the week, or mapped to a continuous timeline from 0 to 24 or a discrete time bucket within a week.

[0068] After obtaining the click time record sequence, a regression analysis model is introduced to fit the notification response pattern, in order to deduce the optimal notification time for the current user and task. The regression analysis model can be based on linear regression, fitting the click probability to a time variable; it can be based on periodic regression, using time slices within a day or week as independent variables and outputting the response probability in each time slice; or it can employ a multivariate regression structure with time features, inputting terminal type, business category, historical unread ratio, and time together to characterize click tendencies under different conditions. When training or updating the regression analysis model, the "whether it was clicked within a certain time window" in historical notifications can be used as the target variable, with time-related features and task features as inputs. In the inference phase, for the current task to be processed, the system calculates the predicted response probability one by one based on the candidate time set (e.g., every half-hour node of the next 24 hours or a reminder window allowed by a certain business), selecting the time point with the highest predicted result as the optimal notification time point, and adjusting it as needed for working hours, regulatory requirements, or business constraints, such as avoiding nighttime or legally unreachable periods.

[0069] After determining the optimal notification time, the system enters the alert message generation and sending phase. The alert message can be automatically assembled based on the business type of the task to be processed, including a task overview, risk level, deadline, direct processing entry link, and key information related to the subject or project. During generation, the system can supplement context fields from the associated business data table, binding the task identifier with page routing, interface parameters, or jump paths to ensure that users can directly jump to the processing interface after receiving the alert message. The alert message, along with the optimal notification time, is written to the message scheduling queue or scheduled task table. The scheduling module scans the records to be sent according to a predetermined time granularity. Once the system time reaches the optimal notification time corresponding to a record, the sending operation is triggered, and the alert message is sent to the corresponding user via SMS gateway, email service, or in-application push channel. The sending result can be written back to the user's historical behavior data, providing new sample records for subsequent model updates.

[0070] This embodiment parses business monitoring conditions from a business condition configuration library, converts trigger thresholds and inspection cycles into filtering logic for associated business data tables to form a set of tasks to be processed, and then extracts click time records from the historical behavior data of the users corresponding to the tasks. By using a regression analysis model to deduce the optimal notification time point adapted to individual behavior patterns from time features, a warning message carrying direct access to the processing entry is finally sent at this time point. This can increase the probability of notifications being noticed and executed without increasing user interference, transforming task reminders from static time configuration to adaptive scheduling based on behavioral data. This reduces the risk of important tasks being ignored or overdue, and improves the efficiency of clinical trial business collaboration and the time sensitivity of task processing.

[0071] In one embodiment, a clinical trial data intelligent processing device is provided, which corresponds one-to-one with the clinical trial data intelligent processing method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the intelligent clinical trial data processing device of the present invention. The modules include a subject data processing module 10, a data synchronization module 20, a document synchronization module 30, a semantic retrieval module 40, a content verification module 50, and a task early warning module 60. Detailed descriptions of each functional module are as follows: The subject data processing module 10 is used to extract the values ​​of key fields from the local subject records and generate a current status feature verification value based on the values ​​of the key fields. The data synchronization module 20 is used to retrieve the historical status feature verification value stored locally and compare it with the current status feature verification value. Based on the comparison result, it sends the subject change data to the external data system through a bidirectional interface and receives the data change notification sent by the external data system to update the local subject record. The document synchronization module 30 is used to detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of the external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status. The semantic retrieval module 40 is used to collect the real-time context text of the report writing interface, use a pre-trained language model to convert the real-time context text into a current semantic vector, and retrieve historical report fragments similar to the current semantic vector from the vector database to generate report content. The content verification module 50 is used to call the intelligent verification engine to analyze the report content and generate correction suggestions based on the analysis results; The task warning module 60 is used to scan the business condition configuration library to identify tasks to be processed, predict the best notification time based on the task to be processed using user historical behavior data, and send a warning message corresponding to the task to be processed at the best notification time.

[0072] Specific limitations regarding the intelligent processing device for clinical trial data can be found in the aforementioned limitations on the intelligent processing method for clinical trial data, and will not be repeated here. Each module in the aforementioned intelligent processing device for clinical trial data can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0073] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a server-side intelligent processing method for clinical trial data.

[0074] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a client-side intelligent processing method for clinical trial data.

[0075] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Extract the values ​​of key fields from the local subject records, and generate the current state feature verification value based on the values ​​of the key fields; The system retrieves historical state feature verification values ​​stored locally and compares them with the current state feature verification values. Based on the comparison results, it sends subject change data to an external data system through a bidirectional interface and receives data change notifications from the external data system to update local subject records. Detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of an external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status; The real-time context text of the report writing interface is collected, and the pre-trained language model is used to convert the real-time context text into a current semantic vector. Historical report fragments similar to the current semantic vector are retrieved from the vector database to generate report content. The intelligent verification engine is invoked to analyze the report content, and correction suggestions are generated based on the analysis results; Scan the business condition configuration library to identify pending tasks, predict the optimal notification time based on the pending tasks using user historical behavior data, and send an early warning message corresponding to the pending tasks at the optimal notification time.

[0076] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon. When the computer program is executed by a processor, it performs the following steps: Extract the values ​​of key fields from the local subject records, and generate the current state feature verification value based on the values ​​of the key fields; The system retrieves historical state feature verification values ​​stored locally and compares them with the current state feature verification values. Based on the comparison results, it sends subject change data to an external data system through a bidirectional interface and receives data change notifications from the external data system to update local subject records. Detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of an external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status; The real-time context text of the report writing interface is collected, and the pre-trained language model is used to convert the real-time context text into a current semantic vector. Historical report fragments similar to the current semantic vector are retrieved from the vector database to generate report content. The intelligent verification engine is invoked to analyze the report content, and correction suggestions are generated based on the analysis results; Scan the business condition configuration library to identify pending tasks, predict the optimal notification time based on the pending tasks using user historical behavior data, and send an early warning message corresponding to the pending tasks at the optimal notification time.

[0077] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

Claims

1. A method for intelligent processing of clinical trial data, characterized in that, Includes the following steps: Extract the values ​​of key fields from the local subject records, and generate the current state feature verification value based on the values ​​of the key fields; The system retrieves historical state feature verification values ​​stored locally and compares them with the current state feature verification values. Based on the comparison results, it sends subject change data to an external data system through a bidirectional interface and receives data change notifications from the external data system to update local subject records. Detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of an external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status; The real-time context text of the report writing interface is collected, and the pre-trained language model is used to convert the real-time context text into a current semantic vector. Historical report fragments similar to the current semantic vector are retrieved from the vector database to generate report content. The intelligent verification engine is invoked to analyze the report content, and correction suggestions are generated based on the analysis results; Scan the business condition configuration library to identify pending tasks, predict the optimal notification time based on the pending tasks using user historical behavior data, and send an early warning message corresponding to the pending tasks at the optimal notification time.

2. The intelligent processing method for clinical trial data as described in claim 1, characterized in that, Extract key field values ​​from local subject records and generate current state feature verification values ​​based on these key field values, including: The enrollment status identifier and the planned visit date in the local participant records were identified as key fields. Extract the values ​​of the key fields and convert them into standard string format; The standard string format values ​​are concatenated in a preset order to generate the string to be verified; The string to be verified is processed using a hash algorithm to generate a current state feature verification value.

3. The intelligent processing method for clinical trial data as described in claim 1, characterized in that, The system retrieves historical state feature verification values ​​stored locally and compares them with the current state feature verification value. Based on the comparison result, it sends subject change data to an external data system via a bidirectional interface and receives data change notifications from the external data system to update the local subject records. This includes: Query the local database to obtain the historical state feature verification value corresponding to the subject record associated with the current state feature verification value; Compare the historical state feature verification value with the current state feature verification value; When the comparison results are inconsistent, the data synchronization direction is determined according to the preset source system priority identifier; If the data synchronization direction indicates that the local system is the update source, the subject change data is sent to the external data system through the bidirectional interface. If the data synchronization direction indicates that the external data system is the update source, then data change notifications are received from the external data system through a bidirectional interface; Update local subject records based on data change notifications or results of subject change data being sent to external data systems.

4. The intelligent processing method for clinical trial data as described in claim 1, characterized in that, Detecting local document operation events to generate change audit logs, and based on these logs, using an asynchronous scheduling mechanism to call the application programming interface (API) of an external document system to perform document synchronization, and receiving document change notifications from the external document system to update the local document status, including: Deploy an event interceptor at the local application layer to detect document upload events, document editing events, and document approval events as local document operation events; Extract the unique document identifier, operation timestamp, and version number associated with the local document operation event; Structured log entries are constructed based on the document's unique identifier, operation timestamp, and version number to generate a change audit log; The pending records in the change audit log are polled using an asynchronous scheduling mechanism. For the pending records identified in the polling process, a document synchronization request is initiated by calling the application programming interface of the external document system. Receive document change notifications from external document systems; Update the local document status based on the unique document identifier and version number contained in the document change notification.

5. The intelligent processing method for clinical trial data as described in claim 1, characterized in that, The system collects real-time context text from the report writing interface, converts the real-time context text into a current semantic vector using a pre-trained language model, and retrieves historical report fragments similar to the current semantic vector from a vector database to generate report content, including: Monitor the cursor position in the report writing interface in real time and extract the paragraph content before the cursor position as real-time context text; The pre-trained language model is invoked to encode the real-time context text, and a high-dimensional feature vector is output as the current semantic vector. Calculate the similarity value between the current semantic vector and the historical report fragment vectors stored in the vector database; Filter out historical report segments whose similarity values ​​exceed a preset threshold; After annotating the source information of the selected historical report fragments, insert them into the editing area of ​​the report writing interface to generate the report content.

6. The intelligent processing method for clinical trial data as described in claim 1, characterized in that, The intelligent verification engine is invoked to analyze the report content, and correction suggestions are generated based on the analysis results, including: Load the pre-built clinical trial standard condition library, medical terminology ontology library and natural language processing model into the intelligent verification engine; The intelligent verification engine performs compliance analysis on the report content based on the clinical trial standard condition library, and generates compliance check results. The intelligent verification engine performs logical consistency analysis on the report content based on a natural language processing model, and generates logical consistency check results. The intelligent verification engine performs terminology consistency analysis on the report content based on the medical terminology ontology, generating terminology consistency check results. The intelligent verification engine performs language quality analysis on the report content based on a natural language processing model to generate language quality check results. Based on the compliance check results, logical consistency check results, terminology uniformity check results, and language quality check results, the intelligent verification engine generates correction suggestions.

7. The intelligent processing method for clinical trial data as described in claim 1, characterized in that, Scan the business condition configuration library to identify pending tasks, predict the optimal notification time based on the pending tasks using user historical behavior data, and send an alert message corresponding to the pending tasks at the optimal notification time, including: Read the enabled business monitoring conditions from the business condition configuration library, and parse the trigger thresholds and inspection cycles contained in the business monitoring conditions; Based on the aforementioned trigger threshold and inspection cycle, scan the associated business data table to identify tasks to be processed; For the task to be processed, extract the click time records from the user's historical behavior data; Based on the click time records, the optimal notification time is predicted using a regression analysis model. Generate an early warning message corresponding to the task to be processed; Send the warning message corresponding to the task to be processed at the optimal notification time.

8. A clinical trial data intelligent processing device, characterized in that, The intelligent processing device for clinical trial data includes: The subject data processing module is used to extract key field values ​​from local subject records and generate current status feature verification values ​​based on the key field values. The data synchronization module is used to retrieve the historical status feature verification value stored locally and compare it with the current status feature verification value. Based on the comparison result, it sends the subject change data to the external data system through a bidirectional interface and receives the data change notification sent by the external data system to update the local subject record. The document synchronization module is used to detect local document operation events to generate change audit logs, and based on the change audit logs, call the application interface of the external document system through an asynchronous scheduling mechanism to perform document synchronization, and receive document change notifications sent by the external document system to update the local document status. The semantic retrieval module is used to collect the real-time context text of the report writing interface, use a pre-trained language model to convert the real-time context text into a current semantic vector, and retrieve historical report fragments similar to the current semantic vector from the vector database to generate report content. The content verification module is used to call the intelligent verification engine to analyze the report content and generate correction suggestions based on the analysis results; The task warning module is used to scan the business condition configuration library to identify tasks to be processed, predict the best notification time based on the task to be processed using user historical behavior data, and send a warning message corresponding to the task to be processed at the best notification time.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a clinical trial data intelligent processing program stored in the memory and executable on the processor. When executed by the processor, the clinical trial data intelligent processing program implements the steps of the clinical trial data intelligent processing method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a clinical trial data intelligent processing program, which, when executed by a processor, implements the steps of the clinical trial data intelligent processing method as described in any one of claims 1-7.

Images