WO2023069467A1

WO2023069467A1 - Privacy-preserving data aggregation and sharing system

Info

Publication number: WO2023069467A1
Application number: PCT/US2022/047063
Authority: WO
Inventors: Adam Wesley HANSEN; Christopher Glenn HANSEN
Original assignee: Geneial, Inc.
Priority date: 2021-10-19
Filing date: 2022-10-18
Publication date: 2023-04-27

Abstract

The method may include obtaining a first consent to access medical data of an individual. The method may further include, retrieving the medical data of the individual from a number of independent data sources. Further, the method may include, aggregating the medical data retrieved from the number of independent data sources together in a central repository. Systems and devices for performing the method are also disclosed.

Description

PRIVACY-PRESERVING DATA AGGREGATION AND SHARING SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims the benefit of and priority to U.S. Provisional App. No. 63/262,724 filed October 19, 2021, titled PRIVACY-PRESERVING DATA AGGREGATION AND SHARING SYSTEM, which is incorporated in the present disclosure by reference in its entirety.

FIELD

The embodiments discussed in the present disclosure are related to a privacypreserving data aggregation and sharing system.

BACKGROUND

Unless otherwise indicated herein, the materials described herein are not prior art to the claims in the present application and are not admitted to be prior art by inclusion in this section.

All types of data in numerous different fields are being generated throughout the world. Similarly, significant amounts of data are being aggregated and stored in various repositories throughout the world, including those which are commercially or governmentally managed or held. Within a given field, the accumulated data may be used in aggregate by individual repositories for various purposes.

The subject matter claimed herein is not limited to implementations that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some implementations described herein may be practiced.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential characteristics of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

In an example embodiment, a method includes obtaining a first consent to access medical data of an individual. The method includes retrieving the medical data of the individual from a number of independent data sources. The method includes aggregating the medical data retrieved from the number of independent data sources together in a central repository.

In another example embodiment, the method further includes obtaining a second consent for a data user to access medical data of the individual. The method additionally includes providing a subset of the medical data stored in the central repository to the data user based on the second consent.

In another example embodiment, the method additionally includes homomorphically encrypting at least a subset of medical data before the subset of medical data is aggregated in the central repository.

In another example embodiment, the method additionally includes conveying an offer of compensation from the data user to the individual in return for providing the subset of medical data to the data user.

In another example embodiment, the medical data is retrieved from the number of independent data sources and is retrieved via an Application Programming Interface (API) for each of the number of independent data sources.

In another example embodiment, the method additionally includes encrypting the medical data of the individual, and the method also includes standardizing the medical data retrieved from the number of independent data sources in the central repository.

In another example embodiment, the method additionally includes receiving a request for the medical data of the individual from a data user. The method additionally includes providing a decryption key to the data user to decrypt the medical data of the individual.

In another example embodiment, one or more non-transitory computer-readable storage media is configured to store instructions. In response to being executed, the instructions cause a system to perform operations that include obtaining a first consent to access medical data of an individual. The operations include retrieving the medical data of the individual from a number of independent data sources. The operations include aggregating the medical data retrieved from the number of independent data sources together in a central repository.

In another example embodiment, the operations additionally include obtaining a second consent for a data user to access medical data of the individual and providing a subset of the medical data stored in the central repository to the data user based on the second consent. In another example embodiment, the operations additionally include homomorphically encrypting at least a subset of medical data before the subset of medical data is aggregated in the central repository.

In another example embodiment, the operations additionally include conveying an offer of compensation from the data user to the individual in return for providing the subset of medical data to the data user.

In another example embodiment, the medical data is retrieved from the number of independent data sources via an Application Programming Interface (API) for each of the number of independent data sources.

In another example embodiment, the operations additionally include encrypting the medical data of the individual, and standardizing the medical data retrieved from the number of independent data sources in the central repository.

In another example embodiment, the operations additionally include receiving a request for the medical data of the individual from a data user and providing a decryption key to the data user to decrypt the medical data of the individual.

In another example embodiment, a system includes one or more processors, and one or more non-transitory computer-readable storage media configured to store instructions that, in response to being executed, cause the system to perform operations. The operations include obtaining a first consent to access medical data of an individual. The operations include retrieving the medical data of the individual from a number of independent data sources. The operations include aggregating the medical data retrieved from the number of independent data sources together in a central repository.

In another example embodiment, the operations performed by the system additionally include obtaining a second consent for a data user to access medical data of the individual and providing a subset of the medical data stored in the central repository to the data user based on the second consent.

In another example embodiment, the operations performed by the system additionally include homomorphically encrypting at least a subset of medical data before the subset of medical data is aggregated in the central repository.

In another example embodiment, the operations performed by the system additionally include conveying an offer of compensation from the data user to the individual in return for providing the subset of medical data to the data user. In another example embodiment, the medical data from the system is retrieved from the number of independent data sources via an Application Programming Interface (API) for each of the number of independent data sources.

In another example embodiment, the operations performed by the system additionally include encrypting the medical data of the individual, standardizing the medical data retrieved from the number of independent data sources in the central repository, receiving a request for the medical data of the individual from a data user, and providing a decryption key to the data user to decrypt the medical data of the individual.

The object and advantages of the embodiments will be realized and achieved at least by the elements, features, and combinations particularly pointed out in the claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 A illustrates an example system for aggregating medical data from a number of independent data sources;

FIG. IB illustrates an example system for sharing medical data with one or more data users;

FIG. 2 illustrates an example system for secure data exchange;

FIG. 3 illustrates a flowchart of an example method of aggregating medical data from a number of independent data sources;

FIG. 4 illustrates a flowchart of another example method of aggregating medical data from a number of independent data sources;

FIG. 5A and 5B illustrate flowcharts of other example methods of aggregating medical data from a number of independent data sources;

FIG. 6 illustrates a block diagram of an example computing system, all arranged in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION OF SOME EXAMPLE EMBODIMENTS

Data collection and aggregation has become increasingly common in many industries including financial technology, social networking, security systems, smart home technology, and other industries improving services through collecting and analyzing user data. In many instances, the ability to securely aggregate and share personal data is central to successfully using the data. The ability to securely aggregate and share personal data may be a challenge for many industries, including the medical industry that, as a part of its daily business, collects private medical data from patients. The collection of medical data creates a particular set of challenges both for patients whose data is being collected and for data users in the medical industry (e.g., health clinics, doctors, research clinics, and other medical data users). The challenges may include fragmentation of patient data across various data repositories, patient ignorance regarding use of the patient’s medical data when consent is given for research purposes, and the “red tape” restrictions around accessing medical data. Each of the challenges may be addressed by any number of embodiments described and illustrated below.

In more detail, one challenge for collecting medical data is the fragmentation of patient data across various data repositories. Without a way for medical data users to communicate, it may become difficult for the patient to collect or acquire their medical data and it may be difficult for medical data users to collect all of the relevant data for a patient. When medical data is fragmented across different repositories, it may become difficult for healthcare professionals to adequately care for and diagnose their patients. For example, a diabetic patient may have a primary care physician in one healthcare system, but their dialysis center might be part of a different healthcare system whose data is not accessible to the primary care physician. Knowing whether the patient is attending dialysis as needed and whether the patient may experience any complications while receiving dialysis treatment may be important information for the primary care physician to know about the patient. Furthermore, fragmentation of medical data may be a problem for the patient because their own medical data is siloed in separate data repositories often in different clinics or systems. Patients may move to different states and countries, their health needs may change throughout their lives, and/or other circumstances may exist in which access to a full collection of their medical data may be beneficial for the patient.

In an effort to allow patients easier access to their own data, the Office of the National Coordinator for Health IT (“ONC”) published a final rule in 2020 under the title, “21^st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (the “Final Rule”). The ONC’s Final Rule, among other things, requires the health care industry to adopt standardized application programming interfaces (“APIs”) that allows patients to access Electronic Health Information (“EHI”), both structured and unstructured data. The Final Rule provides a gateway for each patient to access their medical data via APIs.

