JP6113068B2 - Method and system for managing clinical trials - Google Patents

Description

This application claims priority to US Provisional Patent Application No. 61 / 341,451 (filed Apr. 7, 2010). The contents of this patent application are hereby incorporated by reference.

  This application relates to a method and apparatus for managing trials, and more particularly to a web-based system, in which a trial portal is created for each trial, and access to the portal and trial documents are centrally managed.

  A pharmaceutical company (referred to as a trial sponsor) conducts a clinical trial to obtain approval for the drug. In order to obtain approval, the investigator should contact hospitals, clinics, medical colleges (called investigating sites) and qualified health care professionals (called clinical investigators) for drugs under development. Ask for cooperation to participate in clinical trials. During this trial, the sponsor and the study site will exchange large amounts of data and information. Prior to the present invention, these data were exchanged using a combination of mail, telephone, fax, email, and website. Because such a diverse set of communication technologies was used, the trial was cumbersome for the administrator and required significant overhead for the primary investigator, study site, and sponsor. It was.

  A method and apparatus for improving communication between sponsors, trial sites, and investigators is desired to minimize the overhead associated with conducting trials. The present invention has been made to solve this need in the art.

  The present invention solves the above-mentioned need for easy management of clinical trials by centralizing all clinical trial communications in a website system. By using the system of the present invention, a sponsor can easily manage individual websites for each valid trial using a website template driven by workflow management software. Candidate investigators can view current and future trials and select the trials they want to participate. The investigator can enter contact information and professional credentials to create a personal profile and register interest in the trial. The sponsor can search for candidate investigators who have qualifications that match those required for the trial. The sponsor can also invite candidate investigators to participate in the trial. The present invention programmatically creates a secure account that the investigator can use to access the trial website (referred to as a collaboration portal). Once the investigator logs into the collaboration portal, the investigator can assign additional administrative accounts for the investigator and portal. In addition, the investigator can upload an essential document of the clinical trial to a document storage location set for the clinical trial by the sponsor through the collaboration portal. The physician portal also gives investigators a central position to access trial alerts, notifications, and to-do lists.

  In an exemplary embodiment, the invention relates to a system and associated method for managing a trial. The system has at least one processor and at least one memory for storing instructions, wherein the instructions cause the at least one processor to generate an administrator portal when executed by the at least one processor, wherein The administrator portal allows the trial administrator to create and manage at least one trial website and exchange trial documents with the trial website. A clinical trial website is generated for each trial to be managed, where each clinical trial website exchanges clinical trial documents with the administrator portal, and each clinical trial website includes the relevant clinical trial administrator and each authorized trial. It has a separate file for storing data supporting the relevant clinical trial that can be accessed by the physician. The investigator accesses the study website via the physician portal for each investigator, where the physician portal associates the investigator with authority to participate in the study-related documents. Allows uploading to individual files on the trial website. The physician portal further allows the investigator to monitor activities and communications related to the trial for which the investigator is authorized to participate.

  The administrator portal is configured to list a plurality of investigators and allow the administrator to send an invitation to invite the investigator to participate in the study. The administrator portal is further configured to allow an administrator to create a Clinical Trial Master File for the relevant study website based on the template for customization to the study. Workflow management software can be used to display the templates according to a predetermined workflow order and order.

  The physician portal is configured to list multiple trials managed by the administrator and to allow the investigator to contact the administrator about their interest in participating in a particular trial. The Physician Portal also allows investigators to define personal or site profiles for administrator access and access study drug files related to the characteristics of the study drug being tested in the trial It is configured. The Physician Portal also allows investigators to index uploaded documents with metadata identified based on their identity and related trial and site information, and allows physicians to conduct trials in real time Allows access to the latest version of essential documentation that affects the implementation of. This communication also includes communication between an administrator and a doctor related to the required work item to-do list. Safety reports related to study drug can also be communicated between the administrator and the physician.

  These and other features and advantages of the present invention will become apparent from the following detailed description of the drawings.

