Clinical trial subject whole-process intelligent recruitment platform and method

Abstract

The application provides a subject whole-process intelligent recruitment platform and method for clinical trials, and relates to the technical field of intelligent recruitment. The platform comprises a parameter acquisition module for obtaining multi-dimensional parameters of subjects obtained through preliminary screening; a risk prediction engine for calculating the dropout risk probability of each subject in the whole recruitment process based on the multi-dimensional parameters; a task scheduler for calculating the priority weight of each subject in the recruitment task queue in real time based on the dropout risk probability; and at least one of the following scheduling actions is dynamically executed according to the priority weight: adjusting the task dispatching order, assigning differentiated follow-up actions, and performing resource pre-configuration. The platform changes the recruitment mode from passive waiting and undifferentiated processing to active intervention and precise scheduling, and directly allocates resources to the key nodes and key subjects that are most needed and can produce the most value, thereby greatly reducing the subject loss rate in the process and significantly improving the enrollment efficiency.

Description

Intelligent recruitment platform and method for clinical trial subjects throughout the entire process Technical Field

[0001] This application relates to the field of intelligent recruitment technology, specifically to an intelligent recruitment platform and method for the entire process of clinical trials. Background Technology

[0002] In clinical trial participant recruitment, initially screening out a large number of potential participants is only the first step. The real challenge lies in how to successfully "retain" them and get them through the complex enrollment process until they officially participate in the trial. Traditional recruitment management systems, such as AI screening systems based on fixed rules, can complete the initial screening of massive amounts of medical records, but their subsequent management methods are crude and passive.

[0003] As demonstrated in a clinical trial of a hypoglycemic drug, after the system sent out mass invitations, the research team found itself in a passive response: for subjects who agreed but delayed signing the informed consent form (such as patient A), the system could not identify their attrition risk, nor could it trigger effective follow-up, leading to their natural attrition; for subjects who might give up during the examination process due to its cumbersome nature (such as patient B), the system could not predict their tendency to back down, thus failing to prioritize resources to simplify their process; for subjects who were highly motivated but needed immediate action (such as patient C), the system lacked priority judgment, causing their enthusiasm to cool down while they waited.

[0004] The fundamental problem is that existing technologies place subjects in different states and at different risks on the same assembly line for indiscriminate processing, making it impossible to identify individuals who are about to be lost in real time, let alone perform differentiated and remedial resource allocation. Ultimately, this leads to the loss of a large number of high-quality candidates in the cumbersome process, resulting in extremely low recruitment efficiency. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, this application aims to provide a smart recruitment platform and method for subjects throughout the entire clinical trial process.

[0006] Firstly, this application proposes an intelligent recruitment platform for the entire subject recruitment process in clinical trials, comprising:

[0007] The parameter acquisition module is configured to acquire multi-dimensional parameters of the subjects obtained from the initial screening. These multi-dimensional parameters include historical behavioral parameters and real-time response parameters.

[0008] The risk prediction engine is connected in communication with the parameter acquisition module and is configured to calculate the dropout risk probability of each subject throughout the recruitment process based on the multi-dimensional parameters.

[0009] The task scheduler, which communicates with the risk prediction engine, is configured to:

[0010] Based on the dropout risk probability, the priority weight of each subject in the recruitment task queue is calculated in real time.

[0011] Based on the aforementioned priority weights, at least one of the following scheduling actions will be dynamically executed:

[0012] Adjust the task assignment order: In the task assignment queue, prioritize assigning follow-up tasks to subjects with high weights;

[0013] Differentiated follow-up actions are assigned: For subjects whose priority weight is higher than the first preset threshold, an active communication task that needs to be performed by a human agent is automatically generated and triggered; For subjects whose priority weight is lower than the second preset threshold, they are automatically included in a standardized reminder process driven by system messages.

[0014] Perform resource pre-configuration: For subjects whose priority weight is higher than the third preset threshold, generate a resource pre-allocation request to complete the subsequent key enrollment examinations for them.

[0015] According to the technical solution provided in this application, the historical behavior parameters include at least one of the following extracted from historical interaction records provided by the subject or publicly available:

[0016] Historical reservations or commitments performance reliability assessment indicators;

[0017] Consistency assessment of long-term health management behaviors;

[0018] Consistent behavioral patterns in historical participation in research or health-related activities;

[0019] The real-time response parameters include at least one of the following, which are obtained in real time through the interaction records between the subject and the recruitment platform during this recruitment process:

[0020] Initial response delay to recruitment invitations;

[0021] The interaction depth metric on the interface for accessing informed consent-related materials;

[0022] The online preliminary assessment questionnaire included data on completeness, attentiveness, and modification behavior.

[0023] According to the technical solution provided in this application, the risk prediction engine is specifically configured for:

[0024] The historical behavioral parameters and real-time response parameters are standardized and combined to generate an initial feature vector for each subject;

[0025] According to the protocol of the target clinical trial, the corresponding trial-specific risk prediction model is loaded from the pre-built model library; wherein, the trial-specific risk prediction model is obtained by analyzing the characteristics of the inclusion and exclusion criteria of the trial and the target intervention and pre-adjusting the feature weights of the basic machine learning model;

[0026] Based on the intensity of the subject's current willingness to participate reflected by the real-time response parameters, the weight distribution of historical behavior parameters and real-time response parameters in the initial feature vector is dynamically adjusted to generate a dynamic feature vector; wherein, the stronger the current willingness to participate, the higher the weight of the real-time response parameters is assigned.

[0027] The dynamic feature vector is input into the loaded test-specific risk prediction model to calculate and output the dropout risk probability.

[0028] According to the technical solution provided in this application, it further includes an execution engine communicatively connected to the task scheduler, the execution engine being configured for:

[0029] Receive the scheduling action, which includes the proactive communication task, the standardized reminder process, and the resource pre-allocation request;

[0030] The scheduling actions are converted into standardized instructions that match the interface of the target collaborative system;

[0031] The standardized instructions are sent to the corresponding target collaboration system for their relevant parties to receive and process;

[0032] The target collaboration system includes a coordination system for coordinating inspection resources and a workflow system for allocating manual tasks.

[0033] According to the technical solution provided in this application, the execution engine is specifically configured for:

[0034] When a scheduling action corresponding to the resource pre-occupancy request is received, a resource coordination suggestion conforming to the target coordination system interface specification is generated based on the subject's priority weight, the required examination type, and the expected time period.

[0035] The resource coordination proposal will be sent to the coordination system used to coordinate and inspect resources, so that the relevant coordinators can review and process it.

[0036] When a scheduling action triggering an active communication task is received, a task work order containing personalized communication points is generated based on the subject's multi-dimensional parameters and the current recruitment stage.

