Voice-command activated support tool for clinical research
The voice-command activated clinical research support tool integrates CTMS with daily healthcare provider tasks, enhancing productivity and accuracy by allowing tasks to be performed using voice commands, reducing time and errors.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- CLINICIST LLC
- Filing Date
- 2025-11-13
- Publication Date
- 2026-05-26
AI Technical Summary
Current Clinical Trial Management Systems (CTMS) do not integrate efficiently with the daily work of healthcare providers, requiring them to interrupt their tasks to access and operate software, leading to decreased productivity and quality.
A voice-command activated clinical research support tool that integrates hardware, software, and human resources, enabling healthcare providers to perform tasks using simple voice commands, including a passwordless, biometrically authenticated system for electronic document signing.
The tool significantly reduces task completion time by over 90% and improves accuracy, allowing healthcare providers to perform complex clinical research tasks efficiently and accurately using voice commands.
Smart Images

Figure 2026086381000001_ABST
Abstract
Description
Technical Field
[0001] Cross - References to Related Applications This application claims priority based on Provisional Patent Application No. 63 / 558,203 filed on February 27, 2024, and Provisional Patent Application No. 63 / 720,591 filed on November 14, 2024, the contents of which are incorporated herein by reference.
[0002] Statement Regarding Federally Sponsored Research or Development Not applicable
[0003] Reference to a "Sequence Listing", Table, or Appendix of a Computer Program Listing (submitted on a compact disc) Not applicable
[0004] The present invention relates to a Clinical Trial Management System (CTMS), and more specifically, to a computer - implemented system for a voice - command - activated assistance tool for clinical research that improves the productivity of healthcare providers.
Background Art
[0005] Description of the Prior Art (including information disclosed in accordance with 37 CFR 1.97 and 1.98) The applications of information technology (IT) and artificial intelligence (AI) have had a great impact on multiple industries. However, in modern medical settings, the introduction of new IT has led to inconsistent results. For example, despite the widespread adoption of electronic health records (EHR) and digital tracking systems (DTS), the productivity of the medical field has not improved and has likely deteriorated in many settings in recent years. Quality metrics in healthcare have also declined despite the extensive spread of IT.
[0006] This poor performance of IT in healthcare reflects several factors. One problem is information siloing, which hinders the efficient coordination of applications. Another problem is that software development and design have not enhanced many established routine tasks performed by physicians and other healthcare providers. Rather, the IT adoption in the healthcare industry typically requires users to "retrain" themselves and change long-established practices to coexist with the software. In healthcare, IT has truly become a case of "tail that wags the dog."
[0007] A Clinical Trial Management System (CTMS) is a software and database program that helps researchers perform many elements of conducting clinical trials, such as scheduling, managing research protocols, managing payments to vendors and patients, recruiting subjects, and processing regulatory documentation. These systems continuously track a complex set of subjects, staff, protocols, and business data. Currently, these systems do not integrate the aforementioned resources with the daily work of physicians and other healthcare providers. To retrieve data generated during patient interactions or to initiate a task, healthcare providers must interrupt their work, access computer and software programs, and then operate those programs. This cumbersome process leads to decreased productivity and quality. [Overview of the project]
[0008] This invention relates to a tool that improves the productivity of healthcare providers by uniquely integrating hardware, software, and human resources, enabling healthcare providers to perform certain complex clinical research tasks using simple voice commands. The passwordless, biometric, and verified voice command device can be used with a paperless signature system to electronically sign healthcare-related regulatory documents and other important documents. [Brief explanation of the drawing]
[0009] For these and other purposes described later, the present invention relates to a clinical trial management system, and more specifically, to a voice-command activated clinical research support tool employing a unique training model algorithm described in detail herein and in the appended claims with reference to the accompanying drawings. [Figure 1] This flowchart shows the operation of the computer implementation system of the present invention, from accessing voice commands to completing clinical research tasks. [Figure 2] This flowchart shows an example of how the system executes a selected algorithm for a specific task, such as reporting a serious adverse event (SAE). [Figure 3A] By eliminating errors that occur with voice commands, the training model used by the system to accurately select an algorithm suitable for the research task is shown. [Figure 3B] By eliminating errors that occur with voice commands, the training model used by the system to accurately select an algorithm suitable for the research task is shown. [Modes for carrying out the invention]
[0010] Figure 1 is a flowchart illustrating the operation of the tool. The flowchart above shows how a physician or staff member identifies tasks that require attention. These actions typically include submitting regulatory reports regarding patient interactions (such as serious adverse event reports), scheduling consultations or evaluations, providing information about clinical trials to patients or colleagues, or recording unscheduled consultations for subjects participating in a study.
[0011] Healthcare providers access the tool on their mobile devices and obtain permission to use it. The mobile devices listen for instructions regarding tasks that need to be performed.
[0012] Healthcare providers use specific voice commands created by the system to identify the task at hand. The tool has access to a pre-entered library of these tasks, built for robustness, and uniquely associates a given voice command with a specific task.
[0013] This feature deploys a "trial test." In the trial test, the system interprets numerous user voice commands (over 500 commands in the system), including different accents and background noise. The system evaluates its confidence in what the user said. Common "correct" interpretations and common "incorrect" interpretations are mapped to a single operational command in the system. Infrequent interpretation errors are discarded, and the system prompts the user to repeat the request.
[0014] Because all correct responses and frequently incorrect responses are uniquely mapped to a single command, the system is robust (i.e., recognizes most accents, etc.), but based on actual experience, it is highly confident that errors such as one command being interpreted as another will not occur.
[0015] Once the system accurately identifies a task, the tool instructs an algorithm to complete that task. Each task request deploys a specific algorithm that operates in response to a voice command. These algorithms integrate data and knowledge available to the system from one or more of the following sources: 1) the user, 2) the user's location, 3) the date and time of the request, 4) knowledge about the patient involved, if patient data is available in the system, 5) knowledge about the specific research process requested by the user, 6) knowledge about business data, if necessary to complete the task, 7) knowledge about the research project in which the user and patient are involved, 8) pre-designed forms, emails, texts, and / or other communications associated with the request, 9) details of the research protocol at the specific location in which the user and patient are involved, if necessary, 10) knowledge about regulatory authorities and sponsors overseeing the user and patient's research project, if necessary to complete the task, 11) general data available on the internet, if necessary to complete a report or task, 12) electronic signature applications, if necessary to complete the task, and 13) e-commerce applications, if necessary to complete the task.
[0016] Figure 1 shows the various assets that the tool can access for various specific algorithms related to clinical research tasks. Figure 1 also shows the human interaction for entering or enabling data inputs that are specific and unique to the task requested by the user. The tool uses a different pathway (i.e., algorithm) for each task, but to complete each task, typically, I. Research Facility-Specific Data – Information about users and other staff members, research portfolios (projects within the research facility), and patients. This system defines which users are authorized to enter this data. This system also supports EHR sources for patient data: II. Research Protocol-Specific Data - This data is entered by trained staff who are responsible for inputting details of each specific research project, or information transferred from research sponsors to the system (research protocols, vendor lists, research monitors, institutional review boards, etc.): III. The Clinical Research Process Information System collects information on FDA and other government rules and regulations, standard forms, delegation of authority, and HIPAA requirements: IV. Publicly available data - one or more of the following are required: geographic location information, time, date, generally accepted diagnostic codes, etc.
[0017] Figure 2 illustrates how the tool uses the algorithm in a specific research process. This figure details how the tool integrates multiple steps to create and complete research reports on serious adverse events (as mandated by 21 CFR 312.32). All research investigators are responsible for creating and completing these reports. The reports are submitted to the FDA, IRB, and research sponsor within 24 hours of the occurrence of the event that triggers the event, such as hospitalization, life-threatening injury, birth defect, or death.
[0018] Currently, researchers, for example, who examine patients in hospitals, lack readily available means to create or submit these reports. Typically, creating such reports requires 3 to 5 hours of manual work, involving individual communication between patients, doctors, research coordinators, and other staff to compile all the necessary data.
[0019] This invention enables a user (a physician or other medical professional) to complete a report at the point of contact with a patient (or during another medical procedure), submit it to the appropriate parties, and claim a predetermined reimbursement amount for the service. The tool described can reduce the time required for this task by more than 90% and improve the accuracy of the report.
[0020] Other common uses in which tools significantly improve productivity through data system integration include patient schedule management, messaging groups affected by research results (e.g., when research results are shared with healthcare providers, notifying all research subject patients of relevant results), recording unexpected examinations and results that occur during contact with patients outside of examinations specified by the protocol, and the like.
[0021] Another aspect of the present invention relates to a passwordless, biometrically authenticated, and proven voice command device that uses a paperless signature system compliant with 21 CFR PART 11 to electronically sign regulatory documents and other important documents for medical applications.
[0022] Figure 2 shows an example of many specific algorithms (SAE report submission) within the system. Each of the plurality of voice commands is uniquely mapped to its own algorithm, avoiding errors related to the user's speaking accent or background noise.
[0023] The system receives complex voice instructions and improves accuracy by limiting the algorithm path. Since the system can easily identify this task on behalf of the user, even if the voice recognition is not perfect, a unique and appropriate algorithm can be derived.
[0024] The novel aspect of the present invention lies in the robustness of the algorithm instructions. Most voice recognition tools make mistakes due to the influence of accents, background noise, etc. Since the voice commands of the present invention are constructed considering robustness, even if many errors occur in voice recognition, appropriate commands can be sent to the algorithm.
[0025] The actual algorithm is based on specific and detailed knowledge of how processes operate in clinical research facilities. Taking SAE reports as an example, the system retrieves data from various sources and produces the final deliverable. The algorithm includes proprietary elements specific to each process (business processes unique to each company using the system). The novelty of this invention lies in the way voice commands are routed to the algorithm.
[0026] This system enables this flexibility, ease of use, adaptability to the progress of clinical trials, and efficient compliance with regulatory requirements.
[0027] Even if there is an error in the voice command, the system will execute the correct algorithm. Each algorithm is unique. This system provides a method for routing to each algorithm while eliminating errors caused by voice / accent / background noise. The novelty lies in how voice commands are routed to the algorithms.
[0028] The following is the output report from our user experience test. The "SAE report" voice commands were tested more than 500 times with various people under various circumstances. The attached data shows all commands that the system recognized multiple times, all of which are routed to "SAE Command". This "user experience test" overcomes the barriers that this type of technology has faced until now (particularly the discrepancy between what a person says and what a computer recognizes, depending on the individual and environment). This technology improves the accuracy of key commands because the algorithm maps errors to the correct commands and does not overlap with other commands. Integrating this into a wider range of systems will enable products that can rapidly perform medical tasks that were previously impossible or impossible due to concerns about inaccuracy.
[0029] [Table 1]
[0030] The system training model is designed to address the inaccuracies commonly found in conventional speech recognition systems. This model achieves a higher level of performance through its unique training protocol. To train the model, smartphones are taken to various locations, and voice samples are collected from approximately 500 different people pronouncing the voice commands intended by the system.
[0031] Actual audio recordings (transcriptions) from a smartphone are captured and the data is analyzed (Figure 1). If the intended term is most frequently recognized in the distribution list, the system retains it and associates it with the corresponding action. For example, if "SAE report" is the top-level term, it is linked to the action of submitting an SAE report. In this scenario, all common errors (i.e., errors greater than 1, >1 error), such as "Essay Report," "SAT Report," and "Yes a E Report," are classified into the action of submitting a serious adverse event report. All uncommon errors (errors less than 1, <1) are discarded and not coded into the selected term.
[0032] Alternatively, if the intended term is not ranked highest, such as when "SAE report" is ranked third in the nomogram, the algorithm discards the term "SAE report" and selects a different term for the command. In such cases, "Serious Adverse Event Report" might be selected as the chosen term. The system then re-evaluates the nomogram with this new term "Serious Adverse Event," and if it detects this as the most frequently heard term, the system accepts it as the formal command to submit a serious adverse event report. The system then codes all common errors (i.e., occurring more than once) as "Serious Adverse Event Report" and discards all non-common errors from the system.
[0033] [Table 2]
[0034] Figures 3A and 3B both illustrate in detail how the algorithm learns to improve accuracy by recognizing and eliminating errors. As shown in Figure 3A, when a user speaks a voice command into their smartphone, the system interprets the user's voice command and records the text it hears. A nomogram is generated showing the distribution of all "heard commands".
[0035] If the intended voice command is not #1 (the first) in the nomogram, that specific voice command is removed from the voice command library and is not coded into any other command. A new specific voice command is selected. The algorithm is re-executed, and the user selects the new voice command by voice.
[0036] The new specific voice command is interpreted and transcribed, and a nomogram is generated showing the distribution of all "heard commands". In the nomogram, if the intended specific voice command is #1, all common errors (less than 1) in the nomogram are coded as "requery subject", and all common errors (greater than 1) in the nomogram are reprogrammed into specific voice commands in the voice command library.
[0037] In Figure 3B, if no errors are found in the nomogram, voice command #1 is programmed as the intended action for the system. When the user speaks a voice command, the system either recognizes the voice command, does not recognize it, or does not hear the voice command. If the voice command is not heard, the system queries the user again with the initial voice command.
[0038] If the system recognizes a voice command, the command is executed. If the system does not recognize a voice command, a general error (greater than 1) is logged, and the system either executes the command or the general error is not coded into another command in the voice command library. If an ungeneral error (less than 1) is logged, the system either queries the user again with the initial voice command or discards the command from the voice command library and maps it to a persistent error. In this case, the system queries the user again with the initial voice command.
[0039] The bottom of Figure 3B shows a sample list of possible voice commands within the voice command library.
[0040] While only a limited number of preferred embodiments of the present invention are disclosed for illustrative purposes, it is evident that many modifications and variations are possible. The present invention is intended to encompass all of these modifications and variations that fall within the scope of the invention as defined by the claims.
Claims
1. A computer implementation system for a voice command activation support tool for clinical research, which enables healthcare providers to perform specific complex clinical research tasks using simple voice commands, This involves taking smartphones to various locations and collecting voice samples of multiple individuals pronouncing intended system voice commands. To record the actual audio and analysis data from the aforementioned smartphone, Receiving voice commands, To generate a nomogram of the distribution of all "heard commands", and The voice command is stored, and when the voice command is most frequently recognized in the distribution list of the nomogram, (i) Associating a held voice command with a corresponding action, (ii) Reprogramming all common errors in the retained voice commands into specific voice commands within the system, or (iii) The step of creating an algorithm by coding all non-common errors in the retained voice commands into "target requeries", system.
2. If the retained voice command is not recognized most frequently in the distribution list of the nomogram, the intended voice command is deleted from the system, or The system according to claim 1, further comprising the step of selecting a new voice command and re-executing the algorithm if the retained voice command is not recognized most frequently in the distribution list of the nomogram.
3. The system according to claim 1, wherein a retained voice command associated with the corresponding action is recognized by the system and the task is executed.
4. The system according to claim 1, wherein the system fails to recognize a voice command due to a common error, and the system does not execute the command or encode it into another command.
5. The system according to claim 1, wherein the system fails to recognize a voice command due to an unusual error, and the system either re-queries the user's initial command or discards the voice command and re-queries the user's initial command.
6. The system according to claim 1, wherein the system fails to hear the voice command and the system queries the user for the initial voice command again.
7. A computer implementation system for training an algorithm in a voice command activation support tool for clinical research, which correlates voice commands with specific tasks, wherein the specific tasks are: The steps include taking smartphones to various locations and collecting voice samples of multiple individuals pronouncing intended system voice commands, The steps include recording actual audio and analysis data from a smartphone, Steps include receiving voice commands, The steps include generating a nomogram of the distribution of all "heard commands", The voice command is stored, and when the voice command is most frequently recognized in the distribution list of the nomogram, (i) The step of associating the held voice command with the corresponding action, (ii) The step of reprogramming all common errors in the retained voice commands into specific voice commands in the system, or (iii) The step of coding all non-common errors in the retained voice commands into a "target requery", system.
8. If the retained voice command is not recognized most frequently in the distribution list of the nomogram, the intended voice command is removed from the system, or The system according to claim 7, further comprising the step of selecting a new voice command and re-executing the algorithm if the retained voice command is not recognized most frequently in the distribution list of the nomogram.
9. The system according to claim 7, wherein a retained voice command associated with the corresponding action is recognized by the system and the task is executed.
10. The system according to claim 7, wherein the system fails to recognize a voice command due to a common error, and the system does not execute the command or encode it into another command.
11. The system according to claim 7, wherein the system fails to recognize a voice command due to an unusual error, and the system either re-queries the user's initial command or discards the voice command and re-queries the user's initial command.
12. The system according to claim 7, wherein the system fails to hear the voice command and the system queries the user again for their initial voice command.
13. If the intended voice command is not most frequently recognized in the distribution list of the nomogram, the intended voice command is removed from the system, or The system according to claim 7, further comprising the step of selecting a new voice command and re-executing the algorithm if the intended voice command is not most frequently recognized in the distribution list of the nomogram.
14. The system according to claim 7, wherein a voice command is recognized by the system and a task is executed.
15. The aforementioned algorithm is It is generated using one or more of the following: research protocol-specific data, clinical research process information, and publicly available data. The data specific to the aforementioned research protocol is entered by staff trained to input details of each particular research project, or information transfers from the research sponsor to the system (research protocol, vendor list, research monitor, institutional review board), The aforementioned clinical research process information is information collected by the system regarding knowledge of FDA and other government rules and regulations, standard forms, delegation of authority, and HIPAA requirements. The system according to claim 1, wherein the publicly available data includes geographic location information, time, date, and generally recognized diagnostic codes.
16. 1) The user, 2) The user's position, 3) Date and time of the request, 4) If the system has patient data, knowledge about the patient in question, 5) Knowledge of the specific research process requested by the user, 6) Knowledge of business data, when necessary to complete the task. 7) Knowledge of the research projects in which the user and patient are involved, 8) Pre-designed forms, emails, texts, and / or other communications associated with the request, 9) Details of the research protocol at specific locations involving the user and patient, if necessary. 10) Knowledge of regulatory authorities and sponsors that monitor the user and patient research projects, if necessary to complete the tasks described above. 11) Common data available on the internet, as needed to complete the report or task. 12) If necessary to complete the above task, an electronic signature application, 13) The system according to claim 1, including an algorithm for integrating data and knowledge available to the system from one or more e-commerce applications, if necessary to complete the task.
17. The aforementioned algorithm is generated using one or more of the following: research protocol-specific data, clinical research process information, and publicly available data. The data specific to the aforementioned research protocol is entered by staff trained to input details of each particular research project, or information transfers from the research sponsor to the system (research protocol, vendor list, research monitor, institutional review board), The aforementioned clinical research process information is information in which the system has acquired knowledge regarding FDA and other government rules and regulations, standard forms, delegation of authority, and HIPAA requirements. The system according to claim 7, wherein the publicly available data includes geographic location information, time, date, and generally recognized diagnostic codes.
18. 1) User, 2) The user's position, 3) Date and time of the request, 4) If data exists in the system, knowledge about the patient concerned, 5) Knowledge of the specific research process requested by the user, 6) Knowledge of business data, if necessary to complete the aforementioned tasks. 7) Knowledge of the research projects in which the user and patient are involved, 8) Pre-designed forms, emails, text messages, and / or other communications associated with the request, 9) Details of the research protocol at specific locations involving the user and patient, if necessary. 10) Knowledge of regulatory authorities and sponsors overseeing the user and patient research projects, if necessary to complete the tasks described above. 11) If necessary, general data available on the internet to complete the report or task. 12) If necessary to complete the above task, an electronic signature application, 13) The system according to claim 7, including an algorithm for integrating data and knowledge available to the system from one or more e-commerce applications, if necessary to complete the task.