While the Final Rule may provide potential gateways for patients to access medical data, the difficulty remains in aggregating the medical data and providing a secure way to share the medical data with other medical data users. In addition, while different data repositories may be accessible to patients to access the medical data with the institution of the final rule, the problem still remains that the data within each repository may be structured or unstructured and may be organized differently in different repositories. In some embodiments in this disclosure, the medical data associated with each patient may be retrieved from each data repository via an API and aggregated in a central repository where the patient may have access to their medical data. Furthermore, in some embodiments in this disclosure, the medical data may also be standardized such that the medical data from each of the different data repositories may be sent, encrypted, manipulated, and otherwise used by the patient and third parties.

Another common problem in aggregating and sharing medical data is patient ignorance regarding use of the patient’s medical data when consent is given for research purposes. For example, a patient may give consent for medical data to be used for research purposes; however, the patient may not realize that providing consent may give those requesting consent the ability to sell the medical data of the patient to third parties. In many cases, healthcare systems, healthcare clinics, research companies, insurance companies, and other medical data users may be profiting off of medical data where the patients themselves may not be receiving any compensation. In some embodiments of the present disclosure, the aggregation, encryption, and standardization of medical data may allow patients and other users to have more control of their medical data, knowledge about the use of the medical data, and the ability to receive compensation in exchange for sharing the medical data with other data users.

An additional problem for the medical industry in sharing medical data may be that access to medical data may be mired in red tape which may prevent and/or it make it difficult for researchers, diagnostic developers, and treatment developers to access patient data. Access to medical data may be important to data users in, for example, the process of gathering patient information, communicating with patients, and/or enrolling patients in clinical trials. Embodiments of the present disclosure may allow healthcare systems to handle only encrypted data which may be inherently de-identified. Therefore, some embodiments of the present disclosure may allow the use of protected health information without seeing it or handling it which may greatly de-risk the management and use of protected health information and may aid with HIPAA compliance requirements. Additionally or alternatively, embodiments in the present disclosure may allow researchers, diagnostic developers, treatment developers, and other medical data users to search through patient data in a de-identified manner such that medical data users may reach out to patients who may have potentially relevant data and request the patient data.

In some embodiments of the present disclosure, the medical data may be homomorphically encrypted prior to sharing the medical data. Homomorphic encryption is a technology that allows mathematical operations to be performed on encrypted data, resulting in an encrypted and therefore private output. Some embodiments herein implement homomorphic encryption, which allows third parties to analyze sensitive data aggregated from disparate sources without learning the contents of the data. In comparison, traditional (non-homomorphic) encryption algorithms add value by obfuscating data during storage and transit only. When traditional (non-homomorphic) encryption algorithms are used, all encrypted data must be decrypted during computation to be of any utility, thus by necessity exposing unencrypted data to the computing party. Without homomorphic encryption, aggregate analysis of data from multiple owners will always expose data to external parties and is therefore not private. With homomorphic encryption, data can be managed and made searchable through an aggregate, centralized repository without ever exposing the actual data contents.

Reference will now be made to the drawings to describe various aspects of example embodiments of the invention. It is to be understood that the drawings are diagrammatic and schematic representations of such example embodiments, and are not limiting of the present invention, nor are they necessarily drawn to scale.

FIG. 1A illustrates an example system 100 for aggregating medical data from a number of independent data sources, in accordance with at least one embodiment described in the present disclosure. The system 100 may generally include a user 102, a client device 104, and a central repository 106 that may include a system API 108 and a central database 110. The system 100 may further include a network 112, independent data sources 114a, 114b, up to 114n (the “independent data sources 114”) where each of the independent data sources may include a database 116a, 116b, up to 116n (the “databases 116”) and API 118a, 118b, up to 118n (the “APIs 118”).

The user 102 may include an individual. In some embodiments, the user 102 may include an entity, a group of individuals, or any other number of individuals that may provide input to the system 100 such that the system 100 may aggregate medical data from at least one independent data source. In some embodiments, the user 102 may include the individual whose medical data may be requested and aggregated as further described with respect to FIGS. 1-5. For example, the user 102 may be a patient who may be requesting his/her own medical data. In some embodiments, the user 102 may include an individual or a group of individuals who may act as a representative or representatives to request and aggregate medical data of another individual. For example, a parent/guardian may request and aggregate medical data on behalf of a child through the system 100. In some embodiments, an entity may request and/or aggregate medical data on behalf of another individual or number of individuals. For example, a workplace may receive consent from an employee and the workplace may then request/aggregate medical data of the employee from a number of independent data sources through the system 100. As another example, healthcare systems, clinics, research clinics, and other data users as described further with respect to FIG. IB below, may receive consent from one or more patients and may act as the user 102 to request and aggregate data for the one or more patients through the system 100. In these and other embodiments, the user 102 may request and/or aggregate medical data through the client device 104. In addition, while a single user 102 and client device 104 are depicted in FIG. 1 A, more generally the system 100 may include one or more users 102 and one or more client devices 104.

The client device 104 may include any suitable system, device, or apparatus configured to accept input from a user 102. For example, in some embodiments, the client device 104 may be a smartphone configured to accept input from the user 102. For instance, the client device 104 may be configured to receive consent, requests, and other directions from the user 102. In some embodiments, the client device 104 may be configured to transmit and/or convey the input from the client 102 to the central repository 106. Additionally or alternatively, the client device 104 may be configured to transmit and/or convey the input from the client 102 to the network 112 and/or to the independent data sources 114 as described in further detail below. In some embodiments, the client device 104 may include any suitable computing system such as the computing system described below with respect to FIG. 6.

The central repository 106 may include any suitable system, device, or apparatus configured to receive input from the user 102 via client device 104. In some embodiments, the central repository 106 may be configured to transmit and receive information by performing functions that may include making a call to the system API 108 and compiling data in the central database 110. In some embodiments, the central repository 106 may receive requests from the client device 104. For example, the client device 104 may convey a request to the central repository 106 to aggregate and store medical data from independent data sources 114. Continuing the example, the central repository 106 may be configured to receive the request from the client device 104, request the medical data from the independent data sources 114, and aggregate and store the medical data from the independent data sources 114 in the central database 110. In some embodiments, the central repository 106 may include any suitable computing system such as the computing system described below with respect to FIG. 6.

The system API 108 may include any suitable software interface or communication module that may be configured to communicate with another computer program. In some embodiments, the system API 108 may be configured to communicate with another computer program through a network 112. For example, the system API may be configured to communicate with one or more of the APIs 118 as described in further detail below. Additionally or alternatively, the system API 108 may be configured to allow direct communication between the central repository 106 and another computing system. For example, the system API 108 may allow direct communication from the independent data sources 114 to the central repository 106. In some embodiments, the client device 104 may communicate with central repository 106 via the system API 108.

The central database 110 may be configured to aggregate and store data that may be received from the databases 116 of the independent data sources 114. In some embodiments, the central database 110 may store data received from the independent data sources 114 separately. For example, the data from independent data source 114a may be stored in one location in the central database 110 while the data received from the other independent data sources 114b and up to 114n may be stored in separate locations in the central database 110. In some embodiments, the data received from the independent data sources 114 may be aggregated and stored together in the central database 110. In some embodiments, the data received from each of the independent data sources 114 may be standardized and stored in the central database 110 as further described with respect to FIGS. 4 and 5 below.

The network 112 may be any suitable network configured to communicate information including medical data as described in various embodiments in this disclosure. For example, the network 112 may be a local area network (LAN), a wireless local area network (WLAN), a wide area network (WAN), a virtual private network (VPN) or any other network that may allow communication of medical data between various devices and/or systems.

The independent data sources 114 may include any suitable system, apparatus, or device configured to store, receive and/or send medical data. In some embodiments, the independent data sources 114 may be representative of any number of independent data sources 114 that may store medical data. In some embodiments, one of the independent data sources 114 may store medical data from one medical system. For example, independent data source 114a may exclusively store medical data from one health clinic in database 116a. In some embodiments, one of the independent data sources 114 may store medical data from more than one medical system. For example, independent data source 114a may store medical data from a network of health clinics, hospitals, research facilities, and other organizations that may store medical data. In addition, while three independent data sources 114 are depicted in FIG. 1 A, more generally the system 100 may include one or more independent data sources 114.

