JP2023548962A - Improved Clinician-Centered Clinical Trial Validation Systems and Methods - Google Patents

Abstract

An improvement to a method for providing a method for electronic verification of sources for source capture in a clinical trial research workflow system and a clinical trial workflow system, the method comprising: starting an EMR system; automatically selecting the correct navigation links in the EMR system and filling out the appropriate navigation forms to provide the desired information about the correct study subject record and date of visit. and capturing one or more screenshots of one or more related pages containing desired information regarding answering one or more questions about a case report form (CRF). , verifying that the one or more captured screenshots are of the correct research subject by using the one or more data points for verification.

Description

This application is based on U.S. Provisional Patent Application No. 63/122,677, entitled "IMPROVED CLINICAL TRIAL VERIFICATION SYSTEM AND METHOD," filed December 8, 2020, which is incorporated herein by reference in its entirety; and claims priority to PCT application PCT/US21/33900 entitled “CLINICIAN-CENTERED CLINICAL TRIAL VERIFICATION SYSTEM AND METHOD” filed May 24, 2021.

The present invention provides improvements to clinical trial validation systems that enable a more efficient and streamlined workflow for answering clinical trial questionnaires and entering information. This improvement includes additional electronic verification that the correct patient record is being used to create the source capture. Additionally, in addition to providing greater certainty about the origin of the source capture, the present invention also provides verification that the EMR records used to create the source capture are of the correct patient and date of visit. can do.

This idea pertains to the field of clinical research, where experiments are performed on humans to evaluate the safety and effectiveness of new medical treatments. The process of data collection for a clinical trial begins with an interaction between a doctor (researcher) and a patient (subject) that is documented in writing in the patient's medical record and is considered a legal document. A medical record consists primarily of alphanumeric characters written by a physician to describe interactions with a patient, and a medical record is considered the first point at which a record is created, which is the source document (SD). It is called. Physicians record information in the SD about, for example, patient complaints, previous conditions, medications, allergies, physical exam findings, laboratory tests, imaging studies, and plans. However, for clinical research purposes, only a subset of the information within the SD is needed. For example, a clinical trial for hypertension may only require information about blood pressure, even though the SD may also include information written by the doctor about the patient's prostate exam. , needs to be extracted as related data from the SD.

Manufacturers of medical procedures frequently enlist the help of researchers to conduct clinical studies. These manufacturers are known as sponsors. Sponsors create forms (also known as case report forms or CRFs) to be completed by investigators and/or their hospital staff. The CRF includes questions about subjects related to clinical trials. Answers to these questions must be submitted by researchers in order for sponsors to collect data about the effectiveness and safety of their medical treatments. Upon receiving the completed CRF, the sponsor then posts information from the CRF to the database. This transcription process is a potential point of human error, so sponsors often enter the data twice and later adjust for transcription errors. This process is known as dual data entry (DDE).

It has been recognized that another potential step that can introduce human error is the process by which information is transcribed from the SD to the CRF by researchers or their staff. To minimize this possibility of error, the sponsor implements a process in which the information written on the CRF is checked against the information in the SD. This process is known as Source Document Verification (SDV). In practice, this requires an employee representing the sponsor to take the CRF to the investigator's medical office to view the SD and perform the comparison. This process is very tedious and time consuming, requiring a lot of travel and cost.

Over the past two decades, the industry has adopted new technologies that allow CRFs to be presented to researchers in electronic form. An electronic CRF (or eCRF) is generally a web-based form viewed via a computer that has areas of text representing questions and then allowing researchers to submit answers. Any one of a variety of mechanisms may be present, such as open text fields, radio buttons, drop-down menus, etc. However, the process of filling out the online form representing the eCRF is still performed by the researcher with reference to the patient medical record (SD). Therefore, this remains a transcription process and is prone to human error. Therefore, even with the use of eCRF, there is still a need for the sponsor to perform quality control checks through the SDV.

However, there are advantages to using an eCRF because there is no longer a need for paper forms to be faxed between researchers and sponsors, and electronic forms are easier to read than handwritten forms. Additionally, the eCRF can be programmed such that potential errors can be flagged by the eCRF during data entry. For example, if a researcher enters a heart rate value of 800, the eCRF can be programmed with computer code to detect when the entered value is out of range. Such computer code is called an edit check. In this example, an edit check could be used to alert the researcher that a heart rate of 800 is out of range. Researchers would be able to react immediately to problematic data and make corrections. If a paper CRF was used, the error may not be noticed by the physician, the paper CRF is faxed to the sponsor, the incorrect data is entered into the database, and the edit check is not programmed days or weeks later. This same example would result in many days lost in the data cleaning process for a clinical trial, as it would be applied at the database level and flag data as being out of scope.

These flags placed on problematic data are known as queries. A report of this query must then be printed and faxed back to the researcher, who attempts to resolve the query by referencing the SD back. This process of cleaning data is time-consuming for any clinical trial, typically adding weeks, months, or even years to the drug development cycle. Although the use of eCRF may save some time in the data cleaning process, significant time and expense is still incurred in the process of programming edit checks. In summary, whether a sponsor uses a paper CRF or an eCRF, it takes weeks to months by data management staff to program edit checks for each of the CRF questions. spent. Also, the process of transcribing information from the SD to the CRF (or eCRF) remains a point of potential human error, and thus still requires sponsors to perform SDV.

One prior art process for validating clinical trial source data is described in U.S. Pat. It teaches software and hardware for clinical research systems, including creating new paper CRF data collection documents that are tracked. CRF documents are then uploaded to a central system and reviewed to accept them as clean or to request clarification. The original paper CRF completed by the researcher can be rendered in a digital manner and transmitted over the network from a clinic on the same network with the same software installed. Using Wood's invention, there is no longer a need to fax or mail forms to pharmaceutical companies or create "three-part" carbon copy forms. The physician prints a blank CRF directly from the Wood system and then obtains a paper copy to complete. Importantly, physicians still complete paper CRFs using their own handwriting. The completed form is then scanned back into digital form and imported into Wood's software. The completed forms are then sent over the network to a "central system," which becomes a database for tracking documents. The Wood patent also describes scanning separate source documents (documenting doctor-patient interactions) into the system and transmitting them to a central system in the same manner as CRFs. Similarly, any data queries created by a pharmaceutical data manager can be scanned into Wood's system and sent digitally to the physician. However, in the system of the Wood patent, source document verification must still be performed because the physician is still transcribing information from the source document to the paper CRF. There is no longer a need to travel to the doctor's office to perform source document verification because the source document is scanned into the same system as the CRF. Pharmaceutical employees can verify information on the CRF from anywhere they have a network connection and Wood's software system. Although the CRF is described as "digital" in Wood, the CRF lacks the ability to accept data directly into the CRF, rather than being filled out by a doctor or nurse and then scanned into the system. Requires the CRF to be printed on paper in order to be returned. In other words, the form is electronic, but the data capture is not.

U.S. Patent No. 10,706,958, U.S. Patent No. 10,811,122, U.S. Patent Application No. 16/919,396, and U.S. Patent Application No. 17, all of which are incorporated herein by reference in their entirety. No. 021,456 teaches a clinical trial research system and method that enables researchers to create electronic data documents (EDDs) in response to clinical trial research case report forms (CRFs). There is. Snippets are created by medical professionals as part of the EDD to respond to questions on the CRF. Instead of a physician transcribing information from a patient's medical record to an electronic CRF (eCRF), the physician uses a digital image of the source document. For example, they can log into their electronic health record (EHR) (or electronic medical record (EMR)) system and select the portion of the screen that corresponds to the information that answers each of the questions on the eCRF. You will be asked to create an image (such as a JPEG file) of the section. The clinical trial data collection workflow has medical professionals at the point of care capture screen images and then create individual snippets for each CRF question. The medical professional then reviews the completed form, signs it, and sends it to the sponsor. Once received by the pharmaceutical company, pharmaceutical data management personnel use the snippets to transcribe the information into corresponding fields in the clinical database by accessing the unmasked portions of the images contained in the EDD. The pharmaceutical company receives image information obtained directly from the doctor's official electronic medical record. Using this approach, there is usually no reason to double check or confirm answers by later reference to the source document (SD). However, many of the transcribed data points may be later edited to correct errors. In these cases, when the data changes, the medical professional must revisit and re-sign the document. This may occur multiple times, resulting in inefficiency.

Recently, the industry has created several systems that are "integrated" with several popular EMR backend data systems through APIs and SDKs published by EMR manufacturers. Although these systems can provide rapid acquisition of data from EMR software, they have been slow to be adopted. This is for several reasons, which are solved by the present invention.

One reason for the lack of adoption of existing systems is that there are a large number of EMR manufacturers, each with its own integration interface. This poses challenges of scale when deploying back-end integration systems in clinical trials. A single clinic or hospital using a less popular EMR system causes the entire study to require a hybrid process.

