US20110016030A1 - System and method for aggregation and analysis of information - Google Patents

Abstract

The invention provides a system and method for automated data analysis in which data agents are located and operate at each member site or data source (i.e., locally). These agents access stored data at the data source or member sites, process the data and also aggregate the results. The aggregated results from each of the member sites are then forwarded to and further aggregated at a central analytic hub. The central analytic hub contains a centralized application which can further aggregate each of the aggregated results and perform a final analysis. These results are then delivered to the requestor without any ability to identify individual data sources, or records from those sources.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• The present invention is a continuation-in-part of U.S. application Ser. No. 11/493,558 filed Jul. 27, 2006 (herein incorporated by reference in its entirety) which is a continuation of U.S. application Ser. No. 11/271,824 filed Nov. 14, 2005, which is a Continuation of U.S. application Ser. No. 11/080,980 filed Mar. 16, 2005, which is a nonprovisional of U.S. Provisional Application No. 60/553,132 filed on Mar. 16, 2004.
BACKGROUND OF THE INVENTION
• 1. Field of the Invention
• The present invention relates to a system and method for exchanging, integrating and analyzing information from multiple sources, without risking the divulging of potentially confidential information from any of those sources. Specifically, the present invention relates to the use of a data agent that collects, analyzes and aggregates information related to a data set of interest and forwards the results in a form that can be combined with like data from other sites, and without divulging confidential information contained in the data set.
• 2. Discussion of the Related Art
• The analysis of data generally requires a sufficient set of data points to determine whether results represent real correlations or whether they represent random coincidence. In many industries, there are questions that cannot be answered by any one institution because the size and variation of its dataset is insufficient. Competitors, collaborators, and regulators, may have mutual interest in sharing data to provide a joint body of information for answering questions in which they are interested. However, due to competitive, regulatory, or other concerns of trust, institutions may be reluctant to disclose such data, particularly identifying data. Moreover, in other regulated industries, such as healthcare or finance, or in industries where privacy is implied, sharing of certain data is prohibited. Accordingly, a current need exists for a methodology for exchanging, integrating and analyzing information using a technique that can overcome these concerns and prohibitions and provide data of sufficient size and variation with the added benefit of ensuring anonymity of data providers.
• Current techniques and systems attempt to address these confidentiality and disclosure problems through the use of various data filters that attempt to forward relevant data while preventing the dissemination of private information, by removing personal identifiers. The data filter may be located at a data source. For example, data may be collected from a hospital using an application that strips patient information from the data records before sending the data records for statistical analysis. Alternatively, other known data stripping utilities operate at a data analysis location, removing confidential information from data acquired from distant location, either before or after statistical analysis of the acquired data. The problem with these methods is four-fold. First, the anonymization techniques used are often reversible given other external information, or are insufficient to completely anonymize the individual. Second, the data records themselves are no longer under control of the source site, and so could be used inappropriately. Third, to fully anonymize the data may require removal of important fields other than explicit identifiers. This loss of fields or variables may put constraints on the utility of anonymized data in a pooled analysis. Fourth, removing data that might identify an individual might also impede the ability to find and analyze rare events. For meaningful analysis of rare events, which by definition occur infrequently, all data points should be included because sampling techniques are inappropriate and may miscount or otherwise distort the occurrence of the rare events. Not only might the data be removed for de-identification, but the analysis cannot be performed at individual sites and then combined, because rare events will not show up as significant in local analyses.
SUMMARY OF THE PRESENT INVENTION
• In response to these and other needs, the present invention provides a system and method for automated data analysis in which data agents are located and operate at each member site or data source (i.e., locally). These agents access stored data at the data source or member sites, process the data and also aggregate the results. The aggregated results from each of the member sites are then forwarded to and further aggregated at a central analytic hub. The central analytic hub contains a centralized application which can further aggregate each of the locally aggregated results and perform further analysis. These results are then delivered to the requestor without any ability to identify individual data sources, or records from those sources. Because the data agents at the member sites only forward aggregate data and not any of the actual records from the member sites, there is virtually no risk of disclosing confidential information contained in the member sites. The data agents are designed to provide the data aggregates needed for any specific request without custom programming. Moreover, because the request is processed through a central analytic hub, the source of the request may remain anonymous to the member sites, depending upon the procedures established at the hub.
• In accordance with the invention, a requesting entity can forward a request for analysis to the central analytic hub. That request is translated into requests to each data agent residing at each member site for data aggregates. No reprogramming is required for each request. When the data aggregates have been collected from each agent, final aggregation and analysis is performed at the hub, and the results delivered to the requestor.
• Unlike most standard data warehousing techniques, the data collection, analysis and aggregation system of the present invention does not gather individual records for processing and storage at a central site Zuzek. Instead, the data collection, analysis and aggregation system analyzes individual requests to determine the data needed to fulfill that request and then analyzes and aggregates data at each source site to the maximal extent possible before transferring the data aggregates at a central location to perform final analysis. By aggregating data at source sites, and sending only summary data to the analysis site, no individual records or identities are exposed. The data collection and aggregation system (hub) will conceal the source site identity and requestor information from the summary data. Thus, even the requestor of information will remain anonymous. Consequently, the present invention provides a unique advantage that even mutually distrustful organizations, such as competitors, can participate in such a data exchange, and benefit from industry-wide analyses.
• The data collection and aggregation system in accordance with the invention is used in the context of an exchange model, in which a set of exchange members agree to host a service to summarize their data in response to specific requests and provide those summaries to the exchange analysis servers. In return, exchange members are granted the ability to request analyses from the exchange, receive compensation for the provision of information, or are considered compliant for regulatory purposes.
• Once a request for analysis is made to the exchange, it is processed to identify (1) the data sources needed, (2) the variables to be analyzed, and (3) the strata (or bins) in which to group each variable. Requests are then sent to the agent located at the member sites for the information needed, along with (1) instructions on what data to collect and how to bin the requested data, and (2) instructions on how to aggregate the data. The aggregate requested will not include variables that carry identifying information.
• When an agent residing at a member site receives the request, it retrieves the data needed for processing the request, codes it where necessary according to predefined exchange rules or standard dictionaries, bins the data as specified, and computes the summary data requested. The agent then sends this data aggregate to a central analysis hub. That hub may be a single central hub, or the exchange may be configured with regional analysis hubs that perform another level of aggregation or analysis before forwarding to a central hub. The collected data aggregates can optionally be retained at the member sites in case follow-up requests are made.
• The results of data analysis are then returned to the initial requestor. If the requestor wishes to drill down on the results, a follow-up request can be made. That secondary request is forwarded to the member sites and may include pooled results from the first round, as well as make use of the saved aggregates from the first request. The follow-up may require drill-down or re-slicing of the data aggregate computed for the original request.
• Thus, the present invention provides a system and method for addressing many of the shortcomings of present data collection and aggregation technologies. Specifically, the present invention provides the novel use of data aggregation methods, particularly data aggregation and summary table technology, to protect the privacy of data without losing critical information needed for analysis. While existing data collection and aggregation techniques may build data slices from a common warehouse, the present invention provides the novel use of paired aggregation and disaggregating techniques to combine data from distinct data sources to a common specification, followed by the merger of the data aggregates from the separate data sources.
• The present invention differs from known data collection techniques. The present invention does not reply upon taking only a sample of a data set or otherwise reduce data size or data distribution for performance or throughput improvements. Sampling techniques find a valid subset of data points to reduce data size, to improve performance, or conform to limited resources. In contrast, the present invention provides for meaningful statistical analysis from all data points of interest.
• Similarly, the present invention differs from known caching techniques that pull data from a central warehouse and store previous queries or data subsets in caches close to the user. Instead, the present invention takes data aggregates from multiple sources and conveys them through a central site for processing and analysis.
• Likewise, the present invention further differs from other known data collection and sampling techniques, such as parallel query techniques that use multiple sites to run queries on slices of the data in parallel to improve throughput; meta-analysis that combines existing results by weighting techniques; and Private Information Retrieval techniques that provide individual data points while protecting identity and source of those data points. The present invention does not provide individual data points, or the potentially confidential information contained in these data points. Instead, the systems and methods of the present invention use intelligence about the mining or analytical techniques to guide data aggregation whereby individual record identifying information is removed while retaining all statistical information relevant to the analysis. In one embodiment, the present invention can be adapted to employ known techniques for removing aggregations below thresholds.
BRIEF DESCRIPTION OF THE DRAWINGS
• A more complete understanding of the present invention and advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:
• FIG. 1 illustrates a flowchart depicting steps in a confidential data aggregation method in accordance with embodiments of the present invention;
• FIG. 2A is a block diagram of a system for data aggregation using an exchange hub in accordance with an embodiment of the invention;
• FIG. 2B is a block diagram illustrating the multi-tiered operation of the exchange hub in accordance with an embodiment of the invention;
• FIG. 3 is a block diagram illustrating operation of an exchange member in accordance with an embodiment of the invention; and
• FIG. 4 is a block diagram illustrating operation of the exchange hub in greater detail.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
• As depicted inFIG. 1, the present invention—provides adata aggregation method100 for the confidential and effective collection of data. Thedata aggregation method100 starts atstep105 where a request is formulated and sent by a requesting entity. The process then moves to step110 when at least one formulated data request is received using known techniques. The request is received from a requestor to a hub or central computer. The received data request defines the desired subject matter and scope of the data collection. For example, the data request may ask for aggregated or statistical results related to the use of a specified medical drug to address a specified condition in a specified area over a specified period. As described in greater detail below, the request is generally in an electronic format and received at the central computer.
• In the next step,step120, the hub or central computer processes and/or transforms the request, which can involve reformulating the request so that it can be understood by data sources and then transmits the processed request to the data sources. Thus,step120 entails transmitting the processed request as needed to access relevant data in the other locations. Returning to the above example of a request, the central computer may transform a request about a specified medical drug for a specified condition in a specified area over a specified period into a series of Boolean expressions that defines the data search. It should be appreciated that the transformation step may be adapted as needed to access the relevant data contained at the remote location. Similarly, the transformed search request may be used to access previous analyses that are stored at the hub or other location.
• The process then moves to step130. Instep130, the other locations, including other member sites, receive and process the data request. This step generally includes the other locations searching for relevant data and then processing this data. In this step, the other locations process and analyze the data to determine certain statistics. Continuing with the previous example, each location may, for example, produce and analysis and/or statistics that address the effectiveness and side-effects of the specified drug for the specified condition in the specified area over the specified period according to the data contained in that remote location. This analysis of the data that resides at each remote location is generally performed using known techniques.
• The process then moves to step140, where the analyzed data are aggregated at each remote location and then the aggregated data is ready to be sent to the hub. It should be noted that the analyzed data from the remote locations is never the raw information or data, but only the analyzed data, the statistical data or the aggregates. In this way, it is ensured that confidential data is not improperly divulged. Returning to the above example, the identity of patients receiving the specified drug for the specified condition in the specified area over the specified period would not be used or distributed. Even where the search entailed some type of personal data, such as age, race, sex, etc., this data would not be individually available for each patient, but rather, only present as part of the analyzed or statistical results. In other words, the aggregate data would provide analyzed or statistical information on personal data, such as percentages of people falling into certain categories, but no individual patient's data would ever be transmitted or exposed. The aggregate analyzed data is generally derived using known techniques, and may vary according to the techniques used instep130 to produce the data analysis.
• In one embodiment of the invention, the data collection andaggregation step130 and140 may operate in an iterative fashion. Thus, instep150, a remote location may access and aggregate analyzed and/or statistical data about information contained in secondary locations, and then forward this aggregated analyzed and/or statistical data to the central location or hub where it can be further aggregated with data collected from other remote locations, which may likewise be collecting and analyzing data from secondary locations. In this way, data analysis from multiple locations may be compiled and analyzed in an efficient and confidential matter. This embodiment can be considered multi-tiered as there may be multiple levels of hubs and remote locations.
• The process then moves to step160 where the central location or hub can then aggregate and further analyze the collected analyzed and/or statistical data from each remote (local) location with any analyzed and/or statistical data already residing at the central location or hub, such as previously analyzed data. Thus, the hub is capable of performing additional analysis of the data aggregated from various remote locations. Again, the aggregation is generally performed using known techniques and may vary according to the techniques used insteps130 and140 to produce the data statistics. At this point, if the hub determines that additional aggregated data from the remote locations is required in order to fulfill the original request, the process moves to step165 which returns the process to step130.
• The central location or hub can then forward the aggregate analyzed data to the requestor instep170 using known means. The requestor may subsequently use these results to modify the initial request and to repeat the steps indata aggregation method100. For example, the requestor may change the search terms as needed to refine the results or to collect additional analyzed data and/or statistics.
• Turning now toFIG. 2A, anaggregation data exchange200 for implementing thedata aggregation method100 is now described. The following discussion of theaggregation data exchange200 refers to a system that can handle bothnon-members210 andmembers220 and300. The term “member” is used herein to generally refer to locations that agree to share data results with other locations in theaggregation data exchange200. Similarly, the term “requesting” is used in this discussion to mean a request for specific statistical or analyzed information about data stored at various remote locations in the exchange. Thus, the non-member210 merely requests data from locations without likewise providing access to its own data, whereas the requestingmember300 both initiates its own requests and can respond to requests from thenon-member requestor210 or fromother members220. The requestor,210 or300, forwards arequest201 to a central location, orexchange hub400. Theexchange400 processes therequest201 and forwards the request to thenon-requesting members220.
• Each of thenon-requesting members220 receives therequest201 and processes resident data to produce desired analyzed data or statistics based upon the data that resides within each respectivenon-requesting member220. This aggregated and analyzed data, which can be referred to asresults204, has been anonymized and is transmitted to the central location orexchange hub400. Theresults204 includes other data as needed for the operation of theexchange200. For example, theresults204 may include an accounting or bill for the activities of thenon-requesting members220 or information as needed to further process the transmitted results204. The specific operation of themembers220 and300, along with the statistical analysis used by themembers220 and300, is described in greater detail below inFIG. 3 and the associated discussion.
• Theexchange hub400 then further aggregates and/or analyzes theresults204 collected from thenon-requesting members220. As described above in the discussion of thedata aggregation method100, the central exchange orhub400 may combine theresults204 with information already stored at thehub400, such as data collected in previous searches. These combined results may be referred to asfinal results205. Theexchange hub400 then forwards the aggregated and analyzed data, orfinal results205, to the requestor210 or300. The specific operation of theexchange hub400 is described in greater detail below inFIG. 4 and the associated discussion.
• Where thenon-member requestor210 has initiated the data search, theexchange hub400 forwards thefinal results205 to thenon-member requestor210. Thenon-member requestor210 generally includes a user/application211 who originated therequest201. Thenon-member requestor210 further includes ananalytic engine212 that processes and interprets thefinal results205, as needed for local use in the form of a report of aggregated data. In one embodiment, theanalytic engine212 may communicate with a billing and credit module (not shown) which may be located athub400 in order to further process the request, which may for example involve using known techniques to create an accounting for the data received by the requestor. For example, such a billing and credit module can identify thenon-requesting members220 producing thefinal results205 and produce an invoice for the service provided by thenon-requesting members220.
• It should also be understood thatFIG. 2A supports embodiments of the invention whereby the interaction between theexchange hub400 and the non-requesting members is iterative in nature. In accordance with these embodiments, when theexchange hub400 receives aggregated data from thenon-requesting members220, it can analyze and aggregate the received data and determine that more information is needed to fulfill the request. In this case, theexchange hub400 can direct a further request for aggregated data to each of thenon-requesting members220. This iterative process can continue indefinitely until the exchange hub determines that it has received data meeting the request.
• Referring now toFIG. 2B, a multi-tieredaggregation exchange hub200′ is presented. Thus, in this embodiment, anon-requesting member220′, which is a data source, may seek additional data from another set of data sources (secondary sites230). Thus, this embodiment illustrates a multi-tiered data aggregation, analysis and retrieval system. As shown inFIG. 2B, in theaggregation exchange hub200′, one or more of thenon-requesting members220′ forwards arequest201 to one or moresecondary sites230 that operate in a similar fashion to thenon-requesting members220. Thesesecondary sites230 then analyze resident data and return analyzed and orstatistical results203′ to the associatednon-requesting member220′, which then forms aggregatedresults204 based upon theresults203′ from thesecondary sites230 with data aggregated and analyzed within thenon-requesting member220′. Thus, in this embodiment, thenon-requesting member220′ is acting as both a hub, because it is gathering data aggregated from other remote locations, and also as a non-requesting member through its aggregation and analysis of resident data.
• The operation of a requesting exchange member300 (as shown inFIG. 2A) is described in greater detail inFIG. 3. As shown inFIG. 3, arequest201 is sent from the requestingmember300 to theexchange hub400 viafirewall380. Thisrequest201 may be based upon a request for data received by the requestingmember300 from a user (not shown). Such a user can access the requestingmember300 via any number of know interfaces. As described in connection withFIGS. 2A and 2B,final results205 are then transmitted to the requestingmember300. The requestingmember300 includes ananalytic engine320 which is a resident application that houses algorithms for processing data and for translating therequest201. Therequest201 is sent to the exchange hub400 (shown in detail inFIG. 2A) to be fulfilled to producefinal results205, as described above. Theanalytic engine320 also processes therequest201 to acquire statistics on locally accessible data.
• Thus, theanalytic engine320 is proprietary computer software that can be installed at thedata source220 or requestingmember210/300 that allows both the querying of resident data, the querying of other data sources in the exchange, and the combining of resident data with results from the exchange to provide statistically meaningful results.
• Resident data may be contained in a resident data repository, which is shown as amedical records database330 inFIG. 3. In the illustrated example ofFIG. 3, therecords database330 contains, for example, composite medical data collected from a variety of locations such aslab data340a, electronic medical record (EMR)340bandother sources340c. Therecords database330 is also capable of accessing other locations using known data interfaces as needed to access the respective locations. For example, standard EMR or site specific interfaces may be used.
• The composite medical data stored in theresident data repository330 may contain both private and non-private data. For the purposes of this discussion, private data generally means data that contains potentially identifying information that should not be publicly released. Private data is often intertwined with non-private data and it is typically difficult to automatically and efficiently separate the two.
• The requesting member300 (and220) uses theanalytic engine320 to acquire data, both private and non-private, from theresident data repository330 according to therequest201 to createsummary data module350. Thus, arequest201 may be sent to themedical records database330 andinformation202 may be returned to theanalytic engine320. Theanalytic engine320 can then analyze and aggregate theinformation202. Thus, theanalytic engine320 performs an analysis of relevant data in theresident data repository330 to producesummary data350 that is also analyzed and aggregated. Only summary data is transferred to the exchange and this prevents the transfer of source identifying information. Thus, thesummary data module350 may include data (results206) from thefinal results205 and theinformation202 that is further analyzed and aggregated.
• Thesummary data module350 may include a data construct with two or more logical dimensions containing at least (a) a set of core cells encoding specific data points, (b) a grand total point, (c) a subtotal line for each pair of dimensions, and (d) a subtotal plane for each pair of dimensions. For example, thesummary data module350 may represent a logical data structure having three dimensions: Industry, Department, and Direction. If the Industry dimension includes two values (i.e., Automotive and Telecom), the Direction dimension includes two values (i.e., Send and Receive), and the Business Unit dimension includes three values (i.e., Sales, Development, and Consulting), then the subtotal line may contains values indicating, for example, how many total e-mail messages were sent and received by the sales department, how many were sent and received by the development department, and how many were sent and received by the consulting department.
• The number of values for each dimension also results in core cells forming a two-by-two-by-three cube of cells. Each cell contains the data for one particular combination of the values for each dimension. For example, the sender and recipient of a particular message may both belong to the consulting department. The sender and recipient may both also belong to the industry vertical section associated with the telecom industry (i.e., the Telecom vertical). Therefore, when processing such a message, data integrating component increments the values in core cells. As a result, grand total point, subtotal lines, and subtotal planes would also reflect those incremented values. Each cell therefore contains summary data for one particular subset of documents. This process is not apparent to the information requestor or to the source of the information.
• In alternative embodiments, thesummary data module350 may have more than three dimensions. For example, asummary data module350 that contains organization-specific document statistics derived from e-mail messages include all of the dimensions described above, as well as dimensions for counting e-mail messages between each pair of units within the organization.
• Theanalytic engine320 createsresults206 based upon thefinal results205 and theinformation202, after theinformation202 has first been analyzed and/or aggregated. Theseresults206 are converted by theanalytic engine320 using known techniques to produce a report of aggregateddata360. The report of aggregateddata360 may vary according to the user and therequest201. It should be noted that the report of aggregateddata360 does not generally contain any information on the data sources340a-c, only statistics acquired from these locations. In this way, the locations340a-chave no incentive to conceal adverse information.
• As discussed earlier, in accordance with embodiments of the invention, theexchange members220 and300 may be compensated for providing information. This encourages participation in theexchange200, especially for cross-industry purposes where the data and analysis are used to answer questions that are not critical to the local organization. For example, the pharmaceutical industry and its regulators could use theexchange200 to search for incidence of rare adverse events. This search would lead them, not just to their own industry, but to the medical records stored electronically at hospitals and other care providers. While the providers have a general interest in promoting the discovery of adverse events, it is not operationally a priority and is viewed as the responsibility of the pharmaceutical industry and the regulators. By providing income to the providers, the providers are encouraged to allow their data to be used for such purposes, especially so since privacy will be maintained and no individual records nor the data source will ever be released.
• The requestingmember300 may further include afirewall380, that uses known technology to monitorrequest transmissions201 andinformation202 from thehub400. Thefirewall380 provides security to prevent unauthorized access to information contained in the requestingmember300, or thenon-requesting exchange members220.
• FIG. 4 illustrates the operation of theexchange hub400 in greater detail.FIG. 4 shows that theexchange hub400 may include ananalytic engine410, asummary data module420 and acentral billing module430. Theanalytic engine410 is proprietary software that runs at theexchange hub400 and can answer, in a statistically meaningful way, questions that require detailed (individual) data, without giving any access to the individual data items or the data source and, in fact, through the aggregation techniques, hide the source of the data.
• Specifically, theanalytic engine410 is a resident application that houses algorithms for processing data statistics and for translating therequest201 as needed for transmission through theaggregation data exchange200. In operation, theexchange hub400 can receive arequest201 from a requestingmember300. Theanalytic engine410 can process therequest201 and then transmit the processedrequest201 to thenon-requesting members220. Theanalytic engine410 also processes therequest201 to examine resident data located in asummary date module420. Aggregated and analyzedresults204 from thenon-requesting members220 are transmitted to theanalytic engine410. Theresults204 generally do not come at the same time, but instead in cycles as collected and processed by each of thenon-requesting members220. Thus, thefirst results204 aggregated and analyzed by one of thenon-requesting members220 can populate thesummary data module420. Asadditional results204 arrive from othernon-requesting members220, theanalytic engine410 updates thesummary data module420 with the new statistics.Final results205 are produced based upon theresults204 that are further aggregated with additional results coming from thenon-requesting members220 as well as data resident at theexchange hub400. Thesefinal results205 are transmitted to the requestingmember300.
• Theanalytic engine410 can also update a central billing andmodule430 to credit the variousnon-requesting members220 contributingresults204, as described above.
• It should be noted that the while theexchange hub400 ofFIG. 4 is a centralized dedicated device, in multi-tiered embodiments, there may be a centralized exchange hub in communication with multiple “second-tier” hubs which behave as hubs and also behave has requesting members.
EXAMPLES
• Some examples of requests that might be made to theexchange200 are now described. Most of the examples are in the health care and pharmaceuticals space, although theexchange200 is not limited to that industry. Along with the examples, some details of the steps necessary to service that request are provided.
Example 1
• Which of the two competing brands of coronary stents (or other medical device) has the lowest complication rate? Typically, no hospital has enough data to answer the question definitively, but combining data from a number of hospitals could address. Accordingly, this type of question may be addressed using thedata collection exchange200 of the present invention. First, the question needs to be clarified and put in precise enough terms that the solution can be posed as a database query. This is a standard step, not related directly to the aggregation, but is more complicated, because the data can be represented differently at different sites. Types of questions to be defined in this example include:
• • What events are considered complications? (e.g., consider thrombosis only)
  • In what timeframe after implanting the stent must the event occur to be considered related? (e.g., 3 months).
  • Are there other variables to be controlled for? (e.g., severity of illness, age, etc)