In some embodiments, the independent data sources 114 may store medical data (both structured and unstructured medical data) associated with individuals such that, when the medical data of an individual is properly requested, the independent data source may send the medical data associated with the individual. In some embodiments, the independent data sources 114 may receive requests for medical data from the central repository 106 via APIs 118. In these and other embodiments, the independent data sources 114 may be configured to send requested medical data to the central repository 106 via network 112. In some embodiments, the central repository 106 may request medical data only from a subset of the independent data sources 114, such as the independent data source 114a. For example, the user 102 may request medical data of his/her own. Continuing the example, the user 102 may have only visited one clinic which may keep medical data in database 116a in the independent data source 114a. Further continuing the example, the central repository 106 may therefore only request medical data for the client 102 from the independent data source 114a and the independent data source 114a may send the medical data of the user 102 to the central repository 106. In another example, the user 102 may request his/her own medical data and, in this example, the user may have visited three clinics which may store their data with independent data sources 114a, 114b, and 114n respectively. Continuing the example, the central repository 106 may request medical data for the client 102 from the independent data sources 114a, 114b, and 114n respectively. Further continuing the example, the independent data sources 114 may send the medical data of the user 102 unique to each of the independent data sources 114 to the central repository 106.

Each of the independent data sources 114 may include a database as illustrated by the databases 116. Each of the databases 116 may be configured to store medical data. In some embodiments, the medical data may be stored as structured or unstructured data. In some embodiments, the data may be organized in each of the databases 116 based on standards from one or more different standard development organizations (“SDOs”). The SDOs may include Health Level 7 (HL7), the National Council for Prescription Drug Programs (NCDPD), the International Health Terminology Standards Development Organizations (IHTSDO), Clinical Data Interchange Standards Consortium (CDISC), and other SDOs that may provide direction for medical data organization, storage, transport, security, etc. In some embodiments, the medical data may be organized in each of the databases 116 based on the same standard. In some embodiments, the medical data in database 116a may be organized based on one standard and the medical data in database 116b may be organized based on another standard. In some embodiments, the medical data may be stored in each of the databases 116 such that, when requested, the independent data sources 114 may separate out medical data based on specific personal identifiers. For example, the independent data sources 114 may separate out and share medical data stored in the databases 116 based on searching for an individual, health condition, age, weight, and other personal identifiers.

The APIs 118 may each include any suitable software interface or communication module that may be configured to communicate with another computer program. In some embodiments, the APIs 118 may be configured in accordance with and because of the ONC final rule. In some embodiments, the APIs 118 may be configured to receive requests for medical data from the central repository 106 and the independent data sources 114 may, in turn, send the medical data to the central repository 106 via network 112.

As described herein, each of the independent data sources 114 may be associated with a different entity, such as a health clinic, hospital, research facility, or the like, and each may store medical data of the user 102 and/or of other users. Medical data may be aggregated at the central repository on an individual basis and/or on an entity basis. For example, medical data may be aggregated at the central repository 106 on an individual basis by obtaining consent of a given user, such as the user 102, to aggregate the user’s medical data in the central repository 106 and then obtaining and aggregating the user’s medical data from the independent data sources 114 into the central repository 106 as described herein. Medical data may be aggregated on an entity basis by obtaining and aggregating all of the medical data of a given independent data source (or at least a portion of the independent data source’s medical data that encompasses medical data of more than one user or individual) into the central repository 106 as described in, e.g., PCT App. No. PCT/US2021/043340 filed on July 27, 2021 which is incorporated herein by reference in its entirety. Each of the independent data sources 114 may broadly function as a central repository to the extent each independent data source 114 aggregates medical data of multiple individuals or users. To avoid confusion with the central repository 106, however, each of the independent data sources 114 may be considered and/or referred to as an intermediate repository.

FIG. IB illustrates an example system 150 for sharing medical data with one or more data users (e.g., research labs, healthcare providers, and others who may request and/or use medical data), in accordance with at least one embodiment described in the present disclosure. The system 150 may generally include some or all of the system 100 of FIG. 1A. For example, the system 150 may include the user 102, the client device 104, the central repository 106, the system API 108, and the central database 110. Alternatively or additionally, the system 150 may include an encryption module 120 in the central repository 106, data user devices 122a, 122b, up to 122n (the “data user devices 122”), and/or data users 124a, 124b, up to 124n (the “data users 124”). While the systems 100, 150 are depicted as separate systems in FIGS. 1A and IB, in other embodiments the systems 100, 150 may be combined into a single system that includes, e.g., the central repository 106, one or more users 102 and corresponding client devices 104, one or more independent data sources 114, and one or more data users 124 and corresponding data user devices 122.

The encryption module 120 may be configured to encrypt data that may have been received by one or more of the independent data sources as described with respect to FIG. 1 A above. While the encryption module 120 is not illustrated in FIG. 1 A, the encryption module 120 may in some embodiments be included in the central repository 106 in Fig. 1A. In some embodiments, the encryption module 120 may encrypt medical data from each of the independent data sources. For example, referring to FIG. 1A above, each of the independent data sources 114 may send medical data associated with the user 102. Continuing the example, the encryption module 120 may encrypt the medical data from independent data source 114a using a standard (non-homomorphic) encryption method, the encryption module may additionally encrypt the medical data from independent data sources 114b and 114n respectively using a standard (non-homomorphic) encryption method where each set of encrypted medical data may have a different private decryption key. In some embodiments, by contrast, the encryption module 120 may encrypt all of the medical data together after having been aggregated in the central database 110. In these and other embodiments, the encrypted medical data may be shared in a secure manner with the data users 124 as described with respect to FIG. 2.

In some embodiments, the encryption module 120 may encrypt any subset of the medical data that may have been aggregated and stored in the central database 110. For example, the encryption module may separate a subset of the aggregated medical data in the central database 110 and the encryption module 120 may encrypt the subset of medical data using a standard (non-homomorphic) encryption method where the subset of encrypted medical data may have its own decryption key. In some embodiments, the encryption module may be configured to encrypt a subset of the medical data in the central repository 110 using a homomorphic encryption method such that the homomorphically encrypted subset of the medical data may be manipulated while remaining encrypted.

In some embodiments, the encryption module 120 may be configured to share encrypted medical data along with the decryption keys such that a recipient (e.g., one or more of the data user devices 122) may decrypt the encrypted medical data. For example, data users 124a and 124b may each request a subset of medical data from the client 102. Continuing the example, the user 102 may request, authorize, and/or direct the central repository 106 via the client device 104 to share an encrypted subset of medical data and a one-time decryption key with the data user 124a and a homomorphically encrypted subset of medical data to data user 124b. Further continuing the example, the encryption module 120 may encrypt a subset of medical data with a standard encryption method with a one-time decryption key; in addition, the encryption module 120 may homomorphically encrypt another subset of medical data. Continuing the example, the encryption module 120 may direct the encrypted subsets of medical data to be sent to data users 124a and 124b respectively (via their corresponding data user devices 122).

Modifications, additions, or omissions may be made to the system 150 without departing from the scope of the disclosure. For example, the designations of different elements in the manner described is meant to help explain concepts described herein and is not limiting. Further, the system 150 may include any number of other elements or may be implemented with other systems or environments than those described. FIG. 2 illustrates an example system 200 for secure data exchange, arranged in accordance with at least one embodiment described herein. The system 200 may generally include a repository 202, a data user node 204 (or “data user 204”), and data sources 206. The system 200, repository 202, data user node 204, and data source nodes 206 may each respectively include, be included in, or correspond to the system 100, 150, the central repository 106, data user devices 122, and independent data sources 114 of FIGS. 1A and IB.

The data user 204 may include a computing device or node and/or a person or other entity operating the computing device or node to submit data requests to the repository 202. The repository 202 includes a first database 212 and a second database 218 which in aggregate or individually may include, be included in, or correspond to the central database 110 of FIGS. 1A and IB. The first database 212 includes a sub-database 214 and a subdatabase 216. In the illustrated form, the sub-database 214 is representative of an annotation database and the sub-database 216 is representative of a unique variant database. The second database 218 includes a sub-database 220 and a sub-database 222. In the illustrated form, the sub-database 220 is representative of a database storing homomorphically encrypted data provided by independent data sources 206, 208, 210 and the sub-database 222 is representative of a database storing data provided by independent data sources 206, 208, 210 which is deemed not sensitive. The data in the sub-database 222 may not be encrypted, or it may be encrypted but at a level lower than the data in the sub-database 220. In one form, the homomorphically encrypted data stored in the subdatabase 220 may be homomorphically encrypted by the independent data sources 206, 208, 210 before it is provided to the repository 202, although forms in which all or part of this data is homomorphically encrypted following its receipt at the repository 202 are also possible. Similarly, the data in the sub-database 222, if encrypted, may be encrypted before or after deposit in the repository

