Enhancing Data Security and Access Control Using Machine Learning

Abstract

[0003] Techniques for controlling data access using machine learning are provided. In one aspect, first, second, and third training data sets are generated from a set of historical access records and a set of historical data records, where the access records correspond to requests for data and include information identifying whether the requests satisfy one or more data access rules, and the data records correspond to data elements and include information identifying whether the data elements satisfy one or more data access rules. One or more machine learning models are trained based on the first, second, and third training data sets to generate an output identifying whether the requests for data should be allowed.

Description

[Technical field]

[0001] Aspects of the present disclosure relate to data access and security, and more specifically, to using machine learning to drive data visibility, control, access, and security decisions. [Background technology]

[0002] Various global systems are used to collect and store data regarding any number of data subjects, such as patients, users, or any other individual or entity described by the processed and stored data. For example, medical data is often maintained for each patient at a particular facility. This can include any number of different data elements, such as diagnoses, genetic information, clinical records, medications the patient is taking (or has been previously prescribed), inpatient or outpatient surgical procedures, or other procedures that have been performed or recommended. In general, this data is subject to various protections and requirements related to the security of the data and the privacy of users. However, there are many cases where access to the data can be beneficial to the data subject or others without harming the data subject or violating their privacy.

[0003] Existing systems generally make data access difficult, causing significant confusion regarding which data elements are (or may be) public and which are protected. In many fields (e.g., healthcare), data access and security are largely controlled by various technologies with little flexibility and predictability regarding which elements of data can be shared, even when sharing would be beneficial to others. For example, in certain cases, a patient may unfortunately pass away due to complications or underlying medical conditions. During the patient's lifetime, medical data such as genetic information and diagnoses may be collected and correlated. Such information may also be beneficial for the patient's living relatives, for example, to determine whether they carry genetic markers that may predispose them to the same condition. If the relatives had access to such information, it could help them address the condition earlier and improve their quality of life. However, the current system is so rigid that relatives cannot access such information without the patient's consent, and, moreover, at this stage, unfortunately, cannot obtain it. Summary of the Invention [Problem to be solved by the invention]

[0004] In other industries, fearing losing proprietary knowledge to partners and competitors alike, they commonly prevent data access altogether, despite missing out on opportunities for innovation and growth. At a high level, this can have a detrimental effect on the progress of innovation in society, as valuable data that could be used by others to advance innovation is not publicly available due to access restrictions without consideration of the impact of such restrictions. Thus, a flexible and intelligent system for more granular control of data access is needed as an alternative to the existing all-or-nothing binary framework of data disclosure. [Means for solving the problem]

[0005] Certain embodiments provide a method for automatically controlling data access using one or more machine learning models. The method generally includes receiving a first request from a first user for data related to a second user; automatically determining whether the first request satisfies one or more data access rules by processing the first request using a first set of one or more trained machine learning models; upon determining that the first request satisfies the one or more data access rules, automatically obtaining a first plurality of data elements based on the first request; automatically determining whether each of the first plurality of data elements satisfies the one or more data access rules by processing each of the first plurality of data elements using a second set of one or more trained machine learning models; upon determining that a first set of data elements from the first plurality of data elements satisfies the one or more data access rules, determining whether the first set of data elements satisfies the one or more data access rules by processing the first set of data elements using a third set of one or more trained machine learning models; and upon determining that the first set of data elements satisfies the one or more data access rules, generating a custom report including the first set of data elements.

[0006] Certain embodiments provide a method for training one or more machine learning models to control data accessibility. The method generally includes: generating a first training data set from a set of historical access records, where each access record of the first training data set corresponds to a respective request for data and includes information identifying whether the respective request satisfies one or more data access rules; generating a second training data set from the set of data records, where each data record of the second training data set corresponds to a respective data element and includes information identifying whether the respective data element satisfies one or more data access rules; generating a third training data set from the set of historical access records, where each access record of the third training data set corresponds to a respective set of aggregated data elements and includes information identifying whether the respective set of aggregated data elements satisfies one or more data access rules; training one or more machine learning models based on the first, second, and third training data sets to generate an output identifying whether the request for data should be allowed; and deploying the one or more machine learning models to one or more computing systems.

[0007] Aspects of the present disclosure provide means for apparatus, processors, and computer-readable media for performing the methods described herein.

[0008] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of only a few of the various ways in which the principles of various aspects may be employed.

[0009] The accompanying drawings depict certain aspects of one or more embodiments and therefore should not be considered as limiting the scope of the disclosure. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an environment including an analytics server configured to control data access using machine learning, according to some embodiments disclosed herein. [Diagram 2] FIG. 2 illustrates a workflow for controlling data access using various access rules according to certain embodiments disclosed herein. [Diagram 3] FIG. 3 is a flow diagram illustrating a method for training a machine learning model to control data access based on characteristics of a data request, according to some embodiments disclosed herein. [Figure 4] FIG. 4 is a flow diagram illustrating a method for training a machine learning model to control data access based on characteristics of individual data elements according to some embodiments disclosed herein. [Diagram 5] FIG. 5 is a flow diagram illustrating a method for training a machine learning model to control data access based on characteristics of aggregated data elements that individually satisfy access rules, according to some embodiments disclosed herein. [Figure 6] FIG. 6 is a flow diagram illustrating a method for controlling data access using a trained machine learning model according to certain embodiments disclosed herein. [Figure 7] FIG. 7 illustrates a graphical user interface (GUI) for enhancing data access control and notifications according to certain embodiments disclosed herein. [Figure 8] FIG. 8 is a flow diagram illustrating a method for automatically controlling data access using one or more machine learning models according to certain embodiments disclosed herein. [Figure 9]FIG. 9 is a flow diagram illustrating a method for training one or more machine learning models to control data accessibility according to some embodiments disclosed herein. [Figure 10] FIG. 10 is a block diagram illustrating a computing device configured to train and use a machine learning model to control data access in accordance with some embodiments disclosed herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] To facilitate understanding, identical reference numerals have been used, whenever possible, to designate identical elements that are common to the figures. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further description.

[0012] The embodiments of the present disclosure provide techniques for effective data access control that ensures that data privacy and security are maintained while allowing flexible access when doing so is beneficial without corresponding harm. Advantageously, such a system can automatically provide access to valuable data in a defined manner such that data that can benefit from sharing is shared while sharing of data that may cause harm (e.g., by identifying specific individuals leading to privacy issues) is not performed. Such fine-tuned data sharing is not possible with existing methods that simply utilize an all-or-nothing approach to data sharing. For example, with current mechanisms that manually determine what data to share based on the shear volume of data collected by existing systems, it is not practically feasible to provide the level of data sharing flexibility described herein. Thus, such manual mechanisms may be overly cautious and may overly restrict access to data by not sharing most data.

[0013] In some embodiments, to enable such flexible data sharing, defined access rules are utilized to evaluate data requests and data elements in multiple tiers or steps (e.g., evaluate the request only, evaluate each individual data element, evaluate aggregated data elements) before providing (or refraining from providing) any data. In some embodiments, a set of one or more machine learning models is trained to classify requests and data elements based on such access rules. In doing so, embodiments of the present disclosure enable rapid evaluation and response to data requests while maintaining data security. Additionally, data integrity is ensured because the system utilizes objective models to evaluate requests (whereas current systems rely on subjective decisions).

[0014] In some embodiments, a set of access rules is utilized to drive data access decisions. In some embodiments, there may be any number of access rules in a given deployment. In some embodiments, the system may utilize a base set of access rules in an industry-agnostic manner, and additional rules may be added or modified based on the specific requirements and desires for a given industry or deployment. In some embodiments, the access rules are used to control data access during an initial manual phase, and decisions made based on the rules (e.g., by subject matter experts or other users) are used to train machine learning models to automatically provide analysis. That is, during what is referred to above as the initial manual phase, human reviewers may evaluate requests and data elements in light of the access rules to determine whether the request should be granted and / or the data should be shared. These manual decisions may be stored in records that include details of the request and / or data, labeled with the human decision. Such records may be used in machine learning algorithms to train machine learning models to perform similar analysis automatically.

[0015] In some embodiments, the access rules (and thus the model trained on the access rules) are used to ensure that data can be shared when access is deemed beneficial while maintaining privacy and security. In some embodiments, the system uses a set of three rules: a first access rule that specifies that if data is provided, it can only be used to improve humanity or society (without harming the data subject); a second access rule that specifies that the requesting entity must have legitimate intentions for the data; and a third access rule that specifies that the data must be protected and secured as much as possible without conflicting with other rules. Based on this framework, a model can be trained to effectively provide a dynamic data access system that allows and restricts access to data in an intelligent and flexible manner while respecting the access rules.

[0016] FIG. 1 illustrates an environment 100 including an analytic server 110 configured to control data access using machine learning, according to some embodiments disclosed herein. In the illustrated embodiment, a requesting user 105 may provide a request to the analytic server 110. The request typically identifies at least the requested data as well as the intended use of the data. In some embodiments, the request includes metadata or other additional data used to identify the requesting user 105 or to provide other additional information to give context to the request. In some embodiments, the request is associated with a requester profile that specifies, for example, the identity of the requesting user 105 (e.g., their name or other identifying information), the reason or purpose of the request, a timeline of when the data is needed, or any additional documentation to supplement or provide context to the request.