[0037] The task order is pushed to the workflow system for allocating manual tasks via a message queue, and the status of the agent task pool is updated in real time.

[0038] According to the technical solution provided in this application, it also includes a policy management module that is communicatively connected to the task scheduler, configured for:

[0039] Real-time monitoring of global indicators reflecting the overall recruitment status of the clinical trial includes the current size and growth rate of the pool of qualified subjects, the remaining time until the planned enrollment deadline of the project, and the real-time idle rate of key examination resources.

[0040] Based on the global metrics, the first preset threshold, the second preset threshold, and the third preset threshold used by the task scheduler are calculated and updated.

[0041] According to the technical solution provided in this application, the strategy management module is specifically configured for:

[0042] When the size of the pool of qualified subjects is lower than the safe level or the remaining time is less than the urgent threshold, the first preset threshold and the third preset threshold are lowered so that more subjects can be included in the scope of high-priority follow-up and resource pre-allocation.

[0043] When the real-time idle rate is lower than the resource shortage threshold, the third preset threshold is increased to tighten the resource pre-occupancy eligibility to the highest priority subjects.

[0044] According to the technical solution provided in this application, the task scheduler is further configured to:

[0045] For each subject, a task flow model based on a directed acyclic graph is maintained, where nodes represent specific follow-up tasks and directed edges represent the dependencies and execution order between tasks.

[0046] When dynamically generating scheduling instructions, the task scheduler is specifically configured to:

[0047] The following two analyses are executed in parallel:

[0048] Check if all prerequisite tasks for the current high-priority task have been completed. If not, prioritize scheduling the incomplete prerequisite tasks.

[0049] Based on resource pre-configuration information, the peak resource demand in future time periods is predicted, and tasks that may compete for the same resource time period are scheduled in a staggered manner.

[0050] According to the technical solution provided in this application, the risk prediction engine is also configured to:

[0051] The final recruitment status data of the subjects will be continuously collected, including: successful enrollment, voluntary withdrawal, or failure to be screened.

[0052] The final recruitment status data is correlated and compared with the previously calculated dropout risk probability to generate feedback data for the trial-specific risk prediction model.

[0053] Secondly, this application proposes a fully intelligent recruitment method for subjects in clinical trials, implemented on the platform described above, including the following steps:

[0054] Obtain multi-dimensional parameters of subjects who have passed the initial screening, including historical behavioral parameters and real-time response parameters;

[0055] Based on the aforementioned multi-dimensional parameters, the dropout risk probability of each subject throughout the entire recruitment process is calculated;

[0056] Based on the dropout risk probability, the priority weight of each subject in the recruitment task queue is calculated in real time.

[0057] Based on the aforementioned priority weights, at least one of the following scheduling actions will be dynamically executed:

[0058] Adjust the task assignment order, and prioritize assigning follow-up tasks to high-weight subjects in the task assignment queue;

[0059] For subjects whose priority weight is higher than the first preset threshold, an active communication task that needs to be performed by a human agent is automatically generated and triggered; for subjects whose priority weight is lower than the second preset threshold, they are automatically included in a standardized reminder process driven by system messages.

[0060] For subjects whose priority weight is higher than the third preset threshold, the resource time slots required to complete subsequent key enrollment examinations are reserved in advance in the hospital's examination appointment system.

[0061] Compared with existing technologies, the beneficial effects of this application are as follows: This platform, by introducing dynamic risk prediction and intelligent task scheduling, achieves accurate identification and proactive intervention for subjects at high dropout risk, thereby effectively preventing dropout after acceptance. By analyzing the subject's historical behavior and real-time response parameters, the platform can accurately calculate the high dropout risk for subjects like "Patient A". The task scheduler then adjusts the follow-up task to the highest priority and automatically generates a proactive communication task with a human agent. A single phone call can promptly remind or resolve their concerns, nipping dropout in the bud. Proactively resolving procedural abandonment: For cases like "Patient B", who may abandon due to complex procedures during the examination process, once the platform predicts a high dropout probability, the task scheduler will pre-lock key resources for them in the hospital's examination system, simplify their appointment process, and even arrange a green channel, directly eliminating the main reason for their abandonment due to "feeling it's troublesome". Maximizing High Enthusiasm: For high-quality and proactive participants like "Patient C," the system assigns high weight due to their low dropout risk, ensuring their tasks are prioritized and allowing them to seamlessly transition to the next stage of the process. This maintains their enthusiasm and quickly converts them into successfully enrolled participants. In summary, this platform transforms the recruitment model from "passive waiting and indiscriminate processing" to "proactive intervention and precise scheduling," directly and accurately allocating resources to the most needed and valuable key nodes and participants, thereby significantly reducing participant attrition rates and dramatically improving enrollment efficiency. Attached Figure Description

[0062] Figure 1 is a schematic diagram of the structure of the intelligent recruitment platform for clinical trial subjects provided in the embodiments of this application.

[0063] The text labels in the image represent:

[0064] 1. Parameter acquisition module; 2. Risk prediction engine; 3. Task scheduler. Detailed Implementation

[0065] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0066] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0067] Example 1

[0068] As mentioned in the background section, in response to the problems in the prior art, this application proposes an intelligent recruitment platform for the entire subject recruitment process in clinical trials, as shown in Figure 1, including:

[0069] Parameter acquisition module 1 is configured to acquire multi-dimensional parameters of subjects obtained from the initial screening, including historical behavior parameters and real-time response parameters;

[0070] Risk prediction engine 2 is communicatively connected to parameter acquisition module 1 and configured to calculate the dropout risk probability of each subject throughout the recruitment process based on the multi-dimensional parameters.

[0071] Task scheduler 3, which is communicatively connected to the risk prediction engine 2, is configured for:

[0072] Based on the dropout risk probability, the priority weight of each subject in the recruitment task queue is calculated in real time.

[0073] Based on the aforementioned priority weights, at least one of the following scheduling actions will be dynamically executed:

[0074] Adjust the task assignment order: In the task assignment queue, prioritize assigning follow-up tasks to subjects with high weights;

[0075] Differentiated follow-up actions are assigned: For subjects whose priority weight is higher than the first preset threshold, an active communication task that needs to be performed by a human agent is automatically generated and triggered; For subjects whose priority weight is lower than the second preset threshold, they are automatically included in a standardized reminder process driven by system messages.

[0076] Perform resource pre-configuration: For subjects whose priority weight is higher than the third preset threshold, generate a resource pre-allocation request to complete the subsequent key enrollment examinations for them.