1 shows a configuration of a collaborative clinical trial system according to the present invention. 1 shows a hardware configuration for realizing the cooperative clinical trial system of the present invention. Shows the clinical document exchange (CDE) portal. Shows the menu used to set up a new clinical trial website. FIG. 6 shows a window that appears when a sponsor selects the link in (a) to request a new trial website that prompts the sponsor to enter relevant information about the trial. An example of a clinical trial portal is shown. FIG. 9 shows the process for customizing the trial master file document to turn it into a trial-specific one. FIG. Shows how to edit and approve individual clinical trial documents. Shows the menu used to create a new trial site. A window that prompts the sponsor to answer a series of questions that appears when the sponsor selects the “Create New Investigational Site” link in (a) is shown. Shows the library of the study site from the perspective of the sponsor. Shows the display of the physician portal in the study site library. Figure 6 shows a display of a physician portal containing a published folder hierarchy of documents related to adverse events. Fig. 5 shows a drop-down menu that allows sponsor staff to use to create a new document. Shows the first screen of the New Document Wizard. The screen which a user sees when selecting "Upload from File" which prompts the user to input a file name in FIG. The window displayed after selecting the "Next" button in FIG. 13 is shown. Shows a window that prompts the investigator to enter study drug name, study number, and dose. The confirmation screen about the document is shown. Fig. 3 represents a sample logical data model for a key list included in a trial module. Fig. 3 represents a sample logical data model for a key list included in a trial module. Fig. 3 represents a sample logical data model for a key list included in a trial module. Fig. 3 represents a sample logical data model for a key list included in a trial module. Fig. 4 illustrates a standard SharePoint list processing form for creating new trial list items or editing existing list items. Fig. 5 illustrates a standard SharePoint list processing form for creating a new implementing agency list item or editing an existing list item. Fig. 4 illustrates a standard SharePoint list processing form for creating new implementing agency staff list items or editing existing list items. A form that is only available at a subsite and that is used to create a list of trial sites at that subsite. A form that is only available at the trial subsite and that is used to add an existing investigator to the trial at that subsite. A form that is only available at a subsite and that is used to create a list of implementing agency staff at that subsite. Shows a form that is only available at a subsite and that can be used to add an existing list of implementing agency staff to a trial at that subsite. Indicates a login page viewed by an external user. The user registration page shown with respect to an external user is shown. 1 shows a centralized management site for configuring a function called secure extranet access according to the present invention. FIG. 3 illustrates a SharePoint web application structure used by a collaboration portal in an exemplary embodiment. FIG. Shows the trial sponsor's trials listed on the trial page. Shows the Interest Registration page where you can register your interest in participating in the trial. Shows the entire external view website. A sample to-do list of the website of FIG. 31 is shown. FIG. 32 shows a sample document list of the website of FIG. FIG. 32 shows a sample test announcement on the website of FIG. FIG. 32 shows a sample contact for testing the website of FIG. FIG. 32 shows a sample test link for the website of FIG. FIG. 32 shows a sample test report for the website of FIG. An example of the standby page of the collaboration portal is shown. An example of a specific clinical trial waiting page in the collaboration portal is shown. Shown is the “My Trial Profile” page where an external user can save the location (location) of the trial for the facility. FIG. 5 shows a contact list web page displaying information about sponsor organization staff that a user needs to interact with during a trial. Indicates the study drug file of the study master file. Indicates the test file of the clinical trial master file. Indicates the country file of the trial master file. Indicates the conducting agency file of the clinical trial master file. A list of predetermined documents to upload or a web page showing the user the option to upload documents not in the list. 46 shows the Upload Site Document page that appears when the user clicks on one of the predetermined documents of FIG. 46 (eg, “Upload CV”). Shows the Upload Site Document web form, and external users browse it, select the file you want to upload, enter the name and title of the document, and click the button labeled “Check-In” to view the document. Can be identified. Shows a page listing application URL from which an external user can select access to other web-based clinical trial applications. The invite investigator page is presented and the study manager can view it to identify the investigator with the attributes required for a particular study. Shows the invite investigator page, which allows the study manager to select a previously selected investigator from the invitee list by clicking a button labeled “Remove Selected Investigators”. The process of inviting an investigator to participate in a clinical trial is shown. The software configuration of the clinical trial portal home page is shown. The software configuration of the clinical trial workspace home page is shown.

  For a thorough understanding of various embodiments of the invention, certain specific details are set forth in the following detailed description in conjunction with FIGS. However, some well-known details are not set forth in the following detailed description so as not to unnecessarily obscure the various embodiments of the present invention. Those skilled in the relevant arts will appreciate that other embodiments of the invention may be practiced without the need for the details set forth below. Also, in the following detailed description, various methods are described with reference to steps and sequences, which are for the purpose of providing a clear implementation of the embodiments of the present invention. And the sequence of steps should not be considered necessary for the practice of the present invention.

  FIG. 1 shows the configuration of the collaborative clinical trial system of the present invention. As shown, a website 101 called a clinical document exchange (CDE) or administrator portal provides access to the trial websites 102, 103, 104 in response to access. Website 101 includes a button that allows a sponsor or administrator to choose to automatically create trial websites 102, 103, 104. Each clinical trial website is used to manage a specific drug trial. Each trial is conducted at several clinical trial sites, such as hospitals, clinics and academic institutions. For each site, the sponsor has set up a separate folder of files to support the trial. The file folders 110 to 112 are called clinical trial master files. The sponsor will select these buttons on the trial website to generate these files. The Investigator Portal 120 provides a website for investigators to use at the site, which provides access to the latest version of the essential documents that affect the conduct of the investigator's trial and provide important information about the trial. Real-time contact with information. As will be described later, the investigator uses the doctor portal 120 to upload a document related to the trial.

  In an exemplary embodiment of the invention, a collaborative trial system is implemented with software on a server and / or group of servers, and a collaboration portal is implemented using a Microsoft® SharePoint® content management software system. . The workflow can be implemented using the Nintex ™ Workflow software module, which generates the administrator and physician portals and the trial website from the trial master file as described herein. The order and order of template display is determined. In the exemplary embodiment, collaborative trial system software, collaboration portal software, and workflow software are implemented in a system of the type shown in FIG.

  FIG. 2 shows a hardware configuration for realizing the collaborative clinical trial system of the present invention. As shown, study managers, clinical research associates, and other individuals managing trials can use Microsoft® SQL Server 131, Document Processing Server 132, and Active Directory. It communicates via the internal network 130 including the domain controller 133 that includes it (all via the LAN 140). On the other hand, the LAN 140 communicates through the DMZ firewall 150 including the DMZ LAN 160. The DMZ LAN 160 provides a domain controller 171 including Active Directory Lightweight Directory Service (AD LDS), a digital signature appliance 172, and a SharePoint (registered trademark) front-end web farm 173, and a SharePoint (registered trademark) front-end web farm. 173 provides collaborative clinical trial software of the present invention to provide centralized clinical trial management and search software for searching for desired information in the network shown. Internet firewall 180 separates DMZ LAN 160 from the Internet. As shown, an external investigator communicates from the Internet 190 through the Internet firewall 180 through extranet access.

  The servers 131-133 and 171-173 described in FIG. 2 are adapted to store and execute the collaborative trial system software, collaboration portal software, workflow software and extranet access control software described herein. It will be understood by those skilled in the art. Generally speaking, each server has a memory and a processor, and the processor executes software stored in the memory to perform the functions described herein. Those skilled in the art will appreciate that the server includes a computing environment implemented by a personal computer, mainframe, and the like. In the illustrated embodiment, the computing environment includes hardware and / or software elements such that the implemented computing environment executes applications such as collaborative trial system software, collaboration portal software, workflow software, etc. Used for. For example, the computing environment on each server may be used to run collaborative trial system software, collaboration portal software, and workflow software to perform the methods described herein with respect to FIGS. it can.

  In the exemplary embodiment, the processor of each server is in operative communication with an instruction memory that includes instructions for implementing an operating system and an application program for implementing an application program for implementing the techniques of the present invention. The processor includes a standard processor, a dedicated processor, a microprocessor, and the like. The processor executes instructions including instructions for implementing the processing described in connection with, for example, FIGS.

  The instruction memory stores instructions that can be executed by the processor of the associated server. Instruction memory may be computer readable in the form of volatile and / or nonvolatile memory such as random access memory (RAM), read only memory (ROM), cache, flash memory, hard disk or any suitable storage component A storage medium is mentioned. In one embodiment, the instruction memory may be an independent element that can communicate with the processor, and in other embodiments, the instruction memory may be integrated with the processor of the associated server.

  FIG. 3 shows a Clinical Document Exchange (CDE) portal 101. This portal website shows a trial master file structure 201, which is the default file structure used by the sponsor for the trial. Link 220 is used to create a new clinical trial website. In an exemplary embodiment, this CDE portal is implemented in a Microsoft® SharePoint® content management software system, where a sponsor or administrator uses SharePoint® file editing capabilities to create a trial master file. Allow structure 201 and files to be modified. The SharePoint® editing capabilities also display Nintex ™ to automatically create a collaboration website from data stored in the trial master file, displaying templates in a predetermined order and order. Can be complemented by the Workflow software module.

  FIG. 4a shows the menu used to set up a new trial website. When the sponsor clicks on link 301, the sponsor is prompted to enter relevant information about the trial in a window 310 of the type shown in FIG. 4b. After the sponsor has entered the necessary information in window 310, a new trial website is automatically created by a general software wizard.

  FIG. 5 shows an example of a clinical trial portal. As shown, each trial website is given a unique identifier 401. The new trial website includes a trial master file structure 411 and a copy of the file from the trial master file structure 201. The menu 405 is used by the sponsor to create a new trial site website.

  FIG. 6 shows the customization process to make the document from the trial master file unique to the trial. As shown, the original document 501 includes main templates for the Clinical Research Protocol, which are displayed in the order and order as directed by the workflow management software. The sponsor edits the allowed field in document 501 and converts it to a trial-specific document 502 for the identified trial 103094.

  FIG. 7 shows how the trial-specific document is edited and approved. The draft document 601 is reviewed by the sponsor of the sponsor. The judge adds comments to the draft in document 602. The comments are then included, for example, in a draft for approval and signature in document 603. If document 603 is approved, it is included as a standard document on the trial website. In the exemplary embodiment, the review process is managed by the editing functions of Microsoft® Office and Adobe® Acrobat®. The approval signature is compiled by a digital signature system (see element 172 in FIG. 2) such as the Co-sign system from Algorithmic Research. The Nintex ™ Workflow module is used to coordinate the workflow of this process from the data stored in the trial master file.

  FIG. 8a shows the menu used to create a new site folder in the site library. When the sponsor clicks on the “Request a New Trial Site” link 701, the sponsor is asked to answer the questions in window 702 of FIG. 8b. The sponsor is asked to fill in the following information: Investigational Products, Study Number, Site Number, Site Name, Site Site country, site address, site town, site state, site postal code, phone number of the site (Site Phone), executing agency's fax number (Site Fax), investigator (Principal Investigator), email address (Email address), executing agency's status (Site status), and method of Safety Report Distribution). After answering the questions, a new site folder is created in the site library. The site folder contains all the files needed by the site for managing the trial.

  The study site library can be viewed and modified not only by the sponsor, but also by the investigator and other staff of the study site. FIGS. 9 and 10 show the SharePoint® page used as a front end to the investigator library. In particular, FIG. 9 shows the display of the trial site library from the perspective of the sponsor. A folder 810 indicates a document at an executing agency level used when setting a clinical trial folder. On the other hand, FIG. 10a shows the display of the doctor portal of the trial master file. Items requiring action by a doctor are displayed on the To-Do web part 901. The physician keeps track of upcoming events and test alerts through the calendar and notification web part 902. The trial master file document is accessed through the document list 903. FIG. 10b shows a physician portal including a published hierarchy 950 of adverse event document folders. When a new adverse event document is added to the list, the investigator is notified by email containing a link to the relevant document. In the exemplary embodiment, the physician portal is similarly implemented in SharePoint®, and the trial master file document is modified using the SharePoint® editing functionality.

  FIGS. 11-16 illustrate how sponsor staff upload documents via the Trial Document Exchange Portal Wizard. Without this wizard, sponsor staff will need to be trained on the directory structure used for the trial master file. The wizard makes it easy to upload trial documents without requiring sponsor staff to know the directory structure of the trial master file.