Another reason why existing systems have not been adopted is because EMR integration requires interaction between the EMR vendor and the hospital system to set up the integration. This often requires the deployment of on-site servers and the construction of VPN tunnels to securely extract data. Even if the integration has already been developed with a given EMR system that does not exist, it still requires vendor and site agreement and a deployment process with slight customization for each individual site. do. This is a daunting task and can be hampered by bureaucratic processes or technical hurdles at any individual site. The present invention overcomes this problem by requiring only user credentials and no vendor interaction or consent, comparable to on-boarding for a typical clinical user.

A third reason for the lack of adoption of existing systems is that EMR manufacturers and hospitals have placed less emphasis on clinical trials as a primary source of revenue. This results in a lack of partnership among major stakeholders and reduces the incentive for EMR manufacturers and hospitals to collaborate on integrations beyond the stock interface provided through their APIs or SDKs. . This has resulted in very little progress in this clinical research method over the past decade. The present invention overcomes this problem by interacting with the EMR in the same way that a user would. Anything a user can do, the invention can do. This removes limitations imposed by EMR manufacturers on the types of integration possible. It also removes the incentive structure regarding the types of integration possible.

Pharmaceutical companies tend to keep their data transfer and informatics systems proprietary because they do not want research data to easily leave their firewalls. Therefore, pharmaceutical company computer and informatics systems are not easily "plugged into" hospital systems. Therefore, securely and confidentially transmit and verify original patient data recorded in hospital systems to engage such hospital systems to participate in clinical trials for medical procedures developed by the Company. , there is a need to provide a convenient and reliable method for providing necessary clinical trial data to pharmaceutical company informatics systems that is compliant with patient privacy restrictions. Efficiently create EDDs and allocate the work required to create and validate them among the parties best positioned to do what is needed (clinical researchers and sponsors) There is more need.

US Patent No. 7,669,114 US Patent No. 10,706,958 US Patent No. 10,811,122 U.S. Patent Application No. 16/919,396 U.S. Patent Application No. 17/021,456

The present invention allows a person in the medical field, such as at least one medical professional (researcher), to perform a source capture to define a specific region of the source capture image that contains the answer, thereby improving clinical performance of a medical procedure. A computerized system and method is provided for enabling answering questions in a clinical trial questionnaire (such as an electronic case report form (eCRF)) associated with a trial. The system enables workflows where images of answers obtained through mouse clicks, eg screenshot capture snippets, are used instead of transcription of alphanumeric values.

In a further embodiment, the system assists a medical professional, such as a medical professional user, in the medical setting by allowing the medical professional to answer and organize the questions in an order that best suits a particular EMR. Allows one to reconstruct how questions are answered in the eCRF.

In a further embodiment of the invention, after at least one source capture (SC) is performed at a medical point of care and a snippet is created to initially answer an eCRF question, the system of the invention Remember where within the SC a particular question in the eCRF was answered. The system of the present invention comprises making recommendations for question-answer pairs or creating EDDs for subsequent visits selected by the medical practice where the medical professional user accepts/confirms the suggestions of the system of the present invention.

Another embodiment of the invention uses robotic process automation (RPA) to automate elements of existing source capture and source document verification (SDV) workflows. This includes automating the process of accessing the EMR, locating the correct EMR document or data, screenshots of electronic source documents, and through automated copy-and-paste (in native Windows EMR applications). Extracting EMR data in both Windows formats (for web EMR applications) or extracting individual data through reading the data directly from either the HTML Document Object Model (for web EMR applications) and compiling Personally Identifiable Information (PII) through PII pattern matching, OCR, and machine learning and sending the compiled SC and SDV data to a centralized server for storage, matching, analysis, and utilization. including doing. In a further embodiment of the invention, a medical professional creates a source capture, matches the CRF questions with portions of the source capture, and forwards this information to a non-medical point-of-care user. Non-medical users can create snippets to perform data entry and reduce the amount of work required from the clinical site. Medical professionals at the point of care do not have to review and sign the final CRF package for accuracy and review individual changes that may be made during the process.

The present invention provides the following steps: a medical practitioner selects a clinical trial study; a medical practitioner selects patients for a clinical trial study, wherein a list of patient visits is provided; the specialist selects a particular patient visit; the clinical practice specialist restructures the clinical trial questions on the clinical study form to match the order of viewable information in the active operating system; , the field professional creates a source capture of relevant information based on a particular patient visit that is viewable on the active operating system, and the field professional selects a question from the clinical study form to source associating relevant information on the capture with questions from the clinical research form, wherein the questions from the clinical research form are restructured to be answered in the order of information on the active operating system; The field expert provides the associated source capture to the clinical trial management specialist, the clinical trial management specialist creates a snippet, and the clinical trial management specialist posts the information from the snippet to the clinical trial database. A second clinical trial management professional enters the information from the snippet into a clinical trial database for validation, and a clinical trial professional reviews the completed and finalized clinical study form. A clinical trial research workflow method is provided, including steps for:

Another embodiment of the invention includes the step of a medical care professional reconstructing a clinical trial question to match the order of viewable information in an active operating system; the step of creating a source capture of the source document for the patient visit of Questions from the clinical study form are answered in the order of viewable information on the active operating system, select and associate step, and field professionals capture additional sources for the remainder of the patient visit. the system associates information from the additional source capture with the relevant clinical trial question to create question-answer pairs, and the clinical practice professional creates the system question-answer pairs using the electronic signature. A clinical trial research workflow method is provided for answering clinical trial questions, including approval or rejection steps.

Another embodiment of the invention includes the steps of a medical practice professional selecting a clinical trial study and a medical practice professional selecting patients for the clinical trial study, wherein a list of patient visits is provided. the steps of: selecting a particular patient visit by the healthcare professional; and creating one or more source captures of the particular patient visit information viewable by the healthcare professional on an active operating system; the clinical trial management professional associating the information on the one or more source captures with the questions from the clinical study form. the clinical trial management professional continues to associate the information on the one or more source captures until each of the questions on the clinical study form is answered; A snippet is created using a pair of questions, a clinical trial management professional enters information from the snippet into a clinical trial database, and a researcher reviews the entered information and provides an electronic signature. and approving information entered using the clinical trial workflow method.

Another embodiment of the invention provides a clinical trial workflow method using robotic process automation, the method including the steps of initiating an EMR system and using securely stored credentials to perform a clinical trial workflow on a user's behalf. steps to log into the EMR system, automatically select the correct navigation link in the EMR system, and fill out the appropriate navigation form to reach the EMR page with the desired information about the correct study subject record and date of visit. capturing one or more screenshots of one or more relevant pages containing answers to the one or more questions on the case report form (CRF); automatically marking one or more captured screenshots corresponding to areas containing answers to individual questions of the individual before the one or more screenshots leave the robotic process automation system; permanently redacting a field for identifying information, the robotic process automation system including the personally identifying information using optical character recognition and mapping of discrete text data read from the EMR page; identifying portions of the one or more captured screenshots and reading from the EMR page by the OCR and RPA system to determine alphanumeric data represented by the one or more captured screenshots; identifying a section of the one or more captured screenshots that includes an answer to the one or more CRF questions using the mapping of the individual text data; and using the identified section for data entry. and combining the snippet with one or more captured screenshots, one or more questions from the CRF, alphanumeric data represented within the snippet, and a complete audit trail of the action. assembling an electronic data document (EDD) in detail by associating the details, sending the EDD to a server over a secure network, and automatically selecting a logout button on the EMR system for the user. and providing a report summarizing the actions taken by the RPA system and the EDD to the user for review, commenting, and/or editing.

In further embodiments, devices and methods for adding additional security further reduce the risk of inadvertent errors using the systems of the present invention. This verification includes OCR and programming logic, secure and encrypted communication (“handshake”) between the inventive software and the EMR system, checking of active EMR application windows, interprocess communication (IPC), and Can be driven by a web-based API.

Another embodiment of the invention provides an improvement to a clinical trial research workflow system and method that provides a method for electronic verification of sources of information for source capture in a clinical trial workflow system, the method comprising: and logging into the EMR system on behalf of the user using securely remembered credentials, automatically selecting the correct navigation link in the EMR system, and filling out the appropriate navigation form. one or more EMR pages containing desired information regarding correct research subject records and date of visit; By capturing one or more screenshots of relevant pages and using one or more data points for verification, one or more captured screenshots are of the correct research subject. and a step of verifying. Validation may occur in conjunction with real-time scanning by the clinical trial system of one or more screenshot captures to detect the presence of keywords in one or more data points, and whether the one or more captured screenshots have been validated. , or unverified, and if a defined number of one or more data points are clearly identified within one or more captured screenshots by the clinical trial system, one or more captured One or more captured screenshots are labeled as verified and one or more captured screenshots are labeled as unverified if a defined number of one or more data points are not positively identified by the clinical trial system. Verification may also occur, including a secure handshake when electronic verification is verified that a connection is established and the EMR system provides the source for one or more captured screenshots. includes encrypted two-way communication, and requests the EMR system to confirm that it is displaying information about the correct research subject once the source of the information has been verified.