• Each of these questions in then translated into a database query as needed to collected data fromrelevant data sites220. Thus, in this example, relevant searchable data may include:
• • Total number of patients receiving stents
  • Number receiving type A and number receiving type B
  • Number receiving type A that had complications within 3 months of surgery
  • Number receiving type B that had complications within 3 months of surgery
• If a standard EMR is used at the data sources340, then the data definition is translated into a query against the EMR fields. The percentages for each type of stent could be calculated at eachexchange member220 and sent to thecentral exchange server400, along with the total number for each stent type. The information is assembled into exchange format and transmitted to thedata analysis tool410.
• If the desired information in this example is not in standard EMR format, then for eachsite220, a mapping from local format to the exchange standard format is be predefined. That mapping is used to specify the data available for use in requests. The translation to the exchange standard format is performed as part of gathering the data for the request. Note that even if an EMR standard exists, data may not be maintained natively in that standard format, and so a translation of the request to a local request may be needed.
• Theanalytic engine410 at theexchange server400 gathers data from alldata sources220, aggregates that data, and computes the complication rates. Results are then returned to the requestor210/300. The requestor210/300 may examine the results and decide that more information is needed about the patients to clarify the results. For example, do older patients do better on type of treatment, even if the overall rates do not differ significantly.
• The requestor210/300 can then formulate a follow-up query201 that makes use of previous results. The follow-up query may then be translated into a data query against the previous result sets and sent to thesites220 for computation. Work on the following query continues as described above. More details of this type of request are described below in Example 2.
Example 2
• The complication rates for two stents: In this case, the requestor210/300 wishes to know the relative complication rates of two stents, controlled for age and severity of disease. As in the previous example, the first step in the data collection and aggregation is to clarify the question. In this example, the question clarification requires specifying the strata to be used for age and severity. These criteria may differ for different requests and, consequently, may not be part of the common schema. For example, patients might be aggregated into the following age “bins” or categories: 30-40, 41-50, 51-60, 61-70, 71 and above. Similarly categories are then provided for severity of initial disease.
• According to these questions at eachdata collection site220, patients are counted by type of stent, age, and severity of disease. This stratification creates numerous subgroups. For example, if there are 5 age categories and three severity categories, then there are 15 subgroups for each of the two stent types, or 30 totals categories to be sent to the Exchange. If stratification becomes too detailed, it can potentially provide a backdoor to confidential identifying information. As described above, threshold criteria may be specified at local sites to prevent to prevent the distribution of statistical data from a limited number of data points.
• At theexchange server400, each of the subgroups is summed with the corresponding subgroups from every other site. Evaluations can be performed to determine whether results are different in different subgroups, and whether there is sufficient data in each subgroup for the results to be valid. In needed for analysis, subgroups can be combined. For example, evaluation can be done on severity of disease versus type of stent, without regard to the patients' ages. These are standard calculations, but it should be appreciated that the individual records are hidden atsource site220 and never revealed to the requestor210/300. Preferably, theexchange server400 combines the data subgroups as they arrive, and keeps no site-identifying information. Thus, in addition to protecting confidential patient information, but other confidential information is protected as well, such as physician information, hospital information, exact dates of treatment, etc.
Other Examples
• The present invention may be used to phrase questions in the form of predictions. For instance, cardiologists might be interested in being able to predict which patients are likely to suffer strokes after bypass surgery, and known neural net algorithms might be used to provide such predictions. The execution of those algorithms may be divided between member sites and the hub to provide maximum distance between the individual record data and the aggregated data before sending to the hub. The present invention model is fully compatible with this and other types of known data mining techniques.
• The present invention has further application in site-specific analysis or benchmarking. For instance, the present invention could be used to determine whether a medical treatment data aggregation outcome correlates with the number of surgeries performed annually at that site or with the number of surgeries performed by a surgeon. In these types of cases, thedata aggregation system200 does not want to identify the site or the surgeon, so the solution is to associate the site or surgeon's performance numbers with the patients before aggregating at adata source220. Typically, thedata source220 will have only one bin in the aggregation but other data, such as the surgeons' numbers can be combined in to this bin. Then those numbers can be aggregated again at the exchange. In this way, the only information transmitted from thedata source220 is a number performed procedures and not patients' identities.
• In another application of the present invention, complication rates from bypass surgery (or other medical procedures) for different hospitals could be prepared. This query requires some sort of site identifier for comparison. Theexchange server400 can provide a random number to be used as an exchange member220 (or hospital) identifier in sending out the query. Theexchange member220 can retain that identifier and associate the identifier with the query, but theexchange server400 retains no record of the association. Theexchange server400 compiles the results, returns the fully aggregated data, not broken down by site, to the requestor210/300. The exchange server at the requestor210/300 then compares the results to the global results, and so no comparisons are done or retained at theexchange server400. Of course, the categorization of similar datasource exchange members220 should provide large enough groupings that no single hospital (exchange member220) is alone in a group.
• The foregoing description of the preferred embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. For example, embodiments of the present invention may employ known statistical methods not based on data cubes to collect and aggregate relevant data. Thus, many embodiments of the invention can be made without departing from the spirit and scope of the invention.