The Smart Document Wizard (SDW) is a utility that greatly simplifies the configuration and management of system applications by reducing the number of types of site content required to meet commercial constraints. . SDW is a web page generated by a server based on ActiveX (registered trademark) scripting using Microsoft (registered trademark) ASP.NET framework. The code is first processed on the web server 173 (FIG. 2) and the resulting HTML code is sent to the user's web browser. The web page is generated based on configuration metadata stored in a series of SharePoint (registered trademark) lists described later. The SDW web page performs the following functions when a new document is created or uploaded to the SharePoint library:
1. Retrieve metadata to classify documents and create documents with the correct content type;
2. Retrieve metadata and index documents correctly;
3. Create the correct folder structure in the library and save the document (if the folder structure does not already exist);
4). Attach the appropriate authoring (approval) template to the document when creating the document (does not apply to uploaded documents).

  The following list example defines an inventory of artifacts that can be created within a SharePoint® site.

  The following is a sample list input based on the above list.

  This list defines the properties defined for the document. The properties defined in the list are collected by the user or retrieved in another SharePoint® by the SDW based on the key value provided by the user. The following list specifies the property control type and display order.

  The following is a sample list input based on the above list.

  FIG. 11 shows a drop-down menu that can be used by sponsor staff to create or upload a new document. The sponsor staff select the “Create a new Document.” Option from the menu. FIG. 12 shows the first screen of a new smart document wizard (SDW). In the first step, the sponsor staff can select whether they want to create a document from a template or upload a document from a file. If the user selects “Upload from File”, the user is prompted to enter a file name in the screen shown in FIG. When the “Next” button is clicked, the window of FIG. 14 is displayed. The parent content type, authoring template and folder path are searched in the document inventory list for the selected artifact. Property information regarding the parent content type is searched in the document property list. Based on the metadata, the SDW displays the required fields of FIG.

  In FIG. 15, the sponsor's staff is prompted to select the site of the executing agency, the state / province of the executing agency, and the name of the executing agency. Other fields are required based on metadata from previous steps. Once the sponsor staff has summarized the required properties, the SDW determines the values for the autofill properties and sets them. FIG. 16 shows a confirmation screen regarding a document. When the investigator clicks the finish button in FIG. 16, the system determines whether the folder structure exists in a particular library. If it does not exist, a folder structure is created. Documents with the appropriate content type are created in specific folders and collected properties. Finally, the appropriate authoring template is attached to the document and Microsoft® Word opens.