Further objects, features and details of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate exemplary embodiments of the invention.

A typical screenshot of a user research selection page. A typical screenshot of a landing page for a user performing source capture. Figure 2 is a typical screenshot for a medical professional user showing patient visit status. Figure 2 is a typical screenshot displaying a CRF question on a SC performer's landing page. Figure 3 is a typical screenshot of the CRF Questions tab shown by an SC performer. 2 is a typical screenshot of an SC performer displaying an application selection window. A typical screenshot showing opening a patient record in the EMR. Figure 2 is a typical screenshot displaying information edited on the SC. 1 is an exemplary screenshot showing the system of the present invention overlaid on an existing application; 2 is a typical screenshot of an SC performer displaying the SC's HUD. A typical screenshot showing a snippet generated using the Markup Palette. A typical screenshot showing a snippet about SC in form view. Figure 3 is a typical screenshot displaying a CRF progress screen for an SC performer. Figure 2 is a typical screenshot displaying a landing page for a data entry user. 2 is an exemplary screenshot displaying a data entry user's landing page for backup data entry with a confirmer. 2 is an exemplary screenshot displaying a landing page for a user reviewing a completed CRF package. 1 is a flowchart of exemplary workflow 1; 2 is a flowchart of an exemplary workflow 2 with data entry performed by a supervisor. 3 is a flowchart of an exemplary workflow 3 with data entry performed by a data administrator. 3 is a flowchart of exemplary workflow 3; 3 is a flowchart displaying an exemplary embodiment of an SC verification process for an EMR in the present invention. 3 is a diagram displaying another exemplary embodiment of an SC verification process for an EMR system according to the present invention; FIG.

The present invention allows researchers (doctors, nurses, or other designated medical professionals) to provide SCs to sponsors that correspond to answers to questions posed by the CRF or eCRF. A computerized system and method is provided. SD image segments (snippets) of the SC are then prepared in question-answer pairs to address each of the questions on the CRF or eCRF. A snippet can be a digital photograph, or the output of an imaging device, which can be a digital camera, computer screen capture software, a mobile phone, a medical scanner or imaging machine, and a portable computer. Snippets also include direct electronic or visual recordings of extracted audio and/or visual segments (but not metadata). This includes, for example, direct electronic records from telemedicine interactions. Since the eCRF questions are being answered by images that come directly from the SD, it is no longer a transcription process, thus eliminating the need to perform SDV. Also, because the SD is the ultimate resource of original data, there is virtually no need to program edit checks to assess data quality or perform other time-consuming data cleaning. The SD is considered a legal document and the information therein is considered final. Also, in modern times, most clinics and hospitals have adopted electronic medical records (EMR), and these systems already include complex error checking programming. The present invention allows sponsors to leverage error checking that already exists within the EMR system.

The idea is that the sponsor can perform one or two data entries directly based on the relevant parts of the SD, and therefore the researcher can enter the CRF using alphanumeric data. Present the process to skip steps. The present invention includes a method for a researcher to enter a CRF using an SC of all or a selected portion of the SD where relevant alphanumeric information is visible. SD images can be acquired by a digital camera for paper source documents or by a screen capture function within the software for electronic SD. As required by the Health Insurance Portability and Accountability Act (HIPAA), FDA Title 21 CFR Part 11, and other laws and regulations, protect patient privacy and bring sponsors' attention to only relevant information. To orient the image, researchers can mark the image using drawing and labeling tools. In addition, to protect patient privacy, only the alphanumeric information on the SC that the investigator has determined is relevant and compatible with the clinical trial is marked by the investigator so that the sponsor can see it. Areas that are not marked are made invisible to sponsors by editing (automatically or manually).

Since the researcher is no longer filling out a form, but rather retrieving the SC from the original SD, there is no longer any risk of transcription errors. Since the sponsor is viewing the exact digital image of the SD compartment needed for the clinical study, one or two data entries can be performed directly from the SD image, thus Eliminate or significantly reduce the need to perform SD verification directly.

The present invention takes the SC of a page (e.g., a screenshot or snapshot of a particular section on the page) and labels that SC to identify the relevant data it contains (e.g., body temperature, blood pressure, etc.). may be performed by a medical professional at the clinical site, such as a doctor or nurse, who adds any comments regarding the data or its application to clinical research to the SC. Thus, without having to enter patient information into new forms, medical professionals can identify information that is generally relevant to studies that may be conducted by various pharmaceutical companies. Similarly, a medical professional can take a photo of a paper test record that is not available on a computer (e.g., using a smartphone app), label that information with or without comments, and use the same program. and may include such test records electronically. Patient information not associated with CRF questions by medical professionals is compiled electronically, thus allowing only research-related material to be shared electronically with pharmaceutical companies. The Company will display this information in such a way that only the portion of the record selected by the medical office is shown, surrounded by a redacted portion of the SC, or alternatively, showing only the relevant data in each of the source captures, one by one. receive. This, in turn, shows the pharmaceutical company all the data it needs to see and does not show information that is irrelevant to the study and/or that poses privacy concerns. Sections of the medical record are selected and labeled by the medical office, so pharmaceutical companies can use the Clinical Research Form (CRF) to determine what information they want to see on a study-by-study basis. , the present invention provides that information. This saves pharmaceutical companies time when they have to revisit the entire medical file to verify information. And, because only information relevant to the study can be viewed by the sponsor's reviewers, information can be shared electronically without raising privacy concerns.

Additionally, if redacted portions of the medical file need to be reviewed for regulatory or fraud exclusion purposes (e.g., by an FDA auditor or senior management of a sponsoring company), a user with appropriate privileges may view the edited information in a limited but sufficient manner (eg, a viewport). Thus, the present invention hides sensitive information from public viewing, but allows authorized persons to view it, e.g., to confirm that the data being shared actually relates to a particular patient. If it is necessary to view the information, the data is retained as part of the edited SC.

The present invention provides a system with multiple user interfaces, including an interface for performing SC, an interface for performing data entry, and an interface for reviewing a completed CRF package for approval. do. The use of different interfaces provides personalization for specific roles performed by the user. For example, a user preparing an SC, such as a medical professional, can format the eCRF questions into an EMR-compliant format that allows the medical professional user to answer the eCRF questions in an easier and faster manner. Can be converted. The present invention is independent of the order in which questions appear on the CRF. This allows field users to organize the order in which they answer CRF questions to match the order in which the data appears within the electronic health record (EHR). The lack of synchronization in the prior art between the location of data on the EHR's pages and the order in which the questions appear on the CRF causes field users to experience a high volume of responses when responding to CRF questions using traditional methods. brings about a “page turner”. Using an OCR matching process, the system of the present invention determines if a keyword is not already assigned elsewhere (i.e., there is only one location in the EHR for each search term for a patient visit record). ), search the entire text of the SC looking for every possible search term configured for every CRF question. This allows the user to capture the SD's SC and match the relevant location of answers to CRF questions without any constraints on the order in which the questions are presented on the CRF.

The system of the present invention also provides the ability to deviate from traditional clinical research workflows and roles. Although the system of the present invention supports traditional roles, the system of the present invention optimizes workflow by minimizing workload at the medical site. For example, a medical professional at a medical site attaches an EMR source capture (“SC”) that answers every question on the eCRF list. This SC can be individual parts of the EMR or entire pages of the EMR record, including question-answer associations. Personal patient information on the EMR's SC is compiled, so the patient's information on the EMR is anonymous on the SC. Once the healthcare professional creates the SC and question-answer association, the healthcare professional user can close the eCRF questionnaire and non-medical personnel, such as a sponsor or third party, can create the SC and the associated questions. and prepare a snippet containing question-answer pairs for the eCRF question. To further maintain confidentiality, a sponsor may use a third party to create question-answer snippets and distribute the snippets to parties performing data entry, such as sponsors or monitors. Data entry is then performed using the prepared snippet. This optimized workflow shifts much of the work, including administrative tasks, away from the medical field. (Depending on the workflow chosen, medical sites may also prepare snippets on behalf of non-medical personnel). This is a significant departure from current industry practice, as medical professionals have always been the users tasked with submitting answers to CRF questions. However, source capture is the ultimate reference of truth, so medical interpretation of responses is no longer required, and can be performed by machines, verified by medical users, and procedurally performed by non-field users. There is only a reference to the location on the source document where it can be.