Claims (49)

1. A data collection method, comprising:

a. a computer receiving a data request from a requestor;

b. the computer formatting the request and forwarding the formatted request to at least one data location; the at least one data location retrieving data comprising raw information, confidential information, or personal data responsive to the formatted request;

c. using the data to generate summary data that does not contain the raw information, confidential information, or personal data; and transmitting the summary data to the computer; the computer aggregating and analyzing the summary data to ensure that the requestor will have no ability to identify said data or data location; and

d. the computer forwarding the aggregated and analyzed summary data to the requestor.

2. The method according toclaim 1, wherein the step of creating summary data includes the step of analyzing and aggregating data resident at the at least one data location.

3. The method according toclaim 1, wherein the requestor is at least one of a requesting member and a requesting non-member.

4. The method according toclaim 1, wherein the at least one data location is a non-requesting member.

5. The method according toclaim 1, wherein data responsive to the formatted request includes at least one of private and non-private data.

6. The method according toclaims 1, wherein the data responsive to the formatted request may include at least one of individual records and group records.

7. The method according toclaim 1, wherein the step of creating summary data includes removing all source identifier information.

8. The method according toclaim 1, wherein the aggregated and analyzed summary data does not include individual records, private records and source identifiers.

9. The method according toclaim 1, wherein the step of the at least one data location retrieving data includes:

a. forwarding the formatted request to at least one secondary data location;

b. creating summary data at the at least one secondary data location; and

c. transmitting the summary data to the at least one data location.

10. The method according toclaim 1, wherein the step of the at least one data location retrieving data responsive to the formatted request includes multi-tiered data retrieval, analysis and aggregation.

11. The method according toclaim 1, further including the step of generating a bill for the requesting non-member based upon the requesting non-member's data request.

12. A system for data collection and processing, comprising:

a. an exchange hub;

b. a requesting entity communicatively coupled to the exchange hub;

c. at least one data location communicatively coupled to the exchange hub; wherein the exchange hub receives a request for information from the requesting entity, processes the received request, forwards the received request to the at least one data location, aggregates all data responsive to the request from the at least one data location so as to create an aggregated data result to ensure that the requestor will have no ability to identify said data or data location; and transmits the aggregated data result to the requesting entity; and

d. wherein the at least one data location retrieves data comprising raw information, confidential information, or personal data responsive to the received request; aggregates the data to generate summary data that does not contain the raw information, confidential information, or personal data; and transmits the summary data to the exchange hub.

13. The system according toclaim 12, further including a data agent located at the at least one data location for retrieving data responsive to the request.

14. The system according toclaim 12, wherein the requesting entity is at least one of a requesting member and a requesting non-member.

