Patent Publication Number: US-11657182-B2

Title: Highly secure networked system and methods for storage, processing, and transmission of sensitive personal information

Description:
CROSS-REFERENCE TO RELATED APPLICATION DATA 
     This application is a continuation of U.S. patent application Ser. No. 16/934,276 filed Jul. 21, 2020, which is a continuation of U.S. patent application Ser. No. 15/517,772 filed on Apr. 7, 2017, which is a National Stage application of International Application No. PCT/US2015/054444 filed on Oct. 7, 2015, which claims priority to U.S. Provisional Patent Application Ser. No. 62/060,898, filed on Oct. 7, 2014, all of which are incorporated herein by reference in their entirety. 
    
    
     FIELD OF TECHNOLOGY 
     The present disclosure relates generally to secure networks, and more particularly to securing information within a network of computers. 
     BACKGROUND 
     Various industries collect personal information about individuals. Regardless of the particular industry, personal information is considered highly sensitive and often needs to be secured in an attempt to prevent unauthorized access. For example, in the healthcare context, healthcare providers often use locally maintained computing platforms to manage and secure patient records. These locally maintained computer platforms allow the healthcare providers to satisfy their duties under industry and government standards, such as the Health Insurance Portability and Accountability Act (“HIPAA”). 
     Often times, researchers and other third parties desire access to personal information. In the healthcare industry, personal information cannot be released to researchers until it is secured. However, modern computer technology frequently makes it possible to reverse engineer the “secure” personal information into its unsecure source data. This is undesirable because it gives third parties unauthorized access to sensitive personal information. 
     SUMMARY 
     The present disclosure generally provides a highly secure networked system and methods for storage, processing, and transmission of sensitive, such as personal/private, information. Data contributor computing environments store sensitive personal information. The personal information is cleansed by a data contributor computing environment using specific rules/logic provided to data contributor computing environments by a secure facility computing environment. The secure facility computing environment transmits the same rules/logic to each data contributor computing environment. Thus, cleansing of data at each data contributor computing environment occurs the same way. 
     The cleansed personal information is salted (using a public salt) and hashed using a one-way hashing algorithm. Each data contributor computing environment uses the same public salt and one-way hashing algorithm. This ensures that cleansed personal information for a particular individual or grouping of individuals associated with any given contributor computing environment is hashed into an identically structured hashed field or record across multiple data contributor computing environments (i.e. all contributing computing environments provide data to be secured from that facility structured in the same manner). 
     Data (at least partially including the hashed personal information) is communicated from the data contributor computing environments to the secure facility computing environment. The hashed personal information is therein salted and hashed a second time using a private salt and a one-way hashing algorithm. The private salt is maintained solely within the secure facility computing environment, and is not communicated to or otherwise accessible to third parties (i.e., data contributor computing environments and/or third party, e.g. researcher, computing devices). This further secures the private data in a manner that prevents third parties from re-identifying the second hashed personal information into its unhashed source data. 
     The second hashed personal data value is linked to previously second hashed data values (when possible) and is assigned a unique ID. This linking of the data values to a unique ID provides a robust secure data platform, e.g. for research or data mining, because unhashed data of one data contributor computing environment is linked and accessible along with related data of other data contributor computing environments via the unique IDs. 
     In one embodiment, particular individuals provided access to the highly secure information such as researchers, desiring access to data, identify parameters for a research project. In response, the secure facility computing environment compiles data from various sources (linked using unique IDs) into a data dictionary. The data dictionary undergoes compliance and statistical analyses related to the potential of a researcher re-identifying the unhashed source data. When the data dictionary satisfies the compliance and statistical analyses, the data dictionary is stored and presented to the researcher as a certified view. 
     A researcher may be granted access to one or more certified views via a virtual private network. Each certified view may be presented through a different virtual desktop interface. Access to the certified views, via the virtual private network, by a researcher computer may involve a two factor authentication process. In this manner, a technical solution is provided to permit, among other things, stores of private data to be securely maintained as private data while otherwise being made available in further secure fashion to certified users in a limited and controlled manner. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of devices, systems, and methods are illustrated in the figures of the accompanying drawings, which are meant to be exemplary and non-limiting, in which like references are intended to refer to like or corresponding parts, and in which: 
         FIG.  1    illustrates an embodiment of a secure networked system for securing personal/private information and providing limited/controlled access to the secure personal information according to the present disclosure; 
         FIG.  2 A  is a process flow diagram illustrating a method for transforming personal information into secure personal information in the network according to the present disclosure; 
         FIG.  2 B  is a process flow diagram further illustrating the method of  FIG.  2 A  for transforming personal information into secure personal information by two separate and distinct data contributors in the network according to the present disclosure; 
         FIG.  3    is a process flow diagram illustrating a method for matching and linking hashed data values of an identity vault using unique IDs according to the present disclosure; 
         FIGS.  4 A and  4 B  are process flow diagrams illustrating a method for rekeying/restating previously generated unique IDs according to the present disclosure; 
         FIG.  5    illustrates an example data structure representation of unique IDs and associated concatenated hashed values within the identity vault according to the present disclosure; 
         FIG.  6    illustrates an example of how related claims data and clinical record data may be associated across various data storages using a unique ID in a healthcare data embodiment of a network according to the present disclosure; and 
         FIG.  7    illustrates a system architecture of the virtual private network (VPN) illustrated in  FIG.  1    according to the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     The detailed description of the present disclosure set forth herein makes reference to the accompanying drawings, which show various embodiments by way of illustration. While these various embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, it should be understood that other embodiments may be realized and that logical and physical changes may be made without departing from the spirit and scope of the disclosure. Thus, the detailed description herein is presented for purposes of illustration only and not of limitation. For example, the steps recited in any of the method or process descriptions may be executed in an order other than as presented and are not limited to the order presented. Moreover, references to a singular embodiment may include plural embodiments, and references to more than one component may include a singular embodiment. 
     The present disclosure provides extensive and specialized processes for transforming personal information into secure data. The present disclosure additionally provides particularized databases containing vast amounts of de-identified medical claims, electronic medical records, and other data, such as sociodemographic information collected from consumer research databases structured to provide automated access to vast amounts of information. While the illustrative embodiments described herein may relate to healthcare information, it should be appreciated that secure systems as described may be implemented according to the disclosure for protection and transformation of other types of sensitive information such as financial information, legal information, national security information, or the like (generally referred to herein as “personal” or “private” information). The sophisticated, specialized, and specially configured networked systems and processes described herein, for example, may facilitate data driven healthcare research without compromising privacy with respect to sensitive personal information (again, the information protected, could just as readily be other information requiring high levels of security, privacy and control while facilitating controlled access for manipulation and processing). Specifically, the systems in the illustrated embodiment are configured to provide, among other things, high levels of security of vast amounts of personal/private data while simultaneously providing access to the secure personal/private data in a way that benefits the healthcare industry and its patients. 
     Protection and security of personal digital data is a persistent technical problem that arose after the advent of the computer. The problem is exacerbated by the proliferation of use of digital devices and the volumes of data collected, accessible and processed by such devices. An additional technical problem relates to maintaining security and privacy of vast amounts of personal data while providing digital access to the data for research aimed at furthering use and utility of the vast amounts of data, such as for enhancing consumer and patient outcomes and the delivery of healthcare. It will become apparent from reading the below detailed description that these technical problems are solved by the various teachings herein. 
     Referring to  FIG.  1   , a secure networked system  100  for securing personal information and providing limited and controlled access to the secure data is described. The system  100  includes one or more data contributor computing environments  102 . Each data contributor computing environment  102  includes a data storage  104  that houses clear text data. For example, the clear text data may include healthcare claims data and clinical data that are each partially made up of personal information. The clear text healthcare claims data may be separate and distinct data from the clear text clinical data. Each data contributor computing environment  102  also includes a processor  106  that is in communication with the data storage  104  and that is configured to sanitize or cleanse and hash the personal information as described herein below with respect to  FIGS.  2 A and  2 B . 
     Generally, the cleansed, hashed personal information and associated clear text non-personal information is communicated to a data receipt zone  110  of a secure facility computing environment  108 . Transmission of the data may occur actively by the processor  106  (i.e., the data receipt zone  110  passively receives the data). Alternatively, transmission of the data may occur passively with respect to the data contributor computing environment  102  (i.e., a processor of the secure facility computing environment  108  may actively retrieve the data from the data contributor computing environment  102 ). The transmission of such data may happen in real time or it may happen in batch processes. At the data receipt zone  110 , the data is staged and prepared for subsequent processing as disclosed herein below. 
     The cleansed data is loaded into and stored within respective storage or databases. For example, healthcare claims data and clinical data may be stored within databases, such as a de-identified claims storage  112  and a de-identified clinical storage  114  of an extract, transform, and load (ETL) zone  116  of the secure facility computing environment  108 , respectively. A processor  118  of the ETL zone  114  hashes the previously hashed personal information a second time, as described herein below with reference to  FIGS.  2 A and  2 B . 
     The second hashed personal information values are stored within an identity vault  112 . The newly hashed and stored personal information values are thereafter “linked” by the processor  118  as described with reference to  FIG.  3    below. Once a unique ID is associated with a recently stored personal information value, the same unique ID is associated with the cleansed and second hashed data (within the various storages) to which it relates. For example, when the data is healthcare data, the unique ID is associated within the cleansed, second hashed claims data and clinical data stored within the de-identified claims and clinical storages  116 ,  118 . 
     Prior to the cleansed, second hashed data being stored within various storage databases, it may be processed to change encounter IDs, provider IDs, and facility IDs, provided by the data contributor computing environment(s)  102 , into sequential alternate IDs. This helps eliminate trace back of the de-identified cleansed data to its source data stored within the data storage  104  of the data contributor computing environment  102 . 
     When a researcher, via a researcher computing device  122 , indicates they want to conduct research, a “data dictionary” is created from the clinical and claims data within the de-identified claims and clinical storages  112 ,  114 . The data dictionary is essentially a description of the data presented in a certified view. The data that makes up a data dictionary may be specific to a geographic area/location, membership (e.g., membership in a particular coverage plan or program), a data domain, data type, or some other interest defined by the researcher. For example, an illustrative data dictionary may contain indicators such as table name, field name, business description, and various parameters including data type, field length, and valid values. 
     The generated data dictionary is communicated to a data storage zone  124  where the data dictionary is analyzed for compliance with respect to clarity/proprietary standards. The data storage zone  124  includes an admin schema storage  126  that stores rules/logic relating to clarity/proprietary standards that data must comply with prior to being viewable by a researcher. One illustrative rule identifies fields of data that present re-identification risk and that should be removed from the data dictionary. Another illustrative rule identifies fields that present re-identification risk and contain values that should be consolidated to lessen the risk. An illustrative and non-limiting list of such data values includes bed size, discharge status, and admit channels. A further illustrative rule identifies fields that require standard language to comply with auditing. Yet another illustrative rule may identify fields that are required to be flagged as potentially identifying personal information characteristics. 
     Various statistical de-identification rules/logic may also be applied to the data dictionaries while in the data storage zone  124 . The statistical de-identification rules/logic use statistical methodology to evaluate data of a data dictionary as well as public records to, through reduction of data and consolidation of values, achieve a statistical determination of a very small risk of re-identification. A threshold risk value of re-identification of de-identified data may be set as a function of, for example, geographic location, number of patients, age, timing of disease occurrence, number of providers, or related data. The statistical de-identification rules/logic may be stored within the admin schema storage  126  or a separate storage (not illustrated). 
     When a data dictionary passes the compliance standards, as set out by the rules/logic of the data storage zone  124 , the data dictionary is communicated to a data access zone  128  where it is stored in a certified view storage  130 . Each certified view storage  130  may include only one data dictionary. Alternatively, each certified view storage  130  may contain all of the certified views approved for viewing by a single researcher, or certified views may require no storage. A researcher can view different certified views from different desktops in the manner of one and only one view per desktop. This prevents unauthorized access to certified views by unapproved researchers. While there may be overlap (e.g. common data) between two certified views it may be desirable for security purposes that each certified view is wholly independent of another. 
     A researcher may indicate they desire a previously approved certified view to be augmented to include more types of data. When this occurs, the other data types are identified within the data storages  112 ,  114 . This data is then compiled into the original data of the certified view. The updated data compilation thereafter undergoes the aforementioned compliance and statistical analyses described with respect to the generation of a new data dictionary. If the augmented certified view is analyzed to have a very small risk of source data re-identification, it is stored as an updated certified view and is published to the researcher(s) authorized to view the original certified view. 
     The secure facility computing environment  108  also includes a virtual private network (VPN)  132  that is configured to restrict researcher computer  122  access to certain certified views. The structure of the VPN  132  and its interaction with the data access zone  128  and researcher computers  122  is described in further detail below with respect to  FIG.  7   . 
     Attention is now given to  FIG.  2 A , which illustrates a method  200  for transforming and securing personal/private/sensitive information (all referred to herein as “personal information”), according to the present disclosure. At block  202  a data contributor computing environment  102  standardizes/sanitizes clear text of personal information. At block  204  the data contributor computing environment  102  salts and hashes the standardized/sanitized personal information. At block  206  the secure facility computing environment  108  thereafter receives the cleansed information from the contributor computing environment and salts and hashes the previously cleansed/hashed personal information values. At block  208  the secure facility computing environment  108  stores the second salted and hashed personal information values within an identity vault. The identity vault contains previously stored second salted and hashed personal information values associated with unique IDs. At block  210  the secure facility computing environment  108  links the stored second salted and hashed personal information values with related previously stored hashed values (if possible as described herein below) and associates the second salted and hashed personal information values with associated unique IDs. 
     Each of the blocks illustrated in the method  200  of  FIG.  2 A  involve multiple processing steps, which are more specifically described with reference to  FIG.  2 B .  FIG.  2 B  illustrates the transformation and securing of personal information data by two separate and distinct data contributor computing environments  102 . Corresponding blocks/processes of the data contributor computing environments  102  are collectively described and numbered herein because the processing of personal information data by different data contributor computing environments  102  is exactly the same. This ensures that the processing of personal information data by different data contributor computing environments  102  generates substantially similarly structured output hashed values that can be successfully linked by the secure facility computing environment  108 . 
     Each data contributor computing environment  102  standardizes/sanitizes the personal information clear text using specific rules/logic (illustrated as  212 ). An illustrative and non-limiting list of personal information includes social security number (SSN), first name, last name, and address. While not being personal information, contributor IDs are also salted and hashed according to the teachings herein described. In the context of the healthcare industry, personal information may additionally include Medicare ID, Medicaid recipient number, and Medicaid family number, for example. One illustrative sanitization rule may change the clear text (which may include both upper and lower case characters) into purely upper case or purely lower case text. This rule ensures that hashing of the clear text produces identical values because, for example, “E” produces a different hashed value than “e”. Another illustrative rule removes punctuation marks/characters from the clear text. Yet another illustrative rule removes spaces within the clear text. A further illustrated rule removes line ends and carriage returns from the clear text. 
     The standardized/sanitized text is salted using a “common salt” (illustrated as  214 ). The term “common salt,” as used herein, refers to a single salt used by every data contributor computing environment  102 . “Salting” as known to those skilled in the art is a cryptography concept that involves providing additional data, such as a common random number, as an additional input (e.g. along with confidential or private information) to a one-way function that hashes the private information. 
     The concatenation of the salt and sanitized clear text of the personal information becomes the message digest (illustrated as  216 ) that is input to and hashed using a hashing algorithm (illustrated as  218 ). For example, the hashing algorithm may be a one-way hashing algorithm such as SHA-256. However, one skilled in the art should appreciate that different one-way hashing algorithms may be used, depending upon the data to be hashed and the security level to be achieved. The resulting personal information hashed values (illustrated as  220 ) may be represented as 64 character values. 
     For illustration, Table 1 below depicts illustrative pre-sanitization clear text personal information and Table 2 depicts the resulting hashed values of the sanitized and salted protected personal information. 
     
       
         
           
               
             
               
                 TABLE 1 
               
             
            
               
                   
               
               
                 Illustrative pre-sanitization clear text personal information. 
               
            
           
           
               
               
               
               
            
               
                   
                 FIRST_NAME 
                 LAST_NAME 
                 SSN 
               
               
                   
                   
               
               
                   
                 Joseph 
                 Smith 
                 000000000 
               
               
                   
                 John 
                 Smith 
                 111111111 
               
               
                   
                 Jack 
                 Smith 
                 222222222 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                 TABLE 2 
               
             
            
               
                   
               
               
                 Illustrative resulting hashed values of the sanitized and salted personal information of Table 1. 
               
            
           
           
               
               
               
            
               
                 FIRST_NAME_E 
                 LAST_NAME_E 
                 SSN_E 
               
               
                   
               
               
                 12343cd576727e759d144ec497e 
                 123m812ae83f17a8488bbm9f5f0 
                 123fc7cb86eff142711b4d1e2e7a 
               
               
                 19ecem089cdmdb11578ae10a9 
                 d2m74c46m94e2f42a6bd76d966 
                 ead2aa6f4ce605481632a7430e0 
               
               
                 456092mabafc1d7d 
                 14f71a6fd1efac 
                 m467c79a778b 
               
               
                 1239a57m93e4f368d62e7125890 
                 1231dd4m4e87f2486ee1e639a38 
                 123503bb674edddd4bcfda8865a 
               
               
                 ae6b5230b59024468ff85f7f8cf84 
                 b3e5942d68a9118b107354abacb 
                 d3acfb851555m44ce8325eb47be 
               
               
                 43a1c8e6533 
                 9me34a37824cb 
                 39f72f7bef345 
               
               
                 123e0ead436f8fem1f52b91621ce 
                 123c2edcd9b53e3b6966efb2b20 
                 123f120bb5698d520c5691b6d60 
               
               
                 9b524m53c6c5051fbbfc18cfec41 
                 1f52441dd677d2987bcca3d0635 
                 3am0bfd662d13bf177a04571f9d1 
               
               
                 744cb11m742 
                 77e882cb6m1d9 
                 mcm745dfa2a5 
               
               
                   
               
            
           
         
       
     
     Once the hashed values (illustrated as  220 ) are communicated to and received by the secure facility computing environment  108 , the hashed values are salted using a “private salt” (illustrated as  222 ). As used herein, the term “private salt” refers to a salt maintained within and used solely by the secure facility computing environment  108 . The private salt is not communicated to the data contributor computing environments  102 . This provides an additional level of security that prevents reverse engineering of hashed values into their unhashed source data. 
     The salted values (illustrated as  222 ) are hashed a second time using a one-way hashing algorithm (illustrated as  224 ). The second hashing of the data may produce 64 character values. As with the first hashing of the data (illustrated as  218 ), the SHA-256 hashing algorithm may also be used by the secure facility computing environment  108 . Likewise, one skilled in the art should appreciate that different hashing algorithms may be used depending upon the type of data to be hashed and the security level to be achieved. One skilled in the art should appreciate that the hashing algorithm(s) used to hash the data (illustrated as  218  and  224 ) may be the same or different depending upon implementation of the present disclosure. 
     For illustration, Table 3 below depicts resulting second hashed values of the first hashed values of Table 2. A comparison of Tables 2 and 3 illustrates that the hashed values generated by the data contributor computing environments  102  are different from those generated by the secure facility computing environment  108 . This is a direct result of the use of the different salts (i.e., public and private). This diminishes, or eliminates, the potential of the second hashed data being re-identified into its clear text source data. 
     
       
         
           
               
             
               
                 TABLE 3 
               
             
            
               
                   
               
               
                 Illustrative resulting second hashed values of the first hashed values of Table 2. 
               
            
           
           
               
               
               
            
               
                 FIRST_NAME_E 
                 LAST_NAME_E 
                 SSN_E 
               
               
                   
               
               
                 1238ca657102ae567mc8845167 
                 123m812ae83f17a8488bbm9f5f0 
                 123fcee4cf166e0f1d0c11033894 
               
               
                 957a78a1cd321342ca09d82a28a 
                 d2m74c46m94e2f42a6bd76d966 
                 2f6a8cb1049e78c594ef49952aed 
               
               
                 m53a7e5830fd89 
                 14f71a6fd1efac 
                 348cdda3e63 
               
               
                 123bff7m485135c547322b67779 
                 1231dd4m4e87f2486ee1e639a38 
                 1237546m08f4857e29c90f3ffc3e 
               
               
                 2b39m0d8b08bcd8896m9m3699 
                 b3e5942d68a9118b107354abacb 
                 7509ee072b9234b38a2f3a1a9d5 
               
               
                 a3bmb6e7b6e205a 
                 9me34a37824cb 
                 3em0641d6456 
               
               
                 1232e6c27e28c72a14a20c07e13 
                 123c2edcd9b53e3b6966efb2b20 
                 123b5e9329e72f942c27ea570a1 
               
               
                 8d45d7fca52333f673f560fc4678c 
                 1f52441dd677d2987bcca3d0635 
                 946de34b10463f55ef366c89556a 
               
               
                 734db8ddaf1 
                 77e882cb6m1d9 
                 2a5bf372e634 
               
               
                   
               
            
           
         
       
     
     The different fields run through the hashing algorithm may be tagged with a hash tag  226  effectively identifying the field of the hashed value prior to storage in an identity vault, or the hashed value output of the hashing algorithm  224  may be the hash tag  226  for direct storage in the identity vault. The second hashed values, in either event, are thereafter stored within the identity vault (such as the identity vault  120 ) (illustrated as  228 ). 
     Once stored in the identity vault, the second hashed values are matched and linked to previously stored second hashed values, when possible (illustrated as  230 ). Matching and linking of the data involves the use of unique IDs. Each unique ID is associated with data representative of a specific individual. The recently stored second hashed data either receives a newly generated unique ID (when the individual associated with the recently stored data is not represented by previously stored data within the identity vault) or it receives a unique ID previously generated (when the individual associated with the recently stored data is represented by previously stored data stored within the identity vault). 
     A method  300  for generating a unique ID and matching and linking hashed data values to the identity vault is described with reference to  FIG.  3   . The individual hashed values (e.g., contributor ID, SSN, first name, last name, address, DOB, etc.) are concatenated for each record/file uploaded into the identity vault (illustrated as  302 ). In an illustrative healthcare industry example, the individual hashed values may additionally include a Medicare ID. A processor determines whether an exact match exists between the recently uploaded/stored hashed contributor ID value and a previously stored hashed contributor ID value (illustrated as  304 ). The processor may also determine whether an exact match exists between the recently stored hashed SSN value and associated clear text DOB value, and previously stored hashed SSN values and their associated clear text DOB values (illustrated as  306 ). The processor may further determine whether an exact match exists between the recently stored hashed Medicare ID value and its associated clear text DOB value, and previously stored hashed Medicare ID values and their associated clear text DOB values (illustrated as  308 ). The processor may additionally determine whether an exact match exists between the recently stored hashed first name value, hashed last name value, and their associated clear text DOB value, state value, and zip code value, and previously stored hashed first name values, hashed last name values, and their associated clear text DOB values, state values, and zip code values (illustrated as  310 ). If any matches are determined to exist, the unique ID associated with the matching previously stored data is associated with the recently stored data (illustrated as  312 ). Linking of the data ensures that stored hashed personal information of an individual is associated within the identity vault. This provides a robust data set for research purposes. Alternatively, if no matches are determined to exist, a new, non-previously generated unique ID is generated and associated with the recently stored hashed personal information (illustrated as  314 ). If the recently stored hashed data is the first batch of data received from a specific data contributor computing environment  102 , decision point  304  may be omitted because no matching hashed contributor ID for that contributor will exist in the identity vault. 
     If an exact match is determined between the recently stored hashed data value and previously stored data, the processor may compare all demographic values of the recently stored data (including both hashed and clear text values) to analogous values of the matching previously stored data (not illustrated). Each generated unique ID may be an alpha, numeric, or alphanumeric value. 
     Referring now to  FIGS.  4 A and  4 B , a method  400  for rekeying/restating previously generated unique IDs is described. A unique ID associated with specific hashed data may need to be restated/altered when additional data is subsequently stored within the identity vault. Restating of unique IDs may involve a rekey process. For example, when subsequently stored hashed data includes an additional data element/field value not present in the previously stored data, the unique ID of the previously stored data may be altered/rekeyed and applied to both the previously and subsequently stored and related hashed data. According to an example, stored hashed data may be a bridge record that associates multiple hashed data files. If the bridge record gets deleted/corrupted (e.g., during maintenance of the secure facility computing environment  108 ), the unique ID associated with the bridge record may need to be restated for the bridge record and/or any associated records/data files. 
     Rekeying may involve determining whether an exact match exists between a recently uploaded/stored hashed contributor ID value and previously stored hashed contributor ID values (illustrated as  402 ). Rekeying may also include determining whether an exact match exists between a recently stored hashed SSN value and its associated clear text DOB value, and previously stored hashed SSN values and their associated clear text DOB values (illustrated as  404 ). Rekeying may further involve determining whether an exact match exists between a recently stored hashed Medicare ID value and its associated clear text DOB value, and previously stored hashed Medicare ID values and their associated clear text DOB values (illustrated as  406 ). Additionally, rekeying may include determining whether an exact match exists between recently stored hashed first and last name values, and their associated clear text DOB value, state value, and zip code value, and previously stored hashed first and last name values, and their associated clear text DOB values, state values, and zip code values (illustrated as  408 ). While the described rekeying processes are identical to those used for matching/linking data described herein with respect to  FIG.  3   , one skilled in the art should appreciate that the logics/processes used in the rekeying and matching/linking processes may be different. 
     If it is determined that no matches exist, a new unique ID is generated for and associated with the recently stored hashed data (illustrated as  410 ). Conversely, if it is determined that a match exists, all data fields of the currently stored and matching previously stored data are compared (illustrated as  412 ). If there is an exact match across all of the data fields, the unique ID associated with the previously stored data remains unchanged, and is also associated with the recently stored data (illustrated as  414 ). Alternatively, if the hashed contributor ID values match and at least one demographic data field (e.g., DOB, state, zip code, etc.) of the recently stored data is not present in the previously stored data, a new unique ID is generated and associated with both the previously and recently stored data (illustrated as  416 ). When step  416  occurs, the previously stored data is no longer associated with its previous unique ID. 
       FIG.  5    illustrates how unique IDs and their associated concatenated hashed values may be represented within the identity vault. As stated above with respect to  FIG.  1   , once a unique ID is associated with the recently loaded hashed personal information, the same unique ID is also associated with the clear text data (e.g., within the de-identified claims and clinical storages  116 ,  118 ) to which it relates.  FIG.  6    illustrates how related healthcare claims data and clinical record data may be associated across data storages via a unique ID. The data format illustrated in  FIG.  6    may be how data is represented within a data dictionary. 
     Attention is now given to  FIG.  7   , which illustrates the system architecture of the VPN  132  illustrated in  FIG.  1   . A researcher, via a computing device  122 , accesses certified views for which the researcher has been granted access. Each researcher may be granted access to a single certified view or multiple certified views. When a researcher properly authenticates a session (as described in detail below) the VPN  132  accesses certified views of the researcher from the certified view storage  130  of the data access zone  128  (illustrated in  FIG.  1   ) and places them in a sandbox  702 . The sandbox  702  provides a researcher with access to all of its authorized views during a single session. Each certified view may correspond with one virtual desktop interface (VDI). For example, a researcher that has access to two (2) certified views may be presented with two (2) VDIs upon accessing the virtual private network (VPN)  132 . This separation of the certified views eliminates the possibility of a researcher with access to multiple certified view combining data from two or more certified views, thereby effectively limiting the risk of personal information re-identification. 
     Access by the researcher computer  122  to the certified view via the VPN  132  may be restricted by a two factor authentication. An illustrative two factor authentication includes (1) a username and password factor and (2) a phone factor. Each of the authentication factors may use secure protocols and may be stored in an encrypted manner. The username and password factor may involve the researcher inputting a username and password specific to a particular directory on their computing device  122 . Once the username and password credentials are supplied, the researcher is prompted to perform the second (i.e., phone factor) authentication. This authentication may be performed a variety a ways. For example, the VPN  132  may cause the researcher&#39;s phone to receive a call. To authenticate, the researcher answers the phone call and provides a personal identification number (PIN). In another example, the VPN  132  causes the researcher&#39;s phone to receive a text message. To authenticate, the researcher responds to the text message using the PIN. In another example, the VPN  132  may cause an app on the researcher&#39;s phone to receive a notification. To authenticate, the researcher accesses the app, inputs the PIN, and selects “authenticate.” 
     The two factor authentication information (i.e., username, password, and PIN) are communicated from the researcher computer  122  through a firewall  704  to an analytics server  706 . For example, the analytics server  706  may be the NETEZZA MAKO® server produced by International Business Machines Corporation (IBM). To authenticate the researcher within the VPN  132 , the analytics server  706  communicates with an authentication server  708 . The authentication server may be a lightweight directory access protocol (LDAP) server. 
     Although aspects of the present disclosure are described with respect to examples in a health care data environment, it should be understood that various disclosed techniques can be used in numerous other fields of technology in which sensitive information needs to be transformed, secured, and provided to individuals on a limited and controlled access basis. Various applications of the disclosed techniques provide substantial improvements to the functioning of the computer apparatus and the technical environments in which the various applications are implemented. 
     Moreover, although the present disclosure has been described herein with reference to the accompanying drawings, it is to be understood that the present disclosure is not limited to those precise teachings, and that various other changes and modifications may be made by one skilled in the art without departing from the spirit and scope of the present disclosure.