The repository 202 may also include a processor system 224. When the repository 202 receives data requests from the data user 204, the processor system 224 may first relay the data requests to the database 212 where the data request or data requests are decomposed into an output set of all possible variants meeting the specified input criteria. This simplified, equivalent data request may then be relayed to the sub-database 220 which may be performance-optimized by storing only linking information between variant and sample identifiers (or between sample and phenotype identifiers). Alternatively or additionally, the processor system 224 may perform the decomposition to generate the simplified, equivalent data request to query the sub-database 220.

The number of samples harboring variants matching the data user 204 search criteria, optionally along with pricing information, may then be returned to the data user 204, at which point the data user 204 may decide whether to move forward with purchasing the results. While not previously discussed, in some forms the data request(s) from the data user 204 may be private such that the repository 202, and the processor system 224 thereof, are blind as to the identification of the data user 204 and/or the contents of the data request(s).

If the data user 204 elects to purchase (e.g., deems the results relevant to their objectives), the processor system 224 may coordinate procuring readable results for the data user 204 without exposing results to itself, where the results may be from any number of the independent data sources 206, 208, 210. In some implementations, the repository 202 may receive a standard public key from the data user 204. The homomorphically encrypted results may then be joined with the full variant information stored in the sub- database 222, and both the public key and the results may be sent to the relevant ones of the independent data sources 206, 208, 210 for decryption (e.g., using decryption keys of the independent data sources 206, 208, 210) and re-encryption using the standard public key. The public key may be used for re-encrypting the results with homomorphic encryption (either full or partial) or other encryption. The re-encrypted results may then be passed through the repository 202 and delivered to the data requester 204, who can decrypt the purchased results with their corresponding private key. The private key used by the data user 204 is the private key that decrypts data encrypted with the public key provided by the data user 204 to the repository 202. In this and some other implementations, the repository 202 may be unable to view any sensitive data provided by one or more of the independent data sources 206, 208, 210 and forwarded to the data requester 104. Alternatively, the relevant ones of the independent data sources 206, 208, 210 may each provide a one-time decryption key to the repository 202 and the repository 202 may forward the relevant results along with the one-time decryption key of each of the relevant ones of the independent data sources 206, 208, 210 to the data user 204. Alternatively, the relevant ones of the independent data sources 206, 208, 210 may each provide a one-time decryption key, along with the results relevant to the data request(s), directly to the data user 204, and/or the one-time decryption key, along with the results relevant to the data request(s), may be provided to an independent third party (outside of the repository 202) which may then forward the same on to the data requester 204.

As another alternative, the data user 204 may create a public-private key pair and retain the private key. The public key could be forwarded from the data user 204 to the repository 202 where the processor system 224 forwards the same public key to one or more of the independent data sources 206, 208, 210. One or more of the independent data sources 206, 208, 210 may then issue one-time decryption keys, and those keys may be encrypted with the public key provided by the data user 204. The one or more of the independent data sources 206, 208, 210 may forward the encrypted key to the repository 202, and the processor system 224 may forward the encrypted key package(s) to the data user 204. The data user 204 may use the private key to decrypt the key package(s) to obtain the one-time keys such that the one-time keys may be utilized to decrypt the purchased results of the initial data request(s).

Additions, omissions, modifications, etc. may be made to the system 200 of FIG. 2. For example, the system 200 may include two or more data users 204; one, two, four, or more independent data sources 206, 208, 210, two or more processor systems, or the like. Alternatively or additionally, the first database 212 and/or the second database 218 may include fewer or more sub-databases than shown, such as zero, one, three, or more sub-databases.

FIG. 2 as illustrated depicts a centralized architecture in which at least some homomorphically encrypted data from the data sources 206, 208, 210 is stored at the repository 202, e.g., in the second data base 218 and/or specifically in the sub-database 220. Embodiments described herein may alternatively or additionally include a pseudo decentralized architecture and/or a decentralized architecture. In the pseudo decentralized architecture, the repository 202 does not store any homomorphically encrypted data of the data sources 206, 208, 210 but may have read access to homomorphically encrypted data at the data sources. Thus, the repository 202 may still process (e.g., search, filter, analyze) the homomorphically encrypted data at the data sources 206, 208, 210 without decrypting it. As such, the repository 202 may process requests from the data user node 204 in generally the same manner as in the centralized architecture. In the decentralized architecture, the repository 202 does not store any homomorphically encrypted data of the data sources 206, 208, 210 and does not have read access to any data at the data sources. Instead, any queries received by the repository 202 from the data user node 204 may be passed to the data sources 206, 208, 210 and each data source 206, 208, 210 may perform the query and return the results to the repository 202. The repository may then aggregate results from the data sources 206, 208, 210, otherwise process the results, and return the results to the data user 204.

FIG. 3 illustrates a flowchart of an example method 300 of aggregating medical data from a number of independent data sources, in accordance with at least one embodiment described in the present disclosure. The method 300 may be performed by any suitable system, apparatus, or device, such as the system 100, client device 104, and/or central repository 106 of FIG. 1A, the system 150, client device 104, and/or central repository 106 of FIG. IB, and/or the repository 202 and/or processor system 224 of FIG. 2. The method 300 may include one or more blocks 310, 320, and 330. Although illustrated with discrete blocks, the steps and operations associated with one or more of the blocks of the method 300 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the particular implementation.

In some embodiments, the method 300 may start at block 310. At block 310, a first consent may be obtained to access medical data of a user. In some embodiments, consent may be obtained by a system from the user. For example, the central repository 106 may receive the consent which may be collected by the client device 104, 204 from the user or other individual. Alternatively or additionally, the client devices 104, 204 may be configured to receive an electronic signature or other form of consent from the user and provide the consent to the central repository 106. Additionally or alternatively, client devices like client devices 104 and 204 may be configured to receive consent forms via facsimile, PDF, image capture etc. In some embodiments, the consent may be provided by an individual other than the user. For example, a parent or legal guardian may give consent on behalf of a child. In some embodiments, the consent obtained from the individual may specify parameters within which the system may be bound to operate. For example, consent may be limited only to aggregation and collection of medical data with the condition that all of the medical data must be homomorphically encrypted. As another example, the consent may specify that the system may collect and aggregate medical data from specific independent data sources. In some embodiments, the consent obtained may be a blanket consent for the system to retrieve, aggregate, encrypt, share, and perform any of the operations disclosed herein.

At block 320, medical data may be retrieved from a number of independent data sources. In some embodiments, medical data from the user may be retrieved from one independent data source. In some embodiments, the medical data from the user may be retrieved from two or more independent data sources. In these and other embodiments, independent data sources may include any data collection, database, data repository, or any other collection of data that may include medical data of the user. In some embodiments, medical data may be retrieved from a number of independent data sources by communicating through an API of each of the independent data sources. In some embodiments, the API that may be configured to allow communication between the user and the independent data source, may be available due to the ONC’s final rule which may allow the user to electronically access electronic medical data from different healthcare providers. In some embodiments, a data request may be sent to each of the independent data sources via an API and the medical data of the user may then be collected from each of the independent data sources as described with respect FIG. 1 A above.

At block 330, the medical data may be aggregated in a central repository. In some embodiments, the medical data from each of the independent data sources may be collected together and stored in the central depository as described with respect to FIG. 1 A above. In some embodiments, the central repository may include aggregated medical data of more than one user. For example, several users may use the central repository to store medical data from different independent data sources. In these and other embodiments, medical data stored on behalf of different users may be organized according to each user. For example, rather than organizing all collected data by type or condition, the medical data may be organized in the central repository such that the medical data of one user is stored together and the medical data of another is stored together. In some embodiments, access to medical data may be limited to medical data associated with each user.