Trial Module Design The Trial Module includes a number of custom SharePoint® lists that are used to control many of the features described herein. The creation and subsequent approval of several list items initiates an automated process for creating the trial website, site library, and safety report distribution between administrators and physicians. Many of these lists and list items are interrelated and efficient management of this information is important to the operation of the system. The diagram of FIG. 17 shows a logical data model for the key list included in the exemplary embodiment of the trial module. This logical data model represents the general structure of information managed in the domain of the clinical trial collaboration portal. The logical data model is organized in terms of components and relationships and is independent of any particular management technology. It is the basis of a physical data model that is evident as an aggregation of SharePoint® lists.

  In the present invention, a component can be defined as recognized as being able to exist independently and can be uniquely identified. The components are represented as rectangles in FIG. For example, in FIG. 17, Clinical Trial (Investigation Site), Investigational Sites (Investigation Institution) and Site Personnel (Execution Organization Staff) are all considered components. Each component has properties that describe and identify it. Properties are listed in the rectangle of each component in FIG. A property (or combination of properties) that uniquely identifies an instance of a component is called a primary key, and is represented by “PK” in the rectangle of the component. A property that links a component to the primary key of another component is called a foreign key and is denoted by “FK” in the rectangle of the component. For example, a Clinical Trial component has two properties that are used to describe an instance of the component: a Protocol Number and a Protocol Title. Furthermore, it has a property called Clinical Trial ID (Clinical Trial ID) which is a primary key that uniquely identifies an instance of a component. It is also a foreign key property: indication ID (Indication ID), phase ID (Phase ID), study type ID (Study Type ID), study drug ID (Product ID) and study status ID linking it to the indication (Indication) (Study Status ID), Test Status (Study Phases), Test Drug (Investigational Product), and Test Status Composition (Study Status).

  The relationship can be considered as a link between a plurality of components, and is represented by an arrow connecting each component in FIG. Concentration rules (eg, one-to-one or one-to-many) are applied to the association between components. For example, a Clinical Trial component has a link to one and only one Indication component.

  The following table represents the physical data model as a SharePoint (registered trademark) list.

  18-24 show exemplary embodiments of forms used to manage clinical trial data stored in a SharePoint® list. The forms of FIGS. 18-20 use standard SharePoint® list processing. In order to create a new trial list item in FIG. 18, the user clicks the “New” button in the “All Item” display. To edit an existing list item, the user clicks the “Edit” icon linked to the list item in the “All Item” display. In FIG. 19, in order to create a list item of a new study site (Investigation Site), the user clicks a “New” button for “All Item” display. To edit an existing list item, the user clicks the “Edit” icon linked to the list item in the “All Item” display. In FIG. 20, in order to create a list item of a new executing agency staff (Site Personnel), the user clicks an “Edit” icon linked to a list item of “All Items” display. To edit an existing list item, the user clicks the “Edit” icon in the “All Items” display. On the other hand, the form of FIG. 21 is realized as a web page generated by a custom server based on ActiveX (registered trademark) scripting using Microsoft (registered trademark) ASP.NET framework. The form of FIG. 21 is only available at the trial subsite and is used to build the list of trial sites at the subsite. The form is loaded with the content of the trial site list first. The list is filtered with a country drop-down to limit the number of items displayed on the form. When the user clicks on the name of an individual implementing agency, the “Edit Form” for that list item opens. When the user clicks the “Create new site” link, the “New Item” form for that list opens. When the user selects the “Add from existing sites” link, the “Add from Existing Sites” subform opens.

  22 to 24 are realized as web pages generated by a custom server based on ActiveX (registered trademark) scripting using Microsoft (registered trademark) ASP.NET framework. The form of FIG. 22 is only available at the trial subsite and is used to build the trial site list at that subsite. The user must first select a country in order to filter valid trial sites. The items displayed in the “Available” list box are the conducting agencies in the list of conducting institutions on the root site, in the selected country, and in the status “Active”, An institution that does not exist in the list of investigators in the trial subsite. The item displayed in the “Selected” list box is the implementing agency in the list of treatment providers in the study subsite, is in the selected country, and has the status “Active” Executing agency. For example, the user selects one or more items from the “Available” list box and clicks the “Add” button to move them to the “Selected” list box. Similarly, the user selects one or more items from the “Selected” list box and clicks the “Remove” button to move them to the “Available” list box. When an item is removed from the “Selected” list, its status changes from “Active” to “Inactive” on the list in the study subsite. When an item is added to the “Selected” list box, a copy of the item is created from the site list at the root site and inserted with the status “Active” into the site list at the study subsite. Clicking the “OK” button confirms the change, and clicking the “Cancel” button discards the action.

  The form of FIG. 23 is only available at the trial subsite and is used to construct a Site Personnel list at that subsite. The form is first loaded with the content of the executing agency staff list. The list is filtered using, for example, country and investigative site drop-downs to limit the number displayed on the form. When clicking on a user's personal Last Name, an "Edit Form" is opened for that list item. When the user clicks the “Create new site personnel” link, a “New Item” for that list opens. When the user selects the “Add from existing site personnel” link, the “Add from Existing Site Personnel” subform opens.

  The form of FIG. 24 is only available at the trial subsite and is used to construct the implementing agency staff list at that subsite. The user must first filter the available trial sites and select a country. The user must select a trial site to filter the next available site staff. The items displayed in the “Available” list box are the executing agency staff in the executing agency staff list at the root site, have the status “Active”, and do not exist in the site personnel list at the trial subsite. Institution staff. The items displayed in the “Selected” list box are the executing agency staff in the executing agency staff list on the trial subsite, the executing agency staff who is in the selected executing agency and has the status “Active”. is there. For example, the user selects one or more items from the “Available” list box and clicks the “Add” button to move it to the “Selected” list box. Similarly, the user selects one or more items from the “Selected” list box and clicks the “Remove” button to place them in the “Available” list box. If an item is removed from the “Selected” list, its status will change from “Active” to “Inactive” on the site staff list at the study subsite. When an item is added to the “Selected” list box, a copy of that item is created from the executing agency staff list at the root site and inserted with the status “Active” into the executing agency staff list at the study subsite. . Clicking the “OK” button confirms the change, and clicking “Cancel” discards the action.