[0017] For example, assume that a user wants to determine whether they are at high risk for a particular disorder, such as deep vein thrombosis (DVT), based on their family history. In some embodiments, the user (acting as the requesting user 105) can provide a request, either directly or via another device, such as over a network, to the analysis server 110 containing this information. The analysis server 110 can be any suitable server in any suitable environment (e.g., on-premise, associated with an entity, in the cloud, etc.). In some embodiments, the request specifically identifies one or more data subjects. For example, the requesting user 105 can identify their family members as data subjects (e.g., "Does anyone in my family have a history of DVT?"). In another embodiment, the analysis server 110 evaluates the request to identify relevant data subjects. For example, based on the request (e.g., "Am I at high genetic risk for DVT?"), the system can determine that the relevant data subjects are relatives of the requesting user 105. This can be accomplished using, for example, natural language processing (NLP).

[0018] Additionally, in some embodiments, the request specifically identifies the desired data elements (e.g., identifies a particular report, test, or other piece of data). In another embodiment, the analytic server 110 identifies the relevant data elements based on analyzing the request using NLP or other techniques.

[0019] In the illustrated environment 100, the analytic server 110 includes a data sharing component 115 and a custom report generator 120. The data sharing component 115 generally evaluates the request to determine whether the request should be allowed (fully or partially) based on a set of access rules discussed herein, and further identifies, retrieves, and evaluates associated data elements to determine whether they should be provided to the data requester based on the same set of access rules discussed herein. In some embodiments, the data sharing component 115 evaluates the request and data in three tiers: a first tier that evaluates the request against the access rules, a second tier that evaluates each individual data element against the access rules, and a third tier that evaluates a collective set of data elements against the access rules. Only data elements that pass all tiers are included in the final report. The custom report generator 120 generally builds a custom report for the requesting user 105. This custom report may include any data elements approved for sharing by the data sharing component. In some embodiments, the custom report may further include the reason why any portion of any request (or the entire request) was denied or why any data was excluded, as described in more detail below. Although data sharing component 115 and custom report generator 120 are shown as separate components for conceptual clarity, in embodiments operations may be combined or distributed across any number of components and devices.

[0020] In some embodiments, the data sharing component 115 may first evaluate the request to determine whether the request should be denied outright, such as based on defined access rules. This may be referred to as "Tier 1" in some embodiments described herein. For example, the data sharing component 115 may determine whether granting access to the requested data, as specified in the access rules, would enhance humanity without harming the data subject, whether the request is guided by legitimate intent, whether the data remains protected, etc. In some embodiments, the data sharing component 115 does so using one or more trained models, as described in more detail below. For example, the data sharing component 115 may extract features of the request and process them using one or more models trained based on labeled access data from previous requests, as discussed further herein. Such features may include, but are not limited to, the identity of the requesting user 105 and / or the data subject, the relationship between them, the indicated purpose for requesting the data (which may be explicitly stated or may be determined based on processing the request using, for example, NLP, etc.), etc.

[0021] If the data sharing component 115 determines that the request should be denied (e.g., because the requesting user 105 intends to commercially use the data for advertising purposes, which is not a legitimate use that improves humanity), the data sharing component 115 can deny the request. The custom report generator 120 can then generate a report indicating that the request was denied and include the reason for the determination (e.g., indicating which access rules were failed).

[0022] In some embodiments, if the data sharing component 115 determines (e.g., using a trained model) that the request satisfies the access rules, the data sharing component 115 can begin a second layer of analysis by identifying relevant data elements and retrieving them from one or more data repositories 125. For example, the data sharing component 115 identifies the data repositories 125 in which the data may be contained. The data repositories 125 may be identified based on, for example, the identity of the requesting user 105, the identity of the data subject, the nature or context of the request (e.g., the particular type of data being requested), etc. The data sharing component 115 can then send a query to each identified repository to retrieve the relevant data.

[0023] In some embodiments, the data sharing component 115 then evaluates each individual data element based on the access rules (e.g., using one or more trained models). In embodiments, the data sharing component 115 may utilize the same model used to evaluate the request or may use a different set of trained models to evaluate the data elements. For each individual data element, if the data sharing component 115 determines that the data element satisfies the access rules, the data sharing component 115 may add it to a set of data elements that the requesting user 105 is potentially allowed to access. For any data that fails, the data sharing component 115 may refrain from disclosing it. In some embodiments, the custom report generator 120 will include the reason why a particular data element was excluded.

[0024] If multiple data elements are determined to meet the criteria, in some embodiments, the data sharing component 115 may then collectively evaluate the multiple data elements to determine whether they should be shared collectively. For example, a set of data elements may individually meet the rule (e.g., because they are used to improve humanity without identifying or harming the data subject), but the data elements may fail when evaluated collectively (e.g., because they may collectively be used to identify and / or harm the data subject). For example, each of gender, date of birth, and place of employment alone may not be individually sufficient to identify a data subject because there are many data subjects that individually match such a definition, but collectively, such information may only be relevant to a small group or a single data subject.

[0025] In some embodiments, based on the evaluation of the data sharing component 115, the custom report generator 120 then generates and returns a custom report to the requesting user 105. In some embodiments, the custom report generator 120 may further provide a notification to the data subject 130 indicating what data was shared. In some embodiments, the notification may further indicate the reason or purpose of the request, the identity of the requesting user 105, etc. In certain embodiments, the notification may further indicate any data elements that were withheld.

[0026] In the illustrated embodiment, the data subject 130 can provide feedback related to this data access to the analytic server 110. For example, the data subject 130 can indicate that they do not want one or more particular data elements to be shared, or that one or more of the withheld data elements should nevertheless be shared. In some embodiments, the system can refine the trained model based on this feedback.

[0027] In the illustrated embodiment, the data sharing component 115 utilizes trained models provided by training server 135. Although shown as separate servers for conceptual clarity, in some embodiments, the training server 135 and the analytics server 110 may operate as a single server. That is, models may be trained and used on a single server, or trained on one or more servers and deployed for use on one or more other servers.

[0028] As shown, training server 135 includes training data generator 140 and model trainer 145. Although shown as separate components for conceptual clarity, in some embodiments the operations of training data generator 140 and model trainer 145 may be combined or distributed across any number of components and devices.

[0029] Training data generator 140 generally uses historical access records 150 to generate training data sets that model trainer 145 uses to train one or more machine learning models. In some embodiments, historical access records 150 relate to previous decisions regarding data sharing. For example, each record in historical access records 150 can correspond to a particular request, and the record can indicate whether the request was granted. In some embodiments, for each denied request, the corresponding record can also indicate the reason the request was denied. In some embodiments, for each approved request, the corresponding record can indicate the associated data elements, whether the release of each individual data element was approved, whether the aggregated data set was approved, etc.

[0030] In some embodiments, the training data generator 140 generates a separate training data set for each model to be trained. For example, the model trainer 145 can train a separate model for each tier of analysis, including a first set of one or more models that evaluate whether a request satisfies an access rule, a second set of one or more models that evaluate whether each individual data element satisfies the access rule, and a third set of one or more models that evaluate whether an aggregated data element satisfies the access rule. Similarly, for each tier, the model trainer 145 can train a separate model for each access rule. For example, the model trainer 145 can train a first model that determines whether a request satisfies a first rule (e.g., whether the request benefits humanity), a second model that determines whether the request satisfies a second access rule, and a third model that determines whether the request satisfies the second access rule. Similarly, model trainer 145 may train a first model to determine whether an individual data element satisfies the same first rule, a second model to determine whether the individual data element satisfies a second access rule, and a third model to determine whether the individual data element satisfies a third access rule. Model trainer 145 may also train a third model to determine whether an aggregated data element satisfies the first rule, a second model to determine whether the aggregated data element satisfies the second access rule, and a third model to determine whether the aggregated data element satisfies the third access rule.

[0031] In some embodiments, the generated training data set may vary based on the target model. For example, to train a model for the request tier of analysis, the training data generator 140 may generate a data set from historical access records 150, where each training record specifies input features that are aspects of the request (e.g., determined reason, requester identity, etc.) and a corresponding label indicating whether the request satisfied the access rules and therefore was approved (or was determined to pass or fail the respective individual data access rules). For example, a human user may evaluate the request to determine whether it satisfies the access rules. The request data (or metadata) may then be recorded along with the user's decision as an example of labeling. For each data element tier, the training data generator 140 may generate a set of data records, where each record corresponds to a particular data element previously requested and / or shared, and where each record specifies input features related to the characteristics of the data element (e.g., related fields, predefined privacy levels, associated regulations, etc.), as well as a label indicating whether it was determined that allowing access to the data element satisfied the access rules.

[0032] In the illustrated embodiment, the model trainer 145 uses the generated training dataset to train a set of models. In general, training each model involves providing the indicated input features (which may start with random parameters) as input to the model for one or more training records. The generated output is then compared to the labels of the training records, and the model trainer 145 can calculate a loss based on the difference between the generated output and the provided labels. This loss can then be used to modify the internal parameters or weights of the model (e.g., via backpropagation). By iteratively processing each training record, the model is iteratively refined to generate accurate access decisions based on the input features.

[0033] As shown, training server 135 deploys these trained models to analytic server 110 for use at run time. In some embodiments, training server 135 also receives updates from analytic server 110 (e.g., in the form of feedback from data subjects or subject matter experts). These updates can be used to further refine the models.