15. The system according toclaim 12, wherein the exchange hub aggregates and analyzes information received from the at least one data location and data resident to the exchange hub.

16. The system according toclaim 12, wherein the aggregated and analyzed information does not include any source identifier information.

17. The system according toclaim 12, wherein the at least one data location stores at least one of private and non-private data.

18. The system according toclaim 12, exchange hub may send a further request for information based upon data received in response to the request for information.

19. The system according toclaim 12, wherein the at least one data location includes a multi-tiered group of secondary data locations containing responsive data.

20. The system according toclaim 12, wherein the exchange hub includes an analytic engine for processing requests for information received from a requesting entity, receiving data responsive to the requests for information, aggregating and analyzing the received data and forwarding the aggregated and analyzed data to the requesting entity.

21. The system in accordance withclaim 12, wherein the exchange hub includes a summary data module for storing the results of previous requests for aggregated and analyzed data.

22. The system according toclaim 12, wherein the exchange hub includes a central billing module for generating a billing statement for a requesting non-member.

23. A multi-tiered process for directing computer information comprising the steps of:

a. instructing a second computer to:

i. receive information from a first computer;

ii. format the information into a request; said request not containing identification information about the first computer in the request;

iii. and send the request to a decentralized set of third computers;

b. instructing one of the third computers to:

i. process the request from the second computer;

ii. look-up information in response to the request from a plurality of records containing raw information;

iii. generate a reply to the request by aggregating the information from the records which includes analyzed data but does not include the raw information, and

iv. send the reply to the second computer;

c. instructing the second computer to:

i. receive a plurality of replies from the set of third computers;

ii. aggregate the replies to generate summary data which does not contain the raw information; and

iii. send the summary data to the first computer.

24. The process ofclaim 23 wherein the raw information includes individual records, private records, or source identifier information.

25. A data collection method, comprising:

a. a requestor generating a data request;

b. a computer receiving the data request from the requestor;

c. the computer formatting the request and forwarding the formatted request to at least one data location;

d. the at least one data location retrieving data responsive to the formatted request, creating summary data based upon the data and transmitting the summary data to the computer; wherein the summary data does not include individual records, private records, and source identifiers;

e. the computer aggregating and analyzing the summary data;

f. the computer forwarding the aggregated and analyzed summary data to the requestor.

26. The method according toclaim 25, wherein the step of creating summary data includes the step of analyzing and aggregating data resident at the at least one data location.

27. The method according toclaim 25, wherein the requestor is at least one of a requesting member and a requesting non-member.

28. The method according toclaim 25, wherein the at least one data location is a non-requesting member.