25-27 describe an exemplary embodiment of Secure Extranet Access for the systems described in FIGS. Secure extranet access is a site aggregation function that provides elements that enhance form based authentication (FBA) extranet access to SharePoint (registered trademark) sites. When a SharePoint® site is configured for FBA extranet access, this feature provides the following functionality:
1. User self-registration: External users can register a login account. Registration information is aggregated and can be reviewed by the site aggregation administrator;
2. Password reminder: registered external users can request an email containing login account information;
3. Account creation workflow activity: A custom Nintex ™ Workflow activity is provided that describes the order and order of the templates and is incorporated into a workflow that approves or rejects an external user registration request, for example. The custom activity is used for the created user account in the Active Directory (AD) of the domain controller 171 (FIG. 2).

  For example, secure extranet access is used as follows. Assume that an unregistered external user inputs the URL of a SharePoint (registered trademark) site configured for extranet access using a browser. The user is presented with a login page that includes a link to the self-registration page. The user follows the link to the registration page, inputs necessary registration information, and issues a registration request. The registration information is stored in the SharePoint (registered trademark) list (FIG. 55) of the site aggregation root site. An approval workflow created manually in the extranet configuration is initiated and the registration request is approved or rejected. If approved, a user account is created in an active directory store that supports FBA extranet access, and an email containing login account information is sent to the external user.

  The following is an example of an extranet user list. The secure extranet access function is activated and a list named “Prospective Investigators” is created at the site aggregation root site. This list includes essential user registration information. In addition, an approval workflow can be configured to start when an item (registration request) is added to this list.

  FIG. 25 shows a login page viewed by an external user. In this page, the user is requested for User ID and Password.

  FIG. 26 shows a user registration page shown to an external user. The user is requested for his first name, last name, email address, company name, telephone number, location, city, country, state and zip code.

  FIG. 27 shows a Central Administration site for configuring the secure extranet access function. This page is used to aggregate Active Directory information and SMTP information required by functional elements.

  FIG. 28 illustrates the SharePoint web application structure used by the collaboration portal in the exemplary embodiment. In this embodiment, the default web application exposes the same content in the web application to different types of users, such as internal collaborators (sponsors) and external collaborators (scientists). To include. When a web application is expanded to a new zone, a separate Internet Information Services (IIS) website is created to provide the same content, but a unique Uniform Resource Locator to verify user identity (URL) and approval type. As shown in FIG. 28, the extranet zone authorizes external users using Microsoft (registered trademark) Active Directory Lightweight Directory Service (AD LDS). After the user's identity is verified, an approval process determines which clinical trial websites, content and other features are accessible to the user.

  In FIG. 28, doctors and other external collaborators access the collaboration portal through an external URL (for example, http://collaborativetrials.sponsor.com). This URL directs external users to the extranet zone of the web application. In the extranet zone, the sponsor's welcome message is displayed, and the sponsor's trial is viewed on the trial page as shown in FIG. 29, and participation in the trial as shown in FIG. 30 is displayed. Includes a custom ASP NET web page for registering interests. Such web pages are not protected and do not require approval for access.

External view (appearance)
FIGS. 31-37 show an external view, which is based on a person who has completed basic document exchange (ie, upload and download), document review, document signing and form filling work (eg, an investigator). It is a display of the SharePoint (registered trademark) portal that exposes only the elements necessary to support external participation in the SharePoint (registered trademark) portal. External participants are defined as those who have received a certain training and / or have a certain technical experience in a SharePoint®-based system. From a role perspective, this includes investigator, investigator, laboratory, internal review body (IRB) and others with similar roles.

The external view includes the following important elements of the portal:
1. Standby page: SharePoint (registered trademark) portal “landing page”. Here external participants are directed at login;
2. To-Do list: SharePoint (registered trademark) work list. This includes a list of tasks that participants must complete. The work checklist includes, for example, one of the following “type” actions;
a. Upload new documents (via Smart Document Wizard) b. Document review. This includes the following:
1. Download documents 2. Editing on the local computer Upload a new version of the document. Completion of work c. Document signature d. 3. Fill out forms when existing documents and / or InfoPath® forms are fillable. Document: A SharePoint® document library for documents related to portal visits. In other words, all documents related to supporting document exchange, document review / approval and document signing work to be completed;
4). Contact list (optional): A SharePoint® list showing support contact information. This information can be managed in the page properties. This list can be managed in the “Edit Page” part;
5. Linked list (optional): A SharePoint® list that contains training webcasts, useful links to any material, or links to other applications;
6). Announcements (optional): A SharePoint® list containing important announcements to be shared with visitors to the site;
7). Report (optional): An image or other type of possible report showing a detailed summary of work completed so far and currently outstanding work for external users;
8). My Clinical Trials: A list containing links to all clinical trial websites that the user has access to. By default, the current trial is selected. When the user selects another trial in the list, the user is automatically directed to the trial portal for that trial. The drop-down list is part of the master page, meaning it is always valid.

  The user interface for external views is designed to be familiar and easy to use for everyone and especially for those who have only a certain amount of training and / or experience in a SharePoint® based system. Various people with various technical experiences visit this page. Therefore, it is important to make it as simple as possible to ensure successful adoption and ease of use.

FIG. 31 shows the entire external view website. The website consists of the following elements:
Sample To-Do List (Figure 32);
Sample document list (Figure 33);
A sample of the Study Announcement (Figure 34);
Test Contacts sample (Figure 35);
Test Link sample (Figure 36);
Sample of a study report (FIG. 37).

  A typical use case scenario for an external view is shown in the following example.