In a further embodiment, the system of the present invention enables scanning the SC provided by the medical professional in order to select and group the patient's records and the required relevant information. eCRF forms and questions can be programmed in the system software of the present invention with keywords associated with each of the questions. The system of the present invention allows users to construct a database that incorporates key search terms related to any given question on the CRF. When a user retrieves the SC of an SD, the system of the present invention uses optical characters to identify matches between the contents of the SC and the search terms configured for many questions on the CRF. Apply recognition (OCR) technology. If a match is identified, a region of the SC is presented to the user as corresponding to the search term for the particular question. A skilled medical professional user familiar with the contents of a medical record will know whether the areas identified by the OCR process in the system of the present invention accurately correlate to the associated questions also presented to the user, or whether they are inaccurate. It is possible to determine whether there is a correlation between If the correlation is accurate, the user accepts the match. If the correlation is not accurate, the user can reject the matched region via OCR. In a preferred embodiment, this process of "matching CRF questions and source captures" allows the user to confirm the location where a snippet should be created, but without having to create the snippet itself. The SC can then be sent to a non-field user (such as a CRO user or sponsor user in data management or clinical operations) to view the SCs with specific areas marked as a match and run the snippet process. (A CRO is a contract research organization used by a sponsor to perform operational aspects of a clinical trial, such as data management, site management, and monitoring.) The completed snippet is then used by non-medical point-of-care users for alphanumeric data entry into the database.

In a further embodiment, the system of the present invention creates EDDs for all subsequent visits once the medical professional provides an initial SC with question-answer associations for the first patient visit. This is done through a combination of OCR (to identify keywords from CRFs on EMR pages), pattern recognition, and artificial intelligence (AI). Since EMR pages are structured similarly from visit to visit, our system uses patterns within the SC to provide suggestions for answers to CRF questions based on the location of answers in previous submissions. recognize.

source capture interface

Source capture is typically performed by someone at the medical site, such as a doctor, nurse, or other medical professional at the medical site. In the following, a medical professional user is used to describe this interface, however, this interface can be used by any user delegated to perform source capture. Referring to FIG. 1, in an exemplary embodiment, the present invention allows a medical professional user to provide a list of all clinical trial studies available to a signed-in user based on the user's access details. Menu 110 provides a study selection screen for selecting a clinical trial study. The medical professional user may also select a configuration environment from menu 112 based on the user's project access details.

Referring to FIG. 2, in an exemplary embodiment, the present invention provides a user landing page 200 in a grid view. Other views are also available, such as a list view. Landing page 200 is specific to and adapted to the user's role. Medical professional user information 204 is provided at the top of landing page 200. Landing page 200 provides a list of all clinical trial patients 208 at the medical site (for the selected clinical trial) and a list of all patient visits 210. The patient list 208 includes the patient's unique study ID (or patient's initials) and progress status indicators (e.g., red/green/yellow color indication) made regarding completion of the CRF questionnaire. provide. Patient list 208 is sortable by patient name or color status. Visit list 210 provides a list of the selected patient's visits by name and by visit status, such as completed visits, canceled visits, overdue visits, and visits with unresolved issues. Can be filtered. A user can select a particular patient and then select a particular visit to collect information from that visit. The required information is then selected to create the SC, associate the information with the question, and be forwarded to relevant parties, such as observers, to create snippets of question-answer pairs. This is an optimized workflow where the clinical site only performs the SC and the supervisor or third party performs the snippet creation, data entry, etc. Additional workflows may also be followed by medical professionals to perform both source capture and snippet creation. For added convenience for medical professionals, a search bar 212 is provided on the landing page 200 that allows alphanumeric input to search for patients, visits, forms, and questions. New patients in the study may also be added.

Referring to FIG. 3, in an exemplary embodiment, the present invention provides patient visit status 302. Visit status 302 may include, for example, canceled visits or missed visits, along with reasons for such actions. The user can confirm the visits that have taken place and provide the associated dates 304. A calendar widget may be used to disambiguate data entry. This date becomes a date check for all SCs associated with the visit. Ad hoc, unscheduled visits can be added to the system by drawing from forms or collections of data points already set up for a particular clinical trial.

Referring to FIG. 4, an exemplary embodiment is shown having a CRF question displayed on an SC performer's landing page when a user indicates that a visit, eg, a screening visit, has occurred. The CRF form automatically populates and provides clinical trial questions on a landing page 400. The user can select the type of clinical trial question they wish to answer by tab 402 - "No Source" question or "Source Capture" question. Based on the selected tab, related questions will appear on the screen. A "No Source" question is a simple question that does not require source evidence to answer. They can be listed and answered by the user using response widgets such as yes or no, or the provided comment functionality. "Source Capture" questions require evidence of the source of information that the medical professional user needs to associate the SC with each of the listed CRF questions.

Referring to FIG. 5, in an exemplary embodiment, the present invention provides a source capture tab 502. These questions are organized into two groups - questions attached to the SC "Attached to Source Capture" 506 and questions not attached to the SC "In Progress" 504. The user must associate all or part of the SC with every question on the list. Once all questions have SCs attached, the user's job of answering clinical trial questions can be completed depending on the selected workflow. Figure 5 shows that blood pressure, temperature, pulse, respiratory rate, allergy, serum potassium, serum sodium, creatinine, EKQ QT interval, and pain scale are questions that are still in progress and do not have an attached SC. It shows. (These questions are just examples of what could be asked). Using icon 508, a user may begin the process of adding an SC.

Referring to FIG. 6, in an exemplary embodiment, the present invention provides an application selection window 600. When the user selects the source capture icon 508, an application selection window 600 opens. All software programs open in the operating system appear as icons on screen 600. The user may select and browse within the various selected applications to open relevant records for the SC. When a user selects a software program, e.g., EMR application 602, that they wish to use, the user interface of the present invention is minimized to an adaptable transparent floating widget that remains above the open active application. Ru.

Referring to FIG. 7, in an exemplary embodiment, a patient record is shown open in the EMR. Icon 700 is a transparent floating system of the present invention on an active EMR application.

Referring to FIG. 8, in an exemplary embodiment, the present invention provides automatic and manual editing of information and editing authentication using the SC's electronic signature. Patient personal information 810 is automatically compiled from SC 850. This automatic redaction of personal information takes place on the medical professional's machine, for example within a Google chrome add-on or on a server such as Amazon Wed Service. On the client side, patient personal information is not sent over the server/internet to the SC for editing processing. (Authentication of the patient associated with the SC is done by the machine and then edited before sending the SC over the network). On the server side, OCR and editing are fast and use the computational power of the server architecture to do the computationally heavy lifting. A screenshot is taken and the image is securely transferred to a server in a completely unedited but encrypted format. Once the screenshot reaches the server, all OCR and editing processing is done using ethereal memory, such as RAM, and no PII is recorded to permanent storage media. A user may select OCR and editing between client side and server side using, for example, a toggle selection. The SC 850 is placed in the system pane 800 of the present invention overlapping an open active system application 860, eg, an EMR system. Auto-editing uses optics to find matches for edit fields, such as date of birth, social security number, address, phone number, email address, hospital ID, insurance company, insurance ID, and patient ID photo section. Expression character recognition (OCR) may be used. Edited information is blocked from unauthorized users using an overlay that can be a dark block. A user may also use editing tools 816 to manually edit information that was not automatically edited. For example, patient photo 820 is manually edited using editing tool 816 by selecting information and surrounding it with a box. Manually edited regions show an "X" icon on the pane when you hover over them. After edits are made, the user uses electronic signature 840 to approve both automatic and manual edits. Manual edits need to be applied to each SC individually. A medical professional typically performs manual editing, however, for example, a supervisor may also perform manual editing of the SC.

Referring to FIG. 9, in an exemplary embodiment, the present invention provides a pane 900 that overlays an existing application 960 on the system. Pane 900 includes an SC 950 and an SC markup window 920. Markup window 920 lists the patient's study ID and visit name and date. Markup window 920 also includes a question list 930 that lists all questions for the specified visit that require an SC and are not paired with an SC response. The user can select a suggested list of questions that may have answers found within the SC 950, or a list of all research questions that require the SC. When a suggestion list is selected, OCR may be used to search for keywords within the SC 950 that may answer the CRF question. (These keywords for search purposes may be set up during study configuration). For example, question list 930 provides a list of questions that may have supporting evidence found within SC 950, such as temperature, blood pressure, medications, pulse, respiratory rate, allergies, and laboratory findings. Hovering over/highlighting a particular question on list 930 allows the corresponding section on SC 950 to contain suggested keywords for that question, e.g., blood pressure 970. Highlight. This helps users quickly find answers to CRF questions. Clicking on the arrow next to the proposed question adds the node to the pull-out drawer and places the question in the SC question heads-up display (HUD) 940. HUD 940 is a translucent drawer that overlays SC 950. HUD 940 is permanently linked to SC 950. Once a question is added to SC HUD 940, it is removed from question list 930. If there is no supporting evidence on the SC 950, the user may also remove the question from the list 930 by clicking on the "x". The user may also drag a question back from SC HUD 940 to SC question list 930.

Referring to FIG. 10, in an exemplary embodiment, the present invention provides an SC HUD 1040 and computer software tools used to annotate the SC. When question 1035 is associated with SC 1050 and added to SC HUD 1040, question 1035 can only occur once, so it is removed from list 1030 and SC markup palette 1080 appears. Markup palette 1080 includes tools related to the functionality available to the user's role. (For example, the data entry interface may also include markup tools for snippet creation; user roles are established in the software's management module). Markup palette 1080 includes a snippet tool 1082, an editing tool 1084, a multi-selection tool 1086, and a zoom tool 1088. Markup palette 1080 may be a floating rectangle graphic that can be moved and restructured. Editing tools 1084, as discussed above, allow the user to manually select the information to be edited. The multi-selection tool 1086 allows the user to select items that are not vertically or horizontally aligned by drawing a markup box around the desired information and then drawing another box from the edge of the previously drawn markup. Allows selection of multiple pieces of information on the SC. Each subsequent region created using the multi-selection tool 1086 is attached to the subsequent region's previous selection using a connecting line. Zoom tool 1088 allows the user to zoom in or out of SC image 1050 only. Snippet tool 1082 allows a user to create a snippet by drawing a markup rectangle 1083 around the desired information for the snippet. It allows the user to define which sections of the screen capture represent evidence of answers to particular questions on the clinical trial questionnaire. The result is one or more subsections of a larger screen capture, each representing a particular answer to the clinical trial question. Once markup rectangle 1083 is complete, labeling tool 1081 provides a drop-down list of all questions in question list 1030. The user may select a relevant question with an associated markup toolbox 1083. This will cause the markup rectangle to stay within a location with a green border, and the status indicator node will turn green, indicating to the user (or other Viewers). These smaller screen capture sections with associated answers are snippets. (Depending on the selected workflow, snippet creation may be performed by a non-medical point-of-care user, such as a supervisor, instead of a point-of-care user as discussed above). The snippet includes color-coded boxes with editing options and a comment box to notify the sponsor of any additional information. This snippet creation process can be repeated until all of the information on the SC that is relevant supporting evidence to answer the CRF question is paired with the relevant question. The created snippet may later be edited by the user. However, once a snippet is approved by a sponsor, it is locked and can no longer be edited. A lock symbol may be used to notify the medical professional user (or other snippet creator) that the snippet can no longer be edited.