Modifications, additions, or omissions may be made to the method 300 without departing from the scope of the present disclosure. For example, the operations of method 300 may be implemented in differing order. Additionally or alternatively, two or more operations may be performed at the same time. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the described embodiments. In some embodiments, the method 300 may be combined, in whole or in part, with one or more of the other methods described herein, or with one or more portions of one or more of the other methods described herein. For example, the method 300 may further include some or all of the methods of FIGS. 4-5B. FIG. 4 illustrates a flowchart of another example method 400 of aggregating medical data from a number of independent data sources, in accordance with at least one embodiment described in the present disclosure. The method 400 may be performed by any suitable system, apparatus, or device, such as the system 100, client device 104, and/or central repository 106 of FIG. 1A, the system 150, client device 104, and/or central repository 106 of FIG. IB, and/or the repository 202 and/or processor system 224 of FIG. 2. The method 400 may include one or more blocks 410, 420, 430, 440, 450, 460, and 470. Although illustrated with discrete blocks, the steps and operations associated with one or more of the blocks of the method 400 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the particular implementation.

In some embodiments, the method 400 may start at block 410. At block 410, a first consent may be obtained to access medical data of a user. In some embodiments, the consent may be obtained by a system from the user. In some embodiments, the consent may be provided by an individual other than the user. For example, a parent/guardian may provide consent on behalf of a child whose data may be accessed. In some embodiments, block 410 may be the same as or similar to block 310 in FIG. 3.

At block 420, the medical data may be retrieved from independent data sources. In some embodiments, medical data from the user may be retrieved from at least one independent data source. In some embodiments, the medical data may be retrieved from each of the number of independent data sources by communicating through an API of each of the number of independent data sources. In some embodiments, a data request may be sent to each of the independent data sources through an API and the medical data of the user may then be collected from each of the independent data sources as described with respect to FIGS. 1 A and 3 above.

At block 430, the medical data may be aggregated in a central repository. In some embodiments, the medical data of each of the independent data sources may be collected together and stored in the central depository as described with respect to FIG. 1 A, IB, and 3 above.

At block 440, the medical data from the independent data sources may be encrypted. In some embodiments, the medical data may be encrypted as described with respect to FIG. IB above. In some embodiments, the medical data may be encrypted prior to being retrieved from the independent data source. In some embodiments, medical data that may have been encrypted in the independent data source may be decrypted prior to aggregating the medical data from each of the independent data sources together and re- encrypted with the rest of the medical data after aggregating the medical data together. In some embodiments, the user or other individual may elect to encrypt subsets of the medical data differently. For example, the user or other individual may direct the system to encrypt a first subset of medical data using a symmetric encryption method where the same key may be used to encrypt and decrypt the first subset of medical data. Continuing the example, the user may direct the system to encrypt a second subset of medical data using an asymmetric encryption method which may generate a public key to encrypt the subset of medical data and a private key to decrypt the subset of medical data. Further continuing the example, the user may direct the system to encrypt a third subset of medical data using a homomorphic encryption method which may also generate a key with which to decrypt the third subset of medical data. In some embodiments, the user may elect to share any of the subsets of medical data with a third party. In some embodiments, the user may elect to have the same subset of medical data encrypted in different ways at different times. For example, the user may elect to share a subset of medical data with one data user and to have the subset of medical data encrypted with a standard symmetric encryption method and provide the data user with a one-time decryption key when sharing the subset of medical data. Continuing the example, later, the user may elect to have the same subset of medical data homomorphically encrypted to share with another data user. In some embodiments, a subset of medical data may be encrypted according to a request from the data user. For example, the data user may request only homomorphically encrypted medical data such that the data user may perform calculations and generally analyze the medical data without possessing any identifiers that may accompany the medical data otherwise.

At block 450, the medical data retrieved from the number of independent data sources may be standardized. In some embodiments, the medical data retrieved from the number of independent data sources may have been organized according to various standards as provided by SDOs as described with respect to FIG. 1A. Additionally or alternatively, the medical data retrieved from the number of independent data sources may include unstructured data that may need to be structured, organized, standardized, and/or harmonized with other medical data from the number of independent data sources. In some embodiments, the medical data may include both unstructured data and structured data that may be standardized according to one set of standards. In some embodiments, the medical data may be standardized according to a predefined standard given by an SDO (e.g., HL7). In some embodiments, the medical data may be standardized according to a standard created to make the medical data more visually accessible to the user. Additionally or alternatively, the medical data may be standardized according to a set of standards created to make the medical data easier to analyze by the data user. In some embodiments, the medical data may be standardized according to a set of standards created to allow the data user to search the medical data more easily.

At block 460, a second consent may be obtained for a data user to access the medical data. In some embodiments, the second consent may be the same as the first consent. For example, the user or other individual may, in the first consent, give both consent to the system to search for and aggregate the medical data of the user while additionally providing consent for third parties to receive the medical data of the user for research or other purposes. In some embodiments, the data user may request access to at least a subset of the medical data of the user and the acceptance of the request may constitute the second consent. In some embodiments, the user or other individual may send the medical data to a third party where sending the medical data of the user to the third party may constitute the second consent for the data user to access the data. In some embodiments, the system may request the second consent from the user or other individual prior to sharing the medical data of the user with the data user. In some embodiments, the second consent may be limited to or conditional on a subset of medical data, a time frame within which to use the medical data, a one-time encryption key to access the medical data, or any other constraint that may be placed on access to the medical data. In some embodiments, the user may revoke their consent partially or fully at any time. For example, the user may consent to use by a third party of a subset of their medical data in a research study. Continuing the example, the user may rethink the use by the third party of the subset of medical data and decide to revoke the consent given which may allow the user to retrieve the subset of the medical data from the research study or to have the third party delete/remove the user’s medical data from the research study. In some embodiments, the second consent may allow the data user to analyze, manipulate, sell, rent, or otherwise use the medical data.

At block 470 a subset of medical data may be provided to the data user. In some embodiments, the subset of medical data may include all of the medical data that may have been aggregated in accordance with one or more of the embodiments described with respect to FIG. 1A. In some embodiments, the user or other individual may provide the second consent for the data user to access the subset of medical data of the user in exchange for compensation. In these and other embodiments, an offer of compensation (e.g., money) may be conveyed from the data user through the central repository and the client device to the user or other individual. For example, the data user may offer $20 to use the subset of medical data in a research study. As another example, the data user may offer $200 in exchange for access to and the ability to sell the subset of medical data to a third party(ies). In some embodiments, the subset of medical data may be encrypted and may be shared with the data user according to one or more of the embodiments described with respect to FIG. 2.

Modifications, additions, or omissions may be made to the method 400 without departing from the scope of the present disclosure. For example, the operations of method 400 may be implemented in differing order. Additionally or alternatively, two or more operations may be performed at the same time. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the described embodiments. In some embodiments, the method 400 may be combined, in whole or in part, with one or more of the other methods described herein, or with one or more portions of one or more of the other methods described herein. For example, the method 400 may further include some or all of the methods of FIGS. 3 and 5A-5B.

FIG. 5A illustrates a flowchart of another example method 500 of aggregating medical data from a number of independent data sources, in accordance with at least one embodiment described in the present disclosure. The method 500 may be performed by any suitable system, apparatus, or device, such as the system 100, client device 104, and central repository 106 of FIG. 1A, the system 150, client device 104, and/or central repository 106 of FIG. IB, and/or the repository 202 and/or processor system 224 of FIG. 2. The method 500 may include one or more blocks 502, 504, 506, 508, 510, 512, 514, 516, 518, 520, 522, and 524. Although illustrated with discrete blocks, the steps and operations associated with one or more of the blocks of the method 500 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the particular implementation.

In some embodiments, the method 500 may start at block 502. At block 502, a user may download an application or visit a web-application. In some embodiments, the user may include an individual seeking to retrieve their own medical data from a number of independent data sources as described with respect to FIG. 1 A. In some embodiments, the user may be an individual or entity seeking the medical data on behalf of another. For example, a parent/guardian may be the user seeking to retrieve and aggregate medical data on behalf of their child. As another example, an employer may be seeking to retrieve and aggregate medical data on behalf of an employee after having received that employee’s consent. In still another example, an individual may be the user seeking to retrieve and aggregate their own medical data. In some embodiments, the user may access an application which may include an application on a mobile device where the application may be downloaded and used. For example a mobile phone, tablet, smart watch, or other device may download and run the application. In some embodiments, the user may access a web-based application. For example, the application may be accessible from a webpage that may be accessed via a network (e.g., Internet, intranet, or other network). In some embodiments, the user may interact with the application or web-based application to direct a system to perform one or more operations such as retrieving, aggregating, and/or sharing medical data as described herein. Block 502 may be followed by block 504.