[0034] FIG. 2 illustrates a workflow 200 for controlling data access using various access rules, according to some embodiments disclosed herein. The workflow 200 begins when a request 205 is received. The request typically indicates or identifies the desired data. This indication may be of any specificity, including specifying a particular data element (e.g., identifying a particular record), identifying a type of data (e.g., "lab results"), indicating the desired content (e.g., "records related to DVT"), etc. In some embodiments, the request 205 also identifies one or more data subjects. As described, a data subject is a person for whom the requested data is directed. In some embodiments, identifying a data subject may also be of any level of specificity, including identifying specific people, or indicating a group of people (e.g., "my relatives," "males under 60," etc.).

[0035] In some embodiments, the request 205 further identifies the requesting entity, the purpose of the data, etc. In some embodiments, indicating the purpose of the data can include explicitly stating a reason, selecting a predefined purpose, etc. In certain embodiments, the request 205 includes natural language text. In one such embodiment, the system can use NLP to identify the requested data, the associated data subjects, and / or the purpose of the request. For example, the analytics server can use NLP to extract concepts from the text and determine the relevant industry or field (e.g., healthcare), the desired data elements, the associated data subjects, etc. based on the concepts identified in the request 205.

[0036] At block 210, the analytics server determines whether the request 205 satisfies one or more defined access rules. In some embodiments where a machine learning model is not used, the determination involves comparing the concepts identified (or specified) in the request 205 to one or more defined lookup tables that specify acceptable or legitimate purposes for the data. In certain embodiments, these lookup tables are industry specific, such that a given purpose may be acceptable in some industries but not in others.

[0037] In some embodiments, the analytics server instead utilizes a trained machine learning model to determine whether the request 205 satisfies the access rules at block 210. In some embodiments, as described above, the one or more machine learning models are trained based on manually curated access records that include labeled training data. Further, as described, the labeled training data can be used to train the one or more machine learning models to automatically perform an analysis of whether the request 205 satisfies the access rules. In some embodiments, the access rules relate to a defined code of ethics for data processing, as described.

[0038] In certain embodiments, a separate model is trained for each access rule. In some such embodiments, if the analytic server utilizes three access rules, block 210 includes passing the request 205 through three separate machine learning models. The input to the models (and thus the input used to train the models) generally includes features of the request 205, such as the indicated purpose of the data or the field or industry to which the data pertains. For example, a request indicating that the data will be anonymized and used to further medical research may be approved, while a request indicating that the data will be sold to advertising agencies may be denied. In general, the request features evaluated may include any number of different concepts extracted from the request 205. As noted above, in some embodiments, the features may include the identity of the requesting user and / or data subject, the relationship between them, the indicated purpose for requesting the data (which may be explicitly stated or may be determined based on processing the request using NLP, for example), the field or industry to which the request or data pertains, etc.

[0039] As shown, if the request 205 does not pass an access rule (e.g., as indicated by the trained model rejecting the request 205), the workflow 200 proceeds to block 250, where the analytic server generates a custom report that includes one or more reasons for the rejection. In some embodiments, the analytic server can indicate which access rules the request 205 failed. The analytic server can identify these failed rules based on the model that rejected the request. For any trained model that rejected the request, the analytic server can indicate that the corresponding access rule was not satisfied.

[0040] If the request 205 satisfies all access rules (e.g., if it is approved by all machine learning models at this stage), the analytic server generates a data query 215, which is sent to one or more data repositories 215. In some embodiments, the analytic server generates the data query 215 based on the requested data indicated by the request 205. For example, if the request asks about the requester's familial risk of developing DVT, the analytic server can generate a query to retrieve data records corresponding to data subjects related to the requester and associated with DVT (e.g., diagnosis, test results, genetic markers, name and / or location of the healthcare provider where the test was performed, accuracy of the test, treatment proposed or completed, etc.).

[0041] In the illustrated embodiment, the data repository 125 stores data created by one or more data generators 220. Data generators 220 generally include any data source, such as a medical or non-medical facility, a particular machine or equipment, the data subjects themselves, others who facilitated the collection of the data, etc. For example, in the case of medical data, data generators 220 may include patients, medical professionals, equipment used to obtain or record data from patients, clinics or facilities where the data was collected, etc.

[0042] As shown, the data repository 125 returns relevant data elements 225 based on the data query 215. As used herein, a data element 225 is generally a separate piece of data and can include any number and type of values. For example, a data element 225 may specify a medical test result, indicate the test performed, specify the accuracy of the test, indicate the facility where the test was performed, etc.

[0043] In block 230, these data elements 225 are each individually evaluated to determine whether they satisfy the access rules. In some embodiments, the analytic server utilizes one or more trained machine learning models to perform this review. In some embodiments, the analytic server utilizes models that are specifically trained to evaluate individual data elements. That is, while the models used in block 210 were trained to evaluate request features, the models used in block 230 can be trained to evaluate data elements. In some embodiments, the models used in block 230 are trained similarly to the models discussed above with reference to block 210. For example, the system can obtain historical access records or data records that indicate, for each data element in the data record, whether a human user approved access (or whether a user determined that the data element passed a particular access rule).

[0044] Each such record may specify one or more characteristics of the data as input features. In embodiments, these features may include the type of data, the specificity of the data, the origin of the data, the field to which the data pertains, whether the data specifically identifies a data subject, etc. In some embodiments, one or more of these features are specified in metadata associated with the data element 225. In some embodiments, if the data element 225 includes natural language text (e.g., clinical notes), the analytics server may utilize natural language processing to extract concepts to be used as input features. Additionally, in some embodiments, each record is labeled with an indication of whether a human user determined that the data element passed (or failed) one or more data access rules. In some embodiments, a model is then trained based on the records.

[0045] If a given data element fails any of the access rules, it is excluded from the report at block 250. In certain embodiments, the analytic server may also include one or more reasons for the denial (e.g., indicating that one or more data elements were withheld due to failing a particular rule). In some embodiments, the analytic server may additionally generate and send a notification to the data subject indicating which data elements were withheld and which were released.

[0046] In the illustrated workflow 200, any data elements 225 that are determined to satisfy the access rules are combined to form a set of aggregated data elements ("aggregated data") 235. As shown, this aggregated data 235 is then evaluated in block 240 to determine whether the aggregated data 235 satisfies the data access rules. For example, two or more data elements 225 may pass an access rule when evaluated individually in step 230, but when combined, fail when aggregated because the elements enable identification of the underlying data subject.

[0047] In some embodiments, the evaluation in block 240 is also performed using one or more trained machine learning models. In some embodiments, the analytic server utilizes models trained specifically for this aggregated evaluation. That is, the analytic server may utilize a first set of one or more models to perform the request evaluation in block 210, a second set of one or more models to perform the data evaluation in block 230, and a third set of one or more models to perform the aggregated data evaluation in block 240. In some embodiments, the features evaluated in block 240 may reflect the features utilized in block 230.

[0048] As shown, if the aggregated data passes the access rules, the analytic server generates the custom report using the approved data elements (in block 245). In the illustrated embodiment, if the aggregated set fails one or more access rules, the analytic server generates the custom report while excluding at least one of the data elements. In some embodiments, the analytic server may refrain from providing any data elements. In another embodiment, the analytic server may provide some subset of the approved data elements.

[0049] For example, upon determining that the aggregated data 235 failed one or more access rules, the analytic server may remove one or more data elements from the set and re-evaluate the aggregated data set using the model. In some embodiments, the analytic server may iteratively evaluate different combinations of data elements to identify which data elements should be removed from the set. For example, the analytic server may attempt to find a combination of data elements that passes the rules with the fewest elements removed (so that the analytic server can return as much data as possible).

[0050] 3-5 further explain techniques for training the machine learning models discussed herein, including for evaluating data requests, data elements, and aggregated data.

[0051] FIG. 3 is a flow diagram illustrating a method 300 for training a machine learning model to control data access based on characteristics of a data request, according to some embodiments disclosed herein. In some embodiments, the method 300 can be used to train a model to evaluate requests (e.g., at block 210 of FIG. 2). The method 300 begins at block 305, where a training server (e.g., training server 135) obtains a set of historical access records. In some embodiments, each historical access record corresponds to a previous data request and includes a label indicating whether a human reviewer approved the request (and / or whether the request was determined to satisfy one or more data access rules). For example, during an initial manual / training phase, the training server can collect data as reviewers evaluate and approve or reject requests for data. Based on this monitoring, the training server can build a training dataset of historical access records.

[0052] At block 310, the training server selects one of the historical access records. In embodiments, this selection can utilize any suitable criteria (e.g., starting with the oldest record, starting with the most recent record, etc.) as the training server iterates through each historical access record in the training set. Method 300 then proceeds to block 315, where the training server extracts one or more features of the request corresponding to the selected record. These features are used as input features to the machine learning model. This can include extracting concepts from the request, such as the purpose of the request, the field or industry to which the request pertains. For example, the training server can determine whether the request pertains to health or well-being, economic benefits, etc. In certain embodiments, the training server utilizes NLP to extract these features from the request. In some embodiments, the request may have been previously evaluated to extract features, which can be stored in the access record. In some embodiments, each access record is further associated with a label indicating whether the request was approved or denied.

[0053] Method 300 then proceeds to block 320, where the training server trains one or more machine learning models based on the selected records. In some embodiments, the training server does so by providing the features (extracted in block 315) as input to the model. This model may be a new model initialized with random weights and parameters, or may be partially or fully pre-trained (e.g., based on a previous training round). Based on the input features, the model being trained generates some output (e.g., a classification of one or more access rules as "pass" or "fail"). In embodiments, the training server may compare this generated classification with the actual label of the record (as indicated in the record) and calculate a loss based on the difference between the actual result and the generated result. This loss is then used to refine one or more internal weights and parameters of the model (e.g., via backpropagation) so that the model learns to classify requests more accurately.