Referring to FIG. 11, in an exemplary embodiment, the present invention provides a snippet 1155 created using a markup palette 1180. The process repeats for each new SC page. A status symbol is provided to notify the medical professional user when questions are answered for each patient visit. Status symbols are context-dependent depending on the user's role. If their role is to take source captures and assign CRF questions to their SCs, the status marker will display green when their SC tasks are complete. If a user is assigned a role that requires source capture markup to create a snippet, then their status symbol will not be the same as any question until they create a snippet-question pair for a question. Also displayed in red. For users configured for both source capture and snippet creation, the status symbol remains red until an SC is created and associated with a CRF question, and then each CRF question has a snippet-question pair. .

Referring to FIG. 12, in the exemplary embodiment, snippet 1255 on SC 1250 is shown within a form view. The form view shows only the snippet 1255 created from the SC 1250 and paired with the question. Other information that was on the SC but was not paired with the question is not shown. Native view is another viewing option.

Referring to FIG. 13, in the exemplary embodiment, a progress screen is provided when the user has a completed SC or when the user chooses to exit the SC process. Questions listed as "In Progress" 1304 still require an SC associated with the question. (For users who also have the snippet/markup capability assigned to their user role, a similar progress screen is provided for CRF questions that have snippet pairs or that still require snippet associations). The user may provide notes for ongoing unanswered questions, such as data unavailable, source unavailable, set reminder, or open query. The questions under "Attached to Source Capture" 1306 are answered using SC. (Snippets are created from the SCs attached to each of the questions). The system notifies the user if there are any unresolved queries associated with answers by placing an alert icon 1308 next to the question. An asterisk 1310 next to the question indicates the existence of an audit trail. Audit trail provides a history of all actions taken, including responses provided, data entered, data changes, SC images marked up, detailed date/time stamps, reasons for changes, and actions taken Provided with users who have done so. Once a snippet is accepted by a non-medical field official, such as a supervisor or data administrator, the question is displayed in italics, e.g., "Pulse" in Figure 13, and locked from further editing for the medical professional user. do. At the bottom of the screen, all trays of the SC 1350 used to answer the listed CRF questions are available to the medical professional user. Hovering over the SC highlights the associated questions answered from the highlighted SC page.

data input interface

Data entry can be performed by any party. This includes medical or non-medical personnel such as nurses, supervisors, data entry managers, third parties, or doctors. Sponsors may delegate clinical trial management professionals to perform data entry. Similar to the source capture interface, users of the data entry interface log into the system of the present invention and select the research and configuration environment they wish to work in.

Referring to FIG. 14, in an exemplary embodiment, the present invention provides a landing page 1400 to a data entry user. The screens are specific to the data entry user's role and the selected study and environment. A data entry user may receive an SC with question-answer pair snippets from a clinical point user. Snippets are used to provide information for data entry. However, if the data entry user is also creating a snippet in addition to data entry, the data entry user receives an SC with questions associated with the SC created by the SC user. Data entry users use this information for snippet creation and data entry. If the user's role is to create snippets, a markup palette, as discussed above, including a snippet creation tool, is available to the data entry user. If the same data entry user is creating both the snippet and the data entry, they can create the snippet and enter the data at the same time. The present invention allows data entry users to organize snippets or EDDs based on the medical practice they are responsible for. Users can select which data points they want to see based on the data entry stage, or select All to see all of the currently outstanding items. The site column 1420 provides a list of sites for users and data entry specific team members. When the data entry user selects a site, data points column 1430 opens a list of data points. These data points may be filtered using filter presets 1410 that filter data points based on the stage of data entry, such as initial entry, backup entry, validation, or flagging. When a data point is selected from data point column 1420, details of the data point are displayed in data processing details panel 1440. Panel 1440 may include a data processing page header 1450, a CRF question 1455, a snippet box 1460, a data entry widget 1470, and automatic OCR suggestions 1465. Data processing page header 1450 provides information about the data points. This information may include subject ID, site name, site ID, CRF name, nature of the request, eg, backup input request, and time of last processing step. Automatic OCR suggestions 1465 provides data entry suggestions based on associated snippets. As the first data entry user, the data entry user may need to accept or reject the snippet if another observer (non-medical site personnel) has not already done so. The data entry user accepts the SD snippet if the snippet is supporting evidence about the answer to the question and is representative of the answer to the question. The data entry user rejects the SD snippet if it is not supporting evidence of the answer to the question and is not representative of the answer to the question. (If the snippet is rejected, the data points are processed for query placement). The data entry user enters information from the accepted snippet box 1460 into the data entry widget 1470. Once the data entry is complete, the user submits the information and the system of the present invention checks to confirm that the information has been entered, sends the information to an audit trail, and changes the data to read-only text. . Data entry information may still be edited at this point. If no data is found, the system will provide an error unless the field indicates that no data exists for this data point. This may be set up when the system is configured.

Referring to FIG. 15, in an exemplary embodiment, the present invention provides a data entry landing page for backup data entry using a verifier. A second data entry user, a verifier, may be added for quality control. When a data entry user enters information and the status for the data entry user is completed, the status indicator for a second data entry user, e.g., a quality control ("QC") user, is set to incomplete. Ru. A second data entry user may provide backup input or verification. The data points are sent to a data point column on a landing page for a second data entry user selected to perform this function. When entering data as a backup corroborator, the system of the present invention determines whether the data entered by the first data entry user is the same as the data entered by the second data entry user, i.e. the QC user. Automatically evaluate whether If the entered data are not the same, the input user is notified that a match was not achieved and additional corroborators may be added. If the input data are the same, a match is achieved 1575. Data entry users may submit information to a database or request verification. Once the input is sent to the database, the audit trail is updated, the status indicator on the data point is set to complete, and the data point is removed from the data point list 1530. The system saves a data entry history, including a list of all previous data entries with username and data entered. This also applies to other data entry stages such as initial entry, validation, and flagged data points.

Authorization interface

Similar to the source capture interface, researchers log into the system of the present invention and select the research and configuration environment they wish to work on. This user interface is the primary tool for reviewing and electronically signing the fully finalized version of a completed CRF page and maintaining a record of the fully finalized version of a completed CRF page. It has a function and is for a specific role. This user is ultimately responsible for the performance of the clinical trial in the hospital or clinic. This is generally done by researchers or doctors, experts in medical settings.

In the workflow currently used in the industry, researchers revisit and sign the data on the CRF document multiple times when there are edits to the originally submitted response. In the present invention, only completed and finalized CRF pages are presented to researchers for review and signature. Using the disclosed preferred inventive workflow, snippet creation is performed by a user downstream in a medical setting. Therefore, as a next step after the clinical user provides the SC, the data is thoroughly cleaned and finally entered into the database. Once the data has been entered into the final database, the researcher can review and approve the data after any steps of data cleaning have been resolved. This is a significant departure from current practice and makes the system and method of the present invention enable such a workflow.