Example 1: Approval of a standby page The process in which a user approves a standby page is as follows:
1. The user types a URL on the browser to go to the external view standby page;
2. The user is presented with an approval form, where the user types a username and password;
3. After approval, the user arrives at the external view standby page. On the landing page, the user sees a to-do list that contains the work that he should complete and a list of documents related to the user's visit;
4). The user can also see other optional elements of information.

Example 2: Document Upload The process of uploading a document by a user is as follows:
1. [Complete the page flow];
2. Click on the task in the To-Do list titled “Upload CV”;
3. The Site Document Upload web form opens and the metadata information is automatically entered in the fields to attach the CV;
4). The user clicks the “Browse” button and a document selection means is displayed that directs to the local computer hard drive and selects the appropriate document to upload;
5. The user clicks the "OK"button;
6). The document is uploaded to the correct storage location / folder, metadata is added appropriately, and the work is completed;
7). The user now sees the documents that appear in the “Documents” list.

Example 3: Document Review The process by which a user reviews a document is as follows:
1. [Complete the page flow];
2. Click “Review Clinical Trial Agreement” in the To-Do list;
3. A text box for feedback on the work screen and a link to the appropriate document;
4). The user clicks a link that opens the appropriate document;
5. The document is opened in the user's client document program (Adobe (R), MS Word, etc.);
6). The user can review the document and edit it appropriately; after completion, the user closes the document.
7). The user can optionally enter his final comment in the work text box.
8). The user clicks OK, completes the task, and is removed from the To-Do list.

Example 4: Document Signing The process by which a user signs a document is as follows:
1. [Complete the page flow];
2. Click “Sign Protocol” in the To-Do list;
3. The user will see the “Approve” or “Reject” option of the protocol on the work screen. A link to the protocol document is also displayed for review prior to signing;
4). The user clicks on a link to open the appropriate document;
5. The document is opened in the user's client document program (Adobe (R), MS Word, etc.);
6). The user cannot edit the document. When finished, the user closes the document;
7). Click the “Approve” or “Reject” option on the work screen;
8). When the user clicks on “Approve”, the electronic signature information (aggregation of passwords to digitally sign the document) is displayed;
9. When the user clicks “Reject”, the electronic signature information is not displayed;
10. After selecting “Approve” or “Reject”, the user presses the “OK” button;
11. The work is completed and removed from the To-Do list. If the user selects “Approve” for a document, the document is digitally signed by the user. This records the signature information in the audit trail and version history of the document. Signature information also appears in the document.

Example 5: Form Fill The process for the user to fill in the form is as follows:
1. [Complete the page flow];
2. User clicks “Fill out 1572” in the To-Do list task;
3. The form to be edited / filled by the user (InfoPath (registered trademark), Adobe (registered trademark) PDF, Word form) is shown to the user. The user can edit only certain fields in the form (text boxes, checkboxes, radio buttons, etc.) and not other parts of the form;
4). After completion, the user clicks the “Save” or “Submit” button (depending on the design specifications of the form). User changes are saved to the current system;
5. The form closes, the work is marked as complete, and removed from the To-Do list;

  Contact information entered by a doctor who is an external user into the Register Interest (interest registration) page (FIG. 30) is stored in a SharePoint (registered trademark) list under the name Prospective Investigators (candidate doctor). Data access between the interest registration page and the candidate doctor list is controlled by the ASP .NET Business Object. Nintex ™ Workflow automatically routes each new list item to a central management group for verification of identity and authorization information. If the list item is found to be incorrect, it is removed from the candidate physician list. Once the item is approved, the candidate doctor will have participation in the trial.

  The extranet zone also includes custom ASP.NET web forms that allow registered external users to sign in to the collaboration portal using ASP.NET Forms-Based Authentication (FBA). After an external user has been approved, before the user gains full access to the collaboration portal, the following actions are required: change their temporary password, agree to a standard data privacy agreement, and verify personal contact information There is. The Change Password page is provided as a custom ASP.NET web form that requires external users to enter their current password and a new password (following the password complexity rules set by AD LDS). Is done. The user is required to retype a new password to ensure accuracy. When an external user clicks the submit button on the password change page, the password is reset using the AD LDS Application Programming Interface (API).

  After resetting the password, external users are redirected to a custom ASP.NET web page, which prompts them to accept the standard data privacy agreement. The Privacy Agreement page reads and displays standard message text for data privacy agreements. The external user can accept the terms of the agreement by clicking the button labeled “I Accepted this Agreement”, and then enter the username and password to verify identity. You are prompted to re-enter. The date and time of agreement acceptance is recorded in the Facility Personnel list via ASP.NET Business Object. If an external user rejects the contract terms by clicking on the button labeled “I Reject this Agreement”, the email containing the instructions to respond personally to this user is centrally managed Sent to the group. Once the external user agrees to the data privacy agreement, the user is directed to the collaboration portal by skipping this page on subsequent visits. The final action required of external users before gaining access to the collaboration portal is verification and confirmation of their contact information (this is called a personal profile). The Confirm Personal Profile page is a custom ASP.NET web form used to manage the information stored in the Clinical Personnel SharePoint® list.

  The external user modifies his profile information and submits the change by clicking the button labeled “Submit”. Data access between the Confirm Personal Profile page and the Clinical Personnel list is controlled by the ASP.NET Business Object. Completion of this operation is recorded in the Clinical Personnel list. The external user is prevented from accessing the collaboration portal until this task is completed, and is continuously directed to the web page until the external user does so. When the external user confirms the personal profile, the external user is directed to the collaboration portal by skipping this page in subsequent visits.

  After the necessary actions are completed, the external user is guided to the standby page of the collaboration portal as shown in FIG. From this page, external users will see a “To-Do List”, which is a list of work items that must be completed for all trials in which they are participating. External users will see a list of “Alerts and Notifications” that informs external users about important past and future events for all trials in which the external user is participating. . External users will also be given the option to edit their personal profile.

  Clicking on the Edit My Profile link (Figure 38) takes the external user to the Edit Personal Profile page, which is the SharePoint® list in the Clinical Personnel list. A custom ASP.NET web form used to manage information. External users can edit their personal profile information and submit changes by clicking the button labeled “Submit”. Data access between the Edit Personnel Profile page and the Clinical Personnel list is controlled by ASP.NET Business Object. The external user can click the button labeled “Cancel” to cancel the work and return to the standby page of the collaboration portal.

  External users will see a list of trial website URLs (called Workspaces) that they are invited to join. These URLs appear under the heading “My Clinical Trials” (FIG. 38). Clicking on the workspace URL takes the external user to a specific trial waiting page (FIG. 39). The trial workspace standby page displays to the external user a “To-Do List” of his work items that he should complete for a particular trial. The user is also presented with a list of “Alerts and Notifications” that informs the user about important events in the past or in the future for a particular trial.

  External users can also define and maintain a profile specific to their trial by clicking on the “My Trial Profile” URL, which allows the external user to access the “My Trial Profile” page (FIG. 40). ), This page is for Clinical Facility, Clinical Personnel, Clinical Facility Locations, Clinical Trial Site, Clinical Trial Site Personnel ) And Clinical Trial Site Location, a custom ASP.NET web form used to manage information stored in the SharePoint® list. The “My Trial Profile” page of FIG. 40 allows an external user to maintain a clinical trial specific location (location) regarding his / her facility. External users can click the button labeled “Add Location” to add a new location, or select an item from the list of locations displayed and click “Edit Location” You can edit an existing location by clicking the button labeled "Edit". In either case, the Add / Edit Location subform is displayed. The Add / Edit Location subform updates information stored in the SharePoint (registered trademark) list of the Clinical Facility Location and the Clinical Trial Site Location using ASP.NET Business Objects.

  External users can manage the study staff by clicking the “Personnel” tab on the “My Trial Profile” page. The user can either add a new staff member by clicking the button labeled “Add Personnel” or select an item from the list of staff members displayed and click “Edit Personnel” The existing staff can be modified by clicking the button labeled "". In either case, the Add / Edit Personnel subform is displayed. The Add / Edit Personnel subform uses ASP.NET Business Objects to update the update information stored in the SharePoint (registered trademark) list of the Clinical Personnel (Clinical Trial Site Personnel).

  External users can also view their “Contact List” by clicking on the Contact List URL. This action directs the user to the Contact List web page (Figure 41), which contains information about the sponsor organization staff that the user must interact with during the conduct of the trial. Is displayed. The information on the sponsor's staff displayed on the page is limited to the sponsor's staff directly related to the facility with which the external user is involved. This filtering is accomplished using a custom-developed SharePoint® Webpart that interacts with the ASP.NET Business Object to retrieve the appropriate contact information.