At block 504, the user may agree to an end user license agreement (“license agreement”). In some embodiments, the user may sign the license agreement which may enable the application to act on behalf of the user in retrieving and otherwise manipulating the medical data of the user. In some embodiments the user agreeing to the license agreement may provide the “consent” required to access the user’s medical records at different independent data sources. In some embodiments, the license agreement may allow the application to retrieve and otherwise manipulate the medical data of an individual from whom the user may have received consent. In some embodiments, the license agreement may allow the application to retrieve medical data and other personal records related to the medical data from a number of independent data sources. In this and other embodiments, the user agreeing to the license agreement may provide the “consent” required to access the user’s medical records at the independent data sources. In some embodiments, the license agreement may allow the application to perform at least one action which may include: aggregating, standardizing, encrypting, decrypting, transacting, or otherwise managing the medical data of an individual. Additionally or alternatively, the license agreement may be a part of the application or the web-based application. In some embodiments, the license agreement may be assented to by the user separate and apart from the application and/or web-based application. Block 504 may be followed by block 506.

At block 506, the application or web-based application may retrieve medical data from an independent data source(s). In some embodiments, the application may find the medical data of the individual through a web crawling function and/or hot that may allow the application to find relevant medical data or databases that may contain medical data of the individual. In some embodiments, the application may retrieve medical data from a number of known databases that may include medical data of the individual. For example, the individual may share with the application that the medical data of the individual may be found in five different database locations that may be based on five separate health clinics that the individual may have visited. Continuing the example, the application may retrieve the relevant medical data for the individual from each of the five database locations. In some embodiments, the independent data sources may include health clinics, hospitals, medical research laboratories, and other entities that may be involved in treating patients or otherwise using medical data. In some embodiments, the application may connect and retrieve the medical data from the independent data sources via an Application Programming Interface (“API”) which may allow the independent data source to receive requests for medical data and also allow the independent data source to provide the requested medical data. In some embodiments, the access to the medical data via an API may be made possible by the ONC final rule where the final rule may, in part, allow patient data at each medical clinic to be accessible to the patient via an API. In some embodiments, the application may retrieve medical data for the individual from any number of independent data sources. Block 506 may be followed by block 508.

At block 508, the medical data of the user may be standardized. In some embodiments, each of the independent data sources may use different standards for medical data content, transport, terminology, security, and other data standards. For example, each of the independent data sources may keep medical data organized based on standards from a number of different SDOs where the SDOs may include HL7, the NCDPD, the IHTSDO, CDISC, and/or other SDOs that may provide direction for medical data organization, storage, transport, security, etc. In some embodiments, the medical data from each of the independent data sources may be standardized such that the medical data may be organized in accordance with one of the SDO’s standards. For example, medical data may be retrieved from three different independent data sources, where the first and second data sources organize their medical data in line with the standards provided by HL7 and where the third independent data source structures the medical data in accordance with standards from the NCDPD. Further continuing the example, the application may standardize the medical data from all three of the independent data sources such that the medical data may all be structured in accordance with HL7 (or other) standards. In some embodiments, the medical data may be standardized such that the medical data may be organized in a simple manner for research purposes. In some embodiments, the data may be standardized such that the medical data from the independent data sources may be organized in a simple manner for diagnostic purposes. In some embodiments, the medical data may be standardized such that the medical data may be presented to the user in a readable manner. In some embodiments, the medical data may be standardized such that the medical data may be separated into different subsets and such that the different subsets may be shared independently. In some embodiments, the medical data retrieved from the independent data sources may include unstructured data. In these and other embodiments, the unstructured data may be structured, organized, standardized, and/or harmonized with other medical data from the number of independent data sources. Block 508 may be followed by block 510.

At block 510, the medical data may be shared (e.g., by the central repository) with a data user. In some embodiments, the entirety of the medical data from the independent data sources may be shared with a data user. For example, the data user may be a research institution seeking to research common health concerns among 25 - 40-year-olds. Continuing the example, all of the medical data of one or more users or other individuals from each of the independent data sources may be shared with the data user. The shared data may give the research institution the medical data surrounding the health concerns of the one or more users. In some embodiments, a subset of all of the medical data of one or more users may be shared with the data user. For example, a data user may be a primary care physician seeking to assess a patient that may, in this instance, also be the user. Continuing the example, the user may be involved in dialysis treatment that may be performed at a separate clinic from the clinic of the primary care physician. Further continuing the example, a subset of the medical data associated with the dialysis treatment may be shared with the physician. Block 510 may be followed by block 512.

At block 512, the medical data may be encrypted. In some embodiments, the medical data may be encrypted with a standard (non-homomorphic) encryption method (e.g., symmetric or asymmetric encryption). In some embodiments, the encryption method may include one or more decryption keys. In these and other embodiments, the one or more decryption keys may be in the possession of, e.g., the user on the user’s client device. In some embodiments, the user maintains possession of the one or more decryption keys in a location separate from the application or web-based application. In some embodiments, the medical data may be encrypted immediately upon aggregation. For example, the medical data retrieved from the independent data sources may be aggregated in a central repository and encrypted together. In some embodiments, each amount of data from each independent data source may be encrypted separately. For example, the system may retrieve medical data for a user from three different clinics (independent data sources). Continuing the example, the data associated with a first clinic may be encrypted using a first method and have a first key, the data associated with a second clinic may be encrypted using a second method and have a second key, and the data associated with a third clinic may be encrypted using a third method and have a third key. In some embodiments, the medical data may be homomorphically encrypted. Additionally or alternatively, a subset of medical data may be homomorphically encrypted. In some embodiments, the user (or other individual) may elect to use any number of encryption methods to encrypt all or a subset of the user’s medical data at any time. For example, the medical data may be aggregated, stored, and encrypted. Continuing the example, the user may subsequently elect to homomorphically encrypt a subset of the medical data. Block 512 may be followed by block 514.

At block 514, the encrypted medical data may be shared with the data user. In some embodiments, a subset of medical data may be shared where the subset of medical data may be relevant to the data user. For example, the data user may be a research clinic that may request data having to do with a specific medical treatment. Continuing the example, the subset of the medical data that may be relevant to the research regarding a specific medical treatment may be shared with the research clinic. Additionally or alternatively, the entirety of the medical data may be shared with the data user. For example, the data user may be a general care physician and the user may be a patient. Continuing the example, the entirety of the medical data of the patient may be shared with the general care physician which may increase the quality of care that may be provided by the general care physician. In some embodiments, a subset of encrypted medical data may be shared with a data user. In some embodiments, a subset of homomorphically encrypted data may be shared with the data user. For example, the data user may be a research entity that may be requesting the user’s medical data. Continuing the example, a subset of homomorphically encrypted data may be shared with the research entity such that the research entity may be able to perform calculations, manipulate, or otherwise analyze the subset of the medical data without decrypting the subset of medical data. In some embodiments, at least a subset of medical data may be shared without encrypting the medical data. In some embodiments, a subset of medical data may be shared with a data user through a secured channel such that the medical data may remain secure during the data transfer to the data user as described, e.g., with respect to FIG. 2. In some embodiments, the user may retract provided consent such that the subset of medical data is no longer shared with the data user and, in some embodiments, the subset of medical data previously shared with the data user may be retracted. In some embodiments, the application or web-based application that may accept input from the user may include an option for the user to elect to share the medical data for research or treatment development. Block 514 may be followed by block 516.

At block 516, the data user may manage and transact the medical data of the user. In some embodiments, the data user may have received at least a subset of the user’s medical data. Additionally or alternatively, the data user may collect medical data from a number of different users and may additionally store the medical data collected from the number of different users in a database. In some embodiments, the data user may employ the medical data received from the number of different users for their own purpose. For example, the data user may be a research clinic and may collect and organize the medical data from a number of different users. Continuing the example, the data user may collect and analyze the medical data for research conducted by the data user. In some embodiments, the data user may sell the data collected from the number of different users. For example, the data user may homomorphically encrypt the medical data from the user. Continuing the example, the data user may sell or rent the homomorphically encrypted data for a limited purpose to a third party. Block 516 may be followed by block 518.