Referring to FIG. 16, in an exemplary embodiment, the present invention provides a researcher landing page 1600. Landing page 1600 includes a patient column 1620, a form column 1630, and a form details pane 1650. The researcher landing page 1600 differs from the source capture interface landing page in that the researcher page lists completed packages for review and review/approval by the researcher. These packages exist at the end of the process, for example after data entry and other cleaning queries have occurred. The system of the present invention provides an authorization user when the data associated with the package has been reviewed by the researcher and is ready to be electronically signed using the ready-to-sign icon 1655 next to the package. Notice. Icon 1655 can be displayed at one of three package levels (e.g., form level with all associated questions, visit level with all associated forms, or patient level with all associated visits) or It can appear in everything. Icon 1655 indicates that the data is complete with an associated SC and has no outstanding queries sent to the database. Patient column 1620 includes site names that, when selected, provide a list or archive folder of patients. All of the information may be sorted alphabetically. A list of visits for that patient may be shown or hidden from the researcher next to the patient's name. When a patient visit is selected, the form associated with the selected visit is displayed in form column 1630. The selected form is then displayed in a form details pane 1650, which may include a header 1651, a review icon 1652, a question and answer pair 1653, and an electronic signature section 1654. Form header 1561 may include, for example, a patient study ID, date of visit, and form name. A re-examination icon 1652 allows the researcher to view the original SC to verify the source of the snippet's question-answer pair. The SC may be viewed alone or in a split screen that allows the user to view both the SC and form at the same time. Researchers may also view the SC in native or form view. Question-answer pair snippet 1653 provides, for example, the full text of the question written on the CRF and the answer submitted to the database by the data entry user. Clicking on icon 1655 opens electronic signature field 1654 at the appropriate package level in form details pane 1650. Electronic signature section 1654 includes affidavit text indicating that the electronic signature certifies that the researcher has reviewed the data and SC and certifies that the data is correct. When the e-signature button is clicked, the e-signature is applied to the package, the form details pane is closed, and the signed content is moved to the archive folder 1660 in the patient column 1620. It is a regulatory requirement for physicians to retain clinical trial records for themselves for 15 years. At any time, physicians can download complete records for all of their patients (eg, in pdf or plain text) by accessing archive 1660.

robotic process automation

Embodiments of the invention use robotic process automation (RPA) to automate elements of existing source capture and source document verification (SDV) workflows. This includes automating the process of accessing the EMR, locating the correct EMR document or data, screenshots of electronic source documents, and through automated copy-and-paste (in native Windows EMR applications). Extracting EMR data in both Windows formats (for Web EMR applications) or extracting individual data through reading the data directly from either the HTML Document Object Model (for Web EMR applications) and compiling Personally Identifiable Information (PII) through PII pattern matching, OCR, and machine learning, and transmitting the compiled SC and SDV data to a centralized server for storage, matching, analysis, and utilization. Including things.

For each electronic medical record system used at clinical sites participating in clinical trials, the RPA system of the present invention accesses patient records within these EMR systems for extraction, verifies the patient's identity, and Developed by mapping and automating the user interactions required to find relevant clinical trial data. The adapted RPA solution is then deployed to automatically extract the SC and SDV data required for a given clinical trial, creating an automated RPA solution for a given study subject and data field. Coordinated through interaction with a centralized web service (API) that assigns data extraction tasks. Based on the secure web service task assignment, the automated RPA system accesses the EMR records and extracts the data assigned through the task. (RPA systems can operate remotely or at the client site, depending on network configuration, data, and legal restrictions). RPA web service communications are protected by end-to-end TLS encryption, which is securely established over an insecure channel using industry standards such as TLS, Diffie-Hellman key exchange, and AES encryption. The RPA system caches the extracted data locally in a secure encrypted container using 256-bit+AES encryption for all data at rest. The RPA system maintains appropriate credentials for the EMR system that the EMR system interacts with, provided by the clinical sites participating in the clinical trial, and stored securely using 256-bit + AES encryption. do. The editing process can occur on the client side or on the server side. The client-side editing process ensures that all PII extracted from the EMR is stripped from the SDV and SC data before sending to the web service, ensuring that the web service never processes the PII. . PII is never persisted into long-term storage on the RPA system and is only maintained in temporary memory until editing is complete.

After submission to the web service, the RPA-extracted SC and SDV data is verified by a human reviewer to ensure that no PII is present and that the data is accurate. Patient identity is determined by OCR checks on unedited SDV screenshots, checks against individual EMR data extracted by RPA, and user navigation processes taken by the RPA system (through automation) to access the data. Confirmed through confirmation of procedures for accessing data. These checks ensure that the edited data without PII is assigned to the correct study subject. If a subject cannot be found by RPA, or if these checks fail, a human who can intervene to address the problem, find the correct data, and address any errors in the RPA process is required. An error is raised to the operator.

For example, a clinical nurse or research coordinator may log into the system of the present invention and select a clinical trial and a particular research subject within that trial. They may also be able to drill down and investigate specific clinical trial patient visits. When they do so, they are presented with a series of forms that need to be completed for the selected visit and a button to "automatically complete selected forms." Selecting the automation button initiates the RPA process. The RPA process recognizes relevant EMR pages based on the nurse's previous selections for study subjects, desired visit dates, and forms. Thereafter, the RPA of the present invention may, for example, automatically proceed with the following steps:

Open the EMR software if it is not already open.

Log into the EMR system on behalf of the nurse/user (if they are not already logged in) using securely stored credentials.

Automatically "click" on the correct navigation link in the EMR system and fill out the appropriate navigation form (eg, patient search form) to reach the desired information about the correct study subject record and visit date.

Capture a screenshot of the relevant page containing the answer to the question on the CRF.

Areas containing answers to individual questions on a CRF on a jpeg or other image file of a screenshot to create a snippet (a cropped portion of an EMR page screenshot that represents an answer to a specific CRF question) Automatically "draws" corresponding markings.

Permanently edit the region with PII using OCR. Either client-side OCR or server-side OCR may be used, and a configuration toggle may be provided for the user to select the preferred method. By using OCR and mapping of discrete text data read from the EMR page by the RPA system to identify areas of the screenshot that contain PII, client-side editing and screenshot capture can be performed by the RPA system. Executed before leaving. The advantage of client-side processing is that there is zero transfer of PII since any sensitive data is immediately edited at the time of source capture. On the server side, the screenshot is sent in an encrypted manner to the server where OCR is applied and editing is performed before the edited screenshot is sent back to the client. Editing can be done, for example, within a Google Chrome add-on to the user's computer. On servers, such as Amazon Wed Services (AWS), OCR and editing use only ethereal memory (RAM), so there is no permanent storage medium for PII. Server-side processing may be the faster of the two options, however, if a country's data privacy regulations prohibit the transfer of PII from local residents to servers outside its borders, client-side Edit may be the only option to perform editing. In an effort to improve efficiency and speed, field users may collect numerous screenshots in a session and then perform other activities within the system while OCR and editing processes proceed in the background. A queuing system may be provided that allows for continued queuing. Eventually, the screenshot completes its processing and the user is notified when the screenshot is ready for further interaction.

To provide suggestions for data entry, OCR and mapping of the individual text data read from the EMR page by the RPA system are used to determine the alphanumeric data represented by the image and answer the CRF questions. Identify the region of the image that contains the answer.

Snippets can be combined and associated with screenshots of EMR pages, questions from the CRF, the underlying alphanumeric data represented within the snippet, and a full audit trail of actions (date/time/user) to create an electronic data document. Assemble (EDD) down to the smallest detail.

Send the EDD (with edited PII) to the server over a secure network.

Other processes previously described are initiated to allow for human review of the EDD information, as well as final data entry and/or quality checking.

Automatically “click” the logout button on the EMR system for the nurse/user to create a report summarizing the actions taken and the resulting EDD for review, commenting, and editing. provided to the teacher/user.

Exemplary workflow 1 shown in FIG. 17

Step 1 - Nurse logs into EMR and navigates to patient visit information. The nurse then opens the system of the present invention presenting a list of CRF questions requiring responses. The nurse first performs an SC 170 of any page in the EMR that contains information related to the clinical exam question. SC images can be organized into hierarchies, for example, by study subject's visit date. The nurse then begins the process of markup and editing 172 as desired, such as the patient's name. Any questions that do not require source documents are entered as direct input, whereas questions that require source document evidence only require mouse-driven source markup. During the process of marking up source document type questions, the system automatically regroups the questions according to the question's markup on a particular SC page. (Nurses may also regroup questions manually through a dedicated UI).