The external user can view the electronic trial master file by clicking the URL of the trial master file. The trial master file contains four different SharePoint® document libraries:
i. Study drug file-Documents that can be used for the test drug;
ii. Study files-documents that can be used throughout the trial;
iii. Country file-a document that can be used in the specific country where the trial is taking place;
iv. Investigator File-A document that can be used for the particular study site where the study is being conducted.

External users are directed directly to each document library by clicking on the appropriate URL. External users can only access documents that meet the following criteria:
i. Study drug files-documents classified as public documents;
ii. Test files-documents classified as public documents;
iii. Country files-documents classified as public documents that can be used in the country where the external user's facility is located;
iv. Executing Agency File-A document that is classified as a public document that can be used at a facility with which external users are involved.

  Access to external users' documents is controlled by a custom HTTP (Hyper Text Transfer Protocol) module that compares user authorization information with the metadata associated with each document to determine whether the user can access the document. Is done. Documents that are not accessible are not visible to external users in the document library. This is accomplished using a custom SharePoint web part that interacts with ASP.NET Business Objects to retrieve the appropriate document. The design of such modules is well known to those skilled in the art and is not described herein.

  Examples of trial master files are shown in FIGS. 42 shows an example of a study drug file (Product File), FIG. 43 shows an example of a study file (Study File), FIG. 44 shows an example of a country file (Country File), and FIG. An example of Site File).

  External users can click the Actions URL to upload the document to the executing agency file. The user is presented with a predetermined list of uploaded documents, or the user is given the option to upload documents that are not on the list (FIG. 46). When an external user clicks on one of the predetermined documents (eg, “Upload CV”), the user is directed to the Upload Site Document page (FIG. 47). The Upload Site Document page is a custom ASP.NET web form that allows an external user to browse and select a file to upload. When an external user clicks the button labeled “OK”, the user is then directed to the Upload Site Document web form (Figure 48), where the user enters the name and title of the document, and “Check-In” It is necessary to identify the document by clicking the button labeled “In)”. When an external user selects a predetermined document, the “artifact” field is automatically entered and cannot be edited. When an external user selects a generic document, the user selects a value for the artifact field from the drop-down list. Based on the artifact field, the document is automatically filed in the appropriate folder structure in the agency file. If the folder structure does not exist, the folder structure is automatically created before the document is uploaded. Interaction between the Upload Site Document page and the SharePoint® document library is managed by SharePoint® API calls.

  External users can access other web-based clinical trial applications by clicking on the Application URL. The user is presented with a list of application URLs that direct the user to these systems. This page is illustrated in FIG. Similarly, an external user can access a library of training artifacts by clicking on the Training URL. The user is presented with a list of training items, such as a user guide, frequently asked questions (FAQ) and a guide video that the user can refer to as needed.

  The sponsor staff will access the intranet zone of the collaboration portal via their web browser. Certain staff within the sponsor organization (referred to as study managers) are responsible for recruiting investigators to participate in the study. Study managers can invite one or more physicians to participate in the trial through the Invite investigator page. The invite Investigator page is implemented as a custom ASP.NET web form. The invite Investigator page allows the study manager to, for example, browse a candidate physician list (FIG. 50) or similar known physician list to identify investigators with the attributes required for a particular trial. These attributes include (but are not limited to) location and medical expertise. The test manager can also invite doctors who are not in the candidate doctor list or the known doctor list by entering their name, surname and email address on the web form. The doctor can be added to the invitee list by clicking on the button labeled “Add to Selected List”. The invitee list remains, so the exam manager can build it over time. The test manager can remove a previously selected physician from the list of invitees by clicking a button labeled “Remove Selected Investigators” (FIG. 51). The test manager can display all invited doctors or only the domestic invited doctors responsible for that person by selecting a filter in the invitee list and selecting the associated radio button. If the exam manager is satisfied with the invitee list, the exam manager can start the invitation process by clicking “Finalize and Send Invitations” or “Cancel invitations” By clicking “Cancel”, all ongoing invitations can be deleted (FIG. 51). When a doctor is invited, the doctor is added to the provisioning queue. When the invited physician has not previously participated in the trial (ie, selected from the candidate physician list), a user account is automatically created and an email containing their username and temporary password is sent Sent to that person. This function is realized by a SharePoint (registered trademark) timer job that polls the provisioning queue for new inputs and responds to unprocessed inputs. In addition, candidate doctor information is copied to the known doctor list and a welcome message containing a link to the collaborative trial website that is deleted from the candidate doctor list is sent to all invited doctors. This process is shown in FIG.

  FIG. 53 shows the software configuration of the above-described clinical trial portal homepage, and FIG. 54 shows the software configuration of the above-mentioned clinical trial workspace homepage. Those skilled in the art will appreciate that other forms can be added to this structure using the functionality of the content management software. FIG. 55 shows a representation of the logical data model for the key list for the embodiment illustrated in FIGS.

  It will be readily appreciated by those skilled in the art that many additional revisions and scenarios are possible in the exemplary embodiments without departing from the novel teachings and advantages of the present invention. For example, the system is described for applications using the SharePoint® content management software system. However, it will be appreciated by those skilled in the art that other content management software can be used to implement the functionality described herein. Accordingly, any such modifications are intended to be included within the scope of this invention as defined in the following claims.

