Controlled data access for decentralized clinical trial space

Abstract

This document discloses a system and method for controlling data access within a decentralized clinical trial space. In various embodiments of the invention, a patient portal system may interconnect with a clinical trial database, a patient device configured to access a patient portal application associated with the patient portal system, and an intermediate system having an intermediate database. Data sent from the patient device to the patient portal system may include obfuscated patient data. Such obfuscated patient data may be sent to the intermediate database, which may be configured to access identified patient data from the obfuscated patient data via a private key stored therein. The patient portal system may enable patients to perform various clinical trial-related functions, such as ordering sample collection kits to be performed by a supply system interconnected with the intermediate database.

Description

Cross-references to related applications

[0001] This non-provisional application claims priority to the earlier provisional application No. 63 / 547,219, filed on 3 November 2023, which is currently pending and whose contents are incorporated herein by reference in their entirety. Technical Field

[0002] This application relates in general to systems and methods for controlling data access in decentralized clinical trial spaces, such as, for example, providing trial participants with access to and from their residences for supply kit delivery and sample collection. Summary of the Invention

[0003] Clinical trials are a crucial part of research into new tests and treatments and are often subject to regulatory requirements. Traditionally, participants in clinical trials (also referred to here as “patients”) visit a physical facility to register for the trial and collect one or more samples during a single or multiple visits. As more systems and services shift to online or remote options, providing decentralized trial spaces has become a significant consideration in the clinical trial industry. However, existing technologies used for online ordering and fulfillment, as well as collection, are ill-suited to the unique workflows and data access controls associated with clinical trials. For example, clinical trials are often associated with anonymity regulations, thus clinical trial providers are typically restricted from accessing identifying information about patients, including names, email addresses, and physical mailing addresses, all of which are routinely collected and used in existing online ordering and collection technologies. In other words, anonymity regulations and / or blinding requirements may necessitate data segmentation to facilitate compliance and trial efficacy.

[0004] However, due to these anonymity and / or blinding requirements, patients in decentralized clinical trial settings often cannot know the delivery status of their supply kits to their homes because the clinical trial providers for these patients do not store and access the relevant delivery data associated with the identification information. In other words, because data cannot be unblinded in conventional systems, patients using such systems must manually locate the site and / or contact the researcher for details and make a call to obtain the status of their delivery and pickup. Naturally, the complexity of this process often leads to lower patient adherence metrics in clinical trials.

[0005] Therefore, the embodiments described herein provide systems and methods for addressing these and other technical problems by controlling access to data within online ordering systems (and specifically, online ordering systems associated with decentralized clinical trials). As described in more detail below, the methods and systems described herein allow clinical trial providers and participants to manage in a controlled manner the supply kits provided to patients, manage patient and sample-level data collected for visits, and manage sample collection and delivery to laboratories to ensure proper access to and segregation of data in compliance with the anonymity requirements discussed earlier. The methods and systems described herein also efficiently connect participants within a given clinical trial to their applicable trial site, researchers, help desks, and any necessary third-party applications associated with that given clinical trial. For example, some embodiments described herein enable participants to launch third-party applications within an application installed on the participant's device (e.g., a mobile phone, tablet, etc.), such as using single sign-on (SSO) technology or application programming interface (API) integration.

[0006] In view of the foregoing, an exemplary method for protecting personal patient information in a decentralized clinical trial may include: (a) registering a patient portal application on at least one user device via a registration code including a shared key configured to generate obfuscated patient data for transmission to a patient portal system via at least one server configured to communicatively connect to an intermediate system having an intermediate database and a clinical trial database; (b) receiving sample collection information from the server at the user device, the sample collection information including identifiers of supply kits that can be ordered by at least one patient participating in the clinical trial; (c) providing the sample collection information within the user interface of the patient portal application at the user device; (d) receiving the obfuscated patient data associated with the provided sample collection information from the user device at the patient portal system; (e) transmitting the obfuscated patient data from the patient portal system to the intermediate database, the intermediate database including a private key configured to transform the obfuscated patient data into patient data identifying the patient data; and (f) transmitting the patient data identifying the patient data from the intermediate database to at least one supply system.

[0007] In at least one alternative embodiment, a method for protecting personal patient information in a decentralized clinical trial may include: (a) placing a patient portal system in a communication configuration with a clinical trial database, an intermediate database, and at least one user device via at least one server; (b) storing key-decoded data associated with at least one patient on the clinical trial database; (c) registering the at least one user device with the patient portal system via a patient portal application set on the at least one user device, the registration being performed by at least one registration code provided to the at least one patient; (d) receiving data associated with the at least one patient by the patient portal application and generating obfuscated patient data from the data according to an encoding algorithm; (e) sending the obfuscated patient data to the intermediate database via the patient portal system, the intermediate database having at least one private key stored therein, the at least one private key being configured to access identified patient data from the obfuscated patient data; and (f) sending the obfuscated patient data from the intermediate database to at least one supply system, the at least one supply system being configured to communicatively connect to the intermediate database.

[0008] Similarly, in at least one alternative embodiment, a system for controlling data access to a patient's personal information in a decentralized clinical trial may include: (a) a patient portal system configured to communicatively connect to at least one patient device, a clinical trial database, and at least one intermediate database; (b) the at least one patient device including a processor configured to communicatively connect to memory to provide input / output communication with the patient portal system to the patient via a patient portal application stored on the at least one patient device; (c) the at least one patient device configured to scan at least one registration code configured to enable access by the at least one patient device to the patient portal application for inputting patient identification data in the patient portal application; and (d) the registration code configured to be shared via a shared key. (e) The patient portal system is configured to receive the obfuscated patient data and the key-decoded data from the at least one patient device via the patient portal application; (f) The patient portal system is configured to provide the key-decoded data to the clinical trial database; (g) The patient portal system is configured to provide the obfuscated patient data to the intermediate database; (h) The intermediate database is configured to apply a private key stored therein to the obfuscated patient data to access the obfuscated patient data; and (i) The intermediate database is configured to provide the obfuscated patient data to a supply system configured to communicatively connect to the intermediate database. Attached Figure Description

[0009] The embodiments will be readily understood through the following detailed description taken in conjunction with the accompanying drawings. For ease of description, the same reference numerals denote the same structural elements. The embodiments are illustrated in the figures by way of example rather than limitation.

[0010] Figure 1A This is a block diagram illustrating a decentralized clinical trial system based on various implementation schemes.

[0011] Figure 1B This illustrates the requirements based on various implementation plans. Figure 1A A block diagram of the coding algorithm used in the decentralized clinical trial system.

[0012] Figure 2 This illustrates the inclusion of various implementation schemes. Figure 1A A block diagram of the patient equipment in the system.

[0013] Figure 3 This illustrates the inclusion of various implementation schemes. Figure 1A A block diagram of the patient portal system in the system.

[0014] Figure 4 This is a flowchart illustrating the workflow methods for patient portal applications based on various implementation schemes.

[0015] Figure 5 This is a flowchart illustrating patient portal registration methods according to various implementation schemes.

[0016] Figure 6 This is a flowchart illustrating supply order methods according to various implementation schemes.

[0017] Figure 7 This is a flowchart illustrating sample kit collection methods according to various implementation schemes.

[0018] Figure 8 This is a flowchart illustrating electronic application methods according to various implementation schemes.

[0019] Figures 9A to 9P Multiple graphical user interfaces provided to patients via a patient portal application according to various implementation schemes are described.

[0020] Figure 10 illustrates the implementation based on various schemes. Figure 7 A block diagram of the computing device for the patient portal system. Detailed Implementation

[0021] This document discloses systems, methods, computing and storage devices, and computer-readable media for providing decentralized clinical trial environments. The systems, methods, computing and storage devices, and computer-readable media disclosed herein achieve improved performance compared to conventional methods, and for example, improved performance compared to existing online ordering technologies. As mentioned above, existing online ordering technologies are not suitable for clinical trial settings or other settings that require controlled data access to prevent specific systems and devices from accessing specific data types, such as participant identification information, including but not limited to participant names, email addresses, and / or physical mailing addresses.