At block 518, the data user may share revenues generated through data transactions with the user. For example, the data user may sell the medical data from a user to a third party for use by the third party. Continuing the example, the data user may share some of the revenue generated from the shared medical data with the user whose medical data the data user received. In some embodiments, the user may have provided consent for the data user to use the medical data where the consent may have been contingent on receiving compensation, e.g., a portion of the revenue generated from the data user selling or renting the medical data of the user. In some embodiments, the system described with respect to FIGS. 1-3 may allow the user to elect whether to allow the data user to sell or rent the medical data. Further, in some embodiments, the system may allow the user to negotiate terms that may govern the relationship between the user and the data user. For example, the user, through the system, may receive an offer from the data user requesting to use the medical data of the user. Continuing the example, the user may deny the request. Additionally or alternatively, the user may accept the request from the data user conditional upon the data user paying a fee or royalty or providing other compensation for the medical data. In some embodiments, the user may, through the system, elect to revoke any consent given for the data user to have, sell, rent, manipulate, or otherwise use the medical data of the user at any time. Block 518 may be followed by block 520.

At block 520, the user may alter or change encryption options, data sharing options, and/or consent given. In some embodiments, the user may, through, e.g., the system described with respect to FIGS. 1-3, change a number of options that may allow the user to retain or share their medical data. In some embodiments, the user may elect to have all or a subset of the medical data homomorphically encrypted. In some embodiments, all or the subset of the medical data may be homomorphically encrypted prior to sharing that subset of medical data with a data user. Additionally or alternatively, the user may elect to share that same subset of medical data with another user and may elect not to have that same subset of medical data homomorphically encrypted prior to sharing. In some embodiments, the user may elect to share a first subset of medical data with standard encryption and a second subset of medical data with homomorphic encryption. In some embodiments, a data user may request consent of the user to receive medical data from the user. The request may be routed to the user through, e.g., a central repository and client device. In these and other embodiments, the user may provide consent to share the requested medical data with the data user. Additionally or alternatively, the user may elect to revoke the consent given at any time even after the medical data has been shared with the data user. In these and other embodiments, the system described with respect to FIGS. 1-3 may facilitate revoking the consent and retracting the medical data from the data user such that the data user would no longer have access to the medical data. In some embodiments, the user may elect to provide limited consent to the data user. For example, the user may provide consent for the data user to analyze and otherwise use the medical data in one research study but not to analyze or otherwise use the medical data in another research study or for any other purpose. In some embodiments, the medical data may be provided to a data user through any number of encryption options configured or elected by the user. For example, the medical data may be encrypted using a standard encryption and may be provided to a second user with a decryption key to read the plaintext of the medical data, the medical data may be homomorphically encrypted and provided to a data user, the medical data may be homomorphically encrypted and provided to the data user with a decryption key, the medical data may also be provided to a data user without encryption. Block 520 may be followed by block 522. At block 522, the user or the central repository may receive a request from a data user to decrypt or share the encrypted medical data. The request may be routed to the user through, e.g., a central repository and client device. In some embodiments, the central repository may receive a request from the data user to decrypt encrypted medical data of the user. In some embodiments, the data user may request a subset of the user’s medical data and the subset may be provided to the data user. In some embodiments, the data user may determine what request to make by searching metadata from the medical data of the user. For example, the medical data may be homomorphically encrypted. Continuing the example, the homomorphic encryption may allow metadata associated with the homomorphically encrypted medical data to be searched without allowing the data user to discern any identifying information in the medical data. In some embodiments, the data user may send requests to various users through the system based on the metadata search. In these and other embodiments, the data user may not know personal identifying information associated with the user; rather, the data user may know that the metadata associated with the user may be desirable. For example, the data user may be a research entity that may be performing research on individuals who may have undergone dialysis treatment. Continuing the example, the data user may search through the metadata in the system which may contain homomorphically encrypted medical data from a number of different users. Further continuing the example, the metadata of one of the users may indicate that the user may have undergone a dialysis treatment, and, on the basis of that knowledge, the data user may request access to the medical data without knowing the identity of the user. In some embodiments, the data user may perform a query to request potentially relevant medical data and the central repository may be searched and/or medical data may be requested from one or more users on behalf of the data user based on the query. For example, the data user may be a research entity that may be performing research on dialysis treatment. Continuing the example, the research entity may perform a query searching for medical data from individuals who may have undergone dialysis treatment. Further continuing the example, the metadata associated with the homomorphically encrypted medical data may be searched on behalf of the research organization. Continuing the example, any relevant medical data from the one or more users may be requested on behalf of the research entity. In some embodiments, the search may be based on the query performed by the data user and the data user may be provided with an option to request any of the potentially relevant medical data. Block 522 may be followed by block 524. At block 524, a decryption key may be provided to the data user. In some embodiments, the user may elect to encrypt at least a subset of medical data and may additionally obtain possession of a decryption key for at least the subset of medical data. In some embodiments the medical data may be encrypted using an asymmetric encryption method. In these and other embodiments, a private key may be provided to the data user to allow the data user to decrypt the medical data. In some embodiments, in exchange for the decryption key, the data user may provide compensation to the user. In some embodiments, the central repository may provide the data user with an option to request relevant medical data as illustrated in block 522 above and, in response, the data user may request medical data and may provide a public key to the central repository for encryption. For example, the medical data may be homomorphically encrypted, and the central repository may have performed a search based on a query performed by the data user. Continuing the example, the central repository may have presented the data user with an option to request medical data. Further continuing the example, the data user may request the medical data and may provide a public encryption key that may be used to encrypt the requested medical data. Continuing the example, the user may provide the required consent to share the medical data, the homomorphically encrypted medical data may be decrypted, and the medical data may be re-encrypted using the public key provided by the data user. Continuing the example, the re-encrypted medical data may be sent to the data user and the data user may then decrypt the medical data with a private decryption key corresponding to the public encryption key provided to the central repository. In these and other embodiments, the data user may provide information about how the medical data of the user may be used.

Modifications, additions, or omissions may be made to the method 500 without departing from the scope of the present disclosure. For example, the operations of method 500 may be implemented in differing order. Additionally or alternatively, two or more operations may be performed at the same time. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the described embodiments. In some embodiments, the method 500 may be combined, in whole or in part, with one or more of the other methods described herein, or with one or more portions of one or more of the other methods described herein. For example, the method 500 may further include some or all of the methods of FIGS. 3-4 and 5B. FIG. 5B illustrates a flowchart of another example method 550 of aggregating medical data from a number of independent data sources, in accordance with at least one embodiment described in the present disclosure. The method 550 may be performed by any suitable system, apparatus, or device, such as the system 100, client device 104, and central repository 106 of FIG. 1A, the system 150, client device 104, and/or central repository 106 of FIG. IB, and/or the repository 202 and/or processor system 224 of FIG. 2. The method 550 may include one or more blocks 552, 554, 556, 558, 560, 562, 564, 566, 568, 570, 572. Although illustrated with discrete blocks, the steps and operations associated with one or more of the blocks of the method 550 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the particular implementation.

At block 552, homomorphically encrypted (HE) medical data of multiple users and/or entities may be aggregated. The HE medical data may be aggregated at an individual level and/or an entity level. Block 552 may be followed by block 554.

At block 554, a query from a data user is received and processed. For example, the central repository 106, 202 or other central repository may receive the query and perform the query on the HE medical data. Block 554 may be followed by block 556.

At block 556, HE medical data that matches the query may be identified. For example, the central repository may identify any hits of the query as HE medical data that matches the query. Block 556 may be followed by block 558.

At block 558, the data user is informed of the results of the query. Informing the data user of the results may include information the data user that there is one or more hits or records or the like that match the query. Block 558 may be followed by block 560.

At block 560, a request for the matching HE medical data is received from the data user. In some embodiments, block 560 additionally includes receiving a public key of the data user. The use of the public key is described with respect to block 566. The request may be received from the data user in response to the data user deciding to purchase the medical data. In some embodiments, predetermined transaction terms may be provided to the data user together with the results of the query (at block 558). Block 560 may be followed by block 562.

At block 562, the data owner is informed of the request from the data user for the matching HE medical data. Block 562 may additionally include informing the data owner of the predetermined transaction terms. The data owner may be the user or other individual (e.g., user 102) or an entity such as a health clinic, research facility, or the like. Block 562 may be followed by block 564.

At block 564, the data owner decrypts the matching HE medical data using an HE decryption key of the data owner. Block 564 may be followed by block 566.