[0054] In some embodiments, the training server trains a model to analyze requests given a collective set of access rules. That is, the training server trains a model to simultaneously evaluate requests given all access rules, and can output a binary "pass" or "fail" (or a set of decisions, one for each rule) based on whether the request passes all access rules or fails at least one. In other embodiments, as described above, the training server trains a separate model for each access rule.

[0055] Method 300 then proceeds to block 325, where the training server determines whether additional training is required. This may include evaluation of any termination criteria, such as whether any additional historical access records remain in the training dataset. In various embodiments, other termination criteria may include, but are not limited to, whether a predefined amount of time or computing resources has been spent training the model, whether the model has reached a predefined minimum accuracy, etc. If additional training is not yet complete, method 300 returns to block 310.

[0056] If not, method 300 proceeds to block 330, where the training server deploys the trained model to analyze incoming data requests at runtime. In some embodiments, this includes sending some indication of the trained model (e.g., a weight vector) that can be used to instantiate the model on another device. For example, the training server can send the weights of the trained model to the analysis server. The model can then be used to evaluate newly received data requests.

[0057] FIG. 4 is a flow diagram illustrating a method 400 for training a machine learning model to control data access based on characteristics of individual data elements, according to some embodiments disclosed herein. In some embodiments, the method 400 can be used to train a model to evaluate individual data elements (e.g., at block 230 of FIG. 2). The method 400 begins at block 405, where a training server retrieves one or more historical access records, each corresponding to a previous data request. In some embodiments, the training server selects access records for which the request was approved. That is, since no data is retrieved or analyzed for rejected requests, the training server can only retrieve approved requests for which at least one data element was retrieved and evaluated by a human reviewer. In some embodiments, each historical access record is associated with one or more data records, each corresponding to a respective data element retrieved based on the request.

[0058] Method 400 then proceeds to block 410, where the training server selects a historical access record from the set of training access records. In embodiments, this selection may utilize any suitable criteria (e.g., starting with the oldest record, starting with the most recent record, etc.) as the training server iterates through each historical access record in the training set. At block 415, the training server identifies data records associated with the selected access record. In some embodiments, each data record corresponds to a data element retrieved in response to a request corresponding to the selected access record. For example, assume that a request corresponding to the selected access record resulted in 10 data elements being retrieved from a data repository. Thus, in some embodiments, the access record includes, is linked to, or is otherwise associated with 10 data records (one for each data element). In some embodiments, each data record includes characteristics of the corresponding data element as well as a label indicating whether the data element satisfies one or more access rules.

[0059] At block 420, the training server selects one of the identified data records. Method 400 then proceeds to block 425, where the training server extracts one or more features of the data element corresponding to the selected record. The features generally correspond to characteristics of the data element, such as the type of data, the source of the data, a predefined sensitivity or privacy level of the data, etc. In some embodiments, the features include a data profile for the data element, where the data profile is a metadata structure that specifies the relevant features. In certain embodiments, the training server also extracts one or more data source profiles for the data element. The data source profile is typically a metadata structure that specifies the features of the source of the data element. For example, if the data element was collected by a particular medical facility, the data source profile may specify the features of the facility (name, location, etc.). Similarly, if the data element was collected using a particular device, the profile may specify the identity and type of the device, maintenance records, accuracy of the device, etc. In some embodiments, each data record may be associated with any number of profiles that correspond to entities involved in collecting and transferring the data to the data repository.

[0060] Method 400 then proceeds to block 430, where the training server trains one or more machine learning models based on the selected data records. In some embodiments, the training server does so by providing the features (extracted in block 425) as input to the model. This model may be a new model initialized with random weights and parameters, or may be partially or fully pre-trained (e.g., based on a previous training round). Based on the input features, the model being trained generates some output (e.g., a classification of one or more access rules as "pass" or "fail"). In embodiments, the training server may compare this generated classification to the actual label (included with the data records) and calculate a loss based on the difference between the actual and generated results. This loss is then used to refine one or more internal weights and parameters of the model (e.g., via backpropagation) so that the model learns to more accurately classify individual data elements.

[0061] In some embodiments, the training server trains a model to analyze a data element given a collective set of access rules. That is, the training server trains a model to simultaneously evaluate a data element given all access rules, and can output a binary "pass" or "fail" (or a set of decisions, one for each rule) based on whether the data element passes all access rules or fails at least one. In other embodiments, as described above, the training server trains a separate model for each access rule.

[0062] Next, method 400 proceeds to block 435, where the training server determines whether the selected access record includes at least one more additional data record that has not yet been evaluated. If so, method 400 returns to block 420. If not, method 400 proceeds to block 440, where the training server determines whether additional training is required. This may include evaluation of any termination criteria, such as whether any additional historical access records remain in the training data set. In various embodiments, other termination criteria may include, but are not limited to, whether a predefined amount of time or computing resources has been spent training the model, whether the model has reached a predefined minimum accuracy, etc. If additional training has not yet been completed, method 400 returns to block 410.

[0063] If not, method 400 proceeds to block 445, where the training server deploys the trained model to analyze individual data elements retrieved at run time. In some embodiments, this includes sending some indication of the trained model (e.g., a weight vector) that can be used to instantiate the model on another device. For example, the training server can send the weights of the trained model to the analysis server. This model can then be used to evaluate data elements retrieved in response to a newly received data request.

[0064] FIG. 5 is a flow diagram illustrating a method 500 for training a machine learning model to control data access based on characteristics of aggregated data elements that individually satisfy an access rule, according to some embodiments disclosed herein. In some embodiments, the method 500 can be used to train a model to evaluate aggregated data elements corresponding to aggregated data (e.g., at block 240 of FIG. 2). The method 500 begins at block 505, where a training server retrieves one or more historical access records, each corresponding to a previous data request. In some embodiments, the training server selects access records for which the request was approved. That is, since no data is retrieved or analyzed for rejected requests, the training server can only retrieve approved requests for which at least one data element was retrieved and evaluated by a human reviewer. In some embodiments, the training server retrieves only records for which at least two data elements were retrieved (e.g., such that aggregated data may cause a different result than an individual evaluation). In some embodiments, the historical access records are each associated with one or more data records, each corresponding to a respective data element retrieved based on the request.

[0065] Method 500 then proceeds to block 510, where the training server selects a historical access record from the set of training records. In some embodiments, this selection may utilize any suitable criteria (e.g., starting with the oldest record, starting with the most recent record, etc.) as the training server iterates through each historical access record in the training set. At block 515, the training server identifies data records associated with the selected access record that were determined to satisfy the access rule. That is, the training server may identify which data elements, if any, were deemed to individually satisfy the access rule. For example, assume that the system retrieves 10 data elements based on a request, and three data elements failed one or more data access rules when individually evaluated. In some embodiments, the training server may identify a subset of the data elements (e.g., the remaining seven) that passed the individual review.

[0066] At block 520, the training server selects one of the identified data records that passed the individual review. Method 500 then proceeds to block 525, where the training server extracts one or more features of the data element corresponding to the selected record. As noted above, the features generally correspond to characteristics of the data element, such as the type of data, the source of the data, a predefined sensitivity or privacy level of the data, etc. In some embodiments, the features include a data profile of the data element, where the data profile is a metadata structure that specifies the associated features. In certain embodiments, the training server also extracts one or more data source profiles of the element. The data source profile is typically a metadata structure that specifies the features of the data source. For example, if the data was collected by a particular medical facility, the data source profile may specify the features of the facility (name, location, etc.). Similarly, if the data was collected using a particular piece of equipment, the profile may specify the identity and type of the equipment, maintenance records, accuracy of the equipment, etc. In some embodiments, each data record may be associated with any number of profiles that correspond to entities involved in collecting and transferring the data to the data repository.

[0067] At block 530, the training server determines whether the data element was included in the generated data report. If the data was excluded, a human must have determined that including the data would cause the collection set to violate one or more data access rules. In contrast, if included, a reviewer determined that the selected element satisfies the access rules even when combined with other included elements.

[0068] Next, method 500 proceeds to block 535, where the training server determines whether the selected access record includes at least one additional data record that has not yet been evaluated. If so, method 500 returns to block 520. If not, method 500 proceeds to block 540, where the training server trains one or more machine learning models based on the identified data records that individually satisfied the access rules. In some embodiments, the training server does so by providing the features of each data record (extracted in block 525) as input to the model. This model may be a new model initialized with random weights and parameters, or may be partially or fully pre-trained (e.g., based on a previous training round). Based on the input features, the model under training generates some output (e.g., a classification of the aggregated set as "pass" or "fail") of one or more access rules. In an embodiment, the training server can compare this generated classification to the actual result (e.g., the actual set of data elements included in the report) determined in block 530, and calculate a loss based on the difference between the actual result and the generated result. This loss is then used to refine one or more internal weights and parameters of the model (e.g., via backpropagation) so that the model learns to more accurately classify the aggregated set of data elements.

[0069] In some embodiments, the training server trains a model to analyze the aggregated data taking into account the collective set of access rules. That is, the training server trains a model to simultaneously evaluate the aggregated data taking into account all access rules, and can output a binary "pass" or "fail" (or a set of decisions, one for each rule) based on whether the aggregated set passes all access rules or fails at least one. In other embodiments, as described above, the training server trains a separate model for each access rule.