Claims (23)

A method for managing a clinical trial,
At least one computer generating an administrator portal for a trial administrator to create and manage at least one trial website and to exchange trial documents with the trial website;
The at least one computer generates a trial website for each trial to be managed, and the investigator is authorized to participate in the trial website, and each trial website manages the trial document. Each trial website has a separate file for storage of data supporting the relevant trial that is accessible to the relevant trial administrator and each authorized investigator. And
The at least one computer generates a doctor portal for each investigator, wherein the doctor portal is adapted to upload a document from the investigator, the document being the investigator Is associated with a trial for which the investigator is authorized to participate, and is stored in a separate file on the relevant study website for which the investigator is authorized to participate, via the physician portal, Monitor activities and communications related to the trials the physician is authorized to participate in,
However, each of the trial documents is identified and related by a primary key and a foreign key, and the primary key (PK) uniquely identifies an instance of the component, and the foreign key (FK) links a component to another component's primary key (PK)
Wherein the the comprising, that it.   The method of claim 1, wherein the administrator portal further lists a plurality of investigators and allows the administrator to send invitations to invite investigators to participate in the study.   The method of claim 1, wherein the administrator portal further allows the administrator to create a trial master file for an associated trial website for customization based on a template.   The physician portal further lists a plurality of trials managed by the administrator, allowing the investigator to contact the administrator about their interest in participating in a particular trial. Item 2. The method according to Item 1.   The method of claim 1, wherein the physician portal further allows the investigator to define a personal profile for access by the administrator.   The method of claim 1, wherein the physician portal further allows the investigator to define an enforcement agency profile for access by the administrator.   The method of claim 1, wherein the physician portal further allows the investigator to access an investigational drug file associated with characteristics of the investigational drug being tested in the trial.   The method of claim 1, wherein the physician portal further allows the investigator to identify metadata and index uploaded documents.   The method of claim 1, wherein the physician portal further allows the investigator to access a current version of a mandatory document that affects the conduct of the trial in real time.   The method of claim 1, wherein the physician portal communicates a to-do list of required work items between the administrator and the investigator.   The method of claim 1, wherein the physician portal communicates a safety report related to a test drug between the administrator and the investigator. A system for managing clinical trials,
Having at least one processor and at least one memory for storing instructions, said instructions causing said at least one processor to perform the following steps when executed by said at least one processor:
A trial administrator creates and manages at least one trial website and generates an administrator portal for exchanging trial documents with the trial website;
Generate a clinical trial website for each trial to be managed, where the investigator is authorized to participate in each clinical trial website, and each trial website exchanges clinical trial documents with the administrator portal and The site has a separate file for storing data supporting the relevant trial that can be accessed by the relevant trial administrator and each authorized investigator,
Generate a physician portal for each investigator, wherein the physician portal is adapted to upload a document from the investigator, and the document is included in the trial for which the investigator is authorized to participate. Is stored in a separate file on the relevant clinical trial website to which the investigator is authorized to participate, and the physician portal allows the investigator to participate in the trial for which the investigator is authorized to participate. Monitor related activities and communications,
However, each of the trial documents is identified and related by a primary key and a foreign key, and the primary key (PK) uniquely identifies an instance of the component, and the foreign key (FK) links a component to the primary key (PK) of another component,
A system characterized by that.   The system of claim 12, wherein the administrator portal lists a plurality of investigators and allows the administrator to send an invitation to invite the investigators to participate in a study.   13. The system of claim 12, wherein the administrator portal allows the administrator to create a trial master file for an associated trial website for customization based on a template.   13. The physician portal lists a plurality of trials managed by the administrator and allows the investigator to contact the administrator regarding interest in participating in a particular trial. System.   The system of claim 12, wherein the physician portal allows the investigator to define a personal profile for access by the administrator.   The system of claim 12, wherein the physician portal allows the investigator to define an enforcement agency profile for access by the administrator.   13. The system of claim 12, wherein the physician portal allows the investigator to access study drug files associated with the characteristics of the study drug being tested in the trial.   13. The system of claim 12, wherein the physician portal allows the investigator to index uploaded documents with identifying metadata based on identity and associated trial and site information. .   13. The system of claim 12, wherein the physician portal further allows the investigator to access the latest version of a required document that affects the conduct of the trial in real time.   The system of claim 12, wherein the contact includes a to-do list of required work items to be contacted between the administrator and the investigator.   The system of claim 12, wherein the physician portal communicates safety reports related to a test drug between the administrator and the investigator.   The system of claim 12, wherein the processor further executes instructions of workflow management software that implements the generating step according to a predetermined workflow order and sequence run by a template.

Images