At block 566, the data owner encrypts the decrypted medical data with the public key of the data user. This allows the medical data to be securely transmitted to the data user. Upon receipt, the data user can then decrypt the encrypted medical data using a private key (corresponding to the public key) of the data user. Block 566 may be followed by block 568.

At block 568, the encrypted medical data is received from the data owner. For example, the central repository may receive the encrypted medical data. Block 568 may be followed by block 570.

At block 570, payment from the data user for the encrypted medical data may be processed. Processing the payment may include processing the payment through an online payment portal. Alternatively or additionally, processing the payment may include distributing the payment between an owner of the central repository and one or more data owners of the encrypted medical data.

Modifications, additions, or omissions may be made to the method 550 without departing from the scope of the present disclosure. For example, the operations of method 550 may be implemented in differing order. Additionally or alternatively, two or more operations may be performed at the same time. Furthermore, the outlined operations and actions are only provided as examples, and some of the operations and actions may be optional, combined into fewer operations and actions, or expanded into additional operations and actions without detracting from the essence of the described embodiments. In some embodiments, the method 550 may be combined, in whole or in part, with one or more of the other methods described herein, or with one or more portions of one or more of the other methods described herein. For example, the method 550 may further include some or all of the methods of FIGS. 3-5 A.

FIG. 6 illustrates a block diagram of an example computing system 602, according to at least one embodiment of the present disclosure. The computing system 602 may be configured to implement or direct one or more suitable operations described in the present disclosure. For example, the computing system 602 may be used in various elements of the above disclosure (e.g., system 100, system 150, system 200, client device 104, central repository 106, any of the independent data sources 114, data source 206, data source 208, data source 210, processor system 224 or other systems capable of performing one or more operations or actions in the disclosed embodiments). The computing system 602 may include a processor 650, a memory 652, and a data storage 654. The processor 650, the memory 652, and the data storage 654 may be communicatively coupled.

In general, the processor 650 may include any suitable computer, computing entity, or processing device including various computer hardware or software modules and may be configured to execute instructions stored on any applicable computer-readable storage media. For example, the processor 650 may include a microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a Field- Programmable Gate Array (FPGA), or any other digital or analog circuitry configured to interpret and/or to execute program instructions and/or to process data. Although illustrated as a single processor in FIG. 6, the processor 650 may include any number of processors configured to, individually or collectively, perform or direct performance of any number of operations described in the present disclosure. Additionally, one or more of the processors may be present on one or more different electronic devices, such as different servers.

In some embodiments, the processor 650 may be configured to interpret and/or execute program instructions and/or process data stored in the memory 652, the data storage 654, or the memory 652 and the data storage 654. In some embodiments, the processor 650 may fetch program instructions from the data storage 654 and load the program instructions in the memory 652. After the program instructions are loaded into memory 652, the processor 650 may execute the program instructions.

The memory 652 and the data storage 654 may include computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. By way of example, and not limitation, such computer-readable storage media may include tangible or non-transitory computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD- ROM)or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other non- transitory storage medium which may be used to store particular program code in the form of computer-executable instructions or data structures and which may be accessed by a general-purpose or special-purpose computer. In these and other embodiments, the term “non-transitory” as explained in the present disclosure should be construed to exclude only those types of transitory media that were found to fall outside the scope of patentable subject matter in the Federal Circuit decision of In re Nuijten, 500 F.3d 1346 (Fed. Cir. 2007).

Combinations of the above may also be included within the scope of computer- readable storage media. Computer-executable instructions may include, for example, instructions and data configured to cause the processor 650 to perform a certain operation or group of operations.

Modifications, additions, or omissions may be made to the computing system 602 without departing from the scope of the present disclosure. For example, in some embodiments, the computing system 602 may include any number of other components that may not be explicitly illustrated or described.

Embodiments described in the present disclosure may be implemented using computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media may include non-transitory computer- readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and which may be accessed by a general purpose or special purpose computer. Combinations of the above may also be included within the scope of computer-readable media.

Computer-executable instructions may include, for example, instructions and data, which cause a general -purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are described as example forms of implementing the claims.

As used in the present disclosure, terms used in the present disclosure and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including, but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes, but is not limited to,” etc.).

Additionally, if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., “a” and/or “an” should be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations.

In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” or “one or more of A, B, and C, etc.” is used, in general such a construction is intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc.

Further, any disjunctive word or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” should be understood to include the possibilities of “A” or “B” or “A and B.”

All examples and conditional language recited in the present disclosure are intended for pedagogical objects to aid the reader in understanding the present disclosure and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Although embodiments of the present disclosure have been described in detail, various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the present disclosure.

Claims

CLAIMS What is claimed is:

1. A method, comprising: obtaining a first consent to access medical data of an individual; retrieving the medical data of the individual from a number of independent data sources; and aggregating the medical data retrieved from the number of independent data sources together in a central repository.

2. The method of claim 1, further comprising: obtaining a second consent for a data user to access medical data of the individual; and providing a subset of the medical data stored in the central repository to the data user based on the second consent.

3. The method of claim 1, further comprising: homomorphically encrypting at least a subset of medical data before the subset of medical data is aggregated in the central repository.

4. The method of claim 2, further comprising: conveying an offer of compensation from the data user to the individual in return for providing the subset of medical data to the data user.

5. The method of claim 1, wherein the medical data is retrieved from the number of independent data sources via an Application Programming Interface (API) for each of the number of independent data sources.

6. The method of claim 1, further comprising: encrypting the medical data of the individual; and standardizing the medical data retrieved from the number of independent data sources in the central repository.

7. The method of claim 6, further comprising: receiving a request for the medical data of the individual from a data user; and providing a decryption key to the data user to decrypt the medical data of the individual.

8. One or more non-transitory computer-readable storage media configured to store instructions that, in response to being executed, cause a system to perform operations, the operations comprising: obtaining a first consent to access medical data of an individual; retrieving the medical data of the individual from a number of independent data sources; and aggregating the medical data retrieved from the number of independent data sources together in a central repository.

9. The one or more non-transitory computer-readable storage media of claim 8, the operations further comprising: obtaining a second consent for a data user to access medical data of the individual; and providing a subset of the medical data stored in the central repository to the data user based on the second consent.

10. The one or more non-transitory computer-readable storage media of claim

8, the operations further comprising: homomorphically encrypting at least a subset of medical data before the subset of medical data is aggregated in the central repository.

11. The one or more non-transitory computer-readable storage media of claim

9, the operations further comprising: conveying an offer of compensation from the data user to the individual in return for providing the subset of medical data to the data user.

12. The one or more non-transitory computer-readable storage media of claim 8, wherein the medical data is retrieved from the number of independent data sources via an Application Programming Interface (API) for each of the number of independent data sources.

13. The one or more non -transitory computer-readable storage media of claim

8, the operations further comprising: encrypting the medical data of the individual; and standardizing the medical data retrieved from the number of independent data sources in the central repository.

14. The one or more non-transitory computer-readable storage media of claim 13, the operations further comprising: receiving a request for the medical data of the individual from a data user; and providing a decryption key to the data user to decrypt the medical data of the individual.

15. A system comprising: one or more processors; and one or more non-transitory computer-readable storage media configured to store instructions that, in response to being executed, cause the system to perform operations, the operations comprising: obtaining a first consent to access medical data of an individual; retrieving the medical data of the individual from a number of independent data sources; and aggregating the medical data retrieved from the number of independent data sources together in a central repository.

16. The system of claim 15, the operations further comprising: obtaining a second consent for a data user to access medical data of the individual; and providing a subset of the medical data stored in the central repository to the data user based on the second consent.

17. The system of claim 15, the operations further comprising: homomorphically encrypting at least a subset of medical data before the subset of medical data is aggregated in the central repository.

18. The system of claim 16, the operations further comprising: conveying an offer of compensation from the data user to the individual in return for providing the subset of medical data to the data user.

19. The system of claim 15, wherein the medical data is retrieved from the number of independent data sources via an Application Programming Interface (API) for each of the number of independent data sources.

20. The system of claim 15, the operations further comprising: encrypting the medical data of the individual; standardizing the medical data retrieved from the number of independent data sources in the central repository; receiving a request for the medical data of the individual from a data user; and providing a decryption key to the data user to decrypt the medical data of the individual.