29. The method according toclaim 25, wherein data responsive to the formatted request includes at least one of private and non-private data.

30. The method according toclaim 25, wherein the data responsive to the formatted request may include at least one of individual records and group records.

31. The method according toclaim 25, wherein the step of creating summary data includes removing all source identifier information.

32. The method according toclaim 25, wherein the step of the at least one data location retrieving data includes:

a. forwarding the formatted request to at least one secondary data location;

b. creating summary data at the at least one secondary data location; and

c. transmitting the summary data to the at least one data location.

33. The method according toclaim 25, wherein the step of the at least one data location retrieving data responsive to the formatted request includes multi-tiered data retrieval, analysis and aggregation.

34. The method according toclaim 27, further including the step of generating a bill for the requesting non-member based upon the requesting non-member's data request.

35. The data collection method ofclaim 25, wherein the summary data is not encrypted.

36. The data collection method ofclaim 25, wherein the summary data is not de-identified.

37. A system for data collection and processing, comprising:

a. an exchange hub;

b. a requesting entity communicatively coupled to the exchange hub; and

c. at least one data location communicatively coupled to the exchange hub,

d. wherein the exchange hub receives a request for information from the requesting entity, processes the received request, forwards the request to the at least one data location, aggregates all data responsive to the request from the at least one data location so as to create an aggregated data result; and transmits the aggregated data result to the requesting entity; and