[0022] The aforementioned problems in the prior art can be beneficially addressed using the various examples, aspects, features, and implementations of the systems and methods for data access control disclosed herein. Therefore, the technical problems arising from bringing clinical trials into remote or online environments can be solved by the specific computing systems, devices, and functionalities and data distributions described in the various implementations herein. Thus, the implementations disclosed herein provide improvements to online ordering technologies (e.g., improvements to computer technologies supporting such ordering functionality, and others), such as anonymity-based data control solutions among various devices, systems, and databases associated with decentralized clinical trial systems.

[0023] In the following detailed description, reference is made to the accompanying drawings, which form part of the detailed description, wherein like reference numerals always indicate like parts, and practical embodiments are shown in the drawings by way of illustration. It should be understood that other embodiments may be utilized, and structural or logical changes may be made, without departing from the scope of this disclosure. Therefore, the following detailed description should not be regarded as limiting.

[0024] Various operations can be described as multiple discrete actions or operations in a manner most conducive to understanding the subject matter disclosed herein. However, the described order should not be construed as implying that these operations must depend on the order. Specifically, such operations may not be performed in the order presented. The described operations may be performed in a different order than the described embodiments. Various additional operations may be performed, and / or the described operations may be omitted in additional embodiments.

[0025] For the purposes of this disclosure, the phrases "A and / or B" and "A or B" mean (A), (B), or (A and B). For the purposes of this disclosure, the phrases "A, B and / or C" and "A, B or C" mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). Although some elements may be represented in the singular (e.g., "processing device"), any suitable element may be represented by multiple instances of that element, and vice versa. For example, a set of operations described as being performed by a processing device may be implemented as different operations among those operations performed by different processing devices.

[0026] This specification uses the phrases "implementation," "various implementations," and "some implementations," each of which can refer to one or more implementations of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," etc., used with respect to embodiments of this disclosure are synonymous. When used to describe a range of values, the phrase "between X and Y" indicates a range including both X and Y. As used herein, "apparatus" can refer to any single device, a collection of devices, a portion of a device, or a collection of portions of a device. The figures are not necessarily drawn to scale.

[0027] Figure 1A This is a block diagram illustrating a decentralized clinical trial (“DCT”) system 10 according to various embodiments of the present disclosure. The DCT system 10 includes one or more patient devices 20 (such as those user devices 304 operated by patients and / or trial participants (alternative user devices 304 operated by others associated with the clinical trial are envisioned and discussed in more detail below)), an intermediate system 30 with an intermediate database 31 and an intermediate user interface 308, a patient portal system (“PPS”) 40, and a supply system 50 (also referred to herein as a supply repository). Figure 1A As illustrated, PPS 40 may further communicate with or access clinical trial database 60, which may include laboratory database interface 330 or otherwise interconnect with such laboratory database interface. In some embodiments, clinical trial database 60 may be included as part of PPS 40. Similarly, in some embodiments, clinical trial database 60 may be distributed across multiple databases and / or systems, whether internal or external to PPS 40.

[0028] Various components of the DCT system 10 can communicate via one or more communication networks or connections. These networks or connections can be implemented using wired communication components, wireless communication components, or combinations thereof, and can include various types of networks or interconnections, such as, for example, cellular networks, wide area networks (such as, for example, the Internet), and local area networks (such as, for example, Wi-Fi). ®Network), short-range wireless networks or connections (such as Bluetooth, for example). ® (Connection or near-field connection) or a combination thereof. It is understood that in some embodiments, one or more dedicated connections or communication channels may be used between one or more components of system 10.

[0029] For ease of description, Figure 1A The illustrated system 10 includes a single patient device 20. However, it should be understood that multiple participants using multiple different patient devices 20 can communicate with and access the functionality described herein with respect to system 10. Furthermore, in some embodiments, the functionality described herein as being performed via PPS 40 can be distributed across multiple devices, such as, for example, the functionality described herein can be distributed between PPS 40 and clinical trial database 60, distributed among multiple computing devices included in a cloud computing or other distributed environment, or a combination thereof. Additionally, in some embodiments, PPS 40 performs functionality other than that described herein.