During source markup 172, the system intelligently reorganizes the CRF questions to match the evidence present on any given source capture. If a given source capture contains only 4 out of 7 answers on a CRF page with 7 questions, the system recreates the page in the CRF to reflect only the 4 answerable questions. The remaining three questions are then moved to a new page that the system automatically labels (ie, the page name "Vital Signs" becomes "Vital Signs 2", etc.). Since the screen area captured within the EMR system remains approximately the same from visit to visit, the system remembers the grouping for future instances. When all questions are completed, the source markup process ends and the nurse's work is complete.

Step 2 - Completion of the task by the nurse results in a notification for the researcher (doctor) to log into the system. The doctor can see the markup, edits, and data entry performed by the nurse and can edit any. Finally, when the doctor is satisfied, the system allows the doctor to provide an electronic signature 174. The researcher's work is complete.

Step 3 - Sign-off by the researcher provides notification to the supervisor that the package of visit data is ready for them. A monitor logs into the system and opens the SC, but can only see submitted responses to non-source document questions and questions with corresponding snippets. The observer can use the "periscope" view of the system to see the context surrounding any snippet, but cannot see the edited section of the SC. The monitor then systematically accepts 176 or rejects each of the responses. If the response is rejected, the system displays a dialog to allow the observer to place a query 178 on the response in the form of free text and/or to select from a selection of categories. open. Once all responses from the field have been addressed, the observer's work is complete. Data accepted by the supervisor is considered "locked" and should be designated as such in the user interface and appear visibly. The field cannot change the locked data unless the observer manually unlocks the locked data by rejecting the data points and placing a query.

Step 4 - Responses from any rejected supervisors result in a notification for the appropriate nurse to view the data points of the query. The nurse then logs into the system to see a list of "unresolved queries" with direct links to the relevant SC pages. The nurse can use dialog boxes within the system to adjust markup and/or respond to the supervisor using free text. The nurse's query response is then requeued for the supervisor to review and accept (resolved query) or reject again (requery) and repeat step 3.

Step 5 - Any accepted response from the supervisor results in a notification for data management personnel to perform data entry (DE) 179 of responses to all questions requiring source document evidence. The system systematically examines each of the responses and provides an interface for transcribing the responses. In some cases, a dual data entry workflow can be deployed where data is entered twice (by the same or different users) and the system flags any discrepancies. The system also allows the data administrator to encode the data at this point by allowing the data administrator to select from a menu of predetermined choices. Encoding functionality can be performed by the same user doing the data entry, or by another user specifically designated for this purpose, using a workbench and a queue of data points ready for encoding. It can be executed by the user.

Step 6 - The system is used to output data in the form of a CSV file with several parameters that allow the user to map fields to client specifications for purposes of labeling, integration, etc. be able to.

Exemplary workflow 2 shown in FIGS. 18 and 19

Same as Workflow 1 above, except that the observer can perform source markup and subsequent data entry. In detail, the field performs SC and editing 180, 190. However, while the field may not be performing source markup, they may still regroup the questions so that any given SC is associated with at least one question from the CRF. Can be done. SCs are digitally associated with specified groupings of questions, which are then sent to supervisors as individual packages. Observers are grouped by nurses and provided with an interface that allows them to perform source markup 182, 192 according to questions attached to the SC. Note that this method largely removes any need for queries (although the functionality is still present). Although it is conceivable that the observer might ask questions about the groupings associated with the SC by the nurse, there are cases where the observer asks themselves about the source markup they have just performed. would be rare. Finally, in this workflow, the supervisor may be able to perform data entry 189 immediately or pass the process to a data manager 199 as described in example workflow 1 above. . The main difference between Workflow 1 and Workflow 2 is that the physician's signature 184, 194 in Workflow 2 is done after the supervisor has completed all their work for the visit and not before. It is.

Exemplary workflow 3

It is the same as Workflow 2 except that the supervisor can execute SC202. In particular, the nurse only needs to respond to questions 201 that do not require source document evidence. This then results in a notification for the observer to log into the EMR to take a screenshot and run the markup 200. This method assumes that supervisors have their own access to the hospital EMR system. The supervisor then performs data entry 209 and the physician provides an electronic signature 204.

Image snippet safety improvements

The present invention provides an improvement over the embodiments presented above that adds additional security and further reduces the risk of inadvertent errors by verifying the source of the SC. This verification includes OCR and programming logic, secure and encrypted communication (“handshake”) between the invention software and the EMR system, checking of active EMR application windows, interprocess communication (IPC), and /or may be driven by a web-based API. The improvements to the system of the present invention verify that the SC is legitimate by identifying several key pieces of data that reside on the SC. This information may include the patient's name (first and last name), the patient's date of birth, and/or the date of the patient's visit to the hospital or clinic.

The use of screen OCR technology enables real-time scanning of a user's screen to detect the presence of keywords related to the current set of CRF questions and snippets. Using OCR determines or ensures that the name of the patient for whom the snippet is being created is on the user's screen at the time of the query. For example, a snippet session begins and a screen reader is activated to search for keywords on the user's screen. Monitoring continues until the information is found, otherwise the session is considered "unverified."

Referring to FIG. 21, an embodiment of a verification process using OCR is shown. Each of the above data points is provided to the system of the present invention in a different manner. The patient's name 2108 is provided to the system at the time of screenshot source capture 2120. The patient's name is considered PII and is therefore only processed in temporary memory on the server side and never stored on a permanent medium. On the client/browser side, the patient's name 2108 (client cache) is cleared 2135 the moment the user logs out of the session. This can be intentional or by automatic logout for inactivity based on some time threshold. The client cache may also be cleared the moment the web browser software (such as Google Chrome) is closed. Given this architecture, the system never stores the patient's name on any persistent media, either on the server side or on the client side. The patient's date of birth 2100 is provided by the caregiver staff upon enrollment in the clinical trial 2110 and is available from the system of the present invention. The patient's date of birth 2100 is obtained separately and is not PII. The patient's visit date 2105 to the hospital or clinic is recorded in the EMR and provided to the system of the present invention by the caregiver staff for each visit. Visit date 2105 is also not PII.

Once the SC process 2120 starts/occurs, verification is driven by the OCR 2130. The verification 2140 is based on what the system of the present invention can find, such as the patient's date of birth 2100, the patient's visit 2105, and/or the patient's name 2108. The SC is rated as "verified" 2142 or "unverified" 2144 and marked visually with a different icon so that a user, such as a supervisor user, can see it. The SC is designated as "verified" 2142 if all three data points 2100.2105, 2108 are positively identified by the system. The SC is designated as "unverified" 2144 if one or more data points 2100.2105, 2108 are not identified on the system. The degree of rigor in the validation evaluation 2140 is such that in some cases, two out of three data points, or some combination of data points (such as patient name 2108 and date of birth 2100) may be changed as a configuration setting such that it may be deemed sufficient to be designated as ``Verified'' 2142.

If an SC is designated as "unverified" 2144, it means that a user, such as an observer user, can view a list of all "unverified" SCs organized by the researcher site and save the list to a spreadsheet or Marked in the system so that it can be exported to the database and printed on paper with unverified SCs. A user, such as a supervisor user, can manually re-examine the SC2146 in the system of the present invention to see that the correct SC has been captured, and the "unverified" source capture is changed to "acceptable" (verified). The original source media may be accessed to manually verify 2150 whether it is 2152 or "rejected" (unverified) 2154. This allows the user to adjust the "unverified" SC list for quality assurance measures. A supervisor manually re-inspects 2150 and double-checks by viewing the original EMR to ensure that any remaining "unverified" SCs 2154 marked as "rejected" 2154 are of the source image 2160. Any snippets resulting from SC2154s that are flagged for recapture and are "rejected" will be separated from the CRF query and sent back to the researcher site to start over.

Another verification embodiment is that there is a secure, encrypted communication (a "handshake") between the inventive software that creates the SC and the computer window containing content based on the EMR system from which the SC originated. , including devices and processes. This "handshake" between the two software components is preferably a two-way communication whereby electronic verification occurs each time an SC is created. This electronic verification may be added as a component to the EDD described in the embodiments above, recorded such that a human readable log may be generated.

The two-way communication described above verifies that the window being actively used ("focused") at the time of SC creation is, in fact, the EMR system. In addition, once the two-way communication is created in a secure and encrypted manner, the EMR preferably indicates that the window that is "in focus" has medical information about the correct patient and/or correct visit to the clinic. Data may be requested to be sent from an application programming interface (“API”) for the EMR system that verifies the record.

Referring to FIG. 22, an embodiment of this improvement to the systems and methods described above is shown. Verifying the source of a snippet at the time of capture is a two-step process. The first step 2200, "handshake", occurs when the connection is established and verified to be the EMR application/window providing the source of the snippet or SC. Once the information source is verified, a second step 2210 provides a means for the EMR system to confirm that it is displaying information about a particular patient and/or a particular visit for that patient. do. Screen optical recognition (OCR), checking of active EMR application windows, inter-process communication (IPC), and web-based APIs ensure that the current EMR record from which the snippet is created matches the expected subject EMR record. can be used to verify that