[0077] Specifically, Parameter Acquisition Module 1 is the system's data entry point, responsible for automatically collecting subject-related data from multiple sources. In practice, it retrieves data through the Hospital Information System (HIS), the Electronic Data Capture (EDC) system for clinical trials, and a customized recruitment mini-program or website backend via Application Programming Interface (API). Multi-dimensional parameters refer to the diverse sources and types of data, aiming to comprehensively depict the subject's state. They are specifically divided into: Historical Behavioral Parameters: These refer to the behavioral footprint left by the subject during past medical treatments or research participation; this data can predict future behavioral patterns and compliance. Real-time Response Parameters refer to the instantaneous data generated during the subject's interaction with the recruitment platform in this specific recruitment process, reflecting the intensity of their current interest and willingness. Risk Prediction Engine 2 is the platform's brain, responsible for transforming raw data into predictive insights. Its implementation is a typical machine learning modeling and application process.

[0078] First, the engine standardizes the collected multi-dimensional parameters. For example, it converts "late arrival rate" into a value between 0 and 1, and "medication adherence" from textual descriptions (such as "good" or "average") into numerical scores. The processed data is combined into a structured initial feature vector, a sequence of numbers representing the subject's characteristics that the machine learning model can understand. Next, the engine loads the most suitable trial-specific risk prediction model from a pre-trained model library, based on the characteristics of the ongoing clinical trial. This model is specific because it is optimized for the inclusion and exclusion criteria (such as strict blood glucose ranges) and characteristics of the target intervention (such as the need for frequent injections) of a general model, making it more sensitive to relevant features. Then, the engine performs dynamic weight allocation. For example, if a subject's real-time response to recruitment is very positive (such as quickly completing the questionnaire), the engine judges their current willingness to participate and appropriately reduces the weight of potential past behavioral flaws (such as a history of late arrivals) when calculating the final risk, focusing more on their current positive performance. This process generates a dynamic feature vector that better reflects the real-time status. Finally, this dynamic feature vector is input into the selected prediction model, which outputs a value between 0 and 1, representing the dropout risk probability. This probability value quantifies the likelihood that the subject will withdraw from the recruitment process in the future.