[0030] Patient equipment 20 (such as Figure 2 The described patient device may include a computing device owned and / or operated by a patient 70 in a clinical trial, such as, for example, a smartphone, tablet computer, laptop computer, smart wearable device, etc. Patient device 20 may include multiple electrical and electronic components that provide power, operational control, and protection to components and modules within patient device 20. For example, such as... Figure 2 As illustrated, such a patient device 20 may include an electronic processor 102 (e.g., an electronic microprocessor, microcontroller, or similar device), a memory 104 (e.g., a non-transitory computer-readable storage device), and an input / output (I / O) interface 106. The patient device 20 also includes one or more human-machine interfaces 108, such as, for example, a touchscreen, display, keypad or keyboard, cursor control device, speaker, or combinations thereof. The human-machine interface 108 receives data from the patient 70 and provides data to the patient 70, for example, in an audible, textual, graphical, or combined form. Such a patient device 20 may include a camera 110, as described in more detail below, which allows the patient 70 to scan one or more codes. The patient device 20 may include additional or alternative components, including additional electronic processors and memory, or application-specific integrated circuits (ASICs), and one or more input devices, output devices, or combinations thereof.

[0031] The components of patient device 20 can be connected in various ways, including, for example, a local bus and / or an internal bus configured to connect various internal components of the patient device, such as electronic processor 102 and memory 104, to a motherboard. Electronic processor 102 is communicatively coupled to memory 104 and executes instructions stored on memory 104. Electronic processor 102 is configured to retrieve from memory 104 and execute instructions, etc., relating to the control processes and methods described herein. For example, memory 104 may include a program storage area and a data storage area, and electronic processor 102 is connected to memory 104 and executes computer-readable instructions (“software”) stored in random access memory (RAM), read-only memory (ROM), or another non-transitory computer-readable medium in memory 104. For example, as... Figure 2 As illustrated, memory 104 may store patient portal application 112, which communicates with PPS 40 when executed by electronic processor 102, and in some embodiments communicates with intermediate system 30 to access data and initiate communications within system 10. Patient portal application 112 may include firmware, one or more applications, program data, filters, rules, one or more program modules, other executable instructions, or combinations thereof, and in some embodiments, patient portal application 112 is configured, upon execution, to perform additional functionality beyond that described herein. Furthermore, as mentioned above, the functionality described herein as being performed via execution of patient portal application 112 may be distributed among multiple devices in the same or separate housings.

[0032] The input / output interface 106 of user equipment 102 can be configured to send data to and receive data from one or more devices, networks, or systems outside of patient equipment 20. For example, as illustrated in FIG1, patient equipment 20 (via input / output interface 106) is configured to communicate with PPS 40 and intermediate system 30 via one or more communication networks or connections. It should be understood that patient equipment 20 can communicate with PPS 40, intermediate system 30, or both via one or more intermediate devices (not shown).

[0033] like Figure 1A and Figure 1BAs depicted, data received from and / or provided to patient device 20 may include patient identification data 71, which includes any data that can be used to identify a patient, such as name, address, date of birth, and billing information. In at least one embodiment, such patient identification data 71 may include only such data reasonably necessary to deliver, for example, a supply kit to the patient, including but not limited to the patient's name and address. Similarly, patient device 20 may additionally receive and / or provide obfuscated patient data 72, which may include patient-related data, such as confidential or sensitive data, but which is obfuscated, encrypted, or otherwise disguised so that it may not be associated with a patient. In at least one embodiment, such obfuscated patient data 72 may be set in a non-human-readable format (whether including machine-readable formats or other formats). As will be understood, in some instances, such obfuscated patient data 72 may include patient identification data 71, but in an obfuscated form such that the patient identification data cannot be read by one or more systems (such as PPS 40). In at least one embodiment, such patient device 20 may further receive and / or provide key decoding data 73, which will be discussed in more detail below. In at least one embodiment, the patient device 20 is configured such that it does not directly store such identifying patient data 71 or such obfuscated patient data 72 in the memory 104 of the patient device.

[0034] Therefore, it is understood that when a patient inputs their data from patient device 20 into PPS 40, such data can be transformed into such obfuscated patient data 72 via encoding algorithm 80 before being input into PPS 40. In at least one embodiment (such as...) Figure 1B In the depicted embodiments, such an encoding algorithm 80 may be formed of two components: (a) an obfuscation protocol 81, which performs one or more obfuscation techniques on patient data; and (b) an encryption protocol 82, which applies one or more encryption techniques to patient data. For example, in at least one embodiment of the invention, patient device 20 may register with PPS 40 via a registration code 83, which may include, for example, a quick response (“QR”) code. Such a registration code 83 itself includes a shared key 84, which can be used to apply the aforementioned encoding algorithm to patient data. The generation and use of registration code 83 will be discussed in more detail below.

[0035] In doing so, the encoding algorithm 80 enables proper blinding of patient data across the various systems of the decentralized clinical trial system 10. For example, once the obfuscation protocol 81 and encryption protocol 82 are applied to patient device 20 (i.e., after patient device 20 is registered with PPS 40 via registration code 83 having a shared key 84), the shared key 84 of registration code 83 can be used by the aforementioned protocols to generate obfuscated patient data 72. Meanwhile, a private key 85 associated with such shared key 84 can be stored solely within intermediate database 31. When patient device 20 is used by patient 70 to perform various functions (e.g., ordering sample kits, which may be based on key decoding data 73 passed to patient device 20 via PPS 40, where such key decoding data 73 may include screening identifier 61, as discussed below), patient device 20 transmits the obfuscated patient data 72 to PPS 40, whereby the obfuscated patient data is then sent to intermediate database 31. There, the private key 85 can be applied to the obfuscated patient data 72 to identify the patient data 71. This patient identification data 71 can then be sent to the supply system 50 to fulfill the actions requested by the patient 70. Thus, PPS 40 enables the patient 70 to fulfill their requests without receiving, storing, or accessing the patient identification data 71, and to have visibility associated with those requests.

[0036] like Figure 1A As illustrated, and as discussed previously, PPS 40 can communicate with clinical trial database 60, whether the database is internally or externally configured in relation to the PPS. Clinical trial database 60 stores information defining clinical trials and multiple anonymous patients (such as patient 70) participating in those trials. For example, as... Figure 1AAs depicted in the illustrated embodiments, the clinical trial database 60 may store key-decoded data 73, which may include datasets without personally identifiable identifiers. This key-decoded data 73 may or may not carry information related to any particular patient and may include various study and / or trial-specific information, such as study timeline information, sample delivery and collection schedules, visit schedules, and other such information associated with the progress of the study and / or trial. In at least one embodiment, this key-decoded data 73 may additionally include a screening identifier 61 that identifies a related portion of the data, such as one or more specific patients within a given study and / or trial, without identifying the patient themselves. This screening identifier 61 may include, for example, a unique identifier associated with each patient. In at least one embodiment, such a screening identifier 61 may consist of a combination of two separate identifiers: (a) a study identifier 62, which may include an alphanumeric string used to identify the specific study and / or trial in question, and may be generated by the sponsor of the study and / or trial; and (b) a reference identifier 63, which may include a unique alphanumeric string automatically and / or randomly generated by the clinical trial database 60. Therefore, while there is no guarantee that the study identifier 62 itself is unique, its combination with the reference identifier 63 can form a unique screening identifier 61 that can be used to identify a specific patient in a specific study and / or trial. Therefore, it is understood that the clinical trial database 60 may not store or otherwise access any patient identification data 71, as will be discussed in more detail below.

[0037] Continue to refer to Figure 1A and Figure 1B As can be seen, PPS 40 can also communicate with intermediate system 30 to process supply orders (e.g., supplies or sample kits to be delivered to patient 70, samples collected from patient 70, etc.). In at least one embodiment of the invention, such intermediate system 30 may include intermediate database 31. In such embodiments, intermediate database 31 may include a built-in firewall system operated by the same entity as PPS 40 but different from PPS. Thus, intermediate database 31 can be configured to control access to data stored therein. Therefore, such intermediate system 30 is operable to prevent PPS 40 from accessing certain portions of the data, for example, via a private key 85 stored in the intermediate system, as previously discussed.

[0038] More specifically, such an intermediate system 30 (and more relevantly, its intermediate database 31) can be configured to store obfuscated patient data 72 provided by the patient from the patient device 20. For example, the obfuscated patient data 72 can be transferred from the patient device 20 to the intermediate database 31 via PPS 40. Furthermore, in at least one embodiment, such an intermediate database 31 can be additionally configured to store a private key 85, which can be used to decrypt the obfuscated patient data 72 and obtain the identified patient data 71. Such a private key 85 may be a corresponding portion of a registration code 83, and in particular its shared key 84, such that the private key 85 and the shared key 84 form a key pair. In doing so, it is understood that the intermediate system can act as a controller for patient data, allowing the intermediate system 30 to manage the subjects having access to the identified patient data 71 stored in the intermediate database 31, thereby maintaining blinding and other anonymity-based regulations applicable to patient data. In at least one embodiment (such as...) Figure 1B In the described implementation scheme, such registration code 83, shared key 84 and private key 85 can be generated according to the encoding algorithm 80 discussed earlier.

[0039] However, in at least one alternative embodiment envisioned herein, such intermediate system 30 and its intermediate database 31 may instead include a third-party system that separates patient data by storing patient identification data 71 (such as patient demographics and other patient identification information) of patient 70 separately from clinical trial database 60. For example, intermediate system 30 may maintain accounts associated with patient 70 and store account records in intermediate database 31, which include at least one of a group of data selected from patient 70, such as patient ID, study ID, their name, mailing address, email address, telephone number, date of birth, gender, or other similar demographic information. In at least one embodiment, the aforementioned data may be stored according to the aforementioned disclosure associated with the use of a pair of shared keys 84 and private keys 85, which operate to transform obfuscated patient data 72 transmitted via PPS 40 into patient identification data 71. In such embodiments, PPS 40 may be prevented from accessing accounts associated with patients operated by intermediate system 30. However, in an alternative implementation, the intermediate system 30 and / or intermediate database 31 may instead communicate directly with the PPS 40 in such a manner that the PPS 40 can access patient-associated accounts operated by the intermediate system 30, provided that the intermediate system 30 controls access to the identified patient data 71 in a manner in which the PPS 40 does not have visibility over the identified patient data 71 of the patient 70.

[0040] Therefore, since in alternative implementations the intermediate system 30 and / or intermediate database 31 may be owned and operated by the same entity providing PPS 40 or some other third party, it is understood that various information security mechanisms can be implemented to ensure the separation of patient identification data 70 from PPS 40 and clinical trial database 60. For example, firewalls can be used to control access to patient information. Stored patient information may also be encrypted, with access to the stored patient information in a decrypted form only accessible to authorized systems and software applications, as discussed previously. Audit functionality is also implemented to track access to the stored patient information, which may require compliance with regulatory requirements associated with clinical trials.

[0041] Further reference Figure 1A A supply order (e.g., kit and / or medication delivery) requested by patient 70 via PPS 40 is provided to intermediate system 30 before being subsequently passed to supply system 50. In doing so, intermediate system 30 (and in particular intermediate database 31) can receive the order request along with obfuscated patient data 72 and / or key-decoded data 73 from patient 70. Once received, intermediate database 31 can determine the relevant identifying patient data 71 to be passed to supply system 50, such as patient 70's name and address. And once such identifying patient data 71 is sent to supply system 50, supply system 50 can fulfill the order and ship the supply order to patient 70.

[0042] Alternatively, when patient 70 requests supply pickup (e.g., kit pickup) through PPS 40, PPS 40 provides the pickup request to intermediate system 30. Intermediate system 30 then provides pickup information and associated patient identification data 71 to supply system 50 (or, in some instances, to a courier service attached to supply system 50 or intermediate system 30). Supply system 50 or the courier service then picks up the kit from patient 70's home. PPS 40 communicates with patient 70, intermediate system 30, and supply system 50 via appropriate API 320, such as... Figure 3 The invention is described and discussed in more detail below. However, as will be understood by those skilled in the art, various alternative solutions for enabling communication between the PPS 40, the patient 70, the intermediate system 30, and / or the supply system 50 may be used in various embodiments of the invention.

[0043] As previously mentioned, PPS 40 can be implemented on one or more computing devices (e.g., one or more servers) and includes multiple hardware and software components. Figure 3Examples of software components 300 included in PPS 40 are illustrated. For instance, PPS 40 is configured to provide multiple user interfaces 302 to multiple user devices 304. For example, PPS 40 provides a patient user interface 306 to patient device 20, an intermediate user interface 308 to one or more intermediate devices 310 included in intermediate system 30 (and this intermediate user interface provides a site-level view of all data, such as identifying patient data 71, obfuscated patient data 72, registration code 83, and / or key decoding data 73), an internal user interface 312 to one or more internal user devices 314 of PPS 40, and a sponsor user interface 316 to one or more clinical trial sponsor devices 318. PPS 40 can provide the patient user interface 306 to patient device 20 via a patient portal application 112 installed on patient device 20. Such a patient portal application 112 can be configured for use with a variety of operating systems, such as, but not limited to, Microsoft Windows, Google Android, or Apple iOS. PPS 40 can provide an intermediate user interface 308, an internal user interface 312, and a sponsor user interface 316 respectively via a web browser installed on one or more intermediate devices 310, one or more internal user devices 314, and one or more clinical trial sponsor devices 318, or by other similar means as understood by those skilled in the art.

[0044] PPS 40 may also include multiple APIs 320 for exchanging data with multiple external systems 324. The multiple APIs 320 may include, for example, a third-party application integration framework 328, a laboratory database interface 330, an intermediate integration interface 332, and a supply system interface 334. The third-party application integration framework 328 enables patient device 20 to launch third-party applications (e.g., applications associated with intermediate system 30) from patient portal application 112 to communicate with those third-party applications. For example, the laboratory database interface 330 enables PPS 40 to exchange information with clinical trial database 60 to exchange information related to clinical trials (e.g., sample processing status, missing sample status, etc.). PPS 40 communicates with intermediate system 30 using intermediate integration interface 332 and with supply system 50 via supply system interface 334. Intermediate system 30 may communicate with supply system 50 via a component separate from PPS 40 (e.g., another API). In doing so, it is understood that patient 70 may directly provide patient identification data 71 to third-party applications without contaminating patient portal system 40. However, as previously discussed and as those skilled in the art will understand, this document envisions alternative methods for facilitating communication between multiple external systems 324.

[0045] PPS 40 may also include a user account management module 340 for controlling the registration of patients 70 to PPS 40 and managing patient profiles within the system (at least a portion of which PPS 40 is authorized to access and use). This user account management module 340 may include a user activation component 341 that enables patients 70 to register their patient devices 20. As will be understood, in at least one embodiment, this user activation component 341 may therefore be configured to facilitate the use of the coding algorithm 80 by the patient devices 20. Simultaneously, a maintenance component 342 may be configured to enable users to provide user-related roles and other maintenance-related operations for PPS 40.

[0046] PPS 40 may also include a patient workflow management module 350 and a supply order module 360. The patient workflow management module 350 provides the general functionality of the patient portal application 112. For example, the patient workflow management module 350 can provide patient 70 with research timeline information, notifications, reminders, past visit information, and patient profile information through the patient portal application 112. The patient workflow management module 350 can also receive input from patient 70 related to planned visits (e.g., kit pickup visits, kit delivery visits, or in-person visits) through the patient portal application 112. The patient workflow management module 350 can also interface patient 70 with researchers or the help desk.

[0047] Similarly, the patient workflow management module 350 can enable real-time collection of clinical sample data by providing one or more sample collection forms, which may include various prompts and / or questions indicating the clinical sample data to be collected. Such sample collection forms can be directly integrated with PPS 40 and / or the clinical trial database 60, allowing clinical sample data to be easily reviewed and verified in real time. Therefore, in at least one embodiment, such sample collection forms can be provided to the patient 70 via the patient portal application 112. In at least one embodiment, the patient workflow management module 350 can be interconnected with a system and / or database (whether including the clinical trial database 60 or otherwise) configured to generate such sample collection forms based on the details of the protocol of the clinical trial in question; however, it is understood that the generation of such sample collection forms by PPS 40 is contemplated herein.

[0048] In view of this, it is understood that the patient workflow management module 350 may include a variety of components configured to enable users involved in performing the clinical trial to manage all data, timelines, and other tasks associated with the clinical trial. For example, such a patient workflow management module may include: (a) a study setup component 351 configured to enable users to configure appropriate settings to align with a given clinical trial; (b) a visit setup component 352 configured to enable users to configure patient visits at clinical trial sites; (c) a patient data input component 353 configured to enable users to input various patient data related to the clinical trial; (d) a sample data input component 354 configured to enable users to input sample collection data; (e) a configuration component 355 configured to enable users to configure and customize their settings; (f) a timeline management component 356 configured to enable users to access, review, and change information related to the trial's timeline; (g) an event notification component 357 configured to enable users to review and apply notifications for various clinical trial events; and (h) a help desk component 358 configured to enable users to utilize the help desk or the DCT-assisted system 10 and / or PPS. 40 is operated by another similar operator and / or the patient 70 is connected to the help desk or that other similar operator.

[0049] Continue to refer to Figure 3 The supply order module 360 ​​of PPS 40 is configured to receive and manage supply delivery orders and supply collection orders from patient 70. For example, the supply order module 360 ​​receives a request from patient 70 for a supply kit to be delivered and provides delivery request information to intermediate system 30 and supply system 50, such as via order supply component 361, to fulfill the request. The supply order module 360 ​​may also provide delivery request information to researcher devices (e.g., internal user device 314) for review and approval of the request. Similarly, the supply order module 360 ​​(e.g., after samples have been collected by patient 70) receives a request from patient 70 for a supply kit to be collected and provides collection request information to intermediate system 30 and supply system 50, such as via delivery collection component 362, to fulfill the request. PPS 40 also includes a patient portal application database 370 for storing patient portal application information (e.g., for interfacing with patient device 20 via patient portal application 112). In at least one embodiment of the invention, such a supply system 50 may be configured to include, in addition to a variety of express and other shipping and / or postal service providers worldwide, one or more suppliers configured to fulfill requests.

[0050] Figure 4This is a flowchart of a patient portal application workflow method 400 according to at least one implementation. In one example, method 400 is implemented using components of PPS 40 (such as, for example, user account management module 340, patient workflow management module 350, and supply order module 360). The following continues with reference to Figures 1 through 2. Figure 3 To describe method 400.

[0051] Method 400 includes PPS 40 receiving a registration request from patient 70 for registering patient device 20 (in box 402). In one embodiment, patient 70 registers patient device 20 via registration code 83. In at least one embodiment, such registration code may include a quick response (“QR”) code, or alternatively a barcode, which can be scanned by camera 110 of patient device 20. Such registration code 83 may be associated with a specific clinical trial enrolled by patient 70 and, as discussed previously, may include a shared key 84 configured to enable the application of encoding algorithm 80 to data provided by patient 70. For example, when a patient (or the patient’s physician or trial researcher) wishes to enroll in a clinical trial, the researcher may request a spot in the clinical trial via one or more systems or software applications (e.g., by entering or generating screening identifiers, study identifiers, and reference identifiers to register the patient to PPS 40 and / or some other interconnected laboratory data portal, which represents an external portal for clients and sites to view and manage research data in real time). Upon receiving such a request, PPS 40 may generate a registration code 83 via, for example, account management module 340 and / or encoding algorithm 80. In response to receiving approval, the researcher provides the registration code 83 to the patient 70 (whether in physical, tangible form, or via electronic means such as text or email), wherein such registration code 83 is unique to the patient 70 and the specific clinical trial the patient 70 intends to enroll in. Therefore, the registration code 83 can be provided to the patient 70 without requiring a physical visit to the site (whether the researcher's site managing the patient 70's treatment or otherwise). The registration code 83 may be provided with additional instructions, including instructions for downloading the patient portal application 112 as described below.

[0052] Patient 70 can use registration code 83 to register his or her user device with PPS 40 and access the user interface described herein for purposes such as ordering kits, scheduling sample collection and pickup. For example, as previously discussed, registration code 83 and its shared key 84 enable patient 70 to provide obfuscated patient data 72 to PPS 40, which can then send any relevant information to intermediate system 30 and / or intermediate database 31 for further actions related to that information. When patient 70 registers their patient device 20 via registration code 83, registration code 83 and its shared key 84 can be stored in intermediate database 31 along with the associated private key 85. In doing so, intermediate database 31 thus gains access to the identifier patient data 71 derived from obfuscated patient data 72 sent from PPS 40 to the intermediate database. Therefore, intermediate system 30 and / or intermediate database 31 can use such identified patient data 71 (such as their name and address) to achieve kit delivery and distribution for a specific clinical trial without providing the PPS 40 and / or clinical trial database 60 with the patient 70's identifying patient data 71. As will be understood, in some embodiments, patient 70 may not communicate directly with intermediate system 30 and / or intermediate database 31; however, in alternative embodiments, it is anticipated that patient 70 may communicate directly with intermediate system 30 and / or intermediate database 31 via some authentication scheme (such as a single sign-on program). In instances where patient 70 (whether at the same time or at different times) participates in two or more clinical trials, such patient 70 will receive two or more registration codes 83 to be applied to their data. In doing so, the identified patient data 71, obfuscated patient data 72, and key-decoded data 73 associated with such patient 70 may be appropriately segmented for each trial in which patient 70 participates.

[0053] In at least one alternative implementation, patient 70 can register patient device 20 with PPS 40 by downloading patient portal application 112 to device 20 (if not already downloaded) and scanning the received registration code 83 within the application. Upon receiving registration code 83, patient portal application 112 identifies at least one unique device identifier for patient device 20 (e.g., a machine or hardware identifier or code, such as a Media Access Control (MAC) address and / or Internet Protocol (IP) address) and records this unique device identifier to PPS 40. PPS 40 can record such a device identifier for patient device 20 along with the associated registration code 83. In doing so, it is understood that the unique device identifier for patient device 20 can be used similarly to a shared key 84, such that the unique device identifier is linked to a private key 85 stored in intermediate database 31. In other words, instead of creating a standard user account or profile for patient 70 (which would require requesting identification information, contact information, login information, etc. via application 112), PPS 40 can use the unique device identifier of patient device 20 as the registration link between device 20 and PPS 40. Each time the patient portal application 112 installed on device 20 communicates with PPS 40, the portal application 112 provides PPS 40 with a unique device identifier for subsequent transmission to intermediate database 31. Therefore, patient identification data 71 is never received or maintained by PPS 40 (or patient portal application 112), ensuring regulatory compliance; instead, PPS 40 only receives and transmits obfuscated patient data 72. In some implementations, instead of providing a unique hardware code or address to identify patient device 20, patient portal application 112 may generate a unique device identifier for device 20 (e.g., based on a unique hardware or software code or address associated with device 20), further obfuscating the connection between patient device 20 and a specific patient 70.

[0054] Continue to refer to Figure 4 After registering patient device 20, PPS 40 provides a patient dashboard user interface (in box 404) to patient device 20 via patient portal application 112. The patient dashboard user interface provides research timeline information, such as a list and summary of previous and future visits. The patient dashboard user interface may also provide alerts or notifications related to pending action items (e.g., missing samples), upcoming sample collection deadlines, or upcoming deliveries. The patient dashboard user interface may additionally interface patient 70 with a help desk or researcher, such as through the patient workflow management module 350 of PPS 40. The information provided through patient portal application 112 is unique to patient 70 (e.g., only information about the clinical trial the patient is enrolled in is provided).

[0055] Method 400 also includes PPS 40 receiving order information associated with a requested kit order from patient 70 via patient portal application 112 (in box 406). In response to receiving the order information, PPS 40 communicates with intermediate system 30 and supply system 50 to fulfill the requested order (in box 408). For example, PPS 40 may provide intermediate system 30 with order information (e.g., an identifier for a specific type of kit) and a patient ID corresponding to patient 70 (e.g., obfuscated patient data 72 and / or key-decoded data 73). Intermediate system 30 may then determine and provide patient data 71 (such as patient 70's name, mailing address) and order information to supply system 50 to arrange delivery of the requested kit. However, patient data 71 (such as patient 70's mailing address) is never stored by PPS 40, but is instead passed through as obfuscated patient data 72.

[0056] Method 400 also includes receiving a kit collection request from patient 70 via patient portal application 112 (in box 410). In response to receiving the kit collection request, PPS 40 provides instructions regarding sample collection via application 112 and provides an electronic application (“e-application”) form. PPS 40 communicates with intermediate system 30 and supply system 50 to schedule kit collection by providing, for example, a patient ID and an e-application form to intermediate system 30 and / or supply system 50 (in box 412). In some cases, intermediate system 30 provides kit collection instructions to a courier service attached to intermediate system 30. After the kit is collected by supply system 50 or the courier service, the kit is delivered to the laboratory, making it possible to process the sample collected by patient 70.

[0057] Figure 4 The described method 400 may additionally include PPS 40 receiving a request from patient 70 to launch a third-party application from patient portal application 112 (in box 414). As previously discussed, the third-party application may be another application besides patient portal application 112 used in a decentralized clinical trial environment. For example, the third-party application may be an application associated with intermediate system 30. In response to receiving the request to launch the third-party application, PPS 40 uses, for example, PPS 40's third-party application integration framework 328 to launch the third-party application (in box 416). Such third-party applications may include a variety of systems, including applications for managing patient dosing and / or delivery, document repository applications, applications configured for scheduling appointments with physicians and / or clinical trial sites, and other similar applications typically associated with clinical trials.

[0058] Figure 5This is a flowchart of a patient portal registration method 500 according to at least one implementation. In the depicted example, method 500 is implemented using components of PPS 40 (such as user account management module 340). Reference continues below to Figures 1 through 2. Figure 3 Let's describe method 500.

[0059] Method 500 includes receiving a new patient registration request for patient 70 from an intermediate device (e.g., from a researcher) (in box 504). The new patient registration request includes, for example, the screening ID of patient 70. In some cases, the new patient registration request also includes the patient's year of birth, the patient's date of birth, and / or the patient's gender. Method 500 may also include receiving a request to re-register patient 70, for example, if patient device 20 has been changed (in box 506). In response to receiving a registration or re-registration request, PPS 40 generates one or more registration codes 83, such as one or more QR codes, one or more barcodes, or another scannable code, as described above (in box 508). One or more registration codes 83 may be printed and provided to patient 70, or provided to intermediate system 30 and provided to patient 70 electronically (e.g., via text or email). In some implementations, PPS 40 generates a first registration code 83 or application installation code (in box 512) representing the first key decoding data 73, enabling patient 70 to install the patient portal application 112 on patient device 20, and generates a second registration code 83 or trial code (in box 514) representing the second key decoding data 73, enabling patient 70 to register for a specific clinical trial in patient portal application 112. PPS 40 can register patient 70 by generating a shared key 84 for patient 70 within a clinical trial. As described above, the shared key 84 can be used to apply the encoding algorithm 80 to data provided by patient 70, preventing PPS 40 from storing or accessing any identifying patient data 71. In some implementations, intermediate system 30 also receives a unique device identifier (in box 516) and uses the device identifier or a different unique identifier for patient 70 and / or patient device 20 as the shared key 84 with PPS 40.

[0060] Figure 6 This is a flowchart of a supply order method 600 according to one implementation scheme. In one example, method 600 is implemented using components of PPS40 (e.g., supply order module 360). Refer further to Figures 1 through 2 below. Figure 3 To describe method 600.

[0061] Method 600 includes receiving a request from patient 70 for access to research or visit information via patient portal application 112 (in box 604). PPS 40 may provide patient device 20 with a user interface that includes, for example, a list of action items such as scheduling a visit for sample delivery, placing an order, or scheduling sample collection. As mentioned above, the information provided may be unique to both patient 70 and the clinical trial enrolled by patient 70. For example, PPS 40 may provide sample collection information including an identifier for a specific supply kit that can be ordered by patient 70. In at least one embodiment, information related to the supply kit required by the patient may be automatically populated, and an order supply management component, such as through supply order module 360, may be added to the order within patient portal application 112. In such embodiments, the supply kit may require verification and / or approval by the patient's physician and / or trial investigator before the patient can order the supply kit automatically populated in patient portal application 112. Therefore, while PPS 40 provides a universal user interface for ordering various types of kits, errors may be introduced if a patient does not order the correct kit for their specific clinical trial or orders a kit or provides samples in a manner inconsistent with the trial timeline. Therefore, by using key-decoded data 73 as described herein, PPS 40 can identify what specific kit, collection, etc., is provided to the patient 70 within application 112 and communicate it to the intermediate system 30 without obtaining access to the identified patient data 71.

[0062] Method 600 also includes receiving a selection of a supply kit and / or a specific supply item from the patient 70 via a patient portal application 112 (in box 608). For example, the patient 70 may select a single item that can be included in the supply kit. PPS 40 may provide this notification, for example, to a device included in intermediate system 30 via intermediate user interface 308 to provide a notification for approving the selection. In response to receiving approval of the selection from intermediate system 30 (in box 612), PPS 40 generates an order request for the selected kit and / or specific item and sends an instruction to intermediate system 30 via intermediate integration interface 332 to initiate the delivery of the selected supply kit (in box 616). After transmitting the order request to intermediate system 30, PPS 40 may receive a response from intermediate system 30 confirming that the order request has been received and that intermediate system 30 has placed an order with supply system 50 (in box 620). The order placed with supply system 50 includes patient details required for placing the supply order, such as patient name and address. PPS 40 can receive confirmation from intermediate system 30 that supply system 50 has received the order (in box 624). After the order is shipped to patient 70 by supply system 50, PPS 40 can also receive a shipping confirmation from intermediate system 30 (in box 628). PPS 40 can also provide order status information to patient device 20 during the ordering process (in box 634). For example, using patient portal application 112, patient 70 can view the order processing status and / or shipping status. Shipping status may include the expected delivery date or other tracking information, such as information provided by a third-party courier service. For example, intermediate system 30 can receive tracking information from supply system 50 and provide tracking information to patient 70, for example, through a third-party application.

[0063] Figure 7 This is a flowchart of a sample kit collection method 700 according to one implementation scheme. In one example, method 700 is implemented using components of PPS 40 (e.g., supply order module 360). Refer further to Figures 1 through 2 below. Figure 3 Let's describe method 700.

[0064] Method 700 includes receiving a request from patient 70 via patient portal application 112 to access research or visit information (in box 704). PPS 40 may provide patient device 20 with a user interface that includes, for example, a list of action items such as placing an order, scheduling a visit for kit delivery, or scheduling kit pickup. In response to receiving a selection for kit delivery or kit pickup from patient device 20 (in box 708), PPS 40 provides patient 70 with an e-request form via patient portal application 112 (in box 712). Patient 70 may provide the sample kit ID associated with the sample kit, the scheduled pickup date, or the scheduled pickup time on the e-request form. PPS 40 may further provide sample collection instructions to patient 70 via patient portal application 112. If, at box 708, patient 70 selects to deliver the sample kit, patient 70 delivers the sample kit at a delivery location (such as, for example, a courier service or supply system 50) (in box 714). If patient 70 selects sample kit pickup at box 708, PPS 40 generates a sample kit pickup request and transmits it to intermediate system 30 (in box 716). The sample kit pickup request includes, for example, patient ID, application ID, pickup ID, e-application form, and / or a subset of information included in the e-application form. Intermediate system 30 may provide PPS 40 with confirmation of receipt of the request and a pickup order with the patient's name and address under supply system 50 or courier service (in box 720). When the kit pickup order is received by courier service or supply system 50, PPS 40 may receive confirmation from courier service or supply system 50 via supply system interface 334 and / or intermediate system 30 (in box 724). When courier service or supply system 50 has picked up the kit from the patient's home, PPS 40 may receive confirmation from courier service or supply system 50 via supply system interface 334 and / or intermediate system 30 (in box 724). PPS 40 can provide kit collection status information to patient device 20 during the kit collection process (in box 734). For example, PPS 40 can provide patient device 20 with one or more notifications, including the expected collection date of the sample kit.

[0065] Figure 8 This is a flowchart of an electronic application method 800 according to one implementation scheme. In one example, method 800 is implemented using components of PPS40 (e.g., supply order module 360). Refer further to Figures 1 through 2 below. Figure 3 Let's describe method 800.

[0066] Method 800 includes receiving a request from patient 70 via patient portal application 112 to access research or visit information (in box 804). PPS 40 may provide patient device 20 with a user interface including, for example, a list of action items such as placing an order, scheduling a visit for kit delivery, or scheduling kit pickup. In response to receiving a selection for kit delivery or kit pickup from patient device 20 (in box 708), PPS 40 prompts patient 70 to enter clinical trial information associated with patient 70 (e.g., clinical trial ID, patient ID, kit ID associated with the sample kit to be picked up, etc.) (in box 808) and provides an application form user interface to patient device 20. Using camera 110 and patient portal application 112, patient 70 scans a barcode included in the sample kit to be picked up, and PPS 40 receives the scanned barcode data based on the scanned barcode (in box 812). Based on the scanned barcode data, PPS 40 can determine whether the barcode was generated by PPS 40 (e.g., whether it is included in the clinical trial database 60). If the barcode is a PPS-generated barcode, PPS 40 determines the sample name based on the scanned barcode data and records the sample collection date and time, as well as the sample name, as application information (in box 820). If the barcode is not a PPS-generated barcode, PPS 40 prompts the patient 70 (e.g., from a drop-down menu, using a text input field, etc.) to select a sample name and records the sample collection date and time, as well as the sample name, as e-application information (in box 822). The e-application information may also include the scanned barcode data. PPS 40 may prompt the patient 70 to review and submit the e-application information. After PPS 40 receives the e-application information from patient 70 via patient portal application 112 (in box 824), PPS 40 generates an application ID and registers the sample entry data in clinical trial database 60 based on the e-application information and the application ID (in box 830).

[0067] Figures 9A to 9P Multiple screens 900, i.e., graphical user interfaces, provided by the patient user interface 306 of the patient portal application 112 on the patient device 20 are depicted. Therefore, the various screens 900 of the patient user interface 306 are used to display relevant information to and receive relevant information from the patient 70.

[0068] For example, Figures 9A to 9D Depicting the process during registration (such as in Figure 5 The various screens 900 displayed during the described method 500. For example, in Figure 9AIn the middle, screen 900a includes a prompt that informs patient 70 of the applicable steps for registering patient device 20 with PPS 40. Such a prompt may instruct patient 70, depending on whether patient 70 already has an account for the clinical trial in question, to select either scan code button 902 or skip button 904. Pressing scan code button 902 will cause... Figure 9B The screen 900b shown displays an image capture area 906 to assist patient 70 in scanning registration code 83. Once registration code 83 is scanned by patient device 20 and sent to PPS 40, it can be displayed... Figure 9C The depicted screen 900c displays multiple registration fields 908 to the patient 70. These multiple registration fields 908 may include data fields into which the patient 70 may enter data, such as, but not limited to, an applicable screening ID, the patient 70's email address, and the patient 70's account password. In at least one embodiment, when scanning the registration code 83, the registration field 908 pointing to the applicable screening ID may be automatically entered by the patient portal application 112. Once the patient 70 has completed the multiple registration fields 908, the patient 70 may be directed to… Figure 9D The depicted screen 900d allows the patient 70 to input certain identifying patient data 71, i.e., their address, through multiple address fields 912 available on it. Once entered, the patient 70 can then select the save button 912 to complete the initial device registration process.

[0069] same, Figures 9E to 9F Various screens 900 displayed by the patient portal application 112 are depicted, enabling patients 70 to add studies and / or trials to their accounts and / or select studies and / or trials from their accounts. For example, Figure 9E The depicted screen 900e may include a screening ID field 914 through which a user can enter an applicable screening identifier 61 associated with a specific study and / or trial. In at least one embodiment, such a screening ID field 914 may be automatically entered by the patient portal application 112 when the registration code 83 is initially scanned by the patient device 20. Once the screening identifier 61 has been entered by the patient 70, the patient can use the save button 916 to add the associated study and / or trial to their account. In contrast, Figure 9F The depicted screen 900f can be displayed by a patient portal application 112 to enable patient 70 to select specific studies and / or trials for which they wish to perform various functions. Therefore, such a screen 900f may include a study sidebar 918 with one or more selectable fields, each of which directs patient 70 to different studies and / or trials they are currently participating in.

[0070] Similarly, Figures 9G to 9P Various screens 900, shown by the patient portal application 112, are depicted, enabling the patient 70 to, for example, […]. Figure 7 Method 700 performs various functions related to any research and / or trial during the process. For example, Figure 9G Screen 900g is shown, which may include a main screen for a specific study and / or trial, through which patient 70 can be guided to the appropriate screens 900 and / or forms required to complete various functions. As can be seen, such screen 900g may include: (a) an order button 920, through which patient 70 can order sample kits; (b) a submit button 922, through which patient 70 can submit a sample collection form; (c) a schedule button 926, through which patient 70 can schedule the date and / or time for sample collection; and (d) a confirm button 928, through which patient 70 can provide confirmation of sample collection. Such screen 900g may also include a taskbar 924, which itself may include buttons enabling patient 70 to schedule visits to specific sites or otherwise request assistance, whether related to the study and / or trial or the patient portal application 112 itself. When the order button 920 is selected on the screen 900g depicted in Figure G, a screen 900h can be displayed to the patient 70, through which the patient 70 can perform actions related to ordering the sample kit. For example, the screen 900h may include one or more visit order selection fields 930, which allow the patient 70 to select the type of visit for which the sample kit is required.

[0071] On the other hand, Figure 9G Selecting the "Submit 922" button on the screen displayed in the middle (900g) can cause... Figures 9I to 9N The display on screen 900, as shown, collectively depicts the sample collection form provided by the patient workflow management module 350 of the PPS 40, and therefore includes various prompts and / or questions indicating the clinical sample data to be collected. For example, Figure 9I The screen 900i may first display one or more visit collection selection fields 932, through which the patient 70 can input the visit type in question for sample collection. Once the appropriate visit type is selected from the visit collection selection fields 932, it can be displayed to the patient 70. Figure 9J The screen 900j. As can be seen, such a screen 900j may include a confirmation window 934, through which the patient 70 is prompted to provide confirmation that they have selected the correct visit from the visit collection selection field 932.

[0072] Once confirmed, it can be shown to the patient at 70. Figure 9KThe screen 900k. As understood, the screen 900k may display different information and may include alternative questions and / or prompts, depending on the selected visit and / or the study / experiment under discussion. Figure 9K In the depicted implementation, screen 900k includes a clinical details field 936 through which patient 70 can input requested information in various ways (including selectable buttons, populateable data fields, or other methods). Such screen 900k may also include a change-of-visit button 938 that allows the user to return to... Figure 9I The depicted screen 900i allows selection of different visits from the visit collection selection field 932. Once the appropriate information is entered into the clinical details field 936, the patient 70 can use the sample details button 940 to proceed to the next visit. Figures 9L to 9M The screens 900l and 900m are shown. These screens 900l and 900m may include a sample details screen through which the patient 70 can input information related to the sample itself. In at least one embodiment, such a screen 900l may display a sample scan button 942, through which the patient 70 can scan an applicable barcode from the sample collection device. Similarly, alternatives... Figure 9L The screen 900l or as a supplement to display to the patient 70 Figure 9M The screen 900m is used to input additional information related to the sample to be collected. For example, such a screen 900m may include a sample date field 948, in which the patient can enter the date and / or time the sample was collected. In at least one embodiment, the sample date field 948 can be automatically entered when an applicable barcode from the sample collection device is scanned using the sample scan button 942. Similarly, such a screen 900m may additionally include a sample identification field 950, through which the patient 70 can identify the type of sample collected (whether via selectable options, a populateable data field, or otherwise). As can be seen, the patient 70 can use the clinical details button 944 and the review form button 946 to return to the previous form or proceed to the subsequent form, respectively.

[0073] When the review form button 946 is pressed, it can be displayed to patient 70. Figure 9NAs shown on screen 900n, patient 70 can review all information submitted via previous screens 900i-900m. Therefore, such screen 900n may include a completed form field 952 displaying all information and / or data selected or otherwise submitted by patient 70 in conjunction with the current sample collection request. In at least one embodiment, the completed form field 952 may be locked, preventing patient 70 from directly making any changes to the information displayed therefrom. While reviewing the completed form field 952, patient 70 can use the sample details button 956 to return to the previous screen to correct any information, or otherwise use the submit button 958 to complete the sample collection request.

[0074] Figure 9O and Figure 9P Screen 900o depicts the date and time used to plan sample collection (as can be seen from...) Figure 9G The depicted screen 900g shows the plan button 926 (accessible from) and the screen 900p for providing confirmation of sample collection (as can be seen from) Figure 9G The screen 900g shown in the image is accessed via the confirmation button 928. (As depicted on the screen 900g). Figure 9O As can be seen, such a screen 900o may include a sample collection field 960 through which the patient 70 selects the date on which they wish to retrieve a given sample. In at least one embodiment, such a sample collection field 960 may include a date picker or some other widget that enables selection of a date from a calendar view. As may be noted, other fields in the various screens 900o discussed previously (such as...) Figure 9M The sample date field 948 shown on the depicted screen 900m can also perform the same date selection function using a similar date selector or a similar widget. Once a date is selected, the screen 900o can be configured to display a date confirmation window 962, which provides the patient 70 with confirmation information about the selected date for sample collection. Figure 9P The depicted screen 900p can be used to confirm sample collection after collection. Therefore, such a screen 900p may include one or more visit confirmation selection fields 964, which enable the patient 70 to easily confirm that the sample required for a given visit has been collected. Finally, it can be seen that... Figures 9H to 9P The various screens 900h-900p may each include a help button 966, through which the patient 70 can receive assistance related to research and / or trials or the patient portal application 112, as discussed previously.

[0075] Finally, as mentioned above, PPS 40 can be implemented by one or more computing devices. Figure 10 is a block diagram of a computing device 1000 that performs some or all of the scientific instrument support functions and / or methods disclosed herein, according to various embodiments. In some embodiments, PPS 40 can be implemented by a single computing device 1000 or by multiple computing devices 1000. Furthermore, as discussed below, the computing device 1000 (or multiple computing devices 1000) implementing PPS 40 can be part of one or more of a user local computing device, a service local computing device, or a remote computing device.

[0076] The computing device 1000 of Figure 10 is illustrated as having multiple components, but any one or more of these components may be omitted or repeated depending on their suitability for the application and setup. In some embodiments, some or all of the components included in the computing device 1000 may be attached to one or more motherboards and encapsulated in a housing (e.g., including plastic, metal, and / or other materials). In some embodiments, some of these components may be fabricated onto a single system-on-a-chip (SoC) (e.g., the SoC may include one or more processing devices 1002 and one or more storage devices 1004). Additionally, in various embodiments, the computing device 1000 may not include one or more of the components illustrated in Figure 10, but may include interface circuitry (not explicitly illustrated) for coupling to one or more components using any suitable interface (e.g., a Universal Serial Bus (USB) interface, a High Definition Multimedia Interface (HDMI) interface, a Controller Area Network (CAN) interface, a Serial Peripheral Interface (SPI) interface, an Ethernet interface, a wireless interface, or any other suitable interface).

[0077] Computing device 1000 may include processing device 1002 (e.g., one or more processing devices). As used herein, the term "processing device" may refer to any device or part of a device that processes electronic data from registers and / or memory to transform that electronic data into other electronic data that can be stored in registers and / or memory. Processing device 1002 may include one or more digital signal processors (DSPs), application-specific integrated circuits (ASICs), central processing units (CPUs), graphics processing units (GPUs), cryptographic processors (dedicated processors that execute cryptographic algorithms within hardware), server processors, or any other suitable processing device.

[0078] Computing device 1000 may include storage device 1004 (e.g., one or more storage devices). Storage device 1004 may include one or more memory devices, such as random access memory (RAM) devices (e.g., static RAM (SRAM) devices, magnetic RAM (MRAM) devices, dynamic RAM (DRAM) devices, resistive RAM (RRAM) devices, or conductive bridged RAM (CBRAM) devices), hard disk drive-based memory devices, solid-state memory devices, network drives, cloud drives, or any combination of memory devices. In some embodiments, storage device 1004 may include memory sharing a die with processing device 1002. In such embodiments, the memory may be used as cache memory and may include, for example, embedded dynamic random access memory (eDRAM) or spin-transfer torque magnetic random access memory (STT-MRAM). In some embodiments, storage device 1004 may include a non-transitory computer-readable medium having instructions on which, when executed by one or more processing devices (e.g., processing device 1002), cause computing device 1000 to perform any suitable method or portion thereof disclosed herein. Storage device 1004 can store the above references. Figure 3 The PPS 40 software components 300 described herein.

[0079] Computing device 1000 may include interface device 1006 (e.g., one or more interface devices 6006). Interface device 1006 may include one or more communication chips, connectors, and / or other hardware and software to manage communication between computing device 1000 and other computing devices. For example, interface device 1006 may include circuitry for managing wireless communication used to transmit data to and from computing device 1000. The term "wireless" and its derivatives can be used to describe circuits, devices, systems, methods, techniques, communication channels, etc., that can transmit data through a non-solid medium using modulated electromagnetic radiation. This term does not imply that the associated device does not contain any wires, although in some embodiments it may not contain any wires. The circuitry included in interface device 1006 for managing wireless communications can implement any of a number of wireless standards or protocols, including but not limited to Institute of Electrical and Electronics Engineers (IEEE) standards, including Wi-Fi (IEEE 802.11 series), IEEE 802.16 standards (e.g., IEEE 802.16-2005 amendments), Long Term Evolution (LTE) projects, and any amendments, updates, and / or revisions (e.g., Advanced LTE projects, Ultra Mobile Broadband (UMB) projects (also known as “3GPP2”), etc.). In some implementations, the circuitry included in interface device 1006 for managing wireless communications can operate according to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed ​​Packet Access (HSPA), Evolved HSPA (E-HSPA), or LTE networks. In some embodiments, the circuitry included in interface device 1006 for managing wireless communications may operate according to Enhanced Data GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). In some embodiments, the circuitry included in interface device 7006 for managing wireless communications may operate according to Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Telecommunications (DECT), Evolved Data Optimization (EV-DO), and their derivative protocols, as well as any other wireless protocols designated as 3G, 4G, 5G, and higher versions. In some embodiments, interface device 1006 may include one or more antennas (e.g., one or more antenna arrays) for receiving and / or transmitting wireless communications.

[0080] In light of the foregoing, it is understood that the various embodiments of this disclosure are configured to address a number of problems in the art related to existing online ordering technologies in decentralized clinical trial environments. Specifically, the various systems and processes disclosed herein collectively enable anonymity-based data control solutions between various systems and databases in clinical trials, while allowing patients to receive medications and other trial-related kits to be delivered and / or collected from their residences, thereby facilitating increased trial complexity while reducing patient burden.

Claims

1. A method for protecting personal patient information in decentralized clinical trials, the method comprising: A patient portal application is registered on at least one user device via a registration code, the registration code including a shared key configured to generate obfuscated patient data for transmission to a patient portal system via at least one server, the patient portal system being configured to communicatively connect to an intermediate system having an intermediate database and a clinical trial database. The user device receives sample collection information from the server, the sample collection information including an identifier of a supply kit that can be ordered by at least one patient participating in the clinical trial; The sample collection information is provided on the user device within the user interface of the patient portal application; At the patient portal system, the obfuscated patient data related to the provided sample collection information is received from the user device. The obfuscated patient data is sent from the patient portal system to the intermediate database, which includes a private key configured to access patient data identified from the obfuscated patient data. as well as The identified patient data is sent from the intermediate database to at least one supply system configured to fulfill orders related to the sample collection information.

2. The method of claim 1, wherein the registration code includes a Quick Response (QR) code.

3. The method of claim 1, wherein the shared key of the registration code is generated using an obfuscation protocol and an encryption protocol to generate the obfuscated patient data.

4. The method of claim 1, wherein the obfuscated patient data is configured in a non-human readable format.

5. The method of claim 1, wherein the obfuscated patient data is configured in a manner that prevents it from being read by the patient portal system.

6. The method of claim 1, wherein the identified patient data sent from the intermediate database to the at least one supply system includes the name and address of the at least one patient.

7. The method of claim 1, further comprising receiving at least one notification from the server at the user equipment, the at least one notification relating to a sample collection period.

8. A method for protecting personal patient information in decentralized clinical trials, the method comprising: The patient portal system is configured to communicate with the clinical trial database, intermediate database, and at least one user device via at least one server; Key-decoded data associated with at least one patient is stored in the clinical trial database; The at least one user device is registered with the patient portal system via a patient portal application set up on the at least one user device, the registration being accomplished by at least one registration code provided to the at least one patient. The patient portal application receives data related to the at least one patient and generates obfuscated patient data from the data according to an encoding algorithm; The obfuscated patient data is sent to the intermediate database via the patient portal system. The intermediate database has at least one private key stored therein, which is configured to access identified patient data from the obfuscated patient data. as well as The obfuscated patient data is sent from the intermediate database to at least one supply system configured to communicatively connect to the intermediate database.

9. The method of claim 8, wherein the at least one registration code includes a shared key linked to the private key, the shared key being configured to apply the encoding algorithm to generate the obfuscated patient data.

10. The method of claim 9, wherein the encoding algorithm includes an obfuscation protocol configured to apply at least one obfuscation technique to the data associated with the at least one patient, and an encryption protocol configured to apply at least one encryption technique to the data associated with the at least one patient.

11. The method of claim 8, wherein the intermediate database is located within an intermediate system, the intermediate system including a built-in firewall system different from the patient portal system and the clinical trial database.

12. The method of claim 8, wherein the intermediate database is located within an intermediate system, the intermediate system including a third-party system.

13. A system for controlling data access to patients' personal information in decentralized clinical trials, the system comprising: A patient portal system configured to communicatively connect to at least one patient device, a clinical trial database, and at least one intermediate database; The at least one patient device includes a processor configured to communicatively connect to a memory to provide input / output communication with the patient portal system to the patient via a patient portal application located on the at least one user device; The at least one patient device is configured to receive at least one registration code, which is configured to enable access to the patient portal application by the at least one patient device for inputting patient identification data in the patient portal application; The registration code is configured to apply an encoding algorithm to the identified patient data via a shared key, the encoding algorithm being configured to transform the identified patient data into obfuscated patient data and key-decoded data; The patient portal system is configured to receive the obfuscated patient data and the key-decoded data from the at least one patient device via the patient portal application; The patient portal system is configured to provide the key-decoded data to the clinical trial database; The patient portal system is configured to provide the obfuscated patient data to the intermediate database; The intermediate database is configured to apply a private key stored therein to the obfuscated patient data to access the identified patient data from the obfuscated patient data; and The intermediate database is configured to transmit the identified patient data to the supply system, which is configured to communicatively connect to the intermediate database.

14. The system of claim 13, wherein the registration code includes a quick response code.

15. The system of claim 13, wherein the patient identification data includes the patient's name and address.

16. The system of claim 13, wherein the obfuscated patient data is configured in a format that cannot be read by the patient portal system.

17. The system of claim 13, wherein the intermediate database includes a built-in firewall system operated by the same entity as the patient portal system.

18. The system according to claim 13, wherein: The patient portal system is further configured to receive order information from the at least one patient device and provide the order information to the intermediate database; The intermediate database is further configured to provide the order information to the supply system; and The supply system is configured to fulfill the order information based on the identified patient data.

19. The system of claim 13, wherein the patient portal system comprises a patient workflow management module, a supply order module, a user account management module, and an application programming interface.

20. The system of claim 19, wherein the patient workflow management module is configured to provide at least one sample collection form to the patient via the patient portal application, wherein the at least one sample collection form is directly integrated with the patient workflow management module to enable real-time review of the patient's response.

Images