Another verification embodiment checks for active EMR application windows on a user's operating system to generate information about whether a known EMR software application currently has an active window on the display. Analyze open windows. If the window has a title or metadata that matches the keywords and provides further insight into the window's current contents, the SC is verified. Information such as the patient's name or ID and date of birth may be used. If the information is not available or does not match the queried keywords, the snippet will not be validated. For example, when an SC session begins, the software of the present invention detects an operating system window. Available metadata about the keyword is queried. The presence or absence of expected information determines verification.

Another verification embodiment is that the processes involved are all utilizing a given set of protocols, i.e. they all expect to accept messages and respond as appropriate. If so, provide and use interprocess communication (IPC), which allows different processes (applications) to share or exchange information at the same time. A secure exchange (or handshake) of cryptographic keys in which both the software of the present invention and the computer window containing content from the EMR system identify themselves and the software and computer window verify the provided key. Subsequently, the encrypted information can be transferred through the use of either pipes (one-way data channels) or sockets (endpoints for sending or receiving data). Once authentication is established, messages can be transferred between the two software components to determine whether the EMR is displaying information related to a particular subject. IPC requires the cooperation of EMR applications that implement the software protocols defined by the system of the present invention. These protocols do not require patient information, but only that the information provided about a particular subject, e.g. name or ID, is confirmed to be the information the application window is displaying at the time of the query. . For example, when an SC session is initiated, the system of the present invention requests connection with the EMR software via the operating system. Once the connection is established, the EMR software is asked to confirm whether information about a particular patient is currently being displayed. Response or lack of response determines validation.

Another verification embodiment is for users, such as researcher users, to request information directly from the EMR's web service on their behalf, providing access to as well as information about what is being displayed. A web-based API is used that allows the system of the invention to also generate information that verifies the users who are present. Using standard secure internet protocols, such as OAuth, the system of the present invention is granted a token that is sent to the EMR API with a request for information while the SC is being created. The EMR system verifies the currently displayed patient record. This confirmation may also include more detailed non-sensitive patient information, such as the type of record being viewed by the user, giving greater accuracy to the SC data. This type of authorization token persists until it is revoked. Thus, the authorization token can be reused with each new SC event without repeating the authorization step. For example, the system of the present invention authorizes the EMR web service and the token is stored for later use. When an SC session begins, an API query is made to the EMR software web service to request confirmation that information about a particular patient is currently being displayed. The response determines the validation of the data source.

This improvement can provide additional functionality that adds further value to the systems and methods of the present invention. Improvements may allow validation between the system of the present invention and the SC/EMR to ensure that the correct patient information is being used.

General

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In an exemplary embodiment, the invention is implemented in software including, but not limited to, firmware, resident software, and microcode. Any conventional EMR system can be used as a source of information for the SC, such as Cerner, Epic Systems, and Allscripts. Preferably, the systems and methods of the present invention are implemented in a client/server network connected via the Internet.

The systems and methods of the present invention preferably also employ data security, encryption, and data capture and transfer protocols that enhance patient privacy and security and add desirable authentication and verification features. Preferably, all data is transferred over an SSL connection (also known as HTTPS). Preferably, the systems and methods of the present invention use data encryption (public/private key pair) to protect patient medical records represented within SD media, and the data encryption data and media, both while they are stored and while they are in transit, so that only the intended recipients have access to/view the data and media. We guarantee that you can. Preferably, all users must be authenticated on the system by logging in using their private credentials. Preferably, during each interaction with the server, the server verifies the authenticity of the request for interaction by means of an authentication token issued by the server. Preferably, the system requires users to change their passwords periodically. Preferably, users only have access rights to functionality assigned to them by the system administrator. Preferably, information such as patient or subject ID, data capture date, and other necessary identifying information is not only included within the metadata, but also embedded in the SC and SD images themselves to make them eligible for EDD. accessible to all users and viewers.

In another preferred embodiment, the media or data is stored on any local machine or device by the machine or device when it is created or by the observer/sponsor or researcher when viewing it. Not done. Rather, data is captured directly from screen output by our software and processed by the native operating system, which may write that data to disk, even if only as a temporarily cached file. Not done. Any additional image processing that may be required, such as file compression for storage, is handled by the local machine or a server remote from the device. Preferably, computer systems and programs used in embodiments of the present invention do not save EDDs or other files created incidentally to operations of the present invention as files that can be recalled at a later point in time. . The SC can display information from any EMR software running on the same machine as the software of the invention so that the EMR software displays the EMR software's information on the same screen that is accessible by the software implementing the invention. can be obtained. Additional digital media imported by the present invention from any external source, such as a photo of a paper document or a medical scan, is handled in the same manner as the SC once loaded.

Additionally, the present invention provides program code available from a computer usable or computer readable medium for use by or associated with a computer system or any instruction execution system. , may take the form of one or more computer program products. The computer program product includes instructions for implementing the method of the invention. A computer-usable or computer-readable medium contains, stores, communicates, or propagates a program for use by or in association with an instruction-execution system, apparatus, or device; or can be any device that can be transferred. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of computer readable media include semiconductor or solid state memory, magnetic tape, removable floppy disks, random access memory (RAM), read only memory (ROM), hard magnetic disks, and optical disks. Current examples of optical disks include Compact Disc-Read Only Memory (CD-ROM), Compact Disc-Read/Write (CD-R/W), and DVD.

A computer system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. Memory elements include local memory utilized during the actual execution of program code, mass storage, and at least some temporary storage of program code to reduce the number of times the code is retrieved from mass storage during execution. including cache memory. Input/output (I/O) devices (including, but not limited to, keyboards, displays, pointing devices, etc.) may be coupled to a computer system either directly or through intervening I/O controllers. Network adapters may also be coupled to the computer system to enable the computer system to become coupled to other computer systems or to remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the types of network adapters currently available. A computer system may also include an operating system and a computer file system.

It is to be understood that the above description and examples are intended to be illustrative, not limiting. Many embodiments will be apparent to those skilled in the art upon reading the above description and examples. Accordingly, the scope of the invention should not be determined with reference to the above description and examples, but should instead be determined with reference to the appended claims, with reference to the equivalents to which such claims are entitled. should be determined with reference to the full range of objects. The disclosures of all articles and references, including patent applications and publications, are incorporated herein by reference for all purposes.

Claims (10)

A method for electronic verification of information sources for source capture in a clinical trial workflow system, the method comprising:
starting an EMR system;
logging into the EMR system on behalf of a user using securely stored credentials;
automatically selecting the correct navigation link in the EMR system and filling out the appropriate navigation form to reach the EMR page for desired information about the correct research subject record and visit date;
capturing one or more screenshots of one or more relevant pages containing the desired information regarding answering one or more questions about a case report form (CRF);
verifying that the one or more captured screenshots are of the correct research subject by using one or more data points for verification;
How to prepare. The verifying step includes performing a real-time scan by the clinical trial system of the one or more screenshot captures to detect the presence of keywords in the one or more data points; and evaluating whether the captured screenshot is verified or unverified, the defined number of the one or more data points being determined by the one or more captured screenshots by the clinical trial system. the one or more captured screenshots are labeled as verified if the defined number of the one or more data points are not clearly identified by the clinical trial system; 2. The method of claim 1, wherein if the one or more captured screenshots are labeled as unverified. 3. The method of claim 2, wherein the data points include the research subject's first and last name, the research subject's date of birth, and the research subject's visit date. further comprising manually re-examining said one or more captured screenshots that are labeled as unverified, and if correct research subject data was used, said correct research subject data is labeled as unverified; If used in a captured screenshot, the user can determine that the one or more captured screenshots are approved and labeled as verified. manually re-examine the source of information and if incorrect research subject data is used in the one or more captured screenshots, the one or more captured screenshots are rejected and discarded; 3. The method according to claim 2. 3. The method of claim 2, wherein the defined number of specifically identified data points for validation assessment is set in a configuration setting. If the one or more captured screenshots are rejected and discarded, the one or more captured screenshots and associated snippets are separated from the CRF question and returned to the researcher user. 5. The method according to claim 4, wherein the method starts over from the beginning. the electronic verification is a secure, encrypted, two-way communication verifying that a connection has been established with the EMR system providing the source for the one or more captured screenshots; including two-way communication, with a handshake if the information source is verified; 2. The method of claim 1, requesting. 8. The method of claim 7, wherein the electronic verification is performed each time a screenshot is captured. 8. The method of claim 7, wherein the electronic verification is recorded such that a human readable log is generated. 8. The method of claim 7, wherein the EMR system verifies that the EMR system is displaying information about the correct research subject using screen optical recognition, interprocess communication, or a web-based API.

Images