[0070] Method 500 then proceeds to block 545, where the training server determines whether additional training is required. This may include evaluation of any termination criteria, such as whether any additional historical access records remain in the training dataset. In various embodiments, other termination criteria may include, without limitation, whether a predefined amount of time or computing resources has been spent training the model, whether the model has reached a predefined minimum accuracy, etc. If additional training is not yet complete, method 500 returns to block 510.

[0071] If not, method 500 proceeds to block 550, where the training server deploys the trained model to analyze the aggregate set of data elements obtained at run time. In some embodiments, this includes sending some indication of the trained model (e.g., a weight vector) that can be used to instantiate the model on another device. For example, the training server can send the weights of the trained model to the analysis server. The model can then be used to evaluate the aggregated set of data elements that were determined to individually satisfy the rule.

[0072] 6 is a flow diagram illustrating a method 600 for controlling data access using a trained machine learning model, according to some embodiments disclosed herein. In one embodiment, method 600 provides a common industry-wide methodology to leverage machine learning and / or rules engines to act as a trusted source for retrieving relevant data based on a valid request.

[0073] Method 600 begins at block 605, where an analytic server (e.g., analytic server 110) receives a request for data access. As described above, the request generally indicates the desired data, such as by explicit reference, by providing characteristics that can be used to filter or identify the data, etc. Additionally, in embodiments, the request generally indicates the purpose or reason for the request. In some embodiments, the request includes a natural language textual description of the requested data and / or proposed use. For example, the request may include a question such as "Am I at increased risk for DVT because of my family history? If so, what markers do I need to screen for?" In some embodiments, the request may additionally include other fields, such as a timeline for which the data is needed (or desired), and any additional supporting documentation that may be provided. In some embodiments, these request characteristics are included in a metadata structure called a request profile (either provided directly or generated based on evaluating the request using NLP).

[0074] Method 600 then proceeds to block 610, where the analytics server processes the request profile using a first set of one or more trained machine learning models. In some embodiments, as described above, these models are generally trained to determine whether a request satisfies one or more access rules. For example, to determine whether a request improves humanity without harming the data subject, the analytics server may determine whether the request relates to health or well-being (indicating that it will benefit humanity), whether the use involves commercial gain (indicating that it will not), etc. Additionally, the models may be used to determine whether the proposed use is legitimate (e.g., whether it is clinical or medical, or whether the user is simply curious or intends to misuse the data). Similarly, the models may be used to determine whether the data is protected (e.g., whether confidentiality will remain maintained). In some embodiments, as described above, separate trained models are used to evaluate the request taking into account each individual access rule.

[0075] In block 615, the analytic server determines whether the request passes the access rules based on the classification provided by the model. For example, if the request is for commercial gain, the analytic server can deny the request.

[0076] If the request does not pass, method 600 proceeds to block 660, where the analytics server generates a custom report denying the request. In some embodiments, the report includes the reason the request was denied (e.g., specifying which rules were violated). If the request satisfies the access rules, method 600 proceeds to block 620.

[0077] At block 620, the analytic server retrieves the requested data from one or more data repositories. Method 600 then proceeds to block 625, where the analytic server processes one of the retrieved data elements using a second set of one or more trained models. That is, the analytic server processes each data element individually. In some embodiments, the analytic server evaluates each data element using a single model. In others, the analytic server uses a set of models (e.g., one per data access rule).

[0078] In some embodiments, processing the data element includes extracting features or characteristics of the data element (e.g., one or more data profiles for the data and / or the source or generator of the data). These features are then used as inputs for one or more models. At block 630, the analytic server determines whether the selected data element satisfies all access rules. If not, method 600 proceeds to block 635, where the analytic server blocks the selected data element (e.g., flags it for exclusion from custom reports, discards it, or otherwise stops processing or considering it). If the analytic server determines that the data element passes the rules, the analytic server adds it to the subset of approved data elements and method 600 proceeds to block 640.

[0079] Continuing with the example above for a DVT-related request, the analytic server may determine that some data elements may enhance humanity by using them without harming or identifying the data subject, such as tests and / or DVT markers identified, the requester's family history, diagnoses of relatives, types of tests performed, etc. In contrast, some examples of data elements that may fail this rule because they do not enhance humanity or may potentially harm the data subject include doctor's notes, specific identities of family members who have or have had DVT, etc.

[0080] Similarly, as examples of elements where a usage may be considered legitimate, the analysis server may determine that data such as DVT markers, diagnosis, type of test used, etc. are legitimate uses. In contrast, the analysis server may determine that data elements such as any non-DVT related history, non-DVT related tests, etc. are not legitimate uses given the request. Such elements may be restricted. Additionally, as examples of elements where the analysis server may determine that data is not protected, the analysis server may determine that DVT markers and diagnoses are acceptable, but that data elements such as a specific patient name, date of birth, non-DVT diagnosis, etc. should be excluded.

[0081] 6, at block 640, the analytic server determines whether there are any additional data elements that have been obtained but not yet evaluated. If so, the method 600 returns to block 625. If not, the method 600 proceeds to block 645.

[0082] At block 645, the analytic server processes the aggregated set of remaining data elements (e.g., data elements found to individually satisfy the rules) using a third set of one or more machine learning models. As noted above, this may include using the third set of models to provide an aggregated set of features (from each data element in the set of approved elements). At block 650, the analytic server determines whether the aggregated data passes the data access rules. If so, method 600 proceeds to block 660, where the analytic server generates a report including the aggregated data. In some embodiments, if any elements are excluded (e.g., at block 635), the analytic server may include an explanation (e.g., identifying the rules that were failed for each excluded data element).

[0083] If at block 650 the analytic server determines that the aggregated data fails to pass the set of rules, method 600 proceeds to block 655, where the analytic server excludes at least one of the data elements from the final report. For example, a data element identifying an involved medical professional or facility location may pass an access rule individually, but when combined with other approved data elements may allow the data subject to be identified or may violate other access rules. In some embodiments, the analytic server may iteratively remove one or more data elements from the aggregated data and reprocess the remaining set until a satisfactory aggregated set of data elements is found. Method 600 then proceeds to block 660.

[0084] In some embodiments, a notification may also be sent to the data subject informing them of what data was shared. In certain embodiments, the notification also indicates who made the request, the reason for the request, etc.

