Patent Application
20180101662
The subject technology relates generally to medical data management, and more particularly to processing clinical trial data.
Clinical trials are research studies on participants designed to answer specific questions about biomedical or behavioral interventions, including new treatments (such as drugs and medical devices). A clinical trial may involve a sponsor, which may be a governmental organization, or a pharmaceutical, medical device, or biotechnology company, and one or more clinical sites. Traditionally, patient clinical trial source data are captured on paper at clinical sites. The documents are collected by a sponsor, and the clinical trial source data may then be imported to an electronic data capture (EDC) system, which is a system usually owned by a sponsor and designed for the collection of clinical data in electronic format. It is desirable to improve efficiency of the process for collecting clinical trial data.
A method for processing clinical trial data comprises: enabling display of a first user interface for receiving a definition of a first clinical trial, wherein the definition of the first clinical trial defines requirements and a workflow of the first clinical trial, and wherein the definition of the first clinical trial comprises a first object and a second object. The method further comprises: receiving the definition of the first clinical trial from the first user interface; storing the definition of the first clinical trial in a first repository in a clinical trial sponsor system; enabling a first clinical trial site system and a second clinical trial site system to access the definition of the first clinical trial; and enabling display of a second user interface for receiving clinical trial source data of a first subject and a second subject, wherein the second user interface is generated based on the first object and the second object. The method further comprises: receiving clinical trial source data of the first subject and the second subject from the second user interface, wherein the clinical trial source data are correlated to the first object and the second object from the first repository in the clinical trial sponsor system. The method further comprises storing the clinical trial source data of the first subject and the second subject in the first clinical trial site system.
The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, the subject technology is not limited to the specific details set forth herein and may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.
The user computing devices 120a . . . 120n may be any machine or system that is used by a user to access the medical data management system 110 via the network 150, and may be any commercially available computing devices including laptop computers, desktop computers, mobile phones, smart phones, tablet computers, netbooks, and personal digital assistants (PDAs). A client application 121 may run from a user computing device, e.g., 120a, and access data in the medical data management system 110 via the network 150.
The medical data storage system 111 may store medical data that client applications (e.g., 121) in user computing devices 120a-120n may access and may be any commercially available storage devices. Each content repository (e.g., 111a, 111b or 111n) may store a specific category of data, and allow users to interact with its data in a specific business context. It should be appreciated that content repositories may be separate logic sections in a same storage device.
The medical data management server 112 is typically a remote computer system accessible over a remote or local network, such as the network 150. The medical data management server 112 may store a medical data management controller 112a and a medical data collection controller 112b for controlling management and collection of the medical data, including the method to be discussed with
In one implementation, the architecture 100 may be used for collecting and managing medical data, e.g., clinical trial data. A first repository (e.g., 111a) may be used by a first sponsor (e.g., a pharmaceutical company) to store a first study design received from a first user computing device (e.g., 120a). The first study design may define the infrastructure and lifecycle of the study, and may comprise rules (e.g., for queries, derived values, notifications and displaying events, forms and items), a casebook (i.e., a doctor's binder), event groups, events (e.g., patient visits), forms which comprise segregate sections and fields, item groups and items. In one example, a study design may define a particular study, i.e., each patient may have ten visits, and each visit may have three forms. There may be a workflow associated with each visit, e.g., what needs to be done at each visit.
In one implementation, the first study design may be stored as definition objects in the first repository 111a, specifying what is required to happen on each site during the study. The first repository 111a may also store electronic records of the first study. In one implementation, the electronic records may be EDC data. Patient clinical trial source data may be captured at the user computing devices, and the aggregated and obfuscated data may be stored as EDC data in the first repository 111a. The medical data management system 110 may have an interface for receiving EDC data collected in clinical trials and a reporting tool for analysis of the EDC data.
The second repository 111b may be used by a first site (e.g., a hospital) of the first study to store clinical trial source data from a second user computing device (e.g., 120b), and a third repository (e.g., 111c) may be used by a second site of the first study to store clinical trial source data from a third user computing device (e.g., 120c). The clinical trial source data (e.g., three blood pressure values of a patient taken during one visit) in the second repository 111b may be converted to EDC data (e.g., the average of the three blood pressure values) automatically, and then stored in the first repository 111a as EDC data. Similarly, the clinical trial source data in the third repository 111c may be converted to EDC data automatically, and then stored in the first repository 111a as EDC data. In one implementation, the clinical trial source data may be converted to the EDC data at the client application 121, and the EDC data is transmitted to the medical data management server 112. In one implementation, the clinical trial source data may be transmitted to the repository 111b or 111c via the medical data management server 112, and converted to the EDC data at the medical data management server 112. The EDC data is then stored in the repository 111a. Data in the second repository 111b and the third repository 111c may be synchronized with that in the first repository 111a regularly or from time to time when new data entries are received from user computing devices. The first study design may be transmitted to the second repository 111b and the third repository 111c. The second repository and the third repository may be synchronized with the first repository for updates to the first study design.
In one implementation, the medical data management system 110 may be a multi-tenant system where various elements of hardware and software may be shared by one or more customers. For instance, a server may simultaneously process requests from a plurality of customers (e.g., sponsors, and clinical sites), and the medical data storage system 111 may store content for a plurality of customers (e.g., sponsors, and clinical sites). In a multi-tenant system, a user is typically associated with a particular customer. In one example, a user could be an employee of one of a number of pharmaceutical companies or clinical trial sites which are tenants, or customers, of the medical data management system 110.
In one embodiment, the medical data management system 110 may run on a cloud computing platform. Users can access content on the cloud independently by using a virtual machine image, or purchasing access to a service maintained by a cloud database provider.
In one embodiment, the medical data management system 110 may be provided as Software as a Service (“SaaS”) to allow users to access the medical data management system 110 with a thin client.
The processing unit 201 may be configured to execute computer instructions that are stored in a computer-readable medium, for example, the system memory 202. The processing unit 201 may be a central processing unit (CPU).
The system memory 202 typically includes a variety of computer readable media which may be any available media accessible by the processing unit 201. For instance, the system memory 202 may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). By way of example, but not limitation, the system memory 202 may store instructions and data, e.g., an operating system, program modules, various application programs, and program data.
A user can enter commands and information to the computing device 200 through the input device 203. The input device 203 may be, e.g., a keyboard, a touchscreen input device, a touch pad, a mouse, a microphone, and/or a pen.
The computing device 200 may provide its output via the output device 204 which may be, e.g., a monitor or other type of display device, a speaker, or a printer.
The computing device 200, through the network interface 205, may operate in a networked or distributed environment using logical connections to one or more other computing devices, which may be a personal computer, a server, a router, a network PC, a peer device, a smart phone, or any other media consumption or transmission device, and may include any or all of the elements described above. The logical connections may include a network (e.g., the network 150) and/or buses. The network interface 205 may be configured to allow the computing device 200 to transmit and receive data in a network, for example, the network 150. The network interface 205 may include one or more network interface cards (NICs).
In one implementation, the medical data management controller 112a may be a Java application. A sponsor user may design a clinical study via the medical data management controller 112a and store the study design as definition objects in a repository (e.g., 111a). A study design may have multiple elements, including a casebook, groups, events (e.g., patient visits), and forms which include sections, item groups, items, and fields to be filled out.
In one example, a clinical trial is designed to evaluate patient response to a blood pressure medication. Participants on the medication may visit a clinical trial site three times a week for consecutive six weeks. A workflow may be designed for each visit, and may include forms to be filled out, and measurements to be taken. In one example, a participant's blood pressure may be measured three times during each visit, stored in the medical data storage system (e.g., the repository 111b) as clinical trial source data, and synchronized with other repositories in the medical data storage system 111 (e.g., the repository 111a for the sponsor). In one implementation, only aggregated and obfuscated data, without patient defining information, are sent to the sponsor repository 111a and stored there as the EDC data.
A study design may have its own lifecycle. Once a sponsor completes a study design, a workflow may be executed to publish the study design to the participating clinical trial sites (e.g., by storing the study design in clinical trial site repositories 111b and 111c) and the clinical trial may enter its execution stage. If the study design is amended during the execution stage, the updates may be sent to the participating clinical trial sites (e.g., by synchronizing the updates down to the clinical trial site repositories 111b and 111c) for them to follow.
The study design may be stored in the medical data management system 110 (e.g., the repository 111a) as objects. A few examples of the objects are described below:
1. FORM_DEF
FORM_DEF is the design object for all Forms.
2. FORM_DEF_ITEMGROUP_DEF
FORM_DEF_ITEMGROUP_DEF is the design Intersection object between Form and Item Group. It enables the system to understand what Sections should appear on a Form that is part of a visit.
3. EVENT_DEF
EVENT_DEF is the design object for events (visits). A visit will require that multiple forms be filled out.
4. EVENT_DEF_FORM_DEF
It is the Design Intersection object between Event and Form, and enables the system to understand what Forms should appear on a visit.
5. CASEBOOK_DEF
It is the design object for casebook, which is a set of visits that are expected to be used to collect information for a specific patient.
6. ITEM_[STUDYID]
It is the execution object. Stores the data that is captured. A separate ITEM Table will be created per Study.
7. ITEMGROUP
It is the execution object, and stores that a question was answered in a particular section (ItemGroup) and the section has a status.
The objects may be used and transferred across all parts in the architecture 100 shown in
An example of an item VV-000061 is shown below:
The definitions may be correlated and stored in the medical data storage system 111 as structured data. One example is shown as follows:
The client application 121 may be an application installed on a computing device, or a web application. Users at a clinical trial site may enter patient clinical trial information via the client application 121, and the clinical trial source data may be stored in a repository (e.g., 111b).
When the site user selects a clinical trial from the area 601, a user interface 620 shown in
When the site user selects a subject, a user interface 640 shown in
When the site user starts or selects a visit, a clinical trial form user interface 660 shown in
The clinical trial site user may navigate through the user interfaces, and go to any point in the hierarchy and any subject in the study. The site user may fill out the information, and go to the next subject, without having to change the context and the event in the form that he/she is filling out.
The user interfaces 600, 620, 640 and 660 may be generated based on one or more objects in the definition of the first clinical trial. In one implementation, the user interfaces may be generated by the medical data management controller 112a, and sent to the clinical trial sites and user computing devices. In one implementation, the user interfaces may be generated by the medical data collection controller 112b based on the objects in the definition of the first clinical trial from the medical data management controller 112a, and sent to the user computing devices. In one implementation, the user interfaces may be generated by the user computing device, e.g., 120b, based on the objects in the definition of the first clinical trial from the medical data management controller 112a or the medical data collection controller 112b.
The process may start at 701.
At 703, a user interface, e.g., the user interface 400 shown in
At 705, the first study design may be received at the medical data management controller 112a from the user computing device 120a and stored in the medical data management system 110, e.g., the repository 111a for the sponsor. The first study design may define one or more forms for each visit, and each form may include information such as a patient's demographic information (e.g., name, Date of Birth, race and gender) and clinical trial source data to be collected. The first study design may also define events and the sequence of the events, which may include screening events, enrollment, medical history, repeating frequency of visits depending on the protocol, and workflow of each visit (e.g., administering medication and taking one or more measurements on a predetermined schedule). Each form may have a number of boxes for receiving data. The definitions, elements or items (e.g., Date of Birth) may be used across the sponsor system, all clinical trial site systems and user computing devices, and flow back and forth in the architecture 100 shown in
At 707, the first study design may be published and transmitted to sites involved. In one implementation, the study design may be stored in, e.g., the repository 111b for a first participating site and the repository 111c for a second participating site. In one example, the repository 111b and the repository 111c may be authenticated before the first design study can be transmitted to it.
In one implementation, clinical trial forms, e.g., the clinical trial form shown in
At 709, the first study design may be updated or expanded, e.g., by the medical data collection controller 112b in the first clinical trial site system. For example, the first study definition from the sponsor's medical data management controller 112a may require a blood pressure value, and the object maybe, e.g., 901-Initial. The definition may be updated at the medical data collection controller 112b to use the average of three blood pressure values during one visit as the blood pressure value required by the first study definition, and the objects may be 901-Initial-2, 901-Initial-3 and 901-Initial-Calculated. Different versions of definitions may be mapped and correlated.
At 711, a clinical trial site user may log in, and user interfaces 600, 620, 640 and 660 may be displayed while he/she is navigating through the webpages to select the study, subject, event and form. In one implementation, the user interfaces 600, 620, 640 and 660 may be generated by the medical data collection controller 112b in the first clinical trial site system based on the updated objects (e.g., 901-Initial-1, 901-Initial-2, and 901-Initial-3) and data in the medical data storage system 111, and sent to the user computing device 120b. In one implementation, the user interfaces 600, 620, 640 and 660 may be generated by the user computing device 120b based on the objects in the first study definition from the medical data management controller 112a (e.g., 901-Initial) or updated objects from the medical data collection controller 112b (e.g., 901-Initial-1, 901-Initial-2, and 901-Initial-3), and data from the medical data storage system 111.
At 713, medical data may be entered on a user interface, e.g., the user interface 660 shown in
At 715, the clinical trial source data may be processed to get the EDC data. In one example, the three blood pressure values may be averaged up and obfuscated to get the EDC data. The clinical trial source data from the user computing device 120b (e.g., 110/70, 106/69, and 111/74) and corresponding to the updated objects from the medical data collection controller 112b (e.g., 901-Initial-1, 901-Initial-2, and 901-Initial-3) may be processed to get 901-Initial-Calculated (e.g., 109/71), which may then be processed into the EDC data (e.g., through obfuscation. The EDC data may include the object 901-Initial-Calculated and its value. In one implementation, the clinical trial source data may be sent to the medical data collection controller 112b and converted to the EDC data there. Alternatively, the clinical trial source data may be processed on the user computing device 120b, and the EDC data is then transmitted to the medical data management controller 112a.
At 717, the EDC data may be mapped to the objects in the first study design, e.g., the 901-Initial-Calculated may be mapped to the object 901-Initial in the definition of the first study design based on their definitions.
At 719, the EDC data may be stored in the repository 111a mapped to objects in the definition of the first study design.
At 721, it may be determined if there are any updates to the first study design. If yes, the process may return to 707 for transmitting updates to the first study design. Otherwise, the process may return to 711 to capture the medical data.
In one implementation, Jason formatted structure may be used for the data mapping to allow the data to flow back and forth across various parts in the architecture 100.
The above-described features and applications can be implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
These functions described above can be implemented in digital electronic circuitry, in computer software, firmware or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.
In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some implementations, multiple software technologies can be implemented as sub-parts of a larger program while remaining distinct software technologies. In some implementations, multiple software technologies can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software technology described here is within the scope of the subject technology. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs. Examples of computer programs or computer code include machine code, for example is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium” and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.
It is understood that any specific order or hierarchy of steps in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged, or that all illustrated steps be performed. Some of the steps may be performed simultaneously. For example, in certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components illustrated above should not be understood as requiring such separation, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
Various modifications to these aspects will be readily apparent, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, where reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more.
This application relates and claims priority to provisional patent application No. 62/407,399, filed on Oct. 12, 2016, entitled System and Method for Collecting Medical Data, which is hereby incorporated by reference herein for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 62407399 | Oct 2016 | US |