[0079] Specifically, Task Scheduler 3 is the platform's command center, translating risk predictions into concrete, actionable instructions. Its core logic is that resources should be allocated to high-risk or high-value subjects. Real-time priority weight calculation: The system doesn't directly use risk probability for scheduling; instead, it combines other factors (such as the subject's compliance with key inclusion criteria, project urgency, etc.) to calculate a more operationally meaningful priority weight. A higher weight signifies greater value in taking immediate action on that subject. Dynamic execution of scheduling actions includes: adjusting task assignment order: On the task management interface used by researchers, the system automatically sorts the task list. For example, the "phone follow-up" task for subject A, who has just shown signs of hesitation (high risk probability), will be prioritized and highlighted; while the "send routine reminders" task for subject B, who has remained stable (low risk probability), will be placed later. This ensures that researchers always prioritize the most urgent tasks. Differentiated Follow-up Actions: For subjects with a priority weight higher than the first preset threshold (e.g., 0.8), the system determines that they urgently require human intervention and automatically generates and triggers a proactive communication task to be performed by a human agent. This task, carrying the subject's basic information and high-risk reasons, is directly pushed to the desktop or mobile application of a specific research coordinator, ensuring timely communication by phone or in person to resolve concerns. For subjects with a priority weight lower than the second preset threshold (e.g., 0.3), the system determines that their condition is stable and does not require valuable human resources. Therefore, they are automatically included in a standardized reminder process driven by system messages, i.e., routine follow-up via automatic SMS or email, thereby freeing up human resources. Resource Pre-allocation: For extremely important subjects with a priority weight higher than the third preset threshold (e.g., 0.9) and a very high risk of attrition, the platform takes proactive action. Based on the trial protocol and the subject's profile, the platform automatically generates a well-structured and complete "resource pre-allocation request" (or "resource coordination suggestion"). This request integrates the specific tests required by the participant (such as the OGTT glucose tolerance test), the test constraints parsed from the protocol (such as fasting requirements), and recommends a desired execution time window. Subsequently, this standardized request is sent via a secure interface to the hospital's research coordinator's work system or resource coordination platform. This means that before the participant formally initiates the manual appointment process, the hospital coordinator receives a clear, high-priority electronic notification regarding the participant's test needs. This allows the coordinator to proactively coordinate or reserve time within their internal system, significantly shortening the waiting time from eligibility confirmation to test execution and effectively reducing the risk of participant attrition due to resource scheduling delays.

[0080] In a preferred embodiment, the historical behavioral parameters include at least one of the following extracted from historical interaction records provided by the subject with authorization or publicly available:

[0081] Historical reservations or commitments performance reliability assessment indicators;

[0082] Consistency assessment of long-term health management behaviors;

[0083] Consistent behavioral patterns in historical participation in research or health-related activities;

[0084] The real-time response parameters include at least one of the following, which are obtained in real time through the interaction records between the subject and the recruitment platform during this recruitment process:

[0085] Initial response delay to recruitment invitations;

[0086] The interaction depth metric on the interface for accessing informed consent-related materials;

[0087] The online preliminary assessment questionnaire included data on completeness, attentiveness, and modification behavior.

[0088] Specifically, the acquisition and calculation of historical behavioral parameters: This platform collects historical interaction records from subjects with explicit authorization or from publicly available sources, and constructs the historical behavioral parameters using at least one of the following methods:

[0089] Reliability assessment indicators for historical appointments or commitments: Analysis of the subject's authorized access to personal calendar records, SMS / email confirmation receipts, or verifiable online appointment vouchers. The core indicator is the fulfillment rate (actual fulfillment counts / total appointment counts) of all confirmed appointments within a specific historical period (e.g., the past 12 months). This is further weighted by the average lateness or advance cancellation notification rate (the percentage of cancellations made more than 24 hours in advance) to generate a comprehensive reliability score ranging from 0 to 1.

[0090] Consistency assessment of long-term health management behaviors: After obtaining the subject's authorization, access the anonymized data interface of the health management application (APP) they use, or analyze their publicly verifiable long-term service usage records (such as regular medication delivery records). By calculating the regularity of execution of specific health management behaviors (such as daily medication check-in, weekly exercise records) (e.g., calculating the coefficient of variation of behavior intervals) and long-term adherence (number of consecutive weeks of compliance / total number of observation weeks), an assessment value reflecting the stability and compliance of their behavior is formed.

[0091] Consistent behavioral patterns in historical participation in research or health-related activities: Based on participants' self-reported and authorized verification participation history (such as proof of past participation as health volunteers in physical examinations or public health surveys), without involving confidential details of specific clinical trials. By analyzing their participation completion rate (whether they followed the entire process), feedback timeliness (the speed of submitting questionnaires or providing feedback) and the stability of behavioral sequences in different activities (e.g., whether they always follow the standard "registration-confirmation-participation-feedback" process), pattern recognition algorithms (such as Hidden Markov Models) are used to extract their habitual behavioral pattern feature vectors to quantify the predictability and reliability of their behavior.

[0092] Real-time response parameter acquisition and calculation:

[0093] During this recruitment process, the platform records all interaction events between the test taker and the recruitment interface, and calculates the following parameters in real time:

[0094] Initial response delay to recruitment invitations: The precise time interval (in minutes or hours) from when the system sends the recruitment invitation (e.g., SMS, push notification) to when the subject first clicks the invitation link or opens the relevant application. This parameter can be used directly as a raw value or after logarithmic transformation to reflect the subject's initial interest and initiative.

[0095] Interaction depth metrics on the informed consent-related materials access interface: Non-content-based user behavior data is anonymously collected through the interaction monitoring SDK embedded in the electronic informed consent form (eICF) browser, including:

[0096] Page browsing completeness: Calculate the percentage of total browsing time spent on key sections (such as risk and benefit, privacy protection, and voluntary opt-out terms).

[0097] Interaction activity: Records the pattern of changes in page scrolling speed and the number of clicks on expandable details.

[0098] Repeated reading behavior: Count the number of times the same chapter is returned and reread.

[0099] After normalizing the above behavioral data, an interaction depth score representing "understanding seriousness and engagement" is output through a pre-trained shallow neural network model.

[0100] Online preliminary assessment of questionnaire completion completeness, attentiveness, and modification behavior data:

[0101] Completeness: Directly calculate the percentage of completed required and optional fields out of the total number of fields.

[0102] Attentiveness Index: This is determined by analyzing the sequence of behaviors during the completion process, including but not limited to:

[0103] Single-question dwell time distribution: For critical health history questions, dwell time significantly higher or lower than the average may indicate either careful consideration or hasty response.

[0104] Answer consistency check: Perform internal consistency checks on answers to logically related questions (such as "Do you smoke?" and "Daily smoking amount").

[0105] Non-linear filling mode: Detects for frequent jumps and modifications, which may reflect hesitation or difficulty in understanding.

[0106] Modification behavior data: Record the total number of modifications, the stage at which the modification occurred (during initial completion, before final submission), and the set of question types involved in the modification (e.g., symptom description). These behavioral patterns are encoded as features to assess the subject's decision certainty.

[0107] In a preferred embodiment, the risk prediction engine 2 is specifically configured to:

[0108] The historical behavioral parameters and real-time response parameters are standardized and combined to generate an initial feature vector for each subject;

[0109] According to the protocol of the target clinical trial, the corresponding trial-specific risk prediction model is loaded from the pre-built model library; wherein, the trial-specific risk prediction model is obtained by analyzing the characteristics of the inclusion and exclusion criteria of the trial and the target intervention and pre-adjusting the feature weights of the basic machine learning model;

[0110] Based on the intensity of the subject's current willingness to participate reflected by the real-time response parameters, the weight distribution of historical behavior parameters and real-time response parameters in the initial feature vector is dynamically adjusted to generate a dynamic feature vector; wherein, the stronger the current willingness to participate, the higher the weight of the real-time response parameters is assigned.

[0111] The dynamic feature vector is input into the loaded test-specific risk prediction model to calculate and output the dropout risk probability.

[0112] Specifically, the initial feature vector is generated by the engine receiving raw parameters with varying dimensions (e.g., "response delay time" in minutes, "drug adherence" in scores of 0-100, and "cancellation rate" in percentages). The engine then performs standardization (also known as normalization). For example, Z-score standardization is used to convert each parameter value into a distribution with a mean of 0 and a standard deviation of 1. This process eliminates the influence of dimensions, making different parameters comparable. These processed values ​​are then concatenated into a numerical array in a predetermined order, forming the initial feature vector. This vector is a digital fingerprint that the computer can understand, representing the characteristics of the subject. The platform maintains a pre-built model library containing baseline prediction models for different trial types (e.g., logistic regression, gradient boosting decision trees, etc.). When a new clinical trial project is launched, the platform administrator configures the project's basic information. The engine automatically selects or fine-tunes a model based on the protocol of the target clinical trial. The trial-specificity is reflected in the fact that during model training or initialization, the inclusion and exclusion criteria and the characteristics of the target intervention are given special consideration. For example, for a trial of a hypoglycemic drug requiring twice-daily injections, the engine will load a model that assigns higher feature weights to features such as "drug adherence" and "fear of injection" (which may be inferred from questionnaires). This means that even if a general algorithm is used, the model has been structurally pre-adjusted for the specific risk factors of the current trial, making it more targeted. The generation of dynamic feature vectors introduces dynamic adaptation capabilities. The engine does not view all parameters statically but dynamically weighs them based on the strength of the participants' current willingness. The system first calculates a proxy index of the current willingness to participate based on real-time response parameters (such as response delay and informed consent reading behavior). Then, based on this strength value, the engine dynamically adjusts the weight allocation of the two main categories of historical behavior parameters and real-time response parameters in the initial feature vector. The logic is: the stronger the current willingness to participate, the higher the weight of the real-time response parameters is assigned. For example, a participant's historical data might show a high "appointment cancellation rate" (high weight of historical parameters, indicating high risk). However, in this recruitment, they clicked the link within one minute of receiving the text message and spent 15 minutes carefully reading the informed consent form (extremely high weight of real-time parameters, indicating high willingness). In this case, the engine generates a dynamic feature vector by increasing the weight of the real-time parameters. This vector is more biased towards reflecting their "current positivity," potentially calculating a moderate rather than extremely high risk probability, avoiding rejecting a potential participant with strong current willingness based solely on historical performance. Ultimately, this dynamically weighted feature vector, which better reflects the participant's real-time state, is input into the previously loaded trial-specific risk prediction model. The model performs forward computation and outputs a probability value between 0 and 1, representing the dropout risk probability.This probability is not a simple fraction, but a highly contextualized prediction that integrates long-term behavioral patterns, current willingness intensity, and specific experimental requirements.

[0113] In a preferred embodiment, an execution engine communicatively connected to the task scheduler 3 is further included, the execution engine being configured to:

[0114] Receive the scheduling action, which includes the proactive communication task, the standardized reminder process, and the resource pre-allocation request;

[0115] The scheduling actions are converted into standardized instructions that match the interface of the target collaborative system;

[0116] The standardized instructions are sent to the corresponding target collaboration system for their relevant parties to receive and process;

[0117] The target collaboration system includes a coordination system for coordinating inspection resources and a workflow system for allocating manual tasks.

[0118] Furthermore, the execution engine is specifically configured for:

[0119] When a scheduling action corresponding to the resource pre-occupancy request is received, a resource coordination suggestion conforming to the target coordination system interface specification is generated based on the subject's priority weight, the required examination type, and the expected time period.

[0120] The resource coordination proposal will be sent to the coordination system used to coordinate and inspect resources, so that the relevant coordinators can review and process it.

[0121] When a scheduling action triggering an active communication task is received, a task work order containing personalized communication points is generated based on the subject's multi-dimensional parameters and the current recruitment stage.

[0122] The task order is pushed to the workflow system for allocating manual tasks via a message queue, and the status of the agent task pool is updated in real time.

[0123] Specifically, in the system architecture, the execution engine continuously listens to the internal instruction message queue from task scheduler 3. When a new scheduling action appears in the queue, the execution engine retrieves it in real time. These scheduling actions exist in the form of structured instruction objects, for example:

[0124] {"action": "generate_resource_request", "subject_id": "ID-123", "exam_type": "OGTT"} (Generate resource pre-request)

[0125] {“action”: “create_manual_task”, “subject_id”: “ID-456”, “task_type”:“proactive_call”} (Create a proactive communication task)

[0126] Transformed into standardized harmonized directives:

[0127] The execution engine internally maintains a collaborative system interface adapter library. It invokes the corresponding adapter based on the type of the received scheduled action.

[0128] For the "Generate Resource Reservation Request" instruction: The adapter retrieves complete subject profiles, trial protocol requirements, and intelligently recommended time windows from the platform's internal database and encapsulates them into a structured resource coordination proposal. This proposal follows the data exchange specifications agreed upon with the hospital's "Coordination System for Coordinating Examination Resources" (e.g., using a specific JSON Schema or XML template). The proposal explicitly identifies itself as a "reservation proposal," including recommended examinations, desired time slots, priority descriptions, and a summary of clinical rationale, but does not contain any commands that directly lock in resources.

[0129] For the "Create Human Task" instruction: the adapter generates a standardized task work order whose format is compatible with the target "workflow system for assigning human tasks" (such as conforming to the Jira Issue Creation API format for specific project management tools, or the initiation template for DingTalk / WeChat Work OA processes). This work order includes the subject's background, system-generated communication points, suggested processing time, etc., to facilitate efficient processing by agents.

[0130] Send for receiving and processing:

[0131] After generating standardized instructions, the execution engine sends the instructions as a collaborative message to the corresponding target collaborative system via an encrypted HTTPS / TLS channel or a hospital-approved dedicated line / VPN.

[0132] For resource coordination suggestions, the message is sent to a collaborative to-do interface designed for Clinical Research Coordinators (CRCs) or investigators within the coordination system. Upon receiving the suggestion, the system typically generates a highlighted to-do item in the coordinator's console.

[0133] For a task order, the message is pushed to the task creation API of the workflow system, where a new task is automatically generated and may be assigned to a specific research nurse or coordinator according to rules.

[0134] In this implementation, the interface is not with the business system that directly operates the underlying resources, but with a collaborative system that serves the research team and is used for process coordination.

[0135] The coordination system used to coordinate examination resources typically refers to the clinical research project management platform or subject visit coordination center module used by clinical trial teams within the hospital. This platform itself does not directly operate the radiology or laboratory appointment systems, but it provides a centralized interface for CRCs to track all examinations awaiting coordination. The "resource reservation request" sent by the platform is essentially a high-priority request for examination coordination that requires manual follow-up. Once the CRC sees the request on the platform, they then contact the relevant departments through established hospital procedures (such as telephone or the hospital's OA system) for manual coordination and reservation.

[0136] Workflow systems for assigning manual tasks: This system is a tool for task distribution, tracking, and collaboration within the research team, such as Jira, Asana, DingTalk Tasks, or customized CRC workbenches. Integration with the platform enables seamless embedding of intelligent scheduling instructions into the research team's daily workflow. Created task tickets become part of the team's shared task pool, avoiding duplicate information entry across different systems and ensuring clear attribution of follow-up responsibilities and visibility of status.

[0137] In a preferred embodiment, a policy management module communicatively connected to the task scheduler 3 is further included, configured for:

[0138] Real-time monitoring of global indicators reflecting the overall recruitment status of the clinical trial includes the current size and growth rate of the pool of qualified subjects, the remaining time until the planned enrollment deadline of the project, and the real-time idle rate of key examination resources.

[0139] Based on the global metrics, the first preset threshold, the second preset threshold, and the third preset threshold used by the task scheduler 3 are calculated and updated.

[0140] Specifically, the strategy management module, as an independent, high-level monitoring and decision-making component, communicates with the task scheduler 3. It no longer focuses on the status of individual subjects, but elevates the perspective to the entire clinical trial project. It is configured to: Real-time monitor global metrics: This module continuously pulls or receives data streams from the platform database and various business systems, calculating and maintaining a set of global metrics reflecting the overall health of trial recruitment. These metrics serve as the system's sensors for macro-level decision-making. Calculate and update scheduling thresholds: Based on the real-time values ​​of these global metrics, the strategy management module runs a built-in decision-making algorithm to dynamically calculate new suggested values ​​for the first preset threshold (triggering human intervention), the second preset threshold (triggering automatic reminders), and the third preset threshold (triggering resource pre-allocation) used by the task scheduler 3, and pushes these values ​​to the task scheduler 3 in real time, enabling it to immediately apply the new strategy.

[0141] Specifically, global metrics include: the size and growth rate of the current pool of qualified subjects: size refers to the total number of subjects who have passed the initial screening, have not yet been enrolled, and are in an active follow-up status. Growth rate refers to the number of newly qualified subjects per unit of time (e.g., daily). In practice, the system calculates this metric by aggregating and querying subject status records in the recruitment database. Remaining time until the project's planned enrollment deadline: This is the difference between a fixed deadline obtained from the project master data and the current system time, usually in "days". Real-time idle rate of critical examination resources: For example, for the "OGTT examination," which is crucial to this project, the strategy management module will query the examination appointment system API to obtain the number of booked time slots and the total number of available time slots for the examination within the next week, and calculate the idle rate ((total time slots - booked time slots) / total time slots).

[0142] In a preferred embodiment, the policy management module is specifically configured to:

[0143] When the size of the pool of qualified subjects is lower than the safe level or the remaining time is less than the urgent threshold, the first preset threshold and the third preset threshold are lowered so that more subjects can be included in the scope of high-priority follow-up and resource pre-allocation.

[0144] When the real-time idle rate is lower than the resource shortage threshold, the third preset threshold is increased to tighten the resource pre-occupancy eligibility to the highest priority subjects.

[0145] Specifically, lowering the first and third preset thresholds (to address enrollment pressure): When the strategy management module detects a lag in enrollment progress, it implements a strategy of "relaxing standards and actively intervening." The implementation process is as follows:

[0146] Triggering condition judgment: The module has two key judgment nodes:

[0147] The qualified participant pool size is below the safe level or the remaining time is less than the urgency threshold. This safe level is a configurable parameter, typically calculated dynamically based on the project's total target enrollment and expected attrition rate; for example, it could be 1.5 times the remaining enrollment target. If the number of qualified participants in the current pool is less than this value, it indicates insufficient candidate reserves. The remaining time is less than the urgency threshold. This urgency threshold is also configurable, for example, a quarter of the total project duration or a fixed number of days (e.g., 30 days). Threshold adjustment: When both of the above conditions are met, the module generates an adjustment command. For example, it might execute:

[0148] First preset threshold = original first preset threshold * 0.9 (e.g., decreasing from 0.8 to 0.72)

[0149] The third preset threshold = the original third preset threshold * 0.85 (e.g., decreasing from 0.9 to 0.765).

[0150] This operation essentially lowers the threshold for triggering high-intensity interventions (human intervention, resource pre-allocation). Previously, only subjects with a risk probability of 0.8 or higher were contacted manually; now, those with a probability of 0.72 or higher are contacted. Previously, only those with a risk probability of 0.9 or higher could have resources pre-allocated; now, those with a probability of 0.765 or higher can. This allows the system to allocate limited resources and manpower to a larger number of subjects, using more proactive methods to "rescue" those with moderate risk but still potential for enrollment, and making every effort to achieve enrollment targets.

[0151] Implementation of raising the third preset threshold (to address resource constraints):

[0152] When the strategy management module detects that critical resources are becoming scarce, it executes a "tighten resources, ensure priority" strategy. The implementation process is as follows:

[0153] Trigger condition judgment: The module continuously monitors the resource status:

[0154] A real-time idle rate below the resource shortage threshold is considered to indicate extreme resource shortage. For example, if less than 10% of the available time slots for a critical check remain within the next week (i.e., idle rate < 10%), then resources are considered extremely scarce.

[0155] Execution threshold adjustment: When this condition is met, the module will individually increase the resource pre-allocation threshold. For example:

[0156] Third preset threshold = min(original third preset threshold * 1.1, 1.0) (e.g., increasing from 0.9 to 0.99)

[0157] Specifically, this implementation method can address enrollment pressure by: when the pool of qualified subjects is below the safe level (e.g., only 20 remain, while the target is to enroll 50 more) or the remaining time is less than the urgency threshold (e.g., only 30 days left), the system determines that enrollment pressure is significant. In this case, lowering the first and third preset thresholds means relaxing the criteria for "high priority." For example, the risk probability threshold for triggering human intervention is lowered from 0.8 to 0.6, and the resource pre-allocation threshold is lowered from 0.9 to 0.7. This allows more subjects with moderate risk to receive "VIP" level attention and resource allocation, aiming to maximize the number of successfully enrolled subjects—a radical "cast a wide net, catch the best fish" strategy.

[0158] Optimizing resource utilization: When the real-time idle rate falls below the resource scarcity threshold (e.g., an idle rate below 10% for OGTT examinations), it means that examination resources have become extremely scarce. In this case, raising the third pre-set threshold (e.g., from 0.7 back to 0.9) tightens the pre-allocation of resources, ensuring that only the highest-risk, most valuable "top-tier" subjects are eligible to reserve resources in advance. This ensures that the most valuable examination resources are allocated to subjects most likely to be successfully enrolled and most in need of immediate intervention, avoiding resource waste—a conservative strategy of "using resources wisely."

[0159] This dynamic threshold adjustment mechanism transforms the recruitment platform from a rigid set of automated rules into an organic whole that can sense environmental pressures and intelligently adjust its behavior to always serve the ultimate goal of "accelerating enrollment," significantly improving the success rate and operational efficiency of projects in complex clinical environments.

[0160] In a preferred embodiment, the task scheduler 3 is further configured to:

[0161] For each subject, a task flow model based on a directed acyclic graph is maintained, where nodes represent specific follow-up tasks and directed edges represent the dependencies and execution order between tasks.

[0162] When dynamically generating scheduling instructions, the task scheduler 3 is specifically configured to:

[0163] The following two analyses are executed in parallel:

[0164] Check if all prerequisite tasks for the current high-priority task have been completed. If not, prioritize scheduling the incomplete prerequisite tasks.

[0165] Based on resource pre-configuration information, the peak resource demand in future time periods is predicted, and tasks that may compete for the same resource time period are scheduled in a staggered manner.

[0166] Specifically, the task flow model is implemented based on a directed acyclic graph (DAG):

[0167] Task Scheduler 3 maintains an independent task flow model for each participant, using a Directed Acyclic Graph (DAG) to abstractly describe all their pending tasks. Nodes represent specific follow-up tasks. For example, "sending informed consent form," "confirming baseline examination intention by phone," "scheduling OGTT examination," "confirming examination results as satisfactory," and "signing formal enrollment documents" are all nodes. Directed edges represent the dependencies and execution order between tasks. An arrow pointing from node A to node B indicates that "task A must be completed before task B." For example, the "signing formal enrollment documents" node necessarily has a directed edge from the "confirming examination results as satisfactory" node, meaning that signing can only occur after the examination results are confirmed as satisfactory. This dependency ensures the logical correctness of the business process and prevents violations such as "enrolling before examination."

[0168] Parallel analysis during dynamic generation of scheduling instructions: When it is necessary to decide which task to execute next, Task Scheduler 3 no longer simply sorts by weight, but performs the following two advanced analyses in parallel:

[0169] Dependency analysis:

[0170] When the system identifies a high-priority task (e.g., "schedule an OGTT check"), the scheduler first checks in the DAG model whether all its prerequisite tasks have been completed. It traverses its prerequisite nodes by backtracking all directed edges pointing to that node. If a prerequisite task (e.g., "confirm baseline check intention by phone") is found to be "incomplete" or "in progress," the scheduler prioritizes scheduling this incomplete prerequisite task. This ensures the logical rigor of the workflow. Even if "scheduling a check" is very urgent, if the subject's willingness to participate in the check is not yet confirmed, the scheduling action may be invalid, resulting in wasted resources. This analysis can intelligently identify and address such shortcomings in the process.

[0171] Resource competition analysis:

[0172] The scheduler predicts peak resource demand in future time periods based on pre-configured resource information. For example, by analyzing the number of subjects about to enter the "appointment check" node in the DAG, it predicts that a large number of OGTT check appointment requests may occur between 10:00 and 11:00 AM tomorrow. To prevent these tasks from competing for the same resource time period in the future, the scheduler will perform time-staggered scheduling. It may intelligently dispatch some subjects' "appointment check" tasks a few hours earlier or later, thereby smoothing out the request pressure over time.

[0173] In a preferred embodiment, the risk prediction engine 2 is further configured to:

[0174] The final recruitment status data of the subjects will be continuously collected, including: successful enrollment, voluntary withdrawal, or failure to be screened.

[0175] The final recruitment status data is correlated and compared with the previously calculated dropout risk probability to generate feedback data for the trial-specific risk prediction model.

[0176] Specifically, at the end of the recruitment process, each participant has a clear final recruitment status. The Risk Prediction Engine 2 systematically collects this data. This data is marked on the platform by researchers when a participant withdraws from the process or is successfully enrolled. The status mainly includes: successful enrollment, voluntary withdrawal (the participant decides not to participate), and screening failure (failure to meet all inclusion and exclusion criteria). Correlation and comparison: The engine builds a data table in the background, correlating each participant's final recruitment status data with multiple dropout risk probability values ​​that have been calculated with them historically. For example, for a participant who ultimately "voluntarily withdraws," the system records the risk probability values ​​calculated for him 24 hours and one week before withdrawal (e.g., 0.75, 0.65). The collected correlation data is used to generate feedback data needed for model optimization: this feedback data constitutes a labeled historical dataset. Here, the features (i.e., the dynamic feature vector at the time) are the input, and the final recruitment status is the true label. For example, the true label for a final "voluntary withdrawal" instance is "high risk," while the true label for a "successfully enrolled" instance is "low risk." Subsequent Applications: This batch of high-quality feedback data from the production environment has two main uses: Model Validation: It can be used to evaluate the performance of the currently deployed trial-specific risk prediction model, calculate its accuracy, recall, and other metrics, and determine whether the model remains reliable. Model Retraining: Once enough new data has been accumulated (e.g., hundreds of new feedback instances), this data can be used to incrementally train or fine-tune the existing prediction model. By learning and mining patterns in this new data, the model can adjust its internal parameters and feature weights, thereby better adapting to the behavioral patterns of subjects in the actual clinical environment and improving the accuracy of future subject risk predictions.

[0177] It should be noted that this platform adopts a layered security and compliance architecture throughout the entire process of data processing and system interaction:

[0178] Identity and Access Control:

[0179] The platform operates within the hospital's internal network environment. All access to the hospital's information systems (HIS, examination appointment system, etc.) is based on the hospital's unified patient business identifiers (such as medical record number, hospitalization number) for identity association, and does not directly use the patient's name, ID number or other sensitive personal information.

[0180] The platform implements role-based access control for research team members, ensuring that researchers can only access subject data within their authorized scope.

[0181] The principle of minimizing data acquisition:

[0182] When collecting real-time response parameters of the subjects, the parameter acquisition module 1 only collects behavioral characteristic data directly related to risk assessment (such as response delay and page dwell mode), and does not collect information directly related to personal identity, such as device identifiers and IP addresses.

[0183] For front-end interface behavior tracking, a localized processing method is adopted, that is, after the user terminal completes the behavior feature extraction, only the extracted feature values ​​are uploaded to the platform, and the original interaction records are not uploaded.

[0184] De-identification of system interactions:

[0185] When the execution engine interacts with hospital business systems (examination appointment system, pharmacy management system), the request message contains only the minimum set of information required to complete the operation, such as the patient's internal identifier, examination item code, and reserved time period.

[0186] The results returned by the business system received by the platform are also filtered, retaining only the operation status (success / failure) and necessary business parameters (such as appointment confirmation number), and do not receive the patient's complete medical records.

[0187] Privacy protection in task assignment:

[0188] When proactive communication tasks are assigned to human agents, the task order only contains the minimum necessary information for communication, such as the subject's code, contact information (after anonymization), and system-generated communication points, without exposing sensitive information such as the patient's detailed medical history.

[0189] Through the above multi-layered security and compliance design, the platform achieves intelligent scheduling throughout the entire process while ensuring the security of medical data in all stages of processing, transmission, and storage, thus meeting the stringent requirements of current regulations for the protection of medical and health data.

[0190] Example 2

[0191] Based on Example 1, this example proposes a fully intelligent recruitment method for clinical trial subjects, implemented on the platform described above, including the following steps:

[0192] Obtain multi-dimensional parameters of subjects who have passed the initial screening, including historical behavioral parameters and real-time response parameters;

[0193] Based on the aforementioned multi-dimensional parameters, the dropout risk probability of each subject throughout the entire recruitment process is calculated;

[0194] Based on the dropout risk probability, the priority weight of each subject in the recruitment task queue is calculated in real time.

[0195] Based on the aforementioned priority weights, at least one of the following scheduling actions will be dynamically executed:

[0196] Adjust the task assignment order, and prioritize assigning follow-up tasks to high-weight subjects in the task assignment queue;

[0197] For subjects whose priority weight is higher than the first preset threshold, an active communication task that needs to be performed by a human agent is automatically generated and triggered; for subjects whose priority weight is lower than the second preset threshold, they are automatically included in a standardized reminder process driven by system messages.

[0198] For subjects whose priority weight is higher than the third preset threshold, the resource time slots required to complete subsequent key enrollment examinations are reserved in advance in the hospital's examination appointment system.

[0199] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are merely preferred embodiments of this application. It should be noted that due to the limitations of written expression, while there are objectively infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this invention, and can also combine the above technical features in an appropriate manner. These improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A fully intelligent recruitment platform for clinical trial subjects, characterized in that: include: The parameter acquisition module (1) is configured to acquire multi-dimensional parameters of the subjects obtained from the initial screening. The multi-dimensional parameters include historical behavior parameters and real-time response parameters. The risk prediction engine (2) is connected to the parameter acquisition module (1) and is configured to calculate the dropout risk probability of each subject in the entire recruitment process based on the multi-dimensional parameters. The task scheduler (3), which is connected to the risk prediction engine (2), is configured to: calculate the priority weight of each subject in the recruitment task queue in real time based on the dropout risk probability; and dynamically execute at least one of the following scheduling actions according to the priority weight: adjust the task assignment order: in the task assignment queue, prioritize the assignment of follow-up tasks corresponding to subjects with high weights; allocate differentiated follow-up actions: for subjects whose priority weight is higher than the first preset threshold, automatically generate and trigger an active communication task that needs to be performed by a human agent; for subjects whose priority weight is lower than the second preset threshold, automatically include them in a standardized reminder process driven by system messages; and perform resource pre-configuration: for subjects whose priority weight is higher than the third preset threshold, generate a resource pre-allocation request for them to complete subsequent key enrollment checks; wherein, the real-time response parameters include an interaction depth index on the informed consent related materials viewing interface, which is obtained by: an interaction monitoring SDK embedded in the electronic informed consent form browser. The study anonymously collects non-content-related interactive behavior data from participants, including page browsing completeness, interaction activity, and repeated browsing behavior. After normalizing the collected behavioral data, it is input into a pre-trained shallow neural network model, which outputs an interaction depth score representing the participant's level of understanding and engagement. Additionally, a task flow model based on a directed acyclic graph (DAG) is maintained for each participant, where nodes represent specific follow-up tasks, and directed edges represent dependencies and execution order between tasks. During dynamic generation of scheduling instructions, the following analyses are performed in parallel: Dependency analysis: When a high-priority task is identified, all its predecessor tasks are checked in the DAG model to see if they have been completed. All directed edges pointing to the task node are backtracked to its predecessor nodes. If a predecessor task is incomplete or in progress, it is scheduled first. Resource competition analysis: Based on pre-configured resource information, the peak resource demand in future time periods is predicted, and tasks competing for the same resource time period are scheduled in a staggered manner.

2. The intelligent recruitment platform for the entire subject recruitment process in clinical trials according to claim 1, characterized in that: The historical behavioral parameters include at least one of the following extracted from historical interaction records provided by the subject with authorization or publicly available: reliability assessment indicators of historical appointments or commitments; Consistency assessment of long-term health management behaviors; consistency patterns of behaviors in historical participation in research or health-related activities; the real-time response parameters include at least one of the following, obtained in real time through the interaction records between the subject and the recruitment platform during this recruitment process: initial response delay time to the recruitment invitation; online preliminary assessment of questionnaire completion completeness, seriousness indicators and modification behavior data.

3. The intelligent recruitment platform for the entire subject recruitment process in clinical trials according to claim 1, characterized in that: The risk prediction engine (2) is specifically configured to: standardize the historical behavioral parameters and real-time response parameters, and combine them to generate an initial feature vector for each subject; load the corresponding trial-specific risk prediction model from a pre-set model library according to the protocol of the target clinical trial; wherein the trial-specific risk prediction model is obtained by pre-adjusting the feature weights of the basic machine learning model by analyzing the characteristics of the inclusion and exclusion criteria and the target intervention measures of the trial; dynamically adjust the weight allocation of the historical behavioral parameters and real-time response parameters in the initial feature vector based on the subject's current willingness to participate as reflected by the real-time response parameters, and generate a dynamic feature vector; wherein the stronger the current willingness to participate, the higher the weight of the real-time response parameters is allocated; input the dynamic feature vector into the loaded trial-specific risk prediction model, calculate and output the dropout risk probability.

4. The intelligent recruitment platform for the entire subject recruitment process in clinical trials according to claim 1, characterized in that: It also includes an execution engine that is communicatively connected to the task scheduler (3), the execution engine being configured to: receive the scheduling action, the scheduling action including the proactive communication task, the standardized reminder process and the resource pre-allocation request; convert the scheduling action into a standardized instruction that matches the interface of the target collaboration system; and send the standardized instruction to the corresponding target collaboration system for its stakeholders to receive and process; wherein the target collaboration system includes a coordination system for coordinating the inspection of resources and a workflow system for allocating manual tasks.

5. The intelligent recruitment platform for the entire subject recruitment process in clinical trials according to claim 4, characterized in that: The execution engine is specifically configured to: when receiving a scheduling action corresponding to the resource pre-allocation request, generate a resource coordination suggestion that conforms to the target coordination system interface specification based on the subject's priority weight, required inspection type, and expected time period; send the resource coordination suggestion to the coordination system used to coordinate inspection resources for review and processing by its relevant coordinators; and when receiving a scheduling action that triggers an active communication task, generate a task work order containing personalized communication points based on the subject's multi-dimensional parameters and current recruitment stage. The task order is pushed to the workflow system for allocating manual tasks via a message queue, and the status of the agent task pool is updated in real time.

6. The intelligent recruitment platform for the entire subject recruitment process in clinical trials according to claim 1, characterized in that: It also includes a strategy management module that is connected to the task scheduler (3) and is configured to: monitor in real time global indicators reflecting the recruitment status of the entire clinical trial, including the size and growth rate of the current pool of qualified subjects, the remaining time until the planned enrollment deadline of the project, and the real-time idle rate of key examination resources; and calculate and update the first preset threshold, the second preset threshold and the third preset threshold used by the task scheduler (3) based on the global indicators.

7. The intelligent recruitment platform for the entire subject recruitment process in clinical trials according to claim 6, characterized in that: The strategy management module is specifically configured to: lower the first preset threshold and the third preset threshold when the size of the qualified subject pool is lower than the safe level or the remaining time is less than the urgent threshold, so that more subjects can be included in the scope of high-priority follow-up and resource pre-allocation; and raise the third preset threshold when the real-time idle rate is lower than the resource shortage threshold, so that the resource pre-allocation qualification is tightened to the subjects with the highest priority.

8. The intelligent recruitment platform for the entire subject recruitment process in clinical trials according to claim 3, characterized in that: The risk prediction engine (2) is also configured to: continuously collect the final recruitment status data of the subjects, including: successful enrollment, voluntary withdrawal or screening failure; correlate and compare the final recruitment status data with the previously calculated dropout risk probability to generate feedback data of the trial-specific risk prediction model.

9. A method for intelligent recruitment of subjects throughout the entire clinical trial process, implemented based on the platform described in any one of claims 1-8, characterized in that: Includes the following steps: Obtain multi-dimensional parameters of subjects who have passed the initial screening, including historical behavioral parameters and real-time response parameters; Based on the aforementioned multi-dimensional parameters, the dropout risk probability of each subject throughout the recruitment process is calculated; based on the dropout risk probability, the priority weight of each subject in the recruitment task queue is calculated in real time; according to the priority weight, at least one of the following scheduling actions is dynamically executed: adjusting the task assignment order, prioritizing the assignment of follow-up tasks corresponding to high-weight subjects in the task assignment queue; for subjects with priority weights higher than a first preset threshold, automatically generating and triggering proactive communication tasks that need to be performed by a human agent; for subjects with priority weights lower than a second preset threshold, automatically including them in a standardized reminder process driven by system messages; for subjects with priority weights higher than a third preset threshold, pre-locking the resource time slots required for completing subsequent key enrollment examinations in the hospital's examination appointment system.

Images