[0085] As another example of the evaluation of block 615, assume that an adopted individual requests to know the current location of their biological parents in order to receive information regarding their medical history. In one embodiment, such a request may be denied at block 615 because the stated purpose (receiving and reviewing the medical history) can be met with a less intrusive request (e.g., a specific request for data rather than the parents' location).

[0086] As another example, assume that an adopted individual requests general information about his or her birth parents to verify his or her medical history. In one embodiment, this request may pass at block 615 (e.g., because the requester is valid and the requested data and stated purpose are consistent), and the data may be obtained from one or more sources (such as the relevant adoption agency) at block 620. Some data may pass the access rules at block 630 (such as the parents' names, adoption date, family history, basic medical history, etc.). In contrast, data such as the parents' current contact information, the parents' social security numbers, etc., would fail because they violate the access rules.

[0087] As an example of data elements that, when aggregated, may fail the evaluation at block 650, consider the example of an adopted child. Although data such as the name of each parent and the date or place of adoption may individually pass the rules (at block 630), such data may not pass the evaluation at block 650 (e.g., because it would allow the parents to be identified). In contrast, data such as basic medical history may pass this aggregated evaluation.

[0088] As yet another example, assume that an individual already knows the identity of a biological parent and requests that the parent's health insurance company release medical genetic testing information to determine genetic risk factors. In one embodiment, such a request may pass evaluation at block 615 because it is a valid request for a valid purpose that satisfies the rules of access. At block 630, data such as the parent's physical attributes (e.g., height, weight, BMI, etc.), insurance information, personal responses to surveys or questionnaires (e.g., drug use), and the identity of the company that performed the test may be denied. In contrast, data such as the date the test was performed, the location of the testing facility, and the specific genetic biomarker values ​​found would satisfy the rules at block 630. However, at block 650, data such as the location of the facility, the date of the test, and the doctor's note would fail the aggregate analysis, while data such as the identified biomarkers would pass.

[0089] As yet another example of the evaluation at block 615, assume that a local government official requests report cards or grade information for every student in a county in order to improve educational outcomes and prevent students from dropping out of school. In one embodiment, such a request would fail the evaluation at block 615 because the intent (to improve outcomes and reduce dropout) can be met with a less intrusive request that does not share such data.

[0090] Suppose instead that a government official wishes to improve educational outcomes and requests information about parents who are concerned about their children's education and have requested additional assistance. The request may indicate that the official wishes to augment or modify strategies regarding tutoring and / or classes for these concerned individuals to improve educational outcomes. In one embodiment, such a request may pass the evaluation at block 615 because it is valid and is limited to the least intrusive data necessary to satisfy the intent.

[0091] In one embodiment, data such as parent-teacher notes, parent's names, subjects of interest, ages of students, names of their teachers, supervisors, and learning techniques used may satisfy the rule at block 630. Such data is relevant and does not harm the subject or violate the rule. In contrast, data such as a student's specific report card, parent's financial situation, a student's specific identifier, etc. may fail this evaluation at block 630 because it may harm the data subject or is otherwise not necessary to satisfy the intent.

[0092] Continuing with the example above of a government official requesting information about a parent or student who requested additional assistance, some data, such as the student's name (e.g., contained in a note between the parent and teacher), the specific grade received on a given test, the parent's or teacher's name, etc., may fail the evaluation at block 650. Such data, taken as a whole, may cause harm to the subject. In contrast, data such as subjects of interest, known learning disabilities, age groups or ranges, etc. may pass this evaluation and be included in the report.

[0093] As yet another example of the application of method 600, assume that a government official requests information about taxpayers in each household in a county in order to provide a taxpayer-specific rebate. In one embodiment, the request may pass evaluation at block 615 because the requester's identity and request / intent are valid. At block 630, data such as the taxpayer's social security number, total income, number of dependents, and zip code may each pass individual analysis at block 630 because they can satisfy the request without causing harm. In contrast, data such as the individual's citizenship status, identifiers, disability status, etc. may fail. Overall, at block 650, data such as the social security number, number of dependents, total income, etc. may fail because they could cause harm to the subject. In contrast, data such as the number of taxpayers in the area may pass.

[0094] As an additional example, assume that a government official requests information about the number of people covered by public insurance in order to access insurance for all residents. Such a request may pass evaluation at block 615. At block 630, data such as each entity's family income, the zip code where they live, pre-existing health conditions, etc. may fail the access rules. In contrast, data such as taxpayer information, age, social security number, place of residence, employment status, etc. may pass this individual evaluation because they can accommodate the request without harm. However, at block 650, data such as social security number, age, marital status, etc. may fail the aggregated review, while data such as the subject's eligibility, name, etc. may pass.

[0095] As yet another example, suppose an airline requests the identity of all individuals who have come into contact with an individual with a contagious disease over a certain period of time in order to minimize the risk of spreading the disease and notify relevant passengers of the concern. Such a request may fail evaluation at block 615 because it can be addressed with a less intrusive request.

[0096] Continuing with the above example, suppose instead that the airline requests a determination as to whether any passenger has come into contact with an individual with a contagious disease (without specifically identifying the passenger). In one embodiment, this request may pass evaluation at block 615. At block 620, relevant data may be obtained, such as the passenger's identity, location (e.g., using social media or GPS), calendar, associated testing agencies and laboratory results. At block 630, data such as the passenger's personal name or identifier, age, pre-existing conditions, etc. may be excluded. However, data such as contact tracing information (e.g., location data), current health results, etc. may be included. At block 650, data such as, in general, the names of people who have come into contact with the passenger, the passenger's age, the current location of individuals potentially with a contagious disease, etc. may be excluded. In contrast, data such as a binary "yes" or "no" indication as to whether someone has come into contact with an individual with a contagious disease, whether the contact was within a predefined time period, etc. may pass the rule.

[0097] As another example, assume that a patient (or potential patient) requests information about patients who have had retinal detachment surgery from one or more facilities in order to select a treatment plan and healthcare provider for his or her surgery. Such a request may fail the evaluation at block 615 because the request or data intended can be satisfied with a less intrusive request or data.

[0098] Suppose instead that the patient requested information about the success rate of such surgeries, or any permanent damage or harm caused by them. This request may pass evaluation at block 615. At block 630, data such as specific practice locations, specific patient information, etc., may fail review. In contrast, data such as a list of clinics and / or surgeons performing the surgery, an indication of factors that affect success rates, a list of medical equipment used in the surgery, eye measurements, or other patient data may pass this evaluation.

[0099] However, in block 650, data may be excluded such as specific clinics or individual surgeons with low success rates, specific devices used in procedures, etc. In contrast, data such as a list of surgeons with high success rates, signs of complications or harm, etc. may be included.

[0100] As another example, assume that a government official or contracted non-profit organization requests data related to clinical trials of a vaccine currently under development in order to evaluate the results. The request can pass evaluation at block 615 and the data can be obtained. At block 630, information such as the ingredients of the vaccine, side effects, dates or times the vaccine was administered, dosages, reports of concerns, independent evaluations of the vaccine, stage of development, phase of the trial, number of participants, adverse events reported, indications of patients dropping out of the trial, etc., can all pass the access rules. In contrast, data such as the names, locations, addresses, etc. of specific patients may fail this review.

[0101] Continuing with this example, the names and locations of specific trials, the vaccine pricing structure, costs, etc. may all be filtered out together at block 650. In contrast, data such as vaccine efficacy, antibody or immune responses by age group, reported side effects, etc. may pass this collective review for inclusion in the report.

[0102] As another example, assume that a researcher requests access to raw imaging data of patients who have undergone surgical procedures in order to analyze morphological changes over time around the surgical site. Such a request may pass evaluation at block 615. At block 630, data such as the hospital or site where the surgery is performed, the equipment used in the surgery, the imaging equipment used to collect the data, doctor's notes, patient complaints, side effects, etc. may pass individual evaluation. In contrast, data such as the location of the facility, the patient's name, the patient's medical history, etc. may fail this review.

[0103] Data such as the raw images, summaries of pre-existing conditions related to the images or procedures may pass the aggregated review in block 650. In contrast, data such as physician notes unrelated to the image analysis, physician names or identifiers, the specific medical equipment used to capture the images, side effects unrelated to the images, etc. may be filtered out.

[0104] As yet another example of an application of method 600, assume that a teacher at a school requests information from a health service about the records of all medical care a particular student has received because the teacher suspects the student has been abused. In one embodiment, the requester is legitimate, but the requested records exceed what is needed, so the request fails evaluation at block 615. For example, the request may satisfy the rules if it targeted frequency of absences or tardiness, number of doctor's appointments, etc. (without requesting specific health data).

[0105] As another example, suppose a professor requests a student's location data because the student is suspected of lying about a family emergency to avoid class. In one embodiment, such a request would fail the evaluation at block 615 because it would be harmful to the data subject (and would likely be satisfied if different data was requested).

[0106] As yet another example, assume that an adult child of the deceased requests access to the deceased's social networking accounts to download photos and videos for a video tribute. Such a request may pass evaluation at block 615. At block 630, information such as publicly available photos and videos from the social media accounts, friends lists, etc. may pass separate review. In contrast, data such as non-public information, saved posts or content, private conversations of the deceased, etc. may be excluded.

[0107] As yet another example, assume that a person requests access to a deceased relative's social networking account to determine whether the relative engaged in illegal activity. At block 615, such a request may be denied because the intent does not meet the access rules (e.g., it may not advance humanity or may harm the data subject).

[0108] As another example, assume an individual wishes to obtain diagnostic information for a family member in order to obtain a second opinion. Such a request may pass evaluation at block 615. At block 630, data such as test results, genetic predispositions, symptoms, etc. pertinent to the diagnosis may pass evaluation, while data such as information not pertinent to the diagnosis (such as blood type) is excluded. At block 650, information such as patient name, doctor name, hospital identity or location may be excluded, while data such as relevant test results pass access rules.

[0109] 7 illustrates a graphical user interface (GUI) 705 for enhancing data access control and notification, according to some embodiments disclosed herein. In the illustrated embodiment, the GUI 705 includes a series of data elements 710A-J along with, for each data element 710, an indication of whether the data element is shared (or can be shared). In the illustrated embodiment, the GUI 705 uses a sliding indicator, where one position corresponds to blocked data elements / data that are not shared (e.g., the leftmost position of the slider), one corresponds to data that is sometimes or limitedly shared on a case-by-case basis depending on a particular request (e.g., the middle of the slider), and one position corresponds to data that is always or freely shared (e.g., the rightmost position of the slider). In some embodiments, each of the data elements 710 is associated with other visual aids, such as color coding (e.g., red, yellow, and green).

[0110] In some embodiments, a user can use GUI 705 to provide preferences or selections to the analytic server. For example, a user can specify that an element has been shared (or is selectively shared), but that they would rather have it always be locked. Or, a user can indicate that a data element has been blocked, but that they would prefer to be able to share it (at least selectively). In some embodiments, this user feedback can be used to iteratively refine the models used to make access decisions.

[0111] FIG. 8 is a flow diagram illustrating a method 800 for automatically controlling data access using one or more machine learning models, according to some embodiments disclosed herein. The method 800 begins at block 805, where an analytic server receives a first request from a first user for data related to a second user. At block 810, the analytic server automatically determines whether the first request satisfies one or more data access rules by processing the first request using a first set of one or more trained machine learning models. The method 800 then proceeds to block 815, where upon determining that the first request satisfies the one or more data access rules, the analytic server automatically retrieves a first plurality of data elements based on the first request. At block 820, the analytic server automatically determines whether each of the first plurality of data elements satisfies one or more data access rules by processing each of the first plurality of data elements using a second set of one or more trained machine learning models. Further, upon determining that each data element of the first set of data elements from the first plurality of data elements individually satisfies the one or more data access rules, the analytic server determines whether the first set of data elements collectively satisfy the one or more data access rules by processing the first set of data elements with a third set of one or more trained machine learning models at block 825. Upon determining that the first set of data elements satisfy the one or more data access rules at block 830, the analytic server generates a custom report that includes the first set of data elements.

[0112] 9 is a flow diagram illustrating a method 900 for training one or more machine learning models to control data accessibility according to some embodiments disclosed herein. The method 900 starts at block 905, where a training server generates a first training data set from a set of historical access records, where each access record in the first training data set corresponds to a respective request for data and includes information identifying whether each request satisfies one or more data access rules. At block 910, the training server generates a second training data set from the set of data records, where each data record of the second training data set corresponds to a respective data element and includes information identifying whether each data element satisfies one or more data access rules. Additionally, at block 915, the training server generates a third training data set from the set of historical access records, where each access record of the third training data set corresponds to a respective set of aggregated data elements and includes information identifying whether each set of aggregated data elements satisfies one or more data access rules. The method 900 then proceeds to block 920, where the training server trains one or more machine learning models based on the first, second, and third training data sets to generate an output that identifies whether the request for data should be allowed. Then, at block 925, the training server deploys the one or more machine learning models to one or more computing systems.

[0113] (Example system for training and using machine learning models to control data access) 10 is a block diagram illustrating a computing device 1000 configured to train and use a machine learning model to control data access, according to some embodiments disclosed herein. For example, computing device 1000 may include one or more of the analytics server 110 and / or training server 135 shown in FIG 1. Computing device 1000 may be configured to perform various techniques disclosed herein, such as the methods and techniques described with reference to FIGS. 2-9.

[0114] As shown, computing device 1000 includes a central processing unit (CPU) 1005, one or more input / output device interfaces 1020 that may enable connection of various input / output devices 1035 (e.g., a keyboard, a display, a mouse device, pen input, etc.) to computing device 1000, a network interface 1025 through which computing device 1000 may be connected to one or more networks (which may include a local network, an intranet, the Internet, or any other group of computing devices communicatively connected to one another), memory 1010, storage 1015, and an interconnect 1030.

[0115] CPU 1005 may retrieve and execute programming instructions stored in memory 1010. Similarly, CPU 1005 may retrieve and store application data present in memory 1010. Interconnect 1030 transmits programming instructions and application data between CPU 1005, input / output device interface 1020, network interface 1025, memory 1010, and storage 1015.

[0116] CPU 1005 is included to represent a single CPU, multiple CPUs, a single CPU with multiple processing cores, and the like.

[0117] The memory 1010 represents a volatile memory, such as a random access memory, or a non-volatile memory, such as a non-volatile random access memory or a phase change random access memory. As shown, the memory 1010 includes a data sharing component 115, a custom report generator 120, a training data generator 140, and a model trainer 145.

[0118] The data sharing component 115 is generally configured to evaluate requests and data elements to determine whether they should be shared (e.g., whether the requesting entity should be granted access). In embodiments, the data sharing component 115 does so based in part on a set of access rules that define ethical and acceptable data security and access practices. In some embodiments, the data sharing component 115 utilizes a machine learning model trained on the historical access records 150.

[0119] The custom report generator 120 generally generates a data report based on the decisions returned by the data sharing component 115. That is, the custom report generator 120 generates a report that includes any data elements that were approved for sharing (individually and collectively). In some embodiments, for any data that was excluded, the custom report generator 120 may include an indication as to which rules the element failed to satisfy (e.g., based on a particular model that classified the data element as failing).

[0120] Training data generator 140 generally generates a training data set from historical access records, where each record in the training data set indicates a set of input features (of the corresponding historical request or data element) as well as a target output label (e.g., whether the historical request or data element satisfied an access rule).

[0121] The model trainer 145 generally uses a training dataset to train a set of trained models 1050, which are used by the data sharing component 115 to drive data access decisions.

[0122] (Additional considerations) The foregoing description is provided to enable those skilled in the art to practice the various embodiments described herein. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of the elements discussed without departing from the scope of the disclosure. In various examples, various procedures or components may be omitted, substituted, or added, as appropriate. Also, features described with respect to some examples may be combined in some other examples. For example, an apparatus may be implemented or a method may be practiced using any number of aspects described herein. Furthermore, the scope of the disclosure is intended to cover such apparatus or methods implemented using other structures, functions, or structures and functions in addition to or other than the various aspects of the disclosure described herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.

[0123] As used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items, including a single element. By way of example, "at least one of a, b, or c" is intended to cover a, b, c, ab, ac, bc, and abc, as well as any combination of multiples of the same elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc or any other permutation of a, b, and c).

[0124] As used herein, the term "determining" encompasses a wide variety of acts. For example, "determining" can include calculating, computing, processing, deriving, investigating, searching (e.g., searching in a table, database, or another data structure), ascertaining, and the like. Also, "determining" can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Also, "determining" can include ascertaining, selecting, choosing, defining, and the like.

[0125] The methods disclosed herein include one or more steps or actions for achieving the method. The method steps and / or actions may be interchangeable with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of the specific steps and / or actions may be changed without departing from the scope of the claims. Furthermore, the various operations of the methods described above may be performed by any suitable means capable of performing the corresponding functions. These means may include various hardware and / or software components and / or modules, including but not limited to circuits, application specific integrated circuits (ASICs), or processors. In general, where there are operations illustrated in figures, those operations may include corresponding equivalent means and functional components with similar numbering.

[0126] The various illustrated logic blocks, modules, and circuits described in connection with this disclosure may be implemented or performed by a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but alternatively, the processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration.

[0127] The processing system may be implemented with a bus architecture. The bus may include any number of interconnecting buses and bridges depending on the particular application and overall design constraints of the processing system. The bus may link various circuits together including the processor, machine-readable media, and input / output devices, among others. A user interface (e.g., keypad, display, mouse, joystick, etc.) may also be connected to the bus. The bus may also link various other circuits, such as timing sources, peripherals, voltage regulators, power management circuits, etc., well known in the art, and therefore will not be described further. The processor may be implemented with one or more general-purpose and / or special-purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuits capable of executing software. Those skilled in the art will recognize how to best implement the described functionality for the processing system depending on the particular application and the overall design constraints imposed on the overall system.

[0128] If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium. Software shall be broadly construed to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or the like. Computer-readable media includes both computer storage media and communication media, such as any medium that facilitates transfer of a computer program from one place to another. The processor may be responsible for managing the bus and general processing, including the execution of software modules stored on the computer-readable storage medium. The computer-readable storage medium may be coupled to the processor such that the processor can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium may be integrated into the processor. By way of example, the computer-readable medium may include a transmission line, a carrier wave modulated by data, and / or a computer-readable storage medium with instructions stored thereon separate from the wireless node, all of which may be accessed by the processor via a bus interface. Alternatively, or in addition, the computer-readable medium or any portion thereof may be integrated into the processor, such as in the case of a cache and / or a general register file. Examples of machine-readable storage media may include, by way of example, a RAM (random access memory), a flash memory, a ROM (read only memory), a PROM (programmable read only memory), an EPROM (erasable programmable read only memory), an EEPROM (electrically erasable programmable read only memory), a register, a magnetic disk, an optical disk, a hard drive, or any other suitable storage medium, or any combination thereof. The machine-readable medium may be embodied in a computer program product.

[0129] A software module may include a single instruction or many instructions and may be distributed across several different code segments, among different programs, and across multiple storage media. A computer-readable medium may include several software modules. A software module includes instructions that, when executed by a device such as a processor, cause a processing system to perform various functions. A software module may include a transmitting module and a receiving module. Each software module may reside in a single storage device or may be distributed across multiple storage devices. As an example, a software module may be loaded from a hard drive into RAM when a triggering event occurs. During execution of a software module, a processor may load some of the instructions into a cache to speed up access. One or more cache lines may then be loaded into a general purpose register file for execution by the processor. When referring to a function of a software module, it will be understood that such function is implemented by a processor when executing instructions from that software module.

[0130] The following claims are not intended to be limited to the embodiments set forth herein, but are to be accorded the full scope consistent with the language of the claims. In the claims, reference to an element in the singular is not intended to mean "one and only one" unless specifically so specified, but rather means "one or more." Unless specifically specified otherwise, the term "some" refers to one or more. No element of a claim should be construed under the provisions of 35 U.S.C. 112(f) unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, the element is recited using the phrase "step for." All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later become known to those of skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed in this specification is intended to be dedicated to the public, regardless of whether such disclosure is expressly recited in the claims. According to aspect (1), there is provided a method for automatically controlling data access using one or more machine learning models, comprising: receiving a first request from a first user for data related to a second user; automatically determining whether the first request satisfies one or more data access rules by processing the first request using a first set of one or more trained machine learning models; automatically obtaining a first plurality of data elements based on the first request upon determining that the first request satisfies the one or more data access rules; automatically determining whether each of the first plurality of data elements satisfies the one or more data access rules by processing each of the first plurality of data elements individually using a second set of one or more trained machine learning models; upon determining that each data element of a first set of data elements from the first plurality of data elements individually satisfies the one or more data access rules, determining whether the first set of data elements collectively satisfy the one or more data access rules by processing the first set of data elements using a third set of one or more trained machine learning models; generating a custom report that includes the first set of data elements upon determining that the first set of data elements satisfies the one or more data access rules; The method includes: According to aspect (2), receiving a second request; determining whether the second request satisfies the one or more data access rules by processing the second request using the first set of one or more trained machine learning models; refraining from obtaining data for the second request upon determining that the second request does not satisfy the one or more data access rules; Further includes: According to aspect (3), refraining from providing a second set of data elements from the first plurality of data elements upon determining that the second set of data elements does not satisfy the one or more data access rules; Further includes: According to aspect (4), receiving a second request; automatically obtaining a second plurality of data elements based on the second request; and automatically determining that a second set of data elements from the second plurality of data elements satisfy the one or more data access rules by processing each of the second plurality of data elements with the second set of one or more trained machine learning models; determining whether the second set of data elements collectively satisfy the one or more data access rules by processing the second set of data elements with the third set of one or more trained machine learning models; refraining from providing at least one data element from the second set of data elements upon determining that the second set of data elements collectively do not satisfy the one or more data access rules; Further includes: According to aspect (5), sending a notification to the second user that the first set of data elements has been accessed by the first user; Further includes: According to aspect (6), receiving a second request; determining that the second request does not satisfy the one or more data access rules; generating a custom report specifying why the second request was denied; and Further includes: According to aspect (7), there is provided a method for training one or more machine learning models to control data accessibility, the method comprising: generating a first training data set from a set of historical access records, each access record in the first training data set corresponding to a respective request for data and including information identifying whether the respective request satisfies one or more data access rules; generating a second training data set from a set of data records, each data record of the second training data set corresponding to a respective data element and including information identifying whether the respective data element satisfies the one or more data access rules; generating a third training data set from the set of historical access records, each access record of the third training data set corresponding to a respective set of aggregated data elements and including information identifying whether the respective set of aggregated data elements satisfies the one or more data access rules; training the one or more machine learning models based on the first training data set, the second training data set, and the third training data set to generate an output that identifies whether a request for data should be granted; deploying the one or more machine learning models on one or more computing systems; The method includes: According to aspect (8), training the one or more machine learning models based on the first training data set, the second training data set, and the third training data set includes: training the first set of one or more machine learning models based on the first training dataset; training a second set of the one or more machine learning models based on the second training dataset; training a third set of the one or more machine learning models based on the third training dataset; Includes. According to aspect (9), the one or more data access rules include: (i) the first rule; and (ii) the second rule; and (iii) the third rule; and Includes. According to aspect (10), training the first set of one or more machine learning models includes: training a first machine learning model based on the first training dataset and the first rule; training a second machine learning model based on the first training data set and the second rule; training a third machine learning model based on the first training data set and the third rule; Including, Training the second set of one or more machine learning models includes: training a fourth machine learning model based on the second training data set and the first rule; training a fifth machine learning model based on the second training data set and the second rule; training a sixth machine learning model based on the second training data set and the third rules; and Including, Training the third set of one or more machine learning models includes: training a seventh machine learning model based on the third training data set and the first rule; training an eighth machine learning model based on the third training data set and the second rule; and training a ninth machine learning model based on the third training data set and the third rule; Includes. According to aspect (11), the first rule specifies that data may be accessed only if doing so would improve humanity; the second rule specifies that data may be accessed only if an intended use of the data is legitimate; The third rule specifies that the data can only be accessed if it remains protected. According to aspect (12), each access record in the first training data set includes: The purpose of each of the above requests; and one or more data elements associated with each of said requests; The information further includes information identifying the According to aspect (13), each data record in the second training data set comprises: One or more characteristics of each of said data elements The information further includes information identifying the According to an aspect (14), each data record in the second training data set comprises: a data profile of a source of each data element in said respective set of aggregated data elements; The information further includes information identifying the According to aspect (15), each data record in the third training data set comprises: A data profile of the source of each of said data elements The information further includes information identifying the

Claims

1. A method executed on a training server comprising: a training data generator for generating training data; and a model trainer for training one or more machine learning models to control data accessibility based on characteristics of aggregated data elements that individually satisfy data access rules, the method comprising: generating, by a training data generator, separate training data for each model to be trained for each layer of the plurality of layers of analysis; generating a first training data set from a set of historical access records corresponding to previous requests for data and relating to previous data sharing decisions and whether the data access requests were approved or denied, each access record in the first training data set corresponding to a respective request for data and including information identifying whether the respective request satisfied one or more of the data access rules, each of the access records in the first training data set further including information identifying (i) a purpose of the respective request, and (ii) one or more of the data elements associated with the respective request; generating a second training data set from a set of data records, each of the data records of the second training data set corresponding to a respective one of the data elements and including information identifying whether each of the data elements satisfies one or more of the data access rules, each of the data records in the second training data set further including information identifying one or more characteristics of each of the data elements and information identifying a data profile of a source of each of the data elements in each set of aggregated data elements; generating a third training data set from the set of historical access records, each of the access records of the third training data set corresponding to a respective set of aggregated data elements and including information identifying whether each of the aggregated sets of data elements satisfies one or more of the data access rules based on characteristics of the aggregated data elements that individually satisfy the data access rules, each of the data records in the third training data set further including information identifying a data profile of a source of each of the data elements; training the one or more machine learning models based on the first training data set, the second training data set, and the third training data set to generate an output that identifies whether the request for the data should be allowed; deploying the one or more machine learning models on one or more computing systems comprising an analytics server, the training server deploying the one or more trained machine learning models to analyze received data requests at run-time, analyze individual data elements obtained at run-time, and analyze aggregate sets of the data elements obtained at run-time; The method includes:

2. training the one or more machine learning models based on the first training data set, the second training data set, and the third training data set; training the first set of one or more machine learning models based on the first training data set; training a second set of the one or more machine learning models based on the second training dataset; training a third set of the one or more machine learning models based on the third training data set; The method of claim 1 , comprising:

3. One or more of the data access rules include: (i) a first rule; and (ii) a second rule; and (iii) a third rule; and The method of claim 2 , comprising:

4. Training the first set of one or more machine learning models includes: training a first machine learning model based on the first training data set and the first rule; training a second machine learning model based on the first training data set and the second rule; training a third machine learning model based on the first training data set and the third rule; Including, Training the second set of one or more machine learning models comprises: training a fourth machine learning model based on the second training data set and the first rule; training a fifth machine learning model based on the second training data set and the second rule; training a sixth machine learning model based on the second training data set and the third rule; and Including, Training the third set of one or more machine learning models comprises: training a seventh machine learning model based on the third training data set and the first rule; training an eighth machine learning model based on the third training data set and the second rule; and training a ninth machine learning model based on the third training data set and the third rule; The method of claim 3 , comprising:

5. the first rule specifies that the data may be accessed only if doing so would improve humanity; the second rule specifies that the data may be accessed only if the intended use of the data is legitimate; the third rule specifies that the data may be accessed only if the data remains protected; The method according to claim 3.

6. The request for data is a request for information relevant to a medical diagnostic decision, and a first rule provides that the data may be accessed if the request for data is a legitimate request for data that is beneficial to the requester or another person while maintaining privacy and security; the data elements consist of elements related to medical diagnoses, including test results, genetic predispositions, and symptoms, and a second rule provides that the data may only be accessed if the intended use of the data is justified; The aggregated data elements further include non-diagnosis related data including patient name, hospital identity or location, and a third rule provides that the data may only be accessed if the data remains protected. The method according to claim 3.

7. A method, executed on the analytics server, for automatically controlling data access using the one or more machine learning models according to any one of claims 1 to 6, comprising: receiving a first request from a first user for the data related to a second user, the first request indicating the data requested by one or more explicit references or by providing characteristics that can be used to filter the data and a purpose or reason for the request; automatically determining whether the first request satisfies one or more of the data access rules by processing the first request using a first set of the one or more trained machine learning models; automatically obtaining a first plurality of data elements based on the first request upon determining that the first request satisfies one or more of the data access rules; automatically determining whether each of the first plurality of data elements satisfies one or more of the data access rules by processing each of the first plurality of data elements individually using the second set of the one or more trained machine learning models; upon determining that each of the data elements of the first set of data elements from the first plurality of data elements individually satisfies one or more of the data access rules, adding the first plurality of data elements to a subset of the approved data elements; determining whether the first set of data elements collectively satisfy one or more of the data access rules by processing the first set of data elements using the one or more trained machine learning models; generating a custom report that includes the first set of data elements upon determining that the first set of data elements satisfies one or more of the data access rules; A method comprising:

8. Receiving a second request; and determining whether the second request satisfies one or more of the data access rules by processing the second request using the first set of the one or more trained machine learning models; refraining from obtaining the data for the second request upon determining that the second request does not satisfy one or more of the data access rules; The method of claim 7 further comprising:

9. refraining from providing the second set of data elements from the first plurality of data elements upon determining that the second set of data elements does not satisfy one or more of the data access rules; The method of claim 7 further comprising:

10. Receiving a second request; and automatically obtaining a second plurality of data elements based on the second request; and automatically determining that a second set of data elements from the second plurality of data elements satisfy one or more of the data access rules by processing each of the second plurality of data elements with the second set of the one or more trained machine learning models; determining whether the second set of data elements collectively satisfy one or more of the data access rules by processing the second set of data elements using the third set of the one or more trained machine learning models; refraining from providing at least one of the data elements from the second set of data elements upon determining that the second set of data elements collectively do not satisfy one or more of the data access rules; The method of claim 7 further comprising:

11. sending a notification to the second user that the first set of data elements has been accessed by the first user; The method of claim 7 further comprising:

12. Receiving a second request; and determining that the second request does not satisfy one or more of the data access rules; generating a custom report specifying why the second request was denied; and The method of claim 7 further comprising:

13. The method of claim 7, wherein the data access rules include determining whether a request is related to a legitimate clinical or medical diagnosis without harming the data subject and whether the data will be kept confidential.

14. The method of claim 7, wherein the analysis server can iteratively remove one or more of the data elements from the aggregated data and reprocess the remaining set until a satisfactory set of aggregated data elements is found, and wherein the data elements that may identify a data subject or that may identify a facility location or a medical professional are removed from the aggregated data.

Images