e. wherein the aggregating data does not include individual records, private records and source identifiers.

38. The system in accordance withclaim 37, further including a data agent located at the at least one data location for retrieving data responsive to the request.

39. The system according toclaim 37, wherein the requesting entity is at least one of a requesting member and a requesting non-member.

40. The system according toclaim 37, wherein the exchange hub aggregates and analyzes information received from the at least one data location and data resident to the exchange hub.

41. The system according toclaim 37, wherein the aggregated and analyzed information does not include any source identifier information.

42. The system according toclaim 37, wherein the at least one data location stores at least one of private and non-private data.

43. The system according toclaim 37, exchange hub may send a further request for information based upon data received in response to the request for information.

44. The system according toclaim 37, wherein the at least one data location includes a multi-tiered group of secondary data locations containing responsive data.

45. The system according toclaim 37, wherein the exchange hub includes an analytic engine for processing requests for information received from a requesting entity, receiving data responsive to the requests for information, aggregating and analyzing the received data and forwarding the aggregated and analyzed data to the requesting entity.

46. The system in accordance withclaim 37, wherein the exchange hub includes a summary data module for storing the results of previous requests for aggregated and analyzed data.

47. The system according toclaim 37, wherein the exchange hub includes a central billing module for generating a billing statement for a requesting non-member.

48. The system ofclaim 37, wherein the summary data is not encrypted.

49. The system ofclaim 37, wherein the summary data is not